AIDE À LA DÉCISION · ACCESSIBILITÉ NUMÉRIQUE
Diagnostic, audit ou refonte : quelle intervention choisir ?
Par Théodis Guyon · Publié le
Un diagnostic aide à repérer des difficultés. Un audit établit des résultats sur un périmètre défini. Les corrections modifient le site. Une refonte remplace tout ou partie du socle. Acheter l’une de ces interventions ne réalise pas automatiquement les autres.
Partir de votre situation
| Intervention | Résultat attendu | Ne suffit pas pour |
|---|---|---|
| Diagnostic | Premiers constats sur des usages ou pages ciblés | Établir un taux de conformité RGAA sans évaluation complète |
| Audit | Évaluation documentée des critères applicables sur un échantillon représentatif | Corriger le code ou engager l’éditeur sans mission prévue |
| Corrections | Modifications du code, des contenus ou des composants | Prouver que chaque défaut est résolu sans nouvelle vérification |
| Contrôle après correction | Résultats de vérification sur un périmètre explicite | Étendre les résultats à des pages ou fonctions nouvelles non examinées |
| Refonte | Nouveau socle ou nouveaux parcours, selon le besoin | Garantir l’accessibilité par le seul changement d’outil |
Diagnostic : comprendre avant de commander
Commencez par un diagnostic ciblé si vous devez objectiver une difficulté ou préciser le besoin. Si vous devez établir un taux de conformité, cadrez directement un audit.
Donnez les usages prioritaires : trouver une information, remplir une demande, réserver ou payer. Le prestataire doit nommer les pages vues, les tests réalisés et les limites. Une alerte automatique peut aider à chercher ; elle ne remplace pas les tests humains.
À demander : un constat reproductible, son effet pour l’utilisateur et la suite proposée. À prévoir ensuite : l’audit si vous avez besoin d’une évaluation du service.
Voir la forme d’un diagnostic ciblé · Comprendre les limites des outils automatiques
Audit : établir un état documenté
Préparez un audit si vous avez besoin de résultats exploitables pour votre déclaration et votre plan de correction. Faites valider l’échantillon et la méthode avant le démarrage.
L’auditeur examine les critères applicables, les parcours et leurs états avec les environnements de test prévus. Le rapport relie un résultat à un critère, une page et une preuve. La restitution doit permettre à l’équipe web de comprendre les problèmes et d’organiser les travaux.
À demander : périmètre, référentiel, version, grille de résultats et preuves. À prévoir ensuite : responsables des corrections et vérification de leur réalisation. La préparation de la déclaration et sa publication doivent être attribuées explicitement.
Préparer les pages et parcours · Lire le contenu d’un rapport d’audit
Corrections : agir sur les défauts identifiés
Si un audit exploitable existe déjà, réunissez l’éditeur, les contributeurs et le pilote du projet pour répartir les corrections. Vérifiez d’abord que le rapport correspond encore à la version du site.
Un problème de composant revient souvent sur plusieurs pages. Une correction du modèle peut donc résoudre plusieurs occurrences ; les contenus éditoriaux restent à traiter séparément. Les services embarqués d’un tiers demandent de clarifier qui peut intervenir et avec quel délai.
À demander : liste des travaux, propriétaire de chaque correction, exclusions et critères de vérification. À prévoir ensuite : tests de non-régression et contrôle après correction. Un simple statut « traité » dans un tableau ne prouve pas la résolution.
Contrôle après correction : vérifier ce qui a changé
Faites contrôler les corrections livrées, avec le rapport initial et une liste des changements. Si le site ou ses parcours ont beaucoup évolué, réexaminez le périmètre avec l’auditeur.
Le devis doit distinguer la vérification de constats précis et une nouvelle évaluation plus large. Une correction peut déplacer un défaut : par exemple, le message d’erreur devient visible mais reste mal annoncé par un lecteur d’écran.
À demander : défauts réexaminés, nouveaux résultats, réserves restantes et portée du contrôle. À prévoir ensuite : mise à jour des informations publiées selon les résultats valides et suivi des ajouts futurs.
Refonte : changer le socle quand le besoin le justifie
Avant une refonte, comparez les corrections possibles avec les besoins fonctionnels, éditoriaux et techniques du futur site. Demandez à l’éditeur ce qui peut être corrigé sur le socle actuel.
Un audit défavorable ne signifie pas automatiquement qu’il faut tout reconstruire. Une refonte peut se justifier par des besoins nouveaux, un outil impossible à maintenir ou des limites techniques documentées. Elle implique aussi migration des contenus, maintien des adresses utiles et recette des parcours.
À demander : faisabilité de la correction, besoins non couverts, coûts de migration et charges récurrentes. À prévoir dans la refonte : exigences d’accessibilité dès la conception, contrôle des composants, vérification des contenus et audit avant publication. Changer de CMS ne valide aucune de ces étapes.
Distinguer investissement et frais récurrents · Préparer le cahier des charges
Deux décisions possibles, selon le contexte
Exemple fictif, commune : le site reste utile et l’éditeur peut corriger son modèle. La commune cadre un audit, fait chiffrer les corrections et réserve un contrôle. Aucune refonte n’est décidée sur le seul résultat d’un scan.
Exemple fictif, boutique : un changement de solution de paiement est déjà prévu. L’équipe vérifie les exigences dès le choix du prestataire, teste le parcours complet en recette puis examine le service final. Un ancien audit n’est pas présenté comme la preuve de la nouvelle version.
Sources et prochaine étape
Cette distinction des missions s’appuie sur la méthode officielle d’évaluation RGAA et sur le guide DAJ d’intégration de l’accessibilité dans les marchés publics, consultés le 5 octobre 2026. Les intitulés commerciaux peuvent varier : faites décrire les travaux et livrables dans la proposition.