Contrat d'intégration (ERP, logiciel) : sécuriser un projet d'intégrateur

Un projet ERP coûte souvent plus cher que prévu, prend plus de temps que prévu, et finit parfois devant un expert judiciaire. Dans l'affaire MAIF contre IBM, un contrat d'intégration clé en main signé pour 7,3 millions d'euros HT s'est terminé par une résolution aux torts de l'intégrateur et plus de 6,6 millions d'euros de dommages et intérêts. Le code n'était pas le premier sujet : le besoin, le conseil, le périmètre et la collaboration l'étaient. Le contrat d'intégration est l'outil qui répartit ces risques avant qu'ils se réalisent.

Éditeur, intégrateur, client : trois acteurs pour un contrat d'intégration

Un projet d'intégration réunit presque toujours trois parties. L'éditeur détient les droits sur le progiciel et concède les licences. L'intégrateur paramètre, développe les spécifiques, reprend les données, forme les utilisateurs et pilote parfois l'ensemble. Le client exprime son besoin, met ses équipes à disposition et recette. Chacun signe avec un autre, rarement avec les deux.

Qui signe quoi

Le schéma courant comprend un contrat de licence et un contrat de maintenance avec l'éditeur, un contrat d'intégration avec l'intégrateur, et parfois un contrat d'assistance à maîtrise d'ouvrage avec un troisième prestataire. Dans l'affaire Antilles glaces (Cass. com., 14 mars 2018, n° 16-24.635), le client avait signé avec IBM un contrat d'étude des besoins, puis un « contrat d'intégration du progiciel ERP Movex et de ses développements spécifiques », tandis que l'éditeur Lawson lui concédait la licence, le support et les développements. IBM et Lawson avaient en outre conclu entre eux deux contrats de prestation. Quand le projet s'est arrêté, en 2007, la question de savoir qui devait quoi à qui occupait encore la Cour de cassation en 2018.

Co-traitance ou sous-traitance

La qualification compte. Dans un arrêt du 4 novembre 2021 (CA Orléans, n° 20/00415), l'éditeur d'un ERP soutenait n'être que le sous-traitant de l'intégrateur, pour échapper à l'action du client. La cour a refusé : l'offre était rédigée au nom des deux sociétés, le contrat répartissait les tâches entre elles et l'éditeur était payé directement par le client. Elles étaient co-traitantes, chacune tenue envers le client. Un intégrateur qui revend les licences de l'éditeur ou qui fait intervenir ses consultants doit donc écrire noir sur blanc qui est engagé sur quoi.

Un ensemble contractuel

Depuis 2016, l'article 1186 du Code civil organise la caducité en chaîne : lorsque plusieurs contrats sont nécessaires à la réalisation d'une même opération et que l'un disparaît, les contrats dont l'exécution devient impossible, ou dont il était une condition déterminante, deviennent caducs, à condition que le cocontractant ait connu l'opération d'ensemble au moment de son consentement. Pour un client, c'est l'argument qui permet de ne pas payer cinq ans de licences d'un ERP qui ne sera jamais déployé. Pour l'éditeur, c'est la raison de ne pas mentionner le projet dans sa licence. Pour le rédacteur, c'est un point à trancher explicitement.

Expression du besoin et devoir de conseil de l'intégrateur

L'intégrateur est un professionnel de l'informatique ; son client, le plus souvent, ne l'est pas. Cette asymétrie fonde un devoir de conseil que la jurisprudence applique avec constance aux projets de progiciel, mais qu'elle module selon la compétence du client et la répartition des tâches écrite au contrat.

Avant la signature

L'article 1112-1 du Code civil oblige la partie qui connaît une information déterminante pour le consentement de l'autre à la lui délivrer. Les parties ne peuvent ni limiter ni exclure ce devoir. Celui qui se dit mal informé doit prouver que l'information lui était due ; l'autre doit prouver qu'il l'a fournie. En pratique, l'intégrateur qui sait que le progiciel standard ne couvre qu'une partie du besoin exprimé et que le reste exigera des développements spécifiques doit le dire, et le prouver par écrit. Un manquement peut conduire à la nullité du contrat, en plus de la responsabilité.

Pendant l'exécution

Le devoir de conseil ne s'arrête pas à la signature. Dans l'affaire Antilles glaces, le projet s'était bloqué faute de livraison par l'éditeur d'un module « vente à la Chine ». IBM avait continué à facturer 100 000 euros par mois pendant l'attente. La cour d'appel a jugé qu'IBM aurait dû conseiller une suspension des travaux, et que les sommes versées de mars 2006 à juillet 2007 l'avaient été en pure perte. La Cour de cassation a validé la restitution de 1 802 625 euros TTC. Le message à l'intégrateur est net : quand le projet ne peut pas avancer, continuer à facturer sans alerter est une faute.

La part du client

Le conseil a une limite : le client doit dire ce dont il a besoin et faire ce qu'il a promis. Dans l'affaire Sage (Cass. com., 8 février 2017, n° 15-17.222), le contrat mettait la reprise des anciennes données à la charge exclusive des clientes. Elles ne l'avaient pas faite, les lots suivants n'avaient pas pu démarrer, et elles reprochaient à l'éditeur d'avoir sous-estimé les délais. La Cour a approuvé le rejet de leurs demandes : pas de devoir de conseil sur des tâches que le client s'est engagé à réaliser seul. Dans l'affaire MAIF (Cass. com., 4 juin 2013, n° 12-13.002), les juges ont relevé que le client disposait d'une division informatique très étoffée et que le dérapage tenait notamment au « fort cloisonnement » et au « manque de collaboration » entre ses propres équipes.

Conseil d'avocat. Le cahier des charges n'est pas une formalité. C'est la pièce qui permettra, trois ans plus tard, de dire si le progiciel livré est conforme. Le client a intérêt à le rédiger avec précision ; l'intégrateur a intérêt à formuler par écrit ses réserves sur les points flous, et à conserver la trace de ses alertes.

Forfait ou régie : qui porte le risque du dépassement

Le mode de rémunération décide de la répartition du risque financier. Il conditionne aussi la nature de l'obligation de l'intégrateur.

Le forfait

Au forfait, l'intégrateur s'engage sur un périmètre, un prix et un calendrier. Le dépassement est pour lui, sauf changement de périmètre demandé par le client. Le forfait rapproche son obligation d'une obligation de résultat sur les livrables décrits. Il n'a de sens que si le périmètre est figé et la description du besoin suffisamment fine pour que l'intégrateur puisse chiffrer.

Le forfait ne met pas le client à l'abri de ses propres choix. Dans l'affaire MAIF, le client soutenait avoir été trompé sur le risque de dépassement d'un forfait de 7 302 822 euros HT. La Cour de cassation a approuvé le rejet de l'action en nullité pour dol : c'était la MAIF qui, hors toute concurrence, avait imposé le forfait ; le plan projet avait été revu par ses équipes ; professionnel averti, elle disposait des moyens d'apprécier le risque.

La régie

En régie, le client achète des jours-hommes. L'intégrateur s'engage sur la compétence et la diligence de ses consultants, pas sur le résultat. Le dépassement est pour le client, qui doit donc piloter : validation des feuilles de temps, comités, arbitrages. La régie convient aux phases exploratoires et aux évolutions continues, mal aux déploiements où le client attend un système qui fonctionne à une date donnée. Elle impose aussi de surveiller le lien de subordination : un consultant intégré aux équipes et dirigé par le client expose l'intégrateur à une requalification en prêt de main-d'œuvre illicite, interdit par l'article L8241-1 du Code du travail.

Les formules mixtes

La pratique combine souvent les deux : un forfait par lot fonctionnel, une régie plafonnée pour les spécifiques mal définis, une enveloppe de jours pour la conduite du changement. L'important est que chaque prestation soit rattachée sans ambiguïté à un régime. Un contrat qui dit « forfait » en page de garde et « estimation indicative » en annexe financière ne protège personne.

Jalons, livrables et recette

Un ERP se livre par étapes : conception générale, conception détaillée, paramétrage, développements spécifiques, reprise des données, recette, bascule, vérification de service régulier. Le contrat doit faire de chaque étape un jalon, avec un livrable identifié, une condition d'entrée et une conséquence financière.

Les conditions préalables

L'affaire Sage montre que les jalons dépendent souvent d'une tâche du client. Reprise des données, mise à disposition des utilisateurs clés, environnement technique, réseau : chaque prérequis doit être nommé, daté et rattaché à son débiteur. Le contrat prévoit ce qui se passe quand le prérequis manque : décalage du calendrier, facturation des jours d'attente, droit de suspendre. Sans ces clauses, chaque retard devient une discussion sur la causalité.

Le paiement par jalons

L'échéancier suit les jalons, pas le calendrier. Pour le client, une part significative du prix doit rester due après la recette définitive. Pour l'intégrateur, un acompte à la commande et des paiements à la validation des livrables intermédiaires évitent de financer le projet. Une retenue de garantie, libérée à la fin de la période de garantie, sert les deux : elle donne au client un levier, et elle fixe à l'intégrateur une date de fin.

La recette

La recette est le moment où le contrat produit ses effets : transfert de la charge des corrections, déclenchement des paiements, point de départ de la garantie. Ses étapes, la valeur du PV, les réserves et la recette tacite sont détaillées dans l'article consacré à la recette informatique et au PV de recette. Pour le contrat d'intégration, trois points méritent d'être écrits : la classification des anomalies (bloquante, majeure, mineure), le nombre de cycles de recette inclus dans le prix, et le sort d'un projet qui échoue deux fois à la même recette.

Licences de l'éditeur : le contrat que l'intégrateur ne maîtrise pas

L'intégrateur s'engage sur un projet bâti sur un logiciel qui ne lui appartient pas. Le client, lui, paie des licences dont la valeur dépend du succès de l'intégration.

Le logiciel promis qui n'existe pas encore

L'affaire Faurecia en est le cas d'école. En 1998, l'équipementier signe avec Oracle pour un progiciel intégré dont la version V12 ne doit pas être disponible avant septembre 1999 : licences, maintenance, formation et mise en œuvre. La V12 n'est jamais livrée. La Cour de cassation juge que la livraison de cette version, objectif final des contrats, était une obligation essentielle (Cass. com., 13 février 2007, n° 05-17.407). Pour le client, la leçon est de rattacher le projet à des fonctionnalités disponibles à la signature, ou d'écrire ce qui se passe si la feuille de route de l'éditeur glisse.

Métriques, correction d'erreurs et développements spécifiques

Trois clauses de la licence pèsent directement sur l'intégration. La métrique d'abord : utilisateurs nommés, sessions, cœurs de processeur, volume de transactions. Une interface développée par l'intégrateur qui fait appeler le progiciel par un autre système peut consommer des droits que personne n'a budgétés. La correction des erreurs ensuite : l'article L122-6-1 du Code de la propriété intellectuelle permet à l'utilisateur légitime de corriger les erreurs, mais autorise l'éditeur à se réserver ce droit par contrat. Si la licence le réserve, l'intégrateur ne peut pas promettre de corriger le cœur du progiciel. Les développements spécifiques enfin : l'article L113-9 du même code dévolue à l'employeur les droits sur le logiciel créé par ses salariés, mais ce mécanisme ne joue pas entre un intégrateur et son client. Sans clause de cession conforme à l'article L131-3 (chaque droit cédé mentionné distinctement, domaine délimité quant à l'étendue, la destination, le lieu et la durée), le client n'est pas titulaire des spécifiques qu'il a payés.

L'articulation des contrats

Le client a intérêt à faire reconnaître par l'éditeur l'existence du projet d'ensemble, pour bénéficier de la caducité de l'article 1186 si l'intégration échoue. L'intégrateur a intérêt à exclure de sa responsabilité les défauts du progiciel standard, à condition de le faire clairement et sans vider de substance son propre engagement.

Responsabilité et clauses limitatives dans le contrat d'intégration

Chaque intégrateur plafonne sa responsabilité. Chaque client, le jour du contentieux, cherche à faire tomber le plafond.

L'obligation essentielle et le plafond

Dans la première décision Faurecia, la Cour de cassation a écarté la clause limitative en raison du manquement à l'obligation essentielle. Sur renvoi, la cour d'appel a de nouveau appliqué le plafond, et la Cour a cette fois approuvé (Cass. com., 29 juin 2010, n° 09-11.841) : seule est réputée non écrite la clause qui « contredit la portée de l'obligation essentielle ». Le plafond, égal au prix des licences, n'était pas dérisoire ; Oracle avait consenti une remise de 49 % et des contreparties. Le client a obtenu la garantie d'une condamnation de 203 312 euros, rien de plus. L'article 1170 du Code civil a repris cette solution : est réputée non écrite la clause qui prive de sa substance l'obligation essentielle. La jurisprudence tend à apprécier le caractère dérisoire du plafond au regard du prix et de l'économie du contrat, pas du préjudice finalement subi.

La faute lourde

L'article 1231-3 du Code civil limite la réparation au dommage prévisible, sauf faute lourde ou dolosive. Faurecia précise que la faute lourde ne peut résulter du seul manquement à une obligation, même essentielle : elle se déduit de la gravité du comportement du débiteur. Un intégrateur qui cache un blocage technique pendant des mois ou facture des prestations qu'il sait inutiles s'en approche ; un intégrateur qui échoue malgré ses efforts, non.

Le contrat d'adhésion

Lorsque le contrat est proposé sur les conditions générales de l'intégrateur, sans négociation réelle, l'article 1171 du Code civil permet d'écarter la clause non négociable qui crée un déséquilibre significatif. Un client qui a négocié son contrat aura plus de mal à l'invoquer. Les limites d'une clause limitative côté prestataire sont analysées dans l'article sur la clause limitative de responsabilité du prestataire IT.

Point de vigilance. Un plafond fixé à « 100 % des sommes perçues au titre du présent contrat » ne vaut pas grand-chose pour le client si les paiements sont concentrés en fin de projet : au moment de l'échec, l'intégrateur n'a presque rien perçu. Le client a intérêt à fixer le plafond par référence au prix total du contrat, et l'intégrateur à exclure explicitement les préjudices indirects qu'il ne veut pas assumer.

Changements de périmètre : avenants, protocoles et novation

Aucun projet ERP ne se termine avec le périmètre de départ. Ce qui distingue un projet maîtrisé d'un projet en dérive, c'est la procédure qui encadre ces changements.

La procédure de demande de changement

Le contrat prévoit qui peut demander un changement, sous quelle forme, dans quel délai l'intégrateur chiffre l'impact sur le prix et le calendrier, et qui le valide côté client. Tant que le changement n'est pas signé, le périmètre initial s'applique. Pour l'intégrateur, cette procédure est la seule protection contre l'accumulation de demandes orales qui finissent par faire exploser un forfait. Pour le client, c'est la garantie qu'aucun supplément ne sera facturé sans accord écrit.

Le protocole de recadrage

Quand le projet dérive fortement, les parties signent souvent un protocole qui décale le calendrier et augmente le prix. Dans l'affaire MAIF, un premier protocole avait repoussé les échéances et augmenté les prestations d'intégration de près de 4 millions d'euros, un second avait révisé le projet. La cour d'appel en avait déduit que la MAIF ne pouvait plus se prévaloir des engagements initiaux. Cassation (Cass. com., 4 juin 2013) : la novation ne se présume pas. Sans volonté non équivoque de substituer de nouveaux engagements aux anciens, le contrat initial demeure. Sur renvoi, le contrat d'intégration a été résolu aux torts d'IBM, condamnée à 6 677 102,03 euros de dommages et intérêts, et le pourvoi contre cette décision rejeté (Cass. com., 29 mars 2017, n° 15-16.010).

Un intégrateur qui négocie un protocole a donc intérêt à y faire préciser ce qu'il remplace et ce que le client abandonne. Un client qui accepte un recadrage a intérêt à réserver expressément ses droits sur les manquements antérieurs.

Projet d'intégration en échec : les leviers du client et de l'intégrateur

Quand l'ERP ne fonctionne pas et que les relations se tendent, chaque décision a des conséquences sur le procès qui suivra. Les recours de droit commun et la stratégie judiciaire sont exposés dans l'article sur les recours après l'échec d'un projet informatique ; voici ce qui est propre à l'intégration.

Les remèdes du Code civil

L'article 1217 du Code civil ouvre cinq remèdes : exception d'inexécution, exécution forcée, réduction du prix, résolution, dommages et intérêts. Ceux qui ne sont pas incompatibles se cumulent, et les dommages et intérêts peuvent toujours s'y ajouter. Suspendre les paiements (article 1219) suppose une inexécution suffisamment grave : un client qui cesse de payer pour des anomalies mineures prend le risque d'être lui-même en faute. La réduction du prix (article 1223) suppose une mise en demeure puis une notification si le prix n'est pas encore payé ; s'il l'est, à défaut d'accord, il faut la demander au juge. La résolution par notification (article 1226) suppose une mise en demeure qui mentionne expressément la résolution ; le client agit « à ses risques et périls » et devra prouver la gravité du manquement si l'intégrateur conteste.

Les restitutions

L'article 1229 distingue deux situations. Si les prestations ne pouvaient trouver leur utilité que dans l'exécution complète du contrat, tout est restitué : c'est l'argument du client pour un ERP jamais mis en production. Si elles ont trouvé leur utilité au fur et à mesure, il n'y a pas de restitution pour la période antérieure à la dernière prestation restée sans contrepartie : c'est l'argument de l'intégrateur qui a livré des lots exploités. L'affaire Antilles glaces montre que le juge peut ordonner la restitution ciblée des sommes payées pour des prestations inutiles.

La preuve

Dans l'affaire jugée par la cour d'Orléans, le client avait fait dresser deux constats par huissier de justice (aujourd'hui commissaire de justice). La cour les a admis, mais a relevé qu'ils prouvaient le mauvais fonctionnement du logiciel, pas sa cause : mauvaise utilisation, erreur de manipulation, paramétrage ou défaut du logiciel ? Le client a perdu. Dans un projet d'intégration, la cause se démontre par une expertise technique, idéalement judiciaire et contradictoire. Le délai pour agir est de cinq ans à compter du jour où le titulaire du droit a connu ou aurait dû connaître les faits (article 2224 du Code civil, article L110-4 du Code de commerce entre commerçants). Quand le contentieux devient inévitable, mieux vaut le préparer avec un avocat en contentieux informatique avant d'envoyer la lettre de résolution.

Sécuriser le contrat avant le premier atelier

La plupart des contentieux d'intégration se jouent sur des clauses qui auraient pu être écrites en une page : la répartition des tâches, les prérequis du client, le régime de chaque prestation, la procédure de changement, le sort des licences si le projet s'arrête. Je rédige et négocie ces contrats pour des clients qui lancent un ERP comme pour des intégrateurs qui veulent protéger leur marge, avec une lecture technique du projet que mon parcours de développeur rend directe. Pour la rédaction ou la revue de vos contrats informatiques, ou pour un projet déjà en difficulté, vous pouvez échanger avec moi sur votre projet d'intégration.