Les clauses de sortie dans les contrats informatiques : négocier le contrat et la sortie

Lors de la conclusion d’un contrat informatique, les parties pensent rarement à sa résiliation. L’attention se concentre sur le périmètre, le prix, le calendrier et les plans de mise en œuvre. Anticiper la fin de la collaboration avant même qu’elle ait commencé paraît contre-intuitif. La phase de sortie et la transition nécessaire vers une solution alternative sont souvent négligées ou considérées comme un sujet à régler ultérieurement. Dans la pratique, cela engendre régulièrement des problèmes : des organisations se retrouvent démunies lorsqu’une transition s’impose, ou sont contraintes de poursuivre la relation avec un fournisseur plus longtemps que souhaité (vendor lock-in).

Une chose est pourtant certaine dans toute collaboration informatique : elle se terminera un jour. Qu’il s’agisse d’une résiliation, d’une inexécution contractuelle, d’une faillite ou d’un passage à une nouvelle solution, la sortie est inévitable. Celui qui n’organise la sortie qu’au moment de la résiliation part d’une position de faiblesse : la relation est souvent dégradée, les intérêts divergent et le fournisseur n’a que peu d’incitation à coopérer de manière constructive. Une clause de sortie bien conçue n’est donc pas un luxe, mais un élément essentiel de tout contrat informatique.

Les défis d’une sortie informatique sont plus nombreux qu’il n’y paraît au premier abord. En voici les principaux :

• Données et migration : Où se trouvent les données, dans quel format sont-elles disponibles, et comment le client peut-il les récupérer ? Qui supporte les coûts de migration et comment les rôles sont-ils répartis ?
• Connaissance et documentation : Les descriptions d’architecture, les configurations et le savoir-faire spécifique se trouvent souvent exclusivement chez le fournisseur, parfois même auprès de personnes clés. Il est donc essentiel que le client puisse exiger contractuellement ces informations lorsqu’il en a besoin, et qu’il ait accès à l’expertise nécessaire pendant la période de transition, de préférence via un interlocuteur dédié chez le fournisseur.
• Codes sources : Pour les solutions sur mesure, la disponibilité du code source est indispensable afin que le client puisse apporter des modifications de manière autonome. Pour les logiciels standard, le code source permet, après la faillite du fournisseur (concédant de licence), de continuer à utiliser le logiciel pendant une période transitoire et d’effectuer les adaptations nécessaires. Pour les solutions sur mesure où la propriété intellectuelle est transférée au client, le code source est généralement remis en tant que livrable. Pour les logiciels standard, ce n’est pas le cas, mais le code source peut avoir été confié à un tiers dans le cadre d’un accord d’escrow tripartite (source code escrow), lequel libérera le code en cas de faillite. Cette solution peut convenir pour les logiciels « on premises » que le client détient physiquement. Pour le SaaS, la situation est différente : sans accès à l’environnement cloud, le code source est en pratique inutilisable. Un SaaS-escrow va plus loin : il implique la reprise de l’environnement d’hébergement cloud avec transfert du compte, des configurations, des outils de gestion et de l’accès aux données. Un tel dispositif est envisageable dans un environnement single-tenant, mais sera problématique dans un environnement multi-tenant où d’autres entreprises, voire des concurrents, sont également clients. Des solutions créatives s’imposent alors, notamment lorsque le fournisseur présente une fragilité financière.
• Licences et « background IP » : Lorsqu’une solution informatique repose sur des licences tierces, il convient de vérifier si ces licences restent nécessaires après la résiliation du contrat, et si leur transfert au client ou à un fournisseur successeur est possible. Par ailleurs, le client peut avoir besoin de continuer à utiliser le « background IP » du fournisseur — c’est-à-dire les logiciels du fournisseur sur lesquels le client a obtenu un droit d’usage durable et pour lesquels il doit disposer de droits de modification, par exemple pour permettre l’intégration avec le logiciel du nouveau fournisseur. Ces droits de modification doivent être expressément convenus lors de la conclusion du contrat, car ils vont au-delà d’un simple droit d’utilisation.
• Délais de préavis : Pour des systèmes complexes, tels qu’un ERP, une migration réaliste peut nécessiter un à deux ans. Le client doit sélectionner une solution alternative, négocier et la mettre en œuvre, souvent avec d’importants développements spécifiques. Les délais de préavis contractuels doivent donc être suffisamment longs pour permettre une transition opérationnelle. Il peut être judicieux de prévoir une option contractuelle permettant au client de prolonger le délai de préavis si nécessaire, par exemple de 3 à 6 mois.
• Accompagnement à la transition : Le fournisseur existant doit activement coopérer au passage vers un successeur. Dans la pratique, cela ne va pas de soi, surtout lorsque la relation est tendue ou qu’un concurrent reprend le système. La réticence à partager le savoir-faire et les droits de propriété intellectuelle est fréquente. Si la coopération du fournisseur est nécessaire, cela doit être expressément et concrètement prévu dans le contrat dès le début du projet. Une fois le contrat résilié, la position de négociation du client est considérablement affaiblie.
• L’aspect financier de la sortie : En l’absence d’accord préalable sur le prix des prestations d’accompagnement à la sortie, le fournisseur facturera généralement ses services sur la base de tarifs journaliers, souvent depuis une position de négociation favorable. Fixer ces éléments contractuellement à l’avance permet d’éviter bien des discussions ultérieures.

Depuis l’entrée en vigueur du règlement européen sur les données (Data Act, règlement (UE) 2023/2854) le 12 septembre 2025, les fournisseurs de services cloud (dont les fournisseurs SaaS, PaaS et IaaS) sont tenus d’accompagner leurs clients lors d’un changement de prestataire.

Les clients peuvent initier le processus de changement moyennant un préavis maximal de deux mois. Le fournisseur doit ensuite procéder sans délai au transfert de l’ensemble des données exportables et des actifs numériques, et en tout cas dans les trente jours suivant l’expiration de ce préavis. La durée totale maximale du processus de changement est donc d’environ trois mois. Les données doivent être fournies dans un format structuré, courant et lisible par machine, ou conformément à des spécifications ouvertes d’interopérabilité et à des normes européennes harmonisées. Les fournisseurs sont également tenus de mettre à disposition, gratuitement, des interfaces ouvertes permettant la portabilité des données et l’interopérabilité avec un nouveau prestataire. Tant que les données n’ont pas été transférées ou supprimées, le client doit disposer de suffisamment de temps pour récupérer ou exporter ses données.

L’article 29 du règlement oblige en outre les fournisseurs cloud à supprimer progressivement les frais de changement. Jusqu’au 12 janvier 2027, seuls les coûts directement liés au processus de changement peuvent être facturés ; au-delà, ces frais seront totalement interdits (sauf prestations de conseil véritables ou assistance étendue à la migration). Ces règles s’appliquent également aux contrats existants.

Pour les entités financières, la stratégie de sortie n’est pas une option, mais une obligation légale. L’article 28, paragraphe 8, du règlement sur la résilience opérationnelle numérique (DORA), applicable depuis le 17 janvier 2025, oblige les entités financières à élaborer des stratégies de sortie pour tous les services TIC soutenant des fonctions critiques ou importantes. Ces stratégies doivent être documentées, testées périodiquement et contenir des plans de transition concrets. L’entité financière doit être en mesure de démontrer que la résiliation d’un contrat informatique ne provoque pas d’interruption des activités, n’entraîne pas de violation des obligations réglementaires et n’a pas d’impact négatif sur les services aux clients. Les entités financières qui n’ont pas encore adapté leurs contrats informatiques à ces exigences sont déjà exposées à un risque de non-conformité.

Lorsque peu ou rien n’a été prévu contractuellement sur la sortie, le droit belge peut offrir une protection. L’article IV.2/1 du Code de droit économique interdit l’abus de dépendance économique. Tel est le cas lorsqu’un fournisseur exploite le fait que le client ne dispose pas d’alternative équivalente raisonnable et lui impose unilatéralement des conditions (telles que des indemnités de sortie excessives ou un refus de coopérer) qui ne seraient pas acceptables dans des conditions de marché normales.

Cette réglementation est entrée en vigueur le 1er décembre 2020 dans le cadre de la législation B2B. Toutefois, le seuil d’application est élevé : il doit y avoir une position de dominance relative et un abus susceptible d’affecter la concurrence. Ce filet de sécurité légal ne dispense donc pas les parties de la nécessité de prévoir des clauses de sortie dès la conclusion du contrat. Il peut tout au plus constituer un remède en l’absence de cette préparation, non un substitut.

Une clause de sortie bien conçue dans un contrat informatique doit contenir au minimum les éléments suivants :

• Plan de sortie : élaboré lors de la conclusion du contrat et non au moment de la résiliation, avec un calendrier clair et une répartition des responsabilités ;
• Restitution et suppression des données : dispositions sur le format, les délais, l’assistance à la migration et les durées maximales de conservation chez le fournisseur, en conformité avec le Data Act ;
• Tarifs convenus pour l’accompagnement à la transition : tarifs fixes ou plafonnés pour les prestations complémentaires durant la phase de sortie ;
• Délais de préavis adaptés : calibrés sur la durée réaliste de migration, éventuellement assortis d’une option de prolongation contractuelle ;
• Escrow du code source ou SaaS-escrow : selon le modèle de livraison ;
• Clarification des droits de propriété intellectuelle : accord sur l’usage continu du background IP du fournisseur, y compris éventuels droits de modification ;
• Coopération du personnel clé : obligation pour le fournisseur de mettre à disposition des collaborateurs spécifiques pour le transfert de connaissance ;
• Pour les entités financières : un plan de sortie formel conforme à l’article 28 de DORA, incluant documentation, tests et solutions alternatives.

Un contrat informatique dépourvu de clause de sortie peut fonctionner parfaitement tant que tout se passe bien. Mais au moment où le client souhaite ou doit mettre fin à la relation, il se retrouve démuni et contraint de négocier depuis une position de dépendance. Il est donc primordial, lors de toute conclusion de contrat, de réfléchir dès le départ aux aspects susceptibles d’être déterminants lorsqu’une transition vers un nouveau fournisseur deviendra nécessaire.

Auteurs

Stefan Van Camp et Edwin Jacobs, Timelex