Le projet devait durer neuf mois. Deux ans plus tard, l’ERP n’est toujours pas en production, la facture a doublé, vos équipes sont épuisées et le prestataire vous réclame le solde en menaçant de couper l’accès. Vous êtes DG ou DAF, vous avez déjà signé des centaines de milliers d’euros de bons de commande, et vous vous demandez comment sortir de là sans perdre à la fois l’argent, le temps et vos données.
La première chose à comprendre est contre-intuitive : un projet informatique qui échoue n’est presque jamais gagné ou perdu sur la qualité du code. Il se gagne sur les pièces. Les procès-verbaux de recette, les comptes rendus de comité de pilotage, les mails où vous signalez un blocage, les réserves écrites : voilà ce qui décide de l’issue. Le meilleur expert judiciaire du monde ne rattrapera jamais un dossier vide. Un projet raté est d’abord un problème de preuve.
Tout se joue sur la qualification du contrat
Avant de parler de responsabilité, il faut savoir ce que le prestataire vous devait exactement. La réponse dépend de deux distinctions qui commandent toute la suite : obligation de résultat ou de moyens, et marché au forfait ou en régie.
Le prestataire vous devait-il un résultat ou seulement des moyens ?
Tout dépend de la qualification retenue, car elle commande la charge de la preuve. Sous une obligation de résultat, il vous suffit de constater que l’ERP ne fonctionne pas : la faute du prestataire est présumée. Sous une obligation de moyens, c’est à vous de démontrer sa négligence. L’intégrateur professionnel se voit souvent imposer une obligation de moyens renforcée, position intermédiaire qui rééquilibre la preuve en votre faveur.
L’enjeu pratique est là. Débiteur d’un résultat, le prestataire ne se libère qu’en prouvant une cause étrangère — force majeure, fait d’un tiers, ou votre propre faute. Débiteur de moyens seulement, il vous laisse la tâche, bien plus lourde, de démontrer qu’il n’a pas déployé les diligences qu’un professionnel avisé aurait mises en œuvre.
La ligne de partage n’est pas figée. Les juridictions retiennent fréquemment, à la charge de l’intégrateur professionnel, une obligation de moyens dite renforcée : le client n’a pas à prouver précisément la faute technique, mais le prestataire doit démontrer qu’il a tout fait correctement. La Cour de cassation a validé cette qualification à propos d’un progiciel de gestion, jugeant que le fournisseur professionnel était débiteur, à l’égard de sa cliente, d’une obligation de moyens renforcée, d’abord de conseil initial sur le choix de la solution (chambre commerciale, 10 janvier 2018, n° 16-23.790). Sur les obligations ponctuelles à résultat vérifiable — la livraison d’une version précise à une date convenue —, la qualification bascule volontiers vers l’obligation de résultat.
Le réflexe utile : relisez vos documents contractuels avant tout. Un engagement de livrer « une version opérationnelle au 30 septembre » est une obligation de résultat qui ne se discute pas. Une clause qui promet « les meilleurs efforts » ou « une assistance à la mise en œuvre » tire vers le moyen. Les prestataires soignent cette rédaction ; c’est là qu’il faut chercher.
Forfait ou régie : lequel vous protège, et lequel a fait exploser le budget ?
Le forfait vous protège, la régie protège le prestataire. C’est la seconde distinction qui commande la charge de preuve. Au forfait, le prestataire s’engage sur un livrable global à prix fixe : dépassements à sa charge, exposition accrue à l’obligation de résultat. En régie, vous achetez des jours-hommes, vous pilotez, vous payez le temps passé quel que soit le résultat : l’échec global n’a alors aucun responsable contractuel désigné.
Une réserve pèse toutefois sur le forfait : il ne protège vraiment que si le périmètre a été correctement défini au départ. La régie, elle — l’assistance technique —, ne charge le prestataire que de moyens ; c’est le terrain sur lequel les budgets explosent sans que personne ne soit contractuellement responsable de l’échec global.
Beaucoup de projets sinistrés cumulent les deux : un forfait de cadrage, puis une bascule en régie « pour absorber les évolutions ». Cette bascule est souvent le moment où le prestataire s’est déchargé du risque sans que le client ne le réalise. Vérifiez comment et quand elle a eu lieu : elle pèsera lourd sur la répartition des responsabilités.
Les obligations de chacun, et le piège du besoin mal exprimé
Un projet informatique est un contrat à obligations réciproques. Le prestataire n’est pas seul en cause, et le client qui l’ignore se fait piéger.
Le prestataire a-t-il manqué à son devoir de conseil ?
Il y a manqué s’il ne vous a pas alerté sur un risque qu’il connaissait et que vous ne pouviez pas mesurer seul. Au-delà de la prestation technique, l’intégrateur professionnel est tenu d’un devoir de conseil et de mise en garde : adéquation de la solution, contraintes techniques, dangers du calendrier. Face à un client sans compétence informatique propre, cette obligation est renforcée — et c’est à lui de prouver qu’il l’a exécutée.
Le prestataire ne peut pas se retrancher derrière votre silence si vous n’aviez pas les moyens de mesurer un danger que lui connaissait. C’est un angle décisif. Le prestataire qui laisse un module inopérant pendant deux ans sans vous alerter, qui vous laisse acheter des licences inadaptées, qui ne vous dit pas que le calendrier était intenable, manque à son devoir de conseil — même si vous avez, de votre côté, mal collaboré.
Ce que le prestataire vous opposera : votre défaut de collaboration
Sa défense favorite tient en une phrase : « le projet a échoué parce que le client n’a jamais su ce qu’il voulait. » Le client est en effet tenu d’une obligation de collaboration que la jurisprudence impose à tout contrat informatique, stipulée ou non. Un besoin resté oral, un cahier des charges absent, des évolutions non tracées : autant d’armes que vous lui tendez. La riposte se prépare avant le litige, par l’écrit.
Concrètement, cette obligation vous impose de fournir les informations utiles, d’exprimer vos besoins, de désigner des interlocuteurs, de valider les livrables et de tester. Un client passif, qui n’exprime pas clairement ses besoins et ne réagit pas aux difficultés, engage sa propre responsabilité. Et parfois le prestataire a raison de le lui reprocher. Dans l’affaire du progiciel de gestion évoquée plus haut, la Cour de cassation a validé un partage de responsabilité par moitié : le fournisseur avait manqué à son obligation de conseil en laissant un module en attente sans alerter, mais la cliente avait manqué à son obligation de collaboration en n’exprimant pas clairement ses besoins spécifiques et en résistant à faire évoluer son processus (chambre commerciale, 10 janvier 2018, n° 16-23.790). Résultat : les préjudices divisés par deux.
La leçon pratique est brutale. L’absence de cahier des charges détaillé, l’expression de besoins restée orale, les évolutions de périmètre demandées en cours de route sans les tracer : tout cela se retourne contre vous. À l’inverse, un cahier des charges écrit et des besoins formalisés déplacent la responsabilité vers le prestataire, à qui il appartient alors d’exécuter ou d’alerter. Ce qui compte, encore une fois, ce n’est pas ce qui s’est dit en réunion — c’est ce qui a été écrit.
La preuve de l’échec : ce qu’il faut écrire, et ce qu’il ne faut jamais signer
Vous ne prouverez pas l’échec par le ressenti de vos équipes. Vous le prouverez par des documents datés. Le contentieux se prépare pendant le projet, pas après.
Les pièces qui gagnent le dossier
Quatre catégories de pièces décident de l’issue :
- Les procès-verbaux de recette et leurs réserves. La recette est l’acte par lequel vous acceptez — ou non — les livrables. Une recette signée sans réserve vaut reconnaissance de conformité et referme presque tout le contentieux. Une recette assortie de réserves écrites, précises et datées, conserve vos droits.
- Les comptes rendus de comité de pilotage. Ce sont eux qui matérialisent, réunion après réunion, les retards, les blocages, les alertes. Un comité de pilotage où vous signalez formellement un dysfonctionnement est une pièce à charge redoutable. Encore faut-il que le compte rendu le mentionne : relisez-les avant de les valider.
- Les mails de signalement. Chaque anomalie signalée par écrit, chaque relance sur un retard, chaque demande restée sans réponse construit la chronologie de la défaillance.
- Les pénalités de retard. Si le contrat en prévoit, leur application — ou au moins leur réclamation écrite — matérialise le manquement et chiffre une partie du préjudice.
La règle d’or : ne jamais signer une recette de complaisance
Voici l’erreur qui coûte le plus cher, et personne ne vous en avertit. Sous la pression du calendrier, pour « débloquer » une facture ou parce que le prestataire promet de corriger « juste après », des directions signent un procès-verbal de recette alors que le système ne fonctionne pas. C’est un désastre probatoire. Cette signature vous sera opposée comme une acceptation, et vos réclamations ultérieures apparaîtront comme des regrets tardifs.
Si vous devez avancer malgré des défauts, ne signez jamais une recette « pure ». Signez une recette avec réserves : listez précisément, par écrit, chaque anomalie non corrigée, chaque fonctionnalité manquante, chaque test non concluant. Une réserve écrite vaut mieux que dix mails de plainte après coup.
Le piège avant de cesser de payer : réservez d’abord, arrêtez ensuite
Le premier réflexe d’un DAF excédé, c’est de bloquer les paiements. C’est légitime, mais mal exécuté, ce geste vous transforme en débiteur défaillant — et le prestataire retourne alors le procès contre vous.
Le mécanisme existe : l’exception d’inexécution vous autorise à suspendre votre propre obligation (payer) si l’autre partie n’exécute pas la sienne et si cette inexécution est suffisamment grave (article 1219 du code civil). Le mot « suffisamment grave » est tout le sujet. Si le juge estime, plus tard, que les manquements ne justifiaient pas la suspension, c’est vous qui aurez commis la faute contractuelle.
D’où le réflexe de praticien qui change tout : n’arrêtez jamais de payer sans avoir d’abord constitué le dossier de réserves qui le justifie. Concrètement, une lettre recommandée qui énumère précisément les manquements, met en demeure d’y remédier sous un délai, et annonce la suspension des paiements à ce titre, doit précéder le blocage — jamais le suivre. Cesser de payer d’abord et documenter ensuite, c’est offrir au prestataire l’argument qu’il cherche : que le vrai défaillant, c’est vous. La lettre de réserves précède le blocage, jamais l’inverse.
Résolution, résiliation, torts partagés : et le sort des sommes versées
Quand le projet est irrécupérable, il faut y mettre fin. Le droit offre plusieurs voies, aux conséquences très différentes sur l’argent déjà payé.
Les trois portes de sortie
La résolution du contrat peut résulter de trois mécanismes (article 1224 du code civil) :
- La clause résolutoire, si le contrat en contient une : elle joue de plein droit, généralement après une mise en demeure restée sans effet, selon les conditions qu’elle fixe. C’est la voie la plus rapide, mais elle suppose de respecter scrupuleusement le formalisme de la clause.
- La résolution par notification, en cas d’inexécution suffisamment grave : vous notifiez la fin du contrat à vos risques, à charge pour le juge de contrôler ensuite la gravité. Rapide mais risqué.
- La résolution judiciaire : vous saisissez le tribunal, qui apprécie la gravité et prononce — ou non — la fin du contrat aux torts du prestataire.
Dans un dossier informatique, la clause résolutoire mal actionnée est un piège classique : un formalisme non respecté, et la résiliation se retourne à vos torts. Les conditions exactes de chaque voie, et notamment comment résilier sans mise en demeure quand le contrat l’autorise, dictent le formalisme à respecter.
Allez-vous récupérer les sommes déjà versées ?
Oui, si le projet formait un tout indivisible. La résolution met fin au contrat, mais le sort des sommes payées dépend de la nature des prestations (article 1229 du code civil). Quand les prestations ne valaient que par l’exécution complète — un ERP livré à moitié ne sert à rien —, la restitution est intégrale : vous récupérez tout. Quand elles ont été utiles au fil de l’eau, il n’y a pas de restitution pour le passé.
C’est la question qui intéresse vraiment un DAF, et elle est purement financière. Dans le premier cas — prestations utiles seulement par l’exécution complète —, la restitution est réciproque : vous récupérez les sommes versées et vous rendez les livrables. C’est le scénario favorable au projet global qui a échoué, puisqu’un système à moitié déployé n’a par hypothèse aucune utilité isolée. Dans le second — prestations utiles au fur et à mesure, telle une maintenance mensuelle effectivement rendue —, pas de restitution pour le passé : on parle de résiliation, qui ne vaut que pour l’avenir. Plaider que le projet formait un tout indivisible, dont aucune brique isolée n’avait de valeur, c’est plaider la restitution intégrale de ce que vous avez payé.
Les torts partagés, et pourquoi ils ne sont pas une défaite
Rares sont les échecs de projet informatique où un seul camp est fautif. Le plus souvent, le juge répartit les responsabilités. Un partage à 50/50, comme dans l’affaire du progiciel de gestion citée plus haut, n’est pas un échec : c’est la moitié de votre préjudice indemnisée, et surtout la restitution qui peut suivre la résolution. Aborder le dossier en acceptant qu’une part de responsabilité vous incombe, c’est se donner les moyens de négocier depuis une position réaliste — et solide.
Le préjudice indemnisable, et le mur des clauses limitatives de responsabilité
Vous avez perdu bien plus que le prix du contrat. La question est de savoir ce que le droit vous laisse récupérer.
Ce que vous pouvez réclamer
La réparation doit être intégrale. Les postes classiques d’un échec de projet :
- Les coûts internes : le temps de vos équipes mobilisées en pure perte, les jours de formation à un outil qui ne fonctionnera jamais, la désorganisation.
- Les licences et matériels perdus : ce que vous avez acheté pour un système mort-né.
- Le coût du projet de remplacement : le surcoût de la solution de substitution que vous devez déployer en urgence.
- Les gains manqués : les économies et gains de productivité attendus du nouvel outil, dont vous avez été privé.
Attention à une règle qui piège les demandeurs : le manque à gagner tiré de la bonne exécution du contrat ne se cumule pas avec le remboursement des sommes versées obtenu par la résolution. On ne peut pas à la fois faire comme si le contrat n’avait jamais existé (restitution) et réclamer les bénéfices qu’il aurait produits s’il avait été exécuté. Il faut choisir la construction indemnitaire la plus favorable, pas les empiler.
Comment faire tomber la clause qui plafonne votre indemnisation ?
Par trois brèches, et trois seulement. Ces clauses, valables en principe entre professionnels, plafonnent l’indemnité et excluent les dommages « indirects » — vos gains manqués. On les écarte en démontrant, soit que le plafond prive de sa substance l’obligation essentielle (article 1170 du code civil), soit une faute lourde déduite de la gravité du comportement, soit un dol. C’est là que se joue l’essentiel du montant final.
Ces clauses sont, on l’a dit, valables en principe entre professionnels — et le plafond retenu, souvent le montant payé, laisse hors réparation les gains manqués qui font le gros du préjudice. Reste à ouvrir l’une des trois brèches.
La première : la clause qui prive de sa substance l’obligation essentielle du débiteur est réputée non écrite (article 1170 du code civil). C’est l’héritage de la jurisprudence Chronopost (chambre commerciale, 22 octobre 1996, n° 93-18.632), puis de la saga Faurecia. Mais attention à la portée réelle : dans son arrêt final, la Cour de cassation a jugé que seule est réputée non écrite la clause limitative qui contredit la portée de l’obligation essentielle — un plafond qui n’est pas dérisoire et qui reflète l’économie négociée du contrat reste valable, même si le prestataire a manqué à une obligation essentielle (chambre commerciale, 29 juin 2010, n° 09-11.841). Autrement dit, il ne suffit pas d’invoquer un manquement grave : il faut démontrer que le plafond vide l’engagement de toute portée.
La seconde : la faute lourde. Elle fait tomber la clause. Mais la même affaire Faurecia a posé une exigence stricte : la faute lourde ne peut résulter du seul manquement à une obligation contractuelle, fût-elle essentielle ; elle doit se déduire de la gravité du comportement du débiteur. Un prestataire qui accumule les manquements, qui dissimule, qui persiste malgré les alertes, se rapproche de la faute lourde. Un prestataire qui a échoué en dépit de ses efforts, non.
La troisième, plus radicale : le dol, c’est-à-dire la tromperie, qui écarte toute limitation.
La stratégie qui gagne consiste donc rarement à démolir la clause de front. Elle consiste à documenter le comportement du prestataire — les alertes ignorées, les dissimulations, les fausses promesses de livraison — pour construire soit la faute lourde, soit la démonstration que le plafond vide l’obligation de sa substance. C’est un travail de pièces, encore et toujours.
SaaS : quand le prestataire coupe l’accès à vos données
Le contentieux SaaS a une arme que le contentieux ERP classique ignore : vos données sont hébergées chez le prestataire. Quand le conflit éclate, il peut suspendre l’accès. Du jour au lendemain, votre facturation, votre CRM, votre comptabilité deviennent inaccessibles — et vous êtes sommé de payer pour les récupérer.
La réversibilité, à vérifier avant même le litige
La réversibilité est la clause qui organise, en fin de contrat, la restitution de vos données dans un format exploitable et l’accompagnement de la migration. Un bon contrat SaaS la détaille : format des exports, délais, assistance, coût. Un mauvais contrat reste flou — et le flou profite à celui qui détient les données.
Sortez cette clause du contrat maintenant, avant tout conflit. Elle détermine votre marge de manœuvre le jour où la relation se dégrade. Sans clause de réversibilité claire, la restitution devient un rapport de force.
Comment récupérer vos données quand le prestataire coupe l’accès ?
Par un référé, sans attendre le procès au fond. Vos données vous appartiennent : le prestataire les héberge, il n’en devient pas propriétaire. Leur rétention pour vous forcer à payer un montant contesté caractérise un trouble manifestement illicite ou un dommage imminent, les deux fondements du référé. En quelques semaines, le juge peut ordonner la restitution sous astreinte — et vous rendre votre exploitation.
Le référé est souvent l’action la plus efficace du dossier : au-delà de l’exploitation restaurée, il renverse le rapport de force dans la négociation globale. Le prestataire qui espérait vous étrangler perd son levier.
La difficulté est probatoire : il faut démontrer que les données sont bien les vôtres, que leur rétention est injustifiée, et que l’urgence est réelle. D’où l’importance, là encore, d’avoir conservé les traces contractuelles de ce qui a été déposé sur la plateforme.
L’expertise judiciaire informatique, quasi inévitable
Dans presque tout litige de projet informatique sérieux, un expert judiciaire sera désigné. Le juge n’a pas les compétences techniques pour trancher seul entre « le code était défaillant » et « le client n’a jamais su ce qu’il voulait ». L’expert reconstitue la chronologie, examine les livrables, identifie les causes de l’échec et propose une répartition des responsabilités.
Cette expertise se demande souvent en amont, par un référé destiné à faire constater l’état du système et à conserver les preuves avant qu’elles ne disparaissent — une mesure d’instruction in futurum obtenue avant tout procès au fond.
Modèle de requête aux fins d’adoption d’une mesure d’instruction in futurum (article 145)
Le rapport d’expertise oriente presque toujours l’issue : les magistrats le suivent dans la très grande majorité des cas. D’où l’enjeu de cadrer la mission de l’expert dès sa désignation — les questions posées à l’expert délimitent ce qu’il pourra constater — et de participer activement aux opérations : produire les pièces au bon moment, contester les affirmations adverses, faire acter vos dires. Un expert n’invente rien ; il travaille sur ce que les parties lui donnent. Le rapport d’expertise qui vous est défavorable est souvent celui que vous avez laissé se construire sans réagir. Et si le rapport est vicié par un manquement de l’expert, il existe des voies pour engager sa responsabilité.
Pourquoi ces dossiers finissent presque tous par un protocole
La grande majorité des litiges de projet informatique se règlent par une transaction, pas par un jugement. La raison est structurelle : les torts sont généralement partagés, l’aléa judiciaire est fort, l’expertise coûte cher et dure des mois, et aucune des deux parties ne veut prendre le risque d’un procès long au résultat incertain. Le prestataire redoute la condamnation et l’atteinte à sa réputation ; le client veut récupérer son argent et ses données sans immobiliser ses équipes pendant trois ans.
Négocier en position de force suppose deux choses. D’abord, un dossier de preuves solide : c’est lui qui fixe le curseur de la transaction, bien plus que les arguments juridiques. Un client qui aligne les PV de recette avec réserves, les comptes rendus de comité de pilotage et une expertise favorable négocie autrement qu’un client au dossier vide. Ensuite, des leviers procéduraux crédibles : le référé données, la menace d’une résolution avec restitution intégrale, une saisie conservatoire pour geler une créance. Beaucoup de contrats imposent d’ailleurs une conciliation préalable avant tout procès — un passage obligé qu’il vaut mieux aborder préparé qu’improvisé.
La transaction n’est pas un renoncement. C’est souvent la meilleure issue économique — à condition de la négocier depuis une position construite, et non subie.
Ce que la règle ne dit pas
Tout ce qui précède décrit le droit. Mais l’issue de votre dossier ne dépendra pas seulement du droit : elle dépendra de vos pièces, de la chronologie exacte de ce qui a été écrit et signé, de la qualification précise de votre contrat, et de la manière dont vous engagez les premiers actes — la lettre de réserves, le blocage des paiements, la demande d’expertise. Une erreur de séquence, une recette signée de trop, un mail maladroit peuvent coûter très cher. Les faits comptent autant que le droit, et c’est précisément là qu’intervient l’avocat.
Valentin Simonnet est avocat au Barreau de Paris. Il intervient en contentieux des affaires et en droit pénal des affaires.
