Nous lisons régulièrement des cahiers des charges qui font trente pages et ne permettent pas de chiffrer une ligne. Et il nous arrive d'en recevoir de quatre pages sur lesquels on peut s'engager immédiatement. La différence ne tient pas au volume.
Pourquoi la plupart échouent
Le défaut le plus fréquent n'est pas le manque de détail : c'est la confusion entre le besoin et la solution. Un cahier des charges qui commence par « nous voulons une application mobile avec une base de données PostgreSQL » a déjà tranché des questions techniques avant d'avoir décrit le problème. Le prestataire chiffre alors une solution imposée, sans pouvoir dire qu'une autre coûterait trois fois moins cher.
Le second défaut est l'absence de hiérarchie. Quand tout est prioritaire, rien ne l'est, et le premier arbitrage de calendrier se fera sans vous.
Les sept sections qui suffisent
1. Le contexte. Que fait votre organisation, combien de personnes utiliseront l'outil, dans quelles conditions. Une application utilisée par trois personnes au siège et une application utilisée par quarante agents sur le terrain, avec du réseau instable, ne se construisent pas de la même façon.
2. Le problème à résoudre. En langage métier, pas technique. « Nos commerciaux saisissent deux fois les mêmes informations, dans le cahier puis dans le tableur, et nous perdons des commandes » vaut mieux que « nous voulons un CRM ».
3. Ce que vous faites aujourd'hui. Le processus actuel, même s'il est artisanal. C'est la section la plus utile et la plus souvent absente. Un prestataire qui ne sait pas comment vous travaillez aujourd'hui reconstruira une usine à gaz autour d'un besoin qu'il aura deviné.
4. Les fonctions attendues, hiérarchisées. Trois niveaux suffisent : indispensable, souhaitable, plus tard. Cette hiérarchie est ce qui permettra de tenir un budget quand il faudra couper.
5. Les contraintes réelles. Les outils qui existent déjà et avec lesquels il faudra dialoguer, les obligations réglementaires, les données sensibles, la connexion dont disposent réellement vos utilisateurs. Une contrainte tue oubliée fait dérailler un projet entier.
6. Le budget et l'échéance. Beaucoup d'acheteurs les taisent, en pensant obtenir de meilleurs prix. L'effet est inverse : sans ordre de grandeur, les propositions reçues seront incomparables, et vous perdrez des semaines à faire rechiffrer tout le monde. Donnez une fourchette, quitte à la présenter comme telle.
7. Comment vous jugerez que c'est réussi. Un ou deux critères vérifiables. « La saisie d'une commande prend moins de deux minutes » est un critère. « L'outil doit être ergonomique » n'en est pas un.
Ce qu'il vaut mieux ne pas y mettre
Le choix des technologies, sauf si une contrainte réelle vous l'impose — une compétence déjà présente en interne, un système existant à respecter. Sinon, laissez les prestataires proposer et justifier : leurs réponses vous apprendront quelque chose.
Les maquettes d'écrans détaillées, à ce stade. Elles figent l'interface avant d'avoir compris les parcours, et elles écartent des solutions plus simples.
Les formules creuses. « Solution innovante », « interface moderne », « haute performance » n'engagent personne et ne se vérifient pas.
Quelle longueur ?
Pour un projet de taille moyenne, cinq à dix pages suffisent largement. Au-delà de vingt, on trouve presque toujours du remplissage — des recopies de documents internes ou des exigences génériques qui ne seront jamais vérifiées. Un document court et net obtient de meilleures propositions qu'un document long et vague.
Et si vous n'arrivez pas à l'écrire ?
C'est fréquent, et ce n'est pas un aveu de faiblesse : écrire un cahier des charges suppose de trancher des arbitrages internes que personne n'a encore posés. Deux options honnêtes.
La première : écrivez seulement les sections 1, 2, 3 et 6 — le contexte, le problème, l'existant, le budget — et assumez de ne pas décrire la solution. Un bon prestataire saura travailler avec ça, et vous verrez tout de suite ceux qui ne posent aucune question.
La seconde : faites-vous accompagner pour le cadrage, par quelqu'un qui ne réalisera pas le projet ensuite. C'est le rôle de l'assistance à maîtrise d'ouvrage, et la précaution vaut d'être prise : celui qui écrit le cahier des charges ne devrait pas être celui qui y répond.
Dans les deux cas, ne lancez pas une consultation avec un document dont vous savez qu'il est flou en espérant que les réponses le clarifieront. Elles ne le feront pas — elles feront porter le flou sur le prix.