Le cahier des charges logiciel est le document qui décrit ce que doit faire l'application que vous allez faire développer. Tout le monde s'accorde sur sa nécessité, et presque personne ne le rédige utilement. Le format qu'on enseigne encore, cent pages de spécifications exhaustives, produit des projets en retard et des budgets doublés. Voici ce qu'il faut vraiment écrire, et ce qu'il vaut mieux ne pas écrire.
Le contenu d'un cahier des charges logiciel
Un bon cahier des charges répond à quatre questions, et pas davantage. C'est la réponse à la question classique des quatre composantes.
| Composante | Ce qu'elle établit | Piège fréquent |
|---|---|---|
| Le contexte | Qui vous êtes, comment vous travaillez aujourd'hui | Raconter l'entreprise plutôt que le problème |
| Les objectifs | Ce qui doit changer, mesuré | Écrire "gagner en efficacité" sans chiffre |
| Le périmètre | Ce qui est inclus, et surtout exclu | Oublier la liste des exclusions |
| Les contraintes | Techniques, réglementaires, de délai | Les découvrir en cours de projet |
Notez ce qui ne figure pas dans ce tableau : la solution. Un cahier des charges décrit un problème à résoudre, pas l'application à construire. Dès que vous écrivez "il faut un bouton en haut à droite", vous avez basculé dans la spécification, et vous privez votre prestataire de la seule chose que vous attendez de lui, sa capacité à concevoir.
Pourquoi le cahier des charges de cent pages échoue
L'exhaustivité paraît prudente. Elle est en réalité la première cause de dérive budgétaire.
Le besoin change pendant la rédaction
Un cahier des charges complet demande deux à trois mois d'écriture. Pendant ce temps, votre organisation évolue, un concurrent sort une fonction, un client formule une demande nouvelle. Le document est périmé avant d'être signé.
La précision crée une fausse sécurité
Plus le document est détaillé, plus chacun croit que tout est réglé. Puis la première démonstration arrive, et l'on découvre que trois personnes avaient lu la même phrase différemment. Un écran vaut mille lignes de spécification.
Il empêche de découper
Un cahier des charges monolithique conduit mécaniquement à un projet monolithique, donc à une livraison unique très tardive. Or c'est précisément ce qu'il faut éviter : la dérive fonctionnelle peut faire grimper la facture de 30 à 50 pour cent, et elle prospère d'autant mieux que rien n'est livré.
Le format que nous recommandons
Trois à cinq pages, écrites en une semaine, structurées ainsi.
Le problème, pas la solution
Une page décrivant ce qui coince aujourd'hui, avec des faits. "Chaque devis demande 45 minutes, dont 30 de ressaisie depuis trois outils différents" vaut mieux que "améliorer le processus commercial".
Les cas d'usage prioritaires
Cinq à dix scénarios concrets, formulés du point de vue de l'utilisateur. "Un commercial reçoit un cahier des charges client par mail et doit produire un devis chiffré." Chacun est classé en indispensable, souhaitable ou plus tard.
Cette hiérarchisation est la partie la plus utile du document, et celle qui est presque toujours absente. Sans elle, tout est prioritaire, donc rien ne l'est.
Spécifier une fonction IA, ce qui change
Le point le plus délicat d'un cahier des charges moderne, et celui que presque personne ne traite correctement.
Une fonction classique se spécifie de façon binaire : le bouton enregistre, ou il n'enregistre pas. Une fonction IA est probabiliste. Écrire "l'agent doit correctement extraire les informations du document" ne veut rien dire, parce qu'aucun agent n'est correct à cent pour cent, pas plus qu'un humain.
Ce qu'il faut écrire à la place tient en trois points. Un seuil de qualité mesurable, du type "sur un échantillon de cinquante documents réels, au moins quarante-cinq sont traités sans correction". Un comportement en cas de doute, car l'agent doit savoir dire qu'il ne sait pas plutôt qu'inventer. Et un circuit de validation humaine pour les cas incertains, avec la question de qui tranche.
Corollaire pratique : préparez un jeu de documents ou de cas réels dès la rédaction du cahier des charges. Sans ces exemples, aucun prestataire sérieux ne peut s'engager sur un niveau de qualité, et vous n'aurez aucun moyen de vérifier la livraison.
Les contraintes non négociables
Hébergement des données en Europe, connexion obligatoire à tel logiciel existant, conformité à une norme sectorielle, date butoir liée à un événement réel. Elles se posent au départ parce qu'elles structurent l'architecture.
Ce qui est explicitement hors périmètre
La section la plus courte et la plus rentable. Écrire noir sur blanc ce que le projet ne couvrira pas coupe court à la moitié des discussions ultérieures.
Cahier des charges et devis : ce qui se passe ensuite
Un cahier des charges de cinq pages ne permet pas un chiffrage au centime, et c'est très bien ainsi. Il permet un ordre de grandeur, puis un cadrage payant de quelques jours qui produit le chiffrage ferme.
Cette étape intermédiaire fait gagner du temps à tout le monde. Elle transforme un document rédigé seul en un périmètre validé à deux, et elle révèle les non-dits avant qu'ils ne coûtent cher. Nous détaillons ce fonctionnement, ainsi que les facteurs qui font varier le budget, dans notre article sur ce que coûte un logiciel sur mesure.
Certains secteurs ont déjà leur propre format de cahier des charges. Dans le BTP, c'est le CCTP, et sa lecture est justement ce que notre agent IA BTP automatise.
Notre avis chez RedArrow
Nous recevons régulièrement des cahiers des charges de soixante ou quatre-vingts pages, manifestement rédigés avec sérieux, parfois pendant des mois. Et notre première réaction est presque toujours la même : ce document décrit une solution que quelqu'un a imaginée, pas un problème que nous pourrions résoudre autrement.
Le paradoxe est que ces documents très travaillés conduisent souvent aux projets les plus difficiles. Le client a tellement investi dans sa vision qu'il devient coûteux, humainement, de la remettre en question quand la première maquette montre qu'une autre voie serait plus simple.
Pour les PME et ETI, notre conseil tient en une phrase : écrivez court, décrivez le problème, hiérarchisez les cas d'usage, et gardez votre énergie pour la phase de cadrage où les décisions se prennent réellement. C'est la méthode que nous appliquons en développement de logiciel sur mesure, et elle vaut particulièrement quand il s'agit de remplacer des fichiers Excel par un logiciel métier structuré.
Un dernier point, souvent négligé : faites relire votre cahier des charges par la personne qui utilisera l'outil tous les jours, pas seulement par celle qui le finance. Les écarts entre les deux lectures sont instructifs.
Questions fréquentes
Quelles sont les 4 composantes d'un cahier des charges ?
Le contexte, qui décrit la situation actuelle et son fonctionnement. Les objectifs, exprimés de façon mesurable. Le périmètre, qui précise ce qui est inclus et ce qui est exclu. Et les contraintes, qu'elles soient techniques, réglementaires ou calendaires.
C'est quoi un cahier des charges en informatique ?
C'est le document de référence qui décrit le besoin à couvrir par un projet logiciel. Il sert de base commune entre le commanditaire et le prestataire, et de point de comparaison entre plusieurs devis. Il décrit un problème à résoudre, pas la solution technique à mettre en oeuvre.
Quelle longueur pour un cahier des charges logiciel ?
Trois à cinq pages suffisent pour la grande majorité des projets de PME. Au-delà, le document devient plus difficile à maintenir qu'utile, et il fige des choix qu'il vaudrait mieux prendre pendant la phase de conception.
En résumé
Un bon cahier des charges logiciel décrit un problème, hiérarchise des cas d'usage et pose des contraintes. Il ne décrit pas d'écrans, ne dépasse pas cinq pages, et se rédige en une semaine.
Le temps que vous n'aurez pas passé à spécifier l'inspécifiable, investissez-le dans le cadrage avec votre prestataire. C'est là que se joue la réussite du projet.
