Source: http://www.lagbd.org/index.php/Progiciel_de_gestion_int%C3%A9gr%C3%A9_:_indemnisation_des_pr%C3%A9judices_du_client_en_cas_d%27%C3%A9chec_du_projet_(fr)
Timestamp: 2017-09-24 17:45:04+00:00
Document Index: 3199506

Matched Legal Cases: ['arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ', 'arrêt ']

Progiciel de gestion intégré : indemnisation des préjudices du client en cas d'échec du projet (fr) - La GBD
France > Droit privé > Droit de l'informatique
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 1. Complexité des projets informatiques ERP
2 2. La composition du préjudice du client et son appréciation par le juge
2.1 2.1 L’élémentaire distinction entre créances de restitution et d’indemnisation
2.2 2.2 La variété des postes de préjudices
3 3. Les précautions à observer
3.1 3.1 Assurer la prévisibilité des dommages
3.2 3.2 Etayer la variété des pertes subies
3.3 3.3 Etablir l’importance des gains manqués
4 4. La limitation contractuelle du montant des préjudices
7 Notes et réfèrences
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.
On mesure l’ampleur de l’impact du projet sur l’organisation et la production de l’entreprise.
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].
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 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.
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].
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.
À 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.).
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.
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.
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é.
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.
4. La limitation contractuelle du montant des préjudices
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].
Trouver la notion "progiciel de gestion intégrée" OR "Entreprise Resource Planning" OR ERP OR PGI AND indemnisation préjudice dans l'internet juridique français
Notes et réfèrences
↑ CA Paris, 15 novembre 1988, Expertises 1989 p.72
↑ CA Paris chambre 25 section A, 1er février 2002, Sté Fichorga, CCE 2002, n°103
↑ 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
↑ Cass. Civ. I, 3 juillet 2001 GST Alcatel, et également Cass. Com, 11 juillet 2006, n°04-17.093
↑ CCE juin 2004, com. 77 sous CA Paris 25e ch. 10 octobre 2003
↑ Cour de cassation, civile, Chambre commerciale, 7 octobre 2008, 07-15.423, Inédit
↑ Cour d'appel de Pris, Pôle 5 chambre 10, Comexposium / Axe Selection, , en ligne sur legalis.net, Expertises n°360, juillet 2011
↑ Cass. Com, 24 novembre 2009, n°08-16428
↑ voir par exemple CA Paris, 3e chambre, 15 septembre 2006, n°05/22450
↑ Cour d'appel de Pris, Pôle 5 chambre 10, Comexposium / Axe Selection, revue Lamy Droit de l'Immatériel n°74 p. 43
↑ Cass. req., 1er juin 1932 : D. 1932, 1, p. 102
↑ SAS Horizon 2000 Informatique c/ SARL Etude Colonna d’Istria
↑ Cass. com., 22 octobre 1996, 93-18632
↑ Cass. com., 13 février 2007, 05-17407, Bulletin 2007, IV, N° 43
↑ CA Paris, 25e ch., sect. A, 26 nov. 2008, Faurecia Sièges d’automobiles c/ Oracle France, n° 07/07221
↑ Cass. comm, 29 juin 2010, 09-11841, Bulletin 2010, IV, n° 115
Récupérée de « http://www.lagbd.org/index.php?title=Progiciel_de_gestion_intégré_:_indemnisation_des_préjudices_du_client_en_cas_d%27échec_du_projet_(fr)&oldid=56928 »
Dernière modification de cette page le 19 mai 2014, à 10:28.