Cahier des charges pour un site web : modèle complet pour une entreprise
Une direction décide de refaire le site de l’entreprise. Le marketing veut mieux convertir. Les ventes réclament des leads plus qualifiés. Les RH veulent intégrer les offres d’emploi. Les TI souhaitent limiter les nouveaux outils. La direction générale veut un site « plus moderne ». Quelqu’un ajoute qu’il faudrait aussi penser au SEO, au bilinguisme et peut-être au CRM.
Trois semaines plus tard, l’entreprise contacte des agences.
La première comprend qu’il s’agit surtout d’une refonte visuelle. La deuxième imagine une nouvelle architecture, une stratégie de contenu et une migration SEO complète. La troisième inclut un portail client, plusieurs intégrations et un accompagnement de six mois. Les trois propositions sont sérieuses, mais elles ne chiffrent pas le même projet.
Le problème n’est pas nécessairement du côté des agences. Le projet n’a jamais été suffisamment défini.
C’est précisément le rôle d’un cahier des charges pour un site web : transformer une intention générale — « refaire notre site » — en un projet suffisamment clair pour être compris, évalué, chiffré et livré sans obliger l’entreprise à devenir elle-même experte en UX, développement ou architecture technique.
Un bon cahier des charges ne décrit pas chaque bouton avant que le travail de conception commence. Il fixe les objectifs, les utilisateurs, le périmètre, les contraintes, les responsabilités, les intégrations, les exigences de qualité et les critères d’acceptation. Il laisse ensuite au prestataire la responsabilité de proposer le meilleur moyen d’y répondre.
Le résultat doit être un document de travail, pas un exercice administratif.
À quoi sert réellement un cahier des charges web ?
Un cahier des charges sert d’abord à créer une version commune du projet.
Avant sa rédaction, chacun possède souvent son propre site idéal. Le directeur des ventes imagine un outil de génération d’opportunités. Le marketing pense contenu, conversion et campagnes. Les TI voient surtout l’hébergement, les accès et les intégrations. La direction juge l’image de marque. Le prestataire, lui, doit transformer toutes ces attentes en périmètre concret.
Le document devient donc un point de convergence. Il ne remplace ni les ateliers de stratégie ni la conception UX. Il permet simplement d’éviter qu’une partie du projet n’existe que dans la tête d’une personne.
France Num, portail public français consacré à la transformation numérique des entreprises, présente d’ailleurs le cahier des charges comme un exercice permettant de structurer les besoins du site et d’aider les prestataires à produire des devis plus précis. Cette fonction est universelle : plus le périmètre est explicite, moins le devis repose sur des hypothèses invisibles. Voir les modèles de France Num.
Mais il faut éviter une confusion : plus détaillé ne veut pas automatiquement dire meilleur.
Un document de cinquante pages peut être mauvais s’il verrouille des choix arbitraires, répète des exigences génériques et ne dit jamais ce que le site doit produire pour l’entreprise. À l’inverse, un document de huit ou dix pages peut être excellent s’il rend clairs les objectifs, les contraintes, les responsabilités et les critères de réussite.
Le bon niveau de détail est celui qui réduit les ambiguïtés sans supprimer la capacité de réflexion du prestataire.
Imaginez que vous envoyez le document à trois agences compétentes qui ne peuvent pas vous poser de questions.
Si l’une peut raisonnablement comprendre « refonte graphique de 25 pages », une autre « nouvelle stratégie de contenu avec 80 pages » et la troisième « plateforme intégrée au CRM avec portail client », le cahier des charges est encore trop flou.
Les agences peuvent proposer des approches différentes. Elles ne devraient pas être obligées de deviner quel projet elles chiffrent.
Cahier des charges, brief et appel d’offres : ne mélangez pas les documents
Les termes sont souvent employés de manière interchangeable, ce qui crée beaucoup de confusion.
Un brief explique rapidement le contexte et le besoin. Il convient très bien pour un projet limité ou une première conversation avec une agence.
Le cahier des charges formalise davantage le projet : objectifs, utilisateurs, périmètre, contenus, fonctionnalités, contraintes, intégrations, responsabilités et critères de qualité.
L’appel d’offres organise la consultation de plusieurs fournisseurs. Il peut contenir le cahier des charges, mais ajoute des informations sur le processus : calendrier de réponse, format des propositions, critères d’évaluation, personnes-ressources et modalités de sélection.
| Document | Question principale | Utilité |
|---|---|---|
| Brief | « Quel est notre besoin ? » | Lancer la discussion |
| Cahier des charges | « Qu’est-ce que le projet doit couvrir et respecter ? » | Cadrer le travail |
| Appel d’offres | « Comment allons-nous consulter et choisir un prestataire ? » | Organiser la sélection |
Cette distinction est importante parce qu’un cahier des charges n’a pas besoin de contenir une grille de notation de fournisseurs pour être utile. À l’inverse, envoyer un appel d’offres sans véritable périmètre revient à organiser très proprement une consultation sur un projet mal défini.
Ce qu’il faut décider avant de commencer à rédiger
Le cahier des charges ne devrait pas être écrit seul par la personne du marketing qui « s’occupe du site ».
Avant la rédaction, réunissez les fonctions réellement touchées par le projet. Pour un site corporatif B2B, cela peut inclure marketing, ventes, communications, TI, RH, service à la clientèle et direction. Pour un site transactionnel, les opérations, la logistique ou la finance peuvent aussi être concernées.
L’objectif de cette étape n’est pas de créer un comité de vingt personnes qui approuvera chaque couleur. Il est d’identifier suffisamment tôt les contraintes que le projet devra absorber.
Par exemple, un responsable marketing peut ne pas savoir que l’équipe TI prévoit de retirer un ancien SSO dans six mois. Les ventes peuvent dépendre d’un formulaire connecté à Salesforce dont personne n’a parlé. Les RH peuvent avoir choisi un nouvel ATS. La direction peut prévoir une acquisition qui ajoutera deux marques au site.
Ces éléments ne sont pas des détails. Ils peuvent modifier l’architecture, le budget et l’échéancier.
Le premier atelier doit donc produire quatre réponses : pourquoi le projet existe, qui il doit servir, ce qu’il doit permettre et quelles contraintes sont déjà connues.
Si ces réponses ne sont pas encore claires, le cahier des charges doit le dire. Une zone d’incertitude explicite est préférable à une fausse décision prise uniquement pour remplir un document.
Commencer par le problème d’affaires, pas par la liste des pages
Beaucoup de cahiers des charges commencent par une arborescence.
Accueil. À propos. Services. Équipe. Blogue. Contact.
Cette liste donne l’impression que le projet est cadré alors qu’elle ne dit pratiquement rien sur la raison d’être du site.
Commencez plutôt par le déclencheur.
Pourquoi l’entreprise investit-elle maintenant ?
Le site actuel ne génère peut-être pas assez de demandes. Il peut être difficile à gérer. Une nouvelle marque a été lancée. Plusieurs sites doivent être consolidés. Le catalogue est devenu trop complexe. L’entreprise entre sur un nouveau marché. Le trafic organique progresse, mais les conversions stagnent. Le CMS n’est plus soutenu. Les équipes utilisent des outils parallèles pour contourner les limites du site.
Cette histoire donne du sens aux exigences qui suivent.
Comparez deux introductions.
Version faible :
Nous souhaitons refaire notre site pour le moderniser et améliorer l’expérience utilisateur.
Version utile :
Notre site actuel génère environ 40 000 visites par mois, dont 60 % depuis le référencement naturel, mais moins de 0,5 % des visiteurs remplissent un formulaire. L’équipe marketing dépend d’un développeur externe pour créer de nouvelles pages de campagne et le catalogue de services ne reflète plus notre offre actuelle. La refonte doit préserver notre visibilité organique, améliorer la conversion et rendre l’équipe autonome sur les contenus courants.
La seconde formulation permet déjà à une agence de réfléchir.
Elle comprend ce qu’il ne faut pas casser, ce qu’il faut améliorer et ce que le projet doit changer dans les opérations quotidiennes.
Définir les objectifs et les indicateurs de réussite
« Avoir un site moderne » n’est pas un objectif de projet suffisamment précis.
Le design peut être une composante importante de la refonte, mais il doit servir un résultat.
Un objectif utile décrit un changement souhaité. Il peut être commercial, opérationnel, éditorial ou technique.
Par exemple, une entreprise peut vouloir augmenter les demandes de soumission qualifiées, réduire le temps nécessaire à la création d’une landing page, augmenter les candidatures sur certains postes, consolider plusieurs marques ou diminuer le nombre d’appels de soutien grâce à un espace libre-service.
Le cahier des charges devrait distinguer objectifs et KPI.
L’objectif décrit la direction. Le KPI permet d’observer le résultat.
| Objectif | KPI possible |
|---|---|
| Générer plus d’opportunités | Taux de conversion, nombre de leads qualifiés, pipeline attribué |
| Rendre le marketing autonome | Temps de création d’une page, nombre d’interventions techniques |
| Protéger le SEO | Trafic organique, clics Search Console, positions des pages stratégiques |
| Améliorer la performance | Core Web Vitals, temps de chargement réel |
| Réduire les demandes répétitives | Utilisation FAQ/portail, baisse des contacts de support |
Il n’est pas nécessaire de transformer le cahier des charges en contrat de performance marketing. L’agence web ne contrôle pas toujours tous les facteurs qui influencent les ventes.
Mais si personne ne sait comment reconnaître une amélioration, la discussion post-lancement se réduit vite à des impressions subjectives.
Décrire les utilisateurs sans inventer des personas décoratifs
Les cahiers des charges adorent les personas.
« Sophie, 43 ans, aime le yoga, conduit un VUS et boit du café équitable. »
Ces détails ne servent à rien si aucune décision du site n’en dépend.
Une description utile des utilisateurs répond plutôt à trois questions : qui est la personne, ce qu’elle cherche à accomplir et ce qui complique actuellement son parcours.
Pour une firme d’ingénierie, les groupes pourraient être : donneurs d’ouvrage, partenaires professionnels, candidats et médias. Pour un manufacturier : ingénieurs, acheteurs, distributeurs et clients existants. Pour une clinique : patients, proches aidants et professionnels référents.
À chaque groupe correspondent des tâches.
L’acheteur veut vérifier une capacité et demander un prix. Le candidat veut comprendre les métiers et postuler. Le client existant cherche un document ou du soutien. Le journaliste cherche un porte-parole.
Cette logique influence directement l’arborescence, les contenus et les fonctionnalités.
Le cahier des charges n’a donc pas besoin de raconter toute la vie du persona. Il doit documenter les décisions que le site devra faciliter.
Cartographier l’existant avant une refonte
Un projet de création part d’une situation relativement simple : il faut construire.
Une refonte doit d’abord décider quoi faire de ce qui existe déjà.
C’est pourquoi l’audit de l’existant devrait apparaître dans le cahier des charges, même si l’audit complet est réalisé ensuite par le prestataire.
Documentez ce que vous connaissez : CMS, hébergement, domaines, sous-domaines, outils analytics, formulaires, pixels publicitaires, intégrations, langues, nombre approximatif d’URL, types de contenu, ressources téléchargeables, bases de données et comptes utilisateurs.
Ajoutez les actifs à protéger.
Une page qui génère peu de trafic peut être essentielle à une équipe de vente. Un PDF peut être utilisé quotidiennement par les clients. Une vieille landing page peut encore recevoir des backlinks importants. Un formulaire discret peut alimenter directement une automatisation commerciale.
Le piège de la refonte est de considérer comme inutile tout ce qui paraît ancien.
La bonne question n’est pas « est-ce joli ? ». C’est « est-ce que cet élément joue encore un rôle ? ».
Pour les sites importants, un inventaire de contenu séparé est souvent préférable au cahier des charges lui-même. Le document principal décrit alors la méthode attendue : conserver, fusionner, réécrire, rediriger, archiver ou supprimer.
Définir le périmètre sans concevoir le site à la place de l’agence
C’est probablement la partie la plus délicate du cahier des charges.
Vous devez être suffisamment précis pour permettre un chiffrage. Mais si vous décrivez toute la solution avant même d’avoir choisi l’équipe qui la concevra, vous réduisez la valeur de son expertise.
La bonne méthode consiste à séparer exigences, préférences et questions ouvertes.
Une exigence est non négociable. Par exemple : le site doit être bilingue, utiliser le SSO de l’entreprise, permettre à l’équipe marketing de publier sans développeur ou respecter une norme d’accessibilité définie.
Une préférence peut être discutée. Vous utilisez peut-être WordPress aujourd’hui et souhaiteriez le conserver, mais vous êtes ouvert à une autre solution si elle répond mieux aux contraintes.
Une question ouverte est justement un sujet sur lequel vous attendez une recommandation.
Cette distinction évite les formulations du type : « Le site devra utiliser WordPress, Elementor, tel plugin, telle structure de base de données et tel hébergeur », alors que personne dans l’organisation n’a réellement évalué ces choix.
Un bon cahier des charges dit ce que le système doit permettre. Il ne choisit la solution que lorsque l’entreprise possède une vraie raison de l’imposer.
Le nombre de pages est souvent trompeur.
Un site de 300 fiches construites à partir de six gabarits peut être plus simple qu’un site de 45 pages nécessitant vingt mises en page, plusieurs calculateurs et deux intégrations.
Pour aider au chiffrage, décrivez plutôt les grandes familles : page institutionnelle, service, produit, étude de cas, article, équipe, succursale, ressource, landing page, formulaire complexe.
Vous n’avez pas besoin d’en connaître le nombre définitif. Une estimation documentée vaut mieux qu’un silence qui oblige l’agence à inventer son hypothèse.
Contenu : la rubrique qui fait exploser les échéanciers quand elle est floue
La rédaction est l’un des postes les plus sous-estimés des refontes.
Le design avance. Les gabarits sont validés. Le développement se termine. Puis quelqu’un réalise que 70 pages doivent encore être écrites et approuvées.
Le cahier des charges doit donc répondre très tôt à une question simple : qui fournit le contenu ?
Ne vous limitez pas aux textes.
Le contenu comprend aussi les photos, vidéos, illustrations, biographies, études de cas, tableaux, PDF, témoignages, traductions et données structurées qui alimentent le site.
Pour chaque catégorie, précisez ce qui existe, ce qui doit être créé et qui en est responsable.
Une agence peut fournir une stratégie de contenu, du copywriting, une direction photo, de la traduction et la saisie dans le CMS. Une autre peut supposer que tous ces éléments seront remis prêts à intégrer.
Les deux offres peuvent être parfaitement légitimes, mais elles ne seront pas comparables.
Qui migre les anciens contenus ?
« Migration incluse » doit être précisé.
S’agit-il d’un import automatisé ? D’une reprise manuelle ? Les pages seront-elles recopiées telles quelles ou révisées ? Les images seront-elles renommées et optimisées ? Les vieux PDF sont-ils inclus ? Les métadonnées SEO sont-elles reprises ?
Sur un site important, la migration de contenu peut représenter une part considérable du budget.
C’est un poste de travail, pas une formalité.
Fonctionnalités : exprimer le besoin avant la solution
La rubrique « fonctionnalités » est souvent remplie de noms d’outils.
Chatbot. CRM. Moteur de recherche. Calculateur. Espace client. API.
Ce vocabulaire ne suffit pas.
Une fonctionnalité utile devrait être décrite sous forme de scénario.
Par exemple :
Un visiteur doit pouvoir entrer son code postal, voir les trois succursales les plus proches qui offrent le service recherché, consulter leurs heures et commencer une réservation.
Cette phrase contient beaucoup plus d’information que « store locator ».
Elle permet au prestataire de comprendre les données nécessaires, les filtres, le résultat attendu et l’action finale.
Autre exemple :
Lorsqu’une demande de soumission est envoyée, elle doit créer une opportunité dans HubSpot, associer le service demandé et attribuer le lead au représentant responsable du territoire.
Le besoin commercial est clair. L’agence peut ensuite proposer l’architecture appropriée.
Prioriser les fonctionnalités
Toutes les fonctions ne méritent pas le même statut.
Une méthode simple consiste à identifier ce qui est indispensable au lancement, ce qui est souhaitable et ce qui peut constituer une phase ultérieure.
Ce travail est particulièrement important lorsque le budget n’est pas extensible. Sans priorité, l’agence doit soit tout chiffrer, soit décider elle-même ce qu’elle retire.
Le cahier des charges doit permettre de faire des arbitrages conscients.
Intégrations, CMS et contraintes techniques
Vous n’avez pas besoin d’écrire une architecture logicielle complète.
En revanche, tout système qui doit communiquer avec le site doit être mentionné.
CRM, ERP, ATS, plateforme de réservation, outil d’infolettre, gestion documentaire, authentification, système de paiement, base de données, DAM, PIM, API interne : chacun peut modifier le niveau d’effort.
Précisez ce que vous savez de l’intégration actuelle et ce que vous attendez du futur fonctionnement.
Le simple nom de l’outil n’est pas toujours suffisant. « Intégration Salesforce » peut signifier envoyer un formulaire vers Salesforce ou construire une expérience où le site lit en temps réel des informations de compte. Les deux n’ont rien à voir en matière de complexité.
Concernant le CMS, décrivez surtout les besoins éditoriaux : qui publie, quels rôles existent, quels contenus doivent être réutilisables, si des workflows d’approbation sont requis, si plusieurs langues ou marques doivent être administrées.
Si votre entreprise n’a pas de contrainte technique réelle, laissez le prestataire recommander la plateforme et justifier son choix. Vous pourrez ensuite comparer la recommandation aux solutions déjà analysées dans notre comparatif des plateformes de création de site web.
SEO et migration : rendre les exigences explicites
Un cahier des charges de refonte qui indique simplement « site optimisé SEO » est insuffisant.
Le référencement comporte plusieurs couches : architecture, contenus, balises, maillage, données structurées, performance, indexation et migration des URL.
Lorsque le site actuel génère déjà du trafic organique, la migration doit être considérée comme un chantier à part entière.
Google recommande notamment de préparer le nouveau site, d’établir un mapping entre les anciennes et les nouvelles URL, d’implémenter les redirections appropriées puis de surveiller le trafic et Search Console après la bascule. Voir la documentation Google sur les migrations de sites.
Le cahier des charges devrait donc indiquer qui est responsable de : l’audit avant migration, l’inventaire des URL, le mapping, les redirections, les sitemaps, les balises canoniques, les données structurées, les outils analytics et la surveillance post-lancement.
Vous n’avez pas besoin d’écrire les redirections dans le cahier des charges. Vous devez préciser qu’un plan de redirection fait partie des livrables.
Cette nuance est importante : le document définit l’obligation, le travail de projet produit ensuite le détail.
Pour un projet où la visibilité organique constitue un actif important, notre guide sur la refonte de site web sans perdre son SEO détaille les contrôles à prévoir.
Performance, accessibilité, sécurité et conformité
Les exigences de qualité deviennent utiles lorsqu’elles sont testables.
« Le site doit être rapide » n’est pas testable.
Vous pouvez plutôt demander que l’agence documente les objectifs de performance, les outils de mesure et les conditions de test. Google utilise actuellement trois Core Web Vitals principaux : LCP pour le chargement, INP pour l’interactivité et CLS pour la stabilité visuelle. Google recommande notamment un LCP inférieur à 2,5 secondes, un INP inférieur à 200 ms et un CLS inférieur à 0,1 au 75e percentile. Voir la documentation Core Web Vitals.
Attention cependant à ne pas contractualiser des scores irréalistes sans définir l’environnement. Une page vide et une page remplie de vidéos, outils tiers et scripts marketing ne se comportent pas de la même manière.
Le cahier des charges doit donc surtout préciser les standards, le périmètre de responsabilité et la méthode de validation.
Accessibilité
Si une norme est nécessaire, écrivez-la explicitement.
Le W3C recommande aujourd’hui l’utilisation des WCAG 2.2 pour maximiser l’applicabilité future des efforts d’accessibilité. Les critères sont conçus pour être testables et ne dépendent pas d’une technologie particulière. Consulter WCAG 2.2.
Selon votre organisation, votre juridiction et votre secteur, d’autres obligations peuvent s’appliquer. Le cahier des charges devrait donc distinguer la norme souhaitée d’une obligation légale précise.
Sécurité et confidentialité
Évitez les phrases vagues comme « le site devra être sécurisé ».
Documentez les contraintes connues : authentification, rôles, stockage des renseignements, emplacement des données, formulaires sensibles, sauvegardes, dépendances tierces, politiques internes et processus d’incident.
Les choix détaillés peuvent rester à l’équipe technique. Les contraintes qui pourraient rendre une solution impossible doivent être connues dès le départ.
Définir les rôles, validations et responsabilités
Beaucoup de retards attribués à « l’agence » sont en réalité des retards de gouvernance.
Le design est envoyé jeudi. Personne ne sait qui doit l’approuver. Le marketing fait un commentaire, les ventes demandent autre chose, la direction veut voir une autre option et le service juridique intervient deux semaines plus tard.
Le cahier des charges devrait nommer la gouvernance du projet.
Qui est responsable au quotidien ? Qui peut prendre une décision ? Qui valide le contenu ? Qui approuve le design ? Qui donne accès aux systèmes ? Qui tranche lorsqu’il y a désaccord ?
Il faut également documenter les délais internes raisonnables.
Une agence peut bâtir un échéancier parfait, mais si chaque validation nécessite dix jours et trois comités, le lancement ne tiendra pas.
La matrice de responsabilités vaut plus qu’une réunion de lancement
Pour les projets importants, ajoutez une matrice simple.
| Sujet | Entreprise | Agence | Validation finale |
|---|---|---|---|
| Architecture | Contexte et contraintes | Recommandation | Direction marketing |
| UX/UI | Feedback | Conception | Responsable projet |
| Contenus | Expertise métier | Stratégie/rédaction selon mandat | Experts internes |
| Développement | Accès et contraintes | Réalisation | TI / projet |
| SEO migration | Données existantes | Audit et plan | Marketing |
| Mise en ligne | Approbation | Exécution | Projet + TI |
Le but n’est pas de tout bureaucratiser. C’est d’éviter le classique « je pensais que c’était vous qui vous en occupiez ».
Budget et échéancier : donner assez d’information pour obtenir un vrai chiffrage
Le budget n’est pas une information honteuse à cacher pour voir qui « devine le bon prix ».
Un même besoin peut être résolu à plusieurs niveaux d’ambition. Une agence qui connaît la fourchette peut proposer une architecture réaliste ou identifier les éléments à phaser.
Sans budget, elle doit faire une hypothèse. Vous recevrez alors des propositions qui semblent très éloignées parce qu’elles n’ont tout simplement pas imaginé le même projet.
Vous pouvez donner une fourchette plutôt qu’un plafond exact.
Précisez aussi ce que le budget doit inclure : stratégie, UX, design, développement, contenu, traduction, licences, hébergement, maintenance, migration et support post-lancement.
Les coûts récurrents devraient idéalement être séparés du coût initial.
Notre guide sur le prix d’un site web professionnel au Québec peut servir de point de référence pour comprendre ce qui fait varier les budgets.
L’échéancier doit distinguer souhait et contrainte
« Nous aimerions lancer en septembre » n’est pas la même chose que « le nouveau site doit être en ligne avant le salon du 15 septembre parce que toutes nos campagnes y renverront ».
Dites ce qui est réellement fixe.
Une bonne agence pourra alors construire le projet autour de cette contrainte ou expliquer pourquoi elle crée un risque.
Les livrables et critères de recette à prévoir
Une proposition peut utiliser l’expression « refonte complète » et pourtant ne pas inclure ce que vous imaginez.
Le cahier des charges doit donc décrire les livrables attendus.
Selon le mandat, ils peuvent comprendre stratégie, sitemap, wireframes, prototypes, design system, gabarits, code, intégrations, contenus, plan de redirection, documentation, formation et période de garantie.
Mais la partie la plus intéressante est souvent la recette : comment allez-vous décider que le site peut être accepté et mis en ligne ?
Définissez les grands critères.
Les formulaires doivent envoyer les données au bon système. Le site doit fonctionner sur les navigateurs ciblés. Les redirections critiques doivent être testées. Les pages prévues doivent être intégrées. Les événements analytics doivent remonter. Les rôles CMS doivent fonctionner. Les défauts bloquants doivent être corrigés.
Le cahier des charges n’a pas besoin de contenir les 250 cas de test. Il doit exiger qu’une phase de QA et de recette existe et préciser ce qui constitue un défaut bloquant.
Un site techniquement accessible à une URL de production n’est pas nécessairement terminé.
Qui entre les derniers contenus ? Qui configure les redirections ? Qui rebranche les pixels ? Qui remet les accès ? Qui forme l’équipe ? Qui surveille la première semaine ?
Les conditions de fin de projet devraient être suffisamment claires pour éviter que le lancement devienne un transfert précipité de tâches non prévues.
Le modèle complet de cahier des charges à adapter
Le modèle suivant peut servir de trame. Il ne faut pas le remplir comme un formulaire administratif. Supprimez ce qui n’est pas pertinent et développez les rubriques qui influencent réellement votre projet.
1. Présentation de l’entreprise et contexte
Présentez l’activité, les marchés, les principales offres, les utilisateurs du site et le déclencheur du projet. Expliquez surtout ce qui ne fonctionne plus aujourd’hui.
2. Objectifs du projet
Décrivez les résultats recherchés et, lorsque possible, les indicateurs actuels qui serviront de point de comparaison.
3. Utilisateurs et parcours
Identifiez les groupes prioritaires, leurs besoins et les actions que le site doit leur permettre d’accomplir.
4. État actuel
Indiquez les plateformes, volumes, langues, types de contenu, intégrations, outils de mesure et problèmes connus.
5. Périmètre éditorial
Décrivez les principales familles de pages et de contenus. Précisez ce qui doit être conservé, réécrit, créé ou migré.
6. Fonctionnalités
Décrivez les scénarios importants plutôt que seulement des noms d’outils. Identifiez les fonctions obligatoires et celles qui peuvent être phasées.
7. Intégrations et contraintes techniques
Listez les systèmes concernés, les données échangées lorsque vous les connaissez et les contraintes d’hébergement, d’authentification ou d’infrastructure.
8. SEO et migration
Définissez les responsabilités relatives à l’audit, au mapping des URL, aux redirections, aux balises, aux données structurées, aux sitemaps et au suivi post-lancement.
9. Performance, accessibilité et sécurité
Indiquez les standards attendus et la méthode de validation, sans inventer des exigences techniques que vous ne savez pas justifier.
10. Contenus et responsabilités
Précisez qui rédige, photographie, traduit, approuve, migre et intègre.
11. Gouvernance du projet
Nommez le responsable, les décideurs, les personnes consultées, les délais de validation et les dépendances internes.
12. Budget et calendrier
Présentez la fourchette, les postes à inclure, les coûts récurrents attendus et les dates réellement contraignantes.
13. Livrables et recette
Décrivez ce qui doit être remis, la formation, la documentation, les tests, la garantie et les critères permettant d’accepter le projet.
14. Réponse attendue du prestataire
Si le document est utilisé pour consulter des agences, demandez une réponse structurée : compréhension du mandat, méthode, équipe, échéancier, hypothèses, exclusions, prix, coûts récurrents et références pertinentes.
Ce dernier point facilite énormément la comparaison avec les éléments que nous recommandons de vérifier dans une soumission de site web.
Les erreurs qui rendent un cahier des charges inutile
La première erreur est de commencer par une solution technique et de remonter ensuite artificiellement vers le besoin. Si le document impose déjà le CMS, les plugins, l’arborescence, les modules et la mise en page de chaque écran, l’agence n’est plus vraiment invitée à concevoir. Elle chiffre une exécution.
La deuxième erreur est l’inverse : rester tellement vague que toute interprétation devient possible. « Site moderne, intuitif, rapide et SEO-friendly » ne constitue pas un périmètre.
La troisième est d’oublier les contenus. Un projet de site web n’est jamais seulement un ensemble de gabarits vides. Quelqu’un doit produire, réviser, approuver et intégrer la matière qui leur donne une valeur.
La quatrième est de traiter la migration comme une opération technique de dernière minute. Une refonte qui remplace les URL, les contenus et les outils de mesure doit disposer d’un plan de transition explicite.
La cinquième est d’écrire le document sans les équipes qui dépendront du futur site. Les exigences découvertes en milieu de projet coûtent beaucoup plus cher que les questions posées au début.
Enfin, évitez de considérer le cahier des charges comme un texte figé que personne ne peut remettre en question. Une bonne agence doit pouvoir signaler une contradiction, suggérer une simplification et proposer une alternative. Le document crée un cadre de décision ; il ne doit pas empêcher la découverte.
Un cahier des charges utile ne doit pas donner l’illusion que le projet est déjà conçu.
Chez PRAGMATIK, nous préférons un document qui expose clairement les objectifs, les contraintes, les responsabilités et les zones d’incertitude plutôt qu’un cahier de cinquante pages rempli de décisions techniques prises trop tôt.
Le meilleur signe de maturité n’est pas d’avoir une réponse à tout. C’est de savoir distinguer ce qui est non négociable de ce qui doit encore être étudié.
Cette approche produit généralement de meilleurs projets pour une raison simple : elle permet à l’entreprise de garder le contrôle sur le pourquoi et le quoi, tout en laissant aux spécialistes la responsabilité du comment.
Avant de parler de plateforme, de design ou de fonctionnalités, nous cherchons donc à répondre à quatre questions : quel problème le site doit-il résoudre, qui doit-il servir, qu’est-ce qui pourrait faire échouer le projet et comment reconnaîtrons-nous qu’il a réussi ?
Le reste du cahier des charges devient alors beaucoup plus facile à écrire.
Découvrir notre approche de conception et refonte de sites web
Lire aussi
- Soumission de site web : à quoi s’attendre, comment la lire et les red flags à repérer
- Prix d’un site web professionnel au Québec : fourchettes réelles et facteurs de coût
- Refonte de site web : comment savoir quand le faire — et comment le faire sans perdre votre SEO
- Meilleures plateformes de création de site web en 2026 : comparatif complet
FAQ — Cahier des charges pour un site web
Est-ce qu’un cahier des charges est obligatoire pour créer un site web ?
Non. Un petit projet peut être très bien cadré avec un brief et quelques ateliers. Le cahier des charges devient particulièrement utile lorsque plusieurs décideurs, fonctionnalités, intégrations, contenus ou contraintes doivent être coordonnés, ou lorsque plusieurs prestataires doivent chiffrer le même projet.
Combien de pages doit faire un cahier des charges web ?
Il n’existe pas de longueur idéale. Pour une PME avec un projet relativement classique, quelques pages bien écrites peuvent suffire. Un projet complexe peut nécessiter des annexes techniques, un inventaire de contenu ou une documentation d’intégration. La qualité du cadrage compte davantage que le nombre de pages.
Qui doit rédiger le cahier des charges ?
Le document peut être rédigé par le responsable marketing ou numérique, par une équipe projet ou avec l’aide d’une agence-conseil. L’important est que les fonctions concernées participent à l’identification des besoins et des contraintes. Le prestataire retenu peut ensuite challenger et préciser le document pendant le cadrage.
Faut-il choisir le CMS dans le cahier des charges ?
Seulement si le choix est une vraie contrainte. Si votre entreprise doit utiliser une plateforme pour des raisons de sécurité, d’écosystème ou de gouvernance, indiquez-le. Sinon, décrivez les besoins éditoriaux et techniques puis demandez au prestataire de recommander une solution et de justifier son choix.
Faut-il inclure une arborescence complète ?
Une première architecture est utile, mais elle peut être présentée comme une hypothèse à valider. Si la conception UX et la stratégie de contenu font partie du mandat, figer toute l’arborescence à l’avance peut être contre-productif. Documentez surtout les contenus et parcours incontournables.
Comment décrire les fonctionnalités sans être technique ?
Décrivez ce que l’utilisateur doit pouvoir faire, ce qui doit se produire et quelles données sont impliquées. Par exemple : « un candidat doit pouvoir filtrer les postes par région et envoyer sa candidature dans notre ATS ». Le prestataire pourra ensuite proposer la solution technique.
Que faut-il prévoir pour le SEO dans un cahier des charges ?
Pour une refonte, indiquez au minimum les responsabilités concernant l’audit de l’existant, le mapping des URL, les redirections, les métadonnées, les données structurées, le sitemap, Search Console et le suivi après lancement. La mention générique « SEO-friendly » est insuffisante.
Faut-il indiquer le budget ?
Dans la plupart des consultations privées, oui. Une fourchette permet au prestataire de proposer un niveau de solution cohérent et de phaser les éléments moins prioritaires. Sans indication, chaque agence peut imaginer un niveau d’ambition différent.
Qu’est-ce qu’un critère de recette ?
Un critère de recette décrit ce qui doit être vérifié pour considérer le livrable conforme : fonctionnement des formulaires, intégrations, redirections, rôles CMS, compatibilité des navigateurs, analytics, performance ou accessibilité. Il transforme une attente vague en contrôle concret.
Quelle est la différence entre un cahier des charges et un contrat ?
Le cahier des charges décrit le besoin et le périmètre. Le contrat définit la relation juridique, les engagements, les modalités de paiement, la propriété intellectuelle, les responsabilités et les conditions de fin ou de modification. Le cahier des charges peut être annexé au contrat et devenir une référence du projet, mais il ne remplace pas le contrat.