Que vous soyez prestataire IT ou client acheteur de solutions numériques, il est essentiel de pouvoir décrypter l’état de la jurisprudence pour adapter vos pratiques contractuelles. Vous trouverez ci-dessous les principaux enseignements à tirer de l’année judiciaire écoulée en matière de projets digitaux.

 

Les 6 enseignements clés à retenir

• Le devoir de conseil du prestataire informatique est étendu et renforcé, en particulier en phase précontractuelle, avec une exigence accrue d’analyse des besoins, de faisabilité et de compatibilité des solutions.
•  La résiliation anticipée par le client n’est légitime que s’il a respecté ses propres obligations, notamment son devoir de collaboration et le paiement des prestations.
• Les juges tendent à qualifier de plus en plus les obligations des prestataires IT en obligations de moyens (voire de moyens renforcée) plutôt qu’en obligations de résultat, en raison de la complexité technique des projets et de la nécessaire collaboration du client. La qualification contractuelle reste possible, mais elle doit être cohérente avec la réalité technique des prestations.
• La conformité au RGPD est désormais appréhendée comme une obligation contractuelle dont la violation peut justifier la résolution du contrat.
• La signature d’un procès-verbal de recette ne libère pas le prestataire de son obligation de délivrance et n’empêche pas le client d’invoquer des dysfonctionnements ultérieurs.
• La sécurisation de la sortie du contrat est déterminante, les résiliations prématurées ou mal préparées, ainsi que les clauses limitatives de responsabilité ou d’indemnité de sortie excessives, étant strictement contrôlées par le juge.

 

Enseignement n°1 : le devoir de conseil du prestataire est de plus en plus vaste et exigeant

1. Renforcement de l’obligation précontractuelle d’information

Quelques décisions ont été rendues en 2025 illustrant la sévérité des tribunaux à l’égard des fournisseurs lorsqu’il s’agit de vérifier s’ils ont délivré au client informations et conseils.

Ainsi, dans son arrêt du 28 mai 2025 (RG n°21/08394), la Cour d’appel de Lyon a jugé, à propos d’un projet d’intégration d’un ERP, que le prestataire avait « manqué à son devoir précontractuel de conseil en ne s’informant pas suffisamment des attentes de sa cliente et en lui fournissant un produit qui ne correspondait pas à celles-ci ». L’arrêt relève en outre « qu’en sa qualité de professionnel, il lui appartenait de vérifier l’adéquation de son produit aux besoins du client avant la signature du contrat et non une fois le progiciel installé ».

L’arrêt est intéressant au regard des conséquences – lourdes – du manquement par le prestataire à son devoir précontractuel d’information, la Cour retenant qu’une telle défaillance a « entraîné l’erreur de la [cliente] sur les qualités essentielles du produit informatique, constitutive d’un vice du consentement (…) la nullité du contrat est encourue, laquelle entraîne les restitutions réciproques ».

Dans son arrêt du 24 avril 2025 (RG n°20/12936), la Cour d’appel d’Aix-en-Provence a jugé, à propos d’un prestataire chargé du développement d’un logiciel spécifique, « qu’il lui appartenait, avant de s’engager, d’étudier la faisabilité de sa mission et des prestations qu’[il] offrait », en s’assurant notamment de la compatibilité de sa solution avec les logiciels existants.

Enfin, dans son arrêt du 5 juin 2025 (RG n°24/00139), la Cour d’appel de Rouen a reproché au prestataire de ne pas avoir réalisé « l’étude des prérequis » et exigé de ce dernier, « avant de proposer sa solution informatique » qu’il « établi[sse] quels étaient les besoins effectifs [du client] ».

Conseil pratique 

Ces décisions montrent que l’on attend toujours plus du fournisseur, qui doit procéder – avant la signature du contrat et non une fois le progiciel installé – aux vérifications préalables et identifier les potentiels problèmes de compatibilité de son outil avec ceux en place chez le client. Procéder à un audit préalable du SI du client et réaliser une démonstration de sa solution avant de signer le contrat apparaissent comme autant de bonnes pratiques pour le prestataire.

 

2. Précisions sur les contours de l’information précontractuelle

Dans son arrêt du 14 mai 2025 (n°23-17.948), la Cour de cassation a livré son interprétation restrictive de l’article 1112-1 du Code civil relatif au devoir d’information précontractuelle, énonçant qu’« il résulte de l’article 1112-1 que le devoir d’information précontractuelle ne porte que sur les informations qui ont un lien direct et nécessaire avec le contenu du contrat ou la qualité des parties, et dont l’importance est déterminante pour le consentement de l’autre partie ». Pour qu’une information entre dans le champ du devoir précontractuel, elle doit à la fois avoir un lien direct et nécessaire avec le contenu du contrat ou la qualité des parties et revêtir une importance déterminante. Ce faisant, la solution pose une exigence de double preuve, le lien direct et nécessaire et le caractère déterminant de l’information étant deux choses distinctes.

Conseil pratique 

La question probatoire devrait être le terrain de vives discussions, ce qui doit inciter les parties à formaliser leurs négociations précontractuelles (lettre d’intention, promesse, échange de mails, etc.) et à soigneusement conserver l’historique de l’ensemble des points soulevés en phase précontractuelle.

 

 

Enseignement n°2 : la résiliation anticipée par le client reste conditionnée au respect par le client de ses propres obligations

1. Résiliation injustifiée en cas de manquement par le client à son devoir de collaboration

Par arrêt du 13 mars 2025 (RG n°21/08684), la Cour d’appel de Lyon a rappelé qu’un client qui méconnaît son obligation de collaboration aura toutes les difficultés à reprocher un manquement au prestataire. La Cour a ainsi débouté l’acquéreur d’une solution informatique qui se plaignait d’une incompatibilité du progiciel acquis avec ses matériels et d’une inadéquation avec ses besoins, car il avait lui-même manqué à son devoir de collaboration en refusant notamment de valider les interventions sur sites, d’installer un module du logiciel et de créer son compte sur la solution en question, ce qui a entravé le bon déroulement du projet.

Conseil pratique

Un client mécontent de la solution livrée et qui décide de mettre fin au contrat passé avec son prestataire doit s’assurer au préalable qu’il a lui-même respecté son obligation de collaboration (en procédant aux validations et retours, en fournissant les informations nécessaires pour que le prestataire puisse mener à bien sa mission, etc.). A défaut, il risque d’être mal fondé à opposer l’exception d’inexécution à son prestataire pour justifier la résiliation anticipée.

2. La suspension par le client du règlement des factures dues peut se retourner contre lui

Dans cette affaire, l’acquéreur d’un ERP déplorait l’incapacité de son prestataire à délivrer une solution logicielle complète, dans les délais convenus. Le client a donc notifié sa volonté de résilier le contrat, ce que le prestataire a contesté. L’affaire a été portée devant la Cour d’appel de Paris qui, par arrêt du 28 mars 2025 (RG n°22/17649), a jugé que le prestataire avait satisfait à son obligation de moyens et que, face au décalage important du règlement par le client de l’acompte puis de ses propres prestations, il avait dû décaler ses interventions. En refusant de régler les factures, le client a manqué à son obligation de collaboration, ce qui a impacté le bon déroulement du projet et a obéré les griefs qu’il opposait à son prestataire. C’est donc aux torts exclusifs du client que le contrat a été résilié.

Conseil pratique 

Dans le cadre de sa stratégie (pré)-contentieuse, un client mécontent de la qualité des prestations fournies devrait prendre le temps de la réflexion avant de suspendre le paiement des factures, une telle décision pouvant fragiliser sa position, voire se retourner contre lui.

 

3. Le refus par le client de régulariser un contrat de maintenance peut caractériser un comportement fautif de sa part

Dans cette affaire (CA Paris, 21 mars 2025, RG n°22/17566), un client se plaignant de dysfonctionnements des sites développés et livrés par son prestataire s’est vu reproché d’avoir refusé de régulariser un contrat de maintenance, ce qui lui aurait permis de corriger les défaillances dont il se prévalait. La Cour a relevé que la phase de « garantie post-production (…) de deux mois » prévue au contrat était expirée et que les corrections apportées aux anomalies avaient donc été réalisées en dehors de tout cadre contractuel. La Cour a ensuite jugé qu’en refusant de signer un contrat maintenance, le client a « privé son prestataire de la possibilité d’intervenir dans ce cadre pour remédier aux « bugs » divers qui pouvaient être relevés », ce qui l’a conduit à écarter toute responsabilité du prestataire au titre des perturbations rencontrées.

Conseil pratique

Les parties à un projet informatique ont tout intérêt à bien identifier ls prestations réalisées par le fournisseur au titre de la garantie post-production et celles couvertes par la maintenance à proprement parler, ces dernières nécessitant en principe la signature d’un contrat séparé. La prudence doit d’autant plus être de mise que le refus du client de mettre en place une tierce maintenance applicative peut s’analyser comme un manquement à son devoir général de loyauté contractuelle et obérer les griefs qu’ils pourraient opposer à son prestataire.

 

 

Enseignement n°3 : qualification des obligations du prestataire : vers une tendance à moins de « résultat » et plus de « moyens renforcée » ?

 

1. Qualification de l’obligation du prestataire en obligation de moyens

Dans un arrêt du 3 octobre 2025 (RG n°22/01534), la Cour d’appel de Paris a eu à se prononcer sur la nature de l’obligation du prestataire. Après avoir écarté la qualification prévue au cahier des charges, celui-ci n’étant ni signé, ni même visé au contrat, la Cour a ensuite relevé qu’« en raison de la complexité des opérations d’intégration des applications (…) la fourniture de ces prestations n’est pas présumée régie par une obligation de résultat mais par une obligation de moyens, sauf convention expresse entre les parties ». L’obligation de résultat est donc écartée.

La Cour d’appel de Colmar avait déjà, dans son arrêt du 15 janvier 2025 (RG n°23/02423), rappelé que « dans le cadre de l’installation d’un logiciel informatique, dès lors que l’obligation de délivrance du tiers suppose une collaboration active du client, il en résulte un aléa exclusif de la qualification d’obligation de résultat ». Les juges semblent donc tenir compte de la technicité des projets IT pour qualifier les obligations du prestataire.

Conseil pratique

Les parties ont la faculté de prévoir dans leur contrat la nature des engagements du prestataire, mais encore faut-il que la qualification retenue corresponde à la réalité technique de l’opération dans son ensemble et qu’elle ne contredise pas la portée de l’obligation essentielle du prestataire. Les rédacteurs et négociateurs doivent donc tenir compte du contexte et de leur participation respective à la réalisation des prestations concernées.

 

2. L’émergence de l’obligation de moyens renforcée

La qualification en obligation de moyens renforcée semble de plus en plus retenue par les Tribunaux.

Ainsi, dans son arrêt du 5 juin 2025 (RG n°24/00139), la Cour d’appel de Rouen a jugé qu’« eu égard à la complexité des prestations fournies dans un domaine particulièrement technique, le prestataire informatique est débiteur d’une obligation de conseil renforcée lorsque le client est peu expérimenté ». Et l’arrêt de préciser que « cette obligation, dont il lui appartient de démontrer qu’il y a satisfait, lui impose de rechercher les besoins réels de son client et il ne saurait contractuellement s’en dispenser ».

Dans une autre espèce, le Tribunal judiciaire de Mulhouse (27 mars 2025, RG n°22/00825) a retenu, à propos d’un « travail spécifique comportant une prestation intellectuelle » la qualification d’« obligation de moyen renforcée ». Cette qualification apparaît adaptée à la réalité des projets informatiques : en effet, il est a priori plus facile pour le fournisseur de démontrer qu’il n’a commis aucune faute dans l’exécution de ses obligations, plutôt que de faire peser sur le client non sachant la preuve que son prestataire n’a pas mis en œuvre les moyens promis.

 

 

Enseignement n°4 : Une non-conformité au RGPD peut caractériser un manquement contractuel justifiant la résolution du contrat

Par deux arrêts rendus le 13 mai (RG n°23/02044) puis le 11 juin 2025 (RG n°23/02206), la Cour d’appel de Bordeaux a prononcé la résolution d’un contrat, non pas sur le fondement classique d’une inexécution contractuelle mais sur celui d’une non-conformité au RGPD du site livré (en l’occurrence l’absence de bandeau de consentement pour les cookies de mesure d’audience et l’utilisation d’un reCaptcha collectant des données sans information préalable). La solution est suffisamment rare pour être signalée.

Conseil pratique

Cette solution, parce qu’elle érige la conformité au RGPD au rang d’obligation contractuelle dont la violation peut justifier l’anéantissement d’un contrat, devrait inciter les fournisseurs de solutions IT encore récalcitrants, à ne pas négliger la réglementation relative aux données personnelles dans le cadre des prestations qu’ils fournissent à leurs clients.

 

 

Enseignement n°5 : Portée relative de la signature d’un PV de recette

Une décision de la Cour d’appel de Versailles du 5 mars 2025 (RG n°23/01412) a confirmé la tendance jurisprudentielle – initiée en 2023 – selon laquelle la signature d’un PV de recette ne décharge pas le prestataire de son obligation de délivrance, laquelle n’est considérée comme pleinement exécutée qu’après mise au point effective de la chose vendue. La Cour a en effet relevé que « la signature par [le client] du procès-verbal de réception (…) ne saurait exonérer [le prestataire] » de sorte que « nonobstant la signature par [le client] du procès-verbal de réception précité, il ne peut en être déduit qu’à cette date, la solution était conforme et qu’il appartenait [au client] de dénoncer tout dysfonctionnement dans le délai de garantie de 3 mois ». Ainsi, la signature d’un PV de recette ne libère pas le prestataire de son obligation de délivrance, de sorte que, même en présence d’un PV de livraison signé, le client peut se plaindre de dysfonctionnements du système survenus postérieurement.

Conseil pratique

Les praticiens doivent tenir compte de cette jurisprudence, désormais bien établie, et veiller à bien documenter les phases de réception ainsi que les PV. Ils seront également inspirés de prévoir en amont les modalités techniques, organisationnelles et financières d’un éventuel accompagnement des clients par le prestataire au titre de la prise en main de la solution acquise.

 

Enseignement n°6 : Sécuriser la sortie du contrat

 

1. Le risque d’une résiliation prématurée

Dans son arrêt du 24 avril 2025 (RG n°24/01010), la Cour d’appel de Rouen a eu à se prononcer sur le bien-fondé de la résiliation par un client d’un contrat portant sur l’installation d’un logiciel de gestion et comptabilité assorti de prestations complémentaires. Pour juger la résiliation injustifiée, la Cour a tenu compte du timing dans lequel le client l’a notifiée à son prestataire, relevant que « dès lors que [le prestataire] a répondu à l’essentiel des demandes d’assistance [du client], rien ne permet d’affirmer qu’il ne serait pas parvenu, à brève échéance, à obtenir une installation fonctionnelle de la solution logicielle de sorte que la résolution intervenue le 13 avril 2022 a été faite à contretemps et prématurément et a porté sur une inexécution dont la Cour ne peut estimer qu’elle était suffisamment grave pour la motiver ». La décision de résilier un contrat ne doit donc pas être notifiée à contretemps et/ou prématurément.

Conseil pratique

Il est vivement recommandé aux parties à un contrat IT de bien se préparer avant de le résilier unilatéralement et de ne pas précipiter une telle décision. Le moment de la notification est en effet central, puisqu’il aura nécessairement des conséquences sur le caractère justifié ou au contraire injustifié de la résiliation. Pour éviter de résilier « trop tôt » ou au contraire « trop tard », les clients seront bien inspirés d’associer les équipes projet et opérationnelles à leur décision, en vérifiant en amont qu’une installation conforme du système à brève échéance n’était pas envisageable.

 

2. Le risque d’une résiliation mal préparée

Un client se plaignant de dysfonctionnements du matériel acquis a résilié le contrat de vente et de maintenance d’un système de caisse enregistreuse et a sollicité le remboursement de l’acompte versé. Saisie de l’affaire, la Cour d’appel de Bordeaux (12 juin 2025, RG n°23/02565), après avoir rappelé les principes applicables, a retenu qu’« il n’est pas démontré que le système d’encaissement était inutilisable et que les dysfonctionnements étaient dus au matériel lui-même et non aux modalités d’utilisation ». Les juges ont ici pointé une défaillance de la part du client dans l’administration de la preuve, ce dernier ne parvenant pas, « en l’absence de constat d’huissier ou d’expertise amiable », à établir l’existence de manquements suffisamment graves imputables au prestataire pour justifier la résolution du contrat.

Conseil pratique

Un client qui souhaite mettre fin à sa relation contractuelle avec un prestataire informatique doit disposer en amont d’un dossier probatoire solide et documenté et s’assurer qu’il est en mesure d’objectiver les perturbations et dysfonctionnements invoqués.

 

3. Champ d’application des clauses exonératoire de responsabilité, la vigilance est de mise

Une décision rendue à propos de l’aménagement contractuel de la responsabilité du prestataire particulièrement retenu l’attention. Il s’agit d’un arrêt de la Cour d’appel de Paris du 10 janvier 2025 (RG n°22/11677) rendu à propos de l’exécution d’un contrat de fourniture d’une solution de paiement en ligne sécurisé. Victime d’une série d’opérations frauduleuses, l’entreprise utilisatrice a décidé de ne plus travailler avec ce prestataire et l’a assigné en réparation. L’affaire a été portée devant la Cour d’appel.

Dans sa décision, la Cour a écarté la clause exonératoire de responsabilité du prestataire « au titre de tous dommages ou préjudices indirects ou immatériels qui pourraient résulter de l’inexécution ou de l’exécution défectueuse des services » au motif que c’est « un défaut d’information et de conseil qui était reproché [au prestataire] et non une défaillance de son interface ».

La clause exonératoire de responsabilité s’applique donc, semble-t-il, en cas de violation de l’obligation principale (en l’occurrence la fourniture d’une interface de gestion) et doit être rejetée en cas de manquement au devoir de conseil (accessoire de l’obligation principale). On peine à saisir une telle différence de régime, d’autant que la rédaction de la clause litigieuse semblait suffisamment large pour couvrir tous les manquements du fournisseur au cours de l’exécution du contrat et notamment les défaillances au titre du devoir de conseil.

Conseil pratique

Pour éviter toute déconvenue, les rédacteurs – surtout côté prestataire – veilleront à encadrer précisément les clauses limitatives de responsabilité, de manière à ce que l’obligation contractuelle de conseil ne soit pas mise de côté, quitte à spécifier expressément que l’exclusion de responsabilité s’applique également en cas de manquement au devoir de conseil.

 

4. Indemnité de sortie : attention à la requalification

Dans son arrêt du 13 mars 2025 (RG n°21/08684) la Cour d’appel de Lyon a eu à se prononcer sur la question de la qualification de l’indemnité de sortie (clause pénale vs clause de dédit).

Dans cette affaire, il a été jugé, à propos d’un contrat de mise à disposition d’une solution SaaS, que la clause de résiliation prévoyant le paiement par le client d’une somme égale à ce qui aurait été perçu en cas d’exécution jusqu’au terme du contrat revêt un caractère à la fois indemnitaire (évaluation forfaitaire du préjudice) et comminatoire (son montant élevé ne pouvant que contraindre le client à exécuter le contrat jusqu’à son terme) et devait donc s’analyser en une clause pénale.

La Cour a ensuite, comme le prévoit l’article 1231-5 du Code civil et après avoir tenu compte du comportement fautif du client dans le cadre de l’exécution de ses obligations, réduit son montant d’environ 50%.

Dans une autre affaire, la Cour d’appel de Toulouse (9 septembre 2025, RG n°23/02197) a jugé que l’indemnité de sortie réclamée par le prestataire à hauteur de 95% des sommes restant dues jusqu’à l’échéance du contrat répond à la qualification de clause pénale avant de juger un tel montant excessif et le ramener à 60% des dites sommes.

Conseil pratique

Ces deux arrêts doivent inciter les praticiens à soigner la rédaction de la clause de résiliation afin d’écarter toute difficulté ultérieure de qualification et, en tout état de cause, les encourager à faire preuve de modération dans la fixation des montants pour ne pas risquer d’attirer l’attention du juge qui pourrait, le cas échéant, réviser le montant de l’indemnité.

 

A propos de l’auteur

Olivier Pignatari est avocat spécialisé en droit de l’informatique et des nouvelles technologies, tant en conseil qu’en contentieux.

Le règlement Dora, en vigueur depuis le 17 janvier 2025, est encore, voire de plus en plus, à l’origine de discussions entre les entités financières et les prestataires de service impactés directement (les prestataires critiques devraient être désignés dans la 2^eme moitié de 2025) et indirectement (via les exigences contractuelles de leurs clients).

De nombreux exercices de remédiation sont encore en cours, sans compter la conclusion croissante de nouveaux contrats portant sur des services informatiques par des entités financières. En effet, rien qu’en 2022, les autorités européennes de surveillance (« AES ») ont identifié 15 000 prestataires informatiques fournissant des services à environ 1600 entités financières dans l’Union[1] ce qui montre l’accroissement de l’utilisation de technologies de l’information et de la communication (« TIC ») par le secteur financier et la conclusion de contrats pour les besoins de ces services.

 

Points clés abordés dans l’article

– Le règlement DORA impose un renforcement des contrats entre entités financières et prestataires informatiques.

– Il vise à accroître la résilience opérationnelle du secteur financier, au-delà des seules exigences de cybersécurité.

– Les exigences contractuelles sont nombreuses : clauses obligatoires sur la localisation des données, la sous-traitance, la réversibilité ou encore les droits d’audit.

– Les entités financières souhaitent imposer leurs modèles contractuels pour garantir leur conformité, tandis que les prestataires TIC cherchent à préserver la cohérence de leurs offres standardisées.

– Les discussions portent aussi sur la conformité à la loi, la supervision de la chaîne de sous-traitance, les droits d’audit et les clauses de résiliation, souvent sources de tensions.

– L’article met en lumière la nécessité d’un équilibre contractuel entre les obligations réglementaires et la réalité opérationnelle des prestataires.

– En conclusion, il souligne l’émergence d’offres spécifiques pour le secteur financier, fondées sur le devoir de conseil, la collaboration et le principe de proportionnalité.

 

Propos introductif – contexte d’adoption du règlement

Contexte réglementaire européen : la Décennie Numérique

Le règlement Dora s’inscrit dans le contexte règlementaire de la décennie numérique de la Commission Européenne (la « Décennie Numérique ») qui vise à favoriser une « transformation numérique sécurisée, sûre, durable et centrée sur les citoyens, conformément aux valeurs fondamentales et aux droits fondamentaux de l’UE[2]. Dans sa proposition initiale, la Commission européenne rappelle le contexte de la crise financière de 2008 et les mesures prises pour renforcer la stabilité du secteur financier, déplorant, néanmoins que ces mesures « ne s’attaquent qu’indirectement aux risques informatiques dans certains domaines, dans le cadre des mesures visant à remédier plus largement aux risques opérationnels[3]. Il est bien sûr fait allusion ici à la règlementation mise en place sur la gouvernance et la gestion des risques financiers mais également aux lignes directrices des AES qui prévoyaient déjà un nombre important d’obligations, notamment de contractualisation[4]

Leçons de la crise financière de 2008 et enjeux de stabilité

Adopté le même jour (14 décembre 2022) que la directive Dora[5], la directive NIS II visant la cybersécurité des entités essentielles ou importantes[6] et la directive relative à la résilience des entités critiques[7], le règlement Dora s’inscrit dans une approche holistique de l’Union européenne en matière de cybersécurité : d’une part, une approche horizontale avec NIS II et, depuis octobre 2024, le Cyber Résilience Act concernant la cybersécurité des produits comportant des éléments numériques et, d’autre part, une régulation sectorielle avec le règlement Dora en ce qui concerne le secteur financier constituant une lex specialis pour ce secteur.

Dora et la régulation sectorielle du secteur financier

À ce sujet, le règlement Dora se démarque par une approche encore plus poussée, au-delà de la cybersécurité, celle de la résilience opérationnelle. Ainsi, bien plus que les lignes directrices existantes, le règlement Dora, complété par le corpus de normes techniques de règlementation (« RTS ») et normes techniques d’exécution (« ITS »), prévoit un cadre règlementaire particulièrement prescriptif dans le but de pousser les entités financières à identifier et parer les risques liés aux TICs.

Intérêts divergents : entités financières vs prestataires TIC

Dans ce contexte, deux intérêts divergents apparaissent. D’une part, les entités financières visées par le règlement sont tenues de renforcer de manière massive non seulement la gouvernance liée aux TICs mais également leurs contrats avec leurs fournisseurs. D’autre part, les prestataires informatiques doivent répondre aux exigences réglementaires et contractuelles de leurs clients et les concilier avec leur modèle de fourniture de services souvent standardisé et la loi qui est applicable à leurs activités.

Alors, sommes-nous face des intérêts irréconciliables ou bien devant une opportunité de nouvelles offres contractuelles adaptées au secteur financier ? Pour répondre à cette question, nous nous pencherons sur les différents points de discussion entre entités financières et prestataires de service TIC.

 

 

Documentation contractuelle servant de base à la discussion : un enjeu habituel pour les contrats informatiques

La documentation à utiliser dans le cadre de la contractualisation d’un service TIC n’est ni une problématique nouvelle ni une question spécifique au règlement Dora. Au contraire, il s’agit d’un débat récurrent dans la négociation de contrats informatiques dans lesquels chaque partie insiste pour utiliser sa propre documentation.

Un règlement prescriptif en matière contractuelle

Avant de se plonger dans le débat relatif à la documentation contractuelle source, il est pertinent de rappeler les exigences contractuelles du règlement Dora.

Dans un premier temps, l’article 30(2) applicable à toute prestation de services TIC liste un certain nombre d’éléments fondamentaux à prévoir dans le contrat tels la description de services et si la sous-traitance de fonctions critiques ou importantes est autorisée, la localisation des services et des données, ou encore sur la réversibilité des données pour ne citer que quelques exemples. Pour la plupart, il s’agit d’éléments de bon sens compris dans tout contrat informatique indépendamment du secteur d’activité concerné. Ainsi, le débat autour de ces points est relativement limité, peu importe la documentation contractuelle utilisée.

Dans un deuxième temps, l’article 30(2) ajoute des exigences contractuelles plus détaillées lorsque les services TIC soutiennent des fonctions critiques ou importantes telles que la participation à des tests de pénétration fondés sur la menace (« TLPT »), les notifications d’évolution de la situation du prestataire ou de larges droits d’audit en faveur du client et son régulateur etc.

Ces exigences sont renforcées par les RTS relatives à la politique de contractualisation de services TIC soutenant des fonctions critiques ou importantes[8] (« RTS sur la Contractualisation ») et les RTS dédiées à la sous-traitance de services qui soutiennent des fonctions critiques ou importantes[9](les « RTS Sous-traitance »). En effet, les RTS sur la contractualisation ajoutent aux dispositions de l’article 30(3), des exigences contractuelles en matière de reporting, absence de conflit d’intérêt, notifications d’incidents, audits indépendants, pour n’en citer que quelques-unes. De leur côté, les RTS sous-traitance (traitées plus bas dans l’article) prévoient, elles aussi, des exigences contractuelles à inclure dans le contrat avec le prestataire principal mais aussi à répercuter dans le contrat de sous-traitance.

Un enjeu d’efficacité des discussions

Les attentes des entités financières face à la documentation contractuelle

La question se pose comme d’habitude : quelle documentation contractuelle est la mieux adaptée afin de répondre aux exigences de Dora ? D’une part, les entités financières, clients du service et directement concernées par Dora, soutiennent souvent que leur documentation est mieux adaptée aux exigences règlementaires et reprend la cartographie des obligations directes et indirectes sur le contrat. Par ailleurs, elle reflète le profil de risque de l’entité financière tel qu’il ressort, notamment de sa politique de gestion des risques liés aux TIC, d’autant plus que certaines dispositions du texte ont un impact indirect sur le contrat[10]. Enfin, dans le contexte d’exercices de remédiation importants, les clients peuvent être face à une difficulté s’ils doivent analyser la documentation contractuelle de tous leurs fournisseurs et préfèrent une approche unifiée qui reflète leurs exigences minimales pour contractualiser avec un prestataire de services TIC.

La perspective des prestataires TIC et la réalité opérationnelle

D’autre part, les prestataires informatiques mettent en avant le fait que leur documentation contractuelle reflète le delivery model de leur service et donc est le plus à même de tenir compte de la réalité opérationnelle des exigences contractuelles. Ce raisonnement est d’autant plus mis en avant par les prestataires de service standard (e.g. cloud) dont le service est souvent fourni de la même manière à l’intégralité de leurs clients réglementés ou non et dont la documentation est amenée à évoluer en même temps que le service. Enfin, les prestataires de service TIC, peuvent être réticents à accepter des clauses contractuelles issues de la politique de risques du client ou de son interprétation du règlement et insistent pour se rapprocher au maximum des dispositions obligatoires du règlement afin de limiter leur exposition.

Points de tension : politique de risques vs exigences réglementaires

En fin de compte, la décision de la documentation contractuelle dépend du contexte de négociation des parties et de la clarté et la complétude de la documentation contractuelle qu’elles proposent. Quoi qu’il en soit, il ressort nettement un besoin de mettre en place une documentation contractuelle conforme aux exigences du règlement tant pour les entités financières que pour les prestataires informatiques.

En effet, un document contenant une cartographie des clauses exigées par Dora est généralement bien perçu par les clients comme un signe de maturité et constitue un puissant outil de marketing.

Annexes et documentation complémentaire : optimiser les appels d’offres

Même si les parties conviennent d’utiliser le modèle du client la rédaction d’une annexe dédiée par le prestataire est loin d’être futile : elle pourra servir de grille de lecture de la documentation du client et permettra, en tout état de cause de préciser le détail des engagements du fournisseur en identifiant comment, d’un point de vue opérationnel, ce dernier répond aux exigences règlementaires. Cette approche est d’autant plus pertinente en processus d’appel d’offres dans lequel la conformité règlementaire est souvent un critère de sélection pouvant différencier deux fournisseurs. En d’autres termes, la formulation d’une offre « service financiers » peut être un vrai gain de temps dans le processus de sélection et contractualisation.

 

 

La conformité à la loi : un équilibre difficile à trouver

Des intérêts diamétralement opposés difficiles à concilier

Dans le contexte de la Décennie Numérique et notamment dans celui du règlement Dora, la problématique de la conformité à la loi prend en compte une ampleur plus importante.

Pour les entités financières, la conformité règlementaire du service est fondamentale. En effet, leur conformité à la réglementation applicable au secteur financier est directement liée à la conformité des services telle que reflétée dans le contrat mais également à la réalité opérationnelle. Elles ont donc tendance à exiger dans le contrat le fait que le service fourni sera conforme non seulement à la règlementation applicable aux technologies de l’information mais également à la règlementation bancaire et leurs évolutions sans qu’elles aient besoin de concrétiser des spécifications ou payer pour des ajustements ultérieurs. Cette argumentation est d’autant plus présente lorsqu’un prestataire, notamment de niche, travaille principalement ou en grande partie avec le secteur financier.  Le client s’attend alors à ce que la conformité règlementaire et ses évolutions seront prises en compte dans le business model (p. ex. veille juridique, répartition des conséquences financières d’une évolution sur l’intégralité de la clientèle).

À l’opposé de l’enjeu des clients, les prestataires de service rappelleront, qu’en règle générale ils ne sont pas soumis au règlement Dora et que le client est seul responsable de sa conformité règlementaire. En effet, le règlement Dora ne s’appliquera directement qu’à un nombre limité de prestataires informatiques désignés comme critiques pour le secteur financier dans la deuxième moitié de 2025[11]. Par conséquent, les prestataires insistent pour s’engager uniquement à la loi qui leur est applicable, les spécificités du secteur financier devant être formulées dans les spécifications du client et les ajustements nécessaires devant être supportés financièrement par l’entité financière.

Une solution sur mesure dépendant du contexte de négociation

La question de la conformité à la loi n’a pas de solution unique, ni prédominante : il s’agit essentiellement d’une question technique ainsi que financière. Les approches contractuelles adoptées sont aussi diverses que les offres elles-mêmes et dépendent de la nature du service (standard ou « personnalisé »), les secteurs d’activité dans lesquels intervient le prestataire (service fourni de manière standard ou service spécifique délivré pour le secteur financier), l’impact des évolutions règlementaires (adaptation d’un service existant ou mise en place d’un service nouveau) et du pouvoir de négociation de chaque partie.

Il ne faut pas oublier, par ailleurs, que certaines règlementations applicables aux prestataires informatiques peuvent donner des réponses à certaines exigences du client. À  titre d’exemple, les contraintes sur les prestataires de service cloud en matière de réversibilité imposées par le Data Act peuvent répondre aux demandes des clients de sécuriser et fluidifier les stratégies de sortie en application de Dora. En particulier, le projet clauses contractuelles types relatives à la sécurité et la continuité d’activité en cours d’élaboration dans le contexte du Data Act[12] ne saurait qu’être apprécié par les entités financières qui cherchent à protéger la résilience opérationnelle.

En tout état de cause, les clauses de conformité à la loi deviennent de plus en plus centrales (et détaillées) et il convient d’y consacrer le temps nécessaire afin de s’assurer de la prise en compte des évolutions règlementaires et ses impacts financiers, notamment dans le contexte de contrats à longue durée.

 

La chaîne de sous-traitance : un enjeu majeur dans la résilience opérationnelle

Des exigences règlementaires détaillées sur la supervision de la chaîne de sous-traitance

Plus encore que les lignes directrices existantes des AES, le règlement Dora accorde une grande importance à la sous-traitance et aux risques qu’elle peut créer, notamment avec les RTS sur la sous-traitance de services soutenant des fonctions critiques ou importantes.

Cette approche n’est pas surprenante dans la mesure où, qu’on parle de cybersécurité ou de résilience opérationnelle, les attaques externes concernent de plus en plus la chaîne d’approvisionnement qui représente une porte d’entrée souvent plus facile et surtout plus variée.

Ainsi, bien que les RTS sous-traitance aient été allégées en matière de supervision de la chaîne de sous-traitance avec la suppression de l’ancien article 5, de fortes exigences en matière d’analyse de risque et supervision subsistent. En effet, l’obligation d’identifier tous les sous-traitants impliqués subsiste au titre de l’article 3(1)(b) des RTS sur la sous-traitance mais également l’article 3(2)(b) des ITS sur le registre d’information[13].

Par ailleurs, avant même de contractualiser avec un prestataire de services, l’entité financière devra opérer une analyse de risques poussée tenant compte de la longueur et complexité de la chaîne de sous-traitance ainsi que de nombreux autres critères tels que la localisation des sous-traitants, la possibilité pour le prestataire principal de les identifier et les superviser etc. Tout cela avant même de signer le contrat qui doit comporter des engagements de suivi de la prestation mais également de répercussion dans le contrat avec le sous-traitant d’un certain nombre d’éléments tels les droits d’audit, les obligations de suivi et de déclaration du sous-traitant, les exigences en matière de plan d’urgence, les normes de sécurité[14].

Des engagements de “back-to-back” parfois difficiles à obtenir

Des exigences contractuelles complexes pour les entités financières

Au regard des contraintes règlementaires dont les paragraphes ci-dessus ne sont qu’un résumé, les entités financières sont amenées à détailler leurs accords contractuels relatifs à des services TIC et à exiger de leurs prestataires un nombre important d’informations et engagements au regard de leurs sous-traitants.

Cartographie de la chaîne de sous-traitance : une étape clé pour les prestataires

Pour les prestataires de services, cela suppose dans un premier temps de réaliser une cartographie de la chaîne de sous-traitance dans son intégralité. Cette cartographie pose rarement un problème dans le cadre de prestations de services « sur mesure » (e.g. maintenance, externalisation etc.) dans lesquelles le prestataire principal dispose d’une maîtrise importante des compétences externes dont il a besoin, et donc de la chaîne de sous-traitance relativement réduite ou du moins souvent constituée de ses filiales.

Les défis des services TIC standards

Au contraire, ce travail est plus difficile dans le contexte de service TIC standards (e.g. IaaS, PaaS, SaaS) qui ont comme caractéristique une chaîne de sous-traitance plus complexe, souvent elle-même reposant sur des services standard fournis de manière agnostique. Dans ce contexte, il est plus difficile d’imposer des exigences contractuelles spécifiques au sous-traitant qui, parfois, peut être loin du client final. Le prestataire principal se retrouve alors souvent « entre deux » sans avoir la possibilité d’absorber l’intégralité du risque lié aux exigences contractuelles des clients.

Une documentation contractuelle à deux niveaux

C’est ainsi que commence à apparaître une documentation à deux niveaux, notamment dans des contrats portant sur des services standards proposés aux services financiers : un premier niveau comporte les obligations contractuelles assumées par le prestataire principal et un deuxième niveau prévoit les obligations contractuelles applicables aux sous-traitants (notamment hébergeurs) dans une logique de back-to-back inversé. Les mécanismes d’opposition et résiliation du contrat en cas de désaccord de l’entité financière sont également utilisés. Il convient alors que l’entité financière vérifie que tous les niveaux répondent aux exigences contractuelles et qu’elle s’assure de disposer d’un service alternatif en cas de désaccord sur la chaîne de sous-traitance l’obligeant à résilier le service.

 

Certifications et droits d’audit : un équilibre difficile à trouver pour les prestations standards

Des droits d’audit illimités, rien de nouveau pour le secteur financier

La demande des entités financières d’avoir un droit de regard sur leurs prestataires informatiques n’est pas née avec le règlement Dora. Elle était bien présente dans les lignes directrices des AES et ne surprend guerre. À  titre d’exemple, les lignes directrices de l’EBA, prévoyaient déjà la possibilité pour la fonction d’audit interne de la banque de revoir la fonction externalisée sur la base d’une analyse de risque[15].

Conformément au principe de proportionnalité, dans son article 30(3) et dans l’article 8 des RTS sur la contractualisation, Dora maintient une logique similaire selon laquelle les droits d’audit illimités s’appliquent uniquement sur les services qui soutiennent des fonctions critiques ou importantes. Le règlement précise que l’entité financière ou le régulateur doit être en mesure de collecter des copies de documents pertinents s’ils sont essentiels aux activités du prestataire. Ces droits d’audit visent à sécuriser la possibilité pour l’entité financière de superviser effectivement les prestations et doivent être lus en parallèle des obligations de reporting du prestataire.

Les certifications : une solution incomplète

La nouveauté du règlement Dora est d’interdire l’utilisation exclusive des certifications et plans d’audit internes de leurs prestataires[16]. Cette approche pose rarement de difficulté dans le contexte de prestations de services « personnalisées » (e.g. contrats d’externalisation). En effet, dans la mesure où l’article 30(3)(e)(iv) permet de définir une fréquence, portée et procédure d’audit, les garde-fous habituels restent applicables.

Les défis des services standardisés

Le sujet est tout autre pour les services fortement standardisés qui reposent généralement sur des mécanismes de supervision mutualisés (e.g. supervision de la disponibilité via une console) et des rapports d’audit de tiers (p. ex. SOC II, ISO 27 001 etc.). Pour ces prestataires, dévier de cette approche pose une difficulté majeure dans la mesure où des droits d’audit exigent la mobilisation forte de leur personnel, notamment dans le contexte de TLPT, et peuvent mettre à risque les données de leurs autres clients utilisant des infrastructures mutualisées. Par ailleurs ils peuvent rencontrer des difficultés à répercuter des droits d’audit permissifs avec leurs sous-traitants.

Les niveaux d’assurance alternatifs

La principale solution à cette problématique apparaît à l’article 30(3)(e)(ii) du règlement qui permet de convenir d’autres niveaux d’assurance alternatifs lorsque les droits des autres clients du prestataire sont affectés. Ces niveaux d’assurance alternatifs sont précisés à l’article 8(2) des RTS sur la contractualisation qui permet aux entités financières de s’appuyer, outre sur leur propre audit interne, sur des audits groupés.

Deux types d’audits groupés sont alors possibles et ressortent du projet de RTS relatif aux TLPT[17] : les tests groupés (« pooled test ») à l’occasion desquels le prestataire contractualise avec l’auditeur et qui ne sont possibles que si l’entité financière a vérifié leur complétude, pertinence et mise à jour et les tests joints (« joint test ») qui sont des tests, autres que les tests groupés qui impliquent plusieurs entités financières (p. ex. tests réalisés par plusieurs entités financières du même groupe).

Conclusion sur les audits

En conclusion, il n’y a pas de solution miracle à la question des droits d’audit des entités financières, la réponse devant être trouvée dans le delivery model du prestataire de services TIC et des assurances qu’il peut offrir à son client. L’on peut imaginer l’émergence de programmes d’audit robustes réalisés à une fréquence déterminée lors desquels plusieurs entités financières pourraient activer leur droit d’audit de manière à regrouper les sollicitations du prestataire et réduire le risque d’impact sur les systèmes de production de ses clients.

 

Les droits de résiliation : un point de discorde majeur

Des droits de sortie étendus imposés par la règlementation

Outre les droits d’audit ou encore la supervision de la chaîne de sous-traitance, un des sujets les plus discutés dans le contexte du règlement Dora relève des droits de résiliation.

En effet, l’article 28(7) exige de prévoir dans les contrats de prestation de services TIC, ce peu importe  leur criticité, les droits de résiliation en cas de manquement à la règlementation, de changements significatifs dans la situation du prestataire, de faiblesses avérées liées à la gestion des risques ou encore l’impossibilité pour une autorité de réaliser la supervision de l’entité financière.

Pour les services soutenant des fonctions critiques ou importantes, ces droits de résiliation sont complétés par les RTS sous-traitance qui prévoient des droits de résiliation si le prestataire de services TIC a mis en œuvre des changements significatifs aux accords de sous-traitance malgré l’objection du client ou avant la période de préavis durant laquelle le client peut s’y opposer, ou encore si le prestataire a eu  recours à de la sous-traitance non-autorisée.

On note ici une volonté du régulateur de renforcer la position des entités financières en mettant à risque le prestataire de services TIC si la résilience opérationnelle n’est pas respectée. Néanmoins, c’est justement cette mise à risque que les prestataires de services TIC souhaitent encadrer.

Un équilibre financier difficile mais indispensable

Même en dehors d’un contexte règlementaire, les droits de résiliation sont souvent l’objet de discussions importantes entre les parties à un contrat informatique. Pour le client, ils représentent un moyen de pression sur le prestataire dans un certain nombre de cas jugés fondamentaux par le client. D’autre part, pour le prestataire, des droits de résiliation permissifs, voire subjectifs, mettent le chiffre d’affaires associé à risque et nuisent à la reconnaissance du revenu.

C’est donc sans surprise que les droits de résiliation, ou plutôt leurs conséquences financières, font l’objet de débats passionnés. À ce sujet, les entités financières auront tendance à soutenir que les cas précités sont une exigence règlementaire et, pour la plupart, constitutifs d’un manquement puisqu’ils font état d’une incapacité du prestaire de maintenir la résilience opérationnelle. D’autre part, les prestataires de services TIC soutiendront que certains cas de résiliation sont le résultat d’une analyse de risques subjective ou sont liés à la règlementation applicable au client (notamment la capacité de l’autorité compétente de superviser l’entité financière) qui n’est pas nécessairement rattachée à un manquement.

Encore une fois, il n’y a pas une solution unique si ce n’est de discuter ouvertement des différents cas de résiliation en fonction du contexte, de la nature de la prestation et des enjeux financiers afin de trouver un équilibre économique acceptable pour les deux parties. Naît alors la nécessité pour les prestataires de services TIC de prendre en compte, dans leur modèle financier et leur matrice de risques, des droits de résiliation spécifiques pour le secteur financier.

 

Conclusion

Des offres spécifiques pour le service financier fondées sur le devoir de conseil, d’alerte, de collaboration et le principe de proportionnalité ?

Comme on a pu le voir tout au long de cet article, le règlement Dora et les différentes normes techniques (ITS / RTS) créent le besoin de mettre en place une documentation contractuelle spécifique pour le secteur financier et, par conséquent, une offre commerciale et opérationnelle adaptée. Il n’y pas de doute que les prestataires qui travaillent régulièrement avec le secteur financier sont amenés à personnaliser leur offre de services pour répondre aux exigences du secteur, quand bien même le service fourni est standard.

Deux éléments complémentaires permettent d’éclairer les discussions contractuelles et de trouver des solutions adaptées aux problématiques contractuelles.

Dans un premier temps, en ce qui concerne le prestataire, on voit l’importance accrue de l’obligation de conseil et d’alerte qui vise à guider le client dans la compréhension de l’offre et de la manière dont la conformité règlementaire peut être atteinte. Le devoir de conseil du fournisseur est primordial dans la phase précontractuelle lors de laquelle le client identifie ses besoins (y compris règlementaires) et évalue si, ou plutôt comment, le fournisseur peut y répondre.

Le deuxième élément permettant de débloquer les discussions contractuelles relève du client et de son obligation de respecter le principe de proportionnalité, pilier transversal du règlement Dora. Ainsi, le client doit appliquer systématiquement une analyse de risque afin d’adopter une approche contractuelle proportionnée en évitant des clauses « balais » vides de sens au regard de la réalité du service.

C’est précisément pour pouvoir appliquer le principe de proportionnalité que les entités financières peuvent bénéficier du conseil du prestataire de services TIC qui, à l’aide d’une approche pédagogique, permet au client d’être proportionné dans ses demandes contractuelles et chercher la solution de conformité non seulement dans des clauses contractuelles mais, également , et c’est le but ultime de Dora, dans la configuration, l’utilisation et l’opération du service.

 

A propos de l’auteure

Evelina Dimitrova est avocat à la Cour et Senior Associate au sein du cabinet DLA Piper France LLP. Elle intervient principalement en droit des nouvelles technologies, de la protection des données personnelles, de la propriété intellectuelle et des contrats informatiques.

 

Les points clés à retenir sur les risques contractuels et contentieux informatiques

• La réussite d’un projet informatique repose sur un cahier des charges précis, permettant de définir clairement les besoins, le périmètre et les attentes.
• Un contrat équilibré et adapté à la nature du projet (Agile ou cycle en cascade) est déterminant pour encadrer les responsabilités et limiter les désaccords.
• La phase d’exécution nécessite une collaboration étroite entre les parties et le respect des प्रक्रdures de gouvernance (PAQ, comités, recette).
• Les contentieux naissent souvent d’un défaut de communication ou d’un périmètre mal défini.
• La constitution d’un dossier probatoire solide (échanges, livrables, preuves techniques, constats) est indispensable pour défendre ses droits.
• L’expertise judiciaire joue un rôle central pour analyser les responsabilités et structurer une éventuelle action contentieuse.

Précautions à prendre avant la contractualisation

Un projet informatique mal défini est souvent synonyme d’échec. Aussi, le client doit-il se ménager un temps suffisant pour bien préparer l’appel d’offres et formaliser clairement ses besoins et objectifs dans le cahier des charges qui exposera notamment l’existant, le contexte métier/marché, les contraintes techniques et organisationnelles entourant la mise en place de la solution, le périmètre fonctionnel du projet, le calendrier et les éventuelles dates impératives, les ressources alloués au projet, les performances attendues, les objectifs commerciaux et financiers ou encore les conséquences d’un éventuel échec.

Ce document peut également prévoir une liste de prérequis juridiques (maîtrise d’œuvre, obligations de résultat, limites de responsabilité, pénalités, propriété intellectuelle, droit applicable et tribunaux compétents, etc.) sur lesquels les candidats devront se positionner, ce qui simplifiera et accélérera les négociations avec le candidat retenu.

Les candidats pourront également être amenés, dans le cadre de leur réponse à appel d’offres, à fournir les documents techniques suivants :

 

• un projet de plan d’assurance qualité (PAQ) précisant notamment :
  • la méthode de gestion de projet envisagée (« Agile » ou « cascade »),
  • les grandes phases du projet,
  • l’organisation humaine du projet (ressources/profil),
  • les phases et procédures de recette,
  • la gestion des risques et des problèmes rencontrés,
  • les niveaux de services,
  • la composition/périodicité/rôle des instances de gouvernance, etc.
• la description des prestations envisagées,
• la répartition des tâches entre le candidat, le client et d’éventuels intervenants tiers (sous-traitants, éditeurs, hébergeurs, tiers-mainteneur, etc.) formalisée dans une matrice de responsabilité (RACI)

 

On perçoit l’importance du cahier des charges qui, en cas de litige, permettra de comprendre ce qu’attendait le client et de mesurer les engagements du prestataire.

Cela étant, le client attend souvent des fonctionnalités qui, en réalité, ne sont pas couvertes par la solution proposée ou bien ne sont pas portées à la connaissance du prestataire et, in fine, ne sont pas comprises dans le périmètre.

Pour éviter ce type de malentendu, le client doit donc, en phase d’avant-vente, exprimer clairement ses besoins et objectifs fonctionnels, les partager avec le prestataire qui, se son côté, lui fournit une information circonstanciée et personnalisée, notamment sur l’aptitude de sa solution à l’utilisation prévue, sur son adéquation au regard des fonctionnalités proposées ou encore sur son possible interfaçage avec la configuration du client, etc.

 

Précautions à prendre au stade de la contractualisation

La contractualisation d’un projet informatique est essentielle à son succès : elle permet aux parties d’encadrer les enjeux financiers ainsi que l’organisation du projet et de régir leurs responsabilités respectives.

Un contrat informatique équilibré

La réussite du projet nécessite une étroite et permanente collaboration entre les parties, ce qu’un contrat déséquilibré ne permet a priori pas. Tout en défendant leurs intérêts propres, chaque partie doit donc veiller à ce que les termes du contrat préservent, d’une certaine manière, les intérêts de son cocontractant. En effet, un contrat négocié dans un esprit « gagnant/gagnant » devrait permettre une collaboration entre les parties et limiter ainsi les situations de blocage en phase de réalisation.

Un contrat informatique adapté

Le contrat doit être adapté à la complexité du projet ainsi qu’à la nature des prestations à délivrer. Dans le cadre d’un projet d’envergure, de type intégration, les parties auront tout intérêt à prévoir une phase préalable de cadrage général.

Celle-ci se concrétisera par des ateliers d’analyse technique et fonctionnelle qui permettront aux parties de synchroniser leur vision des processus cible, de partager leurs contraintes respectives ou encore de s’entendre sur les livrables attendus pour chaque jalon. Il est d’ailleurs recommandé, lorsque l’organisation du client le permet, d’y impliquer les métiers, ces derniers ayant souvent des attentes particulières qui ne sont pas toujours exprimées dans le cahier des charges initial. Le client pourra ainsi affiner ses besoins tandis que le prestataire s’assurera de leur bonne compréhension et mesurera l’aptitude de sa solution à y répondre. Autant de précautions qui faciliteront l’adéquation entre le résultat et l’attendu et éviteront des retours en arrière en conception voire en phase de réalisation, limitant ainsi le risque de dérive.

Le contrat doit en outre tenir compte de la méthode de projet (« cascade » ou Agile), sous peine d’être inadapté et de rendre son exécution délicate, voire impossible. Le contrat doit également être clair sur le type de prestations attendues (développements spécifiques, intégration de logiciels, paramétrages, hébergement, maintenance, etc.) ainsi que sur le phasage du projet et les livrables associés, toute ambiguïté sur ces points pouvant générer des désordres.

Enfin, le périmètre des prestations confiées au prestataire doit être clairement défini : pour cela, les parties peuvent y exclure expressément certains services. Ainsi, le client reçoit une information adéquate sur les limites du périmètre d’intervention de son prestataire tandis que ce dernier sera protégé en cas de griefs formulés à son encontre pour des manquements à des engagements qu’il n’aurait précisément pas pris.

 

Précautions à prendre au stade de l’exécution du contrat informatique

L’exécution d’un projet informatique renferme son lot d’imprévus et d’incidents, sources potentielles de désaccords, voire de contentieux. Certains réflexes devraient toutefois permettre d’en limiter le risque et, lorsqu’il survient, de mieux s’y préparer.

Comment limiter le risque de contentieux informatiques ?

Les contentieux informatiques naissent, le plus souvent, d’un manque de collaboration, d’incompréhensions entre les parties ou encore d’une défaillance dans l’organisation du projet. Pour permettre au projet d’aboutir, les parties devront donc collaborer de façon étroite et permanente.

Elles devront également appliquer rigoureusement le PAQ ainsi que les procédures prévues (escalade, recette, signalement, gouvernance, etc.). Les parties ont en effet souvent tendance à traiter les difficultés par l’envoi – prématuré – de courriers recommandés entre directions générales plutôt que de les aborder dans le cadre des instances de pilotage dont le rôle est de remonter et qualifier les problèmes, de les tracer et de procéder aux arbitrages nécessaires.

Comment anticiper le risque de contentieux ?

Que l’on soit côté client ou prestataire, il est fondamental de réunir et conserver les éléments de preuve susceptibles d’être soumis à un expert (en cas d’expertise avant-dire droit) ou à un juge (en cas d’action en justice) et qui permettront d’établir la réalité des prestations ainsi que l’historique des échanges intervenus avant et pendant le projet (demande de précisions, alertes remontées en comité, échange de mails/courriers, PV de recette, etc.). En effet, un grief qui n’est pas notifié à la partie adverse durant le projet et/ou qui n’est corroboré par aucune pièce datée au moment des faits ne pourra pas être valablement invoqué pour caractériser un manquement.

De même que, pour être exploitables, les comptes-rendus de comités doivent décrire le désordre rencontré, rappeler les circonstances de sa survenance, qualifier son niveau de criticité, préciser ses éventuelles conséquences sur le projet et, le cas échéant, exposer le plan d’actions proposé pour y remédier.

S’agissant des preuves techniques, il est conseillé aux parties de réaliser, lorsque cela est possible, une sauvegarde du système d’information et/ou de l’application incriminée dans sa version existante au moment des faits litigieux. A défaut, les tests réalisés dans le cadre d’une expertise judiciaire avec un matériel ou à partir d’une configuration différente de ceux utilisés à l’époque des faits pourrait affaiblir la demande, voire rendre impossible la démonstration du grief[1].

Idéalement la sauvegarde doit être contradictoire, et ce pour éviter que sa valeur probante ne soit remise en cause par l’autre partie qui aura beau jeu d’en contester l’origine, l’authenticité ou encore la complétude ainsi que l’intégrité des fichiers sauvegardés. Cela étant, un expert pourra examiner une sauvegarde non contradictoire, qui conservera une utilité probatoire, dès lors qu’elle sera soumise à la libre discussion des parties et de l’expert. A noter toutefois qu’un expert judiciaire ou un juge ne pourra se fonder exclusivement sur une sauvegarde non contradictoire.

Les parties auront également intérêt à faire constater par PV de Commissaire de Justice les dysfonctionnements rencontrés : même s’il ne permettra pas à lui seul d’imputer les désordres à l’une ou l’autre des parties, un tel document aura une utilité en cas de litige, notamment pour établir la réalité des désordres et justifier que soit ordonnée une mesure d’expertise.

L’intérêt de préparer en amont un dossier probatoire est d’autant plus grand que les ressources mobilisées sur le projet (surtout pour les projets à longue durée) auront, entre temps, quitté l’entreprise. La conservation des éléments ainsi collectés sera utile dans le cadre d’une expertise et/ou d’un contentieux judiciaire, les parties disposant le moment venu de la « mémoire » du projet.

Préparer un contentieux suppose de s’atteler au volet indemnitaire. S’il est possible d’obtenir une réelle indemnisation, encore faut-il disposer d’un dossier indemnitaire robuste et documenté (tant sur l’identification des chefs de préjudices que sur le chiffrage des dommages). Pour cela, les parties doivent mobiliser en interne les expertises du chiffre (comptabilité et finance) et, éventuellement, recourir à un cabinet d’experts spécialisés en chiffrage de préjudices.

Ces précautions seront utiles, que ce soit pour parvenir à un règlement amiable (cela constitue un levier de négociation pour inciter l’autre partie à transiger), ou dans le cadre d’une procédure judiciaire (les tribunaux exigeant la communication de pièces probantes à l’appui des demandes indemnitaires).

 

Comment gérer une expertise judiciaire ?

La sophistication croissante des architectures techniques ainsi que la multiplicité des acteurs (fabricant, éditeur, intégrateur, maître d’ouvrage et assistant au maître d’ouvrage, etc.) et l’intrication de leurs rôles et responsabilités rend les litiges informatiques de plus en plus complexes. Dans ce contexte, l’expertise est une étape quasi incontournable : elle permet aux parties, avant d’engager une éventuelle action au fond, d’obtenir un éclairage objectif et technique sur la réalité et la qualité des prestations, sur la gestion du projet ou encore sur l’évaluation des préjudices. L’expertise est également utile au Tribunal qui pourra apprécier le contentieux à la lumière des conclusions de l’expert.

Dans le cadre des opérations d’expertise, les parties sont assistées de leur avocat (spécialisé en IT), de leur DSI, des équipes mobilisées sur le projet et, en fonction des enjeux et de la technicité du dossier, d’un expert informatique privé.

Les parties s’échangent des Dires exposant leurs griefs respectifs. Ceux-ci doivent être rattachés à un référentiel de conformité (contrat, cahier des charges, PAQ, etc.), documentés (CR de COPIL, mails, PV de recette, extraction JIRA, journaux de connexion, etc.) et datés.

Au terme de l’expertise, l’expert remet son rapport définitif qui est précédé d’un pré-rapport ainsi que d’un Dire récapitulatif rédigé par chaque partie et qui reprenant de manière synthétique l’ensemble des observations, griefs et réclamations antérieurs.

Si l’avis de l’expert consigné dans le rapport définitif ne lie pas le Tribunal, il constitue néanmoins un document dont le juge fera grand cas.

Enfin, si l’expertise a été ordonnée dans le cadre d’une action au fond, les parties devront, après avoir pris connaissance du rapport, conclure au fond en exploitant les passages du rapport qui leur sont le plus favorables. Dans le cadre d’un référé-expertise, le demandeur à l’expertise pourra, en fonction des conclusions du rapport, décider de déclencher ou non une procédure au fond.

[1] CA Aix-en-Provence, 2^e ch. 22 janv. 2015, n° 12/11557.

Destinée aux dirigeants-actionnaires d’un éditeur de logiciels, cet article est tiré de l’expérience d’Atlantic Finance, cabinet de fusions acquisitions dédié au secteur informatique. Il explore les méthodes de valorisation des entreprises de logiciels, les points d’attention critiques lors d’une cession, et les meilleures pratiques pour maximiser la valeur de l’entreprise. En mettant en lumière les multiples appliqués à l’ARR et à la rentabilité, ainsi que les stratégies pour optimiser une vente, cet article offre un guide précieux pour naviguer avec succès dans le processus de cession d’un éditeur de logiciels.

 

Les points clés à retenir

• La valorisation d’un éditeur repose principalement sur les revenus récurrents (ARR) et la rentabilité.
• Les acquéreurs analysent aussi des critères stratégiques : technologie, marché, équipe et potentiel de croissance.
• Une Vendor Due Diligence (VDD) technologique permet d’identifier les risques techniques, cyber et de propriété intellectuelle avant la vente.
• Les revenus SaaS et contrats récurrents constituent des indicateurs clés de valorisation.
• Un processus de cession organisé avec mise en concurrence améliore généralement les conditions financières de la vente.
• Anticiper la transmission des fonctions clés et structurer les actifs logiciels renforcent l’attractivité de l’entreprise.
• Chaque éditeur présente des spécificités nécessitant une préparation sur mesure du processus de cession.

 

Quelles sont les méthodes de valorisation d’un éditeur de logiciels constatées sur le marché ?

On observe deux types de méthodes pour calculer la valeur d’entreprise : d’une part les calculs avec une logique financière qui correspondent généralement à un multiple de la rentabilité et/ou du revenu récurrent annuel (ARR : Annual Recurring Revenue) duquel on retranche la dette nette ; et d’autre part les calculs avec une logique stratégique (souvent relative aux produits de l’éditeur) qui offrent une prime stratégique à la valeur financière.

Un processus de cession orchestré par un cabinet de fusions acquisitions produit une amélioration significative des conditions, notamment financières, du contrat de cession grâce à la mise en concurrence des différents candidats-acquéreurs.

 

Quels sont les points d’attention métier ?Après avoir estimé une valeur théorique, un candidat-acquéreur va affiner son offre en fonction de points d’attention métiers, opérationnels, relatifs au marché et à son potentiel, au positionnement produit, à la présence ou non de personnes clés.

Qu’est-ce que l’ARR ?

Les revenus récurrents annuels, ou Annual Recurring Revenue (ARR), pris en compte dans les calculs de valorisation d’un éditeur de logiciels sont principalement les contrats d’abonnement SaaS (Software as a Service) et les contrats de Support & Maintenance annuels. Par extension, tout contrat correspondant à un engament contractuel pluriannuel d’un client peut également être pris en considération dans le calcul d’un ARR.

 

Quels multiples sont appliqués à l’ARR ou à la rentabilité ?

Le multiple de l’ARR ou de la rentabilité (Résultat d’exploitation, EBIT, EBE, EBITDA) dépend du profil de la société (sa taille, sa croissance potentielle ou avérée), du potentiel du marché sur lequel elle est présente, du profil de l’acquéreur (selon qu’il porte un intérêt purement financier ou stratégique aux solutions), du format de l’opération (minoritaire ou majoritaire), de l’impact du contexte (process organisé, ou opération de gré à gré), de la conjoncture économique et du marché des fusions acquisitions.

Comment calculer la dette nette ?

La dette nette est retranchée de la valeur d’entreprise (obtenue par calcul – Cf. « Méthodes de valorisation »).

On obtient la dette nette après avoir soustrait la dette financière (les emprunts bancaires, les crédit-baux, les locations financières, les provisions pour risques & charges) à la trésorerie (les disponibilités ainsi que les placements financiers).

 

Quelles sont les meilleures pratiques pour anticiper et maximiser la valeur en vue d’une future cession ?
Compte tenu des méthodes de calcul des valorisations observées, il conviendra de (i) porter une attention particulière à la rentabilité et à l’évolution des revenus récurrents et (ii) anticiper le départ des dirigeants en confiant les tâches clés en interne. La réalisation d’une Vendor Due Diligence (VDD) technologique permet également de rassurer un candidat-acquéreur.

 

En quoi consiste une Vendor Due Diligence technologique ?

La VDD technologique est un process d’audit du logiciel, qui inclut notamment un scan du code source et une analyse de l’infrastructure et de l’architecture IT, et qui va permettre aux dirigeants de l’éditeur de logiciels d’identifier et de corriger les failles et vulnérabilités cachées de son actif en amont d’une vente. La VDD va ainsi exposer d’éventuels risques de cybersécurité, de propriété intellectuelle, de scalabilité et de maintenabilité, qui peuvent affecter la valeur de la vente. Elle va également délivrer un plan d’action permettant à l’éditeur de corriger les failles avant d’entamer la négociation avec l’acquéreur et de présenter un rapport d’audit, émis par un tiers reconnu comme Vaultinum, qui rassurera le futur acquéreur sur la qualité de la technologie qu’il souhaite acquérir.

 

Quelles sont les différentes catégories d’acquéreurs ?

Attirés par les revenus récurrents, stables et long terme des éditeurs de logiciels, différentes familles d’acquéreurs se présentent : les éditeurs de logiciels spécialisés, les sociétés technologiques généralistes, des groupes industriels qui souhaitent accélérer leur transition digitale, des fonds d’investissement et leurs participations, des family offices…

 

Comment vendre ?

On observe deux façons de vendre un éditeur de logiciels.

La première, dite « de gré à gré », consiste à discuter d’une éventuelle cession, après avoir été contacté par un candidat-acquéreur. Dans la plupart des cas, cette démarche est chronophage ; elle a peu de chance d’aboutir et elle est financièrement à la défaveur du cédant. En l’absence de conseil pour le cédant, le candidat-acquéreur n’est pas mis en concurrence ; il n’est pas incité à faire d’effort. Le cédant quant à lui ne connaît la valeur de sa société sur le marché et il n’est pas au fait des us et coutumes dans les transactions de son domaine

La deuxième correspond au processus organisé, cadré par un cabinet de fusions acquisitions dont l’une des principales vertus est de mettre en concurrence plusieurs candidats-acquéreurs, créant ainsi une tension concurrentielle, avec pour objectif d’obtenir les meilleures conditions pour le compte des actionnaires cédants.

 

Préparer la cession d’un éditeur de logiciels pour maximiser sa valeur

Le processus de cession d’un éditeur de logiciel peut s’avérer complexe et fastidieux. Même s’il peut être géré en direct par les dirigeants-actionnaires, il est plutôt conseillé d’être accompagné par un cabinet de fusions acquisitions comme Atlantic Finance, qui se chargera de mettre en concurrence plusieurs acquéreurs, et optimisera la vente de l’entreprise au point de vue financier, juridique et opérationnel.

Mails il est important de réaliser que, plus que dans tout autre domaine, chaque éditeur de logiciels est spécifique. Il convient donc de travailler sur chacun des points clés de son dossier pour préparer en amont son processus de cession.

 

À propos des auteurs

Hervé Camus et Étienne Keller interviennent au sein d’Atlantic Finance, cabinet spécialisé en fusions-acquisitions dédié au secteur informatique et technologique.