Rapport d’audit RGAA : lire les constats et les preuves

Mis à jour le 1er octobre 2026 · Rédaction : Plein Accès

Distinguer le résultat de l’explication

Un rapport d’audit RGAA doit permettre de comprendre l’état du service observé et de reproduire les défauts. La synthèse peut présenter le résultat global, mais l’équipe a aussi besoin du détail par critère et par page. Un score isolé ne dit ni où agir ni ce qui a réellement été testé. Avant de commander, demandez la trame du rapport et les formats livrés. Le cahier des charges aide à inscrire ces attentes dans la consultation.

Commencez la lecture par le périmètre : adresses, états, version du service et environnements. Vérifiez ensuite les exclusions et les limitations d’accès. Ces éléments donnent sa portée à l’évaluation. Une page non atteinte ne peut pas être assimilée à une page sans défaut. Le rapport doit expliquer les écarts entre la sélection prévue et la sélection examinée. Gardez cette information avec les résultats plutôt que dans un échange séparé difficile à retrouver.

Lire les résultats critère par critère

La grille doit distinguer les critères conformes, non conformes et non applicables. La justification d’un résultat non applicable est utile lorsqu’elle dépend d’une exemption ou d’une caractéristique du service. Demandez que les observations puissent être rattachées à la page et au test concernés. Un même défaut peut toucher plusieurs pages par un composant partagé ; cette relation doit être visible sans multiplier inutilement les tâches de correction.

Le calcul du résultat doit rester explicite et conforme à la méthode retenue. Un taux issu d’un scan n’est pas interchangeable avec un pourcentage de critères RGAA respectés. Si le prestataire présente aussi des indicateurs de criticité, demandez leur définition. La criticité peut aider à décider l’ordre du travail, mais elle ne change pas à elle seule le statut d’un critère. Les tests officiels liés à cette page permettent de vérifier le rattachement technique des observations.

Un exemple fictif de constat exploitable

Exemple pédagogique, sans référence à un client : dans un formulaire de demande fictif, la validation d’une adresse absente affiche un message visuel sans association avec le champ. Le constat indique l’écran de recette, les données initiales et les étapes : ouvrir le formulaire, laisser le champ vide et activer la validation. Il décrit ensuite ce que le lecteur d’écran restitue dans l’environnement testé, puis ce que l’utilisateur doit pouvoir comprendre pour corriger sa saisie.

La recommandation peut proposer de relier le message au champ et de vérifier la restitution après modification. Le rapport doit nommer le critère et le test retenus par l’auditeur, avec leur justification. Cet exemple ne prétend pas valider une mise en œuvre particulière. La réception de la correction doit reprendre le scénario et vérifier les autres champs qui utilisent le même composant. La capture éventuelle complète le texte ; elle ne doit pas être la seule preuve.

Transformer les preuves en tâches

Pour chaque anomalie, l’équipe doit pouvoir identifier l’élément à modifier et le résultat attendu. Un titre comme « formulaire inaccessible » reste trop large. Préférez une tâche qui décrit l’obstacle et les conditions permettant de vérifier sa disparition. Ajoutez la relation avec le composant partagé, les pages affectées et la responsabilité de correction. Le guide de remédiation décrit l’organisation du backlog et des dépendances.

L’équipe peut regrouper plusieurs observations lorsqu’elles proviennent d’une même cause, tout en conservant les liens vers les critères initiaux. Si l’origine du défaut n’est pas certaine, séparez l’investigation de la correction. Un rapport d’audit observe un résultat ; il ne donne pas toujours accès au code complet. La proposition de solution doit tenir compte de cette limite et rester discutable avec les développeurs.

Recevoir et conserver le dossier

La réception peut vérifier quelques constats de bout en bout : reproduction, compréhension de l’obstacle et transformation en tâche. Contrôlez également la concordance de la liste des pages avec l’échantillon validé. Une restitution accessible facilite le travail de tous les intervenants ; demandez un format structuré et des explications textuelles pour les médias. Le dossier doit rester disponible après la réunion, avec les fichiers nécessaires à une reprise future.

Conservez les résultats avec la date et la version du service. Ils seront utiles au contre-audit et à la rédaction d’une déclaration, dans la limite de leur validité et des changements intervenus. Les résultats ne doivent pas être réutilisés pour une autre version sans examen. Lorsque la direction demande un indicateur, accompagnez-le des limites de couverture et des décisions de correction encore ouvertes.

Questions sur le rapport

Une capture d’écran suffit-elle comme preuve ?

Elle peut montrer une partie du défaut. Ajoutez les étapes, l’état initial, l’environnement et une description textuelle de l’obstacle, surtout pour une interaction dynamique.

La priorité indique-t-elle si un critère est conforme ?

Non. La priorité organise le travail. Le statut du critère relève de l’évaluation selon la méthode ; un défaut moins prioritaire reste à traiter.

Peut-on importer le rapport dans un outil de suivi ?

Oui, si le format et les champs ont été convenus. Conservez les références aux critères et les preuves pour éviter de perdre l’explication derrière chaque tâche.

Sources vérifiées le 1er octobre 2026

DINUM : référentiel et obligations