L’audit complet : une boucle, pas une passe

Un audit ultra11y ne s’arrête pas au premier rapport. Il enchaîne la lecture du code, la page affichée, le jugement de l’IA et sa contre-vérification, puis recommence après correction.

Chaque étape est détaillée dans la suite de cette page.

1. Audit : le moteur lit le code

npx ultra11y audit "src/**/*.{html,tsx}" --graph --standard rgaa --out audits --json

Le moteur applique ses 102 vérifications. --graph suit les imports entre fichiers : il repère par exemple un composant icône utilisé sans nom accessible dans un autre fichier. Le résultat, audits/audit-latest.json, classe chaque critère : C, NC, NA ou « à évaluer ».

Un composant Vue, Svelte ou Astro est lu comme un modèle source : ce qu’injectent les slots et les liaisons dynamiques est invisible. Ses constats sont marqués « provisoires ». Pour un résultat fiable, on audite le HTML produit (voir render --setup dans Commandes).

2. Rendu : scanner avant d’arbitrer

npx ultra11y scan http://localhost:3000 --runtime local --merge audits/audit-latest.json --out audits

scan ouvre la page dans un vrai navigateur, y lance axe-core et des sondes : focus visible, zoom à 200 %, espacement du texte, contenu au survol, affichage à 320 pixels. Il garde une copie de la page et de ses mesures, puis les fusionne dans l’audit.

Cette étape passe avant le jugement de l’IA. Aucune lecture du code ne dit si un contraste calculé est suffisant ou si la page tient au zoom. Sans scan, ces critères ne sont pas seulement ouverts : personne ne peut les trancher. Sur un essai documenté dans la skill, le scan d’une seule page a refermé près de la moitié des critères qui restaient à juger depuis le code seul.

Un audit RGAA porte normalement sur un échantillon de pages représentatif (accueil, contact, mentions légales, formulaires…). pages discover --crawl <url> --write le construit, sample check vérifie qu’il couvre les types de pages attendus, scan --sample le parcourt. Un rapport RGAA sans scan est signalé comme partiel.

3. Arbitrage : l’IA juge

npx ultra11y verify --manual --in audits/audit-latest.json --out audits

Cette commande écrit une liste de travail : une fiche par critère non tranché. Chaque fiche contient les preuves collectées par le moteur (toutes les alternatives d’images, les intitulés de liens et leur contexte, les étiquettes de champs, le plan des titres…) et le texte officiel du critère, avec ses tests et la méthodologie publiée par la DINUM.

L’agent IA rend un verdict pour chaque fiche :

• Conforme, en citant les éléments vérifiés ;
• Non conforme, en désignant l’élément fautif ;
• Non applicable, avec une justification ;
• Manuel, avec la raison pour laquelle il ne peut pas trancher.

npx ultra11y verify --apply audits/ADJUDICATE.todo.json --in audits/audit-latest.json --out audits

Les verdicts sont réintégrés en mode fermé : un verdict incomplet, une citation introuvable ou un « conforme » sur des preuves partielles sont refusés, et le critère reste « à évaluer ».

4. Contre-vérification : l’IA se fait contredire

npx ultra11y verify --report audits/rgaa-AAAA-MM-JJ.md --in audits/audit-latest.json

Cette seconde liste attaque dans tous les sens. Une non-conformité que la page réelle dément est retirée. Un « conforme » est rejugé avec une question inversée : la preuve établit-elle le critère, ou montre-t-elle seulement que l’élément existe ?

Un « non applicable » passe le même examen. Il compte comme un succès dans le taux de conformité : sans contre-vérification, il fermerait un critère que personne n’a regardé. Un NA est donc rejugé même quand le moteur n’a rien collecté pour ce critère. Seul échappe à l’examen le NA que le moteur prouve lui-même, quand aucun élément concerné n’existe dans le périmètre audité. Et les consignes données à l’IA ne lui proposent plus le NA là où il n’a pas de sens : l’ordre de lecture, l’ordre du focus, l’espacement du texte, l’affichage sur petit écran et l’orientation s’appliquent toujours à une page qui a du contenu.

5. Correction, puis ré-audit

npx ultra11y fix "src/**/*.html" --write --iterate

fix applique seulement des corrections sûres et mécaniques (un attribut lang manquant, par exemple). Sans --write, il montre ce qu’il ferait. Le reste (alternatives, intitulés, structure) se corrige à la main, par ordre de gravité : bloquant, majeur, mineur. Puis on relance l’audit.

La boucle s’arrête quand check et verify --apply passent, et que seuls restent des risques résiduels nommés.

Les garde-fous en résumé

Les livrables

• Le rapport RGAA daté (report --standard rgaa) : il s’ouvre sur le résumé (niveau atteint, ce qu’il faut corriger), suivi d’un sommaire qui mène à chaque partie : synthèse par thématique, non-conformités par priorité, grille par page, critères à évaluer ; puis une annexe technique avec les occurrences fichier et ligne. Il existe aussi en HTML imprimable (--html).
• La grille page par page (pages --standard rgaa) : une ligne par critère, une colonne par page, ou un dossier par page avec sa capture d’écran.
• Le backlog (prd) : les mêmes blocs que le rapport, présentés comme une liste de travaux avec l’effort estimé.
• Les tickets (tickets) : GitHub, GitLab ou Jira, un ticket par critère, par page ou par fichier. Toujours essayer d’abord avec --dry-run.

Chaque non-conformité y est décrite par le même bloc d’auditeur : thématique, critère et intitulé officiel, test, constat, état attendu, méthode de vérification, occurrences. Le rapport, le backlog et les tickets ne peuvent donc pas se contredire.

Dernière étape : la revue du changement

Une fois les corrections faites, la skill ultra11y confie le diff à review-a11y, dans un sous-agent. Un sous-agent part d’un contexte vierge : la revue n’est pas influencée par l’audit qui vient de tourner, de la même façon que verify rejuge les verdicts au lieu de leur faire confiance.