Un client contacte régulièrement une agence en expliquant qu’il « doit être aux normes accessibilité » sans trop savoir de quoi il retourne juridiquement. Derrière cette phrase se cache un empilement de textes, français et européens, dont la portée et le calendrier diffèrent sensiblement. Pour un développeur WordPress, savoir distinguer ces obligations évite à la fois de sous-estimer un risque réel et de vendre une prestation d’audit disproportionnée à un client qui n’y est pas soumis.
Ce tour d’horizon reprend les textes fondateurs, leur périmètre exact, et la manière dont ils se traduisent concrètement dans un projet de développement de thème ou de plugin.
La loi du 11 février 2005, le texte fondateur
La loi n° 2005-102 du 11 février 2005 « pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées » pose, dans son article 47, le principe d’accessibilité des services de communication publique en ligne. Ce texte vise l’État, les collectivités territoriales, les établissements publics qui en dépendent, ainsi que les organismes délégataires d’une mission de service public. Une caisse d’allocations familiales, un hôpital public ou un office de tourisme communal entrent dans ce périmètre ; une entreprise privée classique, non.
Le décret d’application du 24 juillet 2019 a précisé ce cadre et introduit une nouveauté attendue depuis longtemps : une sanction financière, jusqu’à 25 000 euros par an et par service en ligne non conforme et sans déclaration d’accessibilité, prononcée par la direction interministérielle du numérique. Avant ce décret, l’obligation existait sur le papier mais restait sans conséquence pratique en cas de manquement.
Le RGAA, la traduction technique de la loi
La loi de 2005 fixe un principe, le RGAA (référentiel général d’amélioration de l’accessibilité) en donne la traduction opérationnelle : 106 critères de contrôle, une méthode de test par critère, et un mode de calcul du taux de conformité. C’est ce référentiel que doit respecter tout site entrant dans le périmètre légal, et c’est lui qui sert de base à la déclaration d’accessibilité que ces organismes doivent publier.
Ce qui change pour un développeur WordPress
Sur un projet institutionnel, cette obligation légale a des conséquences très concrètes dès le cahier des charges. Le choix du thème, par exemple, ne peut plus se faire uniquement sur des critères esthétiques : un thème premium séduisant mais bourré de <div> sans sémantique, ou dont le générateur de mise en page produit du HTML sans hiérarchie de titres cohérente, coûtera cher en corrections. De même, le choix des extensions de formulaire, de carrousel ou de galerie doit intégrer un critère d’accessibilité, et pas seulement de fonctionnalités.
Concrètement, un projet soumis à la loi de 2005 doit prévoir dans son planning : un audit RGAA (initial ou de suivi), la rédaction d’une déclaration d’accessibilité et d’un schéma pluriannuel, et un budget de correction dédié une fois l’audit rendu. Beaucoup de projets sous-estiment ce dernier point et découvrent après coup qu’un audit à 80 % de non-conformité implique plusieurs semaines de reprise du thème.
Et pour les organismes privés ?
Historiquement, le secteur privé n’était pas concerné par la loi de 2005. Cette frontière a commencé à bouger avec l’extension progressive du périmètre aux organismes délégataires d’une mission de service public (transports, énergie, certains organismes de sécurité sociale gérés par des structures privées), puis plus largement avec la directive européenne sur l’accessibilité des produits et services, qui vise notamment le commerce électronique. Un site e-commerce WordPress classique, aujourd’hui hors du champ de la loi de 2005, doit donc surveiller cette évolution plutôt que de la considérer comme définitivement hors sujet.
- Organismes toujours concernés : État, collectivités, établissements publics
- Organismes potentiellement concernés : délégataires de service public
- Organismes non concernés aujourd’hui, mais à surveiller : entreprises privées, notamment celles vendant en ligne
Construire un projet conforme dès le départ
La meilleure stratégie, sur un projet soumis à ces obligations, consiste à intégrer les exigences RGAA dès la maquette plutôt que de les traiter comme un audit final. Cela suppose de choisir un thème dont la structure HTML est propre, de valider les contrastes de couleurs de la charte graphique avant l’intégration, et de tester la navigation clavier à chaque étape de recette, pas seulement à la livraison.
Un audit d’accessibilité mené en fin de projet ressemble toujours à une facture salée. Le même audit mené à mi-parcours ressemble à une liste de corrections raisonnables. La différence tient presque uniquement au moment où on le déclenche.
Pour aller plus loin
Un développeur WordPress qui travaille régulièrement pour le secteur public a intérêt à se familiariser avec le RGAA lui-même plutôt qu’avec la seule loi qui l’impose : c’est ce référentiel technique, et non le texte juridique, qui guidera le travail quotidien. La loi fixe l’obligation et la sanction, le RGAA fixe la méthode ; connaître les deux permet de répondre sereinement à un cahier des charges public sans redécouvrir les règles à chaque projet.
