Une clause de réversibilité organise la fin d’une prestation informatique : ce que le prestataire remet (code, paramétrages, prompts, données, documentation), dans quel format, sous quel délai et avec quelle assistance, pour confier le système à quelqu’un d’autre sans interrompre l’activité. Elle s’écrit dans le contrat avant le projet, puis se vérifie pendant la prestation.
Ce guide présente les textes officiels et les questions à poser. Il ne remplace pas l’avis d’un avocat ou d’un juriste sur votre contrat.
Qu’est-ce qu’une clause de réversibilité ?
C’est la clause du contrat qui permet à une entreprise de reprendre un système confié à un prestataire, en interne ou chez un autre, sans perte ni coupure. Elle met en œuvre la réversibilité informatique. Le guide de l’ANSSI sur l’externalisation recommande de la prévoir dès le contrat, avec une assistance à la reprise.
La question se pose au moment où l’on choisit un partenaire, pas au moment où l’on part. Un dirigeant qui fait construire une automatisation ou un système d’IA se demande, à juste titre : si on arrête demain, qu’est-ce qu’on garde ? La clause répond par écrit. Ce choix relève de la direction, au même titre que les usages autorisés et les données qui peuvent sortir, comme on le décrit dans la gouvernance de l’IA côté direction.
Réversibilité informatique, propriété, portabilité : trois notions
Les trois mots se croisent souvent dans un contrat, et on les confond facilement.
- La réversibilité est contractuelle : restituer ce qui a été construit et aider à le transférer.
- La propriété porte sur les droits : qui peut modifier le code, le réutiliser, le céder.
- La portabilité est un droit des personnes sur leurs données personnelles, prévu par l’article 20 du RGPD. Elle ne règle pas la sortie d’un prestataire.
Une clause de réversibilité sans clause de propriété peut laisser l’entreprise avec des fichiers qu’elle n’a pas le droit de faire évoluer. Les deux se lisent ensemble.
Pourquoi la question se pose davantage avec l’IA
Dans un projet classique, on pense au code et aux données. Un système d’IA ajoute des pièces moins visibles : les prompts, les jeux de test, les règles métier écrites pour le modèle, les paramétrages de workflow, et des comptes ouverts chez des fournisseurs de modèles ou de cloud. Si l’une de ces pièces reste chez le prestataire, le système ne se reprend pas, même avec tout le code en main.
À qui appartient le code écrit par un prestataire ?
En droit français, les droits patrimoniaux sur un logiciel créé par un salarié dans l’exercice de ses fonctions ou d’après les instructions de son employeur reviennent à l’employeur, sauf dispositions statutaires ou stipulations contraires (article L113-9 du Code de la propriété intellectuelle). Pour un prestataire extérieur, rien de tel n’est prévu : la cession doit être écrite.
L’article L131-3 du même code exige que chaque droit cédé fasse l’objet d’une mention distincte, et que le domaine d’exploitation soit délimité quant à son étendue, sa destination, son lieu et sa durée. Sans cette clause, l’entreprise pourrait n’avoir qu’un droit d’utilisation sur un code qu’elle a pourtant payé. L’effet exact dépend du contrat : c’est à faire vérifier par un conseil.
Code sur mesure et briques réutilisées
Tout le code d’un projet n’a pas le même statut. Les bibliothèques open source gardent leur propre licence. Les composants que le prestataire réutilise d’un client à l’autre font plutôt l’objet d’une licence d’utilisation. Le code écrit pour vous peut être cédé. Le contrat gagne à distinguer les trois, liste à l’appui.
Le code source, pas seulement l’exécutable
Posséder des droits sur un code qu’on n’a pas sous la main ne sert à rien. On demande l’accès au dépôt de code, avec son historique, la documentation d’installation et la liste des dépendances. Un repreneur doit pouvoir réinstaller le système à partir de ces seuls éléments.
Et les prompts, les règles et les paramétrages ?
Leur statut juridique n’est pas tranché de façon générale, et on évite de l’affirmer. La voie sûre est contractuelle : lister les prompts, les jeux de test, les règles métier, les paramétrages de workflow et les schémas de données parmi les livrables remis à l’entreprise. Les comptes chez les fournisseurs d’IA et de cloud gagnent à être ouverts à son nom.
Le modèle d’IA lui-même reste la propriété de son fournisseur : l’entreprise en a l’usage selon les conditions de ce fournisseur. Les règles, elles, sont à vous si elles sont écrites. C’est l’intérêt de formaliser un processus avant de l’automatiser.
Dans nos projets, l’objectif de fin de projet est simple : le client doit pouvoir exploiter, faire évoluer et maintenir le système sans dépendre de nous. On remet donc :
- les briques mises en place (connecteurs, extensions, compétences de l’agent), installées dans l’environnement du client et documentées ;
- une cartographie des processus avant et après, avec le temps gagné sur chaque étape ;
- des procédures de modification et de reprise, qui expliquent comment faire évoluer le système sans nous ;
- les accès et les comptes au nom du client, et l’inventaire des outils utilisés avec leurs coûts récurrents.
Vous ne savez pas exactement ce que vous récupéreriez si votre prestataire actuel s’arrêtait demain ? On en parle 30 minutes, sans analyse juridique du contrat.
Parlons de votre transformation
Les données : restitution, suppression et changement de fournisseur
Si le prestataire traite des données personnelles pour vous, l’article 28 du RGPD prévoit qu’en fin de prestation il les supprime ou vous les renvoie, à votre choix, et détruit les copies existantes, sauf obligation légale de les conserver. Pour les services cloud et SaaS, le Data Act européen encadre depuis le 12 septembre 2025 le changement de fournisseur.
Les données personnelles : l’article 28 du RGPD
Le contrat de sous-traitance doit prévoir le sort des données en fin de prestation (article 28, paragraphe 3, point g) du RGPD). La CNIL publie un exemple de clauses de sous-traitance, avec une clause sur le sort des données, qui sert de base de discussion. Le guide IA et RGPD détaille ce que le RGPD impose à un fournisseur dans une automatisation.
Les services cloud : le Data Act
Le règlement (UE) 2023/2854, dit Data Act, s’applique depuis le 12 septembre 2025. Son chapitre VI vise les fournisseurs de services de traitement de données, comme le cloud et le SaaS : droits du client écrits dans le contrat, préavis de changement, période transitoire d’assistance. Son article 29 prévoit qu’à compter du 12 janvier 2027, ces fournisseurs ne pourront plus facturer de frais de changement de fournisseur. Savoir si un prestataire d’automatisation relève de ces règles dépend de ce qu’il fournit : c’est à vérifier avec un conseil.
Le format de restitution
Une restitution utile, ce sont des données lisibles par un autre outil, avec leur description : champs, unités, référentiels, date d’extraction. Un export illisible sans le logiciel d’origine ne permet pas de reprendre. On décrit nos propres pratiques sur la page sécurité et données chez Klaryx.
Ce qu’une clause de réversibilité doit prévoir
Une clause de réversibilité utile liste ce qui sera remis, dans quel format, sous quel délai et avec quelle assistance. Elle fixe aussi le préavis, la période de fonctionnement en parallèle, le coût éventuel et le sort des comptes et des accès. Un plan de réversibilité détaille ensuite les étapes concrètes de la sortie.
Pour un contrat informatique, la liste des points à couvrir tient en quelques lignes :
- Le déclenchement : à quel moment la réversibilité peut être demandée (fin normale, résiliation, demande en cours de contrat) et avec quel préavis.
- Les livrables : code source, documentation, paramétrages, scripts, prompts, jeux de test, règles métier, données.
- Le format : formats ouverts ou documentés, description des données.
- Le délai : la date à laquelle tout doit être remis.
- L’assistance : combien de temps le prestataire aide le repreneur, et comment.
- Le fonctionnement en parallèle : une période où l’ancien et le nouveau système tournent ensemble, si l’activité l’exige.
- Le coût : inclus dans le contrat ou facturé, et sur quelle base.
- Les comptes et les accès : transfert, puis changement des mots de passe et des clés.
- La suppression : destruction des copies chez le prestataire, confirmée par écrit.
On ne propose pas ici de modèle de clause : sa rédaction dépend du contrat et se fait avec un conseil.
Dans les marchés publics
Les acheteurs publics disposent d’un repère : le cahier des clauses administratives générales des marchés de techniques de l’information et de la communication (CCAG-TIC, arrêté du 30 mars 2021) prévoit des stipulations sur la réversibilité. Ce régime ne s’applique pas aux contrats entre entreprises privées, mais sa liste de livrables est une bonne grille de lecture.
Plan de réversibilité : quitter un prestataire, étape par étape
Le plan de réversibilité écrit la sortie à l’avance. On relit le contrat et on donne le préavis prévu, puis on inventorie ce qui doit être remis, on transfère les comptes et les accès, on récupère le code, la documentation et les données, on fonctionne en parallèle avec le repreneur, et on obtient la confirmation écrite de suppression.
Le plan précise pour chaque étape qui fait quoi, quand, et à quel signe on considère l’étape terminée. Le référentiel SecNumCloud de l’ANSSI (version 3.2, chapitre 19.1) impose aux offres cloud qualifiées une clause de réversibilité : le client doit pouvoir récupérer l’ensemble de ses données, dans des formats documentés ou par une interface.
- Relire le contrat et notifier (entreprise) : préavis, livrables, assistance, coût, puis demande dans les formes prévues.
- Inventorier (ancien prestataire, avec l’entreprise) : liste complète des livrables, des comptes et des accès.
- Transférer les comptes (ancien prestataire) : fournisseurs d’IA, cloud, dépôt de code, outils de workflow.
- Remettre le code, la documentation et les données (ancien prestataire), dans les formats convenus.
- Réinstaller, tester et fonctionner en parallèle (repreneur, avec l’ancien prestataire) : à partir de la documentation et des jeux de test, le temps de vérifier les résultats.
- Fermer (entreprise) : changer les mots de passe et les clés, obtenir la confirmation écrite de suppression.
Quand on reprend un système monté par un tiers, il manque le plus souvent la cartographie et les procédures de reprise : sans elles, l’outil s’arrête à la première panne. Une cartographie des processus tenue à jour évite ce trou.
Choisir un système qu’on peut reprendre : la réversibilité dès le cadrage
La réversibilité se prépare au cadrage, pas au moment de partir. Un système construit dans vos outils, sur des comptes à votre nom, avec un code documenté et des règles écrites, se reprend sans drame. C’est un critère de choix au même titre que le délai, et il se vérifie avant de lancer l’automatisation d’un processus.
On décrit notre propre engagement sur la page méthode Klaryx. Pour la construction, on détaille la transformation d’un processus que vous pouvez reprendre. Un contrat pour faire suivre le système après la livraison reste possible, par exemple quand un changement de processus voisin touche le système, mais il est optionnel : le travail livré est documenté et reproductible, et le client doit pouvoir avancer seul.
Pour aller plus loin
- Gouvernance de l’IA côté direction : qui décide des outils, des données et des comptes.
- IA et RGPD : ce que le RGPD impose quand un fournisseur traite des données personnelles.
- Formaliser un processus : écrire les règles avant de les automatiser.
Vous préparez un projet d’automatisation et voulez que le système reste le vôtre dès le départ ? Parlons de ce qu’il faudrait livrer et documenter, en 30 minutes.