Illustration : méthode de recette proposée, sans résultat client représenté. Schéma original GEEKKECH, 14 novembre 2026 — CC BY 4.0.
Une interface créée par IA peut sembler terminée tout en bloquant une personne qui navigue au clavier ou utilise un lecteur d’écran. Pour un développeur indépendant, ce décalage ouvre une prestation précise : reprendre un parcours important, corriger les obstacles et livrer des preuves de vérification. Cette piste commerciale demande des compétences et un test de demande ; aucun revenu réalisé n’est annoncé ici.
La nouveauté : des agents mieux guidés, toujours à contrôler
Le 10 novembre 2026, Chrome a annoncé Modern Web Guidance 1.0, une version stable de ses guides pour agents de développement web. Ils couvrent notamment les formulaires, le focus et la compatibilité des navigateurs. Le billet du 11 novembre détaille des erreurs récurrentes : messages mal reliés aux champs, gestion du focus incomplète et animations ignorant les préférences de mouvement réduit.
C’est une annonce de l’équipe qui développe l’outil, avec ses propres évaluations, et non une preuve de rentabilité pour un freelance. Le texte de position de German UPA, annoncé le 12 novembre, distingue constats automatisés, évaluation spécialisée et expérience des utilisateurs. Une amélioration à un benchmark ne démontre pas l’accessibilité complète d’un produit.
Ce que le client achète réellement
Le client visé est une agence WordPress, un éditeur de plugin ou une PME ayant un formulaire de devis ou de réservation difficile à utiliser. Le forfait peut couvrir un seul parcours, ses versions française et arabe, et un nombre défini de composants. Le livrable comprend le diagnostic reproductible, les correctifs, les preuves avant/après, les environnements vérifiés et les obstacles restant ouverts.
Le contrat doit préciser les états à traiter : formulaire vide, saisie incorrecte, chargement, erreur serveur et confirmation. Une panne réseau ne doit pas laisser croire qu’une demande a été enregistrée. Le client valide aussi les textes et les règles métier ; le prestataire ne déduit pas ces règles d’une capture ou d’une réponse du modèle.
Une recette courte, fondée sur des tâches
Sur un environnement de test et avec des données fictives, écrire d’abord : « demander un devis, corriger une erreur, puis identifier la confirmation ». Fixer les navigateurs et technologies d’assistance avec le client, et consigner leurs versions exactes dans le rapport. Les guides examinés ici concernent le Web ; ils ne valident pas automatiquement une application Android native.
Rejouer ensuite le parcours sans souris avec Tab, Maj+Tab et Entrée. Vérifier que le focus est visible, qu’aucune commande essentielle n’est inaccessible et qu’une fenêtre ouverte puis fermée ne perd pas l’utilisateur. Contrôler les libellés, les erreurs et les changements de contenu avec un lecteur d’écran. Refaire les vérifications à l’agrandissement et dans la version arabe, avec son sens de lecture et ses textes réels.
Lancer un contrôle automatisé sur les états concernés, puis vérifier les résultats manuellement. La documentation Lighthouse précise que les contrôles manuels ne contribuent pas à son score. Un bon score ne remplace donc pas cette recette. Les Easy Checks du W3C se présentent eux-mêmes comme une première revue, pas une évaluation complète.
Exemple technique : une erreur qui reste compréhensible
Voici un état d’erreur fictif après une soumission. Le code HTML associe le libellé au champ et rattache l’explication au contrôle. Il illustre le balisage ; il ne contient ni traitement serveur ni système complet de validation.
<label for="email">Adresse e-mail (obligatoire)</label>
<input id="email" name="email" type="email" required
autocomplete="email" value="exemple-invalide"
aria-invalid="true" aria-describedby="email-erreur">
<p id="email-erreur">
Saisissez une adresse au format nom@domaine.tld.
</p>Lorsqu’une saisie devient valide, synchroniser la disparition du message et la suppression de aria-invalid. Si une erreur apparaît dynamiquement, prévoir sa notification et la gestion du focus selon le contexte. Le tutoriel W3C sur les notifications décrit les liens entre erreurs, champs et retour après soumission. Une couleur rouge seule ne suffit pas à expliquer ce qui doit être corrigé.
Demander à l’agent une modification limitée et une justification référencée. Examiner le diff avant de l’appliquer, puis rejouer le même scénario. Ajouter des attributs ARIA partout peut introduire des incohérences ; privilégier des contrôles HTML adaptés et vérifier le comportement final avec les outils retenus.
Simulation : un forfait de 3 200 MAD peut vite perdre sa marge
Simulation intégralement fictive, hors taxes ; ce ne sont ni des tarifs de marché ni un résultat de GEEKKECH. Prenons 3 200 MAD facturés pour dix heures : repérage 1 h, scénarios 2 h, correction 3 h, vérification 2 h, transmission 1 h et commercial 1 h. Le temps est valorisé à 200 MAD/h, soit 2 000 MAD.
Ajouter 100 MAD d’outils imputés au projet, 400 MAD de relecture spécialisée ciblée et 200 MAD d’acquisition donne un coût de 2 700 MAD. Il reste 500 MAD, soit 15,6 % du prix, avant frais fixes, impôts et imprévus. La relecture ciblée ne constitue pas un audit complet. Les abonnements et consommations IA réels doivent remplacer l’enveloppe hypothétique de 100 MAD.
Solde = 3 200 − (heures × 200) − 100 − 400 − 200
À 10 heures : 500 MAD
Seuil d’équilibre : (3 200 − 700) / 200 = 12,5 heures
À 13 heures : −100 MADCette sensibilité impose de limiter les composants, les langues et les retours inclus. Elle prolonge le raisonnement du coût par dossier accepté : le travail de vérification et de reprise compte dans l’économie de la mission.
Tester la demande avant de transformer la méthode en produit
Présenter à cinq prospects ciblés un obstacle reproductible sur un parcours qu’ils contrôlent, sans leur attribuer de pertes non mesurées. Proposer un pilote payé, avec périmètre et critères d’acceptation écrits. Mesurer les pilotes signés et le temps réel de livraison ; les compliments ou vues d’une démonstration ne sont pas du chiffre d’affaires.
Pour une agence, une revue périodique des composants peut devenir facturable si elle réduit une charge identifiée. Un SaaS ou un plugin de contrôle exige en plus hébergement, support et maintenance ; mieux vaut vérifier ce besoin sur plusieurs missions. Pour les APK et jeux, TalkBack, les appareils et les interactions propres au moteur demandent une recette distincte. Aucun élément de cette veille ne démontre leurs revenus potentiels.
Le risque commercial principal reste la promesse excessive : « entièrement accessible », « conformité garantie » ou gain de conversion supposé. Vendre le périmètre corrigé, les preuves et les limites protège la relation client. Une procédure réutilisable avec recette facilite ensuite les missions suivantes, tout en conservant une validation humaine des décisions.
Sources et dates
Actualités : Philip Walton, Chrome for Developers, Modern Web Guidance 1.0, 10 novembre 2026 ; erreurs des agents web, 11 novembre 2026. German UPA, annonce du texte de position, 12 novembre 2026, et texte intégral.
Références techniques de fond, antérieures à la fenêtre d’actualité : score Lighthouse, mise à jour le 22 octobre 2025 ; W3C WAI, Easy Checks, 9 août 2023, et User Notification, 3 juin 2022. Toutes les pages ont été consultées le 14 novembre 2026. Méthode commerciale, exemple et simulation originaux ; aucune affiliation avec les organismes cités.