Data Act : règlement européen sur l'accès aux données

Mise à jour (mai 2026) : le Data Act est en application directe depuis le 12 septembre 2025 pour la majorité de ses dispositions. Les obligations de portabilité cloud entreront en vigueur le 12 septembre 2026, suivies des exigences d’interopérabilité cloud le 12 septembre 2027. Le Digital Omnibus Package du 19 novembre 2025 propose des allègements ciblés pour les PME et small mid-caps sur le cloud switching, sans remettre en cause la philosophie du texte. La logique de fond demeure : ouvrir l’accès aux données générées par les produits connectés, encadrer les relations entre détenteurs et utilisateurs, et faciliter le changement de fournisseur cloud.

Le règlement Data Act (UE 2023/2854) crée un cadre harmonisé d’accès, d’utilisation et de partage des données générées par les produits connectés et les services associés. Il déplace fondamentalement la question des données : de la protection (assurée par le RGPD) vers l’accès, l’usage, le partage, la portabilité et le pouvoir économique attaché à ces données.

Son angle est moins défensif que celui du RGPD. Là où le RGPD répond à la question « à quelles conditions peut-on traiter des données personnelles ? », le Data Act répond à une autre question : « qui peut accéder aux données générées par les produits et les environnements numériques, et dans quelles conditions ? ». C’est un texte sur le pouvoir économique attaché aux données, autant qu’un texte juridique.

Le constat à l’origine du règlement est frappant : 80% des données industrielles générées dans l’UE ne sont jamais réutilisées. Les fabricants conservent un accès exclusif aux données générées par leurs produits, empêchant utilisateurs et tiers d’en tirer de la valeur. Le Data Act vise à corriger ce verrouillage.

Image de juriste étudiant NIS2, DORA, le cadre cyber européen

Data Act : ce qu’une entreprise doit comprendre immédiatement :

Le Data Act ne protège pas seulement les données, il organise leur circulation. C’est un texte de droit économique numérique autant qu’un texte de conformité.
Le règlement couvre les données personnelles et non personnelles. Données industrielles, données d’usage, données de performance, données de maintenance, données issues d’objets connectés. Le RGPD continue de s’appliquer dès qu’une donnée est personnelle.
Le texte limite la captation exclusive des données par les fabricants et les fournisseurs. L’utilisateur d’un produit connecté ne peut plus être totalement privé de l’accès aux données que son propre usage génère.
Le Data Act crée un droit d’accès et de partage. Les utilisateurs peuvent demander que leurs données soient transmises à un tiers : réparateur, prestataire de maintenance, assureur, service d’analyse, concurrent du fabricant, prestataire cloud alternatif.
Le volet cloud du texte est majeur. Suppression progressive des frais de transfert, garantie de portabilité et d’interopérabilité, réduction du verrouillage fournisseur. Les contrats cloud, SaaS, PaaS et IaaS doivent être revus.
Le Data Act crée un sujet de cybersécurité opérationnel. Plus on ouvre l’accès aux données, plus il faut maîtriser l’authentification, l’autorisation, la traçabilité, la séparation des tenants, la sécurité des API et la protection des secrets d’affaires.
Le règlement oblige à repenser les contrats. Clauses abusives encadrées, conditions FRAND pour le partage B2B, réversibilité documentée, portabilité opposable.
Pour une PME ou une ETI, l’enjeu n’est pas de devenir expert du Data Act. C’est de savoir si elle est détenteur, utilisateur, fournisseur, client ou intermédiaire dans une chaîne de données concernée. La qualification précède la mise en conformité.

Qui est concerné ?

Situation	Concerné par Data Act ?	Niveau d’attention
Fabricant de produits connectés (véhicules, équipements industriels, machines agricoles, objets de santé, domotique, compteurs) Fournisseur de services liés à un produit connecté (applications mobiles, diagnostic, supervision, maintenance connectée)	Oui, en qualité de détenteur de données	Très élevé
Fournisseur de services cloud, SaaS, PaaS, IaaS	Oui, sur les volets portabilité, cloud switching, interopérabilité	Très élevé
Entreprise utilisatrice de produits connectés (industrie, logistique, transport, énergie, santé, agriculture) Prestataire de maintenance, réparation, analyse, optimisation	Oui, en qualité d’utilisateur bénéficiaire	Élevé
Entreprise dépendante d’un fournisseur cloud ou SaaS	Oui, sur la réversibilité, la portabilité, la maîtrise contractuelle	Élevé
Éditeur logiciel, plateforme B2B	À évaluer selon les flux de données générés et contrôlés	Moyen à élevé
Secteur public	Oui, mécanisme d’accès aux données privées en cas de nécessité exceptionnelle	Ciblé
PME ou ETI sans IoT et avec une faible dépendance cloud	Hors champ direct, mais peut être indirectement concerné par la chaîne contractuelle	Faible

Nature juridique du texte

Consulter directement le règlement (UE) 2023/2854.

Règlement européen d’application directe, sans loi de transposition nationale. Le texte s’impose uniformément dans les 27 États membres depuis le 12 septembre 2025 pour la majorité de ses dispositions.

Publié au Journal officiel le 22 décembre 2023, entré en vigueur le 11 janvier 2024, le règlement laisse aux acteurs concernés une période de préparation de 20 mois avant l’application principale. Cette période a été utilisée par les grands fabricants automobiles, les industriels et les hyperscalers cloud pour préparer leurs mécanismes d’accès et leurs nouveaux modèles contractuels. Beaucoup de PME et d’ETI ont en revanche découvert le texte tardivement, et continuent leur mise en conformité au-delà de septembre 2025.

Le nom officiel complet est « Règlement (UE) 2023/2854 du Parlement européen et du Conseil du 13 décembre 2023 concernant des règles harmonisées portant sur l’équité de l’accès aux données et de l’utilisation des données ». On parle aussi parfois de « Data Act » tout court, ou de « règlement données ».

Les sanctions sont fixées par les États membres, qui doivent désigner des autorités nationales compétentes et calibrer leur arsenal répressif. En France, la désignation de l’autorité compétente n’était pas encore finalisée à la date d’application principale, ce qui crée une zone d’incertitude opérationnelle.

Le texte n’est pas isolé. Il s’inscrit dans la stratégie européenne des données qui inclut également le Data Governance Act (2023), le règlement sur les services numériques (DSA), le règlement sur les marchés numériques (DMA), et l’AI Act. L’ensemble vise à structurer une économie européenne de la donnée plus ouverte, plus concurrentielle et moins dépendante des grands acteurs extra-européens.

Présentation générale

Le Data Act répond à une évolution fondamentale du paysage numérique. Les objets, les machines, les services, les applications et les infrastructures produisent désormais des volumes considérables de données. Mais ces données sont massivement captées par celui qui fabrique le produit, contrôle la plateforme, fournit le service, héberge l’environnement, maîtrise l’API ou définit le format. Cette captation freine l’innovation, la concurrence, la réparation, la maintenance, et le développement de services alternatifs.

L’Europe a choisi d’intervenir directement sur ces déséquilibres. Le règlement organise quatre grandes ruptures.

Premier mouvement : un droit d’accès aux données IoT.

Quand un utilisateur achète ou utilise un produit connecté, le fabricant doit concevoir le produit de sorte que les données générées soient accessibles à cet utilisateur, facilement, gratuitement, dans un format structuré et lisible par machine. Cela vaut pour les voitures connectées (données du véhicule, télémétrie, diagnostic), les montres de santé, les thermostats intelligents, les machines industrielles à capteurs, les bulldozers, les téléviseurs et même les réfrigérateurs connectés. L’idée est que les données générées par votre usage ne peuvent plus être la propriété exclusive du fabricant.

Deuxième mouvement : un droit de partage avec des tiers.

L’utilisateur peut demander que ses données soient transmises à un tiers de son choix : un autre prestataire de maintenance, un service d’optimisation énergétique, un assureur, un concurrent du fabricant, une plateforme d’analyse. Cette mécanique vise à briser le verrouillage de la chaîne de valeur. Un agriculteur dont le tracteur connecté envoie ses données à John Deere peut désormais demander que ces données soient également transmises à un éditeur tiers qui propose des services agronomiques différenciés.

Troisième mouvement : un encadrement des contrats B2B.

Quand un détenteur partage des données avec un tiers à des fins commerciales, ce partage doit se faire selon des conditions FRAND (Fair, Reasonable And Non-Discriminatory). Les clauses contractuelles imposées unilatéralement et créant un déséquilibre manifeste sont nulles de plein droit. Les PME bénéficient d’un accès aux données sans frais. C’est probablement la disposition la plus radicale du texte : elle rend inapplicables des pratiques contractuelles courantes du marché numérique B2B.

Quatrième mouvement : la portabilité cloud et l’interopérabilité.

Les fournisseurs de services cloud, SaaS, PaaS et IaaS doivent supprimer progressivement les frais de transfert (switching fees), garantir la portabilité des données et des actifs numériques, et faciliter le changement de fournisseur. L’objectif est de réduire le verrouillage écosystémique pratiqué par les hyperscalers et les grands éditeurs SaaS.

Concernant le secteur public.

Le texte prévoit également un mécanisme d’accès du secteur public aux données privées en cas de nécessité exceptionnelle (urgence publique, catastrophe naturelle, pandémie). Cet accès est temporaire, ciblé, et soumis à des garanties strictes. La logique de fond reste qu’en situation de crise, les données privées peuvent avoir une utilité publique.

Contexte et champ d’application

Le Data Act n’est pas tombé du ciel. Il répond à plusieurs constats convergents accumulés depuis 2018.

Le verrouillage des données IoT.

Les fabricants d’objets connectés ont développé des modèles économiques qui captent l’intégralité des données générées par l’usage de leurs produits. Ces données alimentent leurs propres services après-vente (maintenance, optimisation, assurance) tout en restant inaccessibles aux utilisateurs et aux concurrents. Pour une grande entreprise utilisatrice de machines connectées, c’était souvent un acte de foi : on paie l’équipement, mais on n’a pas accès aux données qu’il produit en fonctionnement.

La domination du cloud par quelques acteurs.

Trois hyperscalers américains (AWS, Azure, Google Cloud) captent une part dominante du marché européen. Le verrouillage technique et contractuel (formats propriétaires, frais de sortie élevés, dépendance aux services managés) rend les migrations coûteuses voire impraticables. Pour les régulateurs européens, c’est devenu un sujet de souveraineté économique.

La domination du SaaS.

Au-delà du cloud d’infrastructure, les grands éditeurs SaaS (Salesforce, Workday, Microsoft, Oracle) ont construit des plateformes dont la réversibilité réelle est faible. L’export des données est techniquement possible mais opérationnellement difficile, et les coûts de migration sont prohibitifs.

L’inégalité contractuelle B2B.

Les grands fournisseurs imposent leurs conditions générales à leurs clients PME et ETI. Les clauses asymétriques (limitation de responsabilité, propriété des données dérivées, restrictions d’usage) sont la norme du marché. Le Data Act introduit pour la première fois un contrôle européen des clauses abusives dans les contrats numériques B2B.

Le champ d’application du règlement est large et structuré autour de plusieurs cercles concentriques.

Cercle 1 : les produits connectés

Tous les objets physiques connectés qui obtiennent, génèrent ou collectent des données concernant leur utilisation ou leur environnement. Pas de seuil de taille, pas d’exclusion sectorielle large. Une montre connectée, un capteur industriel, un véhicule électrique, un compteur intelligent, tout est dans le champ.

Cercle 2 : les services liés aux produits connectés

Les applications, plateformes, services d’analyse et services de support qui sont nécessaires au fonctionnement, à l’usage ou à l’exploitation d’un produit connecté. Un fabricant ne peut pas contourner le règlement en délocalisant l’intelligence du produit dans une application séparée.

Cercle 3 : les services de traitement des données

Cloud, edge, SaaS, PaaS, IaaS. Le volet portabilité et cloud switching s’applique à tous les fournisseurs de services de traitement de données accessibles dans l’UE, indépendamment de leur localisation.

Cercle 4 : les contrats B2B impliquant des données

Toute relation commerciale entre une entreprise détentrice de données et une autre entreprise qui demande l’accès. L’encadrement des clauses abusives s’applique horizontalement.

Cercle 5 : l’accès public exceptionnel.

Les autorités publiques peuvent demander l’accès à des données détenues par des acteurs privés en cas de nécessité exceptionnelle. Ce mécanisme reste rare et encadré, mais il existe.

En synthèse :

Pour une PME ou une ETI, la question n’est donc pas binaire. Une même entreprise peut être à la fois utilisatrice (bénéficiaire d’un droit d’accès aux données de ses propres équipements), détentrice (devant ouvrir l’accès aux données de ses produits), cliente d’un fournisseur cloud (bénéficiaire des nouvelles règles de portabilité) et fournisseur SaaS elle-même (soumise aux obligations de portabilité). La qualification est rarement simple.

Accès aux données IoT :

(voir chapitre II, articles 3 à 7). Les fabricants de produits connectés et les fournisseurs de services associés doivent concevoir leurs produits de sorte que les données générées soient accessibles à l’utilisateur. Cet accès doit être facile, gratuit, et dans un format structuré, couramment utilisé et lisible par machine. Les fabricants doivent également informer clairement les utilisateurs, avant l’achat, sur la nature des données générées, leur volume, leur fréquence de production, et les modalités d’accès.

Concrètement, un constructeur automobile doit prévoir une interface (généralement une API) permettant au propriétaire du véhicule d’accéder à ses données de conduite, de télémétrie et de diagnostic. Cette interface doit être documentée, fonctionnelle, et accessible sans frais. Le constructeur ne peut plus se contenter de proposer l’accès à ses propres services après-vente.

Partage avec des tiers :

(voir chapitre II). L’utilisateur peut demander que ses données soient transmises à un tiers de son choix. Le détenteur ne peut refuser sans motif sérieux, et doit organiser le partage selon des conditions techniques et contractuelles claires. Le tiers destinataire devient à son tour soumis à des obligations d’usage limité : il ne peut utiliser les données que pour les finalités convenues avec l’utilisateur, et ne peut pas les transmettre lui-même à un quatrième acteur sans nouvel accord.

Cette mécanique ouvre théoriquement la voie à un marché européen de services tiers sur données IoT. En pratique, elle reste freinée par la difficulté technique du partage (les API existent rarement avec le bon niveau de granularité) et par la résistance commerciale des fabricants. Les premiers contentieux structurants sont attendus en 2026-2027.

Conditions FRAND pour le partage B2B :

(voir chapitre III). Quand un détenteur partage des données avec un tiers à des fins commerciales, les conditions doivent être équitables, raisonnables et non discriminatoires. Le terme FRAND, emprunté au droit des brevets, désigne ici un ensemble de critères d’équité applicables à la négociation : prix raisonnable, absence de discrimination entre destinataires comparables, transparence des modalités.

Les PME bénéficient d’un accès sans frais aux données, ce qui constitue une asymétrie volontaire en leur faveur. Les clauses contractuelles imposées unilatéralement et créant un déséquilibre manifeste sont nulles de plein droit. Cette nullité est invocable par la partie faible, sans avoir besoin d’attendre une décision administrative.

Accès du secteur public :

(voir chapitre V). En cas de nécessité exceptionnelle (urgence publique, catastrophe naturelle, pandémie), les organismes du secteur public peuvent demander l’accès à des données détenues par des acteurs privés. Cet accès est temporaire, ciblé, soumis à des garanties strictes de proportionnalité et de confidentialité. Il ne s’agit pas d’une porte ouverte à la surveillance, mais d’un mécanisme de crise dont l’usage devrait rester rare.

Changement de fournisseur cloud :

(voir chapitre VI). Suppression progressive des frais de transfert de données (switching fees) : le règlement prévoit la disparition complète des frais d’ici janvier 2027. Pendant la période transitoire (2026), les frais doivent être plafonnés au coût réel supporté par le fournisseur. Obligation d’information précontractuelle sur les modalités de sortie, les formats d’export, les délais. Obligation d’assistance à la migration. Garantie de portabilité fonctionnelle des données et des actifs numériques.

Interopérabilité :

(voir chapitre VIII). Application à partir du 12 septembre 2027. Les fournisseurs de services cloud devront respecter des exigences d’interopérabilité technique pour permettre aux clients de fonctionner simultanément avec plusieurs fournisseurs, ou de migrer plus facilement. Les détails techniques seront précisés par actes d’exécution et par les espaces européens de données (data spaces) sectoriels.

Le Data Act ne prescrit pas une architecture technique unique. Il pose des thèmes que les actes d’exécution, les espaces européens de données sectoriels et les normes techniques précisent au fur et à mesure.

API et mécanismes d’accès :

Pour les détenteurs de données (fabricants, fournisseurs de services liés), construire des API sécurisées, documentées, traçables, exploitables par l’utilisateur ou un tiers autorisé. Standardisation des formats d’export (JSON, CSV, formats sectoriels comme ODX pour l’automobile). Documentation publique des endpoints, des schémas de données, des limites d’usage.

Gestion des identités et des autorisations :

Le sujet critique est de s’assurer que celui qui demande l’accès est légitime. Cela suppose une authentification forte (idéalement adossée à terme à l’EUDI Wallet quand celui-ci sera déployé), une gestion fine des mandats et délégations, une durée d’autorisation limitée et révocable, une journalisation complète, une séparation claire des rôles entre utilisateur, détenteur et tiers destinataire.

Séparation des données :

Maîtriser la frontière entre données utilisateur, données fournisseur, données personnelles, données non personnelles, secrets d’affaires, données de sécurité, données agrégées et données dérivées. Cette séparation est rarement simple dans les environnements SaaS et IoT où les données s’enchevêtrent au fil des couches techniques. Pour un éditeur SaaS qui mêle données client et données d’usage agrégées, la cartographie devient un préalable à toute mise en conformité.

Protection des secrets d’affaires :

Le règlement reconnaît l’existence de secrets d’affaires légitimes qui peuvent justifier des restrictions d’accès. Mais ces restrictions doivent être documentées, proportionnées, et ne pas servir de prétexte général. La pratique en cours d’émergence consiste à classifier finement les données par type de sensibilité et à documenter une justification précise pour chaque catégorie qui resterait fermée.

Portabilité cloud :

Pour les fournisseurs cloud, repenser l’export, la migration, les formats, les dépendances techniques, les frais (qui doivent disparaître), la réversibilité, l’assistance, la documentation et la continuité de service pendant la migration. C’est une extension réglementaire de sujets que les meilleures pratiques contractuelles couvraient déjà depuis longtemps, mais qui devient désormais opposable.

Gouvernance contractuelle :

Revoir l’ensemble des clauses : droits d’accès, droits d’usage, restrictions, transmission à des tiers, responsabilités, sécurité, confidentialité, réversibilité, audit, délais, frais. Identifier les clauses potentiellement abusives au regard des critères du chapitre IV et les réécrire. Pour les groupes ayant des centaines de contrats fournisseurs et clients, c’est un chantier juridique significatif.

Supervision et journalisation :

Toute mise en œuvre du Data Act génère mécaniquement plus de flux de données et plus de surfaces d’API. La supervision (SIEM, SOC, détection d’anomalies sur les API, limitation de débit) devient un prérequis. L’absence de supervision sur des API ouvertes au public est une faute opérationnelle, pas seulement une faiblesse technique.

Date	Étape
23 février 2022	Proposition initiale de la Commission européenne
13 décembre 2023	Adoption du règlement par le Parlement et le Conseil
22 décembre 2023	Publication au Journal officiel de l’Union européenne
11 janvier 2024	Entrée en vigueur
12 septembre 2025	Application de la majorité des dispositions (accès IoT, partage avec des tiers, conditions FRAND, accès du secteur public)
19 novembre 2025	Publication du Digital Omnibus Package, qui propose des allègements ciblés pour PME et small mid-caps sur le cloud switching
12 septembre 2026	Application des obligations de portabilité cloud (suppression progressive des frais de transfert, garantie d’assistance à la migration)
Janvier 2027	Suppression complète des switching fees prévue
12 septembre 2027	Application des exigences d’interopérabilité cloud
2026-2028	Montée en maturité des pratiques contractuelles, premiers contentieux structurants, clarifications par les autorités nationales

Point de réalisme : la date du 12 septembre 2025 a été un signal fort mais elle n’a pas marqué une rupture binaire. Beaucoup d’acteurs continuent leur mise en conformité, et l’absence de désignation claire de l’autorité nationale compétente en France crée une zone d’incertitude. Les premiers contentieux structurants devraient apparaître sur 2026-2027, vraisemblablement sur les conditions FRAND et sur la portabilité cloud. La période 2027-2028 verra l’émergence d’une jurisprudence européenne qui clarifiera l’interprétation des dispositions les plus ouvertes (notion d’équité, périmètre des secrets d’affaires, étendue des obligations d’interopérabilité).

RGPD. L’articulation la plus structurante. Le Data Act n’abroge pas le RGPD. Dès qu’une donnée est personnelle, l’accès, le partage et le transfert doivent respecter l’intégralité du régime RGPD : base légale, information, minimisation, droits des personnes, sécurité, encadrement des sous-traitants, transferts hors UE. Le Data Act ouvre l’accès, le RGPD encadre le traitement. La tension centrale est d’ouvrir sans surexposer. Une entreprise qui doit transmettre des données IoT à un tiers à la demande d’un utilisateur doit vérifier si ces données sont personnelles, et le cas échéant s’assurer que le tiers offre un cadre RGPD conforme.

Data Governance Act (DGA). Texte jumeau du Data Act dans la stratégie européenne des données. Le DGA, applicable depuis septembre 2023, organise les mécanismes de gouvernance, l’intermédiation des données, l’altruisme des données et le partage volontaire. Le Data Act crée les droits et obligations concrets d’accès, d’usage, de partage et de portabilité. Les deux textes forment le socle de l’économie européenne de la donnée. Le DGA pose le cadre de confiance, le Data Act distribue les droits.

NIS2. Articulation indirecte mais structurante. Le Data Act augmente potentiellement les flux, les API et les accès tiers. Il crée de nouveaux points d’attention NIS2 sur la sécurité des interfaces, la gestion des fournisseurs, la traçabilité, la résilience, le contrôle des accès, la gestion des incidents. Une entité NIS2 qui met en œuvre le Data Act doit intégrer les nouvelles surfaces d’attaque dans son plan de gestion des risques.

DORA. Articulation forte pour les entités financières. Sur le cloud switching, la réversibilité, la concentration fournisseur, la dépendance SaaS, les contrats ICT et la continuité d’activité, DORA et Data Act convergent largement. DORA pousse à maîtriser les prestataires ICT critiques avec une supervision directe par les autorités européennes. Le Data Act donne un cadre plus horizontal à la portabilité et à la réduction du verrouillage fournisseur. Une banque qui négocie un contrat cloud bénéficie désormais des deux régimes simultanément.

AI Act. Articulation croissante. L’IA a besoin de données pour s’entraîner et fonctionner. Le Data Act peut faciliter l’accès à certains jeux de données industriels ou d’usage qui étaient verrouillés par les fabricants. Mais l’AI Act encadre les risques des systèmes d’IA à haut risque. Point de tension : plus les données circulent, plus il faut gouverner leur usage pour l’entraînement, l’inférence, la réutilisation, la qualité et la traçabilité.

CRA (Cyber Resilience Act). Complémentarité forte. Le CRA concerne la cybersécurité des produits comportant des éléments numériques (objets connectés, logiciels, équipements). Le Data Act concerne les données générées par ces mêmes produits. Les deux textes se rejoignent sur la conception sécurisée, la documentation, les obligations fabricant, la sécurité des produits numériques et la gestion du cycle de vie.

Cybersecurity Act. Articulation utile sur la certification. Les schémas européens de certification (EUCC, EUCS quand il sera adopté, EUMSS) peuvent servir à démontrer que les mécanismes d’accès, de partage ou de portabilité sont sécurisés. La certification ne remplace pas la conformité Data Act mais elle alimente la preuve.

eIDAS 2. Articulation à venir sur l’authentification et la délégation. Le portefeuille européen d’identité numérique (EUDI Wallet) peut devenir un outil important pour authentifier les utilisateurs qui demandent l’accès à leurs données, prouver des mandats, gérer des délégations à des tiers, sécuriser l’accès à certains services de données. Le déploiement effectif de l’EUDI Wallet en 2027 devrait faciliter techniquement la mise en œuvre des droits Data Act.

DSA et DMA. Philosophie commune de réduction des asymétries de pouvoir dans l’économie numérique. Le DMA vise les gatekeepers et la contestabilité des marchés. Le DSA vise les plateformes en ligne. Le Data Act vise les fabricants de produits connectés et les fournisseurs cloud. Les trois textes participent à un même mouvement de rééquilibrage.

ePrivacy. Reste pertinent dès que les données concernent les communications électroniques, les terminaux, les cookies, les traceurs ou les métadonnées de communication. Le Data Act ne s’y substitue pas.

Pour la vue d’ensemble du cadre cyber européen et de ses articulations, voir Le cadre réglementaire cyber.

Le paquet Digital Omnibus publié par la Commission le 19 novembre 2025 propose des ajustements ciblés sur le Data Act, sans remettre en cause sa philosophie. Le mouvement va vers la simplification administrative pour certains acteurs, pas vers un allègement de fond.

Allègements ciblés pour PME et small mid-caps sur le cloud switching :

La Commission propose des exemptions ou aménagements pour les fournisseurs de services cloud de taille modeste qui auraient du mal à supporter le coût des nouvelles obligations de portabilité. L’idée est d’éviter que les obligations conçues pour discipliner les hyperscalers ne pénalisent involontairement les fournisseurs européens alternatifs. La logique est défendable mais le périmètre exact des exemptions reste à préciser dans les actes adoptés.

Réduction des chevauchements avec d’autres textes :

Le Digital Omnibus cherche à clarifier l’articulation du Data Act avec le RGPD, le DGA, le DSA et l’AI Act, pour éviter les doublons d’obligation et les notifications redondantes. C’est cohérent avec la logique générale du paquet, qui vise à rationaliser l’empilement réglementaire numérique européen.

Pas de changement sur le fond :

Le Data Act reste applicable depuis le 12 septembre 2025. Le droit d’accès aux données IoT, le droit de partage avec des tiers, l’encadrement FRAND, l’accès public exceptionnel et les obligations de portabilité cloud sont maintenus dans leur architecture. Le calendrier des dispositions cloud (septembre 2026 et septembre 2027) n’est pas modifié à ce stade.

Conclusion :

Pour une entreprise concernée, le message est simple : poursuivre la mise en conformité sans attendre les éventuelles modifications. Les allègements Digital Omnibus, s’ils sont adoptés, viendront marginalement adoucir l’exécution pour les petits acteurs, mais ne changent pas la trajectoire générale.

La première question pour une PME ou une ETI n’est pas « sommes-nous experts du Data Act ? » mais « où nous situons-nous dans la chaîne de données ? ». La réponse détermine entièrement la trajectoire. Une même entreprise peut être simultanément utilisatrice (bénéficiaire de nouveaux droits sur ses propres équipements), détentrice (devant ouvrir l’accès aux données qu’elle génère), cliente cloud (bénéficiaire des nouvelles règles de portabilité) et fournisseur SaaS (soumise aux obligations de portabilité). Quatre rôles, quatre logiques différentes.

Cinq situations couvrent l’essentiel des cas PME/ETI. Identifiez la vôtre avant tout chantier de mise en conformité.

Situation 1 : vous fabriquez ou vendez des produits connectés :

Capteurs industriels, équipements médicaux connectés, dispositifs domotiques, machines agricoles connectées, terminaux de paiement intelligents, objets professionnels avec télémétrie. Vous êtes pleinement dans le champ, en qualité de détenteur de données. C’est probablement la situation la plus structurante, parce qu’elle vous oblige à reconcevoir l’architecture de vos produits pour ouvrir l’accès aux données qu’ils génèrent.

Les chantiers concrets : conception d’API documentées et sécurisées permettant à l’utilisateur d’accéder à ses données, mise en place de mécanismes d’authentification et d’autorisation, formats d’export structurés, information précontractuelle claire sur les données générées, révision des conditions générales pour intégrer les nouveaux droits. Pour un fabricant d’équipement industriel ETI vendant en France et en Europe, comptez 12 à 24 mois et un budget projet de 100 000 à 500 000 euros selon la complexité des produits et l’état initial des API. La partie la plus coûteuse n’est pas le développement technique, c’est la refonte des modèles économiques quand l’accès aux données après-vente était un revenu récurrent.

Situation 2 : vous éditez un service SaaS ou vous opérez une plateforme cloud :

ERP cloud, CRM SaaS, plateforme de gestion sectorielle, outil de productivité, service d’analyse de données. Vous êtes concerné par le volet portabilité et cloud switching, applicable à partir du 12 septembre 2026 pour la portabilité et du 12 septembre 2027 pour l’interopérabilité. Les exemptions Digital Omnibus pour les PME pourraient adoucir certaines obligations, mais leur périmètre exact reste à préciser.

Les chantiers concrets : suppression progressive des frais de sortie (au plus tard janvier 2027), documentation publique des formats d’export, capacité d’assistance à la migration, information précontractuelle sur les modalités de réversibilité, refonte des CGV pour aligner sur les exigences FRAND. Tester réellement la portabilité avec un client pilote est une bonne pratique, parce que la plupart des éditeurs découvrent en faisant que leurs exports ne fonctionnent pas en pratique sur le client final. Pour une PME éditeur SaaS, l’investissement se situe entre 30 000 et 150 000 euros selon la taille de la base clients et la maturité technique de départ.

Situation 3 : vous utilisez des équipements connectés en exploitation :

Industrie, logistique, transport, énergie, santé, agriculture, bâtiments intelligents. Vous êtes utilisateur bénéficiaire du Data Act, et c’est plutôt une bonne nouvelle. Vous pouvez désormais exiger l’accès aux données générées par vos propres équipements, et demander leur transmission à un tiers de votre choix.

Les chantiers concrets sont plus légers que dans les deux situations précédentes : identifier les équipements connectés exploités, dresser la liste des données qu’ils génèrent et qui vous étaient inaccessibles, négocier ou exiger l’accès auprès des fournisseurs, intégrer ces données dans vos propres outils d’analyse ou les transmettre à un prestataire alternatif (maintenance prédictive, optimisation énergétique, analyse comparative). L’investissement est faible en absolu (10 000 à 50 000 euros pour une démarche structurée sur l’ensemble du parc), mais la valeur économique potentielle est élevée. Une PME industrielle qui récupère les données de son parc machine peut ouvrir un marché à des prestataires de maintenance alternatifs et faire jouer la concurrence là où elle était captive du constructeur.

Situation 4 : vous êtes fortement dépendant d’un fournisseur cloud ou SaaS :

PME ou ETI dont l’activité repose sur un hyperscaler unique (AWS, Azure, Google Cloud), un éditeur SaaS dominant (Salesforce, Microsoft 365, Workday) ou un cloud sectoriel propriétaire. Vous bénéficiez directement des nouvelles règles de portabilité, mais vous devez aussi structurer une démarche de réversibilité réelle.

Les chantiers concrets : cartographier les dépendances techniques et contractuelles, identifier les services managés propriétaires qui rendraient une migration coûteuse, négocier dès maintenant des plans de sortie documentés, exiger l’information précontractuelle Data Act pour tout nouveau contrat ou renouvellement, tester périodiquement la portabilité des données critiques. Pour une PME ETI moyennement dépendante d’un fournisseur cloud principal, le chantier réversibilité représente quelques dizaines de milliers d’euros et 6 à 12 mois pour aboutir à une démarche crédible. Le retour sur investissement n’est pas dans la migration elle-même (qui n’aura probablement pas lieu) mais dans la position de négociation contractuelle qu’elle vous donne.

Situation 5 : vous êtes prestataire de services tiers sur données IoT :

Maintenance prédictive, optimisation énergétique, analyse de performance, services de cybersécurité, benchmarking, conseil métier. Le Data Act ouvre potentiellement un marché énorme pour votre activité, parce que vos clients peuvent désormais exiger que les données de leurs équipements vous soient transmises.

Les chantiers concrets : structurer une offre Data Act-compatible, documenter votre capacité à recevoir et traiter des données IoT dans le respect du RGPD et des secrets d’affaires des fabricants, contractualiser proprement avec vos clients pour gérer les responsabilités, sécuriser vos environnements de réception (un prestataire tiers qui se fait pirater devient le maillon faible de la chaîne). C’est davantage un sujet commercial qu’un chantier de conformité défensive. Beaucoup de prestataires ne se sont pas encore positionnés sur cette opportunité, ce qui laisse une fenêtre commerciale ouverte aux premiers entrants.

Cinq principes communs aux cinq situations :

1er principe : la qualification précède la mise en conformité :

Une demi-journée passée à clarifier précisément vos rôles dans chaque chaîne de données vaut souvent mieux qu’un projet de six mois mal calibré. Beaucoup d’entreprises se lancent dans des chantiers techniques avant d’avoir cartographié leur position juridique, et se retrouvent à sur-investir sur certaines obligations tout en ignorant d’autres.

2ème principe : les contrats sont le levier le plus immédiat :

Avant même de toucher à l’architecture technique, revoyez vos contrats fournisseurs et clients en cours. Identifiez les clauses potentiellement abusives au regard du chapitre IV du règlement. Pour les contrats à renouveler ou à signer, intégrez systématiquement les clauses Data Act-compatibles : information précontractuelle, droit d’accès, droit de partage avec des tiers, portabilité, plan de sortie, formats d’export. C’est rapide, peu coûteux, et ça vous protège.

3ème principe : ne séparez pas Data Act et RGPD :

Les deux régimes coexistent et s’imbriquent. Ouvrir l’accès aux données IoT sans vérifier si certaines données sont personnelles est une erreur fréquente. Documentez la frontière entre données personnelles et non personnelles dans vos systèmes, et appliquez le bon régime à chaque flux.

4ème principe : la cybersécurité est un préalable, pas un complément :

Chaque nouvelle API ouverte, chaque nouveau flux de partage, chaque nouvelle délégation d’accès est une surface d’attaque supplémentaire. Pour une PME qui n’avait pas de SOC ni de supervision API, le Data Act impose de structurer ces capacités avant ou en parallèle de l’ouverture, pas après. Une fuite de données causée par une API Data Act mal sécurisée serait à la fois un sinistre RGPD, un manquement NIS2 si vous êtes assujetti, et un échec commercial.

5ème principe : pensez le Data Act comme un avantage concurrentiel, pas comme une charge :

Les entreprises qui se positionneront tôt sur les nouvelles opportunités (services tiers sur données IoT, propositions de portabilité agressive pour gagner des clients SaaS, valorisation des données auparavant captives) prendront une longueur d’avance. La conformité défensive vous protège des sanctions. L’usage offensif du règlement vous fait gagner des marchés.

L’écueil le plus dommageable serait de considérer le Data Act comme un sujet purement juridique. Les entreprises qui le délèguent à leurs équipes juridiques sans impliquer la DSI, le RSSI, les achats et les directions métier produisent des CGV conformes mais des architectures techniques qui n’ouvrent rien. La conformité documentaire ne suffit pas. Le règlement sera évalué sur la réalité opérationnelle de l’accès, du partage et de la portabilité.

Le Data Act renvoie aux États membres pour la définition du régime de sanctions. Le règlement impose que ces sanctions soient effectives, proportionnées et dissuasives, mais il ne fixe pas de plafonds harmonisés comparables à ceux du RGPD ou de NIS2.

Sanctions administratives nationales :

Chaque État membre désigne une ou plusieurs autorités compétentes et calibre son arsenal. En France, la désignation n’est pas finalisée à mai 2026, ce qui crée une zone d’incertitude pour les acteurs. Les autorités candidates probables incluent la DGCCRF (sur le volet contrats abusifs), la CNIL (sur le volet données personnelles), et l’ARCEP (sur le volet cloud et interopérabilité). Un dispositif multi-autorités est probable.

Cumul avec le RGPD :

Quand un manquement Data Act implique des données personnelles, les sanctions RGPD peuvent s’appliquer en parallèle. Pour un opérateur cloud qui ne respecterait pas ses obligations de portabilité concernant des données personnelles de ses clients européens, le cumul peut être significatif. Les amendes RGPD pouvant atteindre 20 millions d’euros ou 4% du chiffre d’affaires mondial, le risque combiné devient sérieux.

Nullité de plein droit des clauses abusives :

C’est probablement la sanction la plus immédiate et la plus structurante. Une clause contractuelle imposée unilatéralement et créant un déséquilibre manifeste est nulle, sans qu’une décision administrative ou judiciaire soit nécessaire. La partie faible peut l’invoquer directement. Pour un grand fournisseur cloud ou un éditeur SaaS, cela signifie que des clauses standard utilisées avec des milliers de clients PME peuvent être contestées simultanément.

Risques contractuels et commerciaux :

Au-delà de la sanction administrative, le risque réel pour une entreprise non conforme se trouve dans le contentieux contractuel, le blocage commercial, la perte de clients qui exigent désormais des garanties de portabilité, l’impossibilité de répondre à un appel d’offres qui inclut des clauses Data Act-compatibles. Pour un éditeur SaaS qui n’a pas anticipé la portabilité, le coût commercial peut largement dépasser la sanction administrative.

Effet réputationnel :

Encore émergent en 2026, mais probable à mesure que les premiers cas publics apparaîtront. Un fournisseur cloud qui se voit imposer la modification de ses CGV après un contentieux Data Act subira un signal négatif sur le marché européen.

À ce stade (mai 2026), aucune sanction Data Act significative n’a été prononcée en France. Les premières décisions structurantes sont attendues sur 2027-2028, probablement sur les conditions FRAND et sur les manquements à la portabilité cloud.

Le Data Act est un texte de données, mais il crée des obligations directes en cybersécurité. C’est probablement la dimension la plus sous-estimée du règlement.

Plus d’accès signifie plus de surface d’attaque :

Chaque nouveau mécanisme d’accès aux données devient une API à sécuriser, une identité à vérifier, un droit à limiter, un flux à journaliser, un abus potentiel à détecter. Pour un fabricant qui ouvre l’accès aux données de millions d’objets connectés, c’est une multiplication massive des surfaces d’exposition.

La sécurité devient une condition de l’ouverture :

L’entreprise doit éviter deux erreurs symétriques. Bloquer tout accès au nom de la sécurité, ce qui contrevient au règlement. Ouvrir trop largement au nom de la conformité, ce qui crée des fuites de données. La voie pratique consiste à construire une ouverture contrôlée : authentification forte, autorisation granulaire, minimisation des données partagées, chiffrement en transit et au repos, journalisation, supervision, limitation de débit, détection d’abus, contractualisation précise avec les tiers destinataires.

Les secrets d’affaires doivent être protégés sans devenir un prétexte :

Le règlement reconnaît la sensibilité des secrets d’affaires, mais il faudra justifier sérieusement les restrictions. Cela suppose une classification fine des données, une analyse de risque pour chaque catégorie, des mesures techniques documentées, une procédure d’arbitrage entre juridique, cybersécurité et métier. Une approche trop large des secrets d’affaires sera contestable.

La portabilité cloud rejoint la résilience opérationnelle :

Le Data Act converge ici avec DORA et NIS2. Une entreprise mature doit savoir où sont ses données, comment les exporter, dans quels formats, avec quels délais, vers quel fournisseur alternatif, avec quelles pertes fonctionnelles, et avec quels risques de sécurité pendant la migration. La portabilité n’est pas une simple question contractuelle. C’est une capacité opérationnelle qui doit être testée régulièrement, comme un PRA.

Le rôle du RSSI devient transversal :

Le Data Act est l’un de ces textes qui obligent à faire travailler ensemble juridique, DPO, RSSI, DSI, achats, métiers, product owners et cloud architects. Le RSSI ne peut plus être uniquement le défenseur du périmètre interne. Il devient un acteur de la gouvernance des données ouvertes, ce qui modifie sa relation avec les directions métier et avec la direction générale.

Pour les fabricants d’objets connectés, le défi est encore plus pointu. Beaucoup de produits ont été conçus sans considération sérieuse pour la sécurité (mots de passe par défaut, pas de mise à jour, pas d’API sécurisée). Le Data Act expose ces faiblesses en imposant des accès qui n’existaient pas, et le CRA ajoutera ses propres exigences sur le cycle de vie sécurité du produit. Pour un fabricant traditionnel qui découvre la cybersécurité, c’est une refonte profonde des pratiques d’ingénierie.

Où en êtes-vous sur le Data Act ?

Le Data Act n’est pas un sujet de conformité ponctuelle. C’est une transformation des modèles économiques numériques qui impose de revoir simultanément les contrats, les architectures techniques, la gouvernance des données et la cybersécurité. Les entreprises qui s’en sont saisies tôt utilisent désormais le règlement comme un levier de négociation contre leurs fournisseurs cloud et comme une opportunité d’accéder à des données qui leur étaient fermées. Celles qui attendent vont découvrir, contrat après contrat, qu’elles ont perdu du terrain.

Quelques questions concrètes pour situer votre maturité :

Savez-vous quelles données vos produits, services ou fournisseurs génèrent réellement, et qui peut y accéder aujourd’hui ?
Avez-vous identifié votre rôle dans chaque chaîne de données : utilisateur, détenteur, fabricant, fournisseur de service lié, fournisseur cloud, client cloud, destinataire tiers ?
Vos contrats cloud et SaaS vous permettent-ils vraiment de sortir, ou seulement de croire que vous le pouvez ? Avez-vous testé la portabilité au-delà de la documentation contractuelle ?
Pouvez-vous ouvrir l’accès aux données générées par vos produits connectés sans créer une nouvelle fuite de données ou exposer vos secrets d’affaires ?
Vos API de partage sont-elles gouvernées, journalisées, sécurisées, et alignées avec votre cadre NIS2 ou DORA ?
Vos clauses contractuelles sur les données résisteraient-elles à un examen Data Act, notamment celles imposées à vos clients PME ?
Votre stratégie data protège-t-elle seulement vos droits, ou prépare-t-elle aussi votre réversibilité et votre résilience opérationnelle ?

Radical-SSI accompagne les entreprises sur l’ensemble de la trajectoire Data Act : qualification des rôles, cartographie des flux de données concernées, revue des contrats cloud et SaaS, conception des mécanismes d’accès et de partage sécurisés, gouvernance des données ouvertes, articulation avec NIS2, DORA, RGPD et AI Act, trajectoire concrète pour une PME ou une ETI.

Prenons rendez-vous pour une consultation sans engagement.

Pour la vue d’ensemble du cadre européen, voir Le cadre réglementaire cyber.

Partagez cette page via :

Data Act – Règlement européen sur l’accès et le partage des données