Un cahier des charges vaut ce que vaut sa liste des exclusions
Dans notre process, le cahier des charges se situait entre la clarification du besoin et le chiffrage. Sur le papier, c'est un document qui décrit ce qui sera livré. Dans les faits, sa valeur tenait à une autre section — la liste de ce qui n'est pas inclus.
La différence apparaît au moment où le client demande « juste un petit ajout ». Si le cahier des charges ne décrit que ce qui est inclus, toute demande ressemble à une précision dans le périmètre convenu. S'il existe une liste des exclusions, cette même demande est immédiatement identifiée comme un avenant — et la discussion porte sur le délai et le prix, pas sur votre bonne volonté.
Un cahier des charges est un outil de pilotage des attentes, pas une description de solution. Sa partie utile, c'est la liste des exclusions, parce qu'elle transforme une future précision d'ajout gratuit en décision à part entière. Les données sur la volatilité des exigences montrent un lien statistiquement significatif entre les changements de périmètre et les dépassements de délai et de budget ; les recherches sur l'ambiguïté montrent que le formalisme d'un document ne suffit pas, à lui seul, à éviter les malentendus.
Ce que fait vraiment la liste des exclusions
Examinons ses fonctions une à une — elles sont au nombre de quatre, et aucune ne concerne la description de la solution technique.
Elle transforme une précision en décision. Tant que la frontière n'est pas posée, chaque demande se négocie comme une question relationnelle : accepter ou non. Une fois la frontière posée, c'est le périmètre qui se négocie : intégrer à la phase en cours ou à la suivante, avec quel délai et à quelles conditions.
Elle protège les deux parties, pas une seule. Le client sait clairement ce qu'il ne paie pas et ce qu'il ne recevra pas — c'est souvent plus important que la liste de ce qui est inclus. Croire que la liste des exclusions ne profite qu'au prestataire est une erreur : sans elle, le client découvre ce qui manque après la livraison.
Elle rend le chiffrage pertinent. On ne peut chiffrer qu'un périmètre borné. La liste des exclusions est précisément cette limite par rapport à laquelle un chiffre a un sens ; sans elle, l'estimation devient un argument de négociation, pas une étape du processus.
Elle révèle les écarts de vision avant le début des travaux. C'est sa fonction la plus utile. Le client lit la liste des exclusions plus attentivement que la description des travaux — parce qu'elle lui dit ce qu'il ne recevra pas. C'est précisément à cette lecture que se révèlent les écarts qui, autrement, apparaîtraient à la recette.
| Section du cahier des charges | Qui la lit vraiment | Quand elle joue son rôle |
|---|---|---|
| Description de la solution | Le prestataire | Pendant le développement |
| Liste des travaux | Les deux parties, à la validation | Au chiffrage |
| Liste des exclusions | Le client | À la première précision demandée et à la recette |
| Critères de recette | Les deux parties, à la fin | À la livraison |
La deuxième colonne explique un déséquilibre courant : le document est rédigé par le prestataire pour le prestataire, si bien que la section sur la solution devient détaillée, tandis que celle sur les exclusions reste courte, voire absente. Or c'est justement cette seconde section qui détermine le déroulement des trois mois suivants.
Ce que coûte réellement la volatilité des exigences
Le lien entre les changements d'exigences et le résultat du projet a été mesuré, et ces chiffres sont utiles à connaître avant d'accepter « un petit ajout ».
La volatilité des exigences est statistiquement liée de manière significative aux dépassements de délai et de budget. Seuls 14 % des projets de l'échantillon ont été livrés en avance et dans le budget ; la majorité a dépassé le calendrier de 25–50 % et le budget de 4–25 %.
Les limites sont réelles : il s'agit d'une enquête déclarative, pas d'une expérience contrôlée, le taux de réponse de 21 % crée un risque de biais en faveur des répondants aux projets difficiles, et l'étude a plus de vingt ans. Je m'en sers comme indice d'un lien durable, pas comme norme. Le mécanisme, lui, n'a pas vieilli : un avenant sans révision du délai et du prix transfère le risque vers le prestataire, et c'est exactement ce que capture cette statistique.
Pourquoi le formalisme ne suffit pas à éviter l'ambiguïté
Deuxième idée reçue : plus le cahier des charges est formel et détaillé, moins il y a de malentendus. La vérification expérimentale dit le contraire.
L'inspection d'un seul document d'exigences par trois relecteurs, en 4,5 heures, a révélé 58 ambiguïtés : 4 purement linguistiques et 54 propres à l'ingénierie des exigences. Les auteurs recommandent de détecter les ambiguïtés par inspection avant de rédiger la spécification formelle, et non après.
L'ampleur de l'expérience est modeste — au fond une étude de cas sur un seul document assortie d'une série d'exercices, et je le signale sans détour. Mais le ratio 4 contre 54 est parlant : l'immense majorité des malentendus ne vient pas de la langue, mais de trous fonctionnels — ce que les deux parties jugeaient évident et n'ont donc pas écrit. C'est exactement ce niveau que traite la liste des exclusions.
Ce que dit la norme
La norme internationale ISO/IEC/IEEE 29148 encadre les processus d'ingénierie des exigences pour les systèmes et les logiciels. Deuxième édition, 2018, reconfirmée sans changement en 2024.
Il faut ici une honnêteté qui manque souvent aux références aux normes. Le texte complet est payant, je n'ai lu que le résumé officiel décrivant l'objet et le domaine d'application. La liste souvent citée des qualités d'une bonne exigence — complétude, cohérence, vérifiabilité — je ne l'ai pas vérifiée sur la source primaire et je ne la cite donc pas comme telle. Je n'utilise cette référence que pour une chose : confirmer que les exigences constituent une discipline d'ingénierie à part entière, avec sa propre norme, et non une annexe du contrat.
Comment rédiger une liste des exclusions
La deuxième source est la plus précieuse et la plus sous-estimée. La liste de ce que l'on demande habituellement sur ce type de projet s'enrichit avec l'expérience passée et transforme la liste des exclusions d'une formalité en un outil : elle anticipe une conversation qui, sinon, aurait lieu un mois plus tard, dans de moins bonnes conditions.
La troisième source élimine toute une catégorie de conflits. Tout ce qui dépend d'un tiers — accès, matériaux, validations — doit être nommé explicitement, avec les conséquences d'un retard. Sinon, le retard d'un tiers devient par défaut le problème du prestataire.
Quatre règles pour un cahier des charges qui fonctionne
Rédigez les exclusions avant les inclusions
En partant de ce qui n'est pas inclus, vous obtenez une liste plus précise de ce qui l'est.
Tenez une liste des demandes récurrentes
Ce que l'on demande habituellement sur ce type de projet. Elle s'enrichit sur un an et économise des mois de discussions.
Nommez les dépendances à un tiers
Accès, matériaux, validations et conséquences d'un retard. Explicitement, avec des dates.
Décrivez la procédure d'avenant
Pas une interdiction de changer — c'est inévitable — mais une règle : ce qui arrive au chiffrage et au délai.
Si un cahier des charges ne comporte pas de section sur ce qui n'est pas inclus, le document décrit les intentions du prestataire, pas les limites du projet.
Les questions les plus fréquentes sur le cahier des charges
Que doit obligatoirement contenir un cahier des charges ?
Quatre sections : la liste des travaux, la liste de ce qui n'est pas inclus, les dépendances à des tiers avec les conséquences d'un retard, et la procédure d'avenant. La description de la solution technique est utile mais pas indispensable, et souvent nuisible en phase amont : elle fige une méthode avant même que le besoin soit compris. Dans les faits, la partie utile du document, ce sont les deuxième et quatrième sections.
Comment répondre à une demande de « juste un petit ajout » ?
Vérifiez-la par rapport à la liste des exclusions plutôt que d'en évaluer la charge. Si le point y figure, la discussion porte sur le délai et le prix, et prend cinq minutes. S'il n'y figure pas, c'est l'occasion de compléter la liste pour l'avenir — et de traiter la demande actuelle selon la règle d'avenant. Le danger n'est pas le petit ajout en soi, c'est l'accumulation de petits ajouts sans qu'aucune discussion n'ait lieu.
Un cahier des charges détaillé évite-t-il les malentendus ?
En partie. L'inspection expérimentale de documents d'exigences montre que l'immense majorité des ambiguïtés relevées ne sont pas linguistiques, mais fonctionnelles : des trous dans ce que les deux parties jugeaient évident. Le volume du document n'y remédie pas ; l'inspection avant la formalisation, si. Une méthode pratique : faites lire le document par quelqu'un qui n'a pas participé à sa rédaction, et notez toutes ses questions.
Faut-il un cahier des charges quand on travaille en itérations ?
Il faut sa partie utile — la frontière de l'itération en cours et la règle d'avenant. Une description complète de tout le projet n'a effectivement pas de sens en travail itératif : les exigences évoluent, et les données sur la volatilité montrent que c'est la norme, pas l'exception. Mais la frontière de l'itération et la procédure de révision sont d'autant plus nécessaires qu'il y a davantage de changements.
La place du cahier des charges dans le processus (entre la clarification du besoin et le chiffrage) et la structuration par étapes du travail client proviennent du référentiel interne d'Alego.Digital. Les exemples de cahiers des charges qui fondent la description de la structure du document proviennent des archives projet de l'entreprise (cahiers des charges pour un groupe de conseil et une entreprise industrielle, 2026). Ce sont des documents internes à l'entreprise de l'auteur ; ils n'ont pas été vérifiés par un tiers indépendant et sont présentés à titre d'illustration du mécanisme. La pratique consistant à tenir une liste cumulative des demandes récurrentes relève de la pratique personnelle de l'auteur, non formalisée dans les documents de l'entreprise.
- Zowghi D., Nurmuliani N. A Study of the Impact of Requirements Volatility on Software Project Performance. APSEC, 2002. opus.lib.uts.edu.au
- Kamsties E., Berry D. M., Paech B. Detecting Ambiguities in Requirements Documents Using Inspections. WISE, 2001. cs.uwaterloo.ca
- ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. iso.org