Exiger l’accessibilité dans un marché public
L'accessibilité numérique est une obligation légale pour les services publics. Dans un marché informatique, elle ne devient réelle que si le cahier des charges la rend vérifiable et si la recette la contrôle.
Un établissement public lance un marché pour refondre son site de démarches en ligne. Le cahier des charges mentionne que « le site devra respecter les normes d’accessibilité en vigueur ». Le prestataire retenu livre un site visuellement réussi, mais dont les formulaires sont inutilisables au clavier, les messages d’erreur invisibles pour un lecteur d’écran, et les contrastes insuffisants sur la moitié des pages. L’accessibilité figurait dans le contrat ; elle n’était ni spécifiée, ni pondérée dans le choix, ni contrôlée à la livraison. Exiger l’accessibilité dans un marché public, c’est l’écrire de façon à pouvoir la vérifier et la faire tenir.
Le cadre réglementaire en quelques lignes
L’article 47 de la loi du 11 février 2005 impose l’accessibilité des services de communication publique en ligne. Le décret du 24 juillet 2019 en fixe les modalités. Le Référentiel général d’amélioration de l’accessibilité (RGAA), dans sa version 4.1.2, transpose les critères de succès des WCAG 2.1 au niveau AA et constitue la référence technique pour les services publics français. Les WCAG 2.2, publiées en octobre 2023 par le W3C, ajoutent des critères utiles, notamment sur la taille des cibles et les modes d’authentification, et peuvent être citées en complément.
La directive européenne sur l’accessibilité du web (2016/2102) couvre les sites et applications mobiles des organismes du secteur public. L’Acte européen sur l’accessibilité (directive 2019/882), applicable depuis le 28 juin 2025, étend les exigences à certains produits et services du secteur privé, dont les services bancaires, le commerce en ligne et les terminaux en libre-service.
Inscrire l’accessibilité dans le cahier des charges
Trois emplacements du dossier de consultation portent l’accessibilité : les exigences techniques, les critères de choix et les conditions de recette.
Dans les exigences techniques
Citer le référentiel (RGAA 4.1.2, WCAG 2.2 niveau AA), la portée (tous les écrans destinés au public, y compris les formulaires, les documents téléchargeables et les contenus multimédias), et le périmètre des technologies d’assistance à couvrir (au minimum NVDA et JAWS sous Windows, VoiceOver sur macOS et iOS, TalkBack sur Android, navigation clavier seule). Préciser que les composants tiers intégrés (bibliothèques, lecteurs vidéo, captchas) doivent respecter les mêmes exigences.
Dans les critères de choix
L’accessibilité n’est pas un bonus ; c’est une exigence légale. La valoriser dans les critères de choix — avec une pondération suffisante pour qu’elle pèse dans le classement — est le moyen le plus direct de sélectionner un prestataire capable. Demander une démonstration sur cinq cas d’usage précis (formulaire, recherche, navigation, document, contenu multimédia) est plus fiable qu’une déclaration de conformité ou une liste de certifications.
Un candidat qui ne peut pas montrer un formulaire fonctionnant au clavier et au lecteur d’écran lors de la démonstration ne le fera pas mieux en production. La démonstration est le meilleur filtre.
Dans les conditions de recette
Prévoir un audit d’accessibilité avant la mise en service, réalisé par un auditeur indépendant du prestataire, sur un échantillon représentatif de pages. L’audit suit la grille du RGAA et produit un taux de conformité par critère. Fixer un seuil : par exemple, conformité totale sur les critères de niveau A, conformité à 90 % sur les critères de niveau AA, aucune non-conformité bloquante (empêchant la réalisation d’une démarche).
Les non-conformités relevées à la recette sont des défauts à corriger par le prestataire avant le prononcé de la réception, au même titre que les anomalies fonctionnelles. Le calendrier de correction et les conséquences d’un retard doivent être écrits dans le marché.
Pendant l’exécution du marché
- Exiger un plan d’accessibilité au démarrage Le prestataire décrit comment il intègre l’accessibilité dans son processus : outils de test automatique, revues de code, tests manuels avec technologies d’assistance, fréquence des contrôles.
- Contrôler à chaque livraison intermédiaire Vérifier l’accessibilité des écrans livrés, même en version préliminaire. Une non-conformité détectée tôt coûte dix fois moins à corriger qu’en fin de projet.
- Faire auditer par un tiers indépendant L’audit de recette final ne doit pas être une surprise. Un pré-audit à mi-parcours permet d’ajuster le tir.
- Documenter pour la maintenance Les règles d’accessibilité appliquées, les composants utilisés et leurs contraintes, les tests à refaire après chaque évolution. Sans cette documentation, l’accessibilité se dégrade au premier ajout de contenu.
Aller plus loin que le minimum
Le RGAA fixe un socle. Trois pratiques renforcent l’accessibilité réelle du service sans alourdir le marché.
Impliquer des utilisateurs en situation de handicap dans les tests d’acceptation. L’audit technique vérifie la conformité aux critères ; le test utilisateur vérifie que le service est réellement utilisable. Les deux sont complémentaires.
Exiger la rédaction en langage clair (niveau B1 du CECRL) pour les contenus destinés au public. L’accessibilité cognitive est un angle souvent oublié, et le langage clair bénéficie à tous les utilisateurs.
Prévoir la formation des contributeurs. Un site livré accessible se dégrade dès que des contenus sont ajoutés sans respecter les règles : images sans texte alternatif, tableaux mal structurés, documents PDF non balisés. La formation est un livrable du marché.
Notre offre Accessibilité et inclusion et notre expertise web accessible accompagnent les acheteurs publics à chaque étape, de la rédaction du cahier des charges à l’audit de recette. Pour une vue d’ensemble, voir notre dossier complet sur l’accessibilité numérique.
Questions fréquentes
Quel référentiel d'accessibilité citer dans un marché public français ?
Le Référentiel général d'amélioration de l'accessibilité (RGAA), dans sa version en vigueur (4.1.2 en mars 2026). Il transpose les WCAG et constitue l'exigence réglementaire pour les services publics en ligne. Citer aussi le niveau AA des WCAG 2.2 pour les interfaces non couvertes par le RGAA.
Peut-on éliminer un candidat qui ne démontre pas l'accessibilité ?
Oui, si les critères de choix et leur pondération le prévoient. L'accessibilité peut être un critère technique noté, avec un seuil éliminatoire si le cahier des charges le prévoit. Demander une démonstration sur des cas d'usage est plus fiable qu'une déclaration.
Qui réalise l'audit d'accessibilité à la recette ?
Un auditeur indépendant du prestataire, formé au RGAA. L'acheteur peut le désigner et le financer, ou exiger que le prestataire le fasse réaliser par un tiers. L'essentiel est que l'auditeur n'ait pas participé au développement.
Que faire si le prestataire livre un système non conforme ?
La non-conformité d'accessibilité est un défaut fonctionnel comme un autre. Si la clause de recette le prévoit, les corrections sont à la charge du prestataire, dans un délai fixé, avant le prononcé de la réception. C'est pourquoi la clause doit être écrite avant, pas découverte après.