Obligation de délivrance : enjeux et bonnes pratiques pour les acheteurs IT

Qu’est-ce que la délivrance conforme ?

L’article 1604 du Code civil définit la délivrance comme le transport de la chose vendue en la puissance et possession de l’acheteur.

« L’obligation de délivrance ne se réduit pas à la remise d’un logiciel, d’un serveur ou d’un matériel : elle suppose la mise à disposition d’un produit ou d’un service apte à remplir la fonction prévue par le contrat. »

Ce principe, apparemment simple et transposable en matière de services, prend une dimension particulière dans le domaine informatique. La délivrance ne se réduit pas à la remise matérielle d’un logiciel, d’un serveur ou d’un matériel : elle suppose la mise à disposition d’un produit ou d’un service apte à remplir la fonction prévue par le contrat.

L’obligation peut prendre des contours différents selon l’objet du contrat. Dans les licences logicielles, elle recouvre non seulement la remise du programme dûment exploitable, mais aussi celle de sa documentation qui en constitue le corollaire. Dans les prestations de services, comme un développement spécifique ou l’intégration d’un ERP, elle implique la livraison d’une solution opérationnelle, conforme aux spécifications convenues. Dans les contrats d’hébergement ou de SaaS, la délivrance correspond à la mise à disposition effective du service, assortie du respect des engagements de disponibilité et de performance.

La jurisprudence rappelle régulièrement que l’obligation de délivrance est une obligation essentielle : elle détermine si le fournisseur a exécuté son engagement. L’appréciation de la délivrance conforme se fait avant tout au regard du contrat. Cahier des charges, spécifications fonctionnelles et techniques, SLA sont autant de documents qui fixent le périmètre des obligations du fournisseur.

Comment s’apprécie la délivrance conforme ?

Trois critères essentiels sont à retenir.

Le premier est la conformité fonctionnelle : le produit doit remplir les fonctions prévues.

À titre d’exemple, dans une décision du 22 mars 2024, la Cour d’appel de Paris a jugé, dans le cadre de la fourniture d’un système logiciel ERP, que celle-ci ne pouvait être considérée comme conforme alors que le procès-verbal, emportant formellement recette définitive, comportait plus de trente réserves, dont certaines touchaient à des fonctionnalités essentielles. Elle estime que ce document ne pouvait donc valoir acceptation définitive, d’autant qu’aucune recette provisoire n’avait été réalisée alors que pourtant prévue contractuellement. Par ailleurs, la mise en production de l’outil ne pouvait valoir démonstration de la conformité, dès lors que l’entreprise cliente avait été contrainte d’exploiter temporairement la solution pour ne pas cesser son activité.

Ensuite, la conformité technique : la fourniture doit être opérationnelle et accompagnée des éléments indispensables à son déploiement ou à sa mise en production.

Dans le cadre de la fourniture d’une application dont le prestataire alléguait que le déploiement relevait de son client en ayant recours à un logiciel open source, la Cour d’appel de Toulouse a, dans un arrêt du 27 février 2024, jugé que le fournisseur avait manqué à son obligation, l’application ne pouvant être déployée ni exploitée en raison de bugs multiples et d’une documentation lacunaire. La défense consistant à renvoyer au client l’installation autonome de l’application a été rejetée, alors qu’il appartenait au fournisseur, en exécution de son obligation d’information, de fournir une solution complète, en précisant notamment les éléments open source utilisés et leurs licences.

Le troisième critère est la conformité temporelle. Le respect des délais constitue souvent une condition déterminante. Un projet livré en retard peut être jugé non conforme, même si les deux premiers critères sont remplis, dès lors que le retard emporte des conséquences économiques négatives pour le client.

Quelles obligations pour les parties ?

L’obligation de délivrance place le fournisseur au premier plan. En tant que professionnel, il doit livrer un produit conforme aux spécifications, dans les délais convenus, accompagné d’une documentation claire et, le cas échéant, d’une assistance à la mise en exploitation.

« Le client n’est pas indemne de toutes responsabilités. Il doit définir ses besoins avec précision, collaborer activement au projet, et signaler les anomalies constatées lors de la recette. »

En ce sens, la Cour d’appel de Bordeaux a, dans un arrêt du 2 décembre 2024, jugé qu’un fournisseur de systèmes de caisse avait manqué à son obligation de délivrance et à son devoir de conseil en livrant des écrans tactiles et une interface de commande inadaptés aux besoins de son client restaurateur. Le fournisseur, professionnel averti, ne pouvait se retrancher derrière l’absence d’un cahier des charges détaillé : il lui appartenait d’aider son client à formaliser ses besoins.

Pour autant, le client n’est pas indemne de toutes responsabilités. Il doit définir ses besoins avec précision, collaborer activement au projet en fournissant les informations et les ressources nécessaires, et signaler les anomalies constatées lors de la recette.

L’acceptation sans réserve d’une livraison incomplète ou l’absence de formulation de tout grief risquent de compromettre toute réclamation ultérieure. Toutefois, l’obligation de coopération du client ne saurait exonérer le fournisseur de ses propres manquements. Dans son arrêt du 27 février 2024 précité, la Cour d’appel de Toulouse souligne que, même si le client n’avait pas toujours participé aux tests, le fournisseur restait responsable, faute d’avoir recouru aux mesures qui s’offraient à lui contractuellement, comme la cessation du contrat ou la conclusion d’un avenant.

Si l’absence de coopération ou la passivité du client est de nature à atténuer la responsabilité du fournisseur, elle ne saurait l’effacer alors que la charge de l’obligation repose avant tout sur celui-ci.

Quels leviers en cas de dérive ?

En cas de manquement par le fournisseur à son obligation de délivrance, des leviers contractuels peuvent être mobilisés comme des pénalités de retard, des garanties contractuelles, des clauses de sortie, voire d’anéantissement du contrat.

Rappelons néanmoins ici l’importance de la prévention de la dérive par une gestion étroite de projet !

Une bonne gestion de projet se doit d’inclure un suivi concomitant du contrat qui a présidé à la fixation première de l’équilibre des responsabilités des parties en fonction d’un périmètre opérationnel et financier donné. De la théorie à la pratique, le fossé reste grand dans de nombreux cas.

L’instauration d’un véritable secrétariat juridique de projet, au fil de l’exécution de celui-ci, constitue le seul moyen probant de reconstitution des responsabilités en cas de dérive.

« L’instauration d’un véritable secrétariat juridique de projet, au fil de l’exécution de celui-ci, constitue le seul moyen probant de reconstitution des responsabilités en cas de dérive. »

En pratique, tentons de caler les outils juridiques sur les outils opérationnels. En ce sens, sous réserve d’une procédure claire fixée au sein de la référence contractuelle et d’une validation commune par les parties, certains procès-verbaux (à vocation technique) peuvent utilement s’intégrer au contrat en y valant avenant.

De la même manière, des alertes permettent de s’interroger sur leurs éventuelles incidences en termes contractuels et donner lieu à formalisation. Loin de les ériger en outils de police, utilisons-les pour provoquer une concertation, nécessaire, afin d’anticiper les dérapages.

L’intérêt des procédures d’escalade n’est pas à minimiser. En cas de différend en germe, elles permettent qu’il ne reste pas cantonné aux équipes terrain, mais soit rapidement porté au niveau décisionnel approprié, qu’il s’agisse des directions métiers, de la DSI ou du management.

Ce mécanisme contribue à débloquer des situations avant qu’elles ne dégénèrent en contentieux et participe au maintien d’une relation de confiance entre le client et le fournisseur dans l’intérêt des deux parties.

Bonnes pratiques

Au-delà de l’analyse juridique, l’obligation de délivrance doit se traduire, pour la DSI, par une série de réflexes opérationnels :

1. S’assurer de la définition claire des besoins afin de délimiter l’étendue de l’obligation de délivrance, positivement d’abord, mais aussi négativement (à savoir ce qui est hors périmètre).
2. Adosser chaque étape du projet à un support écrit : cahier des charges, comptes rendus de comités, procès-verbaux de recette.
3. Formaliser les réserves en veillant à ce qu’elles soient précises, circonstanciées et suivies d’un plan de correction validé.
4. Anticiper les phases critiques du projet en organisant des points d’étape dédiés et en exigeant, si nécessaire, des tests supplémentaires.
5. Croiser gouvernance projet et gouvernance contractuelle : associer les directions métiers et juridiques, dès les premières alertes permettant de replacer les difficultés techniques dans leur cadre contractuel et de sécuriser la position de l’entreprise.

Ces bonnes pratiques ne garantissent pas l’absence de litiges, mais elles renforcent la capacité de la DSI à les prévenir, les documenter et, le cas échéant, à les résoudre.

Associé chez TaylorWessing, Marc Schuler est expert depuis plus de 20 ans en conseil et en contentieux de la propriété intellectuelle et des technologies de l’information.