Dans le cadre des projets informatiques, la recette (ou « réception ») des travaux est une étape critique, car elle doit permettre de contrôler que ce qui est livré correspond à ce qui a été commandé, et plus précisément, que la solution logicielle répond à l’ensemble des besoins exprimés par le client, et qu’elle fonctionne correctement. Mais vaut-elle décharge totale de responsabilité ?
Rappel de la notion de recette
La notion de « recette » d’une solution informatique est héritée des règles du droit de la construction, qui encadrent la réception de l’ouvrage. La recette a pour principale fonction d’acter de la conformité de que livre le prestataire, et « purge » donc le livrable des critiques que le client pourrait formuler.
En principe, le prononcé de la recette décharge le prestataire de sa responsabilité en cas de non-conformité de la solution aux attentes du client. Il incombe donc au client d’effectuer l’ensemble des vérifications adéquates pour s’assurer que la solution répond bien à ses besoins – du moins tels qu’ils ont été convenus avec le prestataire, et tels que l’expertise de ce dernier permettait d’espérer.
Mais ce principe, simple en apparence, revêt en réalité une grande complexité, comme en témoignent le nombre de projets informatiques qui achoppent au moment du prononcé de leur recette.
Tout d’abord, la recette dépend de la détermination contractuelle précise du référentiel de conformité, c’est-à-dire du périmètre auquel le prestataire s’est engagé à répondre. En d’autres termes, que vérifie-t-on au moment de la recette ? Par rapport à quels critères objectifs doit-on considérer que la solution fournie est conforme, ou au contraire, qu’elle ne répond pas à ce qui a été convenu ? Quel est le degré de détail à prendre en compte ?
Il s’agit ici d’encadrer soigneusement l’obligation de délivrance conforme, qui caractérise les contrats de projets informatiques, et qui est l’objet de nombreux débats devant les juges selon ce à quoi s’était contractuellement engagé le professionnel, et selon les décisions du client lui-même.
Ensuite, la recette doit s’effectuer de manière pertinente, c’est-à-dire à partir de cas de tests qui permettront effectivement aux utilisateurs du client de s’assurer que la solution répond aux besoins exprimés. Usuellement, c’est le client qui prépare ses jeux de tests, mais il est préconisé de se faire assister du prestataire, ou d’une AMOA (assistance à maîtrise d’ouvrage), pour s’assurer que ces cas de tests couvriront l’ensemble des utilisations à venir de la solution.
C’est capital, car la recette a un « effet cliquet » important, qui permet de passer à la phase suivante du projet, mais qui limite aussi la capacité du client à revenir ultérieurement sur la validation ainsi prononcée. La règle, qui comme on le verra plus bas comporte des exceptions notables, est qu’une fois la recette prononcée, il n’est plus possible d’arguer d’une non-conformité, d’un oubli ou d’un manque par rapport aux besoins exprimés.
L’étape de la recette est d’autant plus importante qu’elle conditionne généralement la facturation de portions importantes du prix du projet informatique.
De plus, ce n’est qu’une fois la recette définitivement prononcée que peuvent débuter d’éventuelles prestations de maintenance payante, ou parfois préalablement, une garantie contractuelle (qui s’analyse en correction gratuite, pendant une période provisoire, des anomalies susceptibles d’apparaître après la signature du procès-verbal de recette).
Dans les faits, on distingue souvent la « vérification d’aptitude au bon fonctionnement » (VABF), sorte de recette « à blanc » permettant de vérifier que les fonctionnalités répondent aux besoins exprimés, et la « vérification de service régulier », qui permet de contrôler le bon fonctionnement de la solution en production avec l’ensemble des données chargées et des utilisateurs connectés.
Cette vérification de conformité s’effectue très différemment selon la méthodologie du projet. Dans les projets dits « en cycle V », le client doit d’abord vérifier que les spécifications préparées par l’intégrateur correspondent à ses besoins fonctionnels, puis que la solution livrée répond en tous points aux spécifications validées. Dans les projets plus « agiles », les utilisateurs contrôlent en temps réel que le comportement de la solution, construite par incréments successifs, correspond aux cas d’usage définis progressivement. Là encore, le contrat doit refléter fidèlement la façon dont le projet est mené concrètement.
La recette peut être prononcée sans réserve si, dans le meilleur des mondes, la solution répond en tous points aux besoins et ne présente aucun dysfonctionnement. Elle peut être prononcée avec réserves, si globalement la solution répond aux besoins mais présente des anomalies plus ou moins conséquentes. Elle peut enfin être ajournée ou refusée, si l’état du livrable est tel qu’il est impossible d’envisager de l’utiliser.
Mais quelle que soit la méthode mise en œuvre et le type de projet informatique, la recette est une étape nodale à laquelle doit être apporté le plus grand soin, tant dans les clauses du contrat que sur le terrain.
Les écueils de la procédure de recette
Premier écueil : les recettes, voire les mises en production précipitées. Dans de nombreux cas, le client, pressé par le temps (et parfois par le prestataire), décide de prononcer une recette partielle ou de mettre en production un périmètre livré mais qui présente encore des non-conformités.
A cet égard, la mise en production d’une solution pourtant imparfaite n’est pas sans conséquences sur l’acquisition de la recette (ex : CA Nîmes, 17 nov. 2023, n° 22/00107 ; CA Rennes, 12 déc. 2023, n° 22/00275 ou encore CA Douai, 18 janv. 2024, n° 22/00994). Souvent, la solution est réputée validée du seul fait de sa mise en service.
Or, compte tenu de l’effet cliquet de la recette, il est vivement recommandé de ne jamais la prononcer (i) tant que le prestataire n’a pas livré l’intégralité du périmètre, du module ou de la version soumise à recette, (ii) tant que les utilisateurs du client n’ont pas été en capacité de tester l’ensemble des fonctionnalités fournies, d’abord en VABF, puis en production (VSR) avec les données chargées et les flux interfacés, ni (iii) tant que des anomalies bloquantes empêchent de dérouler les tests jusqu’au bout.
Si le contrat peut prévoir que des anomalies « mineures » ne doivent pas être un obstacle au prononcé de la recette (et relèveront de la garantie ultérieure), en revanche, tant que subsistent des anomalies bloquantes ou majeures, la recette doit être refusée. Le procès-verbal de recette doit mentionner les réserves correspondantes, à charge pour le prestataire de les corriger avant de présenter de nouveau la solution en recette.
Il est donc important d’éviter toute précipitation, de même que toute recette « tacite », cela fût-il au prix de retards par rapport à des plannings parfois contraints. A cet égard, il est courant que les contrats précisent que la « mise en production de la solution vaudra recette ».
Cette dernière affirmation peut effectivement paraître logique : si le client prend le risque de mettre la solution fournie en production, c’est qu’il estime que son fonctionnement n’impactera pas son activité, et donc qu’il présume lui-même qu’elle est conforme.
Cependant, la réalité des projets informatiques complexes diffère un peu de cette position de principe. L’enchainement des phases, la nécessité d’avancer, la pression des utilisateurs ou de la hiérarchie, parfois la pression du prestataire lui-même, font parfois brûler les étapes et conduisent à des mises en production rapides sans avoir d’abord relevé et traité toutes les anomalies. Le client est alors exposé au risque de ne plus pouvoir invoquer ces anomalies puisqu’il les a en quelque sorte « couvertes » lui-même.
Si de manière pragmatique, les contrats peuvent envisager des mises en production anticipées, cela devrait alors être en indiquant, justement, qu’elles ne valent pas recette (ou a minima, que le prestataire doit impérativement corriger les anomalies détectées dans un délai contraint). Cependant, il est vivement recommandé de ne jamais accepter une telle équivalence entre « mise en production » et « recette conforme ».
C’est d’autant plus important que dans les projets complexes, la mise en production est le nécessaire préalable à la phase de VSR, qui sert justement à tester la solution en exploitation réelle : c’est dire que malgré la mise en production, la procédure de recette n’est toujours pas achevée. Il est par conséquent contradictoire de prétendre que cette mise en production vaudrait recette.
De plus, quand bien même le contrat stipule que la mise en production vaudra recette, la jurisprudence vient corriger les excès qui peuvent en résulter : dans un arrêt du 6 décembre 2017 (n°16-19.615), la Cour de cassation a en effet rappelé que « si les contrats sur la preuve sont valables lorsqu’ils portent sur des droits dont les parties ont la libre disposition, ils ne peuvent établir au profit de l’une des parties une présomption irréfragable ». En l’espèce, dans la mesure où le client rapportait la preuve que le prestataire ne lui avait pas livré un progiciel opérationnel et exempt d’anomalies, la Cour a estimé que le client avait renversé la présomption de recette tacite résultant de l’absence de réserve conformément au formalisme contractuellement prévu.
Second écueil, la profondeur des tests. En effet, la recette s’entend généralement des tests fonctionnels menés par les futurs utilisateurs de la solution (ou souvent, des « utilisateurs clés » qui interviennent à ce stade), dits « UAT ». Ces utilisateurs doivent donc vérifier le comportement des fonctionnalités, le traitement des données, les résultats obtenus, les interdépendances fonctionnelles, et relever les traitements erronés, blocages, incohérences ou dysfonctionnements techniques.
Mais la recette ne permet généralement pas à un utilisateur métier de s’assurer de la qualité technique des développements logiciels effectués. La recette n’est pas un audit de code, et l’utilisateur n’est pas un expert du langage informatique. Il est donc possible que malgré le prononcé d’une recette, des malfaçons existent dans le code source. Il peut s’agir de choix structurants des développeurs qui permettent à l’instant T de faire fonctionner un module, mais qui risquent avec le temps d’entraîner des limitations techniques, des surcharges au niveau du cache, des régressions fonctionnelles ou d’autres problèmes de maintenabilité future.
Or, puisque la recette ne permet pas d’investiguer en profondeur les aspects techniques de la solution, elle ne devrait pas pouvoir être opposée par le prestataire à un client qui se plaint de dysfonctionnements ultérieurs liés à ces aspects techniques « profonds ». On retrouve ici la notion de « vices cachés » qui peuvent entacher la vente de biens comme le contrat de louage d’ouvrage (cf. infra).
Valeur absolue ou relative recette ?
Plus largement, il apparaît que même si le client signe le procès-verbal de recette, l’effet de « purge » ne jouera pas nécessairement s’il est en capacité de démontrer que nonobstant cette signature, des anomalies existaient effectivement à cette date. Et ce, quand bien même il ne les découvre qu’après celle-ci.
C’est notamment ce qu’illustre une décision de la Cour d’appel de Versailles du 5 avril 2025 (n°22/06503) au sujet du développement d’un site web – mais cette approche vaut pour tout type de développement informatique : solution logicielle spécifique, application mobile, etc.
En l’espèce, le client avait bel et bien signé un procès-verbal de réception (sans doute hâtivement), mais des dysfonctionnements étaient apparus dans les mois suivants. Le prestataire arguant de l’écoulement de la garantie, refusait de corriger ces défauts sauf à facturer une prestation complémentaire d’assistance technique. Il soulignait en outre qu’il n’était tenu que d’une obligation de moyens.
Or, la Cour d’appel a considéré que le prestataire avait manqué à son obligation de délivrance conforme, en posant que le prestataire « ne démontre pas avoir remédié à ces différentes anomalies qui s’opposaient au prononcé de la recette puisque le contrat la soumettait à l’absence de subsistance de toute anomalie bloquante ou majeure et s’agissant des anomalies mineures, à l’établissement d’un plan d’action à mener pendant la période de garantie, dont il n’est pas justifié. »
Un débat était apparu sur l’objet même du procès-verbal de réception, le client arguant du fait qu’il n’avait signé qu’un simple « bon de livraison » de la solution alors que le contrat prévoyait bien un contrôle de conformité et la correction des anomalies par le prestataire.
Le prestataire, quant à lui, ne niait pas la réalité des anomalies, mais se contentait d’expliquer qu’elles avaient été signalées bien après le prononcé de la réception ainsi qu’après l’échéance de la période de garantie. Selon lui donc, leur correction ne pouvait intervenir que moyennant la commande d’une prestation payante d’assistance technique.
La Cour d’appel a constaté la réalité et la gravité des dysfonctionnements, pour conclure à l’absence de délivrance conforme, ouvrant la voie à l’indemnisation des préjudices invoqués par le client et même à la restitution du prix payé en conséquence de la résolution du contrat. C’est au prestataire qu’elle a reproché de n’avoir pas mis en œuvre la procédure contractuelle de recette.
Cette décision confirme une jurisprudence établie, selon laquelle l’obligation de délivrance du fournisseur ne pourra être considérée comme parfaitement et définitivement exécutée que si le progiciel a été installé, testé et mis en production, avec pour terme de ce processus une recette contradictoire attestant que le progiciel fonctionne et répond aux besoins du client.
En outre, cette jurisprudence confirme que l’obligation de délivrance du vendeur de « produits complexes » n’est « pleinement exécutée qu’une fois réalisée la mise au point effective de la chose vendue ». S’agissant d’un logiciel, cette mise au point s’entend de l’installation et du paramétrage du logiciel conformément aux besoins de l’acheteur résultant des spécifications contractuelles (comme rappelé par exemple par la Cour de cassation dans une décision du 31 janvier 2018, 16-16.634 16-22.097).
Force est toutefois de reconnaître que cette notion de « mise au point », initialement forgée au sujet des matériels informatiques, est susceptible d’interprétation s’agissant de logiciels complexes. En l’espèce en effet, la procédure contractuelle n’avait manifestement pas été respectée, et la Cour d’appel de Versailles l’a inscrit au passif du prestataire – professionnel de l’informatique qui n’aurait manifestement pas dû se contenter d’une validation purement formelle de la remise de la solution.
Mais dans de nombreux cas, la recette est bel et bien mise en œuvre par le client, au moins partiellement, et conduit à la signature de procès-verbaux, avec réserves, voire sans réserves (ce qui est encore plus problématique si effectivement demeurent des dysfonctionnements). Le danger réside dans des procédures de recette expéditives qui n’ont pas réellement tout testé.
Or, dès lors que la solution fournie a fait l’objet de prestations de personnalisation (paramétrages spécifiques, développements logiciels pour répondre précisément aux pratiques du client, interfaçages et modifications), la recette ne doit en aucun cas constituer un simple « bon de livraison », et doit impérativement donner lieu à un contrôle complet de la conformité et du bon fonctionnement du produit.
En outre, la notion de « mise au point » peut également se rapporter à l’obligation de recette interne par le prestataire, préalable à la livraison au client en recette utilisateur. Cette recette interne (tests « usine », contrôle de non-régressions, tests automatisés, etc.) est une pratique courante en matière de développement logiciel, mais que le prestataire peut parfois escamoter. Il est vivement recommandé de prévoir dans le contrat cette étape intermédiaire capitale, et de ne surtout pas la court-circuiter lors des phases d’exécution.
Par ailleurs, la recette utilisateurs ne peut permettre que de déceler des anomalies « apparentes », c’est-à-dire celles dont l’utilisateur peut se convaincre en utilisant normalement les fonctionnalités de la solution qui lui est soumise.
Dans une décision du 11 avril 2011 (09/05685), la Cour d’appel de Douai affirmait déjà que « la réception sans réserve ne couvre que les défauts apparents de conformité alors [que] certaines prestations prévues au contrat (…) ne pouvaient s’apprécier qu’à l’usage à plus long terme ».
La notion de « vices cachés » est relativement rarement appliquée en matière logicielle. Or, il s’agit par excellence d’un produit complexe, dont la structure et le fonctionnement profond ne peuvent être compris que par des sachants au fait des pratiques de développement technique.
L’article 1641 du Code civil dispose que : « Le vendeur est tenu de la garantie à raison des défauts cachés de la chose vendue qui la rendent impropre à l’usage auquel on la destine, ou qui diminuent tellement cet usage que l’acheteur ne l’aurait pas acquise, ou n’en aurait donné qu’un moindre prix, s’il les avait connus. ».
Le vice caché s’entend d’un défaut de conception suffisamment grave, que le client ne pouvait pas déceler à l’usage normal du produit, et qui le rend impropre à cette utilisation. Concrètement, il peut s’agir d’erreurs de code qui se révèleront par exemple lors de montées en charge, lors de mises à jour, ou qui seront révélées par des dysfonctionnements ultérieurs.
Une autre illustration a été donnée par une décision de la Cour d’appel de Bordeaux du 8 janvier 2024 (n°22/00008), dans laquelle la Cour a confirmé la résolution d’un contrat de fourniture de matériel informatique en raison des vices cachés au sein d’une nouvelle version du logiciel installé.
Ainsi, la notion de délivrance conforme (actée par le procès-verbal de recette) ne devrait pas écarter toute possibilité de recours sur la base de la garantie contre les vices cachés. Il s’agit bien de deux obligations distinctes qui pèsent sur le prestataire.
La signature par le client du procès-verbal de recette peut donc certes constituer un obstacle fort à la possibilité d’agir pour défaut de délivrance conforme, mais ne peut pas, en revanche, écarter la garantie des vices cachés – légale qui plus est.
Ainsi, même si l’action en responsabilité paraît fermée sur le fondement du défaut de conformité en raison de la signature d’un procès-verbal de recette en bonne et due forme, l’action sur le fondement des vices cachés reste ouverte – du moins dans le respect des règles qui s’imposent dans ce cas, dont l’obligation d’agir dans le délai de 2 ans à compter de la découverte du vice telle que posé par l’article 1648 du Code civil.
Malheureusement, se pose ici essentiellement une question de preuve, pour caractériser le vice caché : il est nécessaire de recourir à des auditeurs spécialisés ou des experts informatiques pour déceler ce type de malfaçons, et pour établir qu’elles sont à l’origine de dysfonctionnements apparus après la phase de recette. Il est également nécessaire de caractériser la malfaçon, par exemple par rapport aux règles de l’art en matière de codage, ou encore par rapport aux règles de développement proposées par l’éditeur du progiciel standard.
Les clauses de recette sont donc particulièrement importantes dans les contrats informatiques, en particulier lorsqu’ils portent sur des solutions spécifiques complexes. Il est impératif de les rédiger avec un très grand soin : en sachant d’abord distinguer procédure de recette (à prévoir au calendrier) et prononcé de la recette (qui dépend elle de la qualité du livrable) ; en articulant ses phases dont l’articulation cruciale entre VABF, mise en production et VSR ; en imaginant ce qui peut empêcher le prononcé de la recette ; en préservant la faculté décisionnaire du client ; et en conservant la possibilité d’agir si même une recette circonstanciée et rigoureuse n’a pas permis de déceler des anomalies significatives.
Thomas Beaugrand, Counsel
L’activité de Thomas Beaugrand porte sur le droit du numérique, le droit de la data et le droit de l’e-commerce.
Une question ?
