Ce qu'un cahier des charges doit contenir pour obtenir un prix ferme

Vous voulez un prix ferme. Le prestataire vous demande une spécification. Vous lui envoyez un document de quarante pages et il vous répond qu'il ne peut pas s'engager. Ce n'est pas de la mauvaise volonté : votre document décrit sans doute très bien ce que le système doit faire, et pas du tout ce qui se passe quand il ne le fait pas.

Les six éléments qui manquent presque toujours

1. La liste des exclusions. C'est le point le plus souvent absent et celui qui produit le plus d'avenants. Écrire ce qui est inclus ne suffit pas : tout ce qui n'est pas mentionné devient un sujet de négociation en cours de projet. Un bon document dit explicitement « la reprise de l'historique antérieur à 2020 n'est pas dans le périmètre » ou « l'application n'est pas prévue pour un usage mobile ».

2. Les cas de recette. Écrits avant le développement, pas après. Des cas rédigés à la fin décrivent ce qui a été construit et non ce qui était demandé, ce qui rend la recette inutile comme mécanisme de contrôle.

3. La grille de qualification des anomalies. Ce qui compte comme bloquant, majeur, mineur. Sans cette grille, la fin de projet devient une négociation sur la définition d'un bug, généralement au moment où les deux parties sont les moins disponibles pour la mener sereinement.

4. Le nom de la personne qui tranche. Une seule, avec un délai d'engagement. L'attente d'arbitrage sur une règle de gestion est la première cause de retard sur les projets au forfait, devant les difficultés techniques. Si trois directions doivent se mettre d'accord pour valider une règle, le prestataire doit le savoir avant de s'engager sur une date.

5. Les systèmes à intégrer, avec leur documentation ou un contact. Une intégration découverte en cours de route est la cause classique de dépassement. Il ne suffit pas de citer le nom d'un progiciel : il faut dire si son API est documentée, qui la maintient, et si un environnement de test est disponible.

6. Les exigences non fonctionnelles chiffrées. « Ça doit être rapide » n'est pas une exigence, c'est un litige futur. Donnez des volumes, des temps de réponse cibles, un nombre d'utilisateurs simultanés, une plage de disponibilité attendue.

Ce qui n'est pas nécessaire

Beaucoup de cahiers des charges consacrent des pages à des choix techniques qui ne devraient pas y figurer. Imposer un langage, un framework ou une architecture avant d'avoir discuté du besoin réduit la concurrence et supprime la possibilité que le prestataire propose plus simple.

De même, les maquettes détaillées de chaque écran sont rarement le meilleur investissement au stade du chiffrage. Un parcours utilisateur décrit précisément vaut mieux que trente écrans qui seront de toute façon retravaillés.

Le raccourci qui fonctionne

Si votre document ne contient pas ces six éléments, deux options s'offrent à vous. Passer plusieurs semaines à les produire en interne, ce qui suppose des compétences de cadrage disponibles. Ou acheter une phase de cadrage courte à un prestataire, qui produira le document et un prix ferme sur cette base.

Dans le second cas, exigez que le document vous appartienne, y compris si vous confiez la réalisation à quelqu'un d'autre. Un cadrage que vous ne pouvez pas mettre en concurrence n'est pas un cadrage, c'est un mécanisme de verrouillage.

Le test rapide

Posez-vous une question : si le prestataire qui a écrit ce document disparaissait demain, un autre pourrait-il chiffrer le projet à partir du document seul ? Si la réponse est non, le document n'est pas suffisant, quelle que soit son épaisseur.