Un cahier des charges web « robuste » ne liste pas seulement des fonctionnalités. Il formalise des exigences vérifiables (preuves attendues, critères d’acceptation, responsabilités, jalons) pour garantir un service accessible (RGAA), sobre (RGESN) et fiable (Opquast). La méthode la plus efficace consiste à intégrer ces référentiels dès le cadrage, puis à piloter la conception, la réalisation et la recette à l’aide d’une matrice d’exigences qui suit tout le cycle projet.
Une réalité de terrain : quand la qualité n’est pas contractualisée
Dans une collectivité, la refonte d’un site internet démarre souvent avec une ambition légitime : moderniser l’image, faciliter les démarches, mieux informer. Dans une destination touristique, le projet vise aussi la conversion : agenda, réservation, contenus multi-saisons, interconnexions avec des outils métiers. Pourtant, dans les deux cas, le scénario se répète.
Le cahier des charges est solide sur les fonctionnalités, mais flou sur ce qui fait la qualité d’un service public numérique : l’accessibilité, la sobriété numérique, la cohérence éditoriale, la maintenabilité, la qualité des formulaires, la gestion des contenus. Le prestataire livre « ce qui est demandé », et la MOA découvre en recette une série de problèmes : parcours clavier incomplet, contrastes insuffisants, PDFs inexploitables, vidéos sans transcription, pages lourdes, scripts superflus, composants tiers inaccessibles, absence d’indicateurs, etc.
Le résultat n’est pas seulement un irritant utilisateur. C’est une dette technique, des surcoûts et une exposition au risque juridique et réputationnel. La bonne nouvelle est qu’il existe une manière simple de sécuriser l’essentiel : transformer RGAA, RGESN et Opquast en exigences contractuelles et en preuves de conformité.
Pourquoi RGAA, RGESN et Opquast doivent cohabiter dans un même cahier des charges
RGAA : l’accessibilité comme exigence légale et de qualité
Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) est le cadre français de vérification de l’accessibilité des services numériques. Il traduit en pratique des exigences issues des WCAG et s’appuie sur une logique de tests. Pour une collectivité ou un organisme lié au service public, l’enjeu n’est pas seulement de « faire au mieux » : il s’agit de démontrer une démarche (audit, déclaration, schéma pluriannuel, plans d’action) et de maintenir un niveau de conformité dans le temps.
Le RGAA est le référentiel français de tests permettant de vérifier l’accessibilité d’un site, d’un intranet ou d’une application, afin que les contenus et fonctionnalités soient utilisables par tous, y compris par les personnes en situation de handicap. Il s’appuie sur des critères testables et une démarche de conformité documentée.
RGESN : la sobriété numérique passe par des choix de conception et d’exploitation
Le RGESN (Référentiel Général d’Écoconception de Services Numériques) structure une démarche d’écoconception orientée réduction des impacts : consommation d’énergie, sollicitations réseau, charge serveur, obsolescence des terminaux, etc. L’écoconception n’est pas un vernis : elle influence les choix d’architecture, de design, de contenus et d’outillage. C’est précisément pour cela qu’elle doit être cadrée dans un marché, avec des indicateurs et une méthode de preuve.
Le RGESN est un référentiel d’écoconception des services numériques visant à réduire les impacts environnementaux d’un site ou d’une application. Il couvre l’ensemble du cycle de vie (cadrage, conception, contenus, développement, hébergement, exploitation) et encourage des choix mesurables de sobriété et de durabilité.
Opquast : le socle transversal qui facilite la recette
Opquast est un référentiel de qualité web couvrant un périmètre plus large : clarté, navigation, contenu, formulaires, performance perçue, sécurité, interopérabilité, etc. Dans un projet, Opquast joue un rôle utile : il rend la qualité « discutable » et donc pilotable, notamment avec des équipes mixtes (communication, SI, prestataires). En sélectionnant un sous-ensemble pertinent, Opquast devient un excellent complément pour sécuriser la contribution et l’exploitation.
Opquast est un référentiel de règles de qualité web qui aide à sécuriser l’expérience utilisateur, la contribution et la maintenabilité d’un site. Il sert de cadre commun entre métiers pour formuler des exigences claires, vérifier des points concrets en recette et professionnaliser la gouvernance qualité.
Le principe clé : une exigence n’existe que si elle est vérifiable
Le point de bascule, dans un cahier des charges, consiste à passer d’une formulation « déclarative » à une formulation « vérifiable ». Dire « le site sera accessible » est trop vague. Dire « un audit RGAA sera réalisé sur un échantillon défini, un rapport sera fourni, un plan de corrections sera priorisé, un contre-audit validera la conformité » est pilotable.
Pour chaque exigence, trois questions doivent être posées :
- Quelle preuve est attendue ? Un rapport, une capture, un test reproductible, un indicateur, un livrable, une démonstration en atelier.
- À quel moment est-elle contrôlée ? Maquettes, design system, intégration, pré-recette, recette, post-MEP.
- Qui porte la responsabilité ? Prestataire, MOA, éditeurs tiers, hébergeur, contributeurs.
C’est exactement l’objet de la matrice d’exigences.
La méthode en 5 étapes pour intégrer RGAA, RGESN et Opquast
Étape 1 : cadrer les objectifs avant d’écrire le DCE
Tout commence avant la rédaction du cahier des charges. Si les objectifs ne sont pas clarifiés, les exigences deviennent incohérentes ou impossibles à vérifier.
Définissez d’abord le périmètre : site principal, mini-sites, extranet, espace pro, formulaires, services tiers, médiathèque, documents, vidéos, cartographies, modules de réservation, etc. Identifiez ensuite les contraintes : CMS imposé, système d’informations existant, délais politiques, saisonnalité, ressources internes.
Enfin, fixez une cible réaliste. Pour l’accessibilité, cela peut être un objectif de conformité sur un périmètre prioritaire, assorti d’une trajectoire. Pour l’écoconception, cela peut être un score minimal RGESN ou une progression mesurée entre pré-production et mise en ligne.
Étape 2 : transformer les référentiels en exigences de marché
Plutôt que de « coller » des extraits de référentiels, l’objectif est de sélectionner les points structurants et de les traduire en livrables et critères d’acceptation.
Pour le RGAA, exigez une démarche : audit initial, plan de corrections, recette, contre-audit, publication de la déclaration d’accessibilité, et organisation de la maintenance.
Pour le RGESN, exigez une méthode d’écoconception documentée : hypothèses, arbitrages, mesures, justification des critères non applicables, et indicateurs avant / après.
Pour Opquast, choisissez un sous-ensemble cohérent : contribution, formulaires, navigation, contenu, erreurs, performance perçue, sécurité basique. L’intérêt n’est pas d’en faire « un examen », mais un filet de sécurité.
Étape 3 : évaluer les offres avec une grille orientée preuves
Une offre « rassurante » n’est pas celle qui promet le plus. C’est celle qui explique comment elle prouve la conformité.
Demandez des exemples de livrables : extrait de rapport d’audit, plan de test, grille de recette, modèle de déclaration, démarche d’écoconception, exemples d’indicateurs. Dans la grille d’analyse, valorisez la méthode, la clarté, et l’organisation de la maintenance.
Étape 4 : piloter la conception et la réalisation avec des jalons qualité
La conformité ne se rattrape pas en recette finale. Elle se construit par jalons.
Dès les maquettes, vérifiez contrastes, hiérarchie, focus, comportements de composants, cohérence des formulaires. En développement, exigez des contrôles réguliers et une correction au fil de l’eau. À chaque jalon, la matrice d’exigences sert de check-list contractuelle.
Étape 5 : recetter, publier, puis maintenir
La recette n’est pas un « go /no go » générique. C’est un ensemble de contrôles tracés.
Un bon marché prévoit explicitement : les critères de recette, les réserves possibles, les modalités de correction, la production des documents obligatoires, et un plan de maintien (contre-audit, formation, gouvernance, contribution).
La matrice d’exigences prête à l’emploi : structure et usage
Une matrice efficace doit être utilisable à trois moments :
- Avant le marché, pour écrire les exigences et éviter les angles morts ;
- Pendant le projet, pour piloter les jalons et la recette ;
- Après la mise en ligne, pour maintenir la qualité dans le temps.
Les colonnes recommandées
Vous pouvez reproduire cette structure dans un tableur. Elle couvre l’essentiel sans complexifier inutilement.
- Phase / Thématique ;
- Exigence ;
- Référentiel (RGAA / RGESN / Opquast) ;
- Niveau (Obligatoire / Recommandé / Différenciant) ;
- Preuve attendue ;
- Critère d’acceptation ;
- Moment de contrôle (Maquette, Dev, Pré-recette, Recette, Post-MEP) ;
- Responsable ;
- Commentaires / Justification (dont « non applicable »).
Extrait de matrice
| Phase / Thématique | Exigence | Référentiel | Preuve attendue | Critère d’acceptation |
| Formulaires | Les champs, erreurs et aides à la saisie sont utilisables au clavier et compréhensibles par lecteur d’écran. | RGAA | Rapport de tests + démonstration en atelier. | Parcours complet clavier ; messages d’erreur associés ; labels explicites ; focus visible. |
| Médias | Toute vidéo publiée dispose au minimum de sous-titres synchronisés et d’une transcription. | RGAA / Opquast | Exemple sur 3 vidéos + procédure de contribution. | Sous-titres présents ; transcription accessible ; lecteur contrôlable au clavier. |
| Performance / Sobriété | Les pages types respectent des budgets de poids et limitent les scripts non essentiels. | RGESN | Mesures avant MEP + rapport d’arbitrage. | Budget défini ; suivi des gabarits ; justifications documentées. |
Cet extrait est volontairement court. L’intérêt du modèle complet est de couvrir vos gabarits, vos parcours clés et vos dépendances (cartographie, réservation, moteur de recherche interne, etc.).
Clauses types : ce qu’il est utile d’écrire noir sur blanc
L’objectif n’est pas de transformer cet article en modèle juridique, mais de fournir des formulations directement réutilisables dans un CCTP / CCAP. Les clauses ci-dessous sont à adapter à votre contexte et à votre niveau d’exigence.
Clause type RGAA (accessibilité)
La prestation inclut une démarche de conformité au RGAA couvrant la conception, le développement, la recette et la mise en production. Un audit initial, sur un échantillon défini avec la MOA, et réalisé par un organisme tiers, sera effectué idéalement avant la mise en ligne. Un plan de corrections priorisé sera mis en place et appliqué, puis un contre-audit sera réalisé avant mise en production.
Clause type RGESN (écoconception)
La prestation intègre une démarche d’écoconception selon le RGESN. Le titulaire documente les choix de conception, les arbitrages et les mesures associées (poids des pages types, consommation de ressources, scripts tiers). Une auto-évaluation est fournie et justifie les critères non applicables. Les objectifs de sobriété sont définis au cadrage et vérifiés avant mise en production.
Clause type Opquast (qualité web)
La prestation s’appuie sur un sous-ensemble de règles Opquast défini en annexe, couvrant notamment la contribution, la navigation, les formulaires, l’information utilisateur et la qualité perçue. Le titulaire fournit les preuves attendues en recette (check-list, captures, démonstrations) et contribue à la mise en place de procédures de contribution garantissant la pérennité de la qualité.
Recette : comment objectiver sans alourdir le projet
Le piège classique est de rendre la recette impossible à tenir. L’objectif est plutôt d’organiser des contrôles efficaces, reproductibles, et adaptés à votre périmètre.
Pour l’accessibilité, combinez toujours deux approches : des tests automatisés (pour détecter des erreurs évidentes) et des tests manuels (pour vérifier les cas d’usage réels : navigation clavier, formulaires, composants interactifs, contenus éditoriaux). La matrice permet de documenter ce qui est testé, sur quels gabarits, et avec quelles preuves.
Pour l’écoconception, la meilleure approche est de fixer quelques indicateurs simples, stables et comparables : budgets de poids sur pages types, limitation des scripts et médias, cohérence des gabarits, et traçabilité des choix. Une mesure ponctuelle ne suffit pas ; un suivi par gabarit est plus fiable.
Pour la qualité Opquast, la recette est souvent plus rapide que prévu lorsque les règles ont été sélectionnées intelligemment. Un sous-ensemble bien choisi agit comme une check-list de cohérence : erreurs explicites, liens compréhensibles, contenus datés, pagination claire, téléchargements identifiés, etc.
Deux cas d’usage : collectivité et destination touristique
Cas 1 : refonte d’un site de collectivité avec démarches et formulaires
Sur un site institutionnel, les priorités se concentrent souvent sur l’accès à l’information et la réalisation de démarches. Les enjeux RGAA sont immédiats : si un formulaire est inutilisable au clavier, une partie du public est exclue. Dans le cahier des charges, il est donc pertinent de détailler les exigences sur les formulaires, la structure des pages, la cohérence des libellés, la gestion des erreurs, et l’accessibilité des documents.
Côté RGESN, l’écoconception se joue sur des points concrets : limiter les médias lourds, cadrer les gabarits, encadrer les scripts tiers, optimiser les images, et éviter les composants superflus. L’impact est double : réduction de charge et amélioration de la performance perçue.
Enfin, Opquast est particulièrement utile pour sécuriser la contribution : règles de nommage, gestion des liens, identification des fichiers, pages utiles (contact, accessibilité, mentions), cohérence de navigation, etc. C’est souvent ce qui fait la différence entre un site propre à la mise en ligne et un site durable dans le temps.
Cas 2 : site de destination avec agenda, cartographie et réservation
Les destinations touristiques cumulent des contraintes spécifiques : saisonnalité, pics de charge, contenus riches, filtrage avancé, cartes, interconnexions avec des outils de réservation ou des bases de données.
Dans ce contexte, le cahier des charges doit anticiper les dépendances : widgets tiers, cartes, modules de réservation, avis, flux externes. Le risque d’inaccessibilité vient souvent de là. La matrice permet de formaliser des exigences de compatibilité et de responsabilité : qui corrige quoi, et quelles alternatives sont prévues si un outil tiers est partiellement inaccessible.
Sur le plan RGESN, l’écoconception est un levier fort : une destination peut concilier attractivité et sobriété en cadrant les formats médias, les budgets de poids, la stratégie de chargement, et la hiérarchisation des contenus. Cela améliore la navigation mobile, qui reste un usage majoritaire dans de nombreux parcours touristiques.
Opquast, de son côté, aide à sécuriser la qualité éditoriale sur la durée : mise à jour des informations pratiques, datation, cohérence des pages événementielles, erreurs 404 évitées, contenus « saison » archivés correctement, etc.
Gouvernance : le facteur qui fait tenir la qualité après la mise en ligne
Un site peut être conforme un jour et se dégrader très vite, simplement parce que la contribution n’est pas cadrée. C’est particulièrement vrai sur les sites publics et touristiques, riches en contenus et mis à jour en continu.
La gouvernance minimale à prévoir dans le cahier des charges est simple : un référent (ou binôme) côté MOA, une procédure de contribution, une formation courte pour les contributeurs, et un rituel de contrôle (mini-audit périodique, vérification de gabarits, suivi des indicateurs). La matrice reste l’outil commun, car elle permet de vérifier la conformité non seulement sur le code, mais aussi sur les contenus.
Conclusion : un cahier des charges plus utile, plus sobre, plus sécurisant
Intégrer RGAA, RGESN et Opquast dans un cahier des charges ne consiste pas à empiler des exigences. L’enjeu est de rendre la qualité lisible, vérifiable et maintenable. La matrice d’exigences est l’outil le plus simple pour y parvenir : elle transforme des référentiels parfois perçus comme abstraits en un pilotage concret, avec des preuves, des critères d’acceptation et des jalons. Si votre objectif est de sécuriser une refonte, un marché public ou l’évolution d’un site existant, commencez par la matrice. Une fois qu’elle est posée, le cahier des charges devient plus clair, la sélection du prestataire plus objective, et la recette plus sereine.
FAQ
Comment gérer l’accessibilité des outils tiers (cartes, réservation, widgets) ?
La priorité est de clarifier les responsabilités : ce qui relève du prestataire et ce qui relève de l’éditeur tiers. Il est utile d’exiger des preuves de compatibilité, de prévoir des alternatives si certains parcours sont inaccessibles, et de documenter les limites dans la déclaration d’accessibilité lorsque cela est justifié.
Faut-il viser 100 % de conformité RGAA dès la première mise en ligne ?
Tout dépend du périmètre et de la maturité de l’organisation. Viser un haut niveau dès la conception est pertinent, mais la stratégie la plus robuste reste une trajectoire pilotée : prioriser les parcours critiques, recetter, publier, puis maintenir avec des contrôles périodiques. L’essentiel est d’éviter l’absence de pilotage.
Comment rendre le RGESN « mesurable » dans un marché ?
Le plus efficace est de fixer des indicateurs simples et comparables : budgets de poids sur pages types, limitation des scripts, règles médias, suivi des gabarits, et un rapport d’arbitrage documentant les choix. Exigez aussi une auto-évaluation RGESN et la justification des critères non applicables.
Un objectif de score RGESN est-il pertinent ?
Un score peut être utile s’il est accompagné d’une méthode claire et d’une traçabilité. Sans cela, il devient déclaratif. Une alternative efficace consiste à exiger une trajectoire et des indicateurs par gabarit, puis à vérifier l’amélioration entre une version de référence (pré-prod) et la mise en production.
Comment choisir les règles Opquast à intégrer au cahier des charges ?
Il est préférable de sélectionner un sous-ensemble aligné sur vos risques : contribution, formulaires, navigation, erreurs, contenus, téléchargements, cohérence des pages. L’objectif n’est pas d’« appliquer Opquast » en bloc, mais d’en faire un socle qualité compréhensible et contrôlable en recette.
Quelle différence entre une exigence et une recommandation dans le DCE ?
Une exigence est assortie d’une preuve et d’un critère d’acceptation. Une recommandation peut être souhaitable, mais sans contrôle, elle ne sécurise pas le projet. Dans la matrice, distinguer « obligatoire », « recommandé » et « différenciant » aide à prioriser et à arbitrer en cas de contrainte.
Qui doit porter la matrice d’exigences dans le projet ?
Le portage idéal est MOA / AMO, car la matrice structure le contrat et la recette. Le prestataire doit s’y référer et produire les preuves attendues. En interne, elle sert aussi de support de gouvernance et de contribution, notamment pour maintenir l’accessibilité et la sobriété après la mise en ligne.
Comment éviter que la qualité se dégrade après la mise en ligne ?
Il faut organiser la contribution : procédures simples, formation courte, gabarits cadrés, contrôles périodiques, et mise à jour des documents de conformité. Une matrice d’exigences vivante, utilisée comme check-list de maintenance, limite fortement la dégradation.
Quelles sont les premières actions à lancer si le marché est imminent ?
Les actions les plus rentables consistent à cadrer le périmètre, sélectionner les exigences prioritaires RGAA/RGESN/Opquast, et formaliser les preuves attendues. Ensuite, construisez une grille d’analyse des offres orientée méthode et livrables. C’est ce qui sécurise le choix du prestataire et la recette.
Sur le même sujet
- Gouvernance éditoriale : circuit de validation, responsabilités et droit à la correction
Dans une collectivité, un office de tourisme ou plus largement une organisation publique, le contenu n’est jamais juste du texte. Il engage la crédibilité institutionnelle, la qualité du service rendu, la cohérence de l’information et, parfois, la conformité à des obligations réglementaires. Pourtant, beaucoup de sites vivent encore avec une organisation implicite : on publie… Lire la suite : Gouvernance éditoriale : circuit de validation, responsabilités et droit à la correction - Opquast pour contributeurs : les règles à formaliser dans une charte éditoriale
Dans une collectivité ou une destination touristique, la qualité d’un site web ne se joue pas uniquement au moment d’une refonte. Elle se joue surtout après, dans la durée, quand des dizaines de mains différentes publient des actualités, mettent à jour des pages pratiques, ajoutent des images, insèrent des documents, créent des liens. C’est précisément… Lire la suite : Opquast pour contributeurs : les règles à formaliser dans une charte éditoriale - CCTP web : clauses RGAA et écoconception prêtes à l’emploi pour vos marchés publics
Dans une communauté de communes, Julien pilote la refonte du site institutionnel. Le budget est cadré, le calendrier serré et le marché public doit partir vite. L’équipe a déjà vécu un scénario classique : une mise en production « conforme aux clauses RGAA sur le papier », puis des retours d’usagers qui ne parviennent pas à utiliser… Lire la suite : CCTP web : clauses RGAA et écoconception prêtes à l’emploi pour vos marchés publics - Cahier des charges web : intégrer RGAA, RGESN et Opquast grâce à une matrice d’exigences prête à l’emploi
Un cahier des charges web « robuste » ne liste pas seulement des fonctionnalités. Il formalise des exigences vérifiables (preuves attendues, critères d’acceptation, responsabilités, jalons) pour garantir un service accessible (RGAA), sobre (RGESN) et fiable (Opquast). La méthode la plus efficace consiste à intégrer ces référentiels dès le cadrage, puis à piloter la conception, la… Lire la suite : Cahier des charges web : intégrer RGAA, RGESN et Opquast grâce à une matrice d’exigences prête à l’emploi