Les projets informatiques : apprendra-t-on quelque chose d’un abondant contentieux ?

Publié le 16/12/2019 - CIO Online - E. Papin

Pour lire l’article d’Etienne Papin, Avocat Associé, du 16 décembre 2019 pour CIO Online.

 

Les projets informatiques sont toujours le théâtre d’un contentieux nourri, les tribunaux rendent à rythme toujours soutenu des décisions opposant clients insatisfaits et prestataires impayés. Ce qui frappe, ce n’est pas la nouveauté de ce contentieux, c’est au contraire son étonnante constance : les décennies passent et rien ne change ; comme si clients et prestataires n’apprenaient jamais de leurs échecs.

Il ne fait pas de doute que les projets informatiques peuvent être complexes, mais ce n’est pas cette complexité qui explique à elle seule les litiges qui naissent d’un projet informatique qui dérive.

En réalité, les contentieux informatiques se nourrissent toujours aux deux mêmes sources : mauvaise formalisation du cadre juridique de la relation et mauvaise gestion de projet. Ce que la jurisprudence résume imparfaitement à une dialectique finalement peu pertinente entre obligation de conseil du prestataire et obligation de collaboration du client. Les décisions qui reprochent le manquement de l’un et de l’autre – voire des deux en même temps – à ces obligations sont légions. Ne nous en cachons pas : il existe en la matière une grande casuistique et l’approche des juges pour des faits identiques peut considérablement varier d’un tribunal de commerce à l’autre.

Pour réduire cet aléa judiciaire, l’étude de la jurisprudence sur les dernières années nous permet d’illustrer ce qu’il est préférable de faire en matière de projet informatique.

La mauvaise formalisation du cadre juridique de la relation

Un projet informatique c’est une règle du jeu : qu’est-ce qu’attend le client, qu’est-ce que le prestataire propose de réaliser ? Le travail de formalisation de cette règle du jeu, quel qu’en soit le support, est essentiel. Ce peut-être dans un contrat, un cahier des charges, une proposition commerciale, un RFP, etc. mais ce doit être quelque part, et ce doit être clairement rédigé. A cet égard, il faut se méfier des outils bureautiques et des e-mails. Il est aujourd’hui tellement simple de produire de l’écrit que souvent l’information essentielle peut être noyée dans l’information inutile, contredite voire tout simplement omise.

Ainsi, la Cour d’appel de Dijon a été saisie de l’échec d’un projet d’automatisation d’un entrepôt et du progiciel associé (Warehouse Management System). On s’en doute, dans ce type de projet, l’amélioration de la productivité escomptée en raison de l’automatisation est le critère clé de succès pour le client. Or, dans son arrêt du 4 décembre 2018, la Cour d’appel est bien forcée de constater : « qu’aucun élément du contrat de fourniture […] ne vise des objectifs quantitatifs ou qualitatifs ; qu’aucun objectif chiffré […] n’a été spécifié dans le contrat initial ni même, d’ailleurs, dans la documentation précontractuelle, les termes employés concernant la productivité mais également la flexibilité et la qualité, étant utilisés de manière vague et générale ; qu’il n’est défini aucune valeur de référence de la productivité avant la mécanisation ou lors de la conclusion du contrat, ni aucune définition de la productivité à améliorer ». Aussi, la Cour d’appel décide que la productivité, prétendument centrale dans le projet, n’a pas fait l’objet d’un critère contractuel susceptible de fonder une non-conformité.

Valoriser les performances attendues du système est un élément indispensable pour le client, tout autant que ses attentes fonctionnelles ou techniques. Mais le client n’est pas seul à devoir formaliser les choses. Le prestataire doit s’y astreindre également : avant et pendant le projet.

Avant le projet. La Cour d’appel de Paris, dans une décision du 17 novembre 2017, reproche au prestataire d’avoir failli à son devoir de conseil et d’information en n’alertant pas son cocontractant sur les spécificités du produit notamment ses limites et la complexité des développements spécifiques à réaliser pour l’intégrer. La décision est d’autant plus remarquable que, en l’espèce, le client avait également une activité dans le domaine informatique. Le prestataire n’est donc jamais trop avisé de formaliser clairement ses mises en garde.

Pendant le projet. Retournons dans le domaine de la logistique avec l’échec d’une bascule sur un progiciel de gestion des stocks et des commandes. Alors que la Cour d’appel reconnait que « les hésitations » et « le retard apporté à l’installation » des équipements par le client « intervenue quelques jours avant le transfert vers le nouveau logiciel », ont rendu impossible les tests de démarrage, il reste reproché au prestataire par la Cour de cassation, de ne pas avoir mis en garde le client « sur la nécessité d’effectuer des tests de démarrage ». Dans sa décision du 10 juillet 2019, elle casse l’arrêt d’appel qui avait opté pour un partage de responsabilité entre prestataire et client suite à l’échec de la bascule sur le nouveau système. La Cour de cassation considère qu’à partir du moment où la Cour d’appel constate le manquement du prestataire à son obligation de conseil, précisément sur les tests devant être menés avant la bascule, elle ne peut prononcer un partage de responsabilité entre le prestataire et son client. Il n’est donc pas d’exécution conforme de l’obligation de conseil sans formalisation claire de celle-ci. L’affaire est renvoyée devant la Cour de Paris.

Une irremplaçable gestion de projet

On serait tenté d’affirmer que la gestion de projet incombe aux deux parties.

De son côté, le client ne peut se contenter de constater la dérive calendaire et/ou budgétaire du projet sans tirer les conséquences juridiques de ce constat : soit un arrêt du projet soit une reconfiguration de celui-ci avec les modifications contractuelles qui s’imposent.

Il est illusoire de penser qu’en laissant un projet s’écarter de son plan initial pendant des mois voire des années, le client pourra ensuite exiger de son prestataire un retour à l’épure contractuelle initiale, alors même que le client peut souvent être lui-même à l’origine de cette dérive. Ainsi, dans cet arrêt de la cour d’appel d’Aix-en-Provence du 2 mars 2017, la cour refuse d’engager la responsabilité du prestataire alors que le client a sollicité « de manière incessante des évolutions et des modifications ». Le contrat ne lie le prestataire en termes de délivrance conforme, de prix et de délai de réalisation qu’autant que le client mette le prestataire en mesure de réaliser le projet.

Cela pourrait aller sans le dire, mais cela va certainement mieux en l’écrivant. Le prestataire doit acter par écrit de ses interventions dans le pilotage du projet. Ainsi, dans son arrêt du 6 avril 2018, la cour d’appel de Paris refuse d’exonérer le prestataire de sa responsabilité alors que celui-ci soutenait que les demandes de prestations, hors du cadre contractuel, étaient à l’origine du retard allégué. La cour reproche au prestataire de ne pas avoir proposé d’avenant ou de devis complémentaires à ce titre, ce qui laissait donc supposer que le retard n’était donc pas lié aux demandes hors périmètre du client.

Le pilotage du projet ne saurait donc être tacite, implicite, voire basé sur la simple « bonne foi » des parties. Bien au contraire ! Il nécessite, de part et d’autre, des ajustements constants ou des rappels, au cadre contractuel initial. Éviter ou gagner les procès se joue pendant le projet !

Autres publications