Vibe coding : votre app générée par IA est-elle accessible ?

Vous avez généré une application en quelques prompts, ou vous héritez d'un projet « vibe-codé » par un client. Ça tourne, c'est joli, c'est allé vite. Mais est-ce utilisable par une personne aveugle, malvoyante ou qui navigue uniquement au clavier ? Cet article explique pourquoi le code généré par IA est presque toujours inaccessible, quels pièges reviennent systématiquement, et comment auditer votre app en moins d'une heure. Commençons par le terme lui-même.

Le vibe coding, c'est quoi exactement ?

Le terme « vibe coding » a été inventé le 2 février 2025 par Andrej Karpathy, cofondateur d'OpenAI et ancien responsable de l'IA chez Tesla, dans un message devenu célèbre sur X. Il décrivait un état où l'on « s'abandonne complètement aux vibes, embrasse les exponentielles, et oublie que le code existe même ». L'expression a été désignée mot de l'année 2025 par le Collins English Dictionary.

Concrètement, le vibe coding consiste à décrire ce que l'on veut en langage naturel et à laisser un modèle générer le code, souvent sans le relire. On accepte le résultat, on relance un prompt pour ajuster, on recommence. Les outils sont nombreux : Cursor, Lovable, v0, Bolt, Claude, GitHub Copilot.

Le problème tient dans la formule de Karpathy : « oublier que le code existe ». Car l'accessibilité, elle, vit précisément dans ce code. La sémantique HTML, les attributs ARIA, les alternatives textuelles, l'ordre de focus : rien de tout cela ne se voit à l'écran. Un bouton factice a exactement la même apparence qu'un vrai bouton. La différence n'existe que dans le code que le vibe coding invite justement à ignorer.

Pourquoi une app « vibe-codée » est presque toujours inaccessible

Deux mécanismes se combinent, et ils vont dans le même sens.

Les modèles sont entraînés sur un web inaccessible. Un LLM apprend en imitant des milliards de pages existantes, or la majorité du web ne respecte pas les standards d'accessibilité. Le modèle reproduit donc fidèlement les mauvais exemples qu'il a le plus vus. C'est un constat documenté : l'expérience de l'agent IA d'accessibilité de GitHub montre que les modèles sont biaisés vers la production d'anti-patterns d'accessibilité, parce qu'ils ont été nourris de décennies de code défectueux.

Le principe même du vibe coding supprime la relecture. Or l'accessibilité est invisible à l'œil nu. Vous ne verrez jamais, en regardant l'interface, qu'un bouton est un <div> déguisé, qu'une image n'a pas d'alternative ou qu'un champ n'a pas de label. Ces défauts ne se révèlent qu'à l'inspection du code ou au test avec une technologie d'assistance, deux étapes que le flux « génère et accepte » élimine.

Le résultat est une dette de qualité déjà mesurée. Une analyse de la plateforme Lovable (mai 2025) a relevé que 170 des 1 645 applications générées présentaient des vulnérabilités d'accès aux données personnelles. Une étude CodeRabbit (décembre 2025) rapporte 2,74 fois plus de vulnérabilités dans le code co-écrit par IA. Ces chiffres portent sur la sécurité, mais le mécanisme est le même pour l'accessibilité : du code accepté sans relecture accumule des défauts invisibles.

La différence, c'est que l'accessibilité est le point aveugle que personne ne mesure. Les guides « vibe coding » les plus lus listent bien des limites (dette technique, sécurité, scalabilité), mais aucun ne parle d'accessibilité. Le sujet est absent du discours, alors même que c'est une obligation légale et une question de qualité produit.

Les cinq pièges d'accessibilité récurrents du code généré par IA

Ces anomalies sont celles que notre scanner détecte le plus souvent sur du code généré au prompt. Chacune est rattachée à un critère du RGAA 4.1.2.

Un sixième piège mérite d'être cité : l'ARIA mal utilisé. Les modèles ajoutent parfois des rôles ou des attributs aria-* là où le HTML natif suffirait, ou pire, sur des éléments qui ne les supportent pas. Un mauvais ARIA est souvent pire que pas d'ARIA du tout, car il ment aux lecteurs d'écran.

Retenez le principe : une anomalie détectée n'est pas une non-conformité automatiquement établie, mais chacun de ces motifs exclut concrètement des utilisateurs si rien ne le corrige.

Comment auditer une application générée par IA

Vous pouvez faire un premier diagnostic sérieux en moins d'une heure, en quatre passes.

1. Scan automatique. Passez l'application au scanner RGAA. Il détecte les 8 critères entièrement automatisables, pré-vérifie 65 critères (anomalies structurelles à confirmer) et signale les 33 critères qui relèvent d'un audit humain. C'est votre carte des zones à risque.
2. Navigation au clavier seul. Débranchez la souris. Parcourez toute l'app avec la touche Tab. Chaque élément interactif est-il atteignable ? Le focus est-il visible en permanence ? Reste-t-on jamais piégé dans un composant ?
3. Test avec un lecteur d'écran. Écoutez ce que l'app raconte réellement. Si vous n'avez pas NVDA ou VoiceOver sous la main, notre simulateur de lecteur d'écran restitue dans le navigateur la façon dont une synthèse vocale parcourt la page.
4. Contrôle des contrastes. Vérifiez les couleurs de texte et d'interface générées par l'IA, qui privilégient souvent l'esthétique au seuil réglementaire.

Aucune de ces passes ne remplace un audit complet. Comme le rappelle notre travail sur la dette d'accessibilité, environ un tiers des critères RGAA ne peut être ni détecté ni corrigé par une machine. Le scan vous équipe, il ne rend pas le verdict à votre place.

Garde-fous : intégrer l'accessibilité dans un workflow vibe coding

Le vibe coding n'est pas condamné à produire de l'inaccessible. Il suffit de réintroduire, aux bons endroits, ce que le flux « génère et accepte » avait retiré.

• Prompter l'accessibilité explicitement. Ajoutez à vos instructions : « HTML sémantique, conforme WCAG 2.1 AA, boutons et liens natifs, labels associés, focus visible, contrastes suffisants. » Une consigne en amont change nettement la qualité du premier jet.
• Linter au commit. Un linter d'accessibilité attrape les fautes évidentes avant même qu'elles n'entrent dans le dépôt, directement dans l'éditeur.
• Scan bloquant en intégration continue. Branchez un scan d'accessibilité sur vos pull requests, avec export SARIF, pour qu'une régression bloque la fusion au lieu de partir en production.
• Connecter l'IA au référentiel. Via un serveur MCP, l'assistant peut interroger les critères RGAA pendant qu'il code, plutôt que de deviner.
• Garder l'humain dans la boucle. Une relecture ciblée et un test au lecteur d'écran avant chaque mise en production restent la seule garantie sur les critères que la machine ne sait pas juger.

Conclusion

Le vibe coding accélère la création d'applications. Il accélère aussi, silencieusement, la création de barrières pour les personnes en situation de handicap. La vitesse n'est un vrai gain que si le produit reste utilisable par tout le monde, et cela ne se joue pas dans l'interface, mais dans un code que la méthode invite à oublier.

La bonne nouvelle, c'est que le contrôle est rapide et outillé. Scannez gratuitement votre application pour cartographier les anomalies en quelques minutes, puis traitez ce qui reste manuel avec un audit guidé. Coder avec l'IA, oui. Exclure des utilisateurs sans le savoir, non.