« Envoyez-nous votre cahier des charges. » La demande paraît anodine, et elle bloque des projets pendant des mois. Parce que ce qui existe côté client, à ce stade, n’est presque jamais un cahier des charges. C’est une expression de besoin, parfois même seulement une intuition, et vouloir la faire passer pour l’autre chose produit un document que personne ne peut chiffrer honnêtement.
Les deux documents existent, ils sont tous les deux utiles, et ils ne se remplacent pas.
L’expression de besoin décrit un problème
Elle répond à une seule question : qu’est-ce qui ne va pas, et pour qui.
Elle est écrite par les métiers, elle parle leur langue, et elle ne contient aucune solution. « Un commercial passe une demi-journée par semaine à retrouver l’historique d’un client dans trois outils différents » est une expression de besoin. « Il faut un CRM avec une vue client unifiée » n’en est pas une : c’est déjà une réponse, et elle a écarté toutes les autres sans les examiner.
C’est la différence qui compte le plus, et c’est celle qu’on saute presque toujours. Un besoin correctement exprimé laisse plusieurs solutions ouvertes. Un besoin exprimé sous forme de solution en laisse une seule, choisie par la personne qui tenait le clavier, souvent la mieux placée pour connaître le problème et la moins bien placée pour connaître les options.
Une expression de besoin utile contient :
- Qui fait quoi aujourd’hui, avec quel outil, à quelle fréquence, en combien de temps.
- Ce qui ne va plus, et depuis quand. Un déclencheur daté. Une croissance, un départ, une panne, un client perdu.
- Ce que ça coûte réellement. Même approximatif. Une demi-journée par semaine et par personne devient un budget quand on la multiplie.
- Les cas particuliers. C’est là que se cache le vrai périmètre, et c’est ce que la direction ignore souvent parce que les métiers ont appris à s’en arranger.
Elle ne contient ni technologie, ni écran, ni planning.
Le cahier des charges décrit ce qu’on attend d’un fournisseur
Il répond à une autre question : sur quoi va-t-on s’engager, et comment saura-t-on que c’est livré.
Il vient après. Il s’appuie sur l’expression de besoin, il ajoute ce qu’elle ne peut pas contenir, et il est écrit pour être opposable. Un cahier des charges est un document contractuel avant d’être un document technique.
Ce qu’il ajoute :
- Les contraintes non fonctionnelles. Disponibilité attendue, volumétrie à trois ans, hébergement, sécurité, données personnelles, sauvegarde. Ces lignes ne sont pas des fonctionnalités et elles coûtent souvent plus cher qu’elles.
- Les connexions à l’existant. Quels outils devront se parler, ce qui doit circuler, dans quel sens, et ce qu’on sait de leurs interfaces.
- Les données à reprendre. Volume, emplacement, qualité connue, et ce qu’on accepte de ne pas reprendre. C’est la section absente qui fait déraper les budgets.
- Les critères de recette. Des phrases qu’on peut déclarer vraies ou fausses sans discuter. Sans elles, la fin du projet est une négociation ; avec elles, c’est un constat.
- Le cadre. Échéance et ce qui la contraint, référent interne nommé, format d’engagement, propriété du code, réversibilité.
On a mis notre trame complète en accès libre, avec ces sections déjà en place : le modèle de cahier des charges est téléchargeable en Word, sans inscription.
Ce qui se casse quand on confond les deux
Cas 1 : on envoie une expression de besoin en croyant envoyer un cahier des charges. Les prestataires répondent avec des chiffres qui ne veulent rien dire, parce qu’ils chiffrent leur interprétation. Les écarts entre devis sont énormes, non pas parce que les prestataires diffèrent, mais parce qu’ils n’ont pas compris la même chose. Vous choisissez, en général, celui qui a le moins bien compris, puisque c’est lui le moins cher.
Cas 2 : on écrit un cahier des charges sans être passé par l’expression de besoin. Le document est complet, précis, chiffrable. Il décrit soigneusement une solution qui ne résout pas le vrai problème. Il n’y a plus de dérapage budgétaire, il y a un outil livré conforme et peu utilisé, ce qui est plus cher.
Cas 3, le plus fréquent : on mélange les deux dans un même document. Des situations métier et des spécifications d’écrans, dans le même fichier, sans qu’on sache lesquelles sont négociables. Les prestataires chiffrent le tout au plus prudent, puisque tout paraît engageant.
L’enchaînement qui marche
Quatre temps, et le premier est celui qu’on saute.
- Expression de besoin, écrite avec les métiers. Quelques ateliers suffisent souvent. Ce qui coûte du temps, c’est de faire dire les cas particuliers, parce que personne ne les considère comme intéressants.
- Arbitrage. Tout ce qui a été exprimé n’entrera pas. On classe en trois niveaux : sans quoi le projet ne sert à rien, utile dès la mise en service, souhaitable plus tard. Sans cette étape, tout est indispensable, donc rien ne l’est.
- Cahier des charges, construit sur le périmètre arbitré. C’est là qu’on écrit les contraintes, la reprise de données et les critères de recette.
- Consultation, avec un document que plusieurs prestataires peuvent chiffrer de la même façon. C’est le seul cas où comparer des devis a un sens.
Entre les étapes 2 et 3, un regard technique change beaucoup de choses. Une exigence qui paraît anodine peut doubler la charge ; une exigence qui paraît lourde peut être gratuite parce que l’outil la fournit déjà. C’est une asymétrie d’information normale, pas un défaut de rédaction, et c’est l’objet d’un cadrage court ou d’une assistance à maîtrise d’ouvrage selon que vous avez besoin d’un avis ou de quelqu’un qui porte le document jusqu’à la réception.
Le raccourci qui est parfois le bon
Il existe un cas où sauter l’étape du cahier des charges est raisonnable : quand le besoin est petit, connu, et que vous travaillez avec quelqu’un en qui vous avez confiance. Écrire vingt pages pour un outil de trois écrans coûte plus cher que l’outil.
La limite est facile à poser. Si le projet engage assez d’argent pour qu’un désaccord de périmètre soit un problème, le document doit exister. En dessous, un échange écrit précis et des critères de recette explicites suffisent, à condition que les critères de recette existent vraiment. C’est la seule partie du cahier des charges qui ne se négocie jamais.
Pour aller plus loin
- Modèle de cahier des charges à télécharger : la trame complète en Word, clauses de protection comprises
- Exemple de cahier des charges informatique : les huit sections détaillées, avec quoi écrire dans chacune
- Rédiger un cahier des charges pour un logiciel sur-mesure : la méthode qui évite les avenants
- Recette d’un logiciel : le plan de tests qui évite la mise en production ratée : ce que deviennent les critères de recette
- Assistance à maîtrise d’ouvrage : quand le document doit être porté par quelqu’un de votre côté
- AMOA ou AMOE : laquelle vous cherchez : qui porte le document, et de quel côté de la table
- AMOA dans un marché public : le cas de la commande publique