Lorsqu’une collectivité confie la création ou la refonte de son site internet à un prestataire, la formule « le site devra être conforme au RGAA » semble, à première vue, suffisamment explicite.
Elle ne l’est pas.
Cette phrase fixe une intention, mais elle ne précise ni le périmètre concerné, ni les preuves attendues, ni les modalités de contrôle. Elle ne dit pas davantage ce qui se passe lorsque le site livré comporte des non-conformités ou lorsque son niveau d’accessibilité se dégrade après une mise à jour.
Pour sécuriser un projet, l’accessibilité doit être traduite en obligations contractuelles vérifiables. Le contrat doit relier chaque exigence à un livrable, chaque livrable à une procédure de validation et chaque manquement à une mesure corrective.
Une clause d’accessibilité efficace ne se contente donc pas d’invoquer le Référentiel général d’amélioration de l’accessibilité. Elle organise concrètement la conception, la recette, la correction et le maintien de la conformité.
Pourquoi une simple obligation de conformité RGAA ne suffit pas
Les services de communication au public en ligne des collectivités territoriales doivent être accessibles aux personnes en situation de handicap. La législation prévoit également la publication d’une mention de conformité, d’une déclaration d’accessibilité, d’un schéma pluriannuel et du plan d’action de l’année en cours.
En juillet 2026, la version de référence publiée est le RGAA 4.1.2. Une version 5 est annoncée pour la fin de l’année 2026. L’administration précise cependant que cette évolution future ne doit pas conduire à suspendre ou à reporter les travaux de mise en accessibilité déjà engagés.
Dans un contrat, écrire que « la prestation devra respecter le RGAA » laisse pourtant plusieurs questions sans réponse.
Le prestataire doit-il rendre conforme l’ensemble du site ou uniquement les pages qu’il produit ? Les documents PDF sont-ils inclus ? Les modules tiers sont-ils concernés ? À quel moment la conformité sera-t-elle mesurée ? Qui réalisera l’audit ? Les anomalies devront-elles toutes être corrigées avant la réception ? Combien de temps le prestataire restera-t-il responsable d’une régression ?
En l’absence de réponses précises, la collectivité risque de découvrir les désaccords au moment de la recette, lorsque les délais sont contraints et que la mise en ligne est déjà annoncée.
Le premier objectif du contrat consiste donc à transformer une obligation générale en exigences objectivement contrôlables.
Définir le périmètre avant de rédiger les clauses
Une clause ne peut être efficace que si son périmètre est clairement défini.
Le contrat doit commencer par identifier les services numériques concernés. Il peut s’agir du site institutionnel, d’un espace citoyen, d’un intranet, d’une application mobile, d’une plateforme de démarches, d’un système de prise de rendez-vous ou encore d’un ensemble de sites satellites.
Cette cartographie doit également intégrer les éléments associés au service principal : formulaires, vidéos, cartes interactives, documents téléchargeables, moteurs de recherche, composants de consentement, outils de paiement ou modules d’authentification.
Les dépendances externes doivent faire l’objet d’une attention particulière. Un site peut être développé dans le respect des règles d’accessibilité tout en intégrant un module tiers inutilisable au clavier ou mal interprété par un lecteur d’écran.
Le contrat doit alors distinguer trois catégories d’éléments :
- les composants conçus et développés par le titulaire ;
- les solutions tierces sélectionnées par le titulaire ;
- les outils imposés par la collectivité ou déjà présents dans son système d’information.
Cette distinction évite que chaque non-conformité soit attribuée, après la livraison, à une dépendance sur laquelle personne ne reconnaît avoir de responsabilité.
Lorsqu’un service externe présente un risque, le prestataire doit disposer d’une obligation d’alerte. Il doit signaler le problème par écrit, expliquer ses conséquences et proposer, lorsque cela est possible, une solution de remplacement accessible.
Préciser le référentiel applicable
Le marché doit citer explicitement la version du référentiel utilisée pour évaluer la prestation.
Une formulation peut indiquer que les travaux sont réalisés et contrôlés selon la version du RGAA en vigueur à la date de notification du marché. Le contrat doit également prévoir la manière dont seront traitées les évolutions réglementaires intervenant pendant son exécution.
Imposer automatiquement toute nouvelle version du référentiel peut sembler protecteur, mais cette approche crée une incertitude sur le périmètre, les délais et le prix de la prestation.
Une solution plus équilibrée consiste à organiser une analyse d’impact. Lorsqu’une nouvelle version est publiée, le titulaire identifie les exigences nouvelles, évalue les écarts et présente les éventuelles adaptations nécessaires. La collectivité peut ensuite décider de les intégrer au marché dans les conditions autorisées par le droit de la commande publique.
L’objectif n’est pas d’affaiblir l’obligation d’accessibilité. Il s’agit de rendre son application prévisible et pilotable.
Transformer les exigences RGAA en obligations métier
L’accessibilité ne doit pas apparaître dans une seule clause isolée du cahier des charges. Elle doit être répartie entre les différentes phases du projet.
Les obligations applicables à la conception
Les maquettes doivent prévoir les comportements accessibles avant le développement.
Cela concerne notamment les contrastes, la taille des textes, la visibilité du focus, l’ordre de navigation, la présentation des erreurs, l’identification des champs obligatoires et les différents états des composants interactifs.
Une maquette qui ne présente que l’état visuel par défaut d’un bouton ou d’un formulaire reste incomplète. Elle doit également montrer ce qui se passe lorsque l’utilisateur navigue au clavier, agrandit le texte ou rencontre une erreur.
Le prestataire doit documenter ces comportements dans les livrables de conception. Sans cette étape, les développeurs doivent interpréter les intentions du designer, avec un risque important d’incohérence.
Les obligations applicables au développement
Le contrat doit exiger un code structuré, sémantique et compatible avec les technologies d’assistance.
Les composants doivent pouvoir être utilisés au clavier. Le focus doit rester visible. Les messages dynamiques doivent être restitués correctement. Les formulaires doivent associer chaque champ à une étiquette pertinente et signaler clairement les erreurs.
L’usage d’attributs ARIA ne doit pas devenir un substitut à un HTML correctement structuré. Leur utilisation doit être justifiée par le comportement réel du composant et contrôlée au moyen de tests manuels.
Le marché peut également imposer l’intégration de contrôles automatiques dans la chaîne de développement. Ces outils permettent de détecter certaines erreurs fréquentes, mais ils ne remplacent pas un audit RGAA complet.
Les obligations applicables aux contenus
Un site techniquement accessible peut rapidement perdre sa conformité lorsque les contenus publiés ne respectent pas les règles de contribution.
Le contrat doit donc préciser les responsabilités relatives aux textes alternatifs, aux titres, aux liens, aux tableaux, aux vidéos et aux documents bureautiques.
Lorsque le prestataire réalise une migration de contenus, il doit contrôler l’accessibilité des contenus transférés et signaler ceux qui nécessitent une reprise. Lorsque la collectivité reste responsable de la production éditoriale, le prestataire doit au minimum fournir des modèles, des consignes et une formation adaptée au CMS.
Quels livrables d’accessibilité faut-il demander ?
Les livrables constituent la preuve que l’accessibilité a réellement été prise en compte. Ils ne doivent pas être limités au rapport d’audit final.
Les livrables de conception
Pendant la phase UX et UI, la collectivité peut demander :
- une grille de contrôle des wireframes et des maquettes ;
- un relevé des contrastes ;
- la description des états de focus ;
- les règles de navigation au clavier ;
- les spécifications des messages d’erreur ;
- la documentation des composants du design system.
Ces documents facilitent la validation des maquettes et évitent de reporter tous les problèmes sur la phase de développement.
Les livrables de développement
Le titulaire peut être tenu de remettre un inventaire des composants réalisés, la documentation de leurs comportements accessibles, les résultats des tests automatiques et les comptes rendus des tests manuels.
La documentation doit être suffisamment précise pour permettre à une autre équipe de reprendre le projet. Elle doit notamment expliquer les éventuelles dépendances techniques, les limites connues et les précautions à respecter lors des évolutions.
Les livrables de recette
Avant la réception, les documents attendus peuvent comprendre :
- un rapport d’audit RGAA ;
- la composition de l’échantillon audité ;
- la liste détaillée des non-conformités ;
- leur niveau de gravité ;
- un plan de correction daté ;
- les résultats du contre-audit ;
- les informations nécessaires à la déclaration d’accessibilité ;
- les supports de formation et de contribution ;
- la documentation destinée à la maintenance.
L’évaluation officielle de la conformité repose sur un échantillon représentatif de pages et sur l’application des critères et tests du RGAA. Le rapport doit donc préciser les pages contrôlées, les environnements de test et les résultats obtenus.
Un simple score fourni par un outil automatique ne constitue pas un audit de conformité.
Les livrables de réversibilité
La fin du marché ne doit pas priver la collectivité des moyens nécessaires pour maintenir l’accessibilité.
Le dossier de réversibilité doit regrouper les rapports d’audit, l’historique des anomalies, les composants documentés, les procédures de test, les décisions de dérogation, les règles de contribution et la liste des dépendances externes.
Ces éléments réduisent la dépendance vis-à-vis du titulaire et facilitent la continuité du projet en cas de changement de prestataire.
Qui doit réaliser l’audit d’accessibilité ?
Le prestataire doit contrôler son propre travail pendant toute la production. Cette auto-évaluation est indispensable, mais elle ne suffit pas toujours pour prononcer la réception.
Une collectivité peut choisir de faire réaliser l’audit final par un tiers indépendant. Cette organisation offre un regard extérieur et limite le risque que le titulaire soit seul juge de la qualité de sa propre prestation.
Le contrat doit alors préciser qui sélectionne l’auditeur, qui finance l’audit initial et qui supporte le coût des contre-audits.
Une répartition fréquente consiste à faire financer l’audit initial par la collectivité et les contre-audits supplémentaires par le titulaire lorsque les corrections annoncées ne sont pas validées. Ce mécanisme doit rester proportionné et être clairement écrit dans les documents du marché.
L’organisation la plus robuste combine généralement trois niveaux de contrôle : des tests continus par l’équipe de production, des revues intermédiaires sur les composants sensibles et un audit indépendant avant la réception.
Ne pas réduire la recette à un taux de conformité
Le taux de conformité constitue un indicateur utile, mais il ne doit pas être le seul critère de réception.
Un site peut afficher un taux relativement élevé tout en laissant un parcours essentiel totalement inutilisable. Un formulaire de demande d’aide, une prise de rendez-vous ou un paiement en ligne peuvent être bloqués par une seule erreur technique.
Les conditions de réception doivent donc combiner plusieurs exigences :
- un niveau de conformité défini ;
- l’absence d’anomalie bloquante ;
- l’accessibilité des parcours prioritaires ;
- la conformité des composants mutualisés ;
- la remise de l’ensemble des livrables ;
- la validation des corrections par un contre-audit.
Pour une collectivité, les parcours prioritaires correspondent généralement aux démarches les plus utiles aux citoyens : rechercher une information pratique, contacter un service, déposer une demande, prendre rendez-vous, consulter une décision ou télécharger un document.
La réception peut être prononcée avec réserves lorsque les anomalies restantes sont limitées et ne bloquent aucun service essentiel. Ces réserves doivent être détaillées, assorties d’un délai de correction et suivies d’une nouvelle vérification.
Une réserve sans échéance ni responsable identifié ne constitue pas un dispositif de pilotage.
Prévoir une garantie de correction
La réception du site ne doit pas mettre fin aux obligations du titulaire.
Certaines non-conformités peuvent être détectées après la mise en ligne, notamment lors d’un test utilisateur ou d’un audit complémentaire. Le contrat doit donc prévoir une garantie couvrant les défauts qui existaient au moment de la livraison, même s’ils n’ont pas été repérés pendant la recette.
Cette garantie doit indiquer sa durée, son périmètre et les délais de prise en charge.
Elle doit également préciser que la correction est réalisée sans coût supplémentaire lorsque l’anomalie résulte d’un composant ou d’un développement relevant du titulaire.
Intégrer une garantie de non-régression
Un site conforme lors de sa mise en ligne peut rapidement se dégrader.
Une mise à jour du CMS, l’ajout d’un module, la modification d’un formulaire ou l’évolution d’un composant peut réintroduire une erreur auparavant corrigée.
La garantie de non-régression doit couvrir ces situations. Elle peut définir une régression comme la perte d’une conformité précédemment validée à la suite d’une intervention réalisée par le titulaire.
Le contrat doit prévoir le délai dans lequel la régression doit être analysée, corrigée et contrôlée. La correction ne doit pas être facturée lorsqu’elle résulte directement de l’intervention du prestataire.
Les marchés de maintenance doivent également imposer des tests après chaque évolution significative. Il est plus efficace de détecter une régression dès sa création que d’attendre l’audit annuel.
À quoi servent les pénalités contractuelles ?
Les pénalités prévues dans les contrats de la commande publique sont des sanctions pécuniaires appliquées lorsque le cocontractant ne respecte pas une obligation contractuelle. Elles ont une fonction dissuasive, mais leur application suppose que le manquement soit précisément défini.
Une pénalité ne doit jamais permettre au titulaire de payer pour rester non conforme.
Elle s’ajoute à l’obligation de corriger. Elle ne doit pas s’y substituer.
Le contrat peut prévoir des pénalités lorsque le prestataire remet tardivement un rapport d’audit, ne fournit pas un livrable obligatoire, laisse persister une anomalie bloquante ou introduit une régression pendant la maintenance.
D’autres manquements peuvent également être concernés : absence d’alerte sur un risque connu, documentation incomplète, refus de participer au contre-audit ou dépassement d’un délai de correction.
Différencier les anomalies selon leur gravité
Toutes les non-conformités ne produisent pas les mêmes conséquences.
Une anomalie critique empêche l’accès à un service ou à une information essentielle. Il peut s’agir d’un formulaire impossible à envoyer au clavier, d’une fenêtre modale qui piège le focus ou d’un bouton dont la fonction n’est pas restituée par un lecteur d’écran.
Une anomalie majeure dégrade fortement l’expérience sans bloquer totalement le parcours. Une anomalie mineure provoque une gêne plus limitée ou concerne un contenu secondaire.
Cette classification permet d’adapter les délais de correction et les conséquences contractuelles.
Une anomalie critique peut entraîner un refus de réception ou une correction immédiate. Une anomalie majeure peut faire l’objet d’une réserve assortie d’un délai court. Une anomalie mineure peut être intégrée dans un plan de correction programmé.
Le niveau de gravité ne doit toutefois pas être décidé unilatéralement par le prestataire. La méthode de qualification doit être définie dans le marché et validée par la collectivité.
Comment calculer des pénalités proportionnées ?
Plusieurs méthodes sont possibles.
Une pénalité peut être calculée par jour de retard, par livrable manquant, par anomalie non corrigée ou selon un pourcentage du montant de la prestation concernée.
Le montant peut également évoluer en fonction de la gravité ou de la durée du manquement.
Un mécanisme progressif est souvent plus pertinent qu’un montant unique. Il distingue une correction remise avec quelques jours de retard d’une anomalie bloquante qui reste présente plusieurs semaines après une mise en demeure.
Les documents particuliers doivent préciser les obligations concernées, les délais, les modalités de calcul et la procédure applicable. Le CCAG applicable ne doit pas être supposé : l’acheteur doit choisir celui qui correspond à l’objet du marché et y faire expressément référence. Pour un marché portant sur la création, l’hébergement ou la maintenance d’un site, le CCAG applicable aux techniques de l’information et de la communication est généralement le cadre à examiner.
Les mécanismes prévus par un CCAG peuvent être complétés ou adaptés dans les documents particuliers. Une pénalité spécifique à l’accessibilité doit donc être articulée avec les autres clauses du marché afin d’éviter les incohérences ou les cumuls injustifiés.
Prévoir une procédure contradictoire
La qualification d’une anomalie peut donner lieu à un désaccord.
Le prestataire peut considérer que le problème provient d’un contenu fourni par la collectivité. La collectivité peut estimer que l’erreur résulte d’un composant mal conçu. Une solution tierce peut également être à l’origine du défaut.
Le contrat doit organiser une procédure contradictoire.
Chaque anomalie peut être enregistrée dans une fiche comprenant la page concernée, les étapes de reproduction, le critère RGAA associé, l’environnement de test, le niveau de gravité et le responsable présumé.
Le titulaire dispose ensuite d’un délai pour présenter ses observations. Si le désaccord persiste, l’avis d’un auditeur indépendant peut être sollicité.
Cette procédure ne doit pas devenir un moyen de reporter indéfiniment les corrections. Les délais doivent être adaptés à la gravité du problème et aux conséquences pour les usagers.
La doctrine et certains CCAG prévoient également que le titulaire puisse présenter ses observations avant l’application de pénalités. Ce principe contradictoire doit être pris en compte dans la rédaction du marché.
Articuler réserves, retenues et pénalités
Ces mécanismes n’ont pas la même fonction.
La réserve constate qu’une prestation n’est pas totalement conforme au moment de la réception. Elle fixe les corrections attendues et leur échéance.
La retenue permet de différer le paiement d’une partie de la prestation jusqu’à la remise d’un livrable ou à la validation d’une correction, lorsque le contrat le prévoit.
La pénalité sanctionne un manquement défini, par exemple un retard ou l’absence d’un document obligatoire.
La réfaction consiste à accepter une prestation imparfaite moyennant une réduction du prix. Cette solution doit être utilisée avec prudence pour l’accessibilité. Une collectivité ne devrait pas accepter durablement qu’une démarche essentielle reste inutilisable simplement parce que le montant de la prestation a été réduit.
Enfin, la résiliation peut être envisagée en cas de manquement grave ou répété : refus de corriger, absence manifeste de compétence, régressions persistantes ou non-respect d’une mise en demeure.
Ces mesures doivent être sécurisées avec le service juridique et adaptées aux pièces particulières du marché.
Exemple de matrice contractuelle
Une matrice permet de relier les exigences aux preuves attendues.
| Exigence | Preuve attendue | Moment du contrôle | Conséquence d’un manquement |
| Maquettes accessibles | Rapport de revue UX et UI | Validation des maquettes | Refus de validation |
| Navigation clavier fonctionnelle | Compte rendu de tests manuels | Recette des composants | Correction obligatoire |
| Parcours essentiels accessibles | Scénarios de recette validés | Avant mise en ligne | Réserve critique ou refus de réception |
| Audit RGAA remis | Rapport complet et échantillon documenté | Avant réception | Report de la réception |
| Corrections validées | Rapport de contre-audit | Fin de recette | Maintien des réserves |
| Absence de régression | Résultats des tests de maintenance | Après chaque évolution | Correction sous garantie |
| Documentation complète | Dossier de réversibilité | Fin du marché | Retenue ou pénalité prévue au contrat |
Cette matrice ne constitue pas un clausier juridique prêt à l’emploi. Elle sert de support au dialogue entre l’acheteur, le chef de projet, le référent accessibilité et le service juridique.
Les erreurs les plus fréquentes
La première erreur consiste à copier une clause générique sans l’adapter au projet.
La deuxième consiste à exiger une conformité totale sans prévoir ni audit, ni temps de correction, ni budget dédié.
Une autre erreur fréquente est de confier l’ensemble de l’évaluation finale au prestataire, sans contrôle indépendant. Le titulaire produit alors le site, choisit l’échantillon, réalise l’audit et valide ses propres corrections.
Certaines collectivités réceptionnent également le site avant la remise du rapport d’audit. Une fois la réception prononcée et les paiements réalisés, le rapport perd une grande partie de sa fonction contractuelle.
Les documents et contenus tiers sont aussi régulièrement oubliés. Pourtant, une démarche accessible qui renvoie vers un PDF inutilisable reste partiellement inaccessible.
Enfin, les clauses se concentrent souvent sur la livraison initiale et négligent la maintenance. Or la conformité n’est pas un état définitivement acquis.
Une méthode en sept étapes pour sécuriser le contrat
Pour rendre les clauses réellement applicables, la collectivité peut suivre une méthode progressive.
- Cartographier les services, les composants et les parcours essentiels.
- Répartir clairement les responsabilités entre la collectivité, le titulaire, les sous-traitants et les fournisseurs de solutions tierces.
- Traduire les exigences RGAA en critères d’acceptation concrets.
- Associer chaque étape du projet à des livrables obligatoires.
- Organiser les audits, les revues intermédiaires et les contre-audits.
- Définir les garanties, les délais de correction et les pénalités proportionnées.
- Maintenir les contrôles pendant les phases de maintenance et d’évolution.
Le principe peut être résumé simplement : chaque exigence doit produire une preuve, chaque preuve doit faire l’objet d’un contrôle et chaque écart doit déclencher une procédure définie.
Quelle gouvernance mettre en place ?
La qualité des clauses ne dispense pas la collectivité d’organiser son pilotage.
L’acheteur public, le service juridique, le chef de projet numérique, la direction de la communication, la DSI et le référent accessibilité doivent intervenir au bon moment.
Une personne ou une instance doit être clairement chargée de valider les livrables, de qualifier les anomalies, de suivre les corrections et de proposer l’application des mesures contractuelles.
Les preuves doivent être conservées : versions des maquettes, rapports d’audit, tickets, décisions, procès-verbaux, échanges avec le titulaire et résultats des contre-audits.
Cette documentation protège la collectivité, mais elle permet surtout de suivre la démarche dans la durée et d’éviter que les mêmes erreurs se répètent lors des marchés suivants.
Pour conclure : contractualiser une méthode, pas une promesse
Un contrat ne rend pas automatiquement un site accessible.
Il peut toutefois donner à la collectivité les moyens de vérifier la qualité de la prestation, d’obtenir les corrections nécessaires et de maintenir la conformité dans le temps.
Une clause générale sur le RGAA ne suffit pas. Elle doit être complétée par un périmètre, des obligations par phase, des livrables, des critères de recette, des garanties et une procédure de traitement des anomalies.
Les pénalités ne constituent que le dernier niveau du dispositif. Elles sont utiles lorsqu’elles sont précises et proportionnées, mais elles ne remplacent ni le dialogue avec le prestataire, ni les contrôles intermédiaires, ni l’expertise nécessaire à la recette.
La meilleure protection contractuelle reste une organisation dans laquelle l’accessibilité est vérifiée dès les maquettes, contrôlée pendant le développement et maintenue après la mise en production.
FAQ
Quelles clauses faut-il prévoir pour garantir l’accessibilité d’un site web ?
Le contrat doit préciser le référentiel applicable, le périmètre du service, les responsabilités, les livrables, les modalités d’audit, les critères de réception, les délais de correction, les garanties de non-régression et les conséquences des manquements.
Une clause indiquant que le site doit respecter le RGAA est-elle suffisante ?
Non. Une telle clause ne précise pas la version du référentiel, les pages concernées, les preuves attendues ou les conditions de validation. Elle doit être complétée par des obligations mesurables et une procédure de recette.
Peut-on appliquer des pénalités en cas de non-conformité RGAA ?
Oui, à condition que le contrat définisse précisément les obligations concernées, les faits générateurs, les délais et le mode de calcul. La pénalité doit rester proportionnée et ne supprime jamais l’obligation de corriger.
Qui doit réaliser l’audit RGAA avant la réception ?
Le prestataire doit réaliser ses propres contrôles, mais la collectivité peut confier l’audit final à un tiers indépendant. Cette organisation limite les conflits d’intérêts et renforce la fiabilité de la recette.
Quels livrables faut-il demander au prestataire ?
Les livrables peuvent comprendre les revues de maquettes, la documentation des composants, les résultats des tests, le rapport d’audit RGAA, le plan de correction, les contre-audits, les supports de formation et le dossier de réversibilité.
Un site peut-il être réceptionné avec des non-conformités ?
Une réception avec réserves peut être envisagée lorsque les anomalies sont limitées, non bloquantes et associées à un délai de correction précis. Les parcours essentiels ne devraient pas être réceptionnés lorsqu’ils restent inutilisables.
Comment éviter les régressions après la mise en ligne ?
Le marché de maintenance doit prévoir des tests après les mises à jour, une garantie de non-régression, des délais de prise en charge et des contrôles périodiques. Les composants mutualisés doivent être surveillés en priorité.
Le prestataire est-il seul responsable de l’accessibilité ?
Non. Le prestataire est responsable des obligations qui lui sont confiées, mais la collectivité reste responsable du service publié. Elle doit piloter la démarche, contrôler les résultats et maintenir ses obligations documentaires.
Les outils automatiques suffisent-ils pour vérifier la conformité ?
Non. Les outils automatiques détectent une partie des erreurs, mais de nombreux critères nécessitent une vérification humaine : navigation au clavier, pertinence des alternatives, restitution par un lecteur d’écran ou compréhension des messages d’erreur.
Le contrat doit-il prévoir les futures versions du RGAA ?
Oui, mais il est préférable d’organiser une analyse d’impact plutôt que d’imposer automatiquement toute nouvelle version. La clause doit préciser comment les évolutions du référentiel seront évaluées et intégrées au marché.
Sur le même sujet
- CCTP web RGAA : ce qui doit être mesurable et vérifiable
Résumer le contenu avec l’IA :Une collectivité prépare la refonte de son site institutionnel. Dans son cahier des clauses techniques particulières, elle demande une plateforme « moderne, intuitive, performante, accessible, sécurisée et écoresponsable ». Sur le papier, les ambitions semblent claires. Pourtant, au moment de la recette, les difficultés apparaissent. Le prestataire estime avoir livré… Lire la suite : CCTP web RGAA : ce qui doit être mesurable et vérifiable - Contrat : clauses de pénalités, garanties et livrables pour l’accessibilité
Résumer le contenu avec l’IA :Lorsqu’une collectivité confie la création ou la refonte de son site internet à un prestataire, la formule « le site devra être conforme au RGAA » semble, à première vue, suffisamment explicite. Elle ne l’est pas. Cette phrase fixe une intention, mais elle ne précise ni le périmètre concerné, ni… Lire la suite : Contrat : clauses de pénalités, garanties et livrables pour l’accessibilité - Sous-traitance web : comment sécuriser l’accessibilité quand il y a plusieurs prestataires ?
Résumer le contenu avec l’IA :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… Lire la suite : Sous-traitance web : comment sécuriser l’accessibilité quand il y a plusieurs prestataires ?