Le Data Act s’applique depuis le 12 septembre 2025. Son chapitre VI encadre le passage d’un service de traitement de données vers un autre fournisseur, vers une infrastructure interne ou, sous conditions, la suppression des données et actifs numériques. En 2026, l’enjeu n’est plus de promettre une « portabilité » abstraite. Il consiste à savoir précisément ce qui peut être transféré, dans quel délai, avec quelle assistance et sous quelle forme de preuve.
Synthèse exécutive
- Le droit au changement de fournisseur dépasse un simple export. Le règlement traite les données exportables, les actifs numériques, les interfaces, la continuité du service, le délai de récupération et l’effacement final. Une archive téléchargée ne démontre pas à elle seule la possibilité de reprendre l’activité ailleurs.
- Le calendrier normal peut déjà dépasser trois mois. Le contrat peut prévoir jusqu’à deux mois de préavis avant une période de transition normalement limitée à trente jours calendaires. Une impossibilité technique justifiée ouvre une période alternative pouvant atteindre sept mois.
- La suppression des frais au 12 janvier 2027 ne rend pas toute migration gratuite. Le règlement distingue les frais de changement de fournisseur des frais de service standard et des pénalités de résiliation anticipée. Un usage parallèle de plusieurs services peut aussi générer des frais continus de sortie de données.
- Les obligations techniques diffèrent selon le modèle de service. L’IaaS impose au fournisseur source de faciliter l’équivalence fonctionnelle. Le PaaS et le SaaS reposent notamment sur des interfaces ouvertes et un export structuré, couramment utilisé et lisible par machine.
- Le Digital Omnibus ne modifie pas encore le droit applicable. La proposition COM(2025) 837 prévoit des allègements ciblés, mais la procédure 2025/0360(COD) attend encore une décision en commission parlementaire au 23 juillet 2026. Une exemption proposée ne doit pas être traitée comme une règle en vigueur.
Conclusion courte : le Data Act crée un cadre de sortie opposable au fournisseur. La capacité réelle de migrer reste à démontrer par un test qui relie contrat, inventaire des actifs, export, intégrité, restauration, continuité et effacement.
La réversibilité porte sur des données et des actifs utilisables
Le règlement (UE) 2023/2854 vise les « services de traitement de données ». La FAQ de la Commission, version 1.4, confirme que cette définition couvre les modèles IaaS, PaaS et SaaS lorsqu’ils présentent les caractéristiques prévues par l’article 2, paragraphe 8. L’utilisation d’une fonctionnalité appuyée sur du cloud ne suffit pas toujours : il faut aussi vérifier qu’un client utilise le service de traitement de données en tant que tel.
Deux ensembles doivent être distingués :
| Ensemble | Périmètre réglementaire | Point de contrôle |
|---|---|---|
| Données exportables | Données d’entrée et de sortie, ainsi que les métadonnées directement ou indirectement générées ou co-générées par l’usage du service, hors éléments protégés par les droits de propriété intellectuelle ou secrets d’affaires du fournisseur ou d’un tiers | Liste des jeux de données, schémas, formats, volumes, relations et métadonnées nécessaires à leur interprétation |
| Actifs numériques | Éléments sur lesquels le client dispose d’un droit d’usage et qui sont nécessaires pour utiliser efficacement ses données dans l’environnement de destination | Configurations, paramètres de sécurité, droits d’accès, images de machines virtuelles, conteneurs, applications ou autres éléments pertinents selon le service |
Le contrat doit fournir une spécification exhaustive des catégories de données et d’actifs pouvant être transférées. Il peut également préciser des catégories liées au fonctionnement interne du service qui sont exclues afin de protéger les secrets d’affaires du fournisseur. Cette exclusion ne doit toutefois ni empêcher ni retarder le changement de fournisseur prévu à l’article 23.
Cette frontière mérite un examen document par document. Une mention générique comme « toutes les données client sont exportables » ne dit rien du schéma, des relations, des journaux, des paramètres d’identité, des clés gérées par le client ou des versions nécessaires à la reprise.
Le calendrier contractuel comporte plusieurs horloges
L’article 25 ne fixe pas un délai unique. Il organise une séquence qui commence avec la notification du client et se termine après la récupération puis l’effacement. Le préavis contractuel permettant d’engager le changement ne peut pas dépasser deux mois. La période de transition qui suit est normalement limitée à trente jours calendaires.
Le fournisseur source doit assister le client et les tiers autorisés, maintenir une continuité raisonnable, fournir les informations nécessaires et conserver un niveau de sécurité élevé pendant le changement. Si trente jours sont techniquement insuffisants, il doit informer le client dans les quatorze jours ouvrables suivant la demande, justifier l’impossibilité et proposer une période alternative qui ne dépasse pas sept mois. Le client peut aussi choisir une période de transition plus longue, adaptée à ses besoins.
Après la transition, le contrat doit prévoir une période minimale de trente jours calendaires pour récupérer les données. L’effacement intervient à son terme, sauf date ultérieure convenue, une fois le changement mené à bien.
Ces maxima ne constituent ni un objectif de reprise ni une garantie de continuité métier. Une organisation qui découvre le format de ses exports après la notification peut consommer le préavis en analyse, puis la transition en corrections. Le test préalable permet de mesurer la durée réellement nécessaire avant de s’engager sur une date.
IaaS, PaaS et SaaS ne portent pas la même obligation technique
L’article 30 distingue l’infrastructure des autres modèles de service. Présenter tous les fournisseurs comme responsables du rétablissement complet chez un concurrent créerait une attente que le texte ne soutient pas.
| Modèle | Obligation technique centrale du fournisseur source | Limite à retenir |
|---|---|---|
| IaaS | Prendre toutes les mesures raisonnables pour faciliter l’équivalence fonctionnelle dans un service de destination du même type, notamment par les capacités, informations, documentations, appuis techniques et outils appropriés | Le fournisseur source n’a pas à reconstruire le service dans l’environnement du fournisseur de destination |
| PaaS | Mettre gratuitement des interfaces ouvertes à disposition du client et du fournisseur de destination, puis permettre l’export dans un format structuré, couramment utilisé et lisible par machine | La disponibilité d’une interface ne garantit ni la compatibilité des composants ni la reprise des comportements propres à la plateforme |
| SaaS | Même socle d’interfaces ouvertes et d’export structuré lorsqu’il s’agit d’un service de traitement de données au sens du règlement | La réimplantation des règles métier, intégrations et automatismes peut rester à la charge du client et du fournisseur de destination |
La FAQ officielle précise aussi le traitement des services développés sur mesure et non proposés à grande échelle. L’article 31 leur applique un régime particulier, mais ne les exclut pas intégralement du chapitre VI. Les interfaces ouvertes et l’export structuré restent notamment cités par la Commission. Les services de test ou d’évaluation, fournis pour une durée limitée hors production, relèvent d’une autre exemption étroite.
La qualification doit donc être établie service par service. Le nom commercial « SaaS » ou « cloud privé » ne remplace ni la définition de l’article 2 ni l’analyse des caractéristiques du contrat.
La gratuité de 2027 laisse plusieurs coûts hors champ
Du 11 janvier 2024 au 12 janvier 2027, le fournisseur peut facturer des frais réduits de changement de fournisseur. L’article 29 plafonne ces frais aux coûts directement liés à l’opération concernée. À partir du 12 janvier 2027, il ne peut plus imposer de tels frais au client pour la procédure de changement.
Le mot « gratuit » serait pourtant trompeur. La définition réglementaire des frais de changement de fournisseur exclut les frais de service standard et les pénalités de résiliation anticipée. Avant la conclusion du contrat, le fournisseur doit communiquer clairement ces montants ainsi que les frais réduits applicables pendant la période transitoire.
| Poste | Situation au 12 janvier 2027 | Vérification utile |
|---|---|---|
| Assistance ou opération facturée au titre du changement de fournisseur | Frais de changement interdits | Devis détaillé, base contractuelle et qualification de chaque ligne |
| Sortie ponctuelle de données liée au changement | Incluse dans la suppression des frais de changement selon la FAQ de la Commission | Volume, fenêtre, destination et preuve du lien avec la procédure |
| Frais de service standard jusqu’à l’échéance | Non supprimés par l’article 29 | Durée ferme, échéance, préavis et facturation résiduelle |
| Pénalité de résiliation anticipée | Distincte des frais de changement dans le règlement en vigueur | Clause, montant, transparence précontractuelle et droit national applicable |
| Sortie continue de données dans un usage multicloud parallèle | Peut rester facturée selon la FAQ, car elle ne correspond pas à une sortie ponctuelle | Politique tarifaire, volumes courants et architecture cible |
| Adaptation, restauration et qualification chez le fournisseur de destination | Hors prix imposé au fournisseur source par l’article 29 | Budget interne, prestation de destination, outillage et temps d’arrêt |
Cette séparation impose une discipline de chiffrage. Un fournisseur qui annonce « zéro frais de sortie » peut respecter l’article 29 tout en laissant subsister une échéance ferme, des coûts de destination et un travail important de transformation. La décision doit comparer le coût complet du scénario, pas une seule ligne tarifaire.
Le contrat doit permettre une sortie observable
L’article 25 exige un contrat écrit et disponible avant signature. Il impose notamment les modalités d’information du fournisseur, les droits et obligations pendant le changement, les catégories de données et actifs portables, les exclusions, le délai de récupération et l’effacement.
Les clauses contractuelles types publiées par la Commission sont volontaires. Trois ensembles traduisent directement le chapitre VI : changement et sortie, résiliation, sécurité et continuité d’activité. Trois autres traitent l’absence de dispersion des clauses, la protection contre les modifications injustifiées et la responsabilité. Elles constituent une base de négociation, pas une certification de conformité du contrat final.
Une revue utile doit relier chaque clause à une action et à une trace :
| Engagement contractuel | Action à tester | Preuve attendue |
|---|---|---|
| Catégories de données exportables | Générer un export complet sur un dossier représentatif | Inventaire, manifeste, schémas, volumes, dates et empreintes |
| Actifs numériques | Relever les configurations, droits et composants nécessaires | Liste versionnée, droits d’usage et dépendances |
| Assistance du fournisseur | Ouvrir une demande selon le canal contractuel | Horodatage, interlocuteurs, réponses, limites et délais |
| Continuité pendant la transition | Exécuter l’export sans dégrader un service critique | Mesures de disponibilité, incidents et décisions |
| Récupération | Importer les données dans une destination contrôlée | Journaux, erreurs, éléments manquants et résultat d’intégrité |
| Effacement | Fermer la période de récupération puis demander la suppression | Confirmation du fournisseur, périmètre, date et exceptions de conservation |
Une réversibilité défendable se teste de bout en bout
Le protocole suivant est une proposition opérationnelle de BLACKPROOF. Il ne constitue ni un délai réglementaire supplémentaire ni une interprétation officielle. Son objectif est de produire un dossier que les équipes sécurité, juridique, achats, produit et exploitation peuvent relire ensemble.
1. Délimiter le scénario
Le dossier nomme le service source, la destination, le périmètre, la date de référence, le motif de sortie et les fonctions concernées. Il distingue un transfert complet, une réinternalisation, une suppression sans transfert et un usage multicloud parallèle, car les obligations et les coûts ne sont pas identiques.
2. Geler l’inventaire
Les données, actifs numériques, interfaces, identités, secrets, dépendances et exclusions sont placés dans un inventaire versionné. Chaque exclusion doit renvoyer au contrat ou à une limite technique identifiée, pas à une appréciation orale.
3. Produire et contrôler l’export
L’équipe enregistre la version du service, l’heure de début et de fin, le compte utilisé, les volumes, les formats, les erreurs et les empreintes cryptographiques. Les journaux contenant des données personnelles ou des secrets sont expurgés avant partage, sans supprimer les éléments nécessaires à la vérification.
4. Restaurer dans une destination distincte
Le test importe l’export sans dépendre de la session source. Les schémas, relations, droits, configurations et automatismes sont contrôlés séparément. Pour l’IaaS, l’évaluation porte sur le résultat matériellement comparable et sur l’assistance fournie par la source, pas sur une identité parfaite entre deux environnements.
5. Valider avec des critères métier
Le service restauré exécute un petit ensemble d’opérations représentatives définies avant le test. Les critères portent sur l’exactitude des données, la sécurité, les droits, les performances nécessaires et les fonctions indispensables. Un export techniquement lisible mais inutilisable par les métiers reste un échec de réversibilité.
6. Fermer les accès et les données
La clôture recense les identités révoquées, les clés renouvelées, les intégrations arrêtées, les données encore récupérables et la confirmation d’effacement. Les obligations de conservation légale ou les sauvegardes résiduelles doivent être documentées avec leur périmètre et leur durée.
Le Digital Omnibus reste une proposition
La Commission a présenté la proposition COM(2025) 837 le 19 novembre 2025. Pour le chapitre VI du Data Act, le texte proposé prévoit notamment :
- un régime allégé pour certains services conçus sur mesure, non disponibles sur étagère et inutilisables sans adaptation préalable à l’écosystème du client, lorsqu’ils reposent sur un contrat conclu au plus tard le 12 septembre 2025 ;
- un régime allégé pour certains services autres que l’IaaS fournis par une PME ou une petite entreprise à moyenne capitalisation sur la base d’un contrat conclu au plus tard à cette même date ;
- la possibilité explicite de prévoir des pénalités proportionnées de résiliation anticipée dans certains contrats à durée déterminée portant sur des services autres que l’IaaS.
La proposition maintient toutefois l’article 29 dans ces régimes allégés. La réduction puis la suppression des frais de changement de fournisseur ne serait donc pas écartée.
Au 23 juillet 2026, l’Observatoire législatif du Parlement européen classe la procédure 2025/0360(COD) dans l’état « awaiting committee decision ». Un projet de rapport de commission est daté du 22 juin 2026. Le texte de 2025 n’est donc pas le droit adopté. Les contrats doivent être évalués au regard du règlement en vigueur, avec une veille séparée sur les éventuelles modifications futures.
Data Act et DORA répondent à deux contrôles différents
Le Data Act est transversal. Il impose des obligations au fournisseur de services de traitement de données et organise les droits du client pendant la sortie. DORA vise les entités financières et demande, pour les services ICT soutenant des fonctions critiques ou importantes, des stratégies de sortie complètes, documentées, suffisamment testées et revues périodiquement.
Une entité financière peut donc mobiliser le contrat Data Act pour obtenir un export, une assistance et un calendrier, sans avoir encore satisfait son propre devoir DORA de préparer la continuité. À l’inverse, un plan DORA interne ne remplace pas les clauses nécessaires face au fournisseur.
Notre analyse sur les dépendances ICT et les plans de sortie DORA approfondit cette articulation pour le secteur financier.
Plan d’action en trente jours
Ce calendrier est une proposition de préparation interne. Il ne correspond pas à la période de transition réglementaire de l’article 25.
Jours 1 à 7 : contrat et qualification
- qualifier chaque service à partir de la définition réglementaire, sans se limiter à son étiquette commerciale ;
- relever préavis, durée ferme, frais, assistance, catégories exportables, exclusions, récupération et effacement ;
- identifier les divergences entre contrat principal, annexes, documentation publique et console.
Jours 8 à 14 : inventaire et export
- construire l’inventaire des données et actifs numériques ;
- produire un export représentatif ;
- documenter format, schéma, volume, durée, coût, erreurs et intégrité ;
- ouvrir les demandes d’assistance prévues au contrat.
Jours 15 à 23 : restauration et validation
- restaurer dans une destination distincte ;
- tester les identités, les règles métier, les intégrations et les contrôles de sécurité ;
- mesurer le temps de reprise et la charge humaine ;
- classer les écarts qui empêchent une sortie dans les délais.
Jours 24 à 30 : décision et preuve
- chiffrer les frais réglementés et les coûts hors champ séparément ;
- corriger ou renégocier les clauses bloquantes ;
- approuver le scénario, les critères et les responsabilités ;
- assembler les pièces selon une méthode de preuve traçable, puis enregistrer les manques dans une dette de preuve.
Questions ouvertes avant toute décision
- Le service entre-t-il dans la définition réglementaire ou le client utilise-t-il seulement une fonctionnalité appuyée sur une infrastructure cloud ?
- Le scénario est-il un changement complet, une réinternalisation, une suppression ou un usage multicloud parallèle ?
- Les données exportables et les actifs numériques sont-ils énumérés avec assez de précision pour être restaurés ?
- Les exclusions invoquées protègent-elles réellement un secret d’affaires sans empêcher ni retarder la sortie ?
- Le délai contractuel commence-t-il au bon événement et distingue-t-il préavis, transition, récupération et effacement ?
- Le devis sépare-t-il frais de changement, service standard, pénalité de résiliation, sortie continue de données et travail de destination ?
- Les critères d’acceptation permettent-ils de juger un résultat comparable sans exiger du fournisseur source une reconstruction qu’il ne contrôle pas ?
- La preuve d’effacement couvre-t-elle les données actives, les copies temporaires et les sauvegardes selon leurs cycles documentés ?
Limites de l’analyse
Cette analyse traite principalement le chapitre VI du Data Act et les services de traitement de données. Elle ne couvre pas en détail l’accès aux données de produits connectés, les demandes du secteur public, les clauses abusives de partage de données ni le régime complet de protection des données personnelles.
Le règlement ne supprime pas les obligations issues du RGPD, du droit des contrats, du secret des affaires ou des règles sectorielles. La qualification d’un service, la validité d’une pénalité et l’étendue d’une obligation peuvent dépendre du contrat et du droit applicable. Une décision contentieuse ou une opération de sortie à fort impact appelle une revue juridique dédiée.
Les recommandations de test, la matrice de preuve et le plan de trente jours sont des propositions méthodologiques de BLACKPROOF. Elles ne sont pas présentées comme des obligations ajoutées par le Data Act.
Les sources ont été contrôlées le 23 juillet 2026. Le statut de la procédure 2025/0360(COD) doit être revérifié avant toute décision fondée sur le Digital Omnibus.