CCTP web RGAA : exigences mesurables et vérifiables

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é un site rapide, alors que certaines pages mettent plusieurs secondes à s’afficher. Il considère le système de gestion de contenu comme simple, mais les agents peinent à publier une actualité. Il annonce un site accessible, alors que plusieurs parcours restent inutilisables au clavier.

Le problème ne vient pas nécessairement d’une mauvaise volonté du titulaire. Il vient souvent d’un CCTP qui exprime des intentions sans définir les conditions permettant de contrôler leur réalisation.

Un CCTP web efficace doit répondre à quatre questions : quel résultat est attendu, comment sera-t-il vérifié, quelles preuves devront être produites et que se passera-t-il si l’exigence n’est pas satisfaite ?

Cette logique transforme le cahier des charges en véritable outil de pilotage. Elle facilite l’analyse des offres, encadre la réalisation et sécurise la recette du site.

Qu’est-ce qu’une exigence mesurable dans un CCTP web ?

Une exigence est mesurable lorsqu’elle décrit un résultat observable, une méthode de contrôle, un périmètre et une règle d’acceptation. Elle ne repose donc pas uniquement sur un adjectif ou sur une appréciation subjective.

La formulation « le site devra être performant » ne permet pas de déterminer si la prestation a été correctement exécutée. Chaque intervenant peut donner une signification différente au mot « performant ».

Une exigence plus exploitable préciserait les modèles de pages concernés, les indicateurs retenus, les conditions de test et les seuils attendus.

La rédaction d’une exigence vérifiable peut ainsi s’appuyer sur cinq composants :

l’objet concerné ;
le résultat attendu ;
la méthode de contrôle ;
le critère d’acceptation ;
la preuve à remettre.

Prenons un exemple.

Le moteur de recherche devra permettre à un utilisateur de retrouver une délibération à partir de son titre, de sa date ou d’un mot contenu dans son objet. Le scénario sera testé sur le jeu de données de préproduction. Les résultats devront être affichés en moins de deux secondes dans les conditions précisées au protocole de recette.

La formulation ne se contente plus de demander un moteur de recherche « efficace ». Elle décrit un usage, des données, un résultat et une modalité de vérification.

Pourquoi les formulations vagues fragilisent-elles un projet web ?

Les termes généraux sont fréquents dans les cahiers des charges numériques : moderne, intuitif, ergonomique, responsive, optimisé, robuste ou évolutif.

Ces termes ne sont pas inutiles. Ils expriment une orientation. En revanche, ils ne peuvent pas constituer seuls une exigence contractuelle.

Chaque candidat peut définir son propre niveau de qualité

Une agence peut considérer qu’un site est responsive dès lors que les contenus s’adaptent à la largeur de l’écran. Une autre peut intégrer dans cette notion la navigation tactile, l’orientation du terminal, la lisibilité des tableaux, la taille des zones interactives et le comportement des menus.

Les deux candidats affirmeront respecter la demande. Pourtant, leurs prestations ne seront pas équivalentes.

Cette imprécision complique l’analyse des offres. L’acheteur compare alors des promesses commerciales plutôt que des méthodes, des livrables et des engagements objectivables.

Les désaccords sont reportés à la recette

Lorsque les critères ne sont pas définis avant le développement, ils doivent être discutés à la fin du projet, au moment où les délais et le budget sont déjà fortement contraints.

Les échanges portent alors sur des questions difficiles à trancher :

le défaut observé correspond-il à une anomalie ou à une demande supplémentaire ?
le comportement contesté était-il explicitement prévu ?
la correction entre-t-elle dans le forfait ?
le défaut empêche-t-il l’admission du site ?
quel document permet de prouver l’écart ?

Un protocole clair réduit ces zones d’interprétation.

Les pénalités ne corrigent pas un besoin imprécis

Prévoir des pénalités peut être pertinent, mais une pénalité ne transforme pas une intention vague en obligation vérifiable.

Pour constater un manquement, il faut pouvoir rattacher l’anomalie à une exigence précise, à un périmètre et à une méthode de contrôle. Dans le cas contraire, son application devient difficile à justifier.

Définir le périmètre avant de définir les indicateurs

Avant de choisir des seuils ou des outils, le CCTP doit préciser ce qui entre réellement dans le marché.

Un site web public ne se limite généralement pas à quelques modèles de pages. Il peut comprendre un moteur de recherche, des formulaires, un espace personnel, des cartes, des vidéos, une newsletter, des documents téléchargeables et plusieurs services tiers.

Pour une destination touristique, le périmètre peut également inclure :

les fiches d’hébergements et d’activités ;
les agendas ;
les disponibilités ;
les systèmes de réservation ;
les cartes interactives ;
les itinéraires ;
les données issues de DataTourisme, Apidae ou d’autres systèmes d’information touristique ;
les widgets fournis par des partenaires.

Le CCTP doit préciser si les exigences s’appliquent à l’ensemble de ces éléments ou seulement à certains composants.

Cette distinction est importante. Un site principal peut être correctement développé tout en intégrant un moteur de réservation tiers lent ou inaccessible. Sans répartition explicite des responsabilités, chaque intervenant pourra considérer que le problème relève d’un autre prestataire.

Il convient donc d’identifier :

les éléments produits par le titulaire ;
les composants fournis par l’acheteur ;
les outils ou contenus gérés par des tiers ;
les responsabilités de l’hébergeur ;
les responsabilités des futurs contributeurs ;
les limites éventuelles du marché.

Décrire des parcours plutôt qu’une liste de fonctionnalités

Un CCTP web énumère souvent les fonctionnalités attendues : moteur de recherche, agenda, carte, annuaire ou formulaire de contact.

Cette liste ne suffit pas à décrire la qualité du service rendu.

Une fonctionnalité doit être rattachée à un parcours utilisateur. L’enjeu n’est pas seulement de vérifier qu’un formulaire existe, mais qu’un usager peut l’utiliser jusqu’à son terme.

Pour une collectivité, les scénarios critiques peuvent être les suivants :

rechercher une délibération ;
prendre rendez-vous avec un service ;
inscrire un enfant à une activité ;
signaler un problème sur l’espace public ;
déposer une demande ;
retrouver les horaires d’un équipement.

Pour une destination touristique, il peut s’agir de trouver un hébergement accessible, filtrer les activités disponibles à une date donnée, localiser un point d’intérêt ou réserver une prestation.

Chaque scénario devrait décrire le point de départ, le profil de l’utilisateur, les prérequis, les principales actions et le résultat attendu.

Le CCTP doit également prévoir les situations dans lesquelles tout ne se déroule pas normalement : champ obligatoire non rempli, session expirée, absence de résultat, erreur d’un service tiers ou indisponibilité d’une offre.

Un service numérique ne peut pas être considéré comme robuste s’il fonctionne uniquement dans son cas idéal.

Rendre l’accessibilité numérique contrôlable

La formule « le site devra être conforme au RGAA » est nécessaire, mais elle ne suffit pas à organiser la conformité.

L’accessibilité doit être intégrée dans les différentes phases du marché : conception, développement, recette, formation et maintenance. Le dispositif DesignGouv consacré aux marchés publics recommande de prévoir explicitement l’accessibilité dans la rédaction des documents, l’analyse des offres et le suivi de l’exécution.

À la date de rédaction de cet article, le référentiel applicable est le RGAA 4.1.2. Le RGAA 5 est annoncé pour la fin de l’année 2026, sans que cette évolution justifie de suspendre ou de reporter les démarches en cours.

Le CCTP doit donc indiquer la version de référence et préciser le traitement d’une éventuelle évolution pendant l’exécution du marché.

Les preuves doivent être prévues dès la consultation

La démonstration de la conformité peut s’appuyer sur plusieurs livrables :

annotations d’accessibilité sur les maquettes ;
documentation des composants ;
tests de navigation au clavier ;
tests avec des technologies d’assistance ;
rapports d’audits intermédiaires ;
audit final ;
plan de correction ;
déclaration d’accessibilité.

La déclaration d’accessibilité doit notamment présenter l’état de conformité, les contenus non accessibles, les éventuelles dérogations et les moyens de signaler une difficulté.

Le CCTP peut également prévoir qu’un audit soit réalisé par un tiers indépendant. Le prestataire conserve la responsabilité de ses contrôles internes, mais il ne devient pas seul juge de la conformité de sa propre production.

Un taux global ne suffit pas

Un taux de conformité donne une indication synthétique. Il ne décrit toutefois pas la gravité des anomalies.

Deux sites affichant un taux proche peuvent proposer des expériences très différentes. L’un peut comporter de nombreuses anomalies mineures, tandis que l’autre bloque l’accès à un formulaire essentiel.

La recette doit donc prendre en compte :

le taux de conformité ;
la liste des critères non conformes ;
les composants concernés ;
les parcours bloqués ;
la fréquence des anomalies ;
les contenus et documents hors périmètre ;
les possibilités de correction.

Contractualiser la performance web

La performance constitue un autre domaine dans lequel les formulations génériques produisent peu de valeur.

Demander un « chargement rapide » n’indique ni la page testée, ni le terminal utilisé, ni le type de connexion, ni l’état du cache.

Une exigence de performance doit préciser les conditions de mesure.

Celles-ci peuvent comprendre :

les modèles de pages sélectionnés ;
le terminal ou le profil simulé ;
le réseau utilisé ;
la localisation du test ;
l’état du cache ;
le nombre de mesures ;
la méthode de consolidation ;
les contenus présents dans la page ;
l’environnement de test.

Il convient également de distinguer les mesures réalisées en laboratoire des données collectées auprès des utilisateurs réels.

Les tests synthétiques sont utiles pour reproduire des conditions déterminées et comparer des versions. Les données réelles permettent d’observer ce qui se passe effectivement selon les terminaux, les réseaux et les usages.

Les deux approches sont complémentaires.

Prévoir des budgets de performance

Le CCTP peut fixer un budget maximal pour chaque modèle de page :

poids total de la page ;
poids des images ;
nombre de requêtes ;
nombre de scripts ;
nombre de polices ;
poids des ressources tierces.

Cette approche présente un avantage : elle permet de détecter les dérives avant qu’elles ne produisent une dégradation visible.

Une page peut respecter les objectifs lors de la première livraison, puis devenir progressivement plus lourde après l’ajout de vidéos, de traceurs ou de composants externes. Le budget de performance fournit une référence pour la maintenance.

Rendre l’écoconception vérifiable

L’expression « site écoresponsable » est aussi ambiguë que l’expression « site performant ».

L’écoconception ne correspond pas à un style graphique minimaliste ni à une note obtenue avec un outil automatisé. Elle suppose une réflexion sur le besoin, l’architecture, les contenus, les équipements, les données, les services tiers et la durée de vie du service.

Le Référentiel général d’écoconception de services numériques, dans sa version 2024, fournit un cadre méthodologique permettant de structurer cette démarche. Il couvre notamment la stratégie, les spécifications, l’architecture, l’UX/UI, les contenus, le développement, l’hébergement et les algorithmes.

Le CCTP peut demander une matrice précisant, pour chaque critère retenu :

son applicabilité ;
la réponse proposée ;
les éléments de preuve ;
les éventuelles limites ;
le responsable du contrôle ;
le moment de la vérification.

Par exemple, le RGESN invite à désigner un référent et à maintenir une documentation interne afin de pérenniser les pratiques d’écoconception.

Il traite également de la compatibilité avec des équipements anciens et de la sobriété des choix de contenus.

Un score environnemental peut compléter ces contrôles, mais il ne doit pas devenir la seule preuve. Le résultat dépend de la page testée, du scénario, des contenus et de la méthodologie de l’outil.

Encadrer le référencement naturel sans promettre une position

Un prestataire ne peut pas garantir durablement une première position dans les résultats de recherche. Le classement dépend des moteurs, de la concurrence, des contenus et de nombreux facteurs extérieurs au marché.

Le CCTP peut en revanche imposer des exigences techniques et méthodologiques vérifiables :

une structure HTML cohérente ;
des URL compréhensibles et stables ;
des balises Title administrables ;
un sitemap XML ;
des balises canoniques correctement configurées ;
la gestion des redirections ;
la prévention des erreurs d’indexation ;
un plan de migration ;
la conservation des anciennes URL stratégiques ;
un rapport de recette SEO.

La migration mérite une attention particulière. Une refonte peut entraîner une perte de visibilité lorsque les anciennes adresses ne sont pas correctement redirigées vers les nouvelles pages.

Le CCTP doit donc demander un inventaire des URL, une table de correspondance et un contrôle après mise en ligne.

Pour renforcer la découvrabilité dans les moteurs de réponse, il est également pertinent d’exiger un contenu accessible dans le code source, une structure sémantique claire, des informations datées, des auteurs identifiés et des données structurées cohérentes avec le contenu visible.

Définir les exigences de sécurité

La demande d’un site « sécurisé » doit être traduite en contrôles précis.

Les attentes peuvent concerner :

le chiffrement des échanges ;
les droits d’accès ;
l’authentification ;
les mises à jour ;
les dépendances logicielles ;
les sauvegardes ;
la restauration ;
la journalisation ;
les formulaires ;
la gestion des incidents ;
la protection des données personnelles.

La sécurité ne doit pas être vérifiée uniquement par une déclaration du titulaire.

Le marché peut prévoir une analyse des dépendances, un contrôle des en-têtes de sécurité, un test de restauration, une vérification des droits et un rapport de vulnérabilités avant la mise en production.

Les anomalies doivent ensuite être classées selon leur gravité. Chaque niveau est associé à un délai de prise en charge et à un délai de correction.

Une vulnérabilité critique ne peut pas suivre le même processus qu’une amélioration mineure de configuration.

Vérifier la qualité du back-office

Les exigences relatives au système de gestion de contenu sont souvent résumées par la formule « le back-office devra être simple et intuitif ».

Cette formulation ne permet pas de mesurer l’autonomie des agents.

La qualité du back-office doit être testée à partir de tâches concrètes :

créer une actualité ;
ajouter une image et son alternative textuelle ;
publier une fiche touristique ;
modifier un menu ;
planifier une publication ;
intégrer une vidéo ;
créer un formulaire ;
gérer une redirection ;
restaurer une ancienne version.

Les tests doivent être réalisés avec de futurs contributeurs, et pas uniquement avec les équipes techniques du titulaire.

Le protocole peut observer le nombre d’étapes, les erreurs rencontrées, les aides disponibles, le temps nécessaire et la capacité à terminer la tâche sans assistance.

La documentation et la formation font également partie de la vérification. Un outil peut sembler simple pendant une démonstration menée par son concepteur, puis devenir difficile à utiliser lorsque les agents travaillent seuls plusieurs semaines plus tard.

Quels livrables demander dans le CCTP ?

Un livrable constitue une preuve uniquement s’il est exploitable.

Un document intitulé « rapport de performance » ne suffit pas s’il ne présente ni les pages testées, ni la date, ni l’environnement, ni la méthode.

Le tableau suivant peut servir de base.

Domaine	Livrable attendu	Moment de remise	Modalité de contrôle
Fonctionnel	Matrice des exigences	Cadrage	Validation par la maîtrise d’ouvrage
UX	Parcours et prototypes	Conception	Revue métier et tests utilisateurs
Accessibilité	Annotations, tests et audits	À chaque jalon	Contrôle RGAA
Performance	Budget et rapports de mesure	Développement et recette	Tests reproductibles
Écoconception	Matrice RGESN	Conception à livraison	Revue documentée
SEO	Plan de redirection et rapport de recette	Avant mise en ligne	Crawl comparatif
Sécurité	Rapport de contrôle	Avant production	Analyse technique
Exploitation	Dossier d’exploitation	Livraison	Vérification de complétude
Formation	Supports et exercices	Transfert	Mise en situation
Réversibilité	Code, exports et documentation	Fin du marché	Test d’exploitabilité

Chaque livrable doit préciser son auteur, sa version, sa date, son périmètre, sa méthode et son statut de validation.

Organiser une recette réellement opposable

La recette ne doit pas être concentrée dans les derniers jours du projet.

Une démarche plus fiable consiste à contrôler progressivement les livrables :

lors du cadrage ;
pendant la validation des parcours ;
au stade des maquettes ;
lors de la production des premiers composants ;
sur la version bêta ;
en préproduction ;
après la mise en ligne ;
pendant la période de garantie.

Cette organisation permet de corriger plus tôt les défauts structurels.

Une erreur dans un composant réutilisé sur cinquante pages coûte beaucoup moins cher à corriger au début du développement qu’après l’intégration complète du site.

Classer les anomalies

Le CCTP ou le protocole de recette doit définir une classification partagée.

Une anomalie bloquante empêche un parcours essentiel ou rend la mise en production impossible.

Une anomalie majeure dégrade fortement le service, sans interdire tous les usages.

Une anomalie mineure constitue un écart limité, qui peut éventuellement être corrigé après l’admission.

Une demande d’évolution ne correspond pas à une anomalie lorsqu’elle ajoute un besoin absent des documents contractuels.

Cette distinction évite de transformer chaque désaccord en négociation sur le périmètre.

Utiliser une matrice de traçabilité

La matrice de traçabilité est probablement l’outil le plus important pour rendre un CCTP vérifiable.

Elle relie chaque exigence à un livrable, une méthode de contrôle, un responsable, un jalon et un résultat.

ID	Exigence	Priorité	Responsable	Livrable	Méthode de test	Seuil	Jalon	Preuve	Statut

Cette matrice peut être utilisée dès la consultation.

Chaque candidat indique si l’exigence est couverte, comment elle sera mise en œuvre, quelles dépendances sont identifiées et quelles preuves seront produites.

Elle doit ensuite être conservée pendant le cadrage, la réalisation et la recette.

Le même identifiant suit ainsi l’exigence depuis le besoin initial jusqu’à son admission. Cette continuité réduit les pertes d’information entre le marché, les ateliers, les tickets de développement et les rapports de recette.

Transformer les formulations vagues

Voici quelques exemples de reformulation.

Formulation vague	Éléments à préciser
Le site doit être rapide	Pages, indicateurs, seuils, outils et conditions de test
Le site doit être accessible	Référentiel, périmètre, audits, livrables et corrections
Le site doit être responsive	Terminaux, résolutions, orientations et parcours
Le site doit être sécurisé	Contrôles, gravité des anomalies et délais
Le site doit être écoresponsable	Critères RGESN, preuves et revues
Le site doit être bien référencé	Exigences techniques, migration et livrables SEO
Le CMS doit être intuitif	Profils, tâches et tests avec les contributeurs
Le site doit être maintenable	Documentation, dépendances et procédures
Le site doit être disponible	Taux, exclusions et méthode de calcul
Le site doit être évolutif	Architecture, documentation et réversibilité

L’objectif n’est pas de produire un CCTP interminable. Il est de préciser les exigences qui conditionnent réellement la qualité du service.

Les erreurs fréquentes à éviter

La première erreur consiste à reprendre un ancien CCTP en modifiant seulement le nom du projet. Les besoins, les outils, les responsabilités et les usages évoluent. Une clause adaptée à un ancien site peut être inutile ou contradictoire dans un nouveau contexte.

La deuxième erreur consiste à imposer systématiquement une technologie au lieu de définir un résultat. Une contrainte technique peut être légitime pour des raisons de sécurité, d’interopérabilité ou de mutualisation. Elle ne doit cependant pas remplacer la description du besoin.

La troisième erreur consiste à fixer un seuil sans préciser la méthode de mesure. Un résultat obtenu dans un outil et un environnement ne sera pas nécessairement reproduit dans un autre.

La quatrième erreur est de confondre un test automatisé avec une vérification complète. Les outils détectent certaines anomalies, mais ils ne peuvent pas évaluer seuls la qualité d’un parcours, la pertinence d’une alternative ou la compréhension d’un message.

Enfin, il est risqué de prévoir des exigences sans réserver le temps, les compétences et le budget nécessaires à leur contrôle. Une exigence non testée a peu de valeur opérationnelle.

Un bon CCTP prépare déjà la recette

La qualité d’un site web ne se décide pas au moment de sa livraison. Elle dépend largement de la manière dont le besoin a été formulé, partagé et suivi.

Un CCTP mesurable et vérifiable permet de comparer les offres sur des bases plus objectives. Il facilite le dialogue avec le titulaire, réduit les interprétations divergentes et sécurise les décisions d’admission.

Il ne s’agit pas de tout prévoir ni de supprimer toute possibilité d’évolution. Un projet numérique conserve nécessairement une part d’incertitude.

L’objectif est plutôt de distinguer clairement ce qui constitue une obligation, ce qui relève d’une proposition du candidat et ce qui devra être arbitré pendant le projet.

Une exigence qui ne peut être testée, constatée ou prouvée reste une intention. Or, dans un marché web, l’intention ne suffit pas à garantir la qualité du service livré.

FAQ

Qu’est-ce qu’un CCTP web ?

Un CCTP web est une pièce contractuelle qui décrit les spécifications techniques et fonctionnelles d’un site ou d’un service numérique. Il précise notamment le périmètre, les fonctionnalités, les contraintes, les livrables, les résultats attendus et les modalités permettant de vérifier la bonne exécution du marché.

Quelle différence existe-t-il entre un cahier des charges et un CCTP ?

Le cahier des charges est une expression générale qui peut désigner l’ensemble des documents décrivant un projet. Dans un marché public, le CCTP rassemble plus précisément les clauses techniques particulières. Il complète notamment les clauses administratives et les autres pièces du dossier de consultation.

Comment savoir si une exigence est mesurable ?

Une exigence est mesurable lorsqu’elle indique ce qui doit être observé, sur quel périmètre, dans quelles conditions et selon quelle règle d’acceptation. Deux évaluateurs appliquant le même protocole doivent pouvoir parvenir à une conclusion comparable.

Faut-il imposer les outils de test dans le CCTP ?

Pas systématiquement. Il est généralement préférable de définir le résultat, l’indicateur et la méthode. Un outil peut néanmoins être imposé lorsqu’il est nécessaire à la reproductibilité des mesures ou à la compatibilité avec le dispositif de contrôle de l’acheteur.

Peut-on exiger une conformité totale au RGAA ?

Les services publics numériques doivent être accessibles et conformes au référentiel applicable. Le CCTP doit néanmoins préciser le périmètre, la version du RGAA, les étapes de contrôle, les livrables, les responsabilités et les modalités d’audit. Une simple déclaration de conformité ne constitue pas une preuve suffisante.

Qui doit réaliser l’audit d’accessibilité ?

Le titulaire doit effectuer des contrôles pendant la conception et le développement. Pour sécuriser la recette, un audit final indépendant est préférable. Il permet de distinguer la production, l’auto-évaluation du prestataire et la validation du résultat livré.

Peut-on utiliser un score Lighthouse comme critère contractuel ?

Un score Lighthouse peut servir d’indicateur, mais il ne doit pas être utilisé seul. Il varie selon la page, le terminal, le réseau et la configuration. Le CCTP doit préciser les conditions de test et compléter le score par des métriques techniques et, lorsque cela est possible, des données réelles.

Comment vérifier l’écoconception d’un site ?

L’écoconception peut être vérifiée à partir d’une sélection de critères du RGESN, d’une matrice de preuves, de budgets de ressources et de revues réalisées à différents jalons. Une note automatisée peut compléter l’évaluation, mais elle ne démontre pas à elle seule la qualité de la démarche.

Quels livrables faut-il demander ?

Les principaux livrables comprennent la matrice des exigences, les spécifications, les parcours, les prototypes, la documentation des composants, les rapports de test, les audits, le plan de redirection, le dossier d’exploitation, les supports de formation et les éléments nécessaires à la réversibilité.

À quel moment faut-il définir les critères de recette ?

Les critères essentiels doivent être définis avant la publication de la consultation. Les préciser après l’attribution peut modifier la perception du périmètre, du prix et des responsabilités. Ils peuvent ensuite être détaillés pendant le cadrage, à condition de rester cohérents avec les documents contractuels.

Un CCTP détaillé limite-t-il la créativité du prestataire ?

Un CCTP détaillé ne limite pas nécessairement la créativité. Il peut définir précisément les usages, les contraintes et les résultats, tout en laissant au candidat la liberté de proposer la solution. La surprescription apparaît surtout lorsque l’acheteur impose les moyens sans justification.

Comment traiter les services tiers ?

Les services tiers doivent être identifiés dans le périmètre. Le CCTP doit préciser les responsabilités, les exigences applicables et les limites éventuelles. Le titulaire doit documenter les impacts des composants externes sur l’accessibilité, la performance, la sécurité, les données personnelles et l’écoconception.

CCTP web RGAA : ce qui doit être mesurable et vérifiable