Droit des contrats informatiques panorama jurisprudentiel

01 juin 2007

I. Obligations du prestataire informatique

1. Obligation du prestataire informatique – Adaptation du progiciel aux besoins du client – Passage à l’an 2000 – Sévérité accrue

CA Bordeaux, 2 mai 2006,

Tradival et Lacheteau c/ Sigma Informatique, AGF et Promacef

RG n° 04/02978

En 1995, la société Promacef s’est vue confier par les sociétés Tradival et Lacheteau l’élaboration d’un cahier des charges devant servir de base à un appel d’offres ayant pour objet l’informatisation de ces deux sociétés. Sur les recommandations de Promacef, la société Sigma a mis en œuvre chez les deux sociétés clientes son progiciel Adonix, après avoir développé divers logiciels spécifiques sur la base du noyau standard.

En 1999, les clientes ont interrogé Sigma en vue de savoir si le progiciel supporterait le passage à l’an 2000. La réponse de Sigma fut d’abord de proposer une mise à jour du progiciel dans sa nouvelle version pour un coût supplémentaire. Compte tenu du refus de ses clientes, Sigma leur a proposé pour un coût bien moindre la simple adaptation du progiciel permettant le passage à l’an 2000, ce que les sociétés Tradival et Lacheteau ont alors accepté.

Ces deux sociétés ont toutefois assigné Promacef et Sigma en vue d’obtenir l’indemnisation du préjudice subi. Déboutées de leur demande en première instance, elles ont interjeté appel de cette décision.

La Cour d’appel de Bordeaux, dans son arrêt du 2 mai 2006, a fait droit à leur demande en posant comme principe que « toute société ayant conçu un logiciel a l’obligation que celui-ci au moment de sa cession réponde tant aux besoins de son client qu’aux obligations légales prévues ou prévisible pour sa durée de vie soit quatre ans, durée de l’amortissement, ou sept ans, durée d’utilisation effective ».

Elle a considéré que la société Sigma a volontairement manqué à ses obligations contractuelles en fournissant en 1996 un progiciel qui ne pouvait pas passer l’an 2000 alors même qu’elle commercialisait concomitamment un produit qui supportait ce passage, ainsi qu’en facturant à son client ce passage à l’an 2000, à quelques mois seulement de la date fatidique, et en lui proposant de passer à un progiciel permettant le passage à l’Euro dont le coût était identique à celui du progiciel initialement fourni.

Sur ce fondement, la cour a décidé que le préjudice des deux sociétés clientes qui, du fait de l’accroissement important du coût du logiciel de Sigma, s’étaient trouvées contraintes de l’abandonner avant le passage à l’an 2000 et d’investir dans un nouveau système, devait être indemnisé.

Contrairement à bon nombre de décisions concernant le passage à l’an 2000, la Cour d’appel de Bordeaux adopte ici une position véritablement stricte à l’égard du prestataire informatique, lui reprochant en particulier de s’être « comporté comme un commercial et non comme un technicien de l’informatique ».

Si l’on se réfère à la jurisprudence applicable au passage à l’an 2000, force est de constater que, jusqu’à présent, les juges avaient pu décider par principe de portée générale que le fournisseur n’était pas tenu de délivrer un logiciel d’usage perpétuel[1] et juger que le fournisseur n’est pas davantage tenu de corriger un logiciel concédé en licence en 1989 pour assurer son passage à l’an 2000, dans la mesure où, à cette époque, les difficultés de ce passage n’étaient pas encore connues[2].

Toutefois, dans le cas d’espèce, Sigma a sciemment proposé à son client un logiciel ne passant pas l’an 2000, alors même qu’elle avait à sa disposition une version du même logiciel qui passait l’an 2000.

C’est sans doute pour cette raison que la Cour d’appel de Bordeaux a été d’une grande sévérité et a dégagé un principe selon lequel l’éditeur de logiciel a l’obligation de fournir un produit qui non seulement réponde aux besoins du client mais qui soit également conforme aux obligations légales « prévues ou prévisibles » pour sa durée de vie, soit quatre ans pour la durée d’amortissement et sept ans pour la durée d’utilisation effective. On notera également que le recours à la notion d’obligation « prévisible » ajoute encore à la sévérité dont les juges ont fait preuve dans cette espèce à l’encontre de l’éditeur de logiciel.

J. MEHAUD

2. Obligation du prestataire informatique – Obligation de délivrance conforme – Conséquences de la recette

CA Lyon 3e ch. civ., 23 février 2006

Data System SA c/ Philibert Tourisme SARL

RG n° 04-04110

Une des obligations classiquement à la charge du professionnel de l’informatique est l’obligation de délivrance conforme, c’est-à-dire l’obligation de livrer un logiciel ou un matériel conforme à ce que les parties ont convenu contractuellement.

De manière symétrique, le client a l’obligation de procéder à la recette de ce qui lui a été livré. Ainsi, il doit apprécier si ce qui lui a été livré est conforme à ce qui était convenu.

La recette est donc une étape-clé de tout projet informatique, puisqu’elle emporte présomption de conformité.

À titre d’illustration, dans un arrêt du 14 avril 1992, la Cour de cassation a considéré que la cour d’appel avait eu raison d’écarter l’action en résolution engagée par un client pour non-conformité du progiciel livré, dès lors qu’elle avait fait ressortir la conformité de la chose vendue à celle commandée, du procès-verbal de réception plus de sept mois après la livraison du progiciel[3].

Toutefois, il ne s’agit que d’une présomption de conformité et les juges ont tendance à l’écarter dès lors que le client apporte la preuve que les dysfonctionnements à l’origine de la demande sont apparus postérieurement à la recette.

L’arrêt de la Cour d’appel de Lyon explique de manière détaillée pourquoi la recette prononcée par le client ne peut faire échec à sa demande.

Les faits de l’espèce sont les suivants : les sociétés Philibert Tourisme et Data System ont conclu un contrat de vente de matériels informatiques et de concession du droit d’utiliser un logiciel. Philibert Tourisme a considéré que le système installé ne remplissait pas les fonctions convenues contractuellement, a résilié le contrat et n’a pas réglé le solde des factures dont le paiement était réclamé par Data System.

La Cour d’appel de Lyon a estimé que la rupture des relations était imputable aux deux parties à hauteur de deux tiers pour Data System en sa qualité de professionnel et d’un tiers pour Philibert Tourisme. En effet, d’un côté, Data System a réalisé un système incapable d’atteindre le niveau de performance auquel pouvait légitimement s’attendre sa cliente en fonction de la définition contractuelle des prestations commandées et de l’autre côté, Philibert Tourisme a méconnu l’impératif de collaboration et a privé Data System de touteschancessérieuses de remédier aux difficultés constatées.

La cour a donc fait droit aux demandes de Philibert, et ce, même si elle avait prononcé sans réserve la recette de l’ensemble du système qui lui avait été livré.

Ellea ainsi rappelé que le prononcé de la recette du système « ne pouvait priver la société Philibert de toute possibilité de critiquer la prestation fournie par sa co-contractante, dès lors qu’à défaut de clause en ce sens, le délai d’expression des réserves ne peut être assimilé à un délai d’action et son expiration à l’acquisition de la prescription ; que le défaut de délivrance conforme ne peut être couvert par l’absence de réserve, qu’en ce qui concerne les vices apparents ou révélés dans la période antérieure à la recette définitive […] ».

Ainsi, la recette ne constitue pas une prescription abrégée et ne couvre que les vices apparents ou révélés antérieurement à la recette définitive. La recette conserve néanmoins sont intérêt pour le prestataire, puisque comme toute présomption, elle renverse la charge de la preuve et impose au client d’apporter la preuve que les dysfonctionnements qui fondent son action ont été découverts postérieurement à la recette.

S. RAMBAUD

3. Obligation du prestataire informatique – Obligation de conseil – Renforcement

CA Paris 5e ch. 1, 13 septembre 2006

Prodimpor c/ Hays IT, arrêt n° 224

Ÿ Cass. com., 11 juillet 2006

Sté Téléfil santé c/ CDA

pourvoi n° 04-17093

www.legifrance.gouv.fr

Depuis les années 70, la jurisprudence française met à la charge du professionnel de l’informatique une obligation d’information de son client qui peut être subdivisée en trois types d’obligations : l’obligation de renseignement, l’obligation de conseil et l’obligation de mise en garde. Cette obligation d’informationest essentiellement justifiée par l’écart de compétences qui existe entre le professionnel et son client.

Incombant au professionnel, elle est très étendue et donne parfois matière à des décisions diamétralement opposées. Ainsi, dans un arrêt du 14 décembre 1995 la Cour d’appel de Rouen a considéré que le professionnel de l’informatique devait au titre de son obligation de conseil s’enquérir des besoins spécifiques de son client[4], alors que la Cour d’appel de Bordeaux a estimé dans un arrêt du 23 mai 1995 que le prestataire ne pouvait s’exonérer de sa responsabilité en arguant du fait que l’étude préalable avait été fondée sur les renseignements fournis par le client, car c’était au prestataire de procéder à une étude sérieuse des besoins du client[5].

Les années passant, l’écart de compétences entre le professionnel et le client s’est réduit dans de nombreux cas, ce qui a conduit les tribunaux à tempérer l’application de cette obligation, notamment lorsque le client ne peut être considéré comme un profane.

Pourtant, les décisions susvisées rendues respectivement par la Cour d’appel de Paris et la Cour de cassation ont appliqué, de manière très sévère, pour le professionnel le concept d’obligation de conseil.

Dans son arrêt du 11 juillet 2006, la Cour de cassation a cassé la décision de la Cour d'appel de Limoges qui, se fondant sur un rapport d’expertise, avait jugé que la société Téléfil Santé avait manqué à son obligation de coopérer en ne communiquant pas au fournisseur les informations qui lui étaient nécessaires pour exécuter ses propres obligations. La cour d’appel reprochait en outre à Téléfil Santé de ne pas avoir attiré l’attention du fournisseur sur « sa faible compétence en matière informatique et son incapacité à réaliser des opérations basiques ».

Pour la Cour de cassation, l’échec de la mise en œuvre du progiciel doit être imputé au fournisseur qui selon elle, a manqué à son obligation de conseil « envers un client dépourvu de toute compétence en la matière ». La Cour de cassation est même particulièrement sévère vis-à-vis du professionnel de l’informatique, puisqu’elle précise 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 », et ce, alors même que la non-transmission par le client des fichiers de l’ancien logiciel était à l’origine des difficultés rencontrées lors de la mise au point.

Avec la même sévérité, dans son arrêt du 13 septembre 2006, la Cour d’appel de Paris a considéré qu’un prestataire avait manqué à son obligation de conseil en laissant un projet changer de nature, sans alerter le client sur les conséquences de ce changement.

En l’espèce, la société Prodimpor a confié à un prestataire la mise en œuvre et l’adaptation aux besoins de l’entreprise d’un progiciel. Par deux avenants, les parties ont convenu d’étendre les prestations à deux autres logiciels, moyennant rémunération additionnelle et un nouveau calendrier. Un différend est né entre les parties sur un des éléments de la prestation, le prestataire considérant que cette prestation n’était pas prévue contractuellement et justifiait le paiement d’un supplément de prix et le client considérant que cette prestation était due au titre du contrat. Reprochant au prestataire de ne pas avoir respecté ses engagements, Prodimpor a mis fin au contrat la liant à son prestataire.

Le tribunal a considéré que la résiliation du contrat devait être prononcée aux torts exclusifs de Prodimpor. À l’inverse, la cour d’appel a estimé que le prestataire avait laissé la démarche se pervertir en acceptant la signature d’avenants et qu’étant un professionnel de l’informatique, cette démarche était nécessairement consciente. Selon la cour d’appel, le prestataire aurait dû alerter son client sur les risques liés à cette « dénaturation » et de ce fait, il est considéré comme étant responsable à hauteur de 50 % de la rupture des relations.

Ces décisions nous montrent d’une part que des faits identiques peuvent donner lieu à des interprétations très diverses par les juges de l’obligation de conseil, ce qui peut conduire à une certaine forme d’insécurité juridique et d’autre part que les juges ont tendance à être particulièrement sévères avec les professionnels de l’informatique.

J. MEHAUD

S. RAMBAUD

II. Obligations du client

4. Mise en place d’un ERP – Obligation de résultat du prestataire intégrateur – Immixtion du client dans le projet – Résiliation du contrat aux torts partagés

CA Paris, 28 avril 2006

SA Nouvelle Allium c/ Bull

RG n° 04/07163

L’arrêt rendu par la Cour d’appel de Paris concernant un projet d’intégration de progiciel de gestion intégrée ou ERP, dont le coût s’élevait à plus de cinq millions d’euros, vient utilement rappeler les rôles précis auxquels le client et le prestataire intégrateur sont chacun respectivement tenus en vue d’assurer la réussite de projets d’une telle envergure.

La société Nouvelle Allium a conclu avec Bull un contrat ayant pour objet l’intégration au sein du système informatique de l’un de ses entrepôts d’un progiciel de gestion intégrée conçu par la société Baan. Ce contrat précisait que Bull, en sa qualité de maître d’œuvre du projet, devait piloter ce projet et avait envers son client, maître de l’ouvrage, un devoir de conseil et de mise en garde, l’obligeant à s’assurer que les engagements de performances du progiciel seraient effectivement remplis. Le contrat précisait en outre que le prestataire intégrateur disposait des connaissances et du savoir-faire nécessaires à la mise en œuvre de solutions pouvant satisfaire les besoins de son client.

Lors du basculement vers le nouveau système, de graves dysfonctionnements ont occasionné le blocage complet du fonctionnement de l’entrepôt concerné, à la suite duquel le client a pris l’initiative de rompre unilatéralement sa relation contractuelle avec Bull et d’assigner cette dernière à titre principal, pour que soit constatée la nullité du contrat pour dol par réticence et à titre subsidiaire, pour que soit prononcée la résolution du contrat du fait des manquements graves de Bull. La société Bull a, quant à elle, assigné son client en paiement de l’ensemble des factures impayées.

S’agissant de la réticence dolosive, le client soutenait d’une part que Bull savait que l’un des modules de l’ERP ne disposait pas des fonctionnalités suffisantes pour atteindre les objectifs définis par le client, et d’autre part, que le prestataire lui avait dissimulé son inexpérience pour la mise en œuvre du progiciel.

Constatant l’absence de preuve par le client de manœuvres dolosives du prestataire intégrateur et relevant que le progiciel avait été choisi par le client, que l’expert avait établi que le progiciel aurait tout à fait pu être utilisé et que l’expérience du prestataire n’avait pas été un critère déterminant du choix du client, la Cour d’appel de Paris dans la présente espèce, a refusé de prononcer la nullité du contrat pour dol.

En outre, selon la cour d’appel, tant le prestataire que le client ont manqué à leurs obligations contractuelles et elle a donc décidé de prononcer la résiliation du contrat aux torts partagés des parties.

Pour arriver à ce résultat, elle a tout d’abord exposé un principe selon lequel, lors de l’implantation d’un système informatique supposant l’intégration d’un progiciel de gestion intégrée ou ERP, l’exécution de la prestation, en raison de la complexité technique des travaux prévus et de la nécessaire interaction entre les parties, devait s’apprécier de façon non instantanée, dès lors qu’elle mettait en jeu les rapports d’un prestataire de service informatique chargé de réaliser un logiciel spécifiquement adapté aux besoins du client.

Ainsi, selon la Cour d’appel de Paris, le maître d’œuvre est tenu à une obligation de résultat à l’égard de son client et à ce titre, a seul l’obligation de concevoir, d’adapter, de livrer et mettre en œuvre un outil informatique conforme aux besoins spécifiques de son client. Ce premier postulat est sujet à critique, dès lors que s’agissant précisément d’un progiciel de gestion intégrée, il est requis du client la plupart du temps d’adapter son organisation au fonctionnement du progiciel. Toutefois, sur ce point, la cour d’appel a précisé que Bull avait fait le choix d’implanter l’un des modules en se bornant à effectuer son paramétrage sans s’assurer qu’il correspondait aux règles de gestion interne du client, et sans concevoir, développer, ni mettre en œuvre les logiciels spécifiques nécessaires pour la gestion des stocks, et que l’intégrateur n’avait pas même averti le client de la nécessité de modifier le système de gestion des stocks avant l’implantation du module, alors qu’il en avait l’intime conviction.

Cependant, la Cour d’appel de Paris a considéré que le client avait également contribué à l’échec du projet et est venue préciser qu’il avait en l’espèce « engagé de manière aussi forte sa responsabilité » et commis une faute consistant à s’immiscer dans la mission du prestataire maître d’œuvre. En effet, selon la cour, le client a contraint le prestataire à décider prématurément de la bascule sur le nouveau système informatique, bascule qui a été à l’origine des dysfonctionnements constatés, et ce, malgré la désapprobation exprimée par le maître d’œuvre. En outre, le client a rompu de manière brutale les relations entre les parties, alors même que des réunions avaient été organisées pour remédier aux dysfonctionnements.

Le présent arrêt illustre la complexité des projets d’intégration d’ERP qui résulte en grande partie de l’imbrication importante des obligations du client et du prestataire.

Il vient en outre préciser que chaque partie doit rester à sa place et que l’obligation de collaboration du client ne doit en aucun cas se matérialiser en une immixtion intempestive de ce dernier dans le projet et en particulier dans la prise de décision, auquel cas ce dernier sera considéré comme fautif et pourra se voir imputer en tout ou partie l’échec du projet et la résiliation du contrat en découlant.

J. MEHAUD

5. Obligations du client – Allègement

CA Paris 5e ch. A, 5 juillet 2006

SAS Z International c/ Sage France, GAN Eurocourtage IARD et Telinfo

La société Z International a confié à un prestataire l’installation d’un progiciel de gestion commerciale édité par la société Sage. Elle a conclu en outre un contrat d’assistance avec la même société Sage. L’installation ayant été défectueuse, Z International a assigné le prestataire et Sage afin que soit prononcée la résolution des contrats conclus et que les défenderesses soient condamnées solidairement à lui restituer les sommes versées en application des contrats et à l’indemniser du préjudice subi.

Le Tribunal de commerce de Paris a fait droit seulement partiellement aux demandes de Z International. En effet, suivant en tous points l’expert judiciaire désigné dans cette affaire, le tribunal a retenu un partage de responsabilité à hauteur de 50 % pour le prestataire, 30 % pour Sage et 20 % pour Z International.

L’expert a en effet constaté que le prestataire avait été défaillant en ne coordonnant pas les différents intervenants, n’avait pas effectué de recette formelle des progiciels et avait laissé son client abandonner son système actuel et démarrer l’utilisation du nouveau système sans s’assurer qu’il fonctionnait correctement selon les règles de l’art. L’expert a retenu aussi des manquements imputables à l’éditeur et notamment l’existence de dysfonctionnements directement imputables au logiciel.

Mais l’expert reprochait aussi au client de ne pas avoir nommé de chef de projet pour suivre au quotidien l’installation et de ne pas avoir procédé à une réception formelle du nouveau système informatique avant de le mettre en production.

Ainsi, en suivant l’expert, le tribunal considérait que le client avait contribué à l’échec du projet en ne collaborant pas et en ne procédant pas à la recette du système, deux obligations classiquement mises à la charge du client dans un projet informatique.

À l’opposé, la cour d’appel a estimé que ces griefs ne pouvaient pas constituer des manquements imputables au client.

S’agissant de la désignation d’un chef de projet, la cour d’appel n’a pas écarté ce point en considérant qu’il ne s’agissait pas d’une obligation à la charge du client, mais a estimé qu’en l’espèce, il n’était pas établi en quoi la nomination d’un chef de projet aurait contribué à prévenir ou diminuer les dysfonctionnements constatés. Cette conclusion semble logique. Si le manquement du client n’a pas contribué à l’échec du projet, il est tout à fait normal qu’il soit écarté. Par ailleurs, la cour d’appel a considéré qu’il ne pouvait être reproché à Z International de ne pas avoir procédé à la recette du système, dès lors que la recette incombait au maître d’œuvre à savoir Telinfo. Selon la cour, la seule obligation de Z International était de donner des indications suffisantes à son maître d’œuvre pour que celui-ci puisse le conseiller et remplir ses engagements contractuels et qu’en l’espèce, il n’est pas établi que tel n’était pas le cas.

Une telle décision nous paraît critiquable dès lors qu’elle semble totalement déresponsabiliser le client. En effet, quand bien même le client confie des prestations de maîtrise d’œuvre à un prestataire, il devrait lui incomber de s’assurer que ce qui a été livré et installé est conforme à ce qu’il attend ou à tout le moins de s’assurer que le prestataire a procédé à cette vérification.

III. Limitations de responsabilité

6. Manquement à une obligation essentielle – Non-application de la clause limitative de responsabilité – confirmation de la Jurisprudence Chronopost de 1996

Cass. com., 13 février 2007

Sté Faurecia c/ Oracle, Ineum Consulting et Franfinance

pourvoi n° 05-17.407

www.legifrance.gouv.fr

Les clauses limitatives de responsabilité ont pour objet (comme leur nom le laisse à penser) de limiter conventionnellement la responsabilité contractuelle de la personne qui s’oblige. La responsabilité peut être limitée de diverses façons dont les plus classiques sont la détermination d’un plafond financier (l’éventuel montant de dommages et intérêts à verser à la victime ne pouvant excéder ce montant) et la détermination par les parties des dommages non indemnisables (à titre d’exemple, les parties conviennent que la perte de chiffre d’affaires ou la perte d’image n’est pas un préjudice indemnisable).

En droit français, il est de jurisprudence constante que les clauses limitatives de responsabilité sont valables par principe, mais doivent être écartées en cas de faute lourde ou dolosive.

Au cours des dix dernières années, la Cour de cassation a eu l’occasion à diverses reprises de se pencher sur une nouvelle exception à l’application des clauses limitatives de responsabilité : le manquement à une obligation essentielle.

Ainsi, la Cour de cassation s’est prononcée sur cette question à de nombreuses reprises à l’occasion des clauses limitatives de responsabilité figurant dans les contrats proposés par la société Chronopost.

Dans un premier arrêt de principe du 22 octobre 1996, la Chambre commerciale de la Cour de cassation a considéré que le non-respect par Chronopost de son engagement de livrer en vingt-quatre heures un pli constituait un manquement à une obligation essentielle et que la clause limitative de responsabilité devait être réputée non écrite, puisque son éventuelle application contredisait la portée de l’engagement pris[6].

La Cour de cassation a depuis suivi quelques chemins de traverses (invalidation de la clause limitative de responsabilité du contrat proposé par Chronopost conduisant à l’application de celle figurant dans le contrat-type de transport arrêté par décret, qui ne pouvait être écartée que pour faute lourde[7] ; application du seul critère de faute lourde qui ne peut résulter d’un manquement à une obligation même essentielle et notamment du seul retard de livraison[8]).

Cependant, dans un arrêt du 30 mai 2006[9], la Cour de cassation revient sur sa jurisprudence de 1996 et casse un arrêt de cour d’appel qui n’avait pas recherché si la clause limitative de responsabilité ne devait pas être réputée non écrite en raison d’un manquement à une obligation essentielle. Par ailleurs, dans un arrêt du 13 juin 2006, la Cour de cassation rappelle que la faute lourde « ne saurait résulter du seul manquement à une obligation contractuelle, fût-elle essentielle, mais doit se déduire de la gravité du comportement du débiteur »[10].

En l’état actuel de la jurisprudence, il existe donc bien deux fondements pour écarter une clause limitative de responsabilité : un manquement à une obligation essentielle ou l’existence d’une faute lourde (voire dolosive) qui ne peut être appréciée qu’en tenant compte de la gravité du comportement du débiteur.

L’arrêt rendu par la Cour de cassation le 13 février 2007 en matière informatique s’inscrit dans la droite ligne de ce dernier état de la jurisprudence Chronopost.

Les faits de l’espèce se prêtaient particulièrement à une telle application.

En 1999, la société Faurecia a décidé de refondre son système d’informations. Aidée d’un prestataire de services, elle a porté son choix sur la version 12 d’un progiciel, version non encore disponible à la date de signature des contrats. Pour ce projet, Faurecia a conclu avec l’éditeur de progiciel un contrat de licence au titre duquel elle se portait acquéreur des licences nécessaires pour le projet dans sa totalité (sites pilotes et déploiement), un contrat de maintenance et un contrat de formation. En outre, elle a conclu un contrat de mise en œuvre du progiciel avec l’éditeur et le prestataire de services (société qui l’avait par ailleurs conseillé dans son choix). Les sites ibériques de Faurecia ne passant pas l’an 2000, et la version 12 du progiciel n’étant pas disponible, les parties ont décidé de mettre en œuvre sur ces sites une solution provisoire.

La mise en œuvre de la solution provisoire a rencontré des difficultés, et la version 12 du progiciel n’a pas été livrée. Faurecia a donc cessé de régler les redevances de licence. Ayant été assignée en paiement de cette redevance par Franfinance, société à laquelle l’éditeur avait cédé sa créance, Faurecia a appelé en garantie ses cocontractants, à savoir l’éditeur du logiciel et le prestataire de services, en demandant la nullité pour dol des contrats à titre principal, et leurrésolution pour inexécution à titre subsidiaire.

La cour d’appel a prononcé, dans son arrêt du 31 mars 2005, la résolution partielle du contrat de licence et la résiliation des autres contrats, en considérant principalement que l’éditeur n’avait pas livré la version 12 du progiciel, alors qu’il s’y était engagé. Toutefois, dans le même temps, elle a limité l’indemnisation à laquelle pouvait prétendre Faurecia, en appliquant la clause limitative de responsabilité figurant dans le contrat de licence.

La cour d’appel a reproché en effet à Faurecia de ne pas caractériser la faute lourde de l’éditeur « qui permettrait d’écarter la clause limitative de responsabilité, se contentant d’évoquer des manquements à des obligations essentielles, sans caractériser ce que seraient les premiers et les secondes », précisant même que la non-livraison de la version 12 du progiciel ne pouvait à elle seule constituer un manquement à une obligation essentielle.

La cour d’appel semble hésiter sur le point de savoir si un manquement à une obligation essentielle peut être un fondement pour écarter une clause limitative de responsabilité. On peut comprendre cette hésitation, dans la mesure où cet arrêt a été rendu à une époque où la jurisprudence de la Cour de cassation sur ce point était fluctuante. Cependant, ce qui est moins compréhensible est le fait de considérer que la non-livraison de l’objet même du contrat, tel que retenu par la cour d’appel, ne constitue pas de fait un manquement à une obligation essentielle, sans plus d’explication.

C’est dans ce contexte que la Cour de cassation, après avoir rappelé qu’en application de l’article 1131 du Code civil un manquement à une obligation essentielle fait échec à l’application d’une clause limitative de responsabilité, a cassé partiellement l’arrêt de la cour d’appel. En effet, selon la Cour de cassation, après avoir constaté que l’éditeur s’était engagé à livrer la version 12 du progiciel, objectif final des contrats conclus, et qu’il n’avait pas exécuté cette obligation, sans pouvoir invoquer un cas de force majeure, la cour d’appel était contrainte de considérer qu’il s’agissait d’un manquement à une obligation essentielle et d’écarter la clause limitative de responsabilité.

Selon la Cour de cassation, les constats faits par la Cour d’appel ne pouvaient conduire à une autre décision.

En tout état de cause, le maintien du manquement à une obligation essentielle comme fondement pour écarter les clauses limitatives de responsabilité est une bonne nouvelle pour tous ceux qui désirent écarter de telles clauses. En effet, et tout particuliérement, en matière informatique où les obligations des parties sont souvent fortement imbriquées et relativement complexes, il peut être difficile d’établir que le prestataire a eu « un comportement d’une extrême gravité confinant au dol et dénotant l’inaptitude du prestataire à l’accomplissement de ses obligations »[11]. À l’inverse, il semble de prime abord plus facile d’établir que l’obligation non exécutée ou mal exécutée par le prestataire était une obligation essentielle pour les parties. Ainsi, à titre d’exemple, la Cour de cassation avait déjà écarté une clause limitative de responsabilité dans un contrat de maintenance informatique pour un manquement à une obligation essentielle (en l’espèce, le non-respect de l’engagement d’intervenir en « 48 heures chrono »)[12]. Cette jurisprudence redonne tout leur intérêt aux clauses qui précisent dans les contrats quelles sont les obligations essentielles des parties.

S. RAMBAUD

7. Résolution du contrat – Remise en état des parties et non application de la clause limitative de responsabilité

CA Colmar 1re ch. civ. B., 13 avril 2006

GMBH Industrial Application Software c/ Escarmor

RG n° 1 B 04/12131

La résolution telle que prévue par les articles 1183 et 1184 du Code civil emporte anéantissement rétroactif du contrat, dans l’hypothèse où une des parties n’exécute pas ses obligations.

Au-delà de la remise en état des parties à la date de signature du contrat (restitutions réciproques lorsqu’elle est possible, […]), l’anéantissement rétroactif signifie-t-il que les clauses convenues entre les parties sont sensées elles aussi ne jamais avoir existé ?

À cet égard, la jurisprudence semble avoir distingué plusieurs types de clauses : les clauses qui visent à régir la fin du contrat et/ou les conséquences de son inexécution, les clauses qui conservent leur utilité malgré la résolution (telles que la clause compromissoire ou la clause attributive de juridiction) et les autres clauses. Seuls les deux premiers types de clauses survivraient à la résolution du contrat.

Ainsi, dans plusieurs arrêts dont un arrêt du 15 février 2005[13] la Cour de cassation a considéré qu’une clause pénale pour inexécution a vocation à être appliquée, en dépit de la résolution du contrat.

À l’inverse, une clause pénale qui aurait pour vocation de sanctionner les conséquences d’un retard dans l’exécution d’une obligation devrait être privée d’effet du fait de la résolution[14].

Sur cette même question, la Cour d’appel de Colmar semble considérer qu’une clause limitative de responsabilité doit être écartée en cas de résolution du contrat.

Dans cette affaire, la cour d’appel a estimé qu’un éditeur de logiciels, qui avait livré son logiciel en retard et avec de graves dysfonctionnements, avait accumulé des fautes particulièrement graves qui rendaient sa prestation et sa livraison totalement impropres à leur usage.

De ce fait, la cour d’appel a prononcé, à la demande du client, la résolution du contrat aux torts exclusifs de l’éditeur.

Très classiquement, ce dernier a tenté de se retrancher derrière la clause limitative de responsabilité contractuelle afin de limiter les conséquences de sa responsabilité.

La cour d’appel a écarté cette clause en se fondant uniquement sur la résolution du contrat, sans expliquer plus longuement les raisons de cette non-application.

Cette décision est conforme à un certain courant de jurisprudence illustré notamment par un arrêt de la Cour d’appel de Paris du 22 février 2002[15].

Ce courant de jurisprudence nous semble particulièrement critiquable.

En effet, la clause limitative de responsabilité a bien vocation à gérer les conséquences de l’inexécution du contrat par une des parties. Cette clause devrait donc être appliquée même si la conséquence de l’inexécution du contrat est la résolution. À défaut, cela conduirait à ne tenir aucuncompte de l’intention des parties qui ont précisément souhaité encadrer les conséquences de l’inexécution du contrat.

On peut comprendre que la cour d’appel ait souhaité que l’éditeur qui avait gravement manqué à ses obligations ne puisse limiter sa responsabilité. Toutefois, il existait d’autres moyens à la disposition de la cour pour atteindre cet objectif et notamment l’existence d’une faute lourde ou le manquement à une obligation essentielle.

S. RAMBAUD






[1]T. com. Créteil, 16 juin 1998 : Expertises 1998, p. 316.



[2]T. com. Flers, 22 oct. 1999 : RJDA 2000, n° 148, 1re espèce.



[3]Cass. com., 14 avr. 1992, pourvoi n° 90-13999 : < www.legifrance.gouv.fr >.



[4]CA Rouen, 14 déc. 1995, CPE c/ ENSI : Juris-Data n° 049588.



[5]CA Bordeaux, 23 mai 1995, Richard c/ Salies : Juris-Data n° 044075.



[6]Cass. com., 22 oct. 1996 : Bull. civ., IV, n° 261.



[7] Cass. com., 9 juill. 2002 : Bull. civ., IV, n° 121.



[8]Cass. ch. mixte, 22 avr. 2005, 2 arrêts : Bull. 2005, mixt. n° 3, p. 9 ; Cass. com., 21 févr. 2006 : D. 2006, p. 717.

[9]Cass. com., 30 mai 2006 : Bull. 2006, IV, n° 132 ; D. 2006, p. 1559.



[10]Cass. com., 13 juin 2006 : Bull. 2006, IV, n° 143.



[11]Par exemple, Cass. com., 26 févr. 1985, Soditrans c/ Gan : RTC civ. 1986, p. 773.



[12]Cass. com., 17 juill. 2001, Securinfor, pourvoi n 98-15678 : < www.legifrance.gouv.fr >.



[13]Cass. 3e civ., 15 févr. 2005, pourvoi n° 04-11223 : < www.legifrance.gouv.fr >.



[14]Cass. req., 8 juill. 1873 : DP 1874, 1, p. 56.



[15]CA Paris 25e ch. A., 22 févr. 2002, arrêt n° 103, ICL c/ Levallois Distribution et Clichy Distribution.