Un cahier des charges de site internet décrit le contexte, les objectifs, les publics, le périmètre, les contenus, les fonctionnalités, les contraintes, les responsabilités, le budget, le calendrier et les critères de validation. Il n’a pas besoin d’imposer toutes les solutions techniques. Son rôle est de donner aux prestataires une base commune pour proposer, chiffrer et livrer un projet adapté.
Une demande comme « nous voulons un site moderne avec un formulaire » laisse trop de place à l’interprétation. Qui utilisera le formulaire ? Quelles informations doit-il transmettre ? Qui recevra les demandes ? Comment vérifier qu’il fonctionne ?
Ce guide vous aide à répondre à ces questions sans devenir développeur. Vous y trouverez une méthode en huit étapes, un modèle directement copiable et une grille pour comparer les réponses reçues.
Qu’est-ce qu’un cahier des charges de site internet ?
Le cahier des charges est le document de référence qui formalise le besoin, le périmètre, les priorités, les contraintes, les livrables et les critères de validation d’une création ou d’une refonte. Il donne au commanditaire et au prestataire une même base de discussion.
Le document n’a pas vocation à prédire chaque détail du projet. Une inconnue peut être indiquée comme à arbitrer, avec une personne responsable et une échéance, plutôt que masquée derrière une formule vague.
Cahier des charges, brief et spécifications : quelle différence ?
| Document | Rôle principal | Niveau de détail |
|---|---|---|
| Brief | Résumer le contexte, le problème et les objectifs | Court et orienté décision |
| Cahier des charges | Définir le périmètre, les priorités, les contraintes, les livrables et la validation | Assez précis pour consulter et comparer |
| Spécifications | Détailler le comportement fonctionnel ou la solution technique | Produit avec le prestataire selon le projet |
Les frontières varient selon la taille du projet. Pour une TPE qui prépare un site vitrine, le brief et le cahier des charges peuvent tenir dans un même document. Une plateforme connectée à plusieurs outils métier demandera souvent des spécifications complémentaires.
Qui doit rédiger le cahier des charges ?
Le commanditaire porte les objectifs, les publics, les priorités et les contraintes de l’entreprise. Le prestataire peut l’aider à traduire ces informations en parcours, fonctionnalités et choix techniques.
Faites relire chaque partie par la personne qui en porte la responsabilité : direction pour les objectifs et le budget, marketing pour les contenus, métier pour les règles de fonctionnement, informatique pour les accès et intégrations, et interlocuteur compétent pour les sujets juridiques ou sectoriels.
Pourquoi préparer ce document avant de demander un devis ?
Un cahier des charges utile réduit les écarts d’interprétation et facilite une comparaison à périmètre commun. Il ne garantit ni le budget, ni le délai, ni le succès du site, mais il rend les hypothèses et responsabilités plus visibles.
Il permet notamment de :
- clarifier le résultat recherché avant de choisir une solution ;
- révéler les décisions manquantes et les dépendances ;
- transmettre la même base à plusieurs prestataires ;
- distinguer le socle indispensable des options ;
- préciser qui fournit et qui valide les contenus ;
- préparer les tests avant la mise en ligne ;
- encadrer les demandes qui apparaîtront en cours de projet.
France Num présente également le cahier des charges comme un moyen de structurer les objectifs, les cibles, le périmètre, les fonctionnalités, le référencement, les responsabilités, le budget et le calendrier d’un projet de TPE ou PME.
Si vous recherchez ensuite un accompagnement global, la page consacrée à la création de sites web présente les principaux types de projets et les étapes de réalisation proposées par Next Rise Digital.
Comment rédiger un cahier des charges en 8 étapes ?
Commencez par le besoin métier, puis précisez le périmètre et les conditions de validation. Vous pourrez laisser au prestataire les choix techniques qui ne constituent pas une contrainte réelle.
1. Décrire le contexte et le problème à résoudre
Expliquez votre activité, vos offres, la place du futur site et le déclencheur du projet. Indiquez s’il s’agit d’une première création ou d’une refonte.
Évitez « nous voulons améliorer notre présence en ligne ». Préférez une formulation observable : « notre offre a changé, mais le site actuel présente encore nos anciennes prestations et ne permet pas d’orienter les visiteurs vers le bon formulaire ».
À renseigner :
- activité, offres et zone servie ;
- rôle actuel ou futur du site ;
- problème rencontré ;
- événement qui déclenche le projet ;
- contraintes déjà connues ;
- décisionnaire et interlocuteur opérationnel.
2. Définir les objectifs, les publics et les actions attendues
Un objectif explique ce que le site doit aider l’entreprise ou l’utilisateur à accomplir. Associez-lui une action attendue et, lorsqu’une base fiable existe, un indicateur de suivi.
Par exemple, une clinique peut vouloir mieux expliquer ses spécialités et orienter chaque patient vers le bon point de contact. Une ESN peut chercher à présenter ses expertises et à qualifier les demandes selon le type de mission. Ces exemples décrivent un besoin, pas un résultat garanti.
Pour chaque public, notez :
- ce qu’il cherche à comprendre ;
- son niveau d’information au départ ;
- l’action principale attendue ;
- ses freins ou questions ;
- les appareils et situations d’usage importants ;
- l’indicateur disponible, sans inventer d’objectif chiffré.
3. Inventorier l’existant et les contenus
Pour une refonte, listez les adresses actuelles, les contenus, les fichiers, les données, les formulaires, les comptes et les outils connectés. Décidez ce qui doit être conservé, corrigé, fusionné, migré ou supprimé.
Ajoutez un responsable pour chaque texte, photo, vidéo ou document. Le prestataire doit savoir si les contenus sont prêts, à réécrire ou à créer. Précisez aussi les droits d’utilisation des visuels.
Un simple tableau suffit :
| Élément existant | Décision | Responsable | Point à vérifier |
|---|---|---|---|
| Page ou contenu | Conserver, réécrire, fusionner ou supprimer | À compléter | Trafic, exactitude, droits |
| Formulaire | Reprendre ou remplacer | À compléter | Destinataire, données, consentement |
| Nom de domaine | Conserver | À compléter | Titulaire et accès |
| Outil connecté | Reconnecter ou arrêter | À compléter | Contrat, données et dépendances |
4. Délimiter les pages, les contenus et les fonctionnalités
Préparez une arborescence provisoire : accueil, offres, pages de services, à propos, contact, ressources et pages obligatoires selon votre situation. Indiquez les langues, les types de pages et les volumes connus.
Décrivez ensuite chaque fonctionnalité par son usage. « Installer une extension de réservation » ne dit pas qui réserve, comment les créneaux sont gérés, si un paiement est demandé ni ce qui se passe en cas d’annulation.
Classez chaque besoin :
| Niveau | Définition | Traitement attendu |
|---|---|---|
| Indispensable au lancement | Nécessaire à l’objectif principal ou à une obligation applicable | Inclus dans le socle |
| Option | Utile, mais le lancement reste possible sans elle | Chiffrée séparément |
| Évolution | À décider après les premiers retours d’usage | Prérequis et impact futur signalés |
| Hors périmètre | Non demandé pour cette version | Exclusion écrite |
5. Formaliser les attentes de design, d’usage et d’accessibilité
Décrivez l’identité à respecter, les usages prioritaires et les critères observables. « Moderne » et « intuitif » ne suffisent pas : montrez des références, puis expliquez précisément ce que vous appréciez ou refusez.
Précisez par exemple :
- charte graphique et éléments de marque disponibles ;
- références appréciées et raisons concrètes ;
- parcours prioritaires sur mobile ;
- lisibilité, contraste, navigation au clavier et alternatives aux contenus visuels ;
- méthode et niveau d’évaluation attendus ;
- personnes chargées de tester et valider.
Le W3C recommande d’intégrer l’accessibilité dans la planification, d’assigner les responsabilités et les ressources, puis d’évaluer régulièrement le site. Le niveau attendu et les obligations applicables doivent être validés selon votre organisation et votre activité.
6. Cadrer la technique, la sécurité, les données, le SEO et la mesure
Indiquez les contraintes connues sans inventer une architecture. Le système de gestion de contenu, ou CMS, ne doit être imposé que si une raison vérifiable le justifie : compétence interne, intégration, politique informatique ou continuité avec un existant.
Votre cahier des charges peut demander :
- les rôles et niveaux d’accès ;
- l’hébergement, les sauvegardes et les environnements de test ;
- les intégrations avec la relation client, la réservation, le paiement ou un outil métier ;
- les données collectées, leurs destinataires et leur durée de conservation à valider ;
- les pages et thèmes prioritaires pour le référencement naturel (SEO) ;
- les adresses à conserver et les redirections à prévoir ;
- le plan de marquage, l’outil de mesure et la gestion du consentement ;
- la documentation et les accès remis à la fin.
La CNIL recommande d’intégrer la protection des données et la sécurité dès la conception. Elle rappelle aussi que certains traceurs nécessitent un consentement préalable, tandis que ceux strictement nécessaires peuvent relever d’exceptions. Listez donc les formulaires, mesures d’audience et services tiers prévus, puis faites valider les règles qui s’appliquent réellement à votre site.
7. Définir les livrables, les responsabilités et la recette
La recette est la vérification du site avant sa validation et sa mise en ligne. Chaque fonction importante doit être associée à un test compréhensible.
Écrivez les livrables attendus : arborescence, maquettes, contenus, configuration, documentation, formation, accès et fichiers. Précisez également le nombre ou le fonctionnement des cycles de correction proposés dans le devis.
| Tâche ou livrable | Produit par | Validé par | Échéance | Dépendance |
|---|---|---|---|---|
| Textes métier | À compléter | À compléter | À compléter | Informations internes |
| Maquettes | À compléter | À compléter | À compléter | Arborescence et charte |
| Photos et licences | À compléter | À compléter | À compléter | Droits d’utilisation |
| Recette | À compléter | À compléter | À compléter | Site de test disponible |
| Domaine, hébergement et accès | À compléter | À compléter | À compléter | Titulaire des comptes |
Demandez aussi les conditions de réversibilité : comment récupérer les accès, les contenus, les données et les éléments livrables si vous changez de prestataire ou de solution.
8. Fixer les priorités, le budget, les jalons et les changements
Donnez une enveloppe ou demandez plusieurs scénarios cohérents. Distinguez le coût initial des licences, de l’hébergement, de la maintenance et des autres frais récurrents.
Pour obtenir des repères distincts de ce guide, consultez l’article consacré au coût d’un site internet pour une TPE ou une PME. Ici, l’objectif est de préciser ce qui doit être chiffré, pas de fixer un prix universel.
Ajoutez les jalons, les délais de retour attendus et la procédure de changement : toute nouvelle demande significative doit être décrite, évaluée sur le périmètre, le coût et le calendrier, puis validée avant réalisation.
Modèle de cahier des charges de site internet à copier
Copiez la trame ci-dessous dans votre document de travail. Pour chaque rubrique, ajoutez un statut — Décidé, À arbitrer, Option ou Hors périmètre — ainsi qu’un responsable. Lorsqu’une décision manque, ajoutez une échéance.
1. Contexte et déclencheur
- Activité et offres : [à compléter]
- Création ou refonte : [à compléter]
- Problème actuel : [à compléter]
- Raison du projet maintenant : [à compléter]
- Résultat principal recherché : [à compléter]
- Statut / responsable / échéance : [à compléter]
2. Objectifs et indicateurs
- Objectif principal : [à compléter]
- Objectifs secondaires : [à compléter]
- Actions attendues sur le site : [à compléter]
- Indicateurs disponibles et méthode de mesure : [à compléter]
- Situation de départ connue : [à compléter ou non disponible]
- Statut / responsable / échéance : [à compléter]
3. Publics et parcours
- Public principal : [à compléter]
- Autres publics : [à compléter]
- Question ou besoin de chaque public : [à compléter]
- Action principale attendue : [à compléter]
- Freins, appareils et situations d’usage : [à compléter]
- Statut / responsable / échéance : [à compléter]
4. Existant à conserver ou migrer
- Site, domaine et hébergement actuels : [à compléter]
- Pages et contenus à conserver : [à compléter]
- Données et comptes à reprendre : [à compléter]
- Outils et intégrations existants : [à compléter]
- Éléments à fusionner ou supprimer : [à compléter]
- Accès disponibles et titulaires : [à compléter]
- Statut / responsable / échéance : [à compléter]
5. Périmètre éditorial
- Arborescence provisoire : [à compléter]
- Types et nombre estimé de pages : [à compléter]
- Langues : [à compléter]
- Textes, photos et vidéos disponibles : [à compléter]
- Contenus à créer ou réécrire : [à compléter]
- Responsable de chaque contenu et des droits : [à compléter]
- Statut / responsable / échéance : [à compléter]
6. Fonctionnalités
- Fonctions indispensables au lancement : [à compléter]
- Options à chiffrer séparément : [à compléter]
- Évolutions envisagées : [à compléter]
- Éléments explicitement hors périmètre : [à compléter]
- Fiche détaillée pour chaque fonction : [utilisateur, action, données, résultat, erreur, recette]
- Statut / responsable / échéance : [à compléter]
7. Identité, expérience et accessibilité
- Charte et éléments de marque : [à compléter]
- Références appréciées et raisons : [à compléter]
- Références refusées et raisons : [à compléter]
- Parcours mobiles prioritaires : [à compléter]
- Objectifs et critères d’accessibilité : [à valider]
- Méthode de test : [à compléter]
- Statut / responsable / échéance : [à compléter]
8. Technique, sécurité et intégrations
- Contraintes informatiques existantes : [à compléter]
- CMS imposé et justification, le cas échéant : [à compléter]
- Hébergement et environnements : [à arbitrer]
- Rôles, accès, sauvegardes et sécurité : [à compléter]
- Outils connectés et données échangées : [à compléter]
- Maintenance attendue : [à compléter]
- Statut / responsable / échéance : [à compléter]
9. SEO, migration et mesure
- Services, pages et sujets prioritaires : [à compléter]
- Adresses à conserver : [à compléter]
- Mappage et redirections : [à compléter pour une refonte]
- Métadonnées, sitemap et liens internes : [à compléter]
- Outils de mesure et Search Console : [à compléter]
- Consentement et plan de marquage : [à valider]
- Contrôles avant et après lancement : [à compléter]
- Statut / responsable / échéance : [à compléter]
10. Conformité et droits
- Identité de l’éditeur et informations de l’hébergeur : [à compléter]
- Données personnelles collectées et finalités : [à compléter]
- Traceurs et services tiers : [à compléter]
- Droits sur les textes, images, vidéos et logiciels : [à compléter]
- Obligations liées au secteur ou à la vente en ligne : [à valider]
- Personne chargée de la validation : [à compléter]
- Statut / responsable / échéance : [à compléter]
11. Livrables, recette et réversibilité
- Maquettes, configuration et contenus livrés : [à compléter]
- Documentation et formation : [à compléter]
- Scénarios et critères de recette : [à compléter]
- Corrections, garantie et maintenance : [à distinguer]
- Accès, fichiers et exports remis : [à compléter]
- Conditions de reprise par un autre prestataire : [à compléter]
- Statut / responsable / échéance : [à compléter]
12. Gouvernance, budget et calendrier
- Décideur et interlocuteurs : [à compléter]
- Budget ou scénarios à chiffrer : [à compléter]
- Coûts récurrents à isoler : [à compléter]
- Jalons et date cible : [à compléter]
- Délais de validation côté client : [à compléter]
- Procédure pour une demande nouvelle : [à compléter]
- Statut / responsable / échéance : [à compléter]
Comment décrire une fonctionnalité sans être développeur ?
Décrivez la fonction avec une formule simple : utilisateur + action + données + résultat + critère de recette. Ajoutez les règles, les cas d’erreur et la personne qui administrera l’information.
| Champ | Question à remplir |
|---|---|
| Utilisateur | Qui réalise l’action ? |
| Besoin | Que veut-il accomplir ? |
| Déclencheur | Depuis quelle page ou situation ? |
| Données | Quelles informations sont saisies, affichées ou transmises ? |
| Règles | Quelles conditions, permissions ou limites s’appliquent ? |
| Résultat attendu | Que se passe-t-il lorsque l’action réussit ? |
| Cas d’erreur | Que doit voir ou faire l’utilisateur si l’action échoue ? |
| Administration | Qui reçoit, modifie ou traite l’information ? |
| Priorité | Indispensable, option, évolution ou hors périmètre ? |
| Recette | Quel test permet de valider la fonction ? |
Exemple : un formulaire de demande de devis
- Utilisateur : un prospect qui souhaite présenter son projet.
- Action : choisir un service, décrire le besoin et transmettre ses coordonnées.
- Données : service demandé, budget estimé, description, délai et coordonnées nécessaires.
- Résultat : afficher une confirmation claire et transmettre la demande au destinataire convenu.
- Erreur : signaler les champs manquants et ne pas afficher de confirmation trompeuse si l’envoi échoue.
- Recette : tester un envoi valide, un champ obligatoire manquant, une adresse invalide, l’affichage mobile et la réception effective.
Cet exemple est pédagogique. Il ne décrit pas un cas client ni un fonctionnement technique universel.
Exemple trop vague et exemple vérifiable
« Ajouter une prise de rendez-vous moderne » est trop vague. Une formulation vérifiable précise qui peut réserver, les créneaux affichés, les confirmations, les annulations, le paiement éventuel, la personne qui gère l’agenda et les tests attendus.
Faut-il choisir WordPress ou un autre CMS ?
Pas nécessairement. En l’absence de contrainte justifiée, décrivez plutôt l’autonomie attendue, les rôles, les intégrations, la maintenance, la sécurité et la réversibilité. Demandez ensuite une recommandation argumentée.
Que faut-il ajouter pour une refonte de site ?
Une refonte doit protéger les contenus, les accès et les adresses utiles de l’existant. Ajoutez un inventaire et un plan de migration au cahier des charges.
Prévoyez :
- la liste des adresses et contenus actuels ;
- les données de performance disponibles ;
- la correspondance entre anciennes et nouvelles adresses ;
- les redirections prévues ;
- les comptes, données et intégrations à reprendre ;
- les éléments à conserver, fusionner ou supprimer ;
- les tests avant et après la mise en ligne ;
- la mise à jour du sitemap et des liens internes ;
- le suivi dans Search Console et l’outil de mesure autorisé.
Google Search Central recommande de tester le nouveau site, de préparer le mappage des adresses, de mettre en place les redirections, de mettre à jour les liens et le sitemap, puis de surveiller la migration. Une refonte ne doit donc pas traiter les anciennes URL comme un détail de dernière minute.
Quelles erreurs rendent un cahier des charges inutilisable ?
Les erreurs les plus fréquentes viennent d’attentes vagues, de responsabilités absentes ou d’une priorité donnée à tout le périmètre.
Évitez de :
- remplacer les résultats attendus par « moderne », « rapide » ou « intuitif » ;
- imposer une technologie sans expliquer le besoin ;
- oublier le volume et le responsable des contenus ;
- classer toutes les fonctions comme indispensables ;
- ignorer les cas d’erreur et les critères de recette ;
- confondre livraison, garantie, maintenance et évolution ;
- négliger les accès, les droits et la propriété des comptes ;
- cacher les inconnues au lieu de les marquer à arbitrer ;
- ajouter une fonction sans évaluer son effet sur le périmètre, le coût et le calendrier ;
- envoyer des versions différentes du document aux prestataires consultés.
Comment comparer les réponses des prestataires ?
Comparez d’abord ce qui est compris, supposé ou exclu. Un montant inférieur peut simplement laisser davantage de tâches à votre équipe.
| Critère | Prestataire A | Prestataire B | Point à clarifier |
|---|---|---|---|
| Compréhension des objectifs et des publics | |||
| Périmètre inclus et exclusions | |||
| Livrables et cycles de correction | |||
| Hypothèses techniques et intégrations | |||
| Contenus, SEO et migration | |||
| Tests et critères de recette | |||
| Responsabilités du client | |||
| Coût initial et options | |||
| Hébergement, licences et frais récurrents | |||
| Maintenance et conditions d’intervention | |||
| Propriété des comptes et réversibilité | |||
| Planning, jalons et dépendances |
Demandez à chaque prestataire de signaler ses hypothèses. Si l’un prévoit que vous rédigerez tous les textes et que l’autre inclut leur production, les deux totaux ne peuvent pas être comparés seuls.
Le point à retenir avant d’envoyer votre document
Un bon cahier des charges ne cherche pas à tout figer. Il rend le besoin, les priorités, les responsabilités et la validation compréhensibles.
Avant l’envoi, vérifiez que :
- l’objectif principal et les publics sont identifiés ;
- chaque exigence importante peut être comprise et testée ;
- les contenus, accès et validations ont un responsable ;
- les priorités, options et exclusions sont visibles ;
- les coûts récurrents et la réversibilité sont demandés ;
- les sujets juridiques ou sectoriels à valider sont signalés ;
- tous les prestataires reçoivent la même version datée.
Votre première trame est prête ? Décrivez votre projet et demandez un devis adapté à vos objectifs, à vos fonctionnalités et aux contenus à prévoir.
Questions fréquentes
Quelle longueur doit faire un cahier des charges de site internet ?
Il n’existe pas de longueur universelle. Le document doit être proportionné au projet : une vitrine simple demande moins de détails qu’un e-commerce ou une plateforme reliée à des outils métier. La clarté des décisions, inconnues, responsabilités et critères de recette compte davantage que le nombre de pages.
Quelle différence entre un brief et un cahier des charges ?
Le brief expose surtout le contexte, le problème et les objectifs. Le cahier des charges ajoute le périmètre, les priorités, les contraintes, les livrables, les responsabilités et les conditions de validation. Des spécifications détaillées peuvent être produites ensuite avec le prestataire.
Qui doit rédiger le cahier des charges d’un site web ?
Le commanditaire doit fournir les objectifs, les publics, les priorités et les contraintes. Une agence ou un consultant peut l’aider à transformer ces éléments en parcours et fonctionnalités. Les responsables métier, marketing, technique et juridique concernés doivent valider leurs parties.
Faut-il indiquer son budget dans le cahier des charges ?
Une enveloppe ou plusieurs scénarios facilitent des réponses réalistes et comparables. Précisez ce que le montant doit couvrir et demandez que les options, abonnements, licences, maintenance et autres frais récurrents soient séparés.
Que mettre dans un cahier des charges pour une refonte ?
Ajoutez l’inventaire des pages et données, les outils connectés, ce qui doit être conservé ou supprimé, le mappage des adresses, les redirections, les reprises de contenus et les contrôles SEO avant et après la mise en ligne.
Le cahier des charges doit-il imposer un CMS ?
Pas nécessairement. Si aucune contrainte justifiée n’existe, décrivez l’autonomie attendue, les rôles, les intégrations, la sécurité, la maintenance et la réversibilité, puis demandez aux prestataires d’expliquer leur recommandation.
Le cahier des charges peut-il évoluer pendant le projet ?
Oui. Chaque modification significative doit cependant être décrite, évaluée sur le périmètre, le coût et le calendrier, puis validée avant réalisation. Conserver une version datée évite que les parties travaillent sur des attentes différentes.
Un modèle gratuit suffit-il pour lancer le projet ?
Le modèle accélère le cadrage, mais il doit être adapté aux publics, aux règles métier, aux contenus, aux données, aux risques et aux contraintes du projet. Une revue par les personnes responsables reste nécessaire avant de consulter ou de contractualiser.
Sources consultées
- France Num — Bâtir le cahier des charges du site internet de son entreprise — publié le 20 mars 2026, mis à jour le 23 mars 2026, consulté les 19 et 20 octobre 2026.
- CNIL — Préparer son développement — publié le 27 janvier 2020, consulté le 20 octobre 2026.
- CNIL — Cookies et traceurs : que dit la loi ? — publié le 29 septembre 2020, consulté le 20 octobre 2026.
- Service Public Entreprendre — Mentions obligatoires sur le site internet d’une entreprise — vérifié le 13 octobre 2026, consulté le 20 octobre 2026.
- Google Search Central — Migrer un site — mis à jour le 11 septembre 2026, consulté le 20 octobre 2026.
- W3C WAI — Planning and Managing Web Accessibility — date non affichée, consulté le 20 octobre 2026.
Ce guide fournit une méthode de cadrage générale. Il ne remplace pas un conseil juridique, une analyse de conformité ou une spécification adaptée aux contraintes propres à votre activité.
