Le regard Quadran · Accessibilité numérique
Audit RGAA et IA : exigez des preuves, pas seulement un verdict
Une liste d’erreurs bien rédigée peut donner l’impression qu’un site a été audité. Pour faire confiance au résultat, il faut pourtant savoir ce qui a été observé, quelle procédure a été exécutée et ce qui reste à vérifier.
L’IA générative peut aider à analyser un contenu, expliquer un obstacle ou proposer une correction. Elle peut aussi produire une conclusion plausible sans disposer de toutes les informations nécessaires. Pour une équipe chargée de l’accessibilité, la question est donc précise : le verdict repose-t-il sur une vérification démontrable ?
Cette exigence vaut pour tous les outils, y compris appYaccess. Elle permet de distinguer la qualité de présentation d’un rapport de la solidité de son évaluation.
Le RGAA est une méthode de vérification
Le RGAA associe des critères, des tests, des conditions d’application et des cas particuliers. Sa méthodologie décrit les opérations nécessaires pour évaluer les exigences. Un contrôle ne consiste donc pas simplement à demander si une page « semble accessible ». [1]
Afficher un numéro de critère dans un rapport ne prouve pas que toutes les vérifications correspondantes ont été réalisées. C’est particulièrement important lorsqu’un résultat est ensuite transmis à un prestataire, utilisé pour accepter une correction ou repris dans la préparation d’une déclaration d’accessibilité.
Trois exemples qui montrent pourquoi la méthode compte
Les cas suivants sont des exemples pédagogiques. Ils ne sont pas issus d’un benchmark comparatif d’appYaccess et de solutions IA et ne constituent pas des réponses observées de modèles.
1. Un contraste proche du seuil : le calcul doit trancher
Considérons un texte normal de 16 pixels, gris #777777, sur un fond blanc #FFFFFF, sans transparence ni mécanisme alternatif.
Le rapport calculé est d’environ 4,478:1. Le minimum applicable est de 4,5:1 : cette combinaison ne satisfait pas l’exigence. Arrondir à une décimale ne permet pas de la rendre conforme ; le W3C le précise explicitement. [2]
Une appréciation visuelle ou une réponse approximative peut manquer cette différence. Un contrôle instrumenté doit identifier les couleurs effectives, calculer le rapport et appliquer le bon seuil. Une IA peut aussi parvenir au bon résultat si elle utilise correctement les données et les outils nécessaires. La preuve réside dans le calcul exécuté.
2. « En savoir plus » : le contexte peut changer le verdict
<p>
Consultez notre rapport annuel 2025.
<a href="/rapport-annuel-2025.pdf">En savoir plus</a>
</p>Signaler automatiquement ce lien comme non conforme au seul motif que son intitulé est générique serait insuffisant. Le test RGAA 6.1.1 permet de prendre en compte l’intitulé avec son contexte. Dans cet exemple, le paragraphe identifie la destination annoncée. [3]
L’évaluation doit examiner le contexte autorisé par la méthode. Une préférence éditoriale pour des liens plus descriptifs ne constitue pas, à elle seule, la preuve d’une non-conformité.
3. Un composant bien balisé peut encore nécessiter un test de restitution
Un menu peut présenter des attributs ARIA qui paraissent cohérents dans le code. Cela ne suffit pas à démontrer que ses états et ses interactions sont effectivement restitués comme attendu.
Le test RGAA 7.1.2 prévoit une vérification de restitution par les technologies d’assistance. Une capture d’écran ou la seule lecture d’un extrait HTML ne réalise pas cette manipulation. [3]
Une solution qui ne dispose pas de cette observation doit laisser la vérification à compléter. Qu’elle repose sur des règles ou sur une IA, elle ne doit pas transformer une absence de preuve en validation.
Trois qualités à ne pas confondre
| Qualité | Question à poser | Pourquoi elle compte |
|---|---|---|
| Justesse | Le verdict correspond-il au résultat attendu ? | Une erreur stable reste une erreur. |
| Reproductibilité | Le même contrôle donne-t-il le même verdict dans des conditions identiques ? | Un changement de résultat doit pouvoir être expliqué. |
| Couverture | Quelles vérifications ont réellement été réalisées ? | Une réponse sur chaque critère ne démontre pas leur évaluation complète. |
Pourquoi la stabilité des verdicts est importante
Après une correction, l’équipe doit pouvoir comprendre pourquoi un résultat change. Le site a-t-il évolué ? L’état du composant est-il différent ? La version du moteur a-t-elle changé ? Ou la variation vient-elle de l’évaluation elle-même ?
Une évaluation générative peut varier entre exécutions. Les mécanismes proposés pour stabiliser les sorties ne garantissent pas toujours leur identité : OpenAI documente cette limite dans son exemple de reproductibilité. [4]
Pour comparer des contrôles déterministes, il faut maîtriser les données d’entrée, l’état de la page, le scénario, l’environnement et la version des règles. La stabilité facilite alors la vérification des corrections et la détection des régressions. Elle ne dispense jamais de valider la justesse des règles.
Une couverture annoncée doit pouvoir se lire test par test
Un éditeur doit distinguer les contrôles entièrement automatisés, les vérifications partielles ou assistées et les points demandant une intervention humaine. Pour un critère composé de plusieurs tests, automatiser l’un d’eux ne signifie pas automatiser tout le critère.
Le format ACT du W3C distingue notamment réussite, échec, non-applicabilité, impossibilité de conclure et absence de test. Cette distinction aide à documenter l’avancement ; elle ne remplace pas les règles de conclusion propres au RGAA. [5]
Un outil fiable doit aussi savoir laisser une question ouverte. Une vérification restant à effectuer est une information utile. Une conformité présumée faute d’observation peut, au contraire, masquer un obstacle réel.
Ce que la recherche permet de dire sur l’IA
Une étude publiée dans Information and Software Technology en octobre 2026 a évalué sept modèles sur 384 cas issus de tests ACT, couvrant 39 critères WCAG selon le périmètre des auteurs. Elle documente des variations entre exécutions et des difficultés à déterminer l’applicabilité. Elle relève aussi l’intérêt des modèles pour certaines évaluations que les outils traditionnels comparés traitent moins bien. [6]
Ces résultats portent sur des extraits HTML et des configurations identifiées. Ils ne constituent ni un audit RGAA complet de sites réels, ni une comparaison avec appYaccess. Leur conclusion soutient une approche associant outils et validation humaine.
Il serait donc excessif d’affirmer que toute solution utilisant une IA est moins fiable. Une architecture peut combiner moteur de règles, mesures, navigation automatisée, assistance générative et expertise humaine. Ce qu’il faut examiner, c’est la chaîne de vérification.
Automatiser sans rendre l’IA générative obligatoire
Le choix d’un outil concerne aussi la politique numérique de l’organisation. Une collectivité peut vouloir encadrer l’IA générative pour des raisons de sobriété, de maîtrise des données ou de gouvernance.
La Ville et l’Eurométropole de Strasbourg demandent, dans leur charte, de démontrer le bénéfice d’un système d’IA par comparaison avec un système sans IA et d’évaluer son impact environnemental avant déploiement. Il s’agit d’un encadrement des usages, et non d’une interdiction générale. [7]
L’ADEME invite également à vérifier si un modèle génératif est nécessaire ou si une solution plus légère suffit. Elle recommande de permettre aux utilisateurs de refuser les fonctionnalités d’IA proposées par défaut. [8]
Pour un contrôle fondé sur une règle explicite, solliciter systématiquement un modèle génératif mérite donc d’être justifié. Automatiser un calcul, inspecter un attribut ou rejouer une procédure ne suppose pas nécessairement d’utiliser une IA générative.
Le fonctionnement sans IA ne démontre pas à lui seul un meilleur bilan environnemental global : une comparaison exige un périmètre et des mesures cohérents. En revanche, la possibilité d’effectuer les contrôles concernés sans appels à un modèle génératif est une caractéristique technique que l’éditeur doit pouvoir documenter.
L’approche appYaccess : des contrôles structurés, une IA optionnelle
appYaccess automatise une grande partie des vérifications d’accessibilité et structure les résultats pour accélérer le travail des équipes. Son approche s’appuie sur les critères, tests et méthodes du RGAA, avec des contrôles déterministes et l’identification des validations restant à effectuer.
Le bénéfice recherché est opérationnel : disposer de résultats exploitables par page et par critère, cibler les corrections, relancer les vérifications et suivre les régressions sur un périmètre maîtrisé. Les résultats structurés facilitent aussi la préparation de la déclaration d’accessibilité, après les validations nécessaires.
Les fonctions d’assistance par IA sont optionnelles. Leur désactivation ne transforme pas les appréciations humaines restantes en tests automatiques : elle permet de choisir comment les compléter, selon les compétences et les règles de l’organisation.
Cette approche ne signifie ni que tous les critères sont entièrement automatisés, ni qu’un résultat partiel constitue une évaluation complète de conformité. Le W3C rappelle que les outils assistent l’évaluation et que le jugement humain reste nécessaire pour certains aspects de l’accessibilité. [9]
Les six questions à poser avant de choisir un outil
- Quelle méthode est exécutée ? Demandez la correspondance avec les tests RGAA et la gestion des cas particuliers.
- Quelle est la couverture réelle ? Distinguez contrôle complet, partiel, assisté et humain, pour la version proposée.
- Quelles preuves accompagnent le verdict ? Élément concerné, observation, mesure ou manipulation, et justification de la conclusion.
- Comment les résultats sont-ils validés ? Demandez les jeux d’essai, les erreurs connues et la gestion des mises à jour.
- Peut-on rejouer le contrôle ? Vérifiez la maîtrise du périmètre, des scénarios, de l’environnement et des versions.
- Que fonctionne-t-il sans IA générative ? Demandez les fonctionnalités disponibles, les validations restantes et les éventuels transferts vers un fournisseur de modèles.
Un rapport utile doit permettre à vos équipes de vérifier une conclusion et d’agir. Exigez une méthode explicite, des preuves consultables et des limites clairement indiquées.
À découvrir également : les contrôles RGAA avec appYaccess et les cas d’usage en accessibilité.