De la nature de l’engagement du prestataire informatique

Publié le 19/03/2018 - CIO Online - E. Papin

Pour lire l’article d’Etienne Papin dans son contexte original pour CIO Online.

Les contrats informatiques sont-ils eux aussi bogués ? Etienne Papin démontre ici qu’il n’y a pas d’exception informatique. Tant pis pour les fournisseurs qui tentent un renversement de la charge de la preuve pour échapper à leur responsabilité.

La mise en œuvre d’un nouveau système applicatif est un investissement important pour les entreprises. Même si les solutions « Saas » ou « Cloud » ont pu faire baisser certains postes de coûts, il reste vrai, aujourd’hui comme hier, que les projets d’intégration de solutions progicielles (ERP, SRIH, CRM, etc.) sont des budgets toujours conséquents pour les entreprises, justifiant une sélection méthodique des prestataires susceptibles de les mener à bien.

Au regard de ces investissements, il n’est guère surprenant que le client entretienne l’espoir qu’il disposera au terme d’un projet d’une solution répondant à ses besoins et ce dans un délai raisonnable et pour un coût conforme à ses prévisions initiales. Las. Les promesses d’avant-vente, et même les engagements contractualisés, ne sont pas toujours au rendez-vous du projet.

Paradoxalement, lorsque les projets dérapent, le client peut apparaître comme étant dans la position de toujours devoir démontrer qu’il n’est pas fautif alors même que celui-ci n’a pas manqué à son obligation principale au titre du contrat : s’acquitter des échéances de facturation. Mauvaise expression des besoins, évolution des besoins en cours de projet, mauvaise appréciation des gaps fonctionnels entre le progiciel et les besoins, retard dans la validation de livrables, etc. les circonstances imputables au client qui peuvent expliquer l’échec du projet sont mutatis mutandis toujours les mêmes et bien souvent invoquées par les prestataires en réaction aux reproches qui leur sont adressés.

Le propos de cet article n’est pas de nier que ces situations existent. Il s’agit de s’interroger sur le renversement de la charge de la preuve que l’automaticité de ces moyens de défense opère et, plus généralement, sur la nature de l’engagement du prestataire informatique vis-à-vis de celui qui le paye.

Les projets informatiques sont-ils allergiques à l’obligation de résultat ?

Rappelons l’intérêt « théorique » de la distinction. Le prestataire engagé sur la base d’une obligation de moyen n’est pas débiteur d’une obligation « minorée » par rapport à celui qui s’est engagé sur un « résultat ». La prestation devant être délivrée sera la même et le niveau de qualité attendu également : soit il s’agit du niveau spécifié explicitement au contrat, soit, en l’absence de précisions contractuelles, il s’agira de la qualité que l’on est en droit d’attendre d’un professionnel raisonnablement compétent et diligent.

La différence entre obligation de moyens et obligation de résultat tient uniquement au régime de la preuve du manquement allégué contre le prestataire. Dans le cadre d’une obligation de moyens, il appartiendra au client de prouver le manquement, alors que dans le cadre d’une obligation de résultat, il s’agira pour le prestataire de prouver son absence de faute et, corrélativement, celle du client dans l’échec du projet.

Voici pour la théorie. Car s’opère souvent en pratique un renversement de la charge de la preuve lorsqu’il suffit d’alléguer à l’encontre du client les manquements « classiques » que nous avons énumérés plus haut. Défense d’autant plus efficace que la jurisprudence fait preuve d’une certaine bienveillance pour les fournisseurs informatiques. En 2018 comme en 1978, les juges considèrent toujours que les projets informatiques sont de la « technologie de pointe » dans lesquels l’échec n’est pas un cas de figure anormal.

Les motivations de cet arrêt de la cour d’appel de Lyon du 23 novembre 2006 peuvent être prises comme un exemple topique de l’approche que retiennent naturellement les juges dans les litiges informatiques : « En l’absence de clause spécifique ou de circonstances particulières, le client du fournisseur informatique n’est créancier que d’une obligation de moyens et doit en conséquence, s’il estime que ses demandes n’ont pas été satisfaites, démontrer que le fournisseur de logiciels, de matériel et de prestations de maintenance et de formation, en l’occurrence, n’a pas mis en œuvre la diligence souhaitable, au sens de l’article 1134 du Code Civil, pour répondre aux besoins et aux objectifs définis ».

Encore devant la cour d’appel de Lyon, dans un arrêt du 21 décembre 2006, s’agissant de l’obligation de fourniture d’un logiciel spécifique : « cette obligation n’est pas une obligation de résultat en raison de la marge d’aléa tenant au rôle du client dans sa participation au projet susceptible d’affecter l’adéquation de la solution proposée aux besoins ».

Plus récemment, la cour d’appel de Paris (13 mars 2017) considère : « L’obligation de l’intégrateur ne peut pas être une obligation de résultat dès lors que l’installation du système informatique nécessite dans sa mise en œuvre, une collaboration et une implication des équipes du client dans la transmission des données nécessaire au paramétrage et dans la validation de chaque étape, susceptibles d’affecter l’adéquation de la solution proposée aux besoins du client. L’intégrateur de solution informatique n’est tenu qu’à une obligation de moyen dans l’exécution de ses prestations et non à une obligation de délivrance ». A croire qu’en 40 ans la méthodologie de gestion de projet n’a pas évolué.

Une précaution indispensable mais pas suffisante

Pour combattre le caractère « naturellement » de moyen de l’obligation de délivrance du prestataire informatique, il est nécessaire pour le client de disposer d’un contrat particulièrement clair sur le niveau d’engagement du prestataire.

Les juges restent sensibles à l’expression « clé en main » que l’on rencontre parfois dans les contrats portant sur la mise en place d’une solution informatique. Ainsi, la Cour de cassation, dans un arrêt du 17 mai 2017, casse la décision d’une cour d’appel qui avait refusé de donner plein effet à cette stipulation : « ayant constaté que le contrat portait sur la création d’un site « clés en main », de sorte que l’obligation souscrite par [le prestataire] devait s’analyser en une obligation de résultat, la cour d’appel a violé le texte susvisé ».

Dans la désormais séquence judiciaire MAIF/IBM, qui s’est terminée par la décision de la Cour d’appel de Bordeaux du 29 janvier 2015 statuant sur renvoi après cassation, les juges constateront que « société IBM s’est engagée par contrat […] à fournir des prestations clairement définies dans des délais et moyennant une rémunération déterminés, au terme d’engagements qui, de l’accord des parties, constituaient une obligation de résultat à la charge de l’opérateur, le résultat promis n’a pas été atteint par la faute présumée d’IBM qui ne peut s’en exonérer que par la preuve de la cause étrangère qu’elle ne fait pas ».

Force doit être donnée aux stipulations claires d’un contrat, mais il a fallu presque 10 ans de procédure pour trancher un litige sur la base d’une considération aussi élémentaire de droit des obligations.

Autres publications