Refonte ou correctif : faut-il tout refaire mon site pour être conforme ?
En bref — refonte ou correctif ?
Non, dans la majorité des cas, vous n'avez pas à refaire votre site. La plupart des problèmes d'accessibilité sont des défauts de gabarit, de thème ou de composants réutilisés : on les corrige à la source et la correction se propage à des centaines de pages. Une refonte complète n'est justifiée que lorsque les barrières sont structurelles.
- La conformité s'apprécie critère par critère : on corrige des écarts précis, pas un « site » en bloc ;
- Le W3C recommande des réparations itératives priorisées par impact, pas une refonte big-bang ;
- Un site récent ou « beau » n'est pas conforme pour autant, et un site ancien se corrige souvent sans tout refaire ;
- Une refonte se justifie quand l'architecture elle-même empêche l'accessibilité (HTML non sémantique partout, dépendance à un overlay) — c'est l'exception, pas la règle.
Le détail ci-dessous, sources officielles à l'appui.
« On me dit que mon site n'est pas accessible — je dois donc tout refaire ? » C'est la première peur après un audit ou une réclamation, et c'est aussi celle qui coûte le plus cher quand on y cède trop vite. La bonne nouvelle : la mise en conformité est presque toujours une affaire de corrections ciblées, pas de reconstruction. Cette page explique pourquoi, comment prioriser à la manière du W3C, quels faux raccourcis éviter, et dans quels rares cas une refonte se justifie réellement.
La conformité se corrige, elle ne se « refait » pas
Le réflexe « tout refaire » vient d'une idée fausse : que l'accessibilité serait une propriété globale du site, qu'on aurait ou qu'on n'aurait pas. En réalité, la conformité WCAG s'apprécie critère par critère : un site échoue à tel critère sur tel élément. On ne corrige donc pas « le site », on corrige une liste finie d'écarts précis.
Et la plupart de ces écarts sont répétés, parce qu'un site e-commerce est fait de gabarits : une fiche produit, une page liste, un en-tête, un pied de page, un tunnel de commande, déclinés sur des milliers d'URL. Un contraste insuffisant dans le thème, un bouton sans libellé, un champ de formulaire sans étiquette : c'est un défaut de gabarit, corrigé une fois, qui disparaît partout. C'est exactement ce qui rend le correctif efficace là où la refonte serait disproportionnée.
La plupart des problèmes sont des défauts de gabarit, pas de pages
Quand un rapport liste « 820 erreurs », il ne s'agit presque jamais de 820 problèmes différents : c'est le plus souvent une poignée de causes répétées sur toutes les pages. Distinguer les causes des occurrences change radicalement l'ampleur du chantier.
- Une cause de gabarit = une correction : corriger le contraste d'un bouton dans le thème le corrige sur l'ensemble du catalogue ;
- Les écarts récurrents dominent : contrastes, libellés de formulaire, textes alternatifs, structure des titres — tous se traitent au niveau du modèle ou de la saisie de contenu ;
- Restent quelques cas isolés (une page spéciale, un composant unique) — par définition peu nombreux.
→ Trier un rapport touffu : j'ai reçu un audit, par où commencer.
Le W3C recommande des réparations priorisées, pas un big-bang
Le W3C consacre une ressource entière aux réparations intérimaires (Web Accessibility First Aid) : l'idée n'est pas de tout refaire d'un coup, mais de corriger d'abord ce qui a le plus d'impact, par vagues. C'est une démarche de chantier progressif, pas de table rase.
- Les corrections présentes sur plusieurs pages d'abord (donc les gabarits) : meilleur effet pour l'effort ;
- Les parcours critiques ensuite : recherche, fiche produit, panier, paiement — là où un blocage empêche d'acheter ;
- Le niveau A en priorité, puis le niveau AA, le reste au fil de l'eau.
→ Le plan complet : accessibilité numérique, par où commencer.
Un site récent ou « beau » n'est pas conforme pour autant
L'accessibilité ne se mesure pas à l'allure du design ni à l'âge du site. Les WCAG portent sur le code et le contenu, pas sur l'esthétique : un site flambant neuf peut échouer (couleurs tendance mais peu contrastées, animations non maîtrisées, composants « maison » non sémantiques), et un site plus ancien peut être mis en conformité sans changer de look.
- « Refaire pour faire moderne » ≠ rendre accessible : une refonte purement visuelle peut même introduire de nouveaux écarts ;
- Inversement, garder son site et corriger contrastes, libellés et navigation au clavier suffit le plus souvent ;
- L'accessibilité est transversale au design : on peut l'ajouter à un thème existant.
L'overlay n'est pas un « correctif » (et pas une alternative à la refonte)
Entre « tout refaire » et « corriger », un troisième chemin est vendu comme magique : le widget ou overlay d'accessibilité, une ligne de script censée « rendre le site conforme ». Le consensus des experts (et l'Overlay Fact Sheet, signé par plus de mille spécialistes) est clair : un overlay ne suffit pas à la conformité et ne remplace pas les corrections dans le code.
- Il ne corrige pas la cause : les défauts de gabarit restent dans le code sous-jacent ;
- Il peut créer de nouveaux problèmes (interférence avec les lecteurs d'écran) ;
- Il expose à un risque de fausse allégation si l'on affiche « site conforme » sans l'être.
→ Pourquoi : overlays accessiBe / UserWay, le risque juridique.
Quand une refonte se justifie vraiment
La refonte n'est pas toujours évitable. Elle devient le choix raisonnable — non pas une obligation légale, mais une bonne pratique d'ingénierie — lorsque les barrières sont structurelles et qu'un correctif reviendrait à colmater sans fin :
- Un site bâti en éléments non sémantiques (tout en
<div>cliquables, sans vraie structure HTML) — corriger chaque composant coûterait plus cher que reconstruire proprement ; - Un framework ou un constructeur qui empêche de produire du HTML accessible (pas de contrôle sur l'ordre du DOM, sur le focus, sur les rôles) ;
- Une dépendance lourde à un overlay qui masque des défauts profonds ;
- Un site en fin de vie déjà prévu pour être remplacé : autant intégrer l'accessibilité dans le projet en cours.
Corriger prend du temps — mais le délai ne s'arrête pas
Que vous choisissiez le correctif ou la refonte, un point ne change pas : pour le commerce électronique, l'obligation d'accessibilité est exigible depuis le 28 juin 2025, et il n'existe pas de « délai de grâce » pour se mettre en conformité après coup. Engager un chantier de corrections ne suspend pas l'obligation ; mais une démarche réelle et documentée est précisément ce qu'on attend.
- Déclarez l'état réel : ce qui est conforme, les non-conformités connues, l'échéancier de correction — c'est le sens de la déclaration d'accessibilité ;
- Avancez par priorités (étape 2) : traiter d'abord les blocages du tunnel d'achat réduit le risque le plus vite ;
- Ne sur-déclarez jamais : « en cours de correction, voici notre plan » protège mieux que « 100 % conforme » démenti au premier test.
→ Combien de temps ai-je : délai de mise en conformité accessibilité.
Correctif ou refonte, en un coup d'œil
| Situation | Approche raisonnable | Pourquoi |
|---|---|---|
| Contrastes, libellés, alt, titres | Correctif de gabarit / contenu | Une cause, corrigée partout |
| Tunnel d'achat bloquant au clavier | Correctif prioritaire | Parcours critique, fort impact |
| Composant unique non accessible | Correctif ciblé | Cas isolé, peu nombreux |
| Tout le site en <div> non sémantiques | Refonte (ou refactor profond) | Barrière structurelle |
| « Site neuf pour faire moderne » | Ne règle rien en soi | WCAG ≠ esthétique |
| Overlay « qui rend conforme » | Ni correctif ni refonte | Ne corrige pas le code |
Savoir si un correctif suffit (ce que DeclareAccess apporte)
Le bon choix entre correctif et refonte se prend sur preuve, pas sur intuition : il faut d'abord voir quels écarts vous avez, et s'ils sont de surface ou structurels. C'est exactement ce que nous produisons.
DeclareAccess analyse une page de votre site (moteur axe-core, calé sur WCAG 2.1 niveau AA — la cible EAA) sans rien installer, vous remet le rapport des manquements détectables et la liste des vérifications manuelles à mener, puis génère la déclaration d'accessibilité à publier (modèle français, allemand, italien ou espagnol). De quoi distinguer les corrections de gabarit (rapides) des vrais sujets de fond — et documenter une démarche honnête pendant que vous corrigez.
Voyez s'il faut corriger ou refaire — gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 niveau AA (la cible EAA via EN 301 549), vous envoie le rapport des manquements détectables et la liste des vérifications manuelles à mener, puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Dois-je vraiment refaire tout mon site pour être conforme ?
Non, dans la grande majorité des cas. La conformité WCAG s'apprécie critère par critère, et la plupart des écarts d'un site e-commerce sont des défauts de gabarit, de thème ou de composants réutilisés : on les corrige à la source et la correction se propage à toutes les pages. Le W3C recommande d'ailleurs une démarche de réparations progressives priorisées par impact, pas une refonte d'un seul bloc. Une refonte ne s'impose que lorsque l'architecture elle-même empêche l'accessibilité.
Mon rapport affiche des centaines d'erreurs — c'est forcément énorme ?
Pas nécessairement. Un nombre élevé d'« erreurs » correspond presque toujours à un petit nombre de causes répétées sur de nombreuses pages. Quelques dizaines d'occurrences d'un même contraste insuffisant ou d'un même bouton sans libellé, c'est une seule correction de gabarit. Comptez les causes, pas les occurrences : le chantier réel est souvent bien plus petit qu'il n'y paraît.
Si je refais mon site, serai-je automatiquement conforme ?
Non. Une refonte ne rend pas un site accessible par magie : si l'accessibilité (niveau AA, recette de conformité) n'est pas écrite dans le cahier des charges, vous pouvez payer un site neuf toujours non conforme. Les WCAG portent sur le code et le contenu, pas sur l'esthétique — un design moderne n'est pas une garantie. Une refonte n'a de sens pour l'accessibilité que si elle est explicitement pilotée par un objectif de conformité.
Un overlay ou un widget peut-il m'éviter le correctif ?
Non. Un overlay (accessiBe, UserWay…) n'est ni un correctif ni une alternative à la refonte : il ne corrige pas les défauts dans le code, peut interférer avec les lecteurs d'écran, et expose à un risque de fausse allégation si vous affichez « site conforme » sans l'être. La FTC a sanctionné l'éditeur accessiBe d'un million de dollars en avril 2025 pour des allégations trompeuses (droit américain, cité à titre d'illustration). La seule voie fiable reste de corriger le code.
Combien de temps ai-je pour corriger ?
Pour le commerce électronique, l'obligation est exigible depuis le 28 juin 2025 et il n'existe pas de délai de grâce pour se mettre en conformité après coup. Engager un chantier de corrections ne suspend pas l'obligation, mais une démarche réelle et documentée est attendue : déclarez l'état réel de votre site (ce qui est conforme, les non-conformités connues, l'échéancier de correction), avancez par priorités en traitant d'abord les blocages du tunnel d'achat, et ne sur-déclarez jamais une conformité que vous n'avez pas encore atteinte.