La directive elle-même ne mentionne pas de délai fixe pour « rendre conforme » une boutique en ligne. En revanche, la date à partir de laquelle l'obligation s'applique est bien établie : depuis le 28 juin 2025, l'exigence est exécutoire pour les services qui en relèvent. La durée réelle du projet pour passer d'un site web actuel à un site conforme à EN 301 549 (en pratique WCAG 2.1 niveau AA) dépend de l'envergure du site, du nombre de défauts identifiés et de la rapidité avec laquelle une organisation peut agir en interne.
Dans la pratique, un projet se divise en quatre phases : inventaire, priorisation, correction technique et documentation. Une petite boutique en ligne avec un thème CMS standard et une étape de paiement limitée franchit généralement ces phases plus rapidement qu'une plateforme avec un environnement de connexion personnalisé, un processus de paiement sur mesure et plusieurs langues. Il n'existe pas de chiffre qui convienne à chaque organisation ; il existe cependant un schéma montrant où les projets accusent du retard.
Ce que la loi régit et ce qu'elle ne régit pas
Le règlement décrit quels services relèvent de la portée, quelle norme technique s'applique et quelles informations une déclaration d'accessibilité doit contenir. Un délai précis pour « d'abord analyser, puis corriger en X semaines » n'y figure pas. Les autorités de surveillance examinent l'état actuel d'un service et la question de savoir si une organisation travaille de manière vérifiable et structurée à la conformité, et non selon un délai d'exécution fixe qui serait identique pour tous. Pour les exigences précises par élément d'un site, il est recommandé de consulter le texte lui-même ; chaque sujet a été examiné pour déterminer exactement ce que les règles impliquent et où elles figurent dans le texte officiel.
Où les projets s'enlisent dans la pratique
Le premier retard ne survient souvent pas au niveau technique, mais au niveau de la vue d'ensemble : les entreprises ne savent pas quelles pages, formulaires et flux relèvent de la portée et lesquels n'en relèvent pas. Un deuxième obstacle concerne l'étape de paiement et l'environnement de connexion ; ce sont souvent des éléments personnalisés qui ne figurent pas dans un thème standard et ne bénéficient donc pas automatiquement d'une mise à jour du CMS. Un troisième obstacle est la dépendance à l'égard d'un fournisseur externe pour le CMS ou le module de paiement, auquel cas une modification peut attendre une nouvelle version de ce prestataire. Et un quatrième obstacle est interne : une liste de défauts en langage technique reste en suspens parce que personne ne sait qui est responsable de quelle règle.
Quatre phases et où elles achoppent
La phase d'inventaire consiste à déterminer ce qui ne fonctionne pas, sur quelles pages, et à quel point cela pose problème pour quelqu'un qui utilise un lecteur d'écran ou seulement un clavier. C'est la phase où une analyse automatisée fait le plus de travail, mais aussi la phase où il doit être clair qu'une telle analyse ne peut pas tout voir ; tous les critères WCAG ne peuvent pas être vérifiés automatiquement.
La phase de priorisation transforme les défauts en une hiérarchie : ce qui bloque une commande entièrement et ce qui constitue un léger inconvénient. Cela s'enlise souvent parce qu'une liste technique de défauts ne dit pas qui au sein de l'organisation est responsable de quel élément.
La phase de correction est celle qui prend le plus de temps, et sa durée dépend fortement de la question de savoir si les ajustements peuvent être effectués en interne ou doivent passer par un fournisseur. Les étiquettes de formulaire et le contraste des couleurs sont souvent faciles à résoudre ; une étape de paiement qui n'est pas techniquement utilisable au clavier seul demande plus de travail de développement.
La dernière phase est la documentation : établir la déclaration d'accessibilité, fixer un plan d'amélioration avec des délais, et prouver qu'une auto-évaluation a été effectuée. Ce n'est pas une phase à sauter une fois que la technique est correcte ; la déclaration doit refléter l'état actuel, même si cet état n'est pas encore parfait.
Ce qui influence réellement la durée du projet
Une organisation qui sait à l'avance quelles pages relèvent du champ d'application et quels problèmes ont le plus de poids perd moins de temps à faire des allers-retours entre la technique et la prise de décision. En quelques questions, il est possible de voir gratuitement où en est un sitesans qu'un compte soit nécessaire pour cela. Pour la suite, c'est-à-dire l'analyse complète de l'étape de paiement et du flux de connexion plus une liste d'actions hiérarchisées en langage courant, l'élaboration par obligation avec les délais correspondants fait partie du parcours payant; ce qu'il contient est clairement énuméré.
Un dernier facteur qui affecte la durée : l'accessibilité n'est pas un projet avec une date limite mais un état qui s'applique à nouveau après chaque modification du site. Une nouvelle étape de paiement ou un formulaire de contact renouvelé peut ramener un problème qui avait déjà été résolu. Celui qui veut savoir d'où provient l'information dans un rapport et à quelle fréquence elle est mise à jour la retrouvera sur la page qui explique comment fonctionne le processus.
Pour la situation propre, avec le CMS, le prestataire et la planification interne, il reste difficile de fixer à l'avance un délai ferme. Celui qui doute qu'un parcours soit réaliste à planifier ferait bien de d'abord clarifier précisément ce qui doit être fait avant de construire un calendrier autour. L'analyse rapide gratuite est un point de départ logique pour cela, sans qu'un compte ou un paiement soit immédiatement nécessaire.