Rédiger un cahier des charges qui ne se retourne pas contre vous
Julien
Co-fondateur, direction commerciale
En bref
Comment rédiger un cahier des charges pour une application web ?
Décrivez les problèmes à résoudre et les résultats attendus, pas les écrans que vous imaginez. Un bon cahier des charges tient en 10 à 20 pages : contexte, utilisateurs et volumétrie, processus actuels, contraintes non négociables, critères de succès mesurables. Les documents de 80 pages remplis de spécifications d'interface produisent des devis élevés et des applications rigides, parce qu'ils verrouillent des solutions avant d'avoir compris le besoin.
Je lis des cahiers des charges toutes les semaines. Les meilleurs font quinze pages. Les pires en font quatre-vingts.
Ce n’est pas une question de sérieux : les documents les plus épais sont souvent ceux qui ont demandé le plus de travail. C’est une question de nature — ils décrivent une solution au lieu de décrire un problème, et c’est ce qui les rend coûteux.
Le problème des cahiers des charges trop précis
Quand un document spécifie « un écran avec un tableau à sept colonnes, un filtre en haut à droite et un bouton d’export », il fait deux choses.
Il empêche le prestataire de proposer mieux. Nous avons peut-être livré quatre fois ce type d’écran et appris que le filtre en haut à droite n’est jamais utilisé. Si c’est écrit, on le fait — et on facture une fonctionnalité inutile.
Et il transfère le risque sur vous. En marché forfaitaire, le prestataire livre ce qui est écrit. Si l’application est conforme mais inutilisable, c’est votre problème : elle est conforme.
J’ai vu des projets livrés à 100 % des spécifications et abandonnés en six mois. Le document était irréprochable.
Photo : Jeffrey Betts — licence CC0.
Ce qu’un bon cahier des charges contient
1. Le contexte, en une page
Qui vous êtes, ce que fait l’entreprise, pourquoi ce projet maintenant. Un prestataire qui comprend l’enjeu propose mieux qu’un prestataire qui répond à une liste.
2. Les utilisateurs et la volumétrie
Combien de personnes, quels profils, quel usage — quotidien ou ponctuel, au bureau ou en mobilité. Et des chiffres : combien de dossiers par jour, combien en base après reprise, combien d’utilisateurs simultanés en pointe.
Ces chiffres changent l’architecture. Sans eux, on surdimensionne — donc on surfacture.
3. Les processus actuels, tels qu’ils se passent vraiment
Pas la procédure officielle : ce que font réellement les gens, y compris les contournements. Le tableur parallèle que tout le monde utilise en dit plus long sur le besoin réel que dix pages de procédure.
4. Les contraintes non négociables
Réglementaires, techniques, calendaires. Distinguez-les clairement de ce qui est souhaitable — mélanger les deux fait exploser les devis, parce qu’un prestataire prudent traite tout comme obligatoire.
5. Les critères de succès, mesurables
C’est la partie la plus souvent absente et la plus utile. « Le temps de traitement d’un dossier passe de 12 à 4 minutes. » « Plus aucune ressaisie entre l’outil commercial et la facturation. »
Ces critères servent à trois choses : arbitrer le périmètre, orienter les propositions, et juger le résultat. Sans eux, « ça marche » devient une affaire d’opinion.
Ce qu’il vaut mieux ne pas y mettre
Les maquettes d’écran, sauf si elles illustrent un point difficile à décrire. Sinon elles seront prises pour des spécifications.
Le choix de la technologie, sauf contrainte réelle — une équipe interne qui devra reprendre, un existant à respecter. Imposer une technologie sans raison élimine des prestataires compétents et vous prive de leur avis.
Une liste de fonctionnalités sans priorité. Si tout est important, rien ne peut être arbitré, et le premier retard devient un conflit. Classez, même grossièrement : indispensable à la mise en production, souhaitable ensuite, plus tard.
Photo : Green Chameleon — licence CC0.
Le format que je conseille
Dix à vingt pages, structurées ainsi :
| Section | Longueur | Rôle |
|---|---|---|
| Contexte et enjeu | 1 page | Faire comprendre pourquoi |
| Utilisateurs et volumétrie | 1–2 pages | Dimensionner |
| Processus actuels | 3–5 pages | Décrire le réel |
| Besoins par priorité | 3–5 pages | Permettre l’arbitrage |
| Contraintes non négociables | 1 page | Éviter les surprises |
| Critères de succès | 1 page | Rendre le résultat jugeable |
| Cadre du projet | 1–2 pages | Budget, délai, gouvernance |
Et une phrase que je recommande d’ajouter en introduction : « Nous décrivons des problèmes. Nous attendons des propositions, y compris différentes de ce que nous imaginons. »
Elle change la nature des réponses que vous recevrez. Les prestataires qui se contentent de recopier votre document se distinguent immédiatement de ceux qui réfléchissent.
Photo : MichaelGaida — licence CC0.
Décrire une règle métier sans se tromper de niveau
C’est l’endroit où la plupart des documents dérapent, dans un sens ou dans l’autre.
Trop vague : « le système calcule automatiquement la remise ». Cette phrase ne permet de coder quoi que ce soit, et elle sera interprétée.
Trop prescriptif : « le système exécute une requête sur la table remises, filtre sur le code client, puis applique un coefficient ». Vous décrivez une implémentation, ce qui n’est pas votre métier et interdit toute meilleure solution.
Le bon niveau se situe entre les deux : la règle, ses cas particuliers, et deux exemples chiffrés. « La remise dépend du volume annuel du client selon le barème ci-joint. Un nouveau client sans historique relève du premier palier. Un client du groupe X bénéficie du barème négocié au niveau du groupe. Exemple : client à 42 000 € de volume, commande de 1 200 € → remise de 4 %. »
Les exemples chiffrés valent tous les paragraphes du monde : ils ne s’interprètent pas, et ils deviennent directement des cas de test.
Ce qui manque presque toujours
Trois sujets absents de neuf cahiers des charges sur dix, et qui ont un impact direct sur le chiffrage.
Les volumes. Combien d’utilisateurs, combien simultanément, combien d’enregistrements aujourd’hui et dans trois ans. Un même écran ne se conçoit pas de la même façon pour cinq cents lignes ou pour deux millions.
Les droits. Qui voit quoi, qui peut modifier quoi. C’est presque toujours plus complexe que prévu, et c’est découvert en cours de projet, au pire moment.
Ce qui existe déjà. Les systèmes en place avec lesquels il faudra dialoguer, et dans quel sens. Une intégration non annoncée est le premier facteur de dérive budgétaire que je constate.
Ces trois points se renseignent en une demi-journée et évitent des semaines de découverte.
Et si vous n’avez pas le temps de l’écrire ?
C’est fréquent, et ce n’est pas grave. Un atelier de cadrage payant produit le même résultat en deux semaines, avec l’avantage d’être écrit par des gens qui savent quelles questions poser.
Ce que je déconseille : lancer une consultation sans document ni cadrage. Vous recevrez des propositions incomparables, et vous choisirez au feeling — ce qui est exactement ce que vous vouliez éviter.