Quantic Avocats, cabinet d’avocats en contentieux logiciel ERP, accompagne depuis près de 20 ans des entreprises confrontées à un projet de logiciel ERP (Enterprise Resource Planning) défaillant. Refonte des processus, centralisation des données, transformation organisationnelle profonde : lorsqu’un projet de progiciel ERP déraille, les conséquences sont immédiates et souvent sévères, telles que, par exemple, désorganisation des équipes, blocage des opérations critiques, dérive budgétaire, pertes d’exploitation.
Les litiges logiciel ERP présentent une complexité particulière : documentation contractuelle dense, multiplicité d’acteurs (éditeur, intégrateur, client, parfois infogérant), enjeux techniques élevés et montants en jeu souvent considérables. Nos avocats en contentieux logiciel ERP interviennent pour structurer la stratégie, identifier les responsabilités et défendre les intérêts de l’entreprise, de la mise en demeure jusqu’au jugement.
À propos de l’auteur
Cette page a été rédigée et est tenue à jour par Maître François-Xavier Langlais, avocat associé chez Quantic Avocats, anciennement co-président de la Commission droit du numérique de l’ACE. Près de 20 ans de pratique exclusive en contentieux informatique, dont un nombre significatif de dossiers de contentieux logiciel ERP à forts enjeux.
→ Biographie complète – Profil LinkedIn
Avocat contentieux informatique: vue d’ensemble des litiges IT
Cette page traite du contentieux ERP. Pour une vision complète des litiges informatiques (SaaS, infogérance, violation de licences, logiciel sur mesure), consultez notre page dédiée.
Qu’est-ce qu’un contentieux portant sur un logiciel ERP ?
Un contentieux portant sur un logiciel ERP est un litige né de l’exécution défaillante ou de la rupture d’un contrat portant sur la conception, le déploiement ou l’exploitation d’un progiciel ERP de gestion intégrée.
Il peut opposer le client à l’intégrateur, à l’éditeur du logiciel, au prestataire de maintenance, ou simultanément à plusieurs d’entre eux.
L’intervention d’un avocat familiarisé avec ce type de contentieux dès l’apparition des premières difficultés est déterminante pour préserver les preuves et structurer la stratégie.
Sur le plan juridique, ces litiges relèvent du droit commun des contrats (articles 1103 et suivants du Code civil), aucune loi spécifique ne régissant les relations entre les parties à un contrat d’intégration de progiciel.
La jurisprudence des tribunaux de commerce est abondante et constitue le principal référentiel. Elle évolue continuellement sur des questions clés comme la qualification des obligations de l’intégrateur (résultat, moyen renforcé, moyen), la recette tacite, le devoir de conseil ou le partage de responsabilité.
Les contentieux portant sur des projets ERP se distinguent des autres litiges informatiques par :
- des projets longs (12 à 36 mois),
- des contrats complexes (licence, intégration, paramétrage, formation, maintenance),
- des acteurs multiples dont les responsabilités respectives sont souvent contestées, et
- des préjudices financiers qui atteignent fréquemment plusieurs centaines de milliers d’euros, voire plusieurs millions dans les projets structurants.
| Type de litige ERP | Situations typiques (exemples) | Enjeu principal |
|---|---|---|
| Retard de livraison | Planning non respecté, jalons non respectés sans justification | Pertes d’exploitation + remboursement |
| Non-conformité | Solution ne couvre pas le périmètre fonctionnel contractualisé | Résiliation + indemnisation des investissements perdus |
| Abandon du projet | Le prestataire informatique cesse les prestations ou se retrouve en liquidation | Restitution + coûts de replacement |
| Dérive budgetaire | Surcoûts imposés sans avenant validé | Contestation des factures + préjudice |
| Recette tacite contestée | Mise en production sans procès-verbal validé par l’entreprise cliente | Qualification juridique + nullité |
| Responsabilité multi-acteurs | Éditeur + intégrateur | Cartographie des responsabilités |
Pourquoi les projets portant sur des logiciels ERP échouent ?
L’échec d’un projet ERP résulte rarement d’un seul facteur.
Il s’agit le plus souvent d’une accumulation de difficultés techniques, organisationnelles et contractuelles.
Il est essentiel de qualifier chaque difficulté : est-elle imputable au prestataire, au client, ou aux deux ? Cette qualification conditionne la stratégie contentieuse.
Défaut de conseil et d’audit préalable de l’intégrateur
L’intégrateur est tenu d’une obligation de conseil renforcée dès la phase précontractuelle.
Il doit s’enquérir avec précision des besoins du client, évaluer la faisabilité du projet dans le périmètre proposé et alerter sur les risques identifiés.
Un défaut d’audit préalable ou une sous-estimation des développements spécifiques nécessaires engage sa responsabilité, indépendamment de la qualité apparente du cahier des charges remis par le client.
Responsabilité du prestataire en cas de cyberattaque : la faute doit être prouvée
CA Rennes, 3 février 2026 – L’intégrateur ne peut invoquer le défaut d’expression du besoin client
La Cour d’appel de Rennes a récemment confirmé la condamnation d’un intégrateur ERP en retenant que c’est à lui qu’il revenait de s’enquérir avec précision des besoins de son client.
Enseignement pratique : l’argument du ‘cahier des charges insuffisant fourni par le client’ ne suffit pas à exonérer l’intégrateur si ce dernier n’a pas lui-même diligementé un audit approfondi des besoins.
→ Source : Décision Cour d’appel de Rennes, 3 février 2026 RG °24/05422
Mauvaise définition du périmètre fonctionnel et spécifications évolutives
Un cahier des charges vague ou des spécifications fonctionnelles insuffisamment détaillées créent un terrain fertile aux litiges.
Le risque est double :
- Le client estime que la solution livrée ne couvre pas ses besoins réels;
- Le prestataire considère que les demandes du client dépassent le périmètre contractualisé.
La qualification juridique de ce périmètre et de ses évolutions est au cœur de la majorité des contentieux ERP.
Défaut de pilotage et de gouvernance du projet
L’absence de gouvernance claire (réunions de projet inexistantes, jalons non formalisés, décisions non documentées) prive les parties des preuves nécessaires pour établir les responsabilités en cas de litige.
Cette carence peut être le fait du prestataire (pilotage insuffisant) ou du client (exemples: défaut de désignation d’un chef de projet, défaut de validation des livrables dans les délais).
Responsabilité partagée : le cas des projets à échec bilatéral
Responsabilité dans un contentieux logiciel ERP : rupture imputable aux deux parties
Dans une affaire récente, la Cour d’appel a refusé de prononcer la résiliation aux torts exclusifs de l’intégrateur, relevant que la rupture des relations contractuelles était imputable aux deux parties qui n’avaient pas exécuté de bonne foi, pour des raisons propres à chacune d’elles. L’intégrateur avait imposé un démarrage prématuré et facturé des prestations non réalisées ; le client avait de son côté insuffisamment structuré sa collaboration.
Enseignement pratique : la stratégie contentieuse doit anticiper la question de la faute du client et documenter rigoureusement toutes ses contributions au projet.
Responsabilité dans un contentieux logiciel ERP : obligation de résultat, de moyens et devoir de conseil
La question de la responsabilité est le cœur des contentieux portant sur les projets ERP.
Elle se détermine en deux temps : d’abord qualifier les obligations de l’intégrateur (résultat? moyen renforcé?moyens ?), puis analyser les comportements respectifs des parties au regard de cette qualification.
L’obligation de résultat vs l’obligation de moyens: une distinction essentielle
La qualification des obligations d’un intégrateur dans le cadre d’un projet ERP est l’un des points les plus débattus en pratique devant les tribunaux.
Cette distinction conditionne directement la charge de la preuve et, partant, l’issue du litige.
| Obligation de résultat | Obligation de moyens |
|---|---|
| Le prestataire s’engage à délivrer un résultat précis défini contractuellement | Le prestataire s’engage à mettre en œuvre tous les efforts nécessaires |
| Preuve du manquement : il suffit de constater que le résultat n’est pas atteint | Preuve du manquement : il faut démontrer une faute précise du prestataire |
| Position favorable au client | Position favorable au prestataire |
| Souvent retenue pour les livrables précisément définis (recette, modules spécifiques) | Souvent retenue lorsque le périmètre est vague ou que l’environnement est incertain |
Le devoir de conseil de l’intégrateur : une obligation renforcée
Indépendamment de la qualification de son obligation principale, l’intégrateur est tenu d’un devoir de conseil renforcé à toutes les phases du projet : avant la contractualisation (audit des besoins, adéquation de la solution), pendant le projet (alerte sur les dérives, mise en garde sur les risques) et à la recette (vérification de la conformité aux spécifications avant livraison).
Ce devoir de conseil est fréquemment rappelé par les tribunaux et constitue un fondement autonome d’engagement de responsabilité.
La recette tacite : le piège le plus fréquent dans les litiges ERP
La recette tacite est le risque juridique le plus sous-estimé dans les projets ERP.
Elle intervient lorsqu’un client met le logiciel en production sans avoir formalisé de PV de recette, ou sans avoir émis de réserves écrites dans les délais contractuels.
Les tribunaux interprètent cette mise en production comme une acceptation implicite de la solution, ce qui fait courir les délais de garantie et rend très difficile l’invocation ultérieure de défauts de conformité.
Règle pratique absolue : ne jamais mettre en production sans procès-verbal de recette contradictoire
Même en présence de dysfonctionnements évidents, la mise en production doit être précédée d’un procès-verbal de recette avec réserves précisément formulées, transmis par écrit au prestataire. Un refus de recette verbal ne suffit pas, il doit être consigné par écrit, idéalement par lettre recommandée ou email avec accusé de lecture.
Si la mise en production a déjà eu lieu sans formalités : consultez un avocat pour évaluer si la recette tacite peut être contestée sur le fondement d’une erreur ou d’une contrainte imposée.
L’obligation de collaboration du client : un risque symétrique
La jurisprudence est constante : le client a une obligation de collaboration active tout au long du projet ERP.
Il doit notamment exprimer ses besoins avec précision, valider les livrables dans les délais contractuels, désigner des interlocuteurs compétents et disponibles et ne pas modifier le périmètre fonctionnel de façon intempestive.
Responsabilité du prestataire en cas de cyberattaque : la faute doit être prouvée
CA Bordeaux, 15 février 2023, n° 20/02883 – Résolution refusée malgré les défaillances du prestataire
La Cour d’appel de Bordeaux a refusé la résolution du contrat malgré les défaillances du prestataire, en raison du manquement du client à son obligation de collaboration : non-fourniture des éléments nécessaires dans les délais. Ce risque est systématiquement examiné par l’expert judiciaire et les tribunaux dans les litiges ERP.
Enseignement pratique : documenter toutes les contributions au projet (fournitures de données, validations, participation aux réunions) est aussi important que de relever les manquements du prestataire.
→ Source : article Quantic Avocats, novembre 2025
Clauses limitatives de responsabilité : comment les neutraliser ?
La quasi-totalité des contrats d’intégration ERP comportent des clauses plafonnant la responsabilité du prestataire (souvent à une fraction du prix du contrat).
Ces clauses peuvent dans certains cas être neutralisées sur le fondement de l’article 1170 du Code civil, qui répute non écrite toute clause privant de substance l’obligation essentielle du débiteur.
L’expertise judiciaire dans les litiges portant sur des logiciels ERP: un levier stratégique souvent incontournable
Dans la très grande majorité des contentieux ERP complexes, l’expertise judiciaire constitue une étape déterminante.
La technicité des systèmes, la volumétrie documentaire et la multiplicité des intervenants dépassent généralement ce qu’un juge peut apprécier seul.
L’expert désigné par le tribunal reconstituera le déroulement du projet, identifiera les anomalies et établira une cartographie des responsabilités sur laquelle les parties et le juge s’appuieront.
Le référé expertise dans le cadre d’un échec de projet ERP : sécuriser la preuve rapidement
Dès l’apparition des premières difficultés sérieuses, le référé expertise (article 145 du Code de procédure civile) permet d’obtenir la désignation d’un expert judiciaire avant tout procès au fond.
Cette procédure est particulièrement précieuse dans les projets ERP : les logs, les données de recette, les tickets et les configurations système sont des preuves volatiles qui peuvent disparaître ou être modifiées.
Une ordonnance de référé expertise peut être obtenue en quatre à huit semaines. Elle interrompt également le délai de prescription.
La formulation de la mission d’expertise
La mission confiée à l’expert conditionne directement la portée de ses conclusions.
Dans les litiges portant sur l’intégration d’ERP, elle doit couvrir notamment :
- L’analyse de conformité aux cahier des charges/spécifications (en fonction de la hiérarchie contractuelle),
- La reconstitution du déroulement du projet et de ses jalons,
- L’identification des causes des dysfonctionnements,
- La quantification des différents postes de préjudices et,
- Si plusieurs acteurs sont impliqués, la répartition des responsabilités techniques entre eux.
Avocat expertise judiciaire informatique – dires à expert, stratégie, conduite de la preuve
Référé article 145 CPC, formulation de la mission, rédaction des dires à expert, exploitation du rapport : notre cabinet vous accompagne à chaque étape de l’expertise judiciaire dans les litiges ERP.
Les enjeux financiers d’un contentieux ERP: postes de préjudice indemnisables
Les contentieux ERP présentent des enjeux financiers souvent considérables.
L’indemnisation allouée par un Tribunal peut couvrir plusieurs catégories de préjudices, à condition de les documenter avec précision dès le début de la procédure.
| Poste de préjudice | Exemples concrets | Pièces justificatives clés |
|---|---|---|
| Investissements directs perdus | Coûts du prestataire, licences sur le logiciel ERP de l’éditeur, serveurs, infrastructure | Factures, contrat, bons de commande |
| Coûts internes | Temps passé par la DSI, les chefs de projet, les utilisateurs métiers clés mobilisés | Tableaux de suivi, salaires, témoignages internes |
| Coûts de remédiation | Nouveau prestataire, migration, correctifs d’urgence | Devis, factures de remplacement |
| Pertes d’exploitation | Chiffre d’affaires non réalisé, production bloquée | Comptes de résultat, attestations clients |
| Coûts de replacement | Nouveau projet ERP, formation des équipes au nouvel outil | Devis, contrats, factures |
| Préjudice d’image | Perte de clients, dégradation réputation | Témoignages, données commerciales |
Les clauses limitatives : plafonds et contestation
Les contrats ERP plafonnent systématiquement la responsabilité du prestataire, souvent entre 50 % et 100 % du prix du contrat.
Ces plafonds sont la première ligne de défense du prestataire dans la négociation post-expertise.
Leur contestation repose sur l’article 1170 du Code civil : lorsque le plafond contractuel est si bas qu’il prive de substance l’obligation principale du prestataire, les tribunaux peuvent l’écarter et retenir la réparation intégrale du préjudice.
Notre méthodologie d’intervention dans les contentieux portant sur des projets ERP
Phase 1 : Audit contractuel et cartographie des responsabilités
Cette phase inclut notamment:
- L’analyse des contrats (licence, intégration, paramétrage, maintenance), des annexes techniques, des spécifications fonctionnelles et de la documentation projet.
- L’identification des obligations de chaque partie, des points de fragilité du dossier et des éléments de preuve disponibles.
- La définition d’une stratégie : négociation amiable, référé expertise, résiliation formelle ou action au fond.
Phase 2 : Mise en demeure et stratégie pré-contentieuse
Cette phase comprend souvent:
- La formalisation d’une mise en demeure motivée référençant les manquements contractuels de l’intégrateur/éditeur.
- Des échanges avec le conseil adverse en vue de l’ouverture d’une possible.
Une mise en demeure bien rédigée constitue la première pièce du dossier probatoire et positionne clairement les responsabilités.
Phase 3 : Saisine en référé et désignation de l’expert
Cette phase inclut notamment:
- La rédaction du projet de mission d’expertise si une solution transactionnelle n’a pu être trouvée;
- Une assignation en référé aux fins de désignation d’un expert judiciaire, la plaidoirie devant le juge des référés.
La formulation de la mission est un exercice stratégique : elle doit couvrir toutes les questions techniques utiles sans ouvrir de flancs inutiles à la partie adverse.
Phase 4 : Conduite de l’expertise et dires à expert
Cette phase inclut notamment:
- L’accompagnement à chaque réunion d’expertise,
- La coordination avec les équipes DSI et les experts techniques,
- La rédaction des dires à expert.
Cette phase est déterminante. Un dire bien construit peut corriger une conclusion défavorable de l’expert avant le dépôt du rapport définitif.
→ Pour le détail de cette phase : Avocat expertise judiciaire informatique
Phase 5 : Action au fond, transaction ou jugement
Cette phase comprends notamment:
- La rédaction des conclusions au fond intégrant le rapport d’expertise, l’audience de plaidoirie;
- L’exploitation du rapport d’expertise dans une possible négociation transactionnelle, qui intervient fréquemment après le dépôt du rapport et avant le jugement.
Si le rapport est défavorable sur certains points, la définition d’une argumentation juridique autonome peut permettre de nuancer ou de dépasser les conclusions de l’expert.
Les principaux types de litiges ERP que nous traitons
Les contentieux portant sur les projets ERP présentent des schémas récurrents liés à la complexité de ces projets : durée longue, multiplicité d’acteurs, technicité fonctionnelle, enjeux financiers significatifs.
Les principaux types de litiges ERP que nous traitons
Les contentieux portant sur les projets ERP (Enterprise Resource Planning) présentent des schémas récurrents liés à la complexité de ces projets : durée contractuelle longue, multiplicité d’acteurs (éditeur, intégrateur, infogérant), technicité fonctionnelle élevée, enjeux financiers significatifs atteignant fréquemment plusieurs centaines de milliers d’euros, voire plusieurs millions d’euros dans les projets structurants.
Voici trois exemples de contentieux ERP sur lesquelles nous accompagnons souvent les directions générales, directions juridiques et DSI des entreprises clientes confrontées à un projet défaillant.
| Projets ERP abandonnés ou interrompus | ERP livrés mais inexploitables : non-conformité aux spécifications et/ou cahier des charges | Contentieux multi-acteurs : éditeur, intégrateur, infogérant |
|---|---|---|
|
Situations typiques:
Notre intervention (exemples):
|
Situations typiques:
Notre intervention (exemples):
|
Situations typiques:
Notre intervention (exemples):
|
Les missions du cabinet en contentieux ERP couvrent l’analyse de la documentation contractuelle, l’accompagnement dans le cadre d’une expertise judiciaire (saisine du juge des référés, formulation de la mission, conduite des opérations, rédaction des dires à expert), la négociation d’une transaction et la représentation devant les tribunaux de commerce et cours d’appel. La nature, le volume et l’identité des dossiers traités ne peuvent être précisés en raison du secret professionnel auquel sont tenus les avocats.
Anticiper un litige portant sur un logiciel ERP: les points de vigilance contractuels
La majorité des litiges ERP que nous traitons auraient pu être évités ou considérablement limités par une meilleure rédaction contractuelle. → Avocat contrats informatiques – sécurisation et négociation
- Cahier des charges : il doit être le plus précis possible, validé par les deux parties et incorporé comme annexe contractuelle opposable
- Qualification explicite de l’obligation : résultat? Moyen renforcé? Moyen? à négocier notamment sur chaque livrable
- Jalons et pénalités de retard : mécanisme de pression efficace et outil de preuve en cas de litige
- Procédure de recette : modalités d’acceptation ou de refus, délais de réserve, procédures de correction obligatoires
- Clause de réversibilité : conditions de restitution des données et de migration vers un nouveau prestataire
- Plafond de responsabilité : à négocier à la hausse et à compléter par une exclusion des dommages indirects calibrée
- Documentation projet : imposer contractuellement la production de comptes rendus de réunion signés et de rapports d’avancement réguliers
Questions fréquentes sur le contentieux des logiciels ERP
Que faire si mon projet ERP ne fonctionne pas ou si l’intégrateur ne livre pas ?
Première règle : ne pas mettre en production le logiciel sans PV de recette contradictoire, même sous la pression du prestataire. Cela pourrait valoir recette tacite. Documentez immédiatement par écrit tous les dysfonctionnements constatés : tickets, emails, comptes rendus. Adressez une mise en demeure formalisée par recommandé identifiant précisément les manquements et fixant un délai de correction.
L’intégrateur est-il toujours responsable en cas d’échec d’un projet d’intégration d’ERP ?
Non. La responsabilité dépend des obligations contractuelles et des comportements respectifs des parties. L’intégrateur peut s’exonérer en démontrant que l’échec résulte du défaut de collaboration du client, de modifications incessantes du périmètre ou d’une expression du besoin insuffisante. Cependant, les tribunaux retiennent de plus en plus souvent que c’est à l’intégrateur qu’il revient de s’enquérir avec précision des besoins de son client.
Peut-on obtenir la résiliation du contrat portant sur l’intégration d’un ERP aux torts du prestataire ?
Oui, sous réserve d’établir l’inexécution suffisamment grave des obligations du prestataire (article 1224 du Code civil). Cette qualification est déterminante : elle conditionne le remboursement des sommes investies et l’ouverture du droit à indemnisation complète.
La résiliation peut être prononcée judiciairement ou, si le contrat le prévoit, notifiée unilatéralement après mise en demeure restée infructueuse.
Qu’est-ce que la recette tacite et comment l’éviter ?
La recette tacite intervient lorsqu’un client utilise ou met en production un logiciel ERP sans avoir formellement refusé la recette ou émis des réserves écrites dans les délais contractuels. Pour l’éviter : tout refus de recette ou toute réserve doit être formulé par écrit, de manière précise, et transmis au prestataire par email ou recommandé.
Faut-il une expertise judiciaire pour un litige ERP ?
Dans la grande majorité des contentieux ERP complexes, oui. L’expertise judiciaire permet d’objectiver les dysfonctionnements techniques, de reconstituer le déroulement du projet et d’établir une cartographie des responsabilités. Elle constitue aussi un levier de négociation puissant. De nombreux dossiers se règlent transactionnellement après le dépôt du rapport.
→ Avocat expertise judiciaire informatique.
Comment mettre en demeure l’intégrateur dans le cadre d’un projet ERP ?
La mise en demeure doit identifier précisément les manquements constatés en les référençant aux stipulations contractuelles violées (jalons, spécifications, niveaux de service), fixer un délai de régularisation raisonnable et être transmise par écrit. Rédigée par un avocat, elle constitue la première pièce structurante du dossier probatoire et positionne clairement les responsabilités pour la suite.
Quel est le délai de prescription pour agir en cas de litige ERP ?
Le délai de droit commun est de cinq ans à compter du jour où vous avez connu ou auriez dû connaître les manquements (article 2224 du Code civil). Ce délai peut être interrompu par une mise en demeure ou une assignation. Dans les projets longs, les premiers signaux d’alerte peuvent remonter à plusieurs années.
Combien coûte un contentieux portant sur l’intégration d’un logiciel ERP et quelle durée prévoir ?
Un référé expertise peut être obtenu en quatre à huit semaines. L’expertise judiciaire dure généralement entre un et deux ans selon la complexité. Une procédure au fond s’étend ensuite sur six à dix-huit mois. Une transaction après expertise peut intervenir en deux à six mois.
Peut-on agir contre l’éditeur du logiciel (SAP, Oracle, Sage, Microsoft) en plus de l’intégrateur ?
Oui, selon la structure contractuelle du projet. Lorsque le client a contracté directement avec l’éditeur pour les licences et avec un intégrateur pour le déploiement, les deux acteurs peuvent être mis en cause sur des fondements distincts : l’éditeur pour les défauts de la solution standard (le cas échéant), l’intégrateur pour les défauts de paramétrage et de déploiement. L’expertise judiciaire permet précisément de répartir les responsabilités techniques entre les différents acteurs.
Quantic Avocats : avocat contentieux logiciel ERP
Notre cabinet intervient exclusivement en droit informatique et numérique. Les litiges portant sur l’intégration de logiciels ERP figurent parmi les contentieux les plus fréquemment traités, avec une pratique couvrant aussi bien les projets SAP, Oracle, Sage que les solutions sectorielles ou développées sur mesure.
Le Cabinet est membre de l’AFDIT, et a assuré la co-présidence de la Commission droit du numérique de l’ACE. Nous intervenons dans toute la France.
Sur le même thème : nos pages dédiées
- Avocat contentieux informatique: vue d’ensemble des litiges IT
- Avocat expertise judiciaire informatique: dires à expert et stratégie
- Avocat litige SaaS: indisponibilité, SLA et sortie de contrat
- Avocat contrats informatiques: sécurisation et négociation
Paris : 01 86 95 84 61 · Bordeaux : 05 56 24 43 85
Nos autres domaines d’expertise