Cahier des charges fonctionnel : quelle valeur juridique en cas de litige ?

Le cahier des charges fonctionnel, souvent désigné par l'acronyme CDCF, est le document qui décrit ce que doit faire un logiciel, une application ou un développement informatique. Il recense les besoins du client, liste les fonctionnalités attendues, précise les contraintes techniques et organisationnelles, et fixe les critères à partir desquels le livrable sera évalué. Dans les projets informatiques, c'est généralement le document de référence autour duquel tout le projet s'organise. Sa valeur juridique en cas de litige est une question que l'on se pose rarement avant le projet et presque toujours après, lorsque la relation entre le client et le prestataire s'est dégradée. Le client estime que la solution livrée ne correspond pas à ce qui avait été demandé. Le prestataire soutient qu'il a livré ce qui était prévu. Chacun brandit le cahier des charges à l'appui de sa position. Et c'est là que les choses se compliquent : la valeur du document dépend entièrement de la manière dont il a été intégré dans la relation contractuelle, validé par les parties et traité au fil du projet.

Un cahier des charges n'est pas automatiquement un document contractuel

C'est le premier point à comprendre, et le plus souvent mal appréhendé. Le cahier des charges fonctionnel n'a pas de valeur contractuelle par nature. Il n'en acquiert une que s'il est expressément intégré au contrat, dans des conditions qui en font un document opposable aux deux parties. Dans la pratique, les projets informatiques démarrent souvent dans une certaine fluidité : un cahier des charges est rédigé par le client, transmis au prestataire, une proposition commerciale est émise, un bon de commande est signé, et les développements commencent. À aucun moment le lien entre le cahier des charges et le contrat n'est formalisé. Le bon de commande ne fait pas référence au cahier des charges. Aucun des deux documents ne précise lequel prévaut en cas de contradiction. Aucune version du cahier des charges n'est datée ni signée par les deux parties. Dans ce scénario, le cahier des charges peut constituer un élément de preuve utile, mais il n'a pas la force d'une obligation contractuelle dont l'inexécution peut être sanctionnée. Le tribunal l'interprétera comme un élément d'appréciation parmi d'autres, sans pouvoir en tirer des conclusions fermes sur l'étendue des engagements du prestataire.

« Dans la quasi-totalité des litiges informatiques que nous traitons, le cahier des charges existe, il est souvent très détaillé, et pourtant il ne peut pas être opposé au prestataire avec la force d'une obligation contractuelle. Parce que personne n'a pris soin de l'annexer formellement au contrat, de le faire signer dans cette version précise, et de prévoir qu'il faisait partie intégrante de l'accord. Le document est là, mais juridiquement, il ne lie personne. C'est une des erreurs les plus coûteuses qu'on voit en pratique, et l'une des plus simples à éviter. »

Comment le cahier des charges acquiert une valeur contractuelle

Pour qu'un cahier des charges fonctionnel soit contractuellement opposable, il faut qu'il soit identifié, daté, accepté et intégré dans le contrat de manière explicite. L'intégration passe généralement par une clause du contrat principal qui désigne le cahier des charges comme une annexe contractuelle et précise sa valeur dans la hiérarchie des documents. Une formulation courante est la suivante : le contrat précise que les annexes font partie intégrante de l'accord et qu'en cas de contradiction entre le contrat principal et une annexe, le contrat principal prévaut. Cette hiérarchie est importante : elle évite qu'une précision technique figurant dans le cahier des charges vienne contredire une clause de responsabilité ou de prix négociée dans le corps du contrat. L'acceptation formelle du cahier des charges par le prestataire est tout aussi déterminante. Un prestataire qui signe le contrat principal sans avoir signé ou approuvé explicitement le cahier des charges peut soutenir qu'il ne s'est jamais engagé sur son contenu précis. Cette position est plus facile à tenir qu'on ne le pense, notamment lorsque le cahier des charges a évolué entre la première version transmise et le démarrage effectif du projet.

La question des versions successives

Les cahiers des charges fonctionnels évoluent. C'est dans leur nature : les besoins du client se précisent, des fonctionnalités sont ajoutées ou retirées, des contraintes techniques émergent au fil des échanges avec le prestataire. Cette évolution est normale et saine d'un point de vue projet. Elle devient un problème juridique lorsqu'elle n'est pas tracée. Un litige courant porte sur la version du cahier des charges qui fait foi. Le client se fonde sur la dernière version qu'il a transmise, qui inclut des fonctionnalités ajoutées en cours de projet. Le prestataire se fonde sur la version initiale, qui était celle intégrée au contrat. Entre les deux, plusieurs échanges d'emails, des réunions dont les comptes-rendus sont incomplets, des modifications validées verbalement. Dans ce contexte, aucune des deux parties ne dispose d'une position inattaquable, et le tribunal devra reconstituer l'accord réel des parties à partir d'un faisceau d'indices. La précaution élémentaire est de "versionner" le cahier des charges, de dater chaque version et de prévoir dans le contrat une procédure formelle pour les modifications : avenant signé des deux parties, ou ordre de modification validé par écrit avant tout commencement d'exécution. Sans cette procédure, chaque modification orale ou informelle est potentiellement une source de litige sur le périmètre réel des obligations du prestataire.

Ce que le juge fait concrètement du cahier des charges

Lorsqu'un litige est porté devant le tribunal, le juge examine le cahier des charges comme un élément d'interprétation du contrat. Il cherche à reconstituer la commune intention des parties : qu'ont-elles réellement voulu, qu'ont-elles accepté, et qu'est-ce que le prestataire s'est engagé à livrer ? Si le cahier des charges est une annexe contractuelle signée, il constitue une obligation de conformité : le prestataire s'est engagé à livrer ce qui y est décrit, et un livrable qui ne correspond pas à ces spécifications est un livrable non conforme. Le client peut alors invoquer la non-conformité pour obtenir des corrections, une réduction de prix ou la résolution du contrat selon les circonstances. Si le cahier des charges n'est qu'un document préparatoire non formalisé, le juge l'utilisera pour apprécier les attentes légitimes du client et le comportement du prestataire, mais sans pouvoir en tirer une obligation aussi directe. La démonstration du manquement sera plus difficile, et le résultat plus incertain. Dans tous les cas, le tribunal s'intéressera également à d'autres éléments : les échanges entre les parties pendant le projet, les comptes-rendus de réunion, les éventuels rapports d'avancement, les emails dans lesquels l'une ou l'autre partie a exprimé des réserves ou des validations. Ces éléments permettent de reconstituer l'interprétation que les parties elles-mêmes ont donnée au cahier des charges tout au long du projet.

Le cas des méthodes Agile

Les projets conduits en méthode Agile posent une difficulté spécifique. Par construction, ces projets ne reposent pas sur un cahier des charges exhaustif défini en amont. Les fonctionnalités sont priorisées et développées par cycles courts, le périmètre évolue en permanence et la définition du livrable final est par nature progressive. Cette flexibilité est une force opérationnelle mais une fragilité juridique. Dans un projet Agile, la référence contractuelle n'est pas le cahier des charges mais le backlog, c'est-à-dire la liste priorisée des fonctionnalités à développer, mise à jour à chaque cycle. Le contrat doit refléter cette réalité : il doit décrire le processus de priorisation et de validation du backlog, les règles de gouvernance du projet, la définition du « done » (quand une fonctionnalité est considérée comme terminée et acceptée) et les conditions dans lesquelles le périmètre peut être modifié. Un contrat Agile qui se contente de renvoyer à un cahier des charges initial comme si le projet allait suivre un cycle en V est un contrat inadapté à la méthode choisie, et une source de litige quasi certaine en cas de difficulté.

La procédure de recette et son articulation avec le cahier des charges

La valeur du cahier des charges en cas de litige est étroitement liée à la procédure de recette prévue par le contrat. La recette est le processus par lequel le client vérifie que le livrable est conforme aux spécifications et formalise son acceptation ou ses réserves. Si le contrat prévoit une recette formelle, avec des critères d'acceptation définis (idéalement dans le cahier des charges lui-même ou dans une annexe dédiée), un délai de recette et une procédure pour formuler des réserves, la recette constitue le moment où la conformité est vérifiée et où les éventuels désaccords doivent être soulevés. Une recette sans réserve vaut acceptation : le client qui signe un procès-verbal de recette sans formuler d'observation renonce généralement à invoquer ultérieurement une non-conformité aux spécifications. Si le contrat ne prévoit pas de procédure de recette, la situation est plus complexe. Le client peut alors soutenir que le livrable ne correspond pas au cahier des charges à n'importe quel moment, mais le prestataire peut opposer une acceptation tacite résultant de l'utilisation du système sans protestation pendant une période significative.

« Le moment où le client perd le plus souvent ses droits, ce n'est pas au début du projet, c'est à la recette. Il signe le procès-verbal parce que le chef de projet est pressé, parce que la mise en production est déjà planifiée, parce qu'il fait confiance au prestataire pour corriger les anomalies restantes. Quelques mois plus tard, quand les corrections ne sont pas venues et que la relation se tend, le prestataire sort le procès-verbal de recette signé sans réserve. À ce stade, il est très difficile de revenir sur une acceptation formelle. La recette n'est pas une formalité administrative : c'est l'acte juridique le plus important du projet. »

Ce qu'il faut retenir avant de démarrer un projet

La valeur juridique d'un cahier des charges fonctionnel n'est pas automatique. Elle se construit par des choix précis au moment de la formation du contrat : intégration explicite comme annexe contractuelle, validation formelle par les deux parties, versionning rigoureux, procédure de modification par avenant, et articulation avec une procédure de recette clairement définie. Ces précautions ne ralentissent pas un projet. Elles lui donnent un cadre qui protège les deux parties : le client contre un prestataire qui livrerait autre chose que ce qui était demandé, le prestataire contre un client qui reformulerait ses attentes a posteriori en se fondant sur un document qu'il n'a jamais formalisé. Si vous souhaitez faire auditer la documentation contractuelle d'un projet informatique en cours ou préparer le cadre contractuel d'un projet à venir, nous sommes disponibles pour vous accompagner.