
Depuis le 12 septembre 2025, le règlement européen sur les données, dit Data Act, impose aux fournisseurs de services cloud — y compris les éditeurs SaaS — de supprimer les obstacles commerciaux, techniques, contractuels et organisationnels qui entravent le changement de fournisseur. Cette obligation légale, déjà en vigueur, vient désormais s'ajouter à la négociation contractuelle classique de la réversibilité, sans pour autant la rendre superflue : le Data Act encadre le principe et les délais du changement de fournisseur, mais ne dispense pas de préciser contractuellement le périmètre exact des données restituables, leurs formats ou les modalités concrètes de l'assistance du prestataire.
La clause de réversibilité d'un contrat SaaS organise la restitution, le transfert ou la migration des données, des paramétrages et, le cas échéant, de la documentation technique en cas de fin de contrat, de résiliation anticipée, de non-renouvellement ou de défaillance du fournisseur. Elle vise à garantir la continuité d'activité du client et à limiter sa dépendance technologique. Aucune loi française n'impose, en droit privé, une telle clause dans un contrat SaaS — le dispositif reste donc largement contractuel, sauf en marchés publics où le CCAG-TIC impose un plan de réversibilité. Cet article détaille le périmètre à négocier, les modalités opérationnelles de la sortie, et l'impact du Data Act sur les pratiques contractuelles actuelles.
Une formule générique du type « les données du client » constitue, en pratique, le principal point de fragilité des clauses de réversibilité rencontrées dans les contrats SaaS standards.
Le périmètre doit inclure explicitement les données métier — clients, factures, dossiers, documents —, les données de configuration et de paramétrage, les historiques et journaux d'activité, les métadonnées, les données de référence, ainsi que les sauvegardes et les données archivées. Il est recommandé de distinguer, au sein de cet ensemble, les données brutes, les données transformées, les données dérivées, les données agrégées et les données anonymisées, dont le régime de restitution peut légitimement différer selon leur nature et leur origine.
La clause doit également prévoir la restitution des règles métier, des workflows configurés, des profils utilisateurs, des rôles et habilitations, des modèles de documents et templates, ainsi que des configurations d'intégration, mappings et connecteurs mis en place pour le client. La documentation à restituer peut comprendre la documentation technique et fonctionnelle, les manuels d'utilisation, les procédures d'exploitation, les schémas d'architecture et les inventaires de composants — autant d'éléments sans lesquels la seule récupération des données brutes ne permet pas une migration réellement opérationnelle.
Un point de vigilance mérite d'être souligné : dans un SaaS standard, le code source du socle applicatif n'est généralement pas restitué au client, celui-ci n'ayant souscrit qu'à un droit d'usage du service et non à la propriété du logiciel sous-jacent. Seuls les éventuels développements spécifiques réalisés pour le client peuvent, selon la clause de propriété intellectuelle négociée, faire l'objet d'une restitution du code source correspondant. La distinction entre cession et licence sur ce type de développement est détaillée dans notre article consacré à la propriété du code source développé par un prestataire.
La clause doit identifier précisément les situations dans lesquelles le client peut activer le mécanisme de réversibilité, ce déclenchement pouvant intervenir dans des circonstances très différentes selon qu'il s'agit d'une fin de contrat maîtrisée ou d'une défaillance subie du prestataire.
La propriété des données ne suffit pas si leur format de restitution rend, en pratique, toute migration impossible ou disproportionnément coûteuse à mettre en œuvre.
Il est recommandé de prévoir des formats structurés, lisibles par machine, documentés et interopérables — CSV, JSON, XML, SQL, XLSX pour les données, PDF pour la documentation, ou tout autre format standard reconnu dans le secteur d'activité concerné. Un format propriétaire lisible uniquement par les outils de l'éditeur constitue, en lui-même, un facteur de dépendance technologique susceptible de neutraliser en pratique l'intérêt de toute clause de réversibilité par ailleurs correctement rédigée.
Il est utile de prévoir, en cours d'exécution du contrat, un test d'export permettant au client de valider concrètement la structure et la complétude des données qui lui seraient restituées, plutôt que de découvrir leur inexploitabilité au moment critique de la sortie. Une procédure de recette de la réversibilité, assortie d'un droit de vérifier l'intégrité des données exportées, permet de sécuriser ce point en amont de tout litige.
Ces deux paramètres, souvent négligés lors de la signature initiale du contrat, deviennent déterminants au moment précis où le client a le plus besoin de rapidité et de prévisibilité.
Il convient de distinguer le délai de déclenchement — le moment où le prestataire doit commencer les opérations de restitution, généralement fixé à la notification de la résiliation ou à la fin du préavis contractuel — du délai de restitution proprement dit, correspondant à la durée maximale accordée pour la remise de l'ensemble des éléments. Les pratiques observées retiennent généralement trente jours pour un périmètre simple, quarante-cinq à soixante jours pour un périmètre standard, et jusqu'à quatre-vingt-dix jours pour un environnement particulièrement complexe.
Le contrat peut prévoir une réversibilité incluse dans le prix de l'abonnement, une facturation au temps passé, ou un forfait déterminé à l'avance. Le tableau suivant compare ces trois approches.
Une clause de réversibilité qui n'organise que la restitution des fichiers, sans assistance ni continuité de service, reste largement théorique une fois confrontée à la réalité opérationnelle d'une migration.
Le contrat doit prévoir la mise à disposition d'interfaces d'export, la documentation précise des formats utilisés, une assistance à l'import chez le nouveau prestataire et la transmission des connaissances relatives aux paramétrages spécifiques mis en place pour le client. Cette assistance fonctionnelle, souvent négligée au profit du seul volet technique, conditionne pourtant directement la rapidité avec laquelle le client pourra redevenir opérationnel sur son nouvel outil.
Il est recommandé de maintenir les niveaux de service contractuels, la sécurité et les sauvegardes pendant toute la durée de la période de transition, plutôt que de considérer la phase de réversibilité comme une parenthèse échappant aux engagements habituels du prestataire. Un plan de réversibilité annexé au contrat, prévoyant des jalons, des tests de recette intermédiaires et des critères de succès objectifs, permet de structurer cette phase souvent sous tension entre les parties.
La réversibilité ne s'achève pas à la restitution des données : elle implique symétriquement une obligation de destruction vérifiable des données conservées côté prestataire.
Le contrat doit préciser le délai de destruction applicable après la restitution, prévoir une attestation ou un certificat de destruction signé par le prestataire, et organiser les exceptions légitimes à cette obligation, notamment pour les données que le prestataire doit conserver au titre d'une obligation légale propre. S'agissant des données à caractère personnel, l'article 28 du RGPD impose déjà, en fin de prestation de sous-traitance, la suppression ou la restitution des données au choix du responsable de traitement, ainsi que la destruction des copies existantes, sauf obligation légale de conservation contraire — cette exigence rejoignant directement celle de la clause de réversibilité proprement contractuelle.
Ce règlement européen transforme progressivement la réversibilité d'un simple point de négociation contractuelle en une obligation légale directement opposable au fournisseur de services cloud.
Depuis le 12 septembre 2025, les fournisseurs de services cloud — y compris les éditeurs SaaS — doivent supprimer les obstacles commerciaux, techniques, contractuels et organisationnels qui entravent le changement de fournisseur, en application du chapitre VI du règlement (UE) 2023/2854. Le client peut désormais résilier son contrat à tout moment moyennant un préavis raisonnable, plafonné à deux mois, suivi d'une période de transition en principe limitée à trente jours calendaires. Si le fournisseur estime cette durée techniquement irréalisable, il doit le signaler dans les quatorze premiers jours du préavis et peut alors proposer une période alternative, qui ne peut toutefois pas excéder sept mois.
Jusqu'au 12 janvier 2027, les frais de changement de fournisseur doivent déjà rester limités aux coûts effectivement supportés par le fournisseur pour réaliser l'opération de migration. À compter de cette date, ces frais seront purement et simplement supprimés pour les opérations de changement de fournisseur classiques, incluant les frais de transfert de données, les frais de résiliation anticipée liés spécifiquement au changement, et tout autre coût imposé par le fournisseur d'origine en raison de ce changement.
Une exception mérite d'être anticipée par les entreprises recourant à des architectures multicloud : des frais de sortie pourront subsister même après le 12 janvier 2027 lorsque le client transfère régulièrement des données entre deux fournisseurs différents, la Commission européenne justifiant cette exception par le caractère récurrent, et non ponctuel, des transferts en jeu dans ce type d'architecture. Le Data Act ne rend donc pas la migration cloud gratuite dans l'absolu : les coûts de conseil, d'ingénierie, d'adaptation applicative, de double exploitation ou de formation restent, quant à eux, à la charge du client.
La clause de réversibilité organise la restitution, le transfert ou la migration des données, des paramétrages et de la documentation en cas de fin de contrat SaaS. Aucune loi française n'impose cette clause en droit privé, mais le Data Act impose, depuis le 12 septembre 2025, aux fournisseurs de services cloud de supprimer les obstacles au changement de fournisseur, ce qui rejoint en pratique une partie de ses objectifs.
Le prestataire doit restituer les données métier, les données de configuration, les historiques et journaux d'activité, ainsi que les paramétrages, workflows et modèles de documents. La documentation technique et fonctionnelle doit également être restituée pour permettre une migration réellement exploitable, et non une simple récupération de données brutes.
En principe, non. Le client d'un SaaS standard ne bénéficie que d'un droit d'usage du service et non de la propriété du logiciel sous-jacent, dont le code source n'est donc généralement pas restitué. Seuls les développements spécifiques éventuellement réalisés pour le client peuvent faire l'objet d'une restitution, selon les termes de la clause de propriété intellectuelle négociée.
Les pratiques contractuelles retiennent généralement trente jours pour un périmètre simple, quarante-cinq à soixante jours pour un périmètre standard, et jusqu'à quatre-vingt-dix jours pour un environnement complexe. Le Data Act prévoit, de son côté, une période de transition de principe de trente jours, extensible jusqu'à sept mois si le fournisseur justifie d'une contrainte technique particulière.
Pas encore totalement. Depuis le 11 janvier 2024, ces frais doivent être limités aux coûts réellement supportés par le fournisseur, mais leur suppression complète pour les opérations de changement de fournisseur classiques n'interviendra qu'à compter du 12 janvier 2027, sous réserve de l'exception applicable aux architectures multicloud.
Le client reste en principe propriétaire de l'intégralité de ses données, le prestataire ne disposant que d'une licence d'exploitation limitée à la fourniture du service, à sa maintenance et à sa sécurisation. Cette licence doit exclure tout usage des données à des fins propres, toute revente, et tout transfert à des tiers non autorisés.
Oui, c'est précisément l'une des hypothèses où elle est la plus nécessaire, et la plus délicate à exécuter puisque le prestataire n'est alors plus en mesure de coopérer activement. C'est pourquoi il est recommandé de prévoir des mécanismes ne dépendant pas de sa coopération volontaire, tels qu'un dépôt séquestre des éléments techniques essentiels ou un accès de secours pré-configuré au bénéfice du client.
Cela dépend du contrat : certains prestataires incluent la réversibilité dans le prix de l'abonnement, d'autres la facturent au forfait ou au temps passé. Le Data Act encadre déjà les frais de changement de fournisseur en les limitant aux coûts réellement supportés, avant leur suppression complète prévue au 12 janvier 2027 pour les opérations de switching classiques.
Elle doit être restituée au même titre que les données, dans la mesure où une migration réellement opérationnelle suppose de comprendre les paramétrages, workflows et règles métier mis en place, et non uniquement de récupérer des fichiers de données bruts.
Il est recommandé de prévoir, en cours de contrat, un test d'export périodique et une procédure de recette de la réversibilité, permettant au client de valider la structure et l'intégrité des données avant d'être placé en situation de dépendance au moment de la sortie effective.
Une clause de réversibilité efficace ne se limite pas à un engagement de principe : elle précise le périmètre exact des actifs restituables, impose des formats réellement exploitables, fixe des délais réalistes et organise une assistance opérationnelle concrète du prestataire, désormais renforcée par le cadre contraignant du Data Act depuis septembre 2025. Cette exigence de précision rejoint directement celle développée dans nos articles sur la propriété du code source développé par un prestataire et sur les SLA, pénalités et plafonnement, deux sujets connexes qui structurent, avec la réversibilité, l'ensemble du cycle de vie d'un contrat de service informatique.
Article rédigé sur la base de l'état du droit disponible à la date de publication.