Il y a deux types de projets qui dérapent : ceux qui n'ont aucun cadrage, et ceux dont le cahier des charges est si exhaustif qu'il n'a plus rien à voir avec la réalité au bout de trois semaines.
Un bon cahier des charges technique n'est pas un document de 80 pages. C'est un outil de travail partagé qui permet à votre équipe — interne ou externe — de comprendre ce qu'on construit, pourquoi, et comment on sait qu'on a réussi.
Pourquoi la plupart des cahiers des charges ne servent à rien
Trois raisons reviennent systématiquement.
La première : il décrit des solutions, pas des problèmes. On liste des fonctionnalités sans expliquer le besoin qu'elles couvrent. Résultat : le prestataire livre exactement ce qui est écrit, mais ce n'est pas ce dont l'utilisateur avait besoin.
La deuxième : il est trop figé. Un cahier des charges qui prétend tout anticiper est un document qui sera périmé au premier contact avec la réalité. Le développement produit est itératif. Le cadrage doit l'être aussi.
La troisième : il n'est pas lu. Un document de 80 pages coûte 3 semaines à produire et est lu en diagonale. Ce n'est pas un cahier des charges, c'est une garantie de malentendu.
Ce qu'un bon cahier des charges doit contenir
1) Le contexte et les objectifs business
C'est la section la plus importante — et la plus souvent absente. Avant de décrire ce qu'on construit, expliquez pourquoi.
- Quel problème ce produit résout-il ?
- Pour qui exactement (persona précis, pas "les utilisateurs") ?
- Quel est le résultat attendu à 3 et 6 mois ?
- Quel est le critère de succès principal ?
Cette section permet à n'importe quel membre de l'équipe de prendre une décision cohérente sans vous consulter à chaque bifurcation.
2) Les parcours utilisateurs prioritaires
Décrivez les flux critiques sous forme de scénarios, pas de listes de fonctionnalités.
Exemple :
"Un utilisateur arrive sur la page d'accueil, s'inscrit via son email, remplit son profil en 3 étapes, puis accède au tableau de bord principal. Il peut ensuite créer son premier projet en moins de 2 minutes."
Ce format est bien plus utile qu'une liste de cases à cocher parce qu'il place le développeur dans la peau de l'utilisateur. Il permet aussi d'identifier immédiatement les décisions techniques structurantes : authentification, onboarding, rôles, gestion des états.
3) Les contraintes techniques non négociables
Ce ne sont pas les contraintes souhaitables, mais celles qui conditionnent réellement l'architecture :
- stack existante à respecter ou à intégrer
- hébergement imposé (cloud souverain, on-premise)
- conformité réglementaire (RGPD, HDS, PCI-DSS)
- SLA ou exigences de disponibilité
- intégrations obligatoires avec des systèmes existants
Tout ce qui n'est pas listé ici est une liberté laissée à l'équipe technique — et c'est souvent la bonne chose à faire.
4) Le périmètre de la V1 — et ce qui est hors périmètre
C'est l'une des sections les plus utiles : ce qu'on ne fait pas.
Lister explicitement les fonctionnalités exclues de la première version évite les malentendus les plus coûteux. "On ne gère pas les notifications push dans cette version" ou "la gestion multi-langue est hors périmètre V1" sont des phrases qui font gagner des semaines.
| In V1 | Hors V1 |
|---|---|
| Inscription et connexion | Connexion via réseaux sociaux |
| Création de projet | Partage de projet avec un tiers |
| Tableau de bord basique | Reporting avancé et export |
| Paiement abonnement mensuel | Facturation annuelle et codes promo |
5) Les critères d'acceptance
Pour chaque fonctionnalité ou parcours principal, définissez comment vous saurez que c'est terminé et conforme.
Un critère d'acceptance, c'est une phrase concrète et testable :
- "L'utilisateur peut s'inscrire avec un email valide en moins de 3 clics."
- "Un email de confirmation est envoyé dans les 30 secondes suivant l'inscription."
- "En cas d'erreur de connexion, un message explicite s'affiche sans redirection."
Ces critères protègent les deux parties : ils évitent les litiges sur "c'est livré ou pas livré" et donnent une base commune pour les recettes.
Ce qu'on ne met pas dans un cahier des charges
Les détails d'implémentation
"Utiliser PostgreSQL avec des indexes sur les colonnes user_id et created_at" n'a pas sa place dans un cahier des charges sauf si vous avez une contrainte technique forte. Ces décisions appartiennent à l'équipe technique — c'est pour ça qu'on la paie.
Les maquettes finales
Les maquettes sont un livrable de design, pas un cahier des charges. Les inclure prématurément dans le document crée deux problèmes : elles figent des choix UX avant qu'on ait validé les parcours, et elles donnent l'impression que le travail de design est fait alors qu'il n'a pas encore été pensé.
Des wireframes schématiques sont suffisants à ce stade, si besoin. Notre offre de prototypage UX permet justement de valider les parcours avant le développement.
Les fonctionnalités "au cas où"
Chaque fonctionnalité dans le cahier des charges finit dans le devis. Chaque fonctionnalité dans le devis finit dans le backlog. Chaque fonctionnalité dans le backlog est une décision de priorité que vous devrez gérer.
Soyez radical dans la sélection : si ce n'est pas nécessaire pour valider votre hypothèse de départ, c'est hors périmètre.
Le bon format selon votre situation
Pour un MVP avec une agence ou un freelance
Un document de 5 à 10 pages suffit largement :
- contexte et objectifs (1 page)
- 3 à 5 parcours utilisateurs critiques (2–3 pages)
- contraintes techniques (1 page)
- périmètre V1 + hors périmètre (1 page)
- critères d'acceptance par parcours (2–3 pages)
Pour un projet plus structuré ou une équipe interne
On peut aller plus loin sur l'architecture cible, les SLA, les intégrations, et la gouvernance. Mais même dans ce cas, gardez le document vivant : un cahier des charges est un point de départ, pas une bible.
Pour un projet avec contraintes réglementaires ou contractuelles
Certains contextes (santé, finance, appel d'offres public) imposent un cahier des charges plus formalisé. Dans ce cas, dissociez clairement le document contractuel du document de travail — le premier protège, le second guide.
Ce que les équipes qui livrent bien font différemment
Elles ne cherchent pas à tout anticiper. Elles cherchent à aligner tout le monde sur les priorités et les intentions.
Leur cahier des charges répond à trois questions, clairement :
- Quel problème résout-on, pour qui, et comment on mesure le succès ?
- Qu'est-ce qu'on construit dans cette version, et qu'est-ce qu'on ne construit pas ?
- Comment sait-on que c'est terminé ?
Le reste est du détail qui peut évoluer en cours de route — et c'est normal.
"Un bon cahier des charges, ça ne prédit pas l'avenir. Ça évite les malentendus évitables."
Comment démarrer concrètement
Si vous partez de zéro, voici la séquence qui fonctionne :
- Rédigez d'abord vos objectifs business — deux ou trois phrases. Si vous n'arrivez pas à les formuler clairement, le reste du document sera flou.
- Listez vos 3 à 5 parcours critiques sous forme de scénarios narratifs.
- Faites relire par quelqu'un qui ne connaît pas le projet — si cette personne ne comprend pas ce qu'on construit et pour qui, recommencez.
- Définissez explicitement ce qui est hors périmètre — c'est souvent la discussion la plus utile à avoir avec votre équipe.
- Ajoutez les critères d'acceptance au moment du cadrage sprint, pas dans le document initial.
Notre service de cadrage produit accompagne cette étape pour les équipes qui veulent structurer leur projet avant de démarrer le développement.