Le cahier des charges web : un rituel que personne ne remet en question
Si vous tapez “cahier des charges site web” dans Google, vous allez tomber sur des dizaines de templates. Des PDF de 30 pages. Des modèles Word avec des sections comme “Architecture technique de la solution” et “Spécifications fonctionnelles détaillées niveau 3”. Le tout présenté comme un passage obligé, une étape fondamentale, le socle de tout projet sérieux.
J’ai une question : combien de ces documents avez-vous réellement lus en entier ?
Après 10 ans à concevoir et développer des sites et applications web — pour des TPE, des PME, des startups et quelques grands comptes —, j’ai accumulé un constat que je n’ai plus envie de garder pour moi. La grande majorité des cahiers des charges web sont une perte de temps colossale. Pas parce que l’idée de cadrer un projet est mauvaise. L’idée est excellente. Mais parce que la manière dont on le fait depuis 20 ans ne fonctionne pas. Et tout le monde le sait. Personne n’ose le dire à voix haute.
Aujourd’hui, je le dis.
Ce que j’ai vu en 10 ans de projets web
Je ne parle pas de théorie. Je parle de projets réels, avec de vrais budgets, de vraies deadlines et de vraies conséquences quand ça rate.
Voici ce que j’ai observé, projet après projet :
- Des cahiers des charges de 50 pages rédigés en 3 semaines, périmés avant le premier développement
- Des spécifications fonctionnelles si détaillées qu’elles décrivaient des boutons qui n’existeraient jamais
- Des clients qui payaient un consultant pour rédiger un document que ni eux ni le prestataire ne relirait jamais intégralement
- Des projets parfaitement spécifiés qui livraient un produit que personne ne voulait utiliser
- Des projets “mal cadrés” sur un coin de table qui marchaient mieux que les projets rigoureusement documentés
Le paradoxe est cruel : plus le cahier des charges est épais, plus le projet a de chances de dériver.
Pourquoi le cahier des charges classique ne fonctionne pas
Personne ne le lit. Vraiment personne.
Soyons honnêtes. Un cahier des charges site internet de 40 pages, rédigé dans un langage semi-technique, rempli de sections génériques copiées-collées d’un template — personne ne le lit mot par mot. Le client le survole. Le développeur cherche les pages qui le concernent. Le designer regarde les maquettes s’il y en a.
J’ai fait un test informel avec des collègues prestataires web : sur un document de 35 pages, la plupart lisent attentivement les 5 premières, survolent le milieu, et s’arrêtent sur le budget à la fin. C’est humain. C’est aussi un problème.
Quand votre document de référence n’est pas lu, il ne sert à rien. Pire : il donne une fausse impression de contrôle.
Le monde change pendant que vous spécifiez
Un cahier des charges web sérieux prend 2 à 6 semaines à rédiger. Pendant ce temps :
- Votre concurrent lance une nouvelle offre
- Vous réalisez que la fonctionnalité phare n’est pas ce que vos clients demandent le plus
- Votre budget change
- Vous embauchez quelqu’un qui a une meilleure idée pour le workflow interne
- Google met à jour ses critères de référencement
Le document que vous finissez de rédiger en mars décrit le projet que vous aviez en tête en janvier. Pas celui dont vous avez besoin en avril quand le développement commence.
Les spécifications projet web figées dans le marbre sont une illusion de contrôle. Le terrain bouge. Les besoins évoluent. Et c’est normal.
La fausse sécurité juridique
“Mais le cahier des charges, c’est un document contractuel ! Si le prestataire ne livre pas ce qui est écrit, on est couvert.”
En théorie, oui. En pratique, les litiges sur des projets web se règlent rarement devant un tribunal avec un cahier des charges comme pièce à conviction. Et quand c’est le cas, le résultat est rarement satisfaisant pour quiconque.
Ce que j’ai vu à la place : des prestataires qui livrent exactement ce qui est écrit dans le cahier des charges — et un client mécontent parce que ce n’est pas ce qu’il voulait. Le document était respecté à la lettre. L’esprit du projet, lui, avait été perdu quelque part entre la section 4.2.3 et l’annexe B.
Le vrai contrat de confiance ne tient pas dans un document de 50 pages. Il tient dans la qualité de la communication entre vous et votre prestataire.
Le syndrome du “pendant qu’on y est”
Les cahiers des charges longs ont un effet pervers : ils encouragent l’ajout de fonctionnalités. Puisqu’on est en train de tout spécifier, autant tout prévoir. Un espace membre. Un blog. Un système de notifications. Une version multilingue. Un chat en direct.
J’appelle ça le “syndrome du pendant qu’on y est”. Chaque section ajoutée au document donne l’impression d’avancer. En réalité, vous augmentez la complexité, le budget, les délais — et la probabilité d’échec.
Un bon cadrage de projet devrait vous forcer à retirer des choses, pas à en ajouter.
Ce que font les projets qui réussissent
J’ai vu des projets livrer en temps et en budget un produit que les utilisateurs adoptent spontanément. Ces projets n’avaient pas de cahier des charges de 50 pages. Ils avaient autre chose.
Un problème clairement identifié (en une phrase)
Les projets qui réussissent commencent par une phrase simple que tout le monde comprend. Pas un chapitre de contexte stratégique. Une phrase.
Exemples que j’ai vus fonctionner :
- “Nos clients ne trouvent pas nos tarifs et appellent pour les demander. On veut qu’ils trouvent tout en ligne.”
- “On perd 3 heures par jour à traiter des demandes de devis par e-mail. On veut automatiser la prise de contact.”
- “Notre site a 7 ans. Il fait fuir les prospects. On veut un site qui reflète ce qu’on est devenu.”
Si vous ne pouvez pas résumer votre projet web en une phrase, vous n’êtes pas prêt à le lancer. Et aucun cahier des charges site internet de 40 pages ne comblera ce manque.
Des user stories, pas des spécifications techniques
Au lieu de décrire “Le système doit disposer d’un formulaire de contact multi-étapes avec validation côté serveur et envoi asynchrone via API REST”, dites simplement :
“En tant que visiteur, je veux pouvoir envoyer une demande de devis avec mon nom, mon e-mail et une description de mon besoin, pour recevoir une réponse sous 24h.”
C’est une user story. C’est compréhensible par tout le monde : le client, le développeur, le designer, le stagiaire. C’est vérifiable : soit le visiteur peut faire cette action, soit il ne peut pas.
Un projet bien cadré peut tenir en 10 à 20 user stories. Pas 50 pages.
Voici la structure que j’utilise avec mes clients :
- En tant que [type d’utilisateur]
- Je veux [action concrète]
- Pour [bénéfice attendu]
C’est simple. C’est puissant. Et surtout, c’est facile à prioriser : on trie les user stories par impact et on commence par les plus importantes.
Un prototype plutôt qu’un roman
Un wireframe ou un prototype interactif vaut 10 000 mots de spécifications. Quand je montre à un client un prototype cliquable de son futur site, les retours arrivent en 10 minutes. Pas en 10 jours de relecture.
Les outils existent : Figma, Penpot, ou même des croquis papier photographiés. Le support importe peu. Ce qui compte, c’est de rendre le projet tangible le plus vite possible.
Un cahier des charges décrit ce qu’on imagine. Un prototype montre ce qu’on va obtenir. La différence est fondamentale.
J’ai vu des projets où le client validait des pages entières de spécifications textuelles, puis tombait des nues en voyant le résultat visuel. “Ce n’est pas ce que j’avais en tête.” Bien sûr que non. Parce que le texte est ambigu. L’image ne l’est pas.
Une livraison itérative, pas un big bang
Les projets qui fonctionnent ne livrent pas tout d’un coup 6 mois après le début. Ils livrent en étapes :
- Semaine 1-2 : Page d’accueil + page de contact fonctionnelles en ligne
- Semaine 3-4 : Pages services + formulaire de devis
- Semaine 5-6 : Blog + optimisation SEO + ajustements visuels
Chaque étape est utilisable. Testable. Corrigeable. Le client voit le produit évoluer. Il peut ajuster le tir sans réécrire un document de 30 pages.
C’est l’approche itérative. Ce n’est pas nouveau — le monde du logiciel l’utilise depuis 20 ans. Mais dans le monde des sites web pour TPE et PME, on continue à fonctionner comme si on construisait un pont : plan complet d’abord, construction ensuite, inauguration à la fin.
Un site web n’est pas un pont. Un site web est un produit vivant qui évolue avec votre activité.
Ce que devrait contenir un vrai cadrage de projet web
Je ne dis pas qu’il faut se lancer sans rien. Le chaos total ne fonctionne pas mieux que la bureaucratie. Voici ce que j’utilise avec mes clients, et qui tient sur 2 à 4 pages maximum.
1. Le contexte en 5 lignes
Qui êtes-vous. Ce que vous faites. Pourquoi un site web (ou un nouveau site). Quel problème on résout. C’est tout.
2. Les objectifs mesurables (3 maximum)
Pas “améliorer notre visibilité en ligne”. Plutôt :
- Passer de 0 à 20 demandes de devis par mois via le site
- Réduire les appels téléphoniques de 50% grâce à une FAQ complète
- Apparaître en première page Google sur “plombier Lyon 3”
Trois objectifs. Mesurables. Vérifiables dans 3 mois.
3. Les user stories prioritaires (10-15 max)
La liste des choses que les utilisateurs doivent pouvoir faire, triées par importance. On attaque les 5 premières. Le reste viendra après.
4. Les contraintes réelles
- Budget : fourchette honnête, pas “on verra”
- Délai : date de lancement souhaitée et pourquoi
- Contraintes techniques : hébergement existant, nom de domaine, outils en place
- Contenu : qui fournit les textes et les photos, et quand
5. Ce qui est explicitement hors périmètre
Aussi important que le périmètre lui-même. Écrire noir sur blanc “pas de version multilingue pour le moment” ou “pas d’espace client dans cette version” évite 80% des dérives de projet.
C’est tout. Quatre à cinq sections. Deux à quatre pages. Lisible en 10 minutes. Compréhensible par tous.
Les vrais signaux d’un projet bien cadré
Vous voulez savoir si votre projet web est bien cadré ? Ne regardez pas l’épaisseur du document. Regardez ces indicateurs :
Le porteur du projet peut expliquer le site en 30 secondes. Pas le cahier des charges. Le site. Ce qu’il fait, pour qui, pourquoi. Si cette explication est confuse, le cahier des charges le sera aussi — même en 80 pages.
Tout le monde est d’accord sur les 3 priorités. Le dirigeant, le responsable marketing, le prestataire web. Si chacun a une vision différente de la priorité numero un, aucun document ne résoudra ce désalignement.
Les premiers retours arrivent en jours, pas en semaines. Un prototype montré en 5 jours génère plus de clarté qu’un document relu pendant 3 semaines. Si votre prestataire disparaît pendant 2 mois avant de montrer quoi que ce soit, c’est un problème de méthode, pas de spécifications.
Le budget est discuté ouvertement. Un cahier des charges qui n’inclut pas de discussion budgétaire honnête est un exercice théorique. Les contraintes financières façonnent les choix. Les ignorer dans le cadrage, c’est construire un plan déconnecté de la réalité.
”Mais mon prestataire me demande un cahier des charges”
Oui, et c’est normal. Un prestataire a besoin de comprendre votre projet pour chiffrer et s’engager. La question n’est pas “faut-il un document ?” mais “quel document ?”
Si votre prestataire vous envoie un template de 30 pages à remplir avec des sections comme “Architecture réseau” et “Matrice de traçabilité des exigences” pour un site vitrine, posez-vous une question : est-ce que ce prestataire comprend votre réalité ?
Un bon prestataire web pour une TPE ou PME devrait :
- Vous poser les bonnes questions en entretien (pas vous envoyer un formulaire)
- Vous aider à formuler vos besoins (pas attendre que vous les spécifiiez seul)
- Vous montrer rapidement à quoi ça va ressembler (pas rédiger pendant 3 semaines)
- Vous proposer un périmètre clair et priorisé (pas une liste infinie de fonctionnalités)
Le cadrage d’un projet web est une collaboration, pas un devoir maison que le client rend au prestataire.
Les cas où un vrai cahier des charges se justifie
Je ne suis pas dogmatique. Il y a des situations où un cahier des charges site internet détaillé a du sens :
- Appels d’offres publics : c’est le format imposé, point final
- Projets complexes multi-prestataires : quand 4 équipes doivent se coordonner sur un extranet avec 200 fonctionnalités, un document de référence détaillé est nécessaire
- Systèmes critiques : une application bancaire, un logiciel médical — la rigueur des spécifications est justifiée par les risques
- Grands comptes avec processus internes : parfois, le document sert autant à convaincre en interne qu’à cadrer le projet
Mais si vous êtes une TPE de 5 personnes qui veut un site vitrine ou un petit e-commerce, un cahier des charges de 50 pages est un canon pour tuer une mouche.
L’alternative en pratique : un exemple concret
Prenons un cas réel (anonymisé). Une entreprise de services à domicile, 8 salariés, pas de site web.
L’approche cahier des charges classique aurait donné :
Un document de 25 pages. 4 semaines de rédaction. Des sections sur “l’écosystème digital de l’entreprise” et “la stratégie de contenu multicanal”. Budget de rédaction : 2000 euros payés à un consultant. Le développement n’a pas encore commencé.
L’approche que j’ai utilisée :
Un entretien d’une heure. Un document de 3 pages avec : contexte (5 lignes), 3 objectifs mesurables, 12 user stories classées par priorité, contraintes (budget, délai, contenu), et hors périmètre explicite.
Un prototype Figma livré en 3 jours. Retours du client le lendemain. Ajustements en 2 heures.
Première version en ligne en 2 semaines. Deuxième itération avec formulaire de devis et pages services 2 semaines plus tard. Le client a commencé à recevoir des demandes de devis via son site avant même que la version 2 ne soit terminée.
Temps total de cadrage : 1 jour. Contre 4 semaines minimum avec l’approche traditionnelle.
Résumé : ce qu’il faut retenir
- Un cahier des charges web long n’est pas un signe de sérieux. C’est souvent un signe de confusion.
- Les documents que personne ne lit ne protègent personne.
- Les spécifications figées ne survivent pas au contact avec la réalité.
- L’alternative existe : un cadrage court, des user stories claires, un prototype rapide, une livraison itérative.
- Le meilleur cadrage est une conversation structurée, pas un roman technique.
La question n’est pas “comment rédiger un bon cahier des charges web ?” La question est “comment cadrer un projet web pour qu’il réussisse ?” Et la réponse, dans 90% des cas, ne passe pas par un document de 50 pages.
Vous avez un projet web à cadrer ?
C’est exactement l’approche que j’applique avec les TPE et PME que j’accompagne. Un cadrage pragmatique, un prototype rapide, une livraison par étapes. Pas de jargon. Pas de documents-fleuve. Des résultats concrets.
Si vous cherchez un accompagnement pour créer votre site web sans passer par la case bureaucratie, parlons-en. Un premier échange de 30 minutes suffit souvent à y voir clair.