La création ou la refonte d’un site web mobilise rarement un seul intervenant. Une collectivité peut confier la conception graphique à une agence, le développement à une société spécialisée, l’hébergement à un prestataire technique et la maintenance à un autre titulaire. Une destination touristique peut également utiliser un système d’information touristique, un moteur de réservation, une cartographie interactive et plusieurs widgets fournis par des éditeurs différents.
Cette organisation permet de mobiliser des expertises complémentaires. Elle crée cependant un risque important : chacun respecte son périmètre contractuel, mais personne ne garantit réellement l’accessibilité du service numérique dans son ensemble.
Pour sécuriser l’accessibilité d’un site géré par plusieurs prestataires, il faut désigner un pilote unique, formaliser la répartition des responsabilités, définir des critères d’acceptation vérifiables et organiser une recette portant sur les parcours complets. L’enjeu n’est pas seulement de contrôler chaque fournisseur séparément. Il faut surtout sécuriser les interfaces entre leurs différents périmètres.
Pourquoi la multiplication des prestataires fragilise l’accessibilité
L’accessibilité numérique repose sur une chaîne de production complète. Elle dépend du cadrage fonctionnel, de la conception graphique, du développement, de l’intégration, des contenus, des documents téléchargeables, des outils tiers et de la maintenance.
Une seule défaillance peut rendre un parcours inutilisable.
Une maquette peut prévoir des contrastes suffisants, mais être mal intégrée. Un composant peut fonctionner correctement dans la bibliothèque de l’agence, puis perdre son accessibilité lorsqu’il est intégré dans le CMS. Un formulaire techniquement conforme peut devenir incompréhensible après la modification de ses libellés par une équipe éditoriale. Un moteur de réservation peut enfin interrompre brutalement la navigation au clavier au moment où l’utilisateur souhaite finaliser son achat.
L’article 47 de la loi du 11 février 2005 précise que l’accessibilité concerne l’accès à tout type d’information numérique, quels que soient les contenus, les moyens d’accès et les modes de consultation. Son périmètre couvre notamment les sites internet, les intranets, les extranets, les applications mobiles et les progiciels.
La conformité ne se limite donc pas à la page d’accueil ou au socle technique du site. Elle doit être examinée à l’échelle du service rendu à l’utilisateur.
Le risque de dilution des responsabilités
Dans un environnement multi-prestataires, les problèmes d’accessibilité donnent souvent lieu à des renvois de responsabilité.
L’agence web considère que l’anomalie provient du CMS. L’éditeur du CMS estime que son outil a été mal configuré. L’intégrateur attribue le problème au composant livré par un tiers. Le fournisseur du composant explique que son contrat ne couvre pas son intégration dans le site.
Pendant ce temps, l’utilisateur reste bloqué.
Cette situation apparaît lorsque les contrats découpent précisément les prestations, sans organiser la responsabilité aux interfaces. Chaque prestataire peut alors démontrer qu’il a respecté son propre périmètre, alors que le service final reste inaccessible.
Une rupture d’accessibilité peut ainsi être définie comme une non-conformité introduite à la jonction entre deux périmètres techniques, éditoriaux ou contractuels. Elle apparaît fréquemment lorsqu’un composant développé par un prestataire est configuré, intégré ou alimenté par un autre intervenant.
Qui reste responsable de l’accessibilité du service numérique ?
Une collectivité ou un organisme de gestion de destination peut externaliser la conception et le développement de son site. Cette externalisation ne transfère pas automatiquement la responsabilité du pilotage global de l’accessibilité.
Pour les collectivités territoriales et leurs établissements publics, les services de communication au public en ligne doivent être accessibles aux personnes handicapées. La structure doit également évaluer la conformité de son service, publier une déclaration d’accessibilité et organiser sa démarche de mise en accessibilité.
Le donneur d’ordre doit donc être capable de démontrer qu’il a défini les exigences, organisé leur vérification, traité les anomalies et suivi les actions correctives.
Il ne doit pas nécessairement réaliser lui-même tous les contrôles. Il doit en revanche s’assurer qu’ils sont effectivement réalisés.
Désigner un pilote unique
La première mesure consiste à désigner un pilote de l’accessibilité disposant d’une vision transverse du service numérique.
Ce rôle peut être assuré par un référent accessibilité interne, un chef de projet numérique, une direction des systèmes d’information ou une assistance à maîtrise d’ouvrage indépendante. L’essentiel est que cette personne dispose d’une légitimité suffisante pour arbitrer les responsabilités et demander des corrections.
Sans pilote identifié, chaque prestataire optimise son propre lot. Aucun acteur ne vérifie réellement la cohérence du résultat final.
Le pilote doit notamment :
- centraliser les exigences d’accessibilité ;
- organiser les échanges entre les intervenants ;
- valider les méthodes de test ;
- suivre les anomalies ;
- arbitrer les cas situés entre plusieurs périmètres ;
- consolider les preuves de correction ;
- préparer les audits et la déclaration d’accessibilité.
Répartir les responsabilités avec une matrice RACI
La matrice RACI permet de préciser, pour chaque activité, qui réalise l’action, qui la valide, qui doit être consulté et qui doit être informé.
Dans un projet web, cette matrice peut couvrir la validation des maquettes, les tests des composants, la recette des parcours, la correction des anomalies et la publication des contenus.
| Activité | Donneur d’ordre | AMO ou référent | Designer | Développeur | Éditeur tiers | Équipe éditoriale |
| Définition des exigences | Responsable | Contributeur | Informé | Informé | Informé | Consulté |
| Validation des maquettes | Validateur | Contrôleur | Réalisateur | Consulté | Non concerné | Consulté |
| Tests des composants | Informé | Contrôleur | Consulté | Réalisateur | Réalisateur | Non concerné |
| Recette des parcours | Validateur | Pilote | Consulté | Correcteur | Correcteur | Contributeur |
| Publication des contenus | Responsable | Contrôleur | Non concerné | Non concerné | Non concerné | Réalisateur |
| Suivi des anomalies | Responsable | Pilote | Correcteur | Correcteur | Correcteur | Correcteur |
Cette matrice n’a pas vocation à produire une documentation administrative supplémentaire. Elle doit éviter qu’une anomalie reste sans propriétaire.
Sécuriser l’accessibilité dès le marché et les contrats
Une clause indiquant simplement que « le site devra être conforme au RGAA » est insuffisante.
Elle exprime une ambition, mais ne précise ni les responsabilités, ni les preuves attendues, ni les modalités de validation.
Le Référentiel général d’amélioration de l’accessibilité actuellement publié est le RGAA 4.1.2. Il comprend 106 critères de contrôle et une méthodologie technique destinée à réduire la marge d’interprétation lors de l’évaluation. Une version 5 est en cours de préparation, avec une publication annoncée pour la fin de l’année 2026. Les services officiels précisent que les travaux de mise en accessibilité ne doivent pas être suspendus dans l’attente de cette évolution.
Le cahier des charges doit donc indiquer clairement le référentiel applicable au projet et les modalités d’adaptation en cas d’évolution réglementaire.
Décrire les livrables attendus pour chaque prestataire
Les exigences doivent être adaptées à la nature de chaque prestation.
Pour une agence UX ou UI, les livrables peuvent comprendre des maquettes annotées, une documentation des contrastes, les états de focus, les comportements au clavier et les règles d’affichage en cas d’agrandissement du texte.
Pour un intégrateur ou un développeur, les exigences peuvent porter sur la structure HTML, la navigation au clavier, la gestion du focus, la restitution des messages d’erreur et la compatibilité avec les technologies d’assistance.
Pour un éditeur de logiciel ou de composant tiers, il est pertinent de demander une documentation d’accessibilité, la liste des limitations connues, les modalités de signalement et le calendrier de correction des anomalies.
Les équipes éditoriales doivent quant à elles disposer de modèles de pages, de règles de publication, de consignes relatives aux textes alternatifs et d’une procédure de création de documents accessibles.
L’objectif consiste à transformer une obligation abstraite en livrables concrets et contrôlables.
Définir des critères d’acceptation vérifiables
Un critère d’acceptation efficace doit être testable et associé à une preuve.
Il est préférable d’écrire :
Tous les éléments interactifs du composant sont accessibles au clavier, le focus reste visible et son ordre suit la logique de lecture.
plutôt que :
Le composant doit être accessible.
D’autres critères peuvent porter sur la présence d’un nom accessible pour chaque bouton, l’association des champs de formulaire avec leurs étiquettes ou la restitution des messages d’erreur par un lecteur d’écran.
Chaque critère doit préciser le livrable concerné, le responsable de sa mise en œuvre, la méthode de vérification et la condition de validation.
Lier l’accessibilité à la réception des prestations
Lorsque l’accessibilité n’est pas intégrée aux conditions de réception, elle devient facilement une demande secondaire, traitée après la mise en ligne.
Les contrats peuvent prévoir des réserves, une obligation de correction avant la réception définitive, des contre-tests ou un plan d’action daté. Ils peuvent aussi organiser la non-régression pendant la période de garantie et la maintenance.
L’objectif n’est pas de multiplier les sanctions. Une pénalité contractuelle ne rend pas un site accessible. Elle peut toutefois rappeler que l’accessibilité constitue une exigence de qualité au même titre que la sécurité, la performance ou la conformité fonctionnelle.
Créer un référentiel commun entre les intervenants
Plusieurs prestataires ne peuvent pas travailler efficacement s’ils utilisent des méthodes, des vocabulaires et des outils de suivi différents.
Le donneur d’ordre doit fournir un cadre commun comprenant la version du RGAA retenue, les règles propres au projet, les composants de référence et la procédure de remontée des anomalies.
Centraliser la documentation
Un dossier d’accessibilité partagé peut regrouper :
- les clauses contractuelles ;
- la matrice des responsabilités ;
- les spécifications fonctionnelles ;
- les règles du design system ;
- les critères d’acceptation ;
- les résultats de tests ;
- les anomalies et les preuves de correction ;
- les décisions d’arbitrage ;
- les éventuelles dérogations ;
- les comptes rendus de recette.
Cette documentation évite la perte d’information lors d’un changement de prestataire ou d’une évolution du projet.
Elle permet également de distinguer une correction déclarée d’une correction effectivement vérifiée.
Utiliser une grille commune pour les anomalies
Chaque anomalie devrait comporter un identifiant, la page ou le composant concerné, le critère RGAA associé, l’impact utilisateur, le prestataire chargé de la correction, l’échéance et le résultat du contre-test.
L’impact utilisateur est particulièrement important. Une description limitée à « critère 7.1 non conforme » sera difficile à comprendre pour un responsable métier. Une formulation telle que « le lecteur d’écran ne restitue pas l’ouverture de la fenêtre modale, ce qui empêche l’utilisateur de poursuivre son parcours » facilite la priorisation.
La méthodologie officielle de test du RGAA documente les étapes permettant de vérifier la conformité des critères. Elle doit être utilisée avec le référentiel technique et ne remplace pas une formation suffisante des personnes réalisant les contrôles.
Organiser une recette d’accessibilité transverse
Tester chaque prestataire séparément ne suffit pas.
Un composant peut être accessible dans son environnement de démonstration, puis perdre cette qualité après son intégration. Une feuille de styles peut supprimer l’indicateur de focus. Un script global peut modifier l’ordre de navigation. Un paramétrage du CMS peut générer des titres ou des attributs incorrects.
La recette doit donc porter sur les composants, les gabarits, les pages représentatives et les parcours complets.
Tester les parcours de bout en bout
Pour une collectivité, les parcours prioritaires peuvent être la recherche d’une démarche administrative, la création d’un compte, la prise de rendez-vous, l’envoi d’un formulaire ou le téléchargement d’un document.
Pour une destination touristique, il peut s’agir de rechercher une activité, filtrer les offres, consulter une fiche, vérifier les informations d’accessibilité, réserver une prestation ou utiliser une carte interactive.
Ces parcours traversent souvent plusieurs solutions. Ils révèlent donc les défauts que les tests réalisés lot par lot ne peuvent pas identifier.
Le passage d’un site institutionnel à une billetterie externe peut, par exemple, provoquer une rupture de contexte. L’utilisateur perd ses repères, le focus revient au début de la page ou les intitulés des boutons deviennent ambigus.
Combiner automatisation et tests manuels
Les outils automatisés sont utiles pour détecter certaines erreurs : absence d’alternative, contraste insuffisant, structure incorrecte ou attribut non valide.
Ils ne permettent cependant pas d’évaluer la pertinence d’un texte alternatif, la logique d’un ordre de tabulation, la clarté d’un message ou la compréhension réelle d’un parcours.
Une recette robuste associe donc des tests automatisés, des contrôles manuels et, lorsque le contexte le permet, des tests avec des utilisateurs en situation de handicap.
Contrôler le projet à plusieurs jalons
L’audit final ne doit pas constituer le premier contrôle d’accessibilité.
Une organisation plus efficace prévoit des vérifications lors de la validation des maquettes, de la conception du design system, de la livraison des premiers gabarits, de la recette avant mise en production et du contrôle après déploiement.
Une anomalie corrigée dans une maquette coûte généralement moins cher qu’une refonte complète du composant déjà développé et déployé.
Comment gérer les composants fournis par des tiers ?
Les collectivités et les destinations touristiques dépendent souvent de solutions externes : moteur de recherche, cartographie, réservation, paiement, lecteur vidéo, gestionnaire de consentement ou base d’informations touristiques.
Ces outils doivent être identifiés dès la phase de cadrage.
Avant de retenir une solution, le donneur d’ordre peut demander au fournisseur sa documentation d’accessibilité, ses résultats d’audit, ses limitations connues et ses engagements de correction. Il doit aussi vérifier les possibilités de navigation au clavier, de personnalisation et d’intégration.
Un outil tiers ne doit pas être considéré automatiquement comme extérieur au périmètre d’accessibilité. Lorsqu’il participe à un parcours essentiel, son défaut peut empêcher l’accès au service dans son ensemble.
La charge disproportionnée peut être invoquée dans certaines conditions tenant notamment à la taille, aux ressources et à la nature de l’organisme. Elle doit cependant faire l’objet d’une appréciation documentée. Elle ne constitue pas une dispense générale applicable à tous les outils externes.
Lorsque le fournisseur ne peut pas corriger rapidement son service, l’organisation doit étudier une alternative accessible, proposer un moyen de contact ou une procédure équivalente et documenter sa trajectoire corrective.
Le contrat devrait également prévoir une stratégie de sortie. Sans clause de réversibilité, une structure peut rester durablement dépendante d’un outil inaccessible qu’elle ne peut ni corriger ni remplacer facilement.
Maintenir l’accessibilité après la mise en ligne
Un site accessible lors de sa mise en production peut perdre progressivement sa conformité.
Les mises à jour du CMS, les nouveaux composants, les changements d’éditeurs et les publications quotidiennes peuvent introduire des régressions.
L’accessibilité doit donc être intégrée à la maintenance corrective et évolutive. Chaque évolution devrait suivre un cycle comprenant une spécification, une conception, un développement, un test, une validation et une mise à jour de la documentation.
Les équipes peuvent suivre quelques indicateurs simples : nombre d’anomalies ouvertes, délai moyen de correction, taux de réussite des contre-tests, nombre de régressions et proportion de composants documentés.
La déclaration d’accessibilité doit rendre compte de l’état réel de conformité du service. Le cadre officiel distingue la conformité totale, la conformité partielle lorsque 50 % au moins des critères applicables sont respectés, et la non-conformité lorsqu’aucun audit valide n’est disponible ou que moins de 50 % des critères sont respectés.
Cette déclaration ne doit pas être traitée comme une simple page juridique. Elle doit refléter une démarche réelle de suivi et d’amélioration.
Une méthode en sept étapes pour coordonner plusieurs prestataires
La sécurisation de l’accessibilité peut être organisée autour de sept étapes.
1. Cartographier les acteurs et les dépendances
Il faut identifier les prestataires, les outils, les contrats, les flux de données et les responsabilités techniques. Cette cartographie permet de repérer les points de jonction les plus risqués.
2. Désigner un pilote unique
Une personne ou une équipe doit disposer d’une vision globale et d’un pouvoir d’arbitrage. Sans pilote, les décisions restent locales et les anomalies transverses ne sont pas traitées.
3. Formaliser les responsabilités
La matrice RACI doit préciser qui conçoit, développe, teste, corrige et valide. Elle doit également définir les responsabilités lorsqu’une anomalie concerne plusieurs intervenants.
4. Définir des critères d’acceptation
Les obligations générales doivent être traduites en exigences mesurables, associées à des preuves et intégrées aux conditions de réception.
5. Centraliser la documentation
Les règles, tests, anomalies, décisions et contre-tests doivent être regroupés dans un espace partagé. Cette traçabilité sécurise la continuité du projet.
6. Tester les parcours complets
La recette doit vérifier le fonctionnement réel du service, y compris les transitions entre le site principal, les outils métier et les solutions tierces.
7. Organiser la non-régression
Les procédures de maintenance, les contrats et les pratiques éditoriales doivent préserver l’accessibilité dans la durée.
Exemple : un site touristique reposant sur quatre prestataires
Une destination touristique exploite un site développé par une agence, une base de données alimentée par un système d’information touristique, une plateforme de réservation externe et un contrat de maintenance confié à une autre société.
Lors de la recette, le moteur de recherche semble fonctionner correctement. Pourtant, plusieurs filtres ne sont pas accessibles au clavier. Les informations relatives à l’accueil des personnes handicapées sont présentes dans la base de données, mais elles sont mal restituées dans les fiches. Le bouton de réservation possède un intitulé imprécis et le passage vers la plateforme externe entraîne une perte du focus.
Chaque intervenant considère avoir respecté son périmètre.
La destination décide alors de cartographier les responsabilités et de définir trois parcours prioritaires : rechercher une offre, consulter ses informations d’accessibilité et réserver.
Les anomalies sont centralisées dans une grille commune. Le fournisseur de la base corrige la structure des données, l’agence modifie leur restitution, la plateforme de réservation améliore ses composants et le mainteneur intègre les tests dans ses procédures.
Le principal enseignement n’est pas technique. Les anomalies existaient surtout parce qu’aucun acteur n’était chargé de vérifier le parcours dans son ensemble.
Les erreurs à éviter
La première erreur consiste à se contenter d’une mention générique du RGAA dans le cahier des charges. Sans livrables ni critères de validation, cette exigence reste difficile à faire appliquer.
La deuxième est d’attendre l’audit final. À ce stade, les composants sont déjà développés, les interfaces validées et les budgets consommés.
La troisième est d’exclure automatiquement les solutions tierces. Même lorsqu’une correction directe est impossible, le donneur d’ordre doit évaluer le risque, solliciter le fournisseur et rechercher une alternative.
Il faut également éviter de confondre correction déclarée et correction validée. Une anomalie ne devrait être fermée qu’après un contre-test.
Enfin, la recherche du responsable ne doit pas retarder la résolution. Lorsqu’un défaut concerne plusieurs prestataires, le pilote doit organiser une correction commune, puis traiter les conséquences contractuelles séparément.
Pour conclure : sécuriser les zones grises entre les prestataires
L’accessibilité d’un service numérique ne dépend pas uniquement de la compétence individuelle de chaque prestataire. Elle dépend de la capacité du donneur d’ordre à organiser leur coopération.
Un projet multi-prestataires doit disposer d’un pilote unique, de responsabilités formalisées, de critères d’acceptation mesurables, d’une documentation commune et d’une recette transverse.
L’objectif n’est pas de demander à chaque intervenant une promesse générale de conformité. Il faut construire une chaîne de preuves permettant de vérifier que les maquettes, les composants, les contenus et les parcours fonctionnent ensemble.
En matière d’accessibilité, les difficultés les plus importantes se trouvent rarement au centre des périmètres. Elles apparaissent dans les interfaces, les dépendances et les zones de responsabilité mal définies.
Une assistance à maîtrise d’ouvrage indépendante peut aider une collectivité ou une destination touristique à cartographier ces risques, encadrer les marchés, coordonner les recettes et vérifier les corrections sans dépendre des prestataires chargés de la production.
FAQ
Qui est responsable de l’accessibilité lorsqu’il existe plusieurs prestataires ?
Le donneur d’ordre conserve la responsabilité du pilotage global du service numérique. Chaque prestataire répond des livrables associés à son contrat, mais une personne ou une équipe doit contrôler la cohérence du résultat final. Une matrice de responsabilités permet de préciser qui réalise les tests, qui corrige les anomalies et qui valide leur résolution.
Une clause imposant le respect du RGAA est-elle suffisante ?
Non. Une clause générale ne précise pas les livrables, les méthodes de contrôle, les responsabilités de correction ou les conditions de réception. Elle doit être complétée par des critères d’acceptation testables, des preuves attendues et une procédure de contre-test.
Comment répartir les responsabilités entre une agence et un éditeur tiers ?
L’éditeur est normalement responsable de l’accessibilité intrinsèque de son composant. L’agence est responsable de son intégration, de sa configuration et des éventuelles modifications apportées. Le donneur d’ordre ou son AMO doit contrôler le parcours complet et arbitrer les anomalies situées à l’interface entre les deux solutions.
Faut-il auditer séparément chaque prestataire ?
Les livrables de chaque intervenant doivent être contrôlés, mais cette approche ne suffit pas. Certaines anomalies apparaissent uniquement après l’assemblage des composants. La recette doit donc également porter sur les pages représentatives et les parcours complets traversant plusieurs outils.
Comment gérer une solution tierce inaccessible ?
Il faut identifier les anomalies, demander leur correction au fournisseur, examiner les solutions de remplacement et proposer une alternative accessible lorsque cela est possible. Une éventuelle dérogation doit être justifiée et documentée. La présence d’un prestataire externe ne suffit pas à écarter automatiquement la responsabilité du service.
Quand faut-il réaliser les tests d’accessibilité ?
Les tests doivent être répartis pendant tout le projet : validation des maquettes, contrôle du design system, recette des premiers gabarits, vérification des parcours avant la mise en production et contrôle après le déploiement. Tester uniquement à la fin augmente les coûts et réduit les possibilités de correction.
Comment éviter les régressions après la mise en ligne ?
La maintenance doit intégrer des critères d’accessibilité, des tests automatiques, des vérifications manuelles et des contre-tests. Les composants validés doivent être documentés et les nouvelles fonctionnalités doivent suivre le même processus de contrôle que le projet initial.
Une AMO accessibilité est-elle indispensable ?
Elle n’est pas systématiquement nécessaire. Elle devient cependant utile lorsque les prestataires sont nombreux, que les outils tiers sont structurants ou que l’équipe interne ne dispose pas de compétences suffisantes. Son indépendance facilite le contrôle des livrables, l’arbitrage des responsabilités et la validation des corrections.
Sur le même sujet
- Recette continue : automatisation utile sans promettre l’impossible
Résumer le contenu avec l’IA :Une collectivité vient de mettre en ligne son nouveau site internet. Les principales non-conformités d’accessibilité relevées pendant la recette ont été corrigées. Les formulaires sont utilisables au clavier, les composants interactifs possèdent un nom accessible et les parcours prioritaires ont été vérifiés. Quelques mois plus tard, une mise à jour… Lire la suite : Recette continue : automatisation utile sans promettre l’impossible - Développement accessible : critères d’acceptation pour éviter les régressions
Résumer le contenu avec l’IA :L’accessibilité numérique ne se joue pas uniquement au moment de l’audit RGAA. Elle se construit, se teste et se maintient tout au long du projet web. Pour une collectivité ou une destination touristique, le vrai risque n’est pas seulement de découvrir des non-conformités en fin de projet. Le risque le… Lire la suite : Développement accessible : critères d’acceptation pour éviter les régressions - Design accessible : livrables attendus UI kit, composants, règles
Résumer le contenu avec l’IA :Concevoir l’accessibilité avant de corriger les erreurs Dans un projet web, l’accessibilité numérique est encore trop souvent traitée en fin de parcours. Une maquette est validée, les développements avancent, les contenus sont intégrés, puis l’audit RGAA révèle une série de non-conformités : contrastes insuffisants, focus invisible, formulaires difficiles à comprendre,… Lire la suite : Design accessible : livrables attendus UI kit, composants, règles - Plan d’actions RGAA : passer d’une liste de non-conformités à une roadmap pilotable
Résumer le contenu avec l’IA :Un audit RGAA produit souvent une liste dense de non-conformités. Utile pour comprendre les écarts, cette liste reste pourtant difficile à exploiter sans méthode de priorisation, sans responsabilités claires et sans calendrier réaliste. Pour une collectivité ou une destination touristique, l’enjeu n’est donc pas seulement de savoir ce qui n’est… Lire la suite : Plan d’actions RGAA : passer d’une liste de non-conformités à une roadmap pilotable