Bienvenue sur la Grande Bibliothèque du Droit ! Ceci est une bibliothèque contributive. Vous pouvez nous proposer des articles.

Les lecteurs et contributeurs ne doivent pas oublier de consulter les Avertissements juridiques.

Welcome to the Grand Law Library ! This is a participatory e-library. You can send us your publications

Maxresdefault.jpg

Progiciel de gestion intégré : indemnisation des préjudices du client en cas d'échec du projet (fr)

Version imprimable
Un article de la Grande Bibliothèque du Droit, le droit partagé.
Aller à : navigation, Rechercher
France > Droit privé > Droit de l'informatique
Fr flag.png

Auteur : Cabinet Staub & Associés
Avocats au barreau de Paris
Publié le 04/01/2012 sur Immateria, le blog du Cabinet Staub & Associés


Les nécessités techniques et organisationnelles d’une entreprise la poussent à recourir, le plus souvent, à des progiciels de gestion intégrée qui s’appliquent à un grand nombre de processus internes. Ainsi les « progiciels de gestion intégrée » « PGI » ou « ERP » (« Entreprise Resource Planning ») sont aujourd’hui indispensables à la gestion des flux d’une entreprise. Mais quid lorsque le projet dérape ? Quel est réellement le coût de l'échec d'un projet informatique pour une entreprise ?

De nombreuses études professionnelles indiquent que les projets d’implémentation d’ERP rencontrent souvent des difficultés. En moyenne selon les études (ex : "The Chaos Report", Standish Group, juin 2009), de 20 à 30% des projets ERP sont des échecs plus ou moins complets, et plus de 50% sont achevés dans la douleur, avec retard ou moyennant un surcoût significatif. Les causes en sont notamment une mauvaise analyse d’adéquation du produit aux besoins, des difficultés à développer ou intégrer dans les faits le progiciel commandé, ou encore une dérive calendaire ou financière. Les entreprises doivent donc se consacrer avec une grande rigueur à la gestion de projet, et planifier en détail les conséquences de son succès… comme de son échec.


1. Complexité des projets informatiques ERP

Un ERP est communément défini comme un progiciel gérant tout ou partie des processus opérationnels de l’entreprise, en intégrant l'ensemble de ses fonctions vitales, telles que la gestion des ressources humaines, la gestion comptable, la gestion financière, les processus de vente et de distribution, l'approvisionnement en produits, le suivi des fournisseurs, la maintenance des équipements, le commerce électronique, la facturation, la gestion des bases clients, l’administration des campagnes marketing, etc.

De ce fait, un ERP constitue le centre névralgique de la gestion informatique des activités de l’entreprise, par secteur (gestion de production, gestion de la logistique, module financier) ou dans son ensemble (gestion commerciale intégrée).

Quelle que soit la taille de l’entreprise, les ERP utilisés ont une importance stratégique, et conditionnent les aspects commerciaux, financiers, logistiques et humains de son activité. Un ERP a un impact sur un grand nombre d’équipes et de services, qui sont amenées à l’utiliser chacun pour leurs besoins spécifiques.

En outre, les projets commerciaux de l’entreprise sont le plus souvent conditionnés par les fonctionnalités et les performances de son système informatique, lui-même tributaire de l’efficacité des ERP qui y sont implantés. Un projet d’implémentation d’ERP au sein d’une entreprise, qu’il s’agisse de son équipement initial ou de sa modernisation, constitue donc un projet hautement stratégique, en ce qu’il influe sur tous les autres. Il n’est pas excessif à ce titre de parler « d’entreprise assistée par ordinateur ».

L’entreprise doit définir ses besoins et contraintes avec soin, afin de choisir l’ERP qui convient le mieux à ses spécificités. De même, l’entreprise doit également sélectionner l’intégrateur avec soin, car de l’efficacité de ses prestations dépend le succès du projet. A ce titre, il est traditionnellement admis qu’un ERP, en tant que logiciel, doit être choisi par le client auquel il incombe de vérifier l’adéquation du produit à ses besoins.

Dans les faits cependant, le choix d’un ERP implique une véritable étude d’adéquation, afin d’identifier les écarts inévitables entre les fonctionnalités standard du progiciel et les besoins de l’entreprise. Cette détermination des écarts permet de jauger l’importance de la nécessaire phase de « personnalisation » (paramétrages, interfaçages ou développements spécifiques complémentaires).

Ainsi, le projet d’intégration d’un ERP ne doit pas être conçu comme un projet comme un autre. Ses impacts doivent être mesurés et quantifiés, et doivent être portés à la connaissance du prestataire retenu. Beaucoup d’entreprises passent d’ailleurs des appels d’offres qui exposent leurs besoins, afin de bénéficier d’un éventail d’offres parmi lesquelles elles choisissent l’offre technique et financière qui lui convient le mieux.

Le client peut donc exiger du prestataire intégrateur, non seulement son conseil et son expertise, mais également une prestation préalable d’analyse fine des besoins et d’identification des écarts, afin de planifier la charge réelle de travail.

Le client doit également exiger du prestataire une analyse des changements à opérer au sein de l’entreprise, afin de mesurer le temps que les équipes du client vont consacrer au projet. La « conduite du changement » ne se résume pas à quelques sessions de formation des personnels, mais implique souvent d’analyser leurs pratiques, de les rationaliser, et de les faire évoluer afin d’assurer leur aptitude à appréhender le nouveau système, dès sa mise en production.

Le prestataire a tout intérêt à rappeler au client que cette conduite du changement est nécessaire, d’autant qu’elle est en dehors de sa sphère d’intervention. Plus d’un projet échoue parce que le client n’a pas su sensibiliser ses propres équipes au nouveau progiciel, ou qu’il s’est crispé sur ses anciennes habitudes et n’a pas appréhendé la nouveauté fonctionnelle.

On mesure l’ampleur de l’impact du projet sur l’organisation et la production de l’entreprise.

Le projet ERP doit dès lors être encadré par un contrat en adéquation avec les attentes du client, qui doit identifier avec soin le périmètre précis des interventions du prestataire et envisager leur dimension juridique : force obligatoire de l’expression initiale des besoins, modalités de fourniture des matériels et des logiciels, déroulement des phases de spécification, d’intégration et de déploiement, obligation de résultat, respect des délais et application des pénalités, maîtrise d’œuvre et méthodologie de travail, matrice de répartition des tâches, calendrier, phases et lots du projet, description des procédures de recette des livrables, modalités de collaboration du client, garanties de qualité et niveaux de service… et enfin, la responsabilité du prestataire en cas d’échec du projet.

L’échec d’un projet revient souvent, en dernière analyse, à l’absence de délivrance conforme du système attendu. Que l’échec soit dû à un dépassement des délais, à l’incapacité du prestataire à fournir les fonctionnalités convenues, à l’absence des performances souhaitées, à une dérive des coûts ou encore à un défaut de pilotage des prestations, le client constate en dernier ressort qu’il ne dispose pas de l’ERP commandé.

Il arrive aussi que le client ne mène pas suffisamment la conduite du changement, ou modifie unilatéralement le périmètre de ses besoins, ou encore manque à son obligation de collaboration en ne validant pas les spécifications ou en n’accomplissant pas les tâches lui incombant. Il serait faux de croire qu’un projet informatique échoue toujours à cause du prestataire en charge de le mener : bien souvent, le client n’a pas su se mettre en ordre de bataille.

Toutefois, si l’on se place du côté du client utilisateur, la jurisprudence accueille traditionnellement l’échec en constatant ou en prononçant la résolution du contrat d’intégration, faute pour l’intégrateur de mettre le client à même de se servir du progiciel[1], de livrer un progiciel conforme aux spécifications convenues[2], ou encore de respecter les délais de livraison convenus[3]. La Cour de cassation a également précisé qu’en matière de fourniture de solutions informatiques, « 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 »[4].

Deux questions se posent alors : quelle est la responsabilité du prestataire dans cet échec, et quel est le préjudice subi par le client susceptible d’être indemnisé ?

La première question fait l’objet de débats judiciaires et techniques parfois complexes : insuffisance dans l’expression initiale des besoins, défaut d’analyse préalable, indigence des spécifications, anomalies récurrentes, régressions des performances… peuvent être imputables au prestataire ou au client, selon la répartition des diligences prévue au contrat.

Dans ce contexte, le prestataire fustige souvent le défaut de collaboration du client, qui tarde à transmettre les informations ou éléments nécessaires au déroulement de l’intégration, ou encore à valider les livrables, par exemple. Il est donc dans l’intérêt des deux parties d’établir, dès le stade du contrat, la matrice de répartition des responsabilités évoquées plus haut, afin de clairement identifier les diligences qui leur incombent ainsi que le rythme auquel chacun doit les effectuer.

La seconde question, objet de la présente étude, implique quant à elle de mesurer quel sont les dommages réellement subis par le client.

2. La composition du préjudice du client et son appréciation par le juge

Le Code civil dispose, à son article 1149, que « les dommages et intérêts dus au créancier sont, en général, de la perte qu’il a faite et du gain dont il a été privé ».

Le principe est immédiatement tempéré par l’article 1150, qui dispose que « le débiteur n’est tenu que des dommages et intérêts qui ont été prévus ou qu’on a pu prévoir lors du contrat, lorsque ce n’est point par son dol que l’obligation n’est point exécutée ». Enfin, l’article 1151 précise que même en cas de faute dolosive, « les dommages et intérêts ne doivent comprendre à l’égard de la perte éprouvée par le créancier et du gain dont il a été privé, que ce qui est une suite immédiate et directe de l’inexécution de la convention ».

La jurisprudence ajoute « qu’une fois le dommage déterminé dans sa nature et son étendue, il importe uniquement d’assurer à la victime une indemnisation intégrale par le versement de l’équivalent monétaire dudit dommage au jour de sa réparation » (Cass. Com. 16 février 1954).

2.1 L’élémentaire distinction entre créances de restitution et d’indemnisation

Le préjudice se réduit très rarement à la simple privation de la prestation attendue. En matière de progiciel, il est nécessairement bien plus vaste, et comprend toute perte subie et tout gain manqué, directement liés à cette privation. Les pertes subies sont des dépenses que le client n’aurait jamais engagées s’il n’avait pensé en retirer un bénéfice supérieur, un gain espéré. L’article 1149 du Code rappelle cette évidence.

La doctrine abonde en ce sens lorsqu’elle estime, comme Monsieur le Professeur P. Stoffel-Munck, que « Le temps c'est évidemment de l'argent. Il en va a fortiori ainsi quand le temps perdu a un coût aisément évaluable en heures de travail payées à accomplir des tâches qui n'avaient pas lieu d'être. C'est exactement ce dont rend compte la Cour de Paris quand elle admet comme préjudice les « pertes de temps et déperditions d'énergie qui [...] ont distrait [les salariés] des tâches auxquelles ils se seraient autrement consacrés ». (…) L’objet de l’informatique est notamment, sinon essentiellement, de faire gagner du temps. Il est normal de s’en souvenir quand, par la faute du fournisseur, elle nous en a bien plutôt fait perdre »[5].

À l’évidence, le remboursement des factures payées par le client, ainsi que l’émission d’éventuels avoirs en compensation des factures émises, mais refusées par le client, ne correspondent qu’aux restitutions qui accompagnent toute résolution contractuelle. Le progiciel n’ayant pas été livré ni mis en production, il est normal que sa contrepartie contractuelle, le paiement du prix, soit également remis en cause. Il s’agit de la conséquence ultime de l’exception d’inexécution, car la cause du paiement disparaît définitivement.

Le remboursement des factures acquittées ne peut donc jamais s’analyser en indemnisation du préjudice. Le premier correspond à la créance de restitution du prix, issue de la résolution. La seconde correspond à la compensation des préjudices subis par le client. Les deux créances ont la même origine, à savoir l’échec du projet pour faute du prestataire, mais sont de nature et d’objet différents.

Dans un arrêt du 7 octobre 2008, la Cour de cassation a d’ailleurs rappelé cette distinction essentielle entre la restitution et l’indemnisation, en traitant d’une part de la question des restitutions croisées consécutives à la résolution du contrat de fourniture d’un système informatique, et d’autre part la question de l’indemnisation des préjudices subis par le client[6].

2.2 La variété des postes de préjudices

Chaque projet ERP est unique, car il correspond toujours à une entreprise particulière, avec son organisation, ses méthodes, ses ressources, ses besoins, ses contraintes. La gamme des préjudices éventuellement occasionnés par un échec du projet informatique est donc très variée. À titre d’exemple, l’arrêt de la Cour d'appel de Paris du 19 janvier 2011[7]) illustre cette variété des postes de préjudice en cas d’échec d’un projet ERP.

Néanmoins, il est possible de classifier les catégories de préjudices envisageables, entre coût humain, coût matériel (et logiciel), conséquences sur la production, et gain de productivité manqué. Il faut ainsi pouvoir identifier toute dépense, tout investissement qui est directement lié au projet informatique, et qui est exposé en pure perte si le projet informatique n’aboutit pas.

À titre d’exemple, on doit considérer que le temps consacré par les équipes du client (sa DSI mais également ses différents métiers dès lors qu’ils doivent exprimer leurs besoins) à la constitution du cahier des charges, est directement lié au projet informatique, puisqu’il en concrétise la conception initiale. Si l’entreprise ne met jamais le progiciel en œuvre, le temps passé à rédiger le cahier des charges est perdu. À l’évidence, il en va de même du temps consacré par les préposés de l’entreprise à analyser l’offre du prestataire, à la négocier ou à demander des éclaircissements.

Une fois les prestations engagées, et comme rappelé plus haut, le client doit dédier des équipes à l’exécution de sonobligation de collaboration, en répondant aux questions complémentaires du prestataire, en participant aux ateliers de spécifications, bref en accompagnant le prestataire dans sa phase d’analyse des pratiques de l’entreprise. Là encore, le temps consacré par les équipes à ces diligences n’est pas consacré à autre chose.

Tout manquement à cette obligation de collaboration peut avoir un impact très fort sur le déroulement du projet, et donc son succès. Le prestataire soulignera le défaut de collaboration du client, pour expliquer que ce manque de coopération est l'origine véritable de l'échec du projet : comment le prestataire pouvait-il assurer le succès d'un projet si le client n'exprime pas correctement ses besoins, ne valide pas les spécifications ou les livrables en temps et heures, ou ne participe pas aux tâches qui lui sont dévolues dans le contrat ?

Pour en revenir aux préjudices du client, l’achat de matériels ou de logiciels (non compris dans le périmètre d’des fournitures du prestataire) constitue bien entendu une autre catégorie de dépenses intrinsèquement liée au projet, et ce d’autant plus que cet achat est parfois préconisé par l’intégrateur. A moins que le client ait l’opportunité de réutiliser différemment ces achats après l’échec du projet (on peut prendre l'exemple des baies qui illustre cet article), il faut considérer qu’ils ont été contractés en vain. À cet égard, le préjudice peut aller très loin, compte tenu des coûts du matériel informatique, mais aussi des contrats éventuellement conclus avec d’autres prestataires (mise en place d’un réseau de communications électroniques, fournitures diverses, etc.).

Par ailleurs, les phases de personnalisation, d’intégration et d’implémentation du progiciel s’étendent dans le temps. Pendant ces périodes, l’entreprise doit continuer de produire, et bien souvent, une partie du personnel est amenée à travailler « en double commande ». Ce mode dégradé implique des vérifications et recoupements, notamment dans les phases de validation d’aptitude au bon fonctionnement (VABF) ou, de manière plus critique, en phase de vérification de service régulier (VSR). Les préposés sont parfois amenés à travailler sur leurs anciens outils, et en même temps, sur un progiciel partiellement opérationnel, dont il s’agit de détecter les erreurs et les éventuelles non-conformités.

Si ces phases n’aboutissent pas à un progiciel opérationnel, il faut considérer que ce travail en mode « dégradé » a fait perdre en productivité. Il s’agit d’un mal nécessaire si le projet est un succès, qui sera compensé par les gains de productivité futurs… mais si le projet échoue, il s’agit encore d’une pesanteur subie en pure perte, à l’instar d’une baie de serveurs achetée en vain.

Au lieu de leur faire gagner du temps, le progiciel conduit les équipes du client à en perdre sur leur travail quotidien, parce qu’ils doivent vérifier les résultats des traitements effectués via le progiciel, sans parler de la démotivation qui risque d’accompagner une phase de qualification trop fastidieuse. Les aspects psychologiques de l’implémentation d’un nouveau progiciel sont extrêmement importants, et il n’est pas rare de voir les cocontractants se reprocher mutuellement une absence de motivation…

Il faut ici faire un sort à l’illusion, invoquée par certains plaideurs, qui réside dans l’affirmation que les salaires versés par le client à ses préposés auraient été payés « en toute hypothèse », pour contester que le temps passé par les équipes du client puisse constituer un préjudice, puisqu’en toute hypothèse, l’entreprise était tenue de payer ses salariés. Cette défense relève du sophisme : certes les salariés auraient naturellement été payés, mais ils auraient bien entendu consacré leur temps de travail rémunéré à d’autres tâches, qui elles, auraient contribué à augmenter les résultats de l’entreprise. A l’inverse, quatre mois passés à participer aux ateliers de spécification d’un progiciel qui n’est finalement jamais livré, sont quatre mois perdus. Le salarié a perdu son temps ; l’entreprise a perdu les salaires qui correspondent au temps perdu par ses employés.

Enfin, certains juges admettent même que le temps passé à rechercher un nouveau progiciel et un nouveau prestataire, suite à l’échec du précédent, constitue également un préjudice directement lié à cet échec. Et, de fait, ce temps n’aurait jamais été consacré à cette recherche si le premier prestataire avait tenu ses engagements.

S’il est finalement aisé, pour l’entreprise cliente, de décompter l’ensemble des dépenses exposées en vain, elle doit toutefois observer certaines précautions pour que ces dépenses puissent être ultérieurement considérées comme des préjudices et recevoir une juste compensation.

3. Les précautions à observer

Le client doit aménager la preuve des préjudices qu'il subit. La jurisprudence a réaffirmé avec constance que le juge ne peut estimer ceux-ci de manière forfaitaire[8]. Les précautions à prendre, pour le client, sont de trois ordres :

  • mesurer l’ensemble des enjeux liés au projet informatique ;
  • identifier et tracer l’ensemble des dépenses et ressources investies dans le projet ;
  • identifier et prévoir les gains de productivité attendus du projet.

Ces trois axes doivent être perçus comme des instruments d’une gestion optimale du projet, idéalement confiés à une Direction Qualité ou à un service spécialement dédié au pilotage du projet, au titre de la maîtrise d’ouvrage. Si de nombreux métiers de l’entreprise peuvent contribuer, à un stade ou un autre, au déroulement du projet, il est vivement conseillé qu’au moins une personne conserve une vision transversale et historicisée du projet.

Mais ces trois axes consistent en réalité, d’un point de vue contentieux, à s’assurer que les dommages éventuellement subis seront considérés comme prévisibles, directs et certains.

3.1 Assurer la prévisibilité des dommages

Beaucoup de praticiens conseillent au client de réaliser ou de commander une étude d’impact avant tout appel d’offres. Il est en effet opportun, avant de décider d’un projet qui va impacter durablement l’activité de l’entreprise et peser pendant quelques mois sur le travail de ses membres, de procéder à cette étude d’impact.

C’est cette étude qui permet d’estimer, ab initio, les coûts induits par le projet, les gains de productivité attendus, et les risques encourus en cas d’échec, Il s’agit d’un élément fort d’aide à la décision.

Il est très important, dès avant la rédaction du contrat, d’identifier avec rigueur les coûts générés en interne et en externe pour la préparation du projet, la sélection du prestataire, et l’ensemble des diligences pendant tout le projet. Tout matériel, tout service acquis aux fins de réalisation de l’ERP doit être identifié comme tel, afin d’être valorisé dans la demande d’indemnisation si le projet échoue. C’est le seul moyen dont le client dispose pour faire reconnaître son dommage.

Toutes les entreprises ne souhaitent ou ne peuvent pas commander une étude d’impact préalable au lancement de leur projet ERP. Mais à tout le moins, elles doivent décrire les enjeux du projet et les communiquer au prestataire, afin que celui-ci ait conscience des conséquences que pourraient avoir une mauvaise exécution de ses prestations. Le dommage devient alors prévisible.

L’article 1150 du Code civil dispose qu’on ne peut indemniser que les dommages qui ont été prévus ou qui étaient prévisibles lors de la conclusion du contrat. Il est donc capital, pour le client, d’exposer dès le contrat l’ensemble des enjeux techniques et économiques que le projet ERP revêt pour lui. Il est nécessaire d’informer par écrit le prestataire, dans le contrat, que l’ERP commandé conditionne l’ensemble de la chaîne de production par exemple, et donc la capacité du client à mener ses activités.

L’ERP peut également constituer la condition sine qua non d’une réorganisation stratégique de l’entreprise, en vue de la conquête de nouveaux marchés. L’ERP peut avoir un impact sur les personnels embauchés, et un échec du projet peut ainsi déséquilibrer les ressources humaines de l’entreprise.

Le prestataire auquel tous ces enjeux sont indiqués pourra difficilement prétendre par la suite qu’il ne « savait pas »… et le caractère impératif d’une date de livraison prend alors tout son sens, parce qu’il est directement corrélé aux autres activités de l’entreprise.

Outre la prévision des conséquences en cas d’accident et l’indication au prestataire des enjeux économiques du projet, le client doit également prendre soin de quantifier ce que le projet lui coûte, afin d’être en mesure de présenter l’ensemble de ces investissements comme des préjudices, entendus comme les pertes subies et les gains manqués de l’article 1149 du Code civil.

Les pertes subies s’entendent de toutes les dépenses exposées pour construire, suivre et valider le projet informatique (matériels et temps humain compris), et les gains manqués s’entendent des gains de productivité que le client était légitimement en droit d’attendre à compter de la date impérative de mise en production de l’ERP.

3.2 Etayer la variété des pertes subies

Le client que souhaite faire valoir ses préjudices doit fournir des justificatifs précis. Plus d'une décision a refusé l'indemnisation d'un client malheureux pour la simple raison qu'il ne produisait pas de documents étayant son calcul de préjudice[9]!

À l’évidence, toute dépense matérielle exposée par le client sans pouvoir être réutilisée dans un autre contexte, constitue une perte sèche pour lui.

Le coût salarial peut être double : il concerne non seulement les personnels spécialement embauchés pour pallier les carences du prestataire (spécialistes ou intérimaires), mais également l’ensemble du temps perdu par les personnels du client dans l’élaboration et le suivi du projet.

On constate ici l’importance capitale qui réside des feuilles de temps de chaque collaborateur, exposant le temps passé et le reliant directement au projet en cause (élaboration du cahier des charges et des spécifications, suivi et validations des livrables, travail en double commande imposé en raison des retards, etc.). Ce coût salarial peut d’ailleurs concerner une grande variété de personnels : équipes informatiques, contrôleurs de gestion, acheteurs, équipes commerciales, consultants… et peut s’étendre à toute prestation d’assistance à maîtrise d’ouvrage. En effet, le client qui recourt à une société d’assistance à maîtrise d’ouvrage paie ses services pendant tout le temps que dure le projet. Cette dépense sera exposée en pure perte si le projet n’aboutit à rien.

Afin d’établir le caractère direct du préjudice, c’est-à-dire son lien de causalité avec l’échec du projet, il est capital que les éléments de preuve produits par le client soient identifiés comme inhérents au projet. Les feuilles de temps doivent identifier les travaux du salarié et les relier expressément au projet. Les embauches réalisées doivent être tracées comme étant directement conditionnées par le projet, etc. Dans cette optique, doivent également être conservées toutes les notes internes, les courriers, et bien évidemment l’ensemble des comptes-rendus de réunion et de comités de pilotage, qui se révèleront des preuves particulièrement importantes en cas de litige.

Le comité de pilotage constitue en effet l’instance de pilotage du projet. S’y échangent les griefs et les solutions, de sorte que les comptes-rendus de ces comités doivent aussi comporter un chapitre consacré à la gestion des risques. Les avertissements adressés au prestataire doivent être consignés, les inquiétudes du client doivent être explicites.

La perte éprouvée doit donc s’entendre, au sens large, de la perte de temps et donc des coûts salariaux, des tiers inutilement associés au déroulement du projet, des dépenses exposées en vain, et même de celles qui seront inévitablement exposées lorsque le client devra préparer un nouveau projet de modernisation informatique.

D’autres postes de préjudice sont encore envisageables, pour autant que le client ait eu la discipline de les quantifier et de les attribuer spécifiquement à son projet ERP : préjudice d’image ; atteinte à sa valorisation financière (notamment s’il a déjà communiqué auprès de ses actionnaires ou du public sur sa modernisation informatique, en particulier s’il est côté en bourse) ; perte de chance, si l’absence de livraison en temps et heure du progiciel fait perdre un marché au client ou l’empêche de répondre avec rigueur à un appel d’offres, par exemple ; bouleversement des calculs d’amortissement des actifs de l’entreprise, etc.

Là encore, les documents probants doivent être conservés : communications financières, plaquettes commerciales vantant le nouveau système informatique en cours d’implantation, etc.

3.3 Etablir l’importance des gains manqués

Le gain manqué doit s’entendre de l’absence des gains de productivité attendus, et au-delà de l’impossibilité d’optimiser les autres investissements de l’entreprise. Il doit être indemnisé en tant que préjudice certain, par opposition à la perte de chance qui ne constitue pas un préjudice certain mais seulement potentiel.

Comme le rappelle l'Expert informatique Hubert Bitan dans son commentaire de l'arrêt de la Cour d'appel de Paris du 19 janvier 2011[10], la jurisprudence a affirmé dès 1932 que la réparation d'un préjudice futur est parfaitement admissible dès lors qu'elle apparaît comme « la prolongation certaine et directe d'un état des choses actuel et comme étant susceptible d'estimation immédiate »[11] - ce qui distingue le gain manqué de la perte de chance, qui n'est qu'hypothétique et donc moins aisément prouvée.

Si la rentabilité attendue du projet ERP n’est pas au rendez-vous, ce gain manqué, certes "futur" mais pourtant directement consécutif à l'échec du projet, doit être indemnisé. Il ne le sera que si l’entreprise est en mesure de prouver les gains de rentabilité espérés, ce qu’elle peut faire en produisant par exemple les calculs de progression de marge qui l’avaient décidé à recourir à cette technologie.

Le prestataire contestera le caractère certain de ce préjudice, puisqu'il est futur, mais de nombreuses juridictions accueillent ce type de demande, en s'appuyant sur l'idée simple selon laquelle l'entreprise qui se lance dans un projet de type ERP le fait nécessairement pour améliorer sa productivité.

En général, une entreprise souhaite s’équiper d’un ERP parce qu’elle souhaite améliorer sa performance, optimiser ses flux, et bénéficier d’une vision transversale de son activité – ce pourquoi nous parlions « d’entreprise assistée par ordinateur ». Réductions de stocks, raccourcissement des processus logistiques, automatisation des plans de maintenance des matériels, réductions d’investissements en conséquence… sont autant de postes budgétaires qui doivent être corrélés au projet d’ERP, et présentés au juge avec précision.

Le gain manqué rejoint d’ailleurs la perte subie, s’agissant de la désorganisation de l’entreprise : non seulement est-elle privée de l’amélioration de ses processus par automatisation, mais elle doit en outre subir les ralentissements et les risques d’erreur que lui font courir le maintien de ses anciens outils, ou le travail en double-commande qui exige tant de vérifications et de recoupements.

Cette notion de désorganisation constitue un préjudice, comme l’indique la Cour d’appel de Paris dans un arrêt du 25 mai 2005[12] à propos la perte de temps de tout le personnel, occupé à répondre aux réclamations des clients suite aux dysfonctionnements d’un logiciel.

Toutes ces précautions permettent d’assurer, le cas échéant, une véritable « réparation intégrale » des préjudices subis par le client. Plus l’information relative à ces enjeux connexes sera précise, voire chiffrée, plus le client aura la possibilité d’étayer la réalité et la quotité des dommages subis devant le juge. Il est important qu’une évocation des gains espérés figure au contrat, afin d’en faire des préjudices prévisibles. Le cahier des charges, notamment, est tout désigné à cette fin. Idéalement, le contrat lui-même précise quels sont ces enjeux.

Mais, afin que ces précautions ne restent pas lettre morte, il est également important de surveiller les clauses relatives à la responsabilité du prestataire, que celui-ci tient évidemment à limiter du mieux qu’il peut. Il s’agit là des clauses limitatives ou exonératoires de responsabilité, qui nourrissent une abondante jurisprudence.


4. La limitation contractuelle du montant des préjudices

Les contrats informatiques comportent également très souvent des clauses relatives à la réparation des éventuels dommages provoqués par l’une des parties, en particulier le prestataire. Ces clauses sont de deux types : elles s’appliquent soit à l’étendue de la prestation promise, soit, de façon plus fréquente, à l’étendue du droit à réparation du client.

Ces dernières plafonnent le montant de l’indemnisation que le prestataire serait amené à payer au client en cas de dommage, et sont en principe négociées entre les parties. Elles sont toutefois écartées de plein droit si le prestataire commet une faute lourde, révélant une particulière incompétence ou une incurie grave, ou s’il commet une faute dolosive, révélant une intention de nuire.

Ces clauses influent forcément sur le coût des prestations proposées, notamment parce qu’elles conditionnent le montant des polices d’assurances que le prestataire doit contracter. Ces clauses participent pleinement à l’économie du contrat, et le client doit avoir à l’esprit qu’elles influent sur son équilibre.

Leur rédaction peut inclure l’indemnisation du damnum emergens et exclure celle du lucrum cessans, distinguer entre dommages « directs » et dommages « indirects » pour exclure la réparation des seconds, plafonner le montant total de l’indemnisation à un multiple du montant du contrat, l’aligner sur le montant de la police d’assurance du prestataire, etc. Ces clauses doivent être examinées avec soin par le client, car elles sont généralement proposées sinon imposées par le prestataire, et qu’elles seront considérées comme acceptées en tant que telles dès lors qu’elles figurent au contrat signé par le client.

Outre les cas de faute lourde ou dolosive, la jurisprudence a identifié, il y a déjà quelques années, le risque de voir ce type de clause permettre au prestataire d’avoir toute latitude entre exécuter correctement ses prestations, ou abandonner l’exécution du contrat moyennant le paiement d’un montant indemnitaire contractuellement borné par ses soins. Le caractère potestatif (soumis à la discrétion d’une seule des parties) de certaines clauses, dans le cadre de contrats à exécution successive notamment, a amené la Cour de cassation à forger la théorie des obligations essentielles.

Depuis l’arrêt de principe Chronopost du 22 octobre 1996[13], et encore récemment dans l’arrêt Faurecia II du 13 février 2007[14], la Cour de cassation a régulièrement énoncé que si la clause limitative de responsabilité permettait au prestataire de « choisir » de ne pas exécuter le contrat, dès lors qu’il sait déjà le coût total qu’une telle inexécution engendrera pour lui puisqu’il l’a lui-même déterminé… alors cette clause a pour effet de vider le contrat de sa substance, en ôtant tout caractère contraignant aux engagements contractuels du prestataire.

Certains commentateurs ont d’ailleurs écrit que l’arrêt Faurecia II du 13 février 2007[15] procède à une application trop systématique de la théorie, et anéantit l’intérêt des clauses limitatives de responsabilité (ou cantonne leurs effets aux seules obligations « non essentielles »). Ils s’appuient volontiers sur l’arrêt de la Cour d'appel de renvoi (Paris), dit «Faurecia III » en date du 26 novembre 2008[16], qui tente effectivement de cantonner les effets de la théorie des obligations essentielles.

Toutefois, la Cour d'appel de renvoi s’est placée non plus sur le terrain de l’exécution contractuelle défaillante, mais sur le terrain de la formation du contrat, pour constater que la clause avait été spécifiquement acceptée par le client, dans un contrat où la fixation même du prix avait été liée à la fixation du plafond de responsabilité du prestataire, de manière explicite, pour une « prise en charge partagée du risque ». Ainsi, la Cour a énoncé que le manquement à une obligation essentielle ne peut conduire à écarter la clause limitative de responsabilité que pour autant que cette clause n’a pas été négociée par le client, ou si elle est d’un montant dérisoire.

Selon cet arrêt de la saga Faurecia, confirmé par la chambre commerciale de la Cour de cassation du 29 juin 2010, ce n’est que si le plafond d’indemnisation est dérisoire qu’il vide le contrat de sa substance. En l’espèce, la Cour a estimé que le montant du plafond n’étant pas dérisoire, il pouvait s’appliquer en dépit de l’absence totale de livraison du progiciel[17].

Il semble toutefois prématuré de voir dans cette décision un véritable coup d’arrêt au développement de la théorie, dans la mesure où les faits de l’espèce sont assez particuliers. Le prestataire était en effet en mesure d’établir que le plafond d’indemnisation avait été négocié par les parties, et expressément intégré dans l’équilibre économique du contrat.

Le plus souvent pourtant, il n’y a pas de réelle négociation de ce plafond d’indemnisation. Il est rare que les parties le prennent en compte dans le calcul du prix des prestations. On doit donc estimer qu’en principe, en cas de manquement à l’obligation essentielle de l’intégrateur (livrer un progiciel conforme dans les délais convenus), le plafond d’indemnisation tombe. Le client peut alors faire valoir l’ensemble de ses préjudices, pertes éprouvées et gains manqués dûment établis, sans se heurter au plafond d’indemnisation stipulé par le prestataire.

5. Conclusion

Un projet d’implémentation d’ERP est un projet stratégique. Il implique des investissements et des ressources en amont, et pendant tout son déroulement. Il conditionne un grand nombre d’autres projets et activités au sein de l’entreprise.

Ces investissements et ces enjeux doivent impérativement être portés à la connaissance du prestataire choisi, et doivent, idéalement, être précisés au contrat, afin de constituer des « préjudices prévisibles ».

Ils doivent également être scrupuleusement tracés et reliés au projet ERP, qu’il s’agisse des dépenses concrètes ou de la rémunération des personnels impliqués, afin de constituer des « préjudices immédiats et directement » liés à l’échec du projet.

Ils doivent également être pris en compte dans le calcul de l’éventuel plafond de responsabilité du prestataire, qui aura tendance à limiter celle-ci. Certes, la jurisprudence relative aux obligations essentielles permet de combattre ces plafonds s’ils vident le contrat de sa substance, mais en toute hypothèse, le plafond de responsabilité doit être pensé par le client à l’aune de l’ensemble des enjeux liés au projet.

Un projet ERP ne peut ni ne doit être conçu de façon isolée des autres activités de l’entreprise, parce qu’il les conditionne souvent toutes. Une telle réforme des pratiques de l’entreprise doit donc s’entourer de toutes les précautions possibles, et chaque euro dépensé pour son succès… doit être identifié et tracé par le client afin d’être indemnisé en cas d’échec.

De son côté, le prestataire a tout intérêt à responsabiliser le client sur les tâches qui incombent à celui-ci (notion de matrice des tâches), et à préciser de manière très précise les contours de son engagement, le périmètre fonctionnel et technique dont il est responsable, les informations au vu desquelles il s’engage, et les limitations de responsabilité dont il entend assortir sa prestation, afin que chacune des deux parties s’engage en pleine connaissance de cause.

Voir aussi

« <strong class="error">Erreur d’expression : opérateur / inattendu.</strong> » n’est pas un nombre.


Notes et réfèrences

  1. CA Paris, 15 novembre 1988, Expertises 1989 p.72
  2. CA Paris chambre 25 section A, 1er février 2002, Sté Fichorga, CCE 2002, n°103
  3. CA Colmar, 13 avril 2006, GMBH Industrial Application Software c/ Sté Escarmor, Lamy droit de l’immatériel juillet/août 2006 p.49 ; Cour d’appel de Paris, 25e ch. 2 septembre 2005, n°2004/786
  4. Cass. Civ. I, 3 juillet 2001 GST Alcatel, et également Cass. Com, 11 juillet 2006, n°04-17.093
  5. CCE juin 2004, com. 77 sous CA Paris 25e ch. 10 octobre 2003
  6. Cour de cassation, civile, Chambre commerciale, 7 octobre 2008, 07-15.423, Inédit
  7. Cour d'appel de Pris, Pôle 5 chambre 10, Comexposium / Axe Selection, , en ligne sur legalis.net, Expertises n°360, juillet 2011
  8. Cass. Com, 24 novembre 2009, n°08-16428
  9. voir par exemple CA Paris, 3e chambre, 15 septembre 2006, n°05/22450
  10. Cour d'appel de Pris, Pôle 5 chambre 10, Comexposium / Axe Selection, revue Lamy Droit de l'Immatériel n°74 p. 43
  11. Cass. req., 1er juin 1932 : D. 1932, 1, p. 102
  12. SAS Horizon 2000 Informatique c/ SARL Etude Colonna d’Istria
  13. Cass. com., 22 octobre 1996, 93-18632
  14. Cass. com., 13 février 2007, 05-17407, Bulletin 2007, IV, N° 43
  15. op. cit.
  16. CA Paris, 25e ch., sect. A, 26 nov. 2008, Faurecia Sièges d’automobiles c/ Oracle France, n° 07/07221
  17. Cass. comm, 29 juin 2010, 09-11841, Bulletin 2010, IV, n° 115