Langue : Français English
Étude de cas

Audit indépendant d'un site transactionnel à fort trafic

Données réelles issues de notre projet de référence, au 10 juillet 2026. Le nom du client est volontairement omis dans ce document — un exemple concret est disponible sur demande, sous réserve d'accord de confidentialité.

Ampleur de l'audit

45 Défauts documentés sur le parcours principal — 11 critiques, 16 sérieux, 14 modérés, 4 mineurs — chacun avec sévérité, critère WCAG et RGAA, méthode de détection, statut de vérification, capture annotée et recommandation technique.
21 Défauts supplémentaires détectés sur un audit séparé de 174 pages en cascade (rubriques secondaires du pied de page), exécuté via orchestration multi-agents (187 agents).
162 Critères réglementaires (56 WCAG + 106 RGAA) évalués indépendamment, chacun avec verdict et protocole de test.

Couverture obtenue grâce à l'outillage développé

Critères tranchés avec preuve concrète, avant/après nos protocoles de preuve réelle
IndicateurAu premier passage (scan automatisé standard)Après protocoles de preuve réelle
Critères tranchés avec preuve concrète86 / 162 (53 %)140 / 162 (86 %)
Critères restant « non testé — manuel requis »7622, tous documentés avec protocole précis pour un futur testeur humain

Les 54 critères « débloqués » entre les deux colonnes l'ont été via : le pont NVDA (voix réelle capturée, citations exactes), le mode contraste forcé, la détection de focus visible par diff de style calculé, l'attente réelle de délai de session (30 min), le triage vision pour les icônes sans nom, et une dizaine d'autres méthodes DOM/CSS spécifiques cataloguées et réutilisables sur d'autres projets.

Défauts systémiques identifiés

L'analyse a mis en évidence des patterns provenant du design system du site (composants partagés sur toutes les pages Angular) — un seul correctif au niveau du composant résout plusieurs findings simultanément :

  • Boutons icônes sans nom accessible (mat-icon-button)
  • Barres de progression sans libellé (mat-progress-bar)
  • Panneaux d'accordéon sans nom accessible
  • Multiples balises H1 par page sur les applications monopage
  • aria-modal="true" employé à tort sur de simples boutons

Cette analyse change l'estimation d'effort de remédiation présentée au client : un correctif de composant peut résoudre des dizaines de défauts d'un coup plutôt que d'être traité page par page.

Ce que cette étude de cas démontre

On ne laisse pas une liste de cases à cocher manuellement

Chaque critère non automatisable a un protocole de test concret, pas juste une étiquette « à vérifier ».

On teste ce qu'un vrai utilisateur vit

Voix réelle d'un lecteur d'écran, attente réelle de délai de session — pas des heuristiques qui approximent le comportement.

On sépare rigueur et vitesse

Le triage assisté par IA (vision) accélère la détection mais n'est pas présenté comme un verdict final.

On documente les défauts systémiques

Pas juste des symptômes page par page — un correctif de composant peut résoudre des dizaines de défauts d'un coup.

Un site de cette envergure à faire auditer ?

Ce projet de référence est un site à très grande échelle, pas un site vitrine simple — parlons de votre périmètre.