Cahier des charges d’un site web : comment le rédiger avant de consulter une agence ?

Pourquoi préparer un cahier des charges avant de contacter une agence

Le cahier des charges d’un site web décrit le projet, ses objectifs, ses utilisateurs, ses contraintes et les résultats attendus. Il sert de document de référence pour comparer les propositions, obtenir des réponses précises et limiter les incompréhensions pendant la conception.

Ce document ne doit pas imposer à l’avance chaque choix technique lorsque les compétences manquent en interne. Il doit plutôt expliquer le besoin métier avec assez de précision pour permettre à une agence de proposer une solution cohérente. Un bon cahier des charges distingue donc les objectifs non négociables, les préférences et les points à arbitrer.

Cette préparation apporte plusieurs bénéfices :

• les agences comprennent le contexte avant de formuler leur recommandation ;
• les fonctionnalités sont décrites en fonction des usages, et non comme une accumulation d’options ;
• les postes de coût sont plus lisibles ;
• les critères de choix peuvent être définis avant la réception des offres ;
• les risques liés au contenu, à la sécurité, à la maintenance ou à la propriété des données sont identifiés plus tôt.

Le cahier des charges n’est pas un document réservé aux grands projets. Pour un site vitrine, une boutique en ligne, un portail réservé à des utilisateurs ou une refonte, quelques pages structurées peuvent déjà éviter des décisions coûteuses prises dans l’urgence.

Commencer par le contexte et les objectifs du site

La première partie doit répondre à une question : pourquoi ce site doit-il être créé ou refondu ? Une description comme améliorer la présence en ligne reste trop vague pour guider une conception. Il faut préciser le problème rencontré et le changement attendu.

Présentez d’abord l’activité, les publics concernés, les offres ou services à mettre en avant et les canaux déjà utilisés. Indiquez ensuite la situation actuelle : site absent, site difficile à administrer, navigation peu adaptée au mobile, contenus obsolètes, parcours de demande trop long ou absence d’outil de suivi.

Formulez ensuite des objectifs observables, sans promettre un résultat que le projet ne peut pas garantir. Par exemple :

• permettre à un visiteur de trouver une information précise depuis la page d’accueil ;
• présenter une gamme de services avec des contenus administrables ;
• recevoir des demandes via un formulaire avec transmission aux destinataires prévus ;
• publier régulièrement des articles ou des ressources ;
• vendre des produits avec un parcours de commande défini ;
• réduire les manipulations nécessaires pour mettre à jour les pages.

Précisez les indicateurs qui permettront de suivre ces objectifs après la mise en ligne. Selon le projet, il peut s’agir du nombre de demandes reçues, du taux de consultation d’une page, du volume de ventes, du nombre de contenus publiés ou du temps consacré à l’administration. L’outil de mesure et les règles de conservation des données doivent être abordés avec l’agence, notamment lorsque des données personnelles sont concernées.

Décrire les utilisateurs et leurs parcours

Un site ne se conçoit pas pour un public abstrait. Le cahier des charges doit présenter les principaux profils d’utilisateurs et leurs attentes. Une personne qui découvre l’activité n’a pas les mêmes besoins qu’un client existant, un candidat, un adhérent ou un professionnel qui recherche une documentation technique.

Pour chaque profil, indiquez :

• le niveau de connaissance du sujet ;
• le contexte de consultation, comme un ordinateur de bureau, un smartphone ou une connexion limitée ;
• la tâche prioritaire à accomplir ;
• les informations nécessaires avant de prendre une décision ;
• les obstacles actuels et les questions fréquentes.

Décrivez ensuite quelques parcours sous forme d’étapes. Un parcours de demande peut commencer par une recherche, se poursuivre par la consultation d’une page de service, puis mener vers un formulaire et une confirmation. Pour une boutique en ligne, le parcours comprend notamment la recherche d’un produit, la consultation des informations utiles, l’ajout au panier, la commande et l’accès aux informations après achat.

Cette approche permet de relier chaque fonctionnalité à un usage. Elle aide aussi à repérer les contenus indispensables : tarifs, conditions, délais, documents à télécharger, coordonnées, questions fréquentes ou informations de contact. L’agence pourra ainsi proposer une arborescence fondée sur les priorités plutôt qu’une organisation centrée sur les services internes.

Construire l’arborescence et préciser les contenus

L’arborescence représente la structure du site. Elle peut être présentée sous forme de liste hiérarchique, avec les pages principales et leurs sous-pages. Ne cherchez pas à produire une structure définitive si les contenus n’ont pas encore été analysés. Présentez plutôt une première organisation, puis identifiez les éléments à valider.

Pour chaque page importante, renseignez :

• son objectif ;
• son public principal ;
• l’action attendue après lecture ;
• les informations à afficher ;
• les liens vers d’autres pages ;
• le responsable de la rédaction et des mises à jour.

Le cahier des charges doit également préciser l’état des contenus. Indiquez ce qui sera conservé, réécrit, créé, traduit, photographié ou retiré. Une agence peut intégrer la conception éditoriale, la rédaction, la mise en page ou l’optimisation pour les moteurs de recherche, mais ces prestations doivent apparaître explicitement dans le périmètre.

Prévoyez une règle pour les fichiers médias. Les images doivent être disponibles dans un format exploitable, avec des droits d’utilisation vérifiés et des textes alternatifs prévus lorsque leur fonction le justifie. Les documents téléchargeables doivent être identifiés, datés si nécessaire et maintenus par un responsable. Un site dont le contenu n’a pas de propriétaire risque de devenir obsolète même lorsque sa partie technique fonctionne correctement.

Lister les fonctionnalités sans transformer le document en catalogue

Une fonctionnalité doit être décrite par son utilité, son comportement attendu et ses conditions d’utilisation. Écrire formulaire de contact ne précise ni les champs, ni les destinataires, ni la confirmation, ni la gestion des messages. Une formulation plus exploitable indique les informations demandées, les champs obligatoires, les contrôles, le message affiché après l’envoi et le traitement prévu des données.

Classez les fonctionnalités par priorité afin d’aider l’agence à construire une proposition par étapes :

• indispensables : elles conditionnent la mise en ligne ou le fonctionnement principal ;
• importantes : elles apportent une valeur attendue, mais peuvent être planifiées dans une seconde phase ;
• optionnelles : elles répondent à un besoin complémentaire à confirmer selon le budget et la charge.

Selon le projet, la liste peut couvrir la recherche interne, les formulaires, les comptes utilisateurs, les paiements, les réservations, les filtres, les téléchargements, les newsletters, les commentaires, les notifications, les connexions à des services tiers ou l’importation de données existantes.

Pour chaque intégration, indiquez le service concerné, les données échangées, la fréquence des échanges, le responsable des accès et le comportement attendu en cas d’erreur. Ne communiquez jamais de mot de passe ou de clé d’API dans un cahier des charges transmis par courrier électronique. Ces informations doivent être fournies par un canal sécurisé au moment approprié.

Définir les contraintes techniques, le SEO et l’accessibilité

Le cahier des charges doit laisser une place aux contraintes techniques déjà connues. Mentionnez le nom de domaine, l’hébergement existant, les outils de messagerie, les services de paiement, les logiciels internes, les comptes d’administration et les données à migrer. Précisez qui détient les accès et si une sauvegarde complète sera réalisée avant toute intervention.

Si un système de gestion de contenu est envisagé, décrivez les besoins des personnes qui publieront les pages : rôles distincts, brouillons, validation avant publication, révisions, médiathèque, catégories ou champs personnalisés. Le choix d’un outil ne doit pas être motivé par sa popularité seule. Il doit correspondre aux compétences disponibles, au niveau de personnalisation attendu, au rythme de publication et aux exigences de maintenance.

Le référencement naturel doit être intégré dès la conception. Demandez notamment :

• une arborescence lisible et cohérente ;
• des adresses de pages stables et compréhensibles ;
• la gestion des titres, descriptions et niveaux de titre ;
• des redirections pour les anciennes adresses lors d’une refonte ;
• un plan de migration des contenus ;
• la maîtrise des pages indexables et des contenus dupliqués ;
• un temps de chargement compatible avec les usages mobiles.

L’accessibilité doit aussi être formulée comme une exigence de conception. Le référentiel WCAG publié par le W3C fournit un cadre reconnu pour travailler sur la perception, l’utilisation, la compréhension et la robustesse d’un site. Le cahier des charges peut demander un niveau cible, des tests au clavier, une structure sémantique correcte, des contrastes vérifiés et des formulaires compréhensibles.

Intégrer la sécurité et la protection des données dès le départ

La sécurité ne doit pas apparaître dans le projet après la mise en ligne. Décrivez les données traitées, les personnes qui y accèdent, leur durée de conservation et les opérations réalisées. Un formulaire de contact, un compte utilisateur, une inscription à une lettre d’information et une commande ne présentent pas les mêmes risques ni les mêmes obligations.

Le cahier des charges peut demander les mesures suivantes :

• des comptes nominatifs avec des droits adaptés aux rôles ;
• une authentification renforcée lorsque le niveau de risque le justifie ;
• des mises à jour suivies du système, des extensions et des composants ;
• des sauvegardes régulières, testées et séparées du serveur principal ;
• un protocole de restauration documenté ;
• la limitation des données collectées aux besoins réels ;
• la protection des échanges par chiffrement ;
• des journaux d’activité et une procédure en cas d’incident.

La Commission nationale de l’informatique et des libertés rappelle que la protection des données doit être prise en compte dès la conception et par défaut. Le cahier des charges peut donc demander l’identification des rôles respectifs, la documentation des traitements, la gestion des consentements lorsque cela s’applique et les modalités d’exercice des droits.

Demandez aussi ce qui se passe lorsque le contrat de maintenance prend fin. Les accès, les sauvegardes, les fichiers sources, les bases de données et les licences doivent être identifiés. Une dépendance technique mal documentée peut rendre une migration difficile, même lorsque le site répond correctement aux besoins au moment de sa livraison.

Préparer le budget, le calendrier et les responsabilités

Un cahier des charges utile ne se limite pas à une liste de fonctionnalités. Il expose les ressources disponibles et les contraintes de calendrier. Indiquez si le projet doit respecter une date liée à une campagne, une ouverture, une publication réglementaire ou une période commerciale. Précisez aussi les délais nécessaires pour fournir les contenus, valider les maquettes et tester le site.

Le budget doit être envisagé sur l’ensemble du cycle de vie : conception, développement, contenus, hébergement, licences, maintenance, sécurité, suivi du référencement, évolutions et éventuelle migration. Si le montant disponible n’est pas arrêté, communiquez une enveloppe ou plusieurs scénarios internes à l’équipe chargée de la consultation. Cela permet aux agences de distinguer une version initiale réaliste d’un périmètre trop large.

Répartissez clairement les responsabilités :

• qui valide l’arborescence et les maquettes ;
• qui fournit les textes, les images et les mentions nécessaires ;
• qui crée les comptes et transmet les accès ;
• qui vérifie les fonctionnalités ;
• qui donne l’autorisation de mise en ligne ;
• qui répond aux demandes de maintenance après livraison.

Prévoyez des jalons de validation et une méthode pour consigner les corrections. Une demande qui intervient après la validation d’une maquette peut avoir un impact différent d’une correction d’erreur. Cette distinction doit être définie dans la proposition et dans le contrat afin d’éviter les désaccords sur le périmètre.

Organiser la consultation des agences et comparer les réponses

Avant l’envoi, ajoutez une fiche de synthèse avec les éléments essentiels : contexte, objectifs, publics, périmètre, contraintes, calendrier, livrables attendus et critères de sélection. Demandez à chaque agence de répondre avec une structure comparable. Une proposition peut notamment détailler la compréhension du besoin, la méthode, le planning, l’équipe mobilisée, les choix techniques, les livrables, les conditions de recette, la maintenance et les exclusions.

Les critères de comparaison peuvent être regroupés dans un tableau de travail :

Critère	Question à examiner	Élément attendu dans la réponse
Compréhension	La proposition reprend-elle les objectifs et les publics ?	Un périmètre reformulé et des points à clarifier
Méthode	Comment les décisions, validations et tests sont-ils organisés ?	Des étapes, des responsables et des livrables
Technique	La solution répond-elle aux contraintes de contenu, d’intégration et de sécurité ?	Des choix justifiés et leurs limites
Transfert	Les utilisateurs pourront-ils administrer le site ?	Formation, documentation et conditions d’accès
Après mise en ligne	Que couvrent la maintenance et l’assistance ?	Délais, périmètre, sauvegardes et évolutions
Coût	Les dépenses initiales et récurrentes sont-elles séparées ?	Devis détaillé, hypothèses et exclusions

Une réponse très technique n’est pas forcément la plus adaptée si elle ne traite pas les usages, les contenus et l’administration quotidienne. À l’inverse, une proposition séduisante sur le plan visuel doit être examinée sur la sécurité, la performance, l’accessibilité, la propriété des données et la capacité à faire évoluer le site.

Prévoir la recette, la mise en ligne et la maintenance

La recette est la phase durant laquelle le site est vérifié avant son acceptation. Le cahier des charges doit préciser les tests attendus et les conditions de validation. Préparez des cas concrets : consultation sur plusieurs tailles d’écran, navigation au clavier, envoi de formulaires, réception des notifications, recherche, téléchargement, création de compte, commande ou réservation selon le périmètre.

Demandez un environnement de préproduction lorsque le projet le justifie. Il permet de vérifier les contenus et les fonctionnalités sans exposer les modifications au public. La mise en ligne doit être accompagnée d’une liste de contrôle : sauvegarde, configuration du domaine, certificats, redirections, formulaires, outils de mesure, droits d’accès, indexation et affichage des mentions requises.

La maintenance doit distinguer plusieurs dimensions :

• maintenance corrective : résolution des dysfonctionnements ;
• maintenance préventive : mises à jour, contrôles et sauvegardes ;
• maintenance évolutive : ajout ou modification de fonctionnalités ;
• maintenance éditoriale : mise à jour des contenus et des documents.

Indiquez qui surveille les sauvegardes, qui applique les mises à jour et qui intervient en cas d’indisponibilité. Une documentation de fin de projet doit recenser les accès, les composants installés, les procédures courantes, les sauvegardes et les contacts utiles, sans y inscrire de secrets d’authentification.

La structure recommandée du document

Pour produire un cahier des charges lisible, utilisez une organisation stable et numérotez les versions. Le document peut suivre ce plan :

1. présentation du contexte et du projet ;
2. objectifs et indicateurs de suivi ;
3. publics et parcours prioritaires ;
4. arborescence et inventaire des contenus ;
5. fonctionnalités classées par priorité ;
6. contraintes techniques et intégrations ;
7. exigences de référencement, d’accessibilité et de sécurité ;
8. gouvernance, responsabilités et validations ;
9. budget, calendrier et livrables attendus ;
10. recette, mise en ligne et maintenance ;
11. critères de sélection et format de réponse demandé.

Ajoutez en annexe les éléments utiles : arborescence provisoire, inventaire des pages existantes, schémas de parcours, exemples de contenus, liste des outils connectés et contraintes juridiques déjà identifiées.

Avant la consultation, relisez le document avec les personnes qui publieront, valideront et administreront le site. Cette relecture révèle souvent des contraintes absentes de la vision initiale, notamment sur les droits d’accès, les circuits de validation, les documents à maintenir ou les délais de réponse. Le cahier des charges doit rester compréhensible par un interlocuteur métier et suffisamment précis pour être exploité par une équipe technique.

FAQ : les questions courantes avant de rédiger un cahier des charges

Faut-il connaître la technologie avant de consulter une agence ?

Non. Il est plus utile de décrire les objectifs, les utilisateurs, les contenus et les contraintes que d’imposer une solution technique mal maîtrisée. Vous pouvez toutefois mentionner les outils existants, les obligations de compatibilité et les préférences justifiées par vos usages. Demandez à l’agence d’expliquer les conséquences de ses choix.

Quelle différence entre un cahier des charges et une liste de fonctionnalités ?

Une liste énumère des fonctions. Un cahier des charges précise le contexte, les priorités, les parcours, les responsabilités, les contraintes, les critères de validation et la maintenance. Il relie chaque fonctionnalité à un besoin concret et indique ce qui est inclus ou exclu.

Faut-il fixer toutes les pages avant le début du projet ?

Une première arborescence est nécessaire pour estimer le périmètre, mais elle peut évoluer après l’analyse des contenus et des parcours. Les changements doivent être documentés et validés afin de mesurer leur impact sur le calendrier et le budget.

Comment éviter les mauvaises surprises après la livraison ?

Demandez une description précise des livrables, des accès, des tests, des exclusions, des coûts récurrents et de la maintenance. Vérifiez également la possibilité de récupérer les contenus, la base de données, les fichiers et la documentation si le prestataire change.

Le référencement doit-il être traité après la mise en ligne ?

Non. L’arborescence, les adresses de pages, les contenus, les redirections, la performance et la structure des titres se préparent dès la conception. Une intervention tardive peut obliger à modifier des pages déjà produites et perturber la migration.