Table des matières :
- Pourquoi le Data Act rend la portabilité cloud et SaaS opérationnelle depuis 2025
- Portabilité, réversibilité et RGPD : ce que le Data Act ajoute (et ce qu’il ne remplace pas)
- Ce que le Data Act implique techniquement : données exportables, interfaces et tests
- Clauses à exiger dans les contrats cloud et SaaS : délais, assistance, frais et chaîne de sous-traitance
- Sécurité de la portabilité : chiffrement, clés, traces et données sensibles
- Une feuille de route pragmatique pour exploiter le Data Act (PME, ETI, secteur public)
Pourquoi le Data Act rend la portabilité cloud et SaaS opérationnelle depuis 2025
Depuis le 12 septembre 2025, le Data Act est applicable dans l’Union européenne, conformément au règlement (UE) 2023/2854 du 13 décembre 2023, publié au Journal officiel de l’UE le 22 décembre 2023 (texte accessible sur EUR-Lex : règlement (UE) 2023/2854 sur EUR-Lex). Pour les décideurs, l’enjeu n’est pas de « changer de cloud » par principe, mais de réduire les frictions quand un changement devient nécessaire : fin de contrat, exigence d’un client, incident majeur ou standardisation d’un parc.
Concrètement, le calendrier « politique » se transforme en calendrier opérationnel : depuis l’entrée en application du règlement, les demandes de réversibilité ne relèvent plus uniquement de la bonne volonté commerciale. Elles concernent aussi la conception du service, le contrat et les éléments de preuve. Cela change la posture côté client : au lieu de négocier une clause générique (« réversibilité : oui »), vous pouvez demander des mécanismes testables (formats, API, délais, assistance) et les inscrire comme critères d’acceptation.
Le texte cible notamment les services de traitement de données — au sens large, des services fournissant à la demande des ressources informatiques — parmi lesquels figurent des services d’infrastructure, de plateforme et de logiciel accessibles en ligne. Un SaaS (Software as a Service) est un logiciel accessible via Internet, administré par le fournisseur, dont l’organisation cliente utilise les fonctions sans gérer l’infrastructure sous-jacente. Cette approche peut créer des dépendances peu visibles : modèles de données propriétaires, journaux d’audit non exportables ou règles métiers difficiles à reconstruire.
Il est utile de clarifier un point de vocabulaire : dans la pratique, la « portabilité » ne se limite pas à l’export de tables. Pour un SaaS, la valeur est souvent aussi dans l’état applicatif (workflows, droits, modèles de tickets, automatisations, champs personnalisés, référentiels) et dans les éléments de preuve (journaux, horodatages, historiques). Toutefois, le Data Act ne garantit pas que tous ces éléments soient exportables : le périmètre dépend notamment de la définition des données exportables et des exclusions prévues par le règlement. Il convient donc de le préciser dans le contrat.
Dès que l’on parle de portabilité, quatre notions doivent être distinguées dès le départ. L’hébergement désigne le stockage de données et l’exécution de traitements sur une infrastructure opérée par un prestataire. Le lieu de stockage peut varier selon les données, les sauvegardes et les traitements. Le droit applicable désigne les règles de droit régissant le contrat ; la juridiction compétente désigne les tribunaux susceptibles de connaître d’un litige. La maîtrise du modèle est la capacité à configurer, auditer, mettre à jour ou remplacer un modèle d’IA sans dépendre d’un tiers pour les paramètres essentiels. La réversibilité est la capacité contractuelle et opérationnelle à quitter un service en récupérant données, configurations et éléments de preuve, dans des délais, à des coûts et selon des conditions de sécurité maîtrisés.
Une manière simple de rendre ces notions actionnables est de les traduire en questions de pilotage :
- Hébergement : où sont les données (région, sauvegardes, archives) et où transitent-elles lors d’un export ?
- Droit applicable et juridiction : quelles règles et quels tribunaux sont prévus au contrat ? Quels moyens de preuve, recours et mécanismes de résolution sont prévus si une clause de sortie n’est pas respectée ?
- Maîtrise du modèle / paramétrage : puis-je reconstituer l’essentiel des règles (mapping, scoring, routage, modèles) ailleurs ?
- Réversibilité : combien de temps, combien d’effort, combien d’erreurs acceptables — et comment le vérifier avant la crise ?
Portabilité, réversibilité et RGPD : ce que le Data Act ajoute (et ce qu’il ne remplace pas)
La portabilité des données désigne la capacité à transférer un ensemble de données et d’actifs associés vers un autre service, de manière exploitable, sans ressaisie manuelle et sans rupture excessive. La réversibilité, elle, englobe la portabilité mais ajoute les aspects de continuité : scénarios de bascule, assistance, délais, responsabilités et traitement des données résiduelles. Dans un contexte cloud et SaaS, la portabilité « pure » (un export) est rarement suffisante si l’on vise une reprise en production.
Une erreur fréquente est de limiter la réversibilité aux « données métier ». Or, dans une sortie SaaS, les paramétrages et les éléments de conformité peuvent coûter cher à reconstruire (rôles, droits, groupes, politiques de rétention, règles d’anonymisation ou de purge, journalisation). Demander explicitement leur restitution — ou, au minimum, leur description complète et versionnée — peut réduire l’effort de reconfiguration chez un autre fournisseur. Il faut toutefois vérifier pour chaque élément s’il entre dans le périmètre des données exportables au sens du Data Act ou s’il doit être prévu contractuellement.
Il est utile de ne pas confondre ces mécanismes avec le droit à la portabilité du RGPD. Le RGPD (règlement (UE) 2016/679) confère aux personnes concernées, sous certaines conditions, le droit de recevoir les données à caractère personnel les concernant qu’elles ont fournies à un responsable du traitement et de les transmettre à un autre responsable. Le Data Act organise, entre autres, les conditions de changement de fournisseur et l’accès à certains jeux de données dans un cadre économique. Dans les services d’IA et d’analytique, vous manipulez souvent des données mixtes (personnelles et non personnelles) : vous devez donc traiter la portabilité comme un sujet à la fois technique (formats, interfaces) et contractuel (sous-traitance, sécurité).
Sur le plan contractuel, le Data Act ne remplace pas les obligations de sous-traitance du RGPD. En pratique, une clause de sortie doit s’articuler avec le contrat de sous-traitance et ses exigences de sécurité, d’assistance et de restitution. Pour cadrer ce point, la lecture de l’article sur les clauses essentielles d’un contrat de sous-traitance reste une base utile : Article 28 RGPD : clauses clés du contrat de sous-traitance.
Dans les organisations françaises (PME/ETI/secteur public), une difficulté récurrente est la coexistence de plusieurs cadres : RGPD, exigences internes (SSI, PSSI), parfois des référentiels sectoriels (ex. HDS pour l’hébergement de données de santé), et obligations de portabilité ou de réversibilité qui doivent rester compatibles avec ces contraintes. Le bon réflexe consiste à traiter la sortie comme un processus gouverné : qui la déclenche, qui la valide, quelles traces sont produites, quelle fenêtre de maintenance est prévue et comment les incidents sont gérés pendant l’export.
Le titre officiel du Data Act décrit un cadre de « règles harmonisées en matière d’accès équitable aux données et d’utilisation équitable des données » (règlement (UE) 2023/2854 du 13 décembre 2023). Cela souligne que l’objectif est l’équilibre et la réduction des obstacles, et non une promesse de sortie « instantanée ».
Pour consulter une source institutionnelle, notamment utile à partager en interne, la Commission européenne maintient une page de référence sur le Data Act : Page de référence de la Commission européenne sur le Data Act.
Ce que le Data Act implique techniquement : données exportables, interfaces et tests
Dans un projet de portabilité cloud et SaaS, la première question n’est pas « dans quel format exporter », mais quels objets doivent être considérés comme exportables. Pour un SaaS de gestion (CRM, ticketing, RH), il faut généralement examiner au minimum : les données d’entrée (créées ou importées par le client), les données générées par l’usage, les métadonnées (schémas, champs personnalisés) et les pièces jointes. Le périmètre juridique des données exportables dépend toutefois du règlement et de ses exclusions ; le code du fournisseur et certains éléments protégés ne sont pas automatiquement concernés.
Dans les faits, la bonne granularité consiste à lister les « objets » comme les voit l’utilisateur et comme les voit l’intégration. Exemple de périmètre exportable réaliste pour un SaaS de support, à confirmer avec le fournisseur et à préciser au contrat :
- Tickets (contenu, statuts, tags, SLA, priorités, affectations)
- Commentaires / échanges (dont l’auteur, la date et les pièces jointes)
- Utilisateurs et groupes (y compris les comptes désactivés si nécessaire à la conservation des historiques)
- Référentiels (catégories, files, modèles, macros)
- Règles et automatisations (routage, escalade, notifications)
- Journaux d’audit (actions d’administration, changements de droits, exports), sous réserve du périmètre applicable et des engagements contractuels
Un tableau simple peut aider à formaliser ce périmètre dès la phase de contrat ou d’annexe technique :
| Objet | Exemple | Format d’export attendu | Point d’attention |
|---|---|---|---|
| Données métier | clients, tickets, commandes | JSON/CSV + schéma | types, encodage, identifiants stables |
| Pièces jointes | PDF, images | fichiers + manifeste | liens, déduplication, antivirus |
| Métadonnées | champs, statuts, taxonomies | JSON + version | compatibilité des versions |
| Configurations | rôles, règles, workflows | JSON/YAML (si possible) | possibilité de les rejouer chez un autre fournisseur |
| Journaux et audit | administration, sécurité, accès | CSV/JSON horodaté | intégrité, horodatage, rétention |
Le deuxième point est l’interopérabilité, définie comme la capacité de deux systèmes à échanger des informations et à les utiliser. Techniquement, cela se traduit par des interfaces documentées (API), des formats structurés (par exemple JSON, CSV, Parquet) et des référentiels de schémas stables. Pour un entrepôt de données, exporter des tables en CSV peut être acceptable pour un audit ponctuel, mais insuffisant pour une migration : on préférera des formats colonnaires (Parquet) pour préserver les types et les partitions et faciliter certains traitements.
À ce stade, un détail fait souvent la différence entre un export « théorique » et un export « rejouable » : la stabilité des identifiants. Si, lors de l’import, les identifiants (clients, tickets, produits) changent, vous pouvez perdre les liens, les historiques et parfois la possibilité de recouper les données avec d’autres systèmes. Exigez donc, quand c’est possible, un export qui conserve :
- les identifiants d’origine ;
- les clés fonctionnelles ;
- une table de correspondance si une réécriture est imposée.
Le troisième point est le test, qui doit être traité comme une exigence d’exploitation, pas comme un « projet de fin de contrat ». Un test de portabilité crédible inclut : un export complet, un import chez un autre prestataire, une vérification d’intégrité (comptage, empreintes) et une mesure du délai. À titre indicatif, 2 To de données applicatives transférés sur un lien à 1 Gbit/s représentent environ 4,5 heures dans des conditions théoriques. En pratique, le temps peut être nettement plus long en raison du chiffrement, des contrôles d’intégrité, des fenêtres de maintenance, des reprises ou des limites du réseau et des services. Sans mesure, la clause « sous 30 jours » reste abstraite.
Pour rendre le test exploitable, vous pouvez définir un « kit de vérification » minimal, sans outillage complexe :
- Intégrité volumétrique : nombre d’enregistrements par table ou objet, taille totale des pièces jointes
- Intégrité logique : échantillon de dossiers reconstitués de bout en bout (ex. 30 tickets avec leurs commentaires, pièces jointes et historique)
- Intégrité cryptographique : empreintes (hash) des exports, au moins par fichier, avec un manifeste signé et horodaté
- Performance : temps total d’export, de transfert, d’import et de réindexation
- Écarts : liste des objets non exportés et justification
À ce stade, les organisations découvrent souvent que ce qui bloque n’est pas le volume, mais la sémantique : listes de valeurs, règles de dédoublonnage, identifiants internes, correspondances entre objets. Une stratégie pragmatique consiste à exiger un dictionnaire de données exportable et versionné, et à maintenir une couche de transformation (ETL/ELT) réutilisable en cas de changement. C’est aussi un levier de qualité des données, indépendamment du Data Act.
Clauses à exiger dans les contrats cloud et SaaS : délais, assistance, frais et chaîne de sous-traitance
Le Data Act impose aux fournisseurs concernés des obligations relatives au changement de fournisseur, mais l’efficacité de la sortie dépend aussi de ce que vous écrivez et contrôlez dans vos contrats et annexes techniques. Dans un contrat SaaS, la clause de sortie doit préciser le périmètre des données exportées, les formats, la fréquence possible, le mécanisme d’authentification et le support. Un « export sur demande » sans engagement de complétude ni de structure exploitable est, en pratique, une portabilité nominale.
Un bon niveau de précision contractuelle consiste à transformer la réversibilité en engagements vérifiables. Par exemple, sans imposer une forme unique, vous pouvez demander que la clause de sortie inclue :
- Périmètre : liste des objets exportables (données, pièces jointes, métadonnées, configurations, journaux)
- Formats : formats acceptés, schéma, règles d’encodage et dictionnaire de données
- Canal : API, export asynchrone, dépôt chiffré ou remise sur support (à titre exceptionnel)
- Assistance : ce qui est inclus (support, vérification, correction d’un export incomplet) et ce qui relève d’une prestation
- Critères d’acceptation : exemple d’export « conforme » et tolérances d’écarts
- Traitement de fin : suppression ou purge côté fournisseur, preuves et délais
Les points qui créent le plus de litiges sont généralement les suivants : qui fait quoi, à quel prix et dans quel délai. Le Data Act prévoit une période transitoire pour les frais de changement : jusqu’au 12 janvier 2027, les frais de changement éventuels ne peuvent pas dépasser les coûts directement liés au processus de changement ; à partir de cette date, les frais de changement doivent être supprimés. Votre risque se situe aussi dans les « zones grises » : assistance technique hors forfait, restauration d’archives, accélération de transfert, intervention d’un intégrateur. Un bon réflexe est de demander une grille tarifaire plafonnée pour les prestations de sortie et une définition claire de ce qui relève des obligations standard du fournisseur.
Vous pouvez aussi éviter une partie des mauvaises surprises avec une règle simple : tout ce qui est nécessaire pour relancer le service ailleurs doit être soit (a) exportable en standard, soit (b) explicitement chiffré et planifié en option. C’est particulièrement vrai pour :
- la récupération de données « froides » (archives, sauvegardes) ;
- la restitution des journaux sur une période donnée ;
- les contraintes de bande passante ou de fenêtre de maintenance.
La chaîne de sous-traitance est un autre point critique. Un SaaS peut s’appuyer sur plusieurs clouds, services de messagerie, services de journalisation ou d’indexation. Votre contrat doit prévoir que la portabilité ne s’arrête pas à l’interface « visible », mais couvre aussi, quand c’est nécessaire à la reprise, les données hébergées chez des sous-traitants (sauvegardes, archives, journaux), sous réserve du périmètre applicable et des contraintes de sécurité. Une méthode simple consiste à utiliser une liste de questions structurées pour examiner cette chaîne et les modalités de sortie.
Enfin, n’oubliez pas que le droit applicable et la juridiction compétente ne sont pas de simples détails : ils déterminent le cadre dans lequel les clauses de sortie seront interprétées et les recours disponibles en cas de non-respect. La portabilité est plus robuste quand elle est décrite dans des annexes techniques opposables (spécifications d’export, exemples de fichiers, limites, exigences de test), plutôt que laissée à des formulations générales.
Sécurité de la portabilité : chiffrement, clés, traces et données sensibles
Migrer, c’est dupliquer et transporter des données, donc augmenter temporairement la surface d’attaque. La sécurité doit être décrite de bout en bout : chiffrement en transit, chiffrement au repos, contrôle des accès, traçabilité et gestion des secrets. Une clause de portabilité ne garantit pas la sécurité si l’organisation n’a pas de procédure d’exécution et de contrôle.
Dans une portabilité réaliste, les risques typiques ne viennent pas uniquement du chiffrement, mais des conditions d’exécution :
- export lancé avec un compte trop privilégié ou non tracé ;
- dépôt de fichiers d’export dans un espace de stockage mal gouverné ;
- conservation trop longue des exports « intermédiaires » ;
- absence de séparation entre environnements (production et test) ;
- synchronisations qui continuent pendant l’export et produisent des données incohérentes.
Le sujet le plus souvent sous-estimé est la gestion des clés de chiffrement. Un KMS (Key Management Service) est un service qui crée, stocke et contrôle l’usage de clés cryptographiques. Si votre SaaS chiffre les données mais garde seul la maîtrise des clés, l’export peut être techniquement faisable mais opérationnellement fragile (rotation, révocation, preuves). Pour clarifier ce point, l’article suivant détaille la gouvernance des clés côté client, utile lors d’une négociation de portabilité : Cloud KMS : gouvernance des CMEK, rotation, destruction et audit.
Une bonne pratique consiste à exiger ou à organiser une séparation explicite entre :
- clés de chiffrement (qui peut chiffrer ou déchiffrer) ;
- droits d’export (qui peut extraire) ;
- droits de suppression (qui peut purger côté fournisseur) ;
- droits de validation (qui atteste la complétude).
La traçabilité est l’autre pilier. Lors d’une sortie, vous devez pouvoir établir ce qui a été exporté, quand, par qui et selon quel périmètre, puis ce qui a été supprimé côté fournisseur. Cela implique des journaux d’audit exportables et horodatés, ainsi qu’une procédure de validation (échantillonnage, hachage, rapprochement des volumes). En pratique, une « attestation de suppression » sans éléments vérifiables a peu de valeur opérationnelle.
Pour les données sensibles, la discussion dépasse la portabilité. Un service peut être techniquement portable et néanmoins inadapté si vos exigences d’hébergement et de qualification imposent un cadre spécifique. En France, certains besoins s’analysent au regard de référentiels comme SecNumCloud, qualification portée par l’ANSSI, avec des impacts concrets sur l’architecture et le choix des services. Pour situer ces contraintes, ce point de repère aide à comprendre les effets de SecNumCloud sur les services de données : SecNumCloud 3.2 : impacts sur les services cloud de données sensibles.
Une feuille de route pragmatique pour exploiter le Data Act (PME, ETI, secteur public)
La portabilité se prépare mieux comme un programme d’hygiène numérique que comme un projet exceptionnel. Première étape : inventorier les services cloud et SaaS, puis cartographier les flux de données, les comptes techniques et les droits. Une cartographie simple, maintenue à jour, fait souvent gagner plus qu’un long « plan de réversibilité » théorique, car elle met au jour les dépendances : connecteurs, comptes de service, partages externes, outils d’export manuels. Sur ce point, la méthode décrite ici est directement réutilisable : Gouvernance IA : cartographie des flux et accès pour données sensibles.
Deuxième étape : définir deux ou trois scénarios de sortie réalistes par catégorie de service. Par exemple, pour un SaaS de relation client : (1) export mensuel des données et des pièces jointes vers un stockage interne, (2) capacité de reconstruire les objets dans un CRM alternatif via API, (3) conservation des journaux d’audit pendant une durée compatible avec vos obligations. Pour un service de calcul ou d’analytique : (1) standardisation des formats de données (Parquet), (2) infrastructure as code pour redéployer ailleurs, (3) tests de performance reproductibles.
Un mini-scénario aide souvent à « débloquer » les arbitrages : une ETI gère son support clients dans un SaaS et découvre lors d’un audit que les journaux d’administration ne sont conservés que 30 jours et ne sont pas exportables en standard. Selon leur nature et le périmètre applicable, ces journaux peuvent ne pas relever des données exportables au titre du Data Act ; il est donc important d’évaluer le besoin et de le prévoir au contrat. Le risque n’est pas la migration en elle-même, mais la perte de capacité à expliquer une action (suppression, export, changement de droits) sur une période longue. La réponse pragmatique n’est pas d’ajouter des exigences partout, mais de :
- prioriser ce SaaS comme « critique conformité » ;
- exiger l’export des journaux d’audit (ou leur transfert en continu) dans un format exploitable ;
- tester l’export sur un mois chargé pour vérifier le volume et la qualité.
Troisième étape : exécuter un pilote de portabilité sur un périmètre borné. Cas typique à l’échelle d’une ETI de 500 personnes : choisir un SaaS non vital mais riche en données (support interne, gestion de projets), exiger l’export complet, reconstruire un environnement de reprise et mesurer le délai, le taux d’erreur, les objets non récupérés et l’effort humain. Après un premier cycle, vous pouvez transformer ces résultats en clauses : délais, formats, assistance incluse et critères d’acceptation.
Quatrième étape : formaliser un « minimum contractuel » réutilisable. Concrètement, préparez une annexe standard incluant la description des données exportables, des exemples de fichiers, les exigences relatives aux journaux et au chiffrement, le rôle de chaque partie et les modalités de test annuel. Vous ne cherchez pas une conformité « théorique », mais un mécanisme qui résiste à un changement de fournisseur, à une fusion ou à une montée en charge.
Pour rendre ce « minimum » réellement exploitable, notamment dans le secteur public où les renouvellements et les marchés peuvent s’étaler, ajoutez deux éléments très concrets :
- un RACI simple (qui est responsable, approbateur, contributeur et informé pour l’export, la validation, la suppression et la gestion des incidents) ;
- une liste courte de preuves attendues (manifeste d’export, journaux d’export, rapport d’écarts, attestation de suppression accompagnée d’éléments vérifiables).
Action concrète à lancer cette semaine : programmer un test d’export complet sur un SaaS critique (données, métadonnées et journaux), puis mesurer l’intégrité et le délai, et convertir ces mesures en exigences contractuelles lors du prochain renouvellement. Niveau d’effort : moyen (quelques jours à quelques semaines selon le volume et l’accès aux API), avec un bénéfice immédiat pour la maîtrise du risque de dépendance.
