Cahier des charges d'un logiciel: ce qui compte vraiment

Le cahier des charges est l’objet le plus paradoxal du développement logiciel : tout le monde pense qu’il en faut un gros, et les projets qui échouent en avaient presque toujours un. Après des dizaines de projets sur mesure, voici ce qui mérite d’être écrit avant de développer, ce qui doit rester ouvert, et dans quel ordre s’y prendre.

Pourquoi le document exhaustif échoue-t-il si souvent ?

La réponse directe : parce qu’il fige des décisions au moment précis où l’on en sait le moins. Un document de 60 pages rédigé avant la première ligne de code spécifie des écrans que personne n’a vus, des parcours que les utilisateurs n’ont pas confrontés au terrain, des priorités arbitrées sur des hypothèses. Six mois plus tard, le logiciel est conforme au document, et le document était faux. Personne n’a fauté, tout le monde a perdu.

L’intuition qui pousse au document exhaustif semble pourtant de bon sens : plus c’est précis, moins il y aura de surprises. La réalité des projets dit l’inverse, et elle a une explication structurelle : l’information nécessaire aux bonnes décisions de détail n’existe pas encore au moment de la rédaction. Elle apparaît en concevant les écrans, en confrontant les maquettes aux utilisateurs, en livrant les premières versions. Sur ce mécanisme, la loi de Hofstadter mérite une lecture entière.

L’autre effet pervers est contractuel : le gros cahier des charges installe une relation de conformité. Le prestataire livre ce qui est écrit, ni plus ni moins, et chaque écart devient un avenant facturé. Vous vouliez un partenaire, vous avez un exécutant défensif.

Que contient un bon cahier des charges de logiciel ?

Cinq sections suffisent, et chacune tient en une à deux pages.

1. Le problème. Pas la solution imaginée : le problème, avec ses chiffres. « Nos techniciens perdent une heure par jour en ressaisie entre le terrain et la facturation » vaut mieux que trois pages de spécification d’un module de synchronisation. Le problème bien posé contient déjà la moitié du cadrage.

2. Les utilisateurs. Qui ouvrira l’outil, dans quel contexte, avec quel niveau d’aisance numérique ? Un logiciel pour un technicien sous la pluie avec des gants et un logiciel pour un comptable au bureau ne se conçoivent pas pareil : c’est ce qui décide de l’interface bien avant le choix des couleurs.

3. Les processus concernés. Comment ça se passe aujourd’hui, avec quels outils, et où ça coince précisément. Les captures d’écran des fichiers Excel de contournement valent de l’or : elles montrent le vrai processus, pas le processus officiel.

4. Les contraintes réelles. Systèmes existants à interfacer, obligations réglementaires, volumes de données, échéances non négociables. Les vraies contraintes, pas les préférences déguisées : « le patron préfère le bleu » n’est pas une contrainte.

5. Les non-objectifs. La section la plus importante et la plus rare : ce que le projet ne fera pas. Chaque fonctionnalité écartée explicitement est un débat évité en cours de route et un budget protégé. Un cadrage sans non-objectifs est un périmètre qui n’attend que de gonfler.

Comment la discovery produit ce document dans le bon ordre

Chez Krafter, ce dossier ne précède pas le projet : il en est le premier livrable. Une à deux semaines de discovery avec les fondateurs : ateliers, cartographie des parcours, arbitrage du périmètre, chiffrage. À la sortie, un backlog priorisé, une estimation ferme sur la V1 et une date de mise en production.

La différence avec le cahier des charges classique tient en un mot : le document est vivant. Le périmètre de la V1 est ferme (c’est lui qui est chiffré et daté), mais tout ce qui suit se réarbitre à chaque cycle en fonction de l’usage réel. Les maquettes valident les écrans avant le code, les livraisons toutes les une à deux semaines confrontent le logiciel au terrain, et la roadmap suit ce qu’on apprend au lieu de défendre ce qu’on avait supposé.

Ce fonctionnement change aussi la relation contractuelle : l’engagement porte sur un problème résolu à une date donnée, pas sur la conformité à un document. Quand un imprévu surgit (il surgira), la conversation n’est pas « avenant ou pas avenant » mais « qu’est-ce qui sort de la V1 pour que la date tienne ».

Par où commencer, concrètement ?

Si vous préparez un projet, n’ouvrez pas un traitement de texte : ouvrez une liste à trois colonnes.

1. Ce qui nous fait perdre du temps aujourd’hui : les ressaisies, les contournements, les informations qui se perdent, avec une estimation d’heures par semaine.
2. Ce qui doit absolument marcher le jour 1 : le cœur, sans lequel l’outil ne sert à rien.
3. Ce qui peut attendre : tout le reste, sans culpabilité.

Avec ces trois colonnes et une conversation de 30 minutes, un professionnel sérieux vous dira si le projet tient la route, dans quel budget et dans quels délais. C’est exactement le format de notre premier échange : venez avec vos trois colonnes, même griffonnées. Les 60 pages, personne ne les regrettera.