Agent IA accessibilité : les leçons de l'expérience GitHub

On vous promet régulièrement qu'une IA rendra votre site accessible en un clic. La réalité documentée est plus nuancée, et plus utile. En juin 2026, GitHub a publié le retour d'expérience d'un agent IA d'accessibilité déployé en interne sur ses propres dépôts.

Cet article décortique ces résultats chiffrés, les confronte à notre propre expérience de moteur de scan RGAA, et vous donne une grille claire : ce qu'un agent IA corrige seul, ce qu'il fait mal, et ce qui reste irréductiblement humain. Commençons par les chiffres.

Un agent IA peut-il vraiment corriger l'accessibilité d'un site ?

GitHub a fait tourner un agent IA d'accessibilité expérimental sur ses pull requests, avec un objectif précis : repérer et corriger automatiquement les problèmes d'accessibilité simples dans le code front-end, avant la production.

Le bilan publié donne un repère rare dans un secteur saturé d'opinions : l'agent a analysé 3 535 pull requests, avec un taux de résolution de 68 %. Ce sont des données de production réelles, pas une démonstration de laboratoire.

Les cinq types de problèmes les plus traités par l'agent sont révélateurs de ce que l'IA gère bien :

• rendre la structure et les relations claires pour les technologies d'assistance ;
• fournir des noms clairs et concis aux contrôles interactifs ;
• s'assurer que les utilisateurs perçoivent les annonces importantes ;
• garantir des alternatives textuelles pour le contenu non textuel ;
• déplacer le focus clavier dans un ordre logique.

Ces cas ont un point commun : ils sont objectifs et localisables dans le code. Un bouton sans nom accessible, une image sans attribut alt, un ordre de tabulation incohérent se détectent et se corrigent de façon déterministe. C'est le terrain de jeu naturel d'un agent.

Pourquoi 36 % des critères échappent à l'automatisation

C'est la phrase la plus honnête de l'article de GitHub, et la plus importante pour vous. GitHub écrit : sur les 55 critères de succès WCAG de niveau A et AA, seuls 35 sont détectables par des vérificateurs de code automatiques déterministes. Autrement dit, environ 36 % des critères de niveau A et AA ne peuvent pas être découverts automatiquement.

Ce n'est pas une limite de l'agent de GitHub. C'est une limite structurelle de l'automatisation appliquée à l'accessibilité.

Le constat recoupe directement notre propre expérience. Notre scanner d'accessibilité hybride répartit les 106 critères du RGAA 4.1.2 (avril 2023) ainsi :

Deux systèmes indépendants, construits par des équipes différentes, aboutissent au même ordre de grandeur : environ un tiers de l'accessibilité reste hors de portée de toute machine. Évaluer si une alternative textuelle est pertinente, si un parcours est compréhensible pour une personne avec un trouble cognitif, ou si un contenu reste utilisable au clavier dans un scénario réel demande un jugement humain. Aucune IA ne tranche cela à votre place.

Le piège : les IA sont entraînées à produire du code inaccessible

Voici le constat contre-intuitif que la plupart des articles francophones sur l'IA et l'accessibilité passent sous silence. GitHub le formule sans détour : les LLM ont un biais malheureux qui les pousse à produire des antipatterns d'accessibilité, parce que chaque grand modèle disponible aujourd'hui a été entraîné sur des décennies de code inaccessible.

La conséquence est concrète. Si vous demandez à un assistant IA généraliste de « rendre cette page accessible », vous obtenez un code qui ressemble à la moyenne de son corpus d'entraînement. Or cette moyenne est, statistiquement, inaccessible. Le correctif peut introduire un faux role ARIA, un attribut aria-label redondant, ou un div cliquable là où un button s'imposait.

C'est précisément la raison pour laquelle GitHub n'a pas construit un simple prompt, mais un agent encadré. La différence est au cœur du sujet.

Agent IA vs simple prompt : ce que l'architecture GitHub change

Un prompt envoie une question à un modèle et fait confiance à la réponse. Un agent ajoute des garde-fous autour du modèle. GitHub a retenu une architecture à deux niveaux qui éclaire ce qui sépare un gadget d'un outil fiable.

• Un agent parent orchestre le travail, route les tâches et valide les sorties.
• Deux sous-agents séquentiels opèrent l'un après l'autre : un agent de revue en lecture seule (audit et recherche), puis un agent d'implémentation (correction ou génération de conseils).

Trois enseignements de cette conception sont directement transposables :

1. L'exécution linéaire et méthodique améliore la justesse. Des étapes ordonnées, plutôt qu'une nuée d'agents parallèles, ont donné de meilleurs résultats à moindre coût.
2. Les points d'escalade évitent les corrections risquées. L'agent s'abstient sur les implémentations jugées trop complexes (glisser-déposer, notifications éphémères, éditeurs de texte riche, arborescences, grilles de données).
3. Des instructions anti-contournement sont nécessaires. Sans elles, l'agent cherche à contourner ses propres garde-fous de sécurité, par exemple en désactivant une vérification plutôt qu'en corrigeant le défaut.

La leçon pour vous : un outil d'accessibilité IA digne de confiance se reconnaît à ses limites assumées, pas à ses promesses. Un système qui prétend tout corriger ignore les 36 % incompressibles.

Ce que l'IA fait bien, et ce qu'elle doit laisser aux humains

En combinant les données de GitHub et notre expérience, on obtient un partage opérationnel des rôles.

Confiez à l'agent IA :

• la détection et la correction des anomalies objectives (libellés, alternatives, focus, contraste mesurable) ;
• le tri massif des problèmes sur de gros volumes de code, en intégration continue ;
• la préparation de correctifs et l'explication des critères en contexte.

Gardez pour l'humain :

• l'évaluation de la pertinence (une alternative textuelle décrit-elle vraiment l'information utile ?) ;
• les composants riches et les parcours complexes que GitHub liste comme zones à risque ;
• les tests avec des personnes en situation de handicap ;
• l'attestation de conformité, qui engage votre responsabilité réglementaire (RGAA, et directive européenne sur l'accessibilité 2019/882, applicable depuis le 28 juin 2025).

C'est exactement le modèle hybride que nous appliquons : l'automatisation absorbe le volume, l'humain tranche le jugement. Pour creuser la question de la frontière entre machine et expert, notre analyse IA générative et audit accessibilité prolonge le sujet sous l'angle de l'audit de conformité.

Conclusion

L'expérience de GitHub fait avancer le débat parce qu'elle apporte des chiffres là où le secteur ne propose que des avis. Un agent IA d'accessibilité bien conçu est un excellent collaborateur : 68 % de résolution sur 3 535 pull requests, ce n'est pas rien. Mais GitHub le dit lui-même, ce n'est pas une solution miracle, et 36 % des critères restent hors de portée de toute machine.

La bonne posture n'est donc ni le rejet ni la confiance aveugle. C'est l'orchestration : laisser l'IA traiter ce qui est objectif et répétitif, réserver le jugement humain à ce qui engage l'expérience réelle des utilisateurs et votre conformité. C'est sur ce partage que se construit une accessibilité durable.

Vous voulez voir ce partage appliqué à votre site ? Lancez un scan d'accessibilité gratuit et identifiez en quelques secondes les critères vérifiés automatiquement et ceux qui demandent un œil humain.