Recette RGAA : organiser une phase de tests sans mobiliser l’équipe technique

La phase de tests RGAA (ou recette RGAA) est souvent considérée comme une étape « réservée aux développeurs ». Dans les faits, une grande partie du travail peut être menée en amont, côté maîtrise d’ouvrage, communication, chefferie de projet ou référent accessibilité, sans ouvrir un IDE ni mobiliser l’équipe technique au quotidien. L’enjeu n’est pas de « faire un audit RGAA à la place d’un auditeur », mais de structurer une phase de tests utile, traçable et exploitable, pour gagner en efficacité et en crédibilité lorsque viendra le temps des corrections.

Pour une collectivité ou une destination touristique, cette approche permet de mieux prioriser les demandes au prestataire, de sécuriser les parcours critiques (démarches, formulaires, prise de rendez-vous, recherche d’informations), et d’aligner la déclaration d’accessibilité avec une évaluation réelle, conformément aux obligations de publication.

L’accessibilité, côté terrain : une scène très courante (et évitable)

Dans une communauté de communes, Amélie pilote le site institutionnel, un portail famille et quelques démarches. Elle a un prestataire, un budget, et un calendrier serré. On lui demande une déclaration d’accessibilité « rapidement », parce que le sujet remonte côté élus et que les usagers se plaignent de formulaires difficiles. Le prestataire répond qu’il faut « un audit », puis « un lot de corrections », puis « un contre-audit ». Amélie se retrouve face à une impression de tunnel, coûteux et technique, alors qu’elle cherche d’abord une méthode simple pour objectiver la situation et cadrer les priorités.

Même contexte côté destination touristique. Un office de tourisme souhaite améliorer son site : information pratique, accès aux activités, réservation, plan interactif, documents à télécharger. Les équipes savent que l’accessibilité est importante, mais elles n’ont ni développeur en interne, ni bande passante pour lancer un chantier technique lourd. La tentation est forte de repousser le sujet. Or, une phase de tests bien menée, sans mobiliser l’équipe technique en continu, permet déjà de franchir un cap : produire des constats clairs, priorisés, et actionnables.

Pourquoi dissocier phase de tests et corrections techniques

Il faut remettre un peu d’ordre dans les termes, car c’est là que naissent la plupart des blocages.

Une phase de tests sert à répondre à une question simple : « Qu’est-ce qui empêche aujourd’hui un usager d’accéder à l’information ou au service ? ». Elle produit des preuves : pages concernées, conditions de reproduction, impact utilisateur, et, idéalement, un lien explicite avec les critères et tests du RGAA.

Les corrections techniques, elles, répondent à une autre question : « Que doit-on modifier dans le code, le CMS, les composants ou les contenus pour supprimer ces blocages ? ». C’est un travail de réalisation (ou de paramétrage), qui peut être internalisé ou confié à un prestataire.

Dissocier les deux, c’est accepter une réalité organisationnelle : dans les collectivités et les OGD, la ressource technique est rarement disponible « en continu ». En revanche, il est possible d’organiser une phase de tests cadrée, portée par la MOA, qui préparera un sprint correctif réellement efficace.

Ce que dit réellement le RGAA sur les tests (et ce qu’il ne dit pas)

Le RGAA n’est pas une « checklist rapide ». C’est un référentiel assorti d’une méthodologie de test et de critères.

Point important : le RGAA encadre l’évaluation de la conformité, mais il n’impose pas que chaque test soit exécuté par un développeur interne. En revanche, il implique que la déclaration d’accessibilité reflète une évaluation effective, et qu’elle soit accessible facilement depuis le service.

Autrement dit, la bonne question n’est pas « qui clique sur les pages », mais « le dispositif de tests est-il sérieux, traçable et aligné avec la méthode ? ». Pour une collectivité ou une destination touristique, une phase de tests préparatoire est donc légitime, à condition d’être positionnée pour ce qu’elle est : un travail de cadrage et de diagnostic opérationnel, qui ne remplace pas un audit de conformité complet lorsqu’il est nécessaire.

Les prérequis indispensables avant de lancer les tests

Organiser une phase de tests sans mobiliser l’équipe technique ne signifie pas improviser. Le succès repose sur trois prérequis.

D’abord, définir le périmètre. Un test RGAA utile n’est pas « on prend dix pages au hasard ». Il doit coller à vos usages réels : démarches, formulaires, prise de rendez-vous, recherche, téléchargement de documents, consultation d’actualités, agenda, carte interactive, réservation, paiement, inscription à une newsletter, etc. Pour une destination touristique, il faut généralement inclure au moins un parcours « trouver une activité », « consulter les infos pratiques », « réserver » (si applicable) et « contacter ». Pour une collectivité, il faut au minimum un parcours « démarche / formulaire », « trouver une information administrative », « accéder à un service tiers » (si présent), et « contacter / signaler ».

Ensuite, clarifier l’objectif. Une phase de tests préparatoire sert à produire une liste priorisée d’anomalies et un plan d’actions court terme, pas à calculer un taux de conformité officiel. Ce cadrage évite les malentendus avec les prestataires et protège la démarche : vous cherchez la performance opérationnelle.

Enfin, prévoir la traçabilité. Dès le départ, décidez où vous consignez les résultats (tableau, outil de ticketing, document partagé), comment vous nommez les anomalies, et comment vous reliez vos constats à des pages, à des captures, et, lorsque c’est possible, à des critères RGAA.

Recette RGAA : une méthode pas à pas, sans dépendance technique quotidienne

Étape 1 : sélectionner un échantillon « intelligent » de pages et de parcours

L’échantillon doit refléter la réalité de votre service, pas l’arborescence. Si vous avez 2 000 pages, ce n’est pas un argument pour tester 200 pages. C’est un argument pour tester ce qui compte.

Une méthode simple consiste à construire un échantillon en trois couches.

La première couche correspond aux pages « porte d’entrée » : homepage, pages thématiques, rubriques fortement visitées (information pratique, démarches, événements, séjour, etc.).

La deuxième couche correspond aux pages « à enjeu » : formulaires, étapes de réservation, pages contact, pages avec widgets tiers, contenus multimédias, documents téléchargeables.

La troisième couche correspond aux pages « représentatives » : un modèle d’actualité, un modèle de fiche, un modèle de liste de résultats, un modèle de page éditoriale, un modèle de page avec carte.

Cette approche produit un échantillon réduit, mais puissant, parce qu’il couvre les gabarits et les parcours. Elle facilite aussi le dialogue avec le prestataire : vous ne discutez pas de pages isolées, vous discutez de modèles, donc de corrections mutualisables.

Étape 2 : exécuter des tests manuels orientés « usage » (le cœur de la démarche)

C’est ici que la phase de tests est la plus rentable, et pourtant la moins technique. L’objectif est de vérifier, comme le ferait un usager, si les parcours sont utilisables au clavier, compréhensibles, et robustes face aux contraintes les plus courantes.

Commencez par la navigation clavier. Sans entrer dans des considérations de code, vous pouvez déjà objectiver des points critiques : peut-on atteindre tous les éléments interactifs au clavier ? Le focus est-il visible ? Peut-on fermer une fenêtre modale sans souris ? Un carrousel ou une carte piège-t-il le focus ? Ces tests révèlent souvent des blocages majeurs, notamment sur les composants tiers.

Poursuivez avec la structure et la compréhension. Dans les collectivités comme dans le tourisme, l’accessibilité se joue aussi sur la qualité de l’information : titres explicites, hiérarchie logique, libellés de liens compréhensibles, formulaires guidants. Beaucoup de non-conformités « techniques » commencent par une faiblesse éditoriale : intitulés vagues, instructions implicites, messages d’erreur incomplets.

Enfin, testez les contenus critiques : images informatives (avec texte dans l’image), documents téléchargeables, vidéos, tableaux. Sans outil complexe, vous pouvez identifier ce qui est manifestement problématique : PDF non structurés, absence d’alternatives pour un schéma, vidéos sans sous-titres, tableaux illisibles sur mobile, etc.

À ce stade, vous ne prouvez pas une conformité. Vous identifiez des risques et des blocages. C’est précisément ce que vous devez faire avant de solliciter la technique.

Étape 3 : utiliser les outils automatiques comme « détecteurs », pas comme arbitres

Les outils automatiques sont utiles, mais ils ne « font pas le RGAA ». Ils doivent être utilisés comme assistants, pas comme arbitres.

Leur usage raisonnable consiste à repérer rapidement des erreurs fréquentes, confirmer un soupçon, et produire un élément de preuve complémentaire dans vos constats.

Le point clé est la posture : l’outil ne conclut pas, il alimente votre diagnostic.

Étape 4 : documenter chaque anomalie pour qu’elle soit exploitable par un prestataire

Une anomalie « non exploitable » coûte cher. Elle génère des allers-retours, elle irrite les équipes, et elle retarde les corrections. À l’inverse, une anomalie bien formulée accélère tout.

Chaque constat devrait tenir en quelques éléments stables : la page (URL) et, si nécessaire, l’emplacement dans la page, le scénario de reproduction, le résultat observé, l’impact utilisateur, le niveau de priorité, et, si possible, le lien avec un critère / test RGAA.

Étape 5 : transformer les résultats en plan d’action

Votre objectif n’est pas d’empiler des constats, mais de décider. Une fois les anomalies recensées, regroupez-les par logique de correction : gabarits, composants, contenus, documents, tiers.

Cette étape est particulièrement adaptée à une MOA, parce qu’elle ne requiert pas de coder, mais de structurer le backlog : ce qui doit être corrigé d’abord, ce qui peut attendre, ce qui nécessite un arbitrage (budget, prestataire, remplacement d’un module).

Les erreurs qui décrédibilisent une phase de tests et comment les éviter

La première erreur consiste à confondre « audit automatique » et « évaluation RGAA ». Les outils détectent des signaux, mais le RGAA repose sur des tests, dont une grande partie est manuelle.

La deuxième erreur est de tester trop large, trop vite. Lorsque l’échantillon explose, la qualité baisse, et la phase de tests devient un inventaire sans fin. Le résultat est souvent un renoncement ou un rapport inutilisable.

La troisième erreur est de produire des constats flous. « Le site n’est pas accessible » ne sert à rien. « Le bouton de validation du formulaire n’est pas atteignable au clavier, le focus disparaît après le champ X » sert immédiatement.

La quatrième erreur est de lancer des corrections sans priorisation. On corrige des détails visibles, alors que des blocages empêchent l’accès au service. La priorisation par impact utilisateur évite ce biais.

La cinquième erreur est d’oublier la traçabilité. Une phase de tests sans trace ne protège pas la collectivité ou la destination. Or, l’obligation porte aussi sur la capacité à présenter une démarche, une déclaration d’accessibilité, et des éléments associés accessibles depuis le service.

Exploiter les résultats sans mobiliser l’équipe technique : le bon « pack » de livrables

Pour une collectivité ou un OGD, la meilleure façon de capitaliser est de produire trois livrables simples.

Le premier est un diagnostic de parcours, rédigé en langage clair. Il décrit, pour chaque parcours critique, ce qui fonctionne et ce qui bloque, sans jargon. Il sert à expliquer la situation à la direction, aux élus, ou aux partenaires.

Le deuxième est un backlog priorisé, structuré par lots. C’est le document opérationnel destiné au prestataire : corrections mutualisables, quick wins, dépendances, et éléments à arbitrer.

Le troisième est une note de cadrage pour la déclaration d’accessibilité. Il ne s’agit pas de rédiger une déclaration « à la place » d’une évaluation. Il s’agit de préparer les éléments factuels qui permettront de publier une déclaration cohérente avec la réalité.

Cas d’usage : collectivités et destinations touristiques

Collectivité : sécuriser une démarche en ligne avant une refonte

Dans une collectivité, la phase de tests sert souvent à sécuriser l’existant avant une refonte, ou à cadrer un lot correctif. Concrètement, vous identifiez les blocages sur les formulaires, la navigation, et les contenus clés, puis vous transformez ces constats en exigences.

Dans ce contexte, la phase de tests devient aussi un outil politique : elle permet d’objectiver, avec des exemples simples, ce qui empêche certains citoyens d’accéder au service.

Destination touristique : améliorer l’expérience sans chantier technique permanent

Pour une destination, l’accessibilité est un enjeu d’accueil et de conversion. Si un visiteur ne peut pas comprendre une information pratique, remplir un formulaire, ou accéder à une page d’activité, vous perdez de la confiance et parfois une réservation.

Une phase de tests bien menée met rapidement en évidence des points très concrets : contrastes insuffisants sur des boutons de réservation, intitulés de liens trop génériques, carrousels difficiles au clavier, cartes interactives inexploitables sans souris, PDF d’information pratique non accessibles.

Articulation avec une démarche RGAA globale : la place exacte de cette recette

Cette recette ne remplace pas un audit de conformité, et elle n’a pas vocation à produire un taux de conformité officiel. Elle joue un rôle différent : elle prépare le terrain et améliore le pilotage.

En amont d’un audit, elle permet d’identifier les gabarits et parcours critiques.

En amont d’un sprint correctif, elle sert à prioriser et à cadrer les tickets, avec une qualité de preuve et une logique de lot.

En accompagnement d’une gouvernance continue, elle devient un rituel : tests trimestriels sur les parcours critiques, puis ajustements ciblés.

Conclusion : tester sans technique, un levier immédiat de maturité

Organiser une phase de tests RGAA sans mobiliser l’équipe technique, ce n’est pas « faire semblant de faire un audit ». C’est construire une méthode de pilotage : choisir un périmètre intelligent, tester par l’usage, documenter des preuves, prioriser, puis dialoguer efficacement avec le prestataire.

Pour une collectivité, c’est un moyen concret de sécuriser les démarches et d’objectiver la situation sans attendre un chantier complet. Pour une destination touristique, c’est une façon pragmatique d’améliorer l’accueil numérique et la conversion, même avec une équipe réduite.

La clé est de rester rigoureux sur la traçabilité et sur le positionnement de la démarche, afin que la déclaration d’accessibilité reste cohérente avec une évaluation effective et des actions planifiées.

FAQ

Peut-on tester l’accessibilité sans être développeur ?

Oui, dans une certaine mesure. Une phase de tests orientée usage (navigation clavier, compréhension des formulaires, lisibilité, cohérence des liens, accessibilité des contenus) peut être menée par des profils MOA, communication ou chefferie de projet. En revanche, cette phase ne remplace pas un audit de conformité complet : elle sert à identifier, prioriser et documenter des anomalies pour cadrer des corrections.

Quels critères RGAA sont les plus accessibles à une équipe non technique ?

Les tests liés aux parcours et aux contenus sont souvent les plus rentables : navigation au clavier et visibilité du focus, libellés de liens, clarté des champs de formulaire et des messages d’erreur, présence d’alternatives sur les contenus informatifs, cohérence de la structure éditoriale.

Les outils automatiques suffisent-ils pour évaluer la conformité RGAA ?

Non. Les outils automatiques détectent des signaux, mais une part importante des vérifications du RGAA est manuelle. Ils doivent être utilisés comme assistants, pas comme arbitres.

Cette phase de tests remplace-t-elle un audit RGAA ?

Non. Elle prépare et facilite l’audit, ou elle permet de cadrer un plan de correction.

Peut-on s’appuyer sur ces tests pour rédiger une déclaration d’accessibilité ?

Vous pouvez vous appuyer sur une phase de tests pour préparer des éléments factuels et cadrer un plan d’action, mais vous devez éviter d’affirmer une conformité non démontrée.

À quel moment mobiliser l’équipe technique ou le prestataire ?

Le bon moment est celui où vous avez un backlog priorisé, documenté et regroupé par lots (gabarits, composants, contenus, tiers). À ce stade, l’équipe technique intervient sur des corrections mutualisables, avec un effort concentré.

Combien de temps prévoir pour une phase de tests « pragmatique » ?

Pour un site de collectivité ou de destination, une phase initiale pragmatique peut se faire en quelques jours à deux semaines selon le périmètre, à condition de cibler des parcours et des gabarits.

Comment rendre cette phase utile dans la durée ?

En la transformant en rituel : tests réguliers sur les parcours critiques, puis mise à jour du backlog et des priorités. Cette logique alimente une démarche d’amélioration continue.