Cahier des charges d’un site web : le modèle qui évite les surprises

Un client m’envoie un brief de trois lignes : « je veux un site comme celui de mon concurrent, mais mieux, avec un espace client, prêt pour la rentrée ». Trois semaines plus tard, le devis part en révision pour la troisième fois parce que personne n’avait défini si « espace client » signifiait un simple formulaire de contact ou un back-office avec authentification, facturation et historique de commandes. C’est exactement ce que le cahier des charges est censé éviter, et c’est exactement ce qui arrive quand on le rédige comme une formalité plutôt que comme un outil de cadrage.

Un cahier des charges n’est pas un exercice de style ni un document juridique de 40 pages. C’est la liste précise de ce que le site doit faire, pour qui, avec quelles contraintes, et comment on saura que c’est terminé. Sans ça, le développeur devine, le client corrige en cours de route, et les deux perdent du temps sur des allers-retours qui auraient pu être évités en une heure de rédaction en amont.

Ce que coûte un cahier des charges bâclé

Le problème n’est jamais visible au moment du devis, il apparaît trois semaines après le début du développement. Un client valide une maquette, puis découvre en recette que le formulaire de contact devait en réalité envoyer les leads vers son CRM, ou que le catalogue produit devait gérer des variantes de couleur non prévues au départ. Chaque ajout non cadré au départ déclenche soit un avenant au devis, soit un développeur qui absorbe le delta sur sa marge — ce qui, à terme, dégrade la qualité du travail livré.

Le cahier des charges sert précisément à sortir ces questions avant le premier devis, pas après la première facture. C’est aussi la pièce qui protège les deux parties en cas de litige sur le périmètre : si une fonctionnalité n’y figure pas, elle n’était pas comprise dans le prix initial.

Les rubriques qui doivent obligatoirement apparaître

Un cahier des charges utile tient sur trois à six pages, pas plus. Voici les sections qui ne doivent jamais manquer :

• Contexte et objectif business — pourquoi ce site existe, quel problème il résout (générer des devis, vendre en ligne, remplacer un site vieillissant), et pour qui.
• Cible et usages — qui visite le site, depuis quel device en majorité, avec quelle intention (comparer, acheter, prendre rendez-vous).
• Périmètre fonctionnel — la liste exhaustive des pages et fonctionnalités : nombre de pages type, formulaires, espace client, moteur de recherche interne, filtres produits, prise de rendez-vous, multilingue.
• Arborescence — même sommaire, un plan du site évite les découvertes de dernière minute sur la profondeur de navigation attendue.
• Contraintes techniques — CMS imposé ou non, hébergeur existant, intégrations obligatoires (ERP, CRM, solution de paiement, outil de facturation), volumétrie de données.
• Identité visuelle — charte graphique existante ou à créer, exemples de sites dont le style plaît (et pourquoi), contenus déjà rédigés ou à produire.
• Exigences SEO et performance — mots-clés cibles si connus, migration d’URLs existantes à préserver, seuil de performance attendu (un score PageSpeed mobile 90+ n’est pas un vœu pieux, c’est un objectif technique mesurable dès la conception).
• Budget et délai — même une fourchette large aide le prestataire à proposer une solution réaliste plutôt qu’à deviner.
• Critères de réception — ce qui doit être vrai pour que le projet soit considéré comme livré : tests sur quels navigateurs, formation à l’administration, documentation, garantie post-lancement.

Le modèle section par section, prêt à remplir

Concrètement, un cahier des charges qui fonctionne suit cette trame, dans cet ordre :

1. Présentation de l’entreprise et du projet (5 lignes suffisent)
2. Objectifs mesurables (nombre de leads, taux de conversion visé, remplacement d’un existant qui ne convertit plus)
3. Public cible et parcours utilisateur principal
4. Liste des pages et fonctionnalités, classées en « indispensable » et « souhaitable »
5. Arborescence proposée
6. Contraintes techniques et intégrations tierces
7. Éléments graphiques disponibles (logo, charte, photos, contenus)
8. Attentes SEO et performance
9. Budget indicatif et délai souhaité
10. Modalités de validation et de réception

La colonne « indispensable / souhaitable » de l’étape 4 est celle qui évite le plus de désaccords : elle force à trancher avant le développement plutôt que pendant.

Site vitrine ou refonte : le cahier des charges n’est pas le même

Pour un premier site, le cahier des charges part d’une feuille blanche : il faut définir l’arborescence complète et les contenus depuis zéro, ce qui est le cas typique d’un site vitrine pour une TPE qui n’a pas encore de présence en ligne structurée. Le document doit alors insister sur les objectifs business et le parcours de conversion, puisque rien n’existe encore à mesurer.

Pour une refonte de site web, la logique s’inverse : le cahier des charges doit d’abord documenter l’existant — ce qui fonctionne, ce qui ne fonctionne pas, les URLs à conserver pour ne pas perdre le référencement acquis, les statistiques de trafic actuelles. Une refonte mal cadrée est la cause la plus fréquente de perte de trafic organique après mise en ligne, précisément parce que personne n’a listé les pages à rediriger avant le lancement.

Qui doit rédiger le cahier des charges, et combien de temps y consacrer

Ce n’est pas au développeur de l’écrire à la place du client : lui seul connaît ses objectifs business, ses contraintes internes et ses priorités. En revanche, un développeur expérimenté doit être capable de le relire, de pointer les zones floues et de reformuler les besoins en spécifications techniques exploitables. Compter une à deux heures de rédaction pour un site vitrine standard, une demi-journée pour un projet e-commerce ou une refonte avec migration de données.

Ce temps n’est jamais perdu : chaque heure passée à clarifier le périmètre en amont évite plusieurs heures d’allers-retours pendant le développement, au moment où les corrections coûtent le plus cher.

L’impact direct sur le devis et le budget

Un cahier des charges précis permet un devis précis. À l’inverse, un brief flou oblige le prestataire soit à surestimer par prudence, soit à sous-estimer et à facturer des avenants en cours de route — la pire option pour la relation de confiance. Les tarifs d’un développeur freelance varient fortement selon la complexité réelle du projet : consulter les tarifs d’un développeur freelance WordPress donne un ordre d’idée des fourchettes de prix selon le type de site, mais seul un cahier des charges détaillé permet de savoir dans quelle fourchette un projet donné se situe réellement.

Un budget donné sans périmètre associé (« j’ai 3000 euros ») est presque aussi inutile qu’un périmètre donné sans budget : le prestataire ne peut pas dire si les deux sont compatibles tant qu’il ne connaît pas les deux en même temps.

Les erreurs qui reviennent le plus souvent

• Copier le cahier des charges d’un concurrent sans l’adapter — il reflète les choix d’une autre entreprise, pas les contraintes propres au projet.
• Décrire une solution plutôt qu’un besoin — écrire « il faut un slider en page d’accueil » au lieu de « il faut mettre en avant trois offres phares » prive le développeur de sa capacité à proposer une solution plus performante.
• Oublier les contenus — textes, photos, vidéos sont souvent la vraie cause de retard, bien plus que le développement lui-même.
• Ne pas chiffrer les priorités — sans hiérarchie claire entre indispensable et souhaitable, tout finit dans la version 1, ce qui gonfle le budget et le délai.
• Négliger la maintenance — qui mettra à jour le site après la livraison, avec quelle autonomie, n’est presque jamais précisé alors que cela conditionne le choix technique (CMS avec back-office ou site statique).

FAQ

Un cahier des charges est-il obligatoire pour un petit site vitrine ?

Il n’est pas obligatoire au sens légal, mais il reste fortement recommandé même pour trois ou quatre pages. Un document d’une page suffit dans ce cas : objectif du site, liste des pages, contenus disponibles et délai souhaité. L’essentiel est d’écrire noir sur blanc ce qui est attendu, pas la longueur du document.

Faut-il un cahier des charges différent pour WordPress, PrestaShop ou Shopify ?

La structure du document reste identique quel que soit le CMS visé : objectifs, périmètre, contraintes, budget. Ce qui change, ce sont les contraintes techniques à préciser — gestion des extensions et de la sécurité pour WordPress, gestion des stocks et des moyens de paiement pour PrestaShop ou Shopify. Le choix du CMS lui-même peut d’ailleurs découler du cahier des charges plutôt que le précéder, si le prestataire est consulté suffisamment tôt.

Le cahier des charges peut-il évoluer en cours de projet ?

Oui, mais chaque évolution doit être tracée et validée par les deux parties, avec un impact chiffré sur le délai ou le budget si nécessaire. Un cahier des charges figé à 100 % dès le départ est rarement réaliste ; ce qui compte, c’est que les changements passent par un avenant explicite plutôt que par des demandes informelles glissées dans un email au fil de l’eau.

Un cahier des charges qui tient sur quelques pages bien remplies vaut mieux qu’un document exhaustif jamais terminé. Si vous avez besoin d’aide pour le structurer avant de lancer votre projet, une demande de devis détaillé permet d’obtenir un retour concret sous 48 heures sur la faisabilité et le budget associés.