Le cahier des charges : ce qu’il doit contenir

Un cahier des charges énonce ce qu’on attend d’un projet ou d’un prestataire : le besoin, le périmètre, les contraintes et les critères sur lesquels le résultat sera accepté. Sa fonction n’est pas de décrire une solution — c’est le travail de la réponse — mais de définir le problème assez précisément pour que deux prestataires différents le comprennent de la même façon, et que la recette puisse se prononcer sans discussion.

Partir du besoin, pas de la solution

L’échec le plus courant est un cahier des charges qui contient déjà la solution : des écrans, des technologies, une architecture choisie. Il ferme la porte à de meilleures réponses, il vous renvoie le risque de conception, et il rend la recette indéfendable — on ne peut pas refuser une livraison qui met en œuvre exactement ce qu’on avait dessiné. Énoncez le besoin métier, le processus à servir et l’effet attendu ; laissez le « comment » à la réponse.

Ce qu’il doit contenir

Le contexte et l’objectif poursuivi. Le périmètre fonctionnel, et tout aussi explicitement ce qui en est exclu. Les exigences non fonctionnelles — volumétrie, performance, disponibilité, sécurité, accessibilité, contraintes d’hébergement et de localisation des données. Les interfaces avec l’existant. Les contraintes de planning et les dates non déplaçables. Les critères de recette. Et la gouvernance : qui décide, qui recette, à quel rythme.

Toute exigence doit être vérifiable

« L’application doit être rapide » ne peut être ni acceptée ni refusée. « Une recherche répond en moins de deux secondes pour 95 % des requêtes à 200 utilisateurs simultanés » le peut. Le test est simple : pour chaque ligne, demandez ce que vous mesureriez pour dire qu’elle est tenue. Toute exigence qui survit sans réponse relève soit de la section contexte, soit de la corbeille — la garder garantit un litige à la recette.

Le hors-périmètre vaut plus que le périmètre

Ce qu’un cahier des charges exclut protège le projet bien davantage que ce qu’il inclut. Nommer ce qu’on laisse volontairement de côté — le deuxième pays, la reprise des données anciennes, l’application mobile — tue l’ambiguïté qui reviendrait sinon en attente non budgétée au cinquième mois. C’est aussi la seule façon qu’une demande de changement soit reconnue comme telle au lieu d’être absorbée en silence.

Du cahier des charges au projet dans FoxPlan

Dans FoxPlan, les exigences vivent comme des objets du projet, chacune reliée aux tâches qui la mettent en œuvre et au livrable qui sera accepté : la couverture devient une lecture plutôt qu’un pointage manuel. Ce qui a été exclu reste écrit à côté de ce qui a été convenu, et le projet garde une trace durable de ce sur quoi il s’est engagé — le document qui rend une réunion de recette courte.