Audit RGAA : les éléments à réunir avant de lancer l'analyse

Audit RGAA: les éléments à réunir avant de lancer l’analyse

C’est une séance de divination administrative, avec un rapport à la fin pour donner à l’illusion une reliure professionnelle.

La préparation d’un audit d’accessibilité RGAA ne consiste donc pas à envoyer l’URL de son site à un prestataire puis à attendre la liste des catastrophes. Il faut définir un échantillon représentatif, ouvrir les zones privatives, documenter les parcours complexes et réunir les personnes capables de corriger ce qui sera trouvé. Sans cela, l’analyse se concentre mécaniquement sur les pages faciles, tandis que les formulaires, espaces clients et tunnels d’achat restent dans l’ombre. Exactement là où la friction utilisateur aime s’installer.

Commencer par le bon périmètre, pas par la page la plus présentable

La première erreur de préparation consiste à confondre le site que l’on montre et le site que l’on exploite.

La page d’accueil est généralement la mieux entretenue. Elle a été relue, maquettée, validée par plusieurs comités et débarrassée des problèmes les plus visibles. Elle ne représente pourtant qu’une partie de l’expérience proposée. Un audit RGAA pertinent doit couvrir les différents types de contenus, les modèles de pages, les fonctionnalités et les parcours réels.

Le référentiel RGAA 4.1.2, publié par la DINUM et décliné des WCAG 2.1 niveau AA, comprend 106 critères répartis en 13 thématiques. Ce volume ne signifie pas qu’il faut livrer au prestataire une arborescence entière en vrac. Il faut au contraire construire un échantillon capable de représenter les usages et les composants du site.

La méthodologie officielle prévoit l’inclusion de plusieurs pages clés:

• la page d’accueil;
• la page de contact;
• les mentions légales;
• la page consacrée à l’accessibilité;
• le plan du site;
• la page d’aide;
• la page d’authentification;
• des exemples représentatifs de chaque service proposé;
• 10 % de pages tirées au hasard.

Cette liste n’est pas une suggestion décorative à placer dans un tableur pour rassurer la direction. Elle sert à éviter un biais classique: auditer abondamment les pages éditoriales et oublier les interfaces qui demandent une action, une décision ou une saisie. Or l’accessibilité se joue rarement dans le simple affichage d’un titre. Elle se joue dans la capacité à comprendre un formulaire, à parcourir un menu au clavier, à identifier une erreur, à modifier une information et à terminer un parcours sans assistance humaine.

Un échantillon d’audit ne doit pas représenter le site tel qu’il est vendu en comité. Il doit représenter le site tel qu’il est réellement utilisé.

Construire l’échantillon par familles de pages

Avant de sélectionner des URL, il faut dresser une cartographie fonctionnelle. Une page n’est pas intéressante uniquement parce qu’elle a une URL différente. Elle l’est parce qu’elle introduit un gabarit, un composant, une interaction ou une règle de contenu particulière.

Une fiche produit avec galerie d’images, filtres, variantes et ajout au panier ne relève pas du même cas d’usage qu’un article éditorial. Une page de résultats de recherche n’expose pas les mêmes risques qu’une page de connexion. Une interface de prise de rendez-vous, un espace de suivi de dossier et un formulaire en plusieurs étapes ajoutent chacun leurs propres zones de friction.

Pour préparer la sélection, regroupez les pages selon plusieurs axes:

• Le gabarit visuel: page éditoriale, fiche détaillée, tableau de données, page de service, page d’erreur, tableau de bord.
• Le niveau d’interaction: consultation simple, recherche, filtrage, sélection, téléchargement, saisie, validation.
• Le statut de l’utilisateur: visiteur anonyme, utilisateur authentifié, administrateur ou opérateur métier.
• La criticité du parcours: contact, achat, demande d’information, dépôt de document, inscription, renouvellement.
• La variété des composants: accordéon, fenêtre modale, carrousel, menu complexe, calendrier, autocomplétion, tableau triable.
• La diversité des contenus: texte, image, vidéo, document téléchargeable, graphique, carte interactive.

Cette étape révèle souvent un problème que le futur audit ne fera que confirmer: l’équipe ne sait pas précisément combien de versions d’un même parcours cohabitent sur le site. Ancienne page conservée pour des raisons historiques, tunnel mobile différent du tunnel desktop, espace client construit par une autre équipe, formulaire fourni par un tiers. La transformation numérique adore les couches sédimentaires. L’audit, lui, les déterre.

Le hasard ne remplace pas la représentativité

Les 10 % de pages tirées au hasard ont une fonction utile, mais ils ne peuvent pas constituer à eux seuls l’échantillon. Une sélection uniquement aléatoire risque de privilégier des pages peu complexes et de laisser de côté les interfaces essentielles.

Il faut donc distinguer deux logiques:

1. Les pages imposées par la méthodologie, qui garantissent la présence des zones structurantes du site.

2. Les pages représentatives, choisies pour couvrir les services, les gabarits et les fonctionnalités.

3. Les pages aléatoires, qui introduisent une part de contrôle moins prévisible et empêchent de préparer uniquement les écrans les plus propres.

Le bon échantillon n’est pas le plus volumineux. C’est celui qui permet de comprendre comment le système fonctionne dans ses différents états. Une page d’accueil impeccable ne compense pas un formulaire inaccessible. Un site éditorial bien structuré ne compense pas un espace client impossible à parcourir au clavier. Il faut auditer l’expérience, pas la vitrine.

Réunir les accès techniques avant que l’auditeur ne les réclame

La deuxième grande famille de documents pour un audit d’accessibilité concerne les accès. Et c’est généralement à ce moment que le projet découvre que personne ne sait qui possède les identifiants, que le compte de démonstration a expiré et que le parcours le plus important dépend d’un code envoyé sur le téléphone d’un ancien collaborateur.

Pour les zones privatives et les parcours complexes, la préparation doit inclure des comptes de test fonctionnels. L’auditeur doit pouvoir accéder aux espaces concernés sans contourner les règles de sécurité ni utiliser les données d’un utilisateur réel.

Préparez au minimum:

• un compte de test pour chaque niveau d’accès pertinent;
• des identifiants valides et vérifiés avant le démarrage;
• les éventuels codes nécessaires à l’authentification;
• un jeu de données permettant d’afficher les différents états de l’interface;
• les informations nécessaires pour atteindre les parcours complexes;
• les conditions particulières liées à une session, une expiration ou une validation manuelle;
• un contact disponible en cas de blocage d’accès pendant l’analyse.

Le compte ne doit pas être vide. Un espace client sans historique, sans document, sans notification et sans état particulier ne permet pas d’observer l’interface dans ses conditions normales. Il faut prévoir des données de test suffisamment représentatives: une demande en cours, un formulaire avec erreur, un document téléchargeable, une notification, un état vide, un état de confirmation.

Cela ne signifie pas qu’il faut simuler tous les cas imaginables. Il faut fournir les états qui structurent le parcours. L’accessibilité d’un écran de confirmation ne se vérifie pas de la même manière que celle d’un écran d’erreur. Et un composant qui fonctionne sur un état vide peut devenir incompréhensible dès qu’il contient plusieurs lignes, des statuts ou des actions secondaires.

Le parcours doit être décrit, pas seulement l’URL

Envoyer l’adresse d’un tunnel d’achat ne suffit pas. L’auditeur doit savoir ce qu’il est censé observer et comment atteindre chaque étape.

Une description utile indique:

• le point de départ du parcours;
• l’action attendue à chaque étape;
• les conditions pour afficher certains écrans;
• les données à saisir;
• les erreurs que l’on peut provoquer;
• les étapes de confirmation;
• le résultat attendu à la fin;
• les éventuelles redirections vers un outil tiers.

Ce document n’a pas besoin de devenir un manuel de 80 pages. Quelques informations précises valent mieux qu’une documentation exhaustive que personne ne lit. Le sujet est de permettre une analyse reproductible et de repérer les endroits où l’interface change de comportement.

Un tunnel de formulaire, par exemple, ne doit pas être transmis comme une succession d’écrans statiques. Il faut signaler les champs obligatoires, les règles de validation, les messages d’erreur, la conservation ou non des données saisies et les conditions de passage à l’étape suivante. La charge cognitive ne se mesure pas uniquement à la longueur d’une page. Elle apparaît aussi quand l’utilisateur ne sait pas pourquoi il est bloqué.

Gérer les environnements sans créer une seconde fiction

L’audit peut être réalisé sur un environnement de production, de préproduction ou de recette, selon le contexte du projet. Ce choix doit être clarifié avant l’analyse, car les différences entre environnements peuvent modifier les résultats.

Une fonctionnalité absente de la recette, un composant non mis à jour ou une configuration différente des messages d’erreur peuvent produire un rapport impossible à exploiter. L’équipe se retrouve alors à débattre de la validité du constat au lieu de corriger le problème. Une manière très coûteuse de découvrir que personne n’avait défini la version à auditer.

Réunissez donc:

• l’URL exacte de l’environnement concerné;
• la version ou la date de mise à disposition;
• les éventuelles restrictions réseau;
• les consignes de sécurité applicables;
• les outils tiers intégrés au parcours;
• les différences connues entre la recette et la production;
• le nom de la personne qui peut débloquer un accès.

Si le site évolue pendant l’audit, signalez-le. Un correctif déployé en plein milieu de l’analyse peut rendre certaines observations difficiles à reproduire. Cela ne veut pas dire qu’il faut figer éternellement le produit sous cloche. Cela veut dire qu’il faut savoir ce qui a été évalué.

Mettre les bonnes personnes autour de la table

Un audit RGAA n’est pas un exercice réservé au développeur front-end qui recevra le rapport dans sa boîte mail. Les non-conformités peuvent venir du contenu, du design, du code, de l’architecture de l’information ou de la gouvernance du produit.

La préparation doit donc identifier les rôles qui pourront répondre aux questions et prendre en charge les corrections:

• le Product Owner ou responsable produit, pour arbitrer le périmètre et les priorités;
• les designers UX/UI, pour analyser les parcours, les composants et les choix d’interaction;
• les développeurs front-end, pour traiter la structure HTML, le clavier, les états et les comportements;
• les responsables éditoriaux, pour corriger les alternatives textuelles, les titres, les liens et la hiérarchie des contenus;
• les équipes métier, pour valider les règles fonctionnelles et les données affichées;
• les responsables techniques ou de production, pour organiser les déploiements et les accès.

Cette clarification des rôles évite le grand classique du rapport d’audit transmis à une équipe qui ne possède ni le design, ni le contenu, ni le code concernés. Tout le monde est alors officiellement informé. Personne n’est réellement responsable. Le document prend de la valeur symbolique et perd toute utilité opérationnelle.

Préparer le travail de correction dès le début

La préparation d’un audit d’accessibilité RGAA doit déjà prendre en compte l’après-audit. Sinon, l’organisation se condamne à collectionner les constats.

Avant le lancement, définissez le circuit de traitement:

• où les résultats seront-ils centralisés?
• qui transforme les constats en tickets exploitables?
• comment les corrections seront-elles priorisées?
• qui valide la compréhension d’un critère lorsqu’il concerne plusieurs équipes?
• dans quel environnement les correctifs seront-ils vérifiés?
• comment éviter qu’un changement de composant réintroduise le problème ailleurs?

La réponse n’a pas besoin d’être sophistiquée. Un outil de suivi partagé peut suffire, à condition que le rapport ne reste pas un fichier isolé dans un dossier nommé « Audit RGAA final_v3 ». Le nom du fichier ne rend pas le processus plus mature.

Il est également utile de transmettre au prestataire les éléments qui décrivent déjà le produit: design system, bibliothèque de composants, documentation UX, règles éditoriales, spécifications fonctionnelles et historique des incidents connus. Ces documents ne remplacent pas l’audit, mais ils permettent de comprendre si un problème est local ou systémique.

Un bouton sans nom accessible dans une page n’est pas le même sujet qu’un composant de bouton mal défini dans toute une bibliothèque. Dans le premier cas, une correction ponctuelle peut suffire. Dans le second, il faut agir sur le système de conception, les règles de développement et le contrôle qualité.

Le rapport indique où l’expérience casse. L’équipe projet doit encore savoir pourquoi elle casse, qui peut la réparer et comment empêcher la même panne de revenir sur trente pages.

Utiliser l’automatisation sans lui demander de penser

Le pré-audit automatisé a sa place dans la préparation. Il permet de repérer rapidement certaines erreurs techniques et de réduire le bruit avant l’analyse approfondie. Mais il ne valide pas la conformité RGAA, pas plus qu’un correcteur orthographique ne garantit la qualité d’un texte.

Les outils automatisés peuvent notamment aider à détecter:

• des alternatives textuelles absentes;
• des contrastes insuffisants;
• une structure de titres incohérente;
• des champs de formulaire mal associés;
• des liens sans intitulé exploitable;
• des erreurs basiques dans la structure du code;
• des attributs ou rôles utilisés de manière incorrecte.

Selon les éléments réunis dans la phase de recherche, un scan automatisé permet de détecter environ 30 % à 40 % des non-conformités techniques. La proportion est utile pour comprendre l’intérêt du pré-audit, mais elle dit aussi clairement ce qu’il ne couvre pas: la pertinence d’un contenu, la logique de navigation, la compréhension d’un intitulé, la cohérence d’un parcours ou la qualité d’un retour d’erreur.

Un outil peut signaler qu’une image n’a pas d’attribut pertinent. Il ne sait pas nécessairement si l’image apporte une information, si elle est décorative ou si son alternative décrit réellement ce que l’utilisateur doit comprendre. Il peut repérer un contraste insuffisant. Il ne peut pas décider si l’interface reste lisible lorsque plusieurs informations concurrentes apparaissent à l’écran.

Ce que le scan ne doit pas faire croire

Le danger du pré-audit automatisé n’est pas seulement son périmètre limité. C’est l’excès de confiance qu’il produit.

Un résultat affichant peu d’erreurs peut signifier que le site est techniquement propre sur les éléments détectables. Il ne signifie pas que l’expérience est accessible. Un résultat très chargé peut signaler des défauts réels, mais aussi des alertes nécessitant une interprétation humaine. Dans les deux cas, il faut lire les résultats comme un matériau de préparation, pas comme un certificat.

L’évaluation manuelle reste indispensable pour examiner la pertinence des contenus et de la navigation. Elle permet aussi de vérifier les comportements au clavier, les changements d’état, les messages d’erreur, les composants dynamiques et les parcours complets. Ce sont précisément les zones où l’interface cesse d’être une image et devient un système de décision.

Le bon usage du scan consiste à:

1. lancer une première détection sur un périmètre connu;

2. regrouper les alertes par composant ou par type de page;

3. éliminer les faux positifs après vérification;

4. repérer les problèmes récurrents;

5. transmettre ces résultats à l’auditeur comme information préparatoire;

6. conserver l’analyse manuelle comme étape de référence.

Le mauvais usage consiste à exporter un score, à le présenter en comité et à conclure que l’accessibilité est « presque réglée ». Le score est souvent le gadget préféré des organisations qui ne savent pas encore quelle décision prendre.

Maîtriser le RGAA 4.1.2 pour préparer des réponses exploitables

La préparation ne demande pas à toute l’équipe de mémoriser les 106 critères du RGAA 4.1.2. Elle demande de comprendre la structure du référentiel et de savoir quelles décisions de conception, de contenu et de développement peuvent être concernées.

Les 13 thématiques du référentiel couvrent des dimensions différentes de l’expérience. Certaines touchent directement la structure et le code. D’autres concernent les médias, les tableaux, les formulaires, la navigation, la consultation, la présentation ou les scripts. Cette organisation permet de ne pas réduire l’accessibilité à la question du contraste et de la taille des textes, deux sujets utiles mais très loin de couvrir le problème.

Pour préparer l’équipe, il est pertinent de relier chaque grande famille de critères aux personnes capables d’agir:

Cette correspondance n’est pas un formulaire à remplir pour satisfaire une procédure. Elle permet de préparer les échanges. Si l’auditeur constate qu’un message d’erreur n’est pas correctement restitué, la discussion ne doit pas commencer par une recherche de coupable. Il faut savoir quel composant produit le message, quelle équipe en définit le contenu et quelle règle métier détermine le blocage.

Les composants réutilisés méritent une attention particulière

Un défaut présent sur un composant partagé peut se propager à toute l’interface. C’est le cas des boutons, champs, menus, fenêtres modales, onglets, accordéons et messages de statut. Dans un tel contexte, le nombre de pages concernées compte moins que le niveau de réutilisation du composant.

Avant l’audit, fournissez si possible:

• la liste des composants du design system;
• les versions réellement utilisées dans le produit;
• les variantes disponibles;
• les états documentés;
• les exemples d’implémentation;
• les composants développés en dehors de la bibliothèque commune;
• les dépendances tierces qui modifient le comportement de l’interface.

Cette documentation aide à distinguer une anomalie isolée d’un défaut de conception systémique. Elle évite aussi de corriger uniquement l’écran audité alors que le même composant existe ailleurs, sous une forme à peine différente et tout aussi fragile.

Le design system ne doit pas être traité comme un catalogue de jolies vignettes. C’est une infrastructure comportementale. Si ses composants ne décrivent pas leur fonctionnement au clavier, leurs annonces, leurs états d’erreur et leurs règles d’utilisation, il ne s’agit pas encore d’un système très solide. Plutôt d’une collection de pièces détachées avec une identité visuelle.

La préparation d’un audit RGAA, en pratique

Pour ne pas transformer le lancement en échange interminable de fichiers manquants, rassemblez les éléments suivants dans un espace partagé et identifiable:

• le périmètre exact du site ou de l’application;
• l’URL de l’environnement audité;
• la liste des pages obligatoires;
• les pages représentatives de chaque service et gabarit;
• les pages tirées au hasard selon la méthodologie prévue;
• les parcours prioritaires, avec leurs étapes;
• les comptes de test et leurs accès fonctionnels;
• les données fictives nécessaires aux espaces authentifiés;
• la liste des outils tiers intégrés;
• la documentation du design system;
• les règles éditoriales et les composants de contenu;
• les résultats disponibles d’un scan automatisé;
• les noms et responsabilités des interlocuteurs;
• les contraintes de sécurité, de réseau ou de déploiement;
• les changements prévus pendant la période d’analyse.

Cette liste n’est pas un substitut à une organisation. Elle sert à empêcher les oublis les plus prévisibles. Le périmètre doit être validé par le produit, les accès par la technique, les parcours par le métier et les composants par le design et le front-end. Une seule personne peut coordonner l’ensemble, mais elle ne devrait pas être obligée d’inventer seule la réalité fonctionnelle du site.

La durée exacte de préparation varie fortement selon la taille du site, la complexité des parcours et la qualité des accès disponibles. Il serait donc absurde de promettre un délai universel. Un site éditorial simple et un portail avec authentification, dépôt de documents et services multiples ne demandent pas le même travail préparatoire. Le bon indicateur n’est pas le nombre de jours annoncé à l’avance, mais la capacité à démarrer l’analyse sans suspendre la moitié des parcours à cause d’un accès manquant.

Ce que cette préparation change réellement

Une préparation sérieuse ne rend pas le site conforme par magie. Elle ne transforme pas un mauvais formulaire en bonne interface et ne remplace pas le travail de correction. Elle fait quelque chose de plus concret: elle évite que l’audit produise une vision partielle, difficile à reproduire et presque impossible à convertir en plan d’action.

Le RGAA 4.1.2 fournit un cadre précis. Encore faut-il lui donner un terrain d’analyse cohérent. Les pages obligatoires garantissent une base commune. Les pages représentatives révèlent les modèles et les services. Les pages aléatoires empêchent de maquiller le périmètre. Les comptes de test ouvrent les zones qui comptent vraiment. Les équipes projet permettent enfin de relier chaque constat à une décision et à une correction.

La préparation audit accessibilité RGAA n’est donc pas une formalité située avant le travail sérieux. Elle en constitue la première partie. Un échantillon mal construit produit un résultat incomplet. Un accès défaillant masque les parcours critiques. Un scan pris pour une validation entretient une fausse tranquillité. Et une équipe non mobilisée transforme le rapport final en inventaire de problèmes sans propriétaire.

L’audit commence avant l’outil, avant la grille et avant le premier test manuel. Il commence au moment où l’entreprise accepte de regarder son interface entière — y compris ses écrans secondaires, ses erreurs, ses espaces privés et ses vieux composants — plutôt que de présenter uniquement la page dont elle est encore fière. C’est moins flatteur. C’est beaucoup plus utile.