Ce que change le Data Act sur les frais de changement (et ce que cela ne change pas)
Le Data Act (règlement (UE) 2023/2854 du 13 décembre 2023, publié au JOUE le 22 décembre 2023) encadre, entre autres, le changement de fournisseur de services de traitement de données, notamment cloud et SaaS. Un frais de changement (switching charge) désigne ici un frais facturé spécifiquement au titre du processus de changement de fournisseur, par exemple pour transférer des données. La réversibilité est la capacité à quitter un service et à migrer ses données et configurations vers une cible, avec des délais, des coûts et des risques maîtrisés.
L’objectif du Data Act n’est pas « d’offrir une migration gratuite », mais de réduire certains obstacles au changement de fournisseur, notamment ceux liés aux contrats, aux formats, aux restrictions techniques ou aux frais de changement. Le règlement prévoit des obligations de transparence et des mécanismes facilitant le changement. Leur portée dépend toutefois du service et du champ d’application du texte.
Il est important de ne pas confondre plusieurs notions. L’hébergement est le fait de stocker ou de traiter des données sur une infrastructure opérée par un tiers. Le droit applicable désigne les règles qui gouvernent le contrat et les litiges ; la juridiction compétente désigne les tribunaux susceptibles de les trancher. La maîtrise du modèle est votre capacité à accéder aux poids, à paramétrer, évaluer et déployer un modèle d’IA et, le cas échéant, à le réentraîner sans dépendre d’un intermédiaire. Ces notions se recoupent parfois, mais ne protègent pas contre les mêmes risques.
Un exemple simple, souvent rencontré dans des ETI ou des collectivités : vous pouvez avoir un SaaS « hébergé en UE » avec une bonne sécurité opérationnelle, tout en restant captif si :
- vos données sont exportables mais sans les métadonnées (statuts, relations, historiques) ;
- les configurations (règles métiers, rôles, workflows) ne sont pas exportables ;
- le fournisseur facture une assistance de sortie comme un projet premium obligatoire.
Le Data Act ne promet pas une sortie « sans effort ». Il vise notamment à réduire les obstacles contractuels, tarifaires et techniques au changement de fournisseur, dans les limites prévues par le règlement. Les coûts internes de migration (refonte d’architecture, tests, conduite du changement) restent généralement à votre charge. Dans une organisation de 20 à 2 000 personnes, c’est souvent là que se trouve l’essentiel du budget, plus que dans les frais de changement facturés par le fournisseur.
Pour garder une lecture réaliste, distinguez bien :
- Coûts de changement internes : équipes, intégration, requalification sécurité, recette, formation.
- Coûts techniques liés à l’usage : bande passante, stockage temporaire, calcul ponctuel. Leur traitement dépend notamment de leur lien avec le processus de changement et des dispositions contractuelles applicables.
- Frais de changement : frais facturés spécifiquement au titre du processus de changement, comme des forfaits de sortie ou des frais d’export.
Le calendrier opérationnel : portabilité dès 2025, suppression progressive jusqu’en 2027
Le règlement est entré en vigueur le 11 janvier 2024 et il est applicable, pour l’essentiel, depuis le 12 septembre 2025. À partir de cette date, les obligations relatives au changement de fournisseur et à l’assistance à la sortie s’appliquent aux services de traitement de données entrant dans le champ du règlement, sous réserve des dispositions et exceptions prévues par celui-ci. Pour un repère plus détaillé sur la mise en œuvre côté portabilité, vous pouvez croiser avec l’article interne : Data Act : portabilité des données cloud et SaaS dès 2025.
La suppression des frais de changement est progressive : jusqu’au 11 janvier 2027, les fournisseurs peuvent appliquer des frais de changement réduits, qui ne doivent pas dépasser les coûts directement liés au processus de changement. À compter du 12 janvier 2027, ils ne peuvent plus imposer de frais de changement. Cela ne signifie pas que toute prestation demandée par le client, tout service optionnel ou tout frais ordinaire d’utilisation du service devient gratuit. Il faut distinguer ces postes des frais facturés au titre du processus de changement.
Dans la pratique, vos contrats signés en 2025–2026 devraient déjà préciser la trajectoire tarifaire applicable et définir ce qui est inclus dans la réversibilité standard, par opposition aux prestations optionnelles.
Table de lecture utile pour piloter (à adapter à votre contexte et à la nature du service) :
| Période | Ce que vous devez obtenir contractuellement | Risque si vous ne le faites pas |
|---|---|---|
| 2024–mi-2025 (avant applicabilité) | Annexe de réversibilité, formats, inventaire des objets exportables, test de sortie | Sortie « théorique » non testée, surprises au renouvellement |
| À partir du 12/09/2025 | Processus de changement opérationnel, assistance et transparence tarifaire, dans le champ des obligations applicables | Export incomplet, assistance floue ou délais incompatibles |
| Jusqu’au 11/01/2027, puis à compter du 12/01/2027 | Vérification des frais de changement appliqués pendant la période transitoire, puis de leur suppression à la date prévue par le règlement | Migration retardée si les frais de changement sont économiquement dissuasifs |
Pour les décideurs, l’enjeu n’est pas seulement la date, mais la prévisibilité. Une migration réussie se prépare 6 à 18 mois à l’avance (inventaire, architecture cible, sécurité, tests). Si vos échéances contractuelles (renouvellement tacite, engagements de volume, remises conditionnelles) ne sont pas alignées avec la fenêtre 2026–2027, vous risquez de payer une « non-sortie » : rester un an de plus faute de capacité à basculer. Ce risque est souvent supérieur à celui des frais de transfert.
Point d’attention très concret : la « trappe » vient fréquemment de clauses non techniques (préavis, reconduction automatique, remise conditionnelle, pénalités de résiliation anticipée). Le Data Act encadre le changement de fournisseur de services de traitement de données dans les limites de son champ d’application ; il ne remplace pas une stratégie contractuelle (calendrier, options de sortie, gouvernance de fin de contrat).
Quelles « exceptions » peuvent subsister en 2027 : distinguer les coûts légitimes des frais de changement
Même après la suppression des frais de changement à compter du 12 janvier 2027, il reste des distinctions importantes à faire en négociation. Un fournisseur peut facturer des prestations optionnelles qui ne sont pas indispensables au changement de fournisseur (par exemple : un accompagnement projet renforcé, des développements sur mesure ou une intervention en heures non ouvrées). L’objectif est de séparer ce qui relève d’un service additionnel choisi de ce qui relève des obligations de changement applicables.
Une bonne pratique de négociation consiste à imposer une liste “inclus / optionnel” dans l’annexe de réversibilité. Exemple de découpage, sans en faire un standard universel :
- Inclus (réversibilité de base) : export des données et métadonnées définies, extraction des configurations clés, documentation des schémas, assistance standard (tickets, créneaux, runbook).
- Optionnel : replatforming applicatif, refonte de workflows, prestations d’architecture, optimisation de coûts, migration « zéro interruption ».
Une deuxième catégorie concerne les coûts techniques liés à l’utilisation du service, comme la connectivité, le calcul ou certaines opérations d’export massives. Il faut distinguer les frais d’usage ordinaire des frais facturés spécifiquement au titre du changement, et vérifier le traitement de chaque poste au regard du contrat et du règlement.
Opérationnellement, cela se traduit par une question simple à poser :
« Ce poste est-il facturé pareil lors d’une extraction pour mon activité normale, ou est-il facturé spécifiquement au titre du changement de fournisseur ? »
La réponse est un indice utile pour qualifier le poste, mais ne suffit pas à elle seule à déterminer son traitement juridique.
Checklist courte pour qualifier un coût :
- Le coût est-il documenté (unité, métrique, grille tarifaire) ?
- Est-il comparable à un coût facturé pour un usage similaire hors changement ?
- Est-il proportionné à un usage de ressources mesurable ?
- Peut-il être évité via un mécanisme standard (export incrémental, API, formats ouverts) ?
- Existe-t-il un plafond ou une trajectoire de baisse claire pendant la période transitoire ?
Enfin, certaines restrictions peuvent être justifiées par la sécurité ou des obligations légales. Un fournisseur peut encadrer les modalités d’export si une demande mettrait en danger l’intégrité du service, expose des secrets d’autres clients ou contrevient à des obligations légales. Cela ne constitue pas un droit général à refuser le changement : les motifs et les modalités doivent être examinés dans leur contexte.
D’où l’intérêt de contractualiser des procédures d’export sécurisées (canal chiffré, liste d’adresses autorisées, contrôle d’accès, traces d’audit) plutôt que de découvrir les conditions en fin de contrat. Dans un contexte français (données sensibles, secteur public, santé), cette formalisation peut aussi produire des éléments probants lors d’audits internes (RSSI, DPO) ou de contrôles.
Les impacts concrets sur les contrats : clauses à ajouter, preuves à exiger, métriques à suivre
La réversibilité se gagne au moment de l’achat, pas au moment du départ. Côté données personnelles, le socle reste le RGPD : l’article 28 impose notamment que « le sous-traitant ne traite les données à caractère personnel que sur instruction documentée du responsable du traitement » (extrait de l’article 28, paragraphe 3, point a), du règlement (UE) 2016/679). Les clauses de fin de contrat (restitution, effacement, assistance) sont un point de rencontre entre RGPD et Data Act. Repère utile : Article 28 RGPD : clauses clés du contrat de sous-traitance.
Concrètement, un contrat « Data Act-ready » doit préciser au minimum : le périmètre des données exportables (données, métadonnées, configurations), les formats (CSV, Parquet, JSON, dumps SQL, objets), les délais de mise à disposition et la façon dont les secrets sont gérés pendant la transition. Le traitement contractuel des configurations et des composants d’IA doit être précisé : leur exportabilité ne découle pas automatiquement du fait qu’ils sont utiles à la continuité opérationnelle. Sur l’IA, n’oubliez pas les objets moins visibles : jeux d’évaluation, historiques de prompts, paramètres d’inférence, index de recherche vectorielle, règles de filtrage et journaux d’accès. Leur exportabilité dépend notamment du service, des droits applicables et du contrat.
Pour éviter une annexe de réversibilité « décorative », demandez des preuves (idéalement avant signature, sinon comme jalon contractuel) :
- Un inventaire des objets exportables (y compris limites et exclusions).
- Un exemple de package d’export (structure, schémas, volumes typiques).
- La documentation des API / interfaces d’extraction et leurs limites (quotas, limitation de débit).
- Un runbook de sortie : qui fait quoi, sous quels délais, par quels canaux et avec quels contrôles.
- Un engagement de conservation des journaux nécessaires à la reconstitution ou à l’audit, sur une durée définie.
Pour piloter et objectiver, fixez des métriques. Exemples simples : temps de génération d’un export complet, volume exportable par jour, taux de réussite des restaurations, temps de reconstitution d’un environnement (IaC) et nombre d’éléments non exportables (listés explicitement). Un test périodique de sortie sur un périmètre restreint permet de repérer les difficultés avant une migration réelle.
Astuce pragmatique : transformez ces métriques en SLO de réversibilité (objectifs de service), au même titre que la disponibilité. Même si vous ne les « pénalisez » pas au contrat, les suivre favorise un dialogue factuel avec le fournisseur.
En complément, la grille de questions à poser aux fournisseurs permet de structurer l’appel d’offres : Questions à poser pour choisir un fournisseur IA et maîtriser les risques.
Cas d’usage IA : données d’entraînement, secrets et dépendances techniques qui bloquent une sortie
Les projets d’IA introduisent de nouvelles dépendances, au-delà du stockage de fichiers. Un cas typique : un assistant interne s’appuie sur des documents, un index vectoriel, une configuration de filtrage et des règles d’accès. Si vous ne pouvez exporter que les documents, mais pas l’index ni la configuration de recherche, vous risquez de devoir reconstruire ces éléments, avec des écarts de qualité. C’est là que la distinction entre maîtrise du modèle (contrôler ce qui fait l’IA) et simple hébergement devient déterminante.
Mini-scénario (réaliste en entreprise) : vous migrez un assistant RH interne.
- Export ok : documents sources et réponses type.
- Manque : embeddings, index vectoriel, règles de chunking, prompts système, journaux de grounding.
- Résultat : la nouvelle plateforme répond, mais avec une précision dégradée, car le pipeline RAG n’est plus identique.
Conclusion : la réversibilité IA n’est pas « un export de fichiers », c’est un export de composants, dans la mesure où le contrat et les droits applicables le permettent.
Les modèles open-weight (à poids accessibles) réduisent certaines formes de verrouillage, car vous pouvez les redéployer ailleurs à coût marginal, sous réserve de matériel compatible et de droits de licence. Ils ne règlent pas tout : le verrouillage peut se déplacer vers la chaîne de données, l’outillage d’évaluation ou des services propriétaires d’orchestration. Pour cadrer ces arbitrages, repère interne : Modèles open-weight : résidence des données et options de déploiement.
Concrètement, pour « déverrouiller » un usage IA, surveillez trois dépendances techniques fréquentes :
- Dépendance au fournisseur d’embeddings (format, dimension, normalisation, versioning).
- Dépendance à l’orchestration (workflows, agents, connecteurs propriétaires).
- Dépendance aux garde-fous (règles de modération et de filtrage, caviardage).
La gestion des secrets est souvent l’angle mort des plans de sortie. Une clé API ou un secret d’accès mal géré peut rendre une migration impossible — ou risquée — en fin de contrat. Un KMS (service de gestion de clés) crée, stocke et contrôle l’usage de clés cryptographiques pour chiffrer et déchiffrer des données. Pour les environnements cloud, l’usage de clés gérées par le client (CMEK) peut faciliter le contrôle des accès aux données et la gestion des clés ; il ne constitue pas, à lui seul, une preuve d’effacement. Il exige une gouvernance (rotation, destruction, audit). Repère interne : Cloud KMS : gouvernance des CMEK, rotation, destruction et audit.
Point pratique à intégrer dès la conception : prévoyez une capacité de double écriture temporaire (ou de double indexation) pendant la migration IA. Même limitée à quelques semaines, elle peut réduire le risque d’arrêt et transformer une sortie « big bang » en bascule contrôlée.
Réversibilité et exigences « données sensibles » : aligner Data Act, SecNumCloud et votre cartographie des flux
Quand les données sont sensibles (santé, défense, secret des affaires, certaines données de collectivités), la question n’est pas seulement « puis-je sortir ? », mais « puis-je prouver ce qui est sorti, ce qui a été effacé et qui y a eu accès ? ». La cartographie des flux est l’inventaire des chemins empruntés par les données (sources, traitements, sorties, sous-traitants). Elle conditionne la capacité à déclencher une sortie sans perdre le contrôle, notamment si des services tiers sont impliqués (vision, traduction, modération, OCR).
Les référentiels de qualification et d’exigences, comme SecNumCloud, apportent des garde-fous sur l’organisation du fournisseur, les opérations et la sécurité. Ils ne remplacent pas un plan de réversibilité : un service qualifié peut rester difficile à quitter si l’architecture est trop couplée ou si les formats sont fermés. L’enjeu pour une DSI est d’aligner trois couches : exigences d’hébergement, exigences de sécurité et capacité de migration. Repère interne : SecNumCloud 3.2 : impacts sur les services cloud de données sensibles.
Sur le plan méthodologique, commencez par une cartographie « utile à la sortie » : où résident les données, quelles identités y accèdent, quels journaux existent, quelles clés les chiffrent et quelles dépendances empêchent de redémarrer ailleurs.
Une façon simple de rendre la cartographie actionnable est de la relier à des livrables de sortie :
- Données et métadonnées : où, sous quel format et avec quels contrôles d’intégrité (hachage).
- Configurations : export possible ? Sous quelle représentation ?
- Identités et accès : comment reconstituer le modèle d’autorisations côté cible ?
- Journaux : lesquels sont nécessaires pour l’audit, l’analyse forensique ou la preuve d’effacement ?
- Clés : quelles clés chiffrent quelles données, qui peut les révoquer et comment prouver leur destruction ?
Cette approche est détaillée dans : Gouvernance IA : cartographie des flux et accès pour données sensibles. Elle permet de transformer les dispositions pertinentes du Data Act en exigences vérifiables, plutôt qu’en principe abstrait.
Pour un repère institutionnel sur la politique européenne des données (complément utile au texte juridique), la Commission européenne maintient une page de synthèse du Data Act : Page de synthèse du Data Act de la Commission européenne
Prochaine étape réaliste : un « test de sortie » en 4 semaines (effort moyen)
Planifiez un test de sortie limité mais réel sur un service cloud ou SaaS critique. L’objectif n’est pas de migrer tout de suite, mais de mesurer votre capacité à exporter, restaurer et redémarrer un service minimum viable. Un bon périmètre : un entrepôt de données secondaire, une application SaaS contenant des données métiers ou un composant IA (index vectoriel, corpus et configuration).
Semaine 1 : cadrage et inventaire. Listez les objets à exporter (données, métadonnées, configurations, journaux), les exigences de sécurité (chiffrement, contrôles d’accès) et les contraintes de délais. Définissez aussi le critère de réussite : par exemple, « restaurer 80 % des usages critiques sur un environnement cible en moins de X jours » (sans promettre une équivalence parfaite).
Semaine 2 : extraction et transfert vers une zone neutre. Documentez comment vous obtenez l’export (API, console, outil), ses limites (quotas, délais) et le coût observé (stockage temporaire, transfert de données, calcul). Si possible, faites au moins une extraction incrémentale pour tester la faisabilité d’une bascule progressive.
Semaine 3 : restauration sur une cible (autre cloud, environnement interne ou plateforme de test). Mesurez le taux de restauration : éléments importables tels quels, éléments à transformer (ETL), éléments impossibles (et pourquoi). Pour l’IA, testez explicitement la reconstruction du pipeline (embeddings, index, prompts, règles d’accès).
Semaine 4 : validation fonctionnelle et sécurité, puis rédaction d’un rapport d’écarts (ce qui manque, ce qui coûte, ce qui bloque). Incluez un volet sécurité : preuves de chiffrement en transit, contrôle d’accès au package d’export, traçabilité et procédure d’effacement (côté fournisseur et côté zone neutre).
À l’issue, négociez ou ajustez trois éléments : une annexe de réversibilité avec livrables et formats, une trajectoire tarifaire conforme au calendrier des frais de changement prévu par le règlement et un engagement de test périodique. Ce sont des demandes à évaluer selon votre contexte et vos cycles d’achat, publics ou privés. Elles réduisent le risque de verrouillage sans promettre une conformité « garantie » et rendent vos arbitrages IA plus soutenables dans la durée.
Référence technique utile pour cadrer le concept de cloud : NIST SP 800-145 (2011) définit le cloud computing comme « a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources » (National Institute of Standards and Technology, 2011). Ce rappel aide à distinguer ce qui relève du service lui-même de ce qui doit rester portable par conception.
Sources principales (accès public) : Règlement (UE) 2023/2854 (Data Act), EUR-Lex ; Règlement (UE) 2016/679 (RGPD), EUR-Lex ; NIST SP 800-145 (2011) ; Commission européenne, page de synthèse du Data Act
