Passer au contenu

Un cahier des charges vaut ce que vaut sa liste des exclusions

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é.

En bref

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.

14 %des projets livrés en avance et dans le budget
58ambiguïtés relevées par une inspection sur un seul document d'exigences
4,5 heuresde travail de trois relecteurs sur ce document

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 chargesQui la lit vraimentQuand elle joue son rôle
Description de la solutionLe prestatairePendant le développement
Liste des travauxLes deux parties, à la validationAu chiffrage
Liste des exclusionsLe clientÀ la première précision demandée et à la recette
Critères de recetteLes 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 ».

Étude

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 %.

Didar Zowghi, N. Nurmuliani (University of Technology Sydney). Communication à la 9e Asia-Pacific Software Engineering Conference, 2002. Enquête postale auprès de 430 entreprises australiennes, 92 réponses (21 %), 52 projets achevés analysés ; analyse de corrélation et de régression · opus.lib.uts.edu.au (PDF)

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.

La liste de ce qui n'est pas inclus est lue plus attentivement que le périmètre lui-même.

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.

Étude

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.

Erik Kamsties, Daniel M. Berry, Barbara Paech. Communication au Workshop on Inspection in Software Engineering, juin 2001. Validation expérimentale d'une technique d'inspection sur un document d'exigences, à l'aide de métamodèles de types d'ambiguïté · cs.uwaterloo.ca (PDF)

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

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.

ISO/IEC JTC1/SC7 conjointement avec l'IEEE. Document normatif élaboré par consensus, ce n'est pas une étude empirique · iso.org

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 liste des exclusions se construit à partir de quatre sources, et aucune ne concerne la solution technique.
01Ce qui a été discuté et écarté pour l'instant
02Ce que l'on demande habituellement sur ce type de projet
03Ce qui dépend d'un tiers
04Ce que l'on fait en cas d'avenant
la liste est révisée avec le chiffrage à chaque avenant, elle ne reste pas figée dans sa version du premier jour

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

01

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.

02

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.

03

Nommez les dépendances à un tiers

Accès, matériaux, validations et conséquences d'un retard. Explicitement, avec des dates.

04

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.

Origine des chiffres internes

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.

Sources externes
  1. Zowghi D., Nurmuliani N. A Study of the Impact of Requirements Volatility on Software Project Performance. APSEC, 2002. opus.lib.uts.edu.au
  2. Kamsties E., Berry D. M., Paech B. Detecting Ambiguities in Requirements Documents Using Inspections. WISE, 2001. cs.uwaterloo.ca
  3. ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. iso.org