Il n'existe pas de délai fixe pour un plan d'amélioration. La directive exige que vous identifiez et corrigiez les défauts, mais ne fixe aucun nombre de semaines ou de mois dans lequel cela doit se faire. La durée dépend en pratique de trois facteurs : le nombre de défauts détectés, qui les résout et comment cette personne ou ce bureau intègre cela dans les travaux en cours.
Ce qui est établi, c'est l'ordre des étapes. Vous identifiez d'abord les défauts, puis vous les priorisez, puis vous les corrigez, et ensuite vous documentez ce qui a été fait et ce qui reste à faire. Chaque étape a son propre rythme, et ce sont précisément les transitions entre ces étapes qui ralentissent les processus en pratique.
La phase d'identification se fait généralement rapidement
Un audit des pages essentielles et des principaux flux — étape de commande, flux de connexion, formulaire de contact — prend généralement quelques jours, pas des semaines. Les tests automatisés détectent une part substantielle des défauts courants : textes alternatifs manquants, champs de formulaire sans étiquette, contraste insuffisant. Une partie des exigences ne peut pas être testée automatiquement et cela est indiqué dans chaque rapport ; ces défauts nécessitent un examen par quelqu'un qui parcourt réellement la page. Si vous souhaitez d'abord savoir si cela est pertinent pour votre organisation avant de consacrer du temps à un audit, un court questionnaire avec indication directe peut vous aider.
La priorisation prend du temps, non parce qu'elle est difficile, mais parce qu'elle exige des décisions
Une liste d'actions comportant dix à trente points peut sembler gérable, mais chaque point exige une décision : qui s'en charge, quand, et quelle est son urgence par rapport aux autres travaux. C'est la phase où de nombreux processus ralentissent — non pas en raison de la technique, mais parce que personne en interne n'est responsable de la liste. Une liste d'actions en langage courant, sans jargon WCAG, aide ici : un responsable de bureau ou un responsable RH n'a pas besoin de savoir ce qu'est une étiquette ARIA pour comprendre que le formulaire de contact pose un problème. Ce qui ralentit souvent la priorisation, ce n'est pas le contenu mais l'absence d'une date limite claire pour chaque point — c'est précisément à cela que sert un plan d'amélioration assorti de délais.
L'exécution dépend du développeur, pas de la directive
Les corrections réelles — modification du code, rédaction de textes alternatifs, amélioration du contraste — ne relèvent pas de ce qu'un service de test effectue. Axessia effectue les tests, établit les priorités, documente et assure le suivi, mais n'effectue pas de travail de correction. La durée de cette phase dépend donc de la capacité de votre propre développeur ou de l'agence qui gère votre site, et de la manière dont ces corrections s'inscrivent dans un sprint ou un planning. Pour une boutique en ligne avec un thème simple, cela peut prendre quelques semaines ; pour du développement sur mesure avec une étape de commande complexe, cela peut s'étendre sur plusieurs mois, notamment si les corrections affectent le processus de paiement ou le flux de connexion et exigent donc des cycles de test supplémentaires.
C'est aussi le piège d'un widget de superposition : il promet une solution rapide en un jour, mais ne répond pas à l'exigence sous-jacente et ne change rien au code sous-jacent. Celui qui gagne du temps avec une superposition perd ce temps plus tard lorsqu'il s'avère que les défauts persistent.
La documentation et la déclaration constituent l'étape la plus courte, à condition que le reste soit correct
Une fois les défauts corrigés, la rédaction de la déclaration elle-même est relativement rapide — il s'agit essentiellement de documenter correctement votre propre évaluation. Cette étape ne rencontre des difficultés que si les étapes précédentes n'ont pas été correctement documentées : sans une évaluation vérifiable, il n'y a rien sur lequel fonder la déclaration. Plus d'informations sur ce qui est nécessaire se trouvent dans la base de connaissances par sujet.
Et ensuite : chaque modification rouvre le cycle
Le plus grand malentendu concernant le délai de mise en œuvre est que le processus s'arrête à la publication de la déclaration d'accessibilité. Une nouvelle page, un processus de commande modifié ou une autre mise à jour de thème peuvent introduire de nouveaux obstacles, ce qui relance le cycle d'évaluation, de priorisation et de correction. Cela fait de la question « combien de temps cela prend-il » une question sur un processus récurrent plutôt que sur un projet unique.
Voulez-vous connaître la situation actuelle de votre organisation et les mesures concrètes à disposition ? Effectuez l'analyse rapide gratuite ou découvrez comment les informations du rapport sont élaborées et ce qu'un abonnement y ajoute via l'aperçu des tarifs.