Cahier des charges de site internet : modèle et méthode
Comment rédiger un cahier des charges de site internet ? Structure, questions, budget, critères de recette et modèle pour comparer des propositions utiles.
Un cahier des charges de site internet ne doit pas décrire une solution comme si toutes les décisions étaient déjà prises. Il doit transmettre assez de contexte pour que plusieurs prestataires comprennent le même problème, proposent une approche pertinente et chiffrent des hypothèses comparables.
Le meilleur document n’est donc pas le plus long. C’est celui qui rend visibles les objectifs, les utilisateurs, les contenus, les contraintes, les responsabilités et la manière dont le résultat sera accepté.
Qu’est-ce qu’un cahier des charges de site internet ?
Un cahier des charges de site internet est un document de cadrage partagé entre le commanditaire et les prestataires. Il décrit le contexte, les résultats attendus, les audiences, le périmètre, les contraintes et les critères de réussite. Il sert à comparer les propositions, organiser le projet et limiter les malentendus.
France Num recommande de formaliser ce besoin tout en laissant au prestataire la possibilité de conseiller les solutions adaptées. Cette nuance est essentielle : imposer une technologie sans raison peut fermer de meilleures options ; ne préciser aucune contrainte rend le devis imprévisible.
Pourquoi rédiger un cahier des charges pour un site web ?
Le document produit quatre effets utiles :
- il oblige l’équipe à accorder ses attentes avant de solliciter le marché ;
- il réduit les différences d’interprétation entre les devis ;
- il révèle les informations, contenus et accès qui resteront à fournir ;
- il crée une base pour arbitrer les demandes pendant le projet.
Il ne supprime pas toute incertitude. Au contraire, il doit signaler ce qui reste inconnu et indiquer comment cette incertitude sera réduite : atelier, audit, prototype, test ou lot de découverte.
Que doit contenir un cahier des charges de site internet ?
Un modèle complet peut suivre les douze sections suivantes.
1. Présentation de l’organisation
Expliquez l’activité, les offres, les marchés, l’équipe impliquée et le rôle actuel du numérique. Évitez le récit institutionnel trop long. Les informations utiles sont celles qui changent la décision : cycle de vente, saisonnalité, réglementation, réseau de points de vente, langues ou dépendance à un distributeur.
2. Contexte et problème à résoudre
Décrivez ce qui déclenche le projet. Le site est-il devenu difficile à maintenir ? L’offre a-t-elle changé ? Le trafic ne produit-il pas de demandes ? Des équipes ressaisissent-elles des informations ? Ajoutez des données de référence quand elles existent.
Pour un existant, joignez les résultats d’un audit de site web ou au minimum les volumes de trafic, conversions, contenus et technologies connues.
3. Objectifs et indicateurs
Un objectif décrit un changement observable : augmenter les demandes qualifiées, rendre un catalogue consultable, réduire les appels récurrents, recruter dans une zone ou faciliter l’accès à un service. Associez-lui une mesure et une situation initiale.
« Moderniser le site » est une orientation, pas un critère de réussite. « Permettre à un prospect mobile d’identifier l’offre adaptée et d’envoyer une demande complète en moins de trois minutes » est testable.
4. Utilisateurs et situations
Présentez les publics, leur contexte, leurs connaissances et leurs obstacles. Un persona décoratif n’apporte rien s’il ne modifie aucune décision. Une situation précise aide davantage : urgence, mobilité, besoin de validation interne, langue, handicap, qualité de connexion ou niveau de confiance.
5. Périmètre éditorial et arborescence
Listez les types de pages et contenus connus : offres, secteurs, cas clients, ressources, équipe, implantations, actualités, catalogue. Signalez ce qui existe, ce qui doit être réécrit et ce qui manque.
Ne figez pas nécessairement toutes les URL avant l’étude SEO. Demandez au prestataire de relier l’arborescence aux intentions de recherche et aux parcours. Si le projet cible le Centre-Val de Loire, précisez les zones réellement servies et les preuves disponibles au lieu d’exiger une page identique par ville.
6. Fonctions et règles métier
Décrivez les actions attendues, leur priorité et leurs exceptions. Pour un formulaire : champs, destinataire, consentement, fichiers, accusé de réception, anti-spam et destination CRM. Pour un catalogue : sources de données, filtres, fréquence de mise à jour et comportement lorsqu’une information manque.
Classez les fonctions en trois niveaux : indispensables au lancement, utiles ensuite, exploratoires. Cette distinction protège le prix du site internet et la date sans sacrifier la qualité du parcours principal.
7. Contenus, médias et responsabilités
Indiquez qui écrit, valide, traduit, photographie, importe et maintient. Fournir « les textes » peut signifier des documents prêts à publier ou des notes qui demanderont des entretiens et une réécriture complète. Estimez les volumes et nommez le responsable de validation.
8. Identité et expérience
Joignez la charte, les sources, les polices et les composants existants. Expliquez ce qui peut évoluer. Donnez des références pour commenter une qualité précise — hiérarchie, sobriété, densité, mouvement — et non pour demander une copie.
Précisez les besoins d’accessibilité, les appareils prioritaires et les parcours qui doivent être testés. Demandez la conception des états de chargement, de vide, d’erreur et de confirmation, pas seulement des écrans idéaux.
9. SEO, mesure et migration
Listez les domaines, propriétés Search Console, outils analytics et campagnes existantes. Demandez l’inventaire des URL, le plan de redirection, les métadonnées, le sitemap, les données structurées et la conservation des contenus utiles. Les recommandations officielles de Google pour un changement d’URL montrent pourquoi une migration doit être préparée et surveillée.
Précisez les événements de conversion, le consentement et les personnes qui auront accès aux données.
10. Technique, sécurité et exploitation
Décrivez les systèmes à connecter, l’hébergement imposé, les contraintes de sécurité, les rôles d’administration, les volumes et les environnements. Si aucune technologie n’est obligatoire, demandez une recommandation argumentée selon l’autonomie, la performance, la disponibilité des compétences et le coût total.
Ajoutez les attentes de sauvegarde, surveillance, mise à jour et reprise. Notre guide de la maintenance d’un site internet aide à distinguer ces responsabilités.
11. Budget, calendrier et gouvernance
Indiquer une enveloppe permet de recevoir une proposition adaptée plutôt qu’une solution théorique. Donnez une fourchette, expliquez ce qu’elle comprend et distinguez l’investissement initial des coûts récurrents.
Le calendrier doit inclure les validations internes, la disponibilité des contenus, les dépendances et une période de recette. Nommez le décideur, les contributeurs et la fréquence des points. Un projet ne gagne pas du temps si chaque écran attend l’accord informel de dix personnes.
12. Livrables et critères de recette
Listez les livrables : recherche, arborescence, textes, maquettes, code, données, documentation, formation, plan de redirection et accès. Pour chaque élément important, définissez un critère observable.
Exemples : un formulaire reçu dans le CRM avec la bonne source ; toutes les anciennes URL importantes redirigées en permanence vers une destination pertinente ; navigation complète au clavier ; publication autonome d’un nouveau cas client ; sauvegarde restaurée sur un environnement de test.
Comment faire un cahier des charges simple ?
Pour un petit site, un document de trois à cinq pages peut suffire. Copiez ce plan court :
- Contexte — activité, déclencheur, site actuel et interlocuteurs.
- Résultat — trois objectifs maximum et leur mesure.
- Publics — personnes, situations et objections principales.
- Périmètre — contenus, fonctions prioritaires et éléments exclus.
- Ressources — textes, images, données, identité et accès disponibles.
- Contraintes — délai, budget, légal, technique et sécurité.
- Attendus — méthode, livrables, maintenance et critères de recette.
Cette version courte reste meilleure qu’un catalogue de fonctions sans contexte. France Num met aussi à disposition plusieurs modèles à adapter plutôt qu’à remplir mécaniquement.
Faut-il imposer le CMS ou la technologie ?
Imposez une technologie lorsqu’une contrainte démontrable l’exige : compétences internes, système d’information, politique de sécurité, licence, hébergeur qualifié ou architecture commune. Sinon, exprimez les qualités attendues et demandez au prestataire de justifier son choix.
Par exemple : administration par trois profils non techniques, prévisualisation, export des données, temps de réponse, déploiement reproductible, disponibilité des développeurs et absence de dépendance à un compte appartenant au prestataire. Ces critères permettent de comparer deux solutions mieux qu’un nom de CMS.
Comment comparer les réponses des agences web ?
Construisez une grille commune avant de recevoir les offres.
| Critère | Question utile | Pondération indicative |
|---|---|---|
| Compréhension | La proposition reformule-t-elle le problème et les arbitrages ? | 20 % |
| Méthode | Les étapes réduisent-elles les incertitudes dans le bon ordre ? | 15 % |
| Équipe | Sait-on qui décide, conçoit, développe et accompagne ? | 10 % |
| Contenu et SEO | Le prestataire traite-t-il les intentions, preuves et migrations ? | 15 % |
| Technique | Les choix sont-ils justifiés et réversibles ? | 15 % |
| Exploitation | Maintenance, accès, documentation et reprise sont-ils clairs ? | 10 % |
| Budget | Le prix, les hypothèses et les coûts récurrents sont-ils lisibles ? | 15 % |
La pondération doit refléter le projet. Pour un site critique connecté au SI, la sécurité et l’exploitation pèseront davantage. Notre article sur comment choisir une agence web détaille les questions et signaux d’alerte.
Quelles erreurs éviter dans un cahier des charges ?
- Copier un modèle sans retirer les sections inutiles.
- Décrire cinquante fonctions sans indiquer le parcours prioritaire.
- Masquer le budget puis comparer des réponses de nature différente.
- Imposer un calendrier sans intégrer les validations internes.
- Sous-estimer la production et la migration des contenus.
- Confondre préférence visuelle et objectif utilisateur.
- Oublier les accès, la propriété du code et la réversibilité.
- Reporter la performance, l’accessibilité et la sécurité « après la V1 ».
- Exiger un prix fixe alors que les données ou intégrations sont inconnues.
Le document doit pouvoir évoluer après la phase de découverte. Conservez un journal des décisions et distinguez le besoin initial du périmètre finalement retenu.
Du document au projet réellement pilotable
Un bon cahier des charges ne sert pas à transférer toute la responsabilité au prestataire. Il crée une conversation exigeante : quel problème mérite l’investissement, quelle preuve doit être obtenue d’abord, et quelles fondations protègent la suite ?
Zence peut cadrer puis réaliser une création ou refonte de site web, ou intervenir en amont pour rendre une consultation plus fiable. Découvrez également notre approche d’agence web en Centre-Val de Loire. Pour faire relire un document ou transformer un besoin encore diffus, envoyez-nous le contexte du projet.
