[A la une] La nature de l'obligation de délivrance de logiciels informatiques

Les engagements informatiques supposent bien souvent, on le sait, l'intervention d'un nombre important d'acteurs, chacun contribuant, à sa manière, à la réalisation du projet informatique. Or, précisément, à la suite des développements consacrés ici même à ces questions la semaine dernière, il paraît désormais utile de s'interroger sur la nature de l'obligation de délivrance qui pèse sur le fournisseur de logiciels informatiques (I). Il convient tout de même, au préalable, d'insister sur le rôle joué par le maître de l'ouvrage, tant il est susceptible d'exercer, à cet égard, une influence sur la réponse à apporter à la question, les obligations des parties ne pouvant être comprises que les unes par rapport aux autres (II).

I. Les obligations du maître de l'ouvrage

Le maître d'ouvrage est tenu à une triple obligation. Il doit, d'abord et fort logiquement, procéder au paiement du prix. La question n'appellera pas ici d'observations particulières dans la mesure où cette obligation n'est pas spécifique à la matière envisagée et ne fait l'objet que de quelques aménagements. De façon plus spécifique, le maître d'ouvrage est tenu d'un véritable devoir de collaboration tout à fait essentiel tant au stade de l'élaboration du contrat qu'au stade de son exécution (A). En outre, il a, à la livraison du matériel, un devoir de recette consistant dans la vérification du produit livré, le prononcé de la recette marquant l'acceptation du maître d'ouvrage (B).

A. Devoir de collaboration

S'il est exact que dans tout contrat, particulièrement lorsque l'objet de celui-ci est complexe ou lorsque le contrat est conclu intuitu personae, une obligation de coopération, qui serait en quelque sorte la conséquence de l'obligation pour les contractants d'exécuter les conventions de bonne foi, pèse sur le créancier, il reste que cette obligation est tout spécialement importante en matière informatique. On sait, à cet égard, que le devoir de collaboration mis à la charge du maître d'ouvrage le contraint d'abord à analyser et à exprimer ses besoins. Afin que le fournisseur d'informatique puisse s'acquitter de son obligation d'information et de conseil, c'est-à-dire qu'il puisse proposer à l'utilisateur la solution la plus apte à satisfaire ses besoins, il est nécessaire qu'il puisse les comprendre et il revient donc, en conséquence, au client de procéder à leur analyse et à leur expression afin de pouvoir les communiquer à son partenaire, d'où l'intérêt du cahier des charges.

Si, donc, le devoir de coopération prend la forme, lors des négociations, d'une obligation d'information permettant l'élaboration d'un référentiel commun (voir not. CA de Paris, 26 juin 1998 : Juris-Data n° 1998-024441, retenant les difficultés de formalisation de la part du client de ses besoins réels), le client étant tenu de spécifier les objectifs à atteindre (Cass. com., 7 janvier 1997, n° 94-19458, N° Lexbase : A1564A4P), ce devoir se poursuit lors de la phase de mise au point du projet (Cass. com., 11 janvier 1994, n° 92-11659 N° Lexbase : A1566A4R : expertises des systèmes d'information 1994). À ce titre, le client doit fournir toutes les données qu'il possède, susceptibles d'intéresser la réalisation du projet, examiner les plans et les documents qui lui sont fournis par la société informatique, faire connaître ses observations (CA de Paris, 26 juin 1998 : Juris-Data n° 024441, relevant, pour exonérer le fournisseur, que le retard dans les délais de livraison était dû à la négligence du client et, particulièrement, dans le manquement de celui-ci à son obligation de dialogue et de collaboration).

Enfin, le devoir de collaboration du maître d'ouvrage se prolonge encore durant la phase d'installation et de mise en route du système (Cass. com., 11 janv. 1994, préc.N° Lexbase : A1566A4R). Il doit en effet, notamment, prévenir son partenaire de toute information utile, faciliter la coordination des personnels, ... Le devoir de collaboration du client/maître d'ouvrage, implique, outre la réalisation du cahier des charges :

- la participation aux différentes réunions (comité de projet, comité de pilotage,  ...) ;

- la validation des comptes rendus des réunions ;

- la validation des spécifications fournies par le maître d'oeuvre ;

- la réalisation des scénarios de tests et des jeux d'essais ;

- la ou les recettes et l'établissement des fiches d'anomalies ;

- la mise en production.

Il importe donc de retenir que l'informatisation d'une entreprise exige, tant dans la phase de conception que dans la phase de mise en place, une étroite collaboration entre le fournisseur et l'utilisateur. Alors que le premier renseigne, met en garde, conseille, le second doit informer, participer et s'impliquer dans le projet. On a d'ailleurs pu comparer l'informatisation d'une entreprise à une greffe que celle-ci subirait. La métaphore est juste, le succès de l'opération dépendant tout à la fois de la qualité du greffon, de l'habileté du praticien et de l'intérêt que le sujet receveur peut porter à sa guérison ou à sa survie.

B. Devoir de recette

Le monde informatique a adopté le terme "recette" dont l'emploi est tombé en désuétude dans le monde économique. Au sens traditionnel, le terme de recette désigne l'action de recevoir et de vérifier des produits (marchandises, constructions, fabrications) mais aussi des sommes d'argent (la recette fiscale). La procédure de recette comprend plusieurs phases. Ainsi, le maître d'ouvrage doit-il d'abord effectuer des tests, identifier des anomalies et procéder à l'élaboration de fiches d'anomalies. Une fois cette étape terminée, au terme de laquelle les anomalies auront été corrigées, le prononcé de la recette sera possible, celui-ci n'étant acquis que par la signature de procès-verbaux qui en font la preuve.

Rappelons en effet qu'il est classique que la solution fournie au maître d'ouvrage nécessite, compte tenu notamment des contraintes inhérentes à la structure informatique existante de la société cliente, un certain nombre d'ajustements. Lorsque, en effet, le client ne peut modifier ses propres règles de gestion, ce qui correspond à l'hypothèse la plus fréquente, l'intégration de la solution dans le système informatique de l'entreprise implique de procéder à l'adaptation de celui-ci. Ces opérations d'adaptation, de paramétrage et d'intégration supposent une restructuration du système et nécessitent une étroite collaboration entre le fournisseur et le client, dont la participation active est, on le sait, requise. Il a ainsi, entre autres, l'obligation de procéder aux tests de recette, d'identifier les dysfonctionnements, les non-conformités, les problèmes de performance et de matérialiser ces malfaçons dans les fiches d'anomalies qu'il soumettra au fournisseur, permettant à ce dernier de procéder aux corrections nécessaires.

Lorsque le fournisseur livre pour recette une version, il a au préalable effectué les tests unitaires et les tests d'intégration. Le client procède à des tests de recette provisoire (un ou plusieurs selon le nombre de lots). Si les résultats sont satisfaisants, le client les met en production et les tests effectués après celle-ci ne sont plus des tests à proprement parler, mais des transactions de production.

Il est essentiel de distinguer les anomalies constatées par les tests du client des fautes du fournisseur dans la réalisation du projet. En effet, si le client peut s'exonérer en démontrant qu'il a relevé les anomalies faisant obstacle à l'utilisation prévue de la solution, le fournisseur pourra corrélativement s'exonérer :

- soit en démontrant qu'il a traité ces anomalies ;

- soit par l'établissement d'une faute du client chez l'utilisateur (utilisation non conforme de la solution) ;

- soit par la démonstration d'une mauvaise interprétation des spécifications contractuelles ;

- soit par une cause étrangère au périmètre d'intervention du fournisseur.

Pendant le déroulement du projet, l'accroissement du nombre de fiches d'anomalies n'est pas forcément révélateur d'un système défectueux, mais au contraire l'indice selon lequel la tâche du client maître d'ouvrage se réalise convenablement. En revanche, ce qu'il est pertinent d'identifier n'est pas le nombre exorbitant de fiches d'anomalies qui ont pu être produites depuis le début du projet mais le nombre de ces fiches non corrigées à un instant donné ou restées sans réponse de la part du maître d'oeuvre. Il reste que, si le nombre d'anomalies est tel qu'il ne permet pas d'envisager une quelconque recette, le client pourra demander la résolution du contrat pour inexécution.

II. L'obligation de délivrance du fournisseur

L'obligation de délivrance comporte en effet l'obligation de délivrer une chose conforme à ce qui avait été convenu (1). Cette exigence pose, en tant que telle, un certain nombre de difficultés bien connues (voir déjà, sur cette question, H. Bitan, Contrats et litiges en informatique- La délivrance du logiciel, préf. M. Armand-Prévost, PUAM, 1996, et les références citées). La seule question qui nous retiendra ici est de savoir si, en tout état de cause, le fournisseur est tenu de délivrer une chose conforme quoi qu'il advienne ou si, plus modestement, il suffit qu'il ait mis en oeuvre tous les moyens susceptibles de permettre d'atteindre un tel résultat ?

On retrouve par là même la question de la nature de l'obligation de délivrance : moyens ou résultat ? La question est d'autant plus importante qu'en dehors de la seule délimitation de l'obligation de délivrance, elle emporte de nombreuses conséquences du point de vue de la preuve de la faute contractuelle (sur cette question, voir not. F. Terré, Ph. Simler et Y. Lequette, Droit civil, Les obligations, Précis Dalloz, 8ème éd., 2002, n°s 577 et s., B. Starck, H. Roland et L. Boyer, Droit civil, Les Obligations, t. II, Le contrat, 6e éd. par H. Roland et L. Boyer, Litec, 1998, nos 1180 et s.). Alors que le créancier d'une obligation de moyens doit, pour pouvoir engager la responsabilité contractuelle du débiteur, prouver la faute de celui-ci, il n'a qu'à établir l'inexécution contractuelle, donc le fait que le résultat promis n'a pas été atteint, lorsque le débiteur est tenu, plus sévèrement, d'une obligation de résultat, le débiteur ne pouvant plus s'exonérer que par la preuve d'une cause étrangère. Il est vrai qu'il existe, entre ces deux catégories, des nuances, d'où la reconnaissance, notamment, d'obligations de moyens renforcées ou de résultat allégée, voire, dernier cas envisageable, de résultat renforcée. Dans le premier cas, la charge de la preuve est inversée, et il existe une présomption simple de faute du débiteur ; dans le deuxième cas, le débiteur peut s'exonérer non seulement par la preuve de la cause étrangère comme dans l'obligation de résultat dans son acception la plus pure, mais aussi par la preuve de son absence de faute, le fait du créancier. Notons enfin, que dans le dernier cas, l'exonération par la cause étrangère est écartée, que ce soit partiellement ou totalement (mais alors en vérité, c'est d'une garantie qu'il s'agit, dont le mécanisme échappe à la logique du droit de la responsabilité).

Sans ici revenir sur la question de la distinction de ces deux catégories d'obligations, on rappellera que, schématiquement, deux critères semblent aujourd'hui retenus par la jurisprudence dans la mise en oeuvre de la distinction (sur lesquels voir not. F. Terré, Ph. Simler et Y. Lequette, op. cit., et la jurisprudence citée). Le premier est celui de l'aléa. Ainsi, lorsque l'exécution de l'obligation est entachée d'une forte part d'aléa, c'est-à-dire qu'elle comporte une grande part de risque, le débiteur ne peut promettre ou garantir un résultat, ce qui explique que l'obligation ne soit alors que de moyens. Le second critère est celui de la part d'initiative laissée au créancier dans l'exécution de la prestation qui lui est due. Si celui-ci s'en remet à son cocontractant, et perd ainsi son autonomie, il n'a qu'un rôle passif dans l'exécution de l'obligation qui lui est due qui justifie que l'obligation soit de résultat. En revanche, lorsque l'on attend de lui une certaine participation et donc qu'il a un rôle actif dans la réalisation de l'obligation, celle-ci sera de moyens. La solution est cohérente. On ne peut en effet considérer que le débiteur soit en mesure de garantir un résultat déterminé, précis, toutes les fois que l'atteinte de cet objectif dépend, au moins pour partie, de l'attitude du créancier.

Transposées dans le domaine ici considéré, ces observations permettent de voir dans l'obligation de délivrance du fournisseur de matériel informatique, a fortiori en cas de délivrance de progiciels ou de logiciels spécifiques, une obligation de moyens et non pas de résultat, et ce en raison du rôle actif joué par le créancier dans l'exécution de cette obligation (voir, récemment en ce sens, CA de Toulouse, 25 janvier 2001 : Juris-Data n° 2001-135138). Faisant application des critères plus haut rappelés, il est en effet permis de considérer que si l'obligation de délivrance impose au fournisseur de mettre à la disposition de son client un matériel conforme aux dispositions du contrat, la portée de cette obligation reste limitée aux diligences de ce dernier. Cependant, il ne peut s'agir que d'une obligation de moyens renforcée puisque c'est au maître d'oeuvre de démontrer qu'il n'a commis aucune faute dans la réalisation de ses obligations et, notamment, dans les réponses et corrections des anomalies qui lui auront été soumises par le maître d'ouvrage (Voir déjà en ce sens, H. Bitan, La délivrance des progiciels de gestion intégréé ERP : Gaz. Pal. 15 -17 juill. 2001, n° 196, p. 10 et s.).

On l'aura compris, deux des traits essentiels du régime de l'obligation pesant sur le fournisseur commandent la qualification d'obligation de moyens renforcée. D'abord, comme nous l'avons vu, le rôle actif du créancier dans l'exécution de l'obligation, entachant celle-ci d'une part certaine d'aléa, est, à cet égard, sans équivoque. Ensuite, quant à l'effet de l'obligation, nous avons montré que la participation du créancier à l'exécution de l'obligation devait le conduire à révéler les anomalies du système en place et, par là même, permettre, lorsque les anomalies détectées ne sont pas corrigées, ou lorsque la correction est sans effet, d'établir la faute contractuelle du débiteur de l'obligation de délivrance (voir supra.). Or, du point de vue de la preuve, on retrouve là l'effet juridique de l'obligation de moyens renforcée, la charge de la preuve de l'inexécution contractuelle fautive du débiteur incombant en ce cas à ce dernier.

---

(1) Voir not. CA de Lyon, 2 octobre 1998 : Juris-Data n° 114466, retenant la responsabilité du fournisseur pour avoir mis à la disposition du client un système de gestion informatique inexploitable en raison de dysfonctionnements importants; sur la responsabilité du concepteur, appelé en garantie par le fournisseur, CA de Lyon, 2 octobre 1998, préc.

Add., CA de Paris, 26 juin 1998, Juris-Data n° 024441, décidant que la responsabilité du fournisseur informatique était engagée pour avoir livré un logiciel différent de celui convenu au contrat ; Cass. com., 5 décembre 2000, (N° Lexbase : A6883A3C) : Juris-Data n° 007351, relevant que la livraison n'avait pas été complète et conforme aux engagements.

© Reproduction interdite, sauf autorisation écrite préalable