Le Data Act européen : l'accès aux données par conception et la fin du verrouillage cloud
Le Data Act est le plus discret des règlements européens actuels et l'un des plus structurants. Il n'ajoute pas de bannière à votre site ni d'étiquette à votre produit. Il change à qui appartiennent les données que vos produits génèrent, et fait du changement de fournisseur cloud un droit plutôt qu'une négociation commerciale.
Le règlement (UE) 2023/2854 est applicable depuis le 12 septembre 2025. L'obligation qui exige réellement de l'ingénierie, à savoir concevoir les produits pour l'accès aux données, s'applique à partir du 12 septembre 2026. L'interdiction des frais de changement de fournisseur cloud est complète le 12 janvier 2027.
Si vous construisez des produits connectés ou exploitez un service de traitement de données, celui-ci est sur votre feuille de route, qu'il y figure ou non.
Deux règlements en un
Le Data Act fait deux choses assez différentes, et il est utile de les traiter séparément.
La première partie donne aux utilisateurs de produits connectés un droit sur les données que ces produits génèrent, et un droit de les faire partager avec un tiers de leur choix.
La seconde partie oblige les fournisseurs de services de traitement de données, c'est-à-dire les services cloud et edge, à rendre le passage à un concurrent praticable et, à terme, gratuit.
Les deux visent le même problème : les données générées par les utilisateurs finissent enfermées chez le fournisseur qui les a collectées.
Produits connectés : l'accès aux données par défaut
Un produit connecté est tout objet physique qui obtient, génère ou collecte des données sur son utilisation ou son environnement et peut les communiquer. C'est délibérément large. Véhicules, machines industrielles, matériel agricole, dispositifs médicaux, électroménager, objets portables, compteurs intelligents, systèmes de bâtiment et électronique grand public entrent tous dedans.
Un service connexe est un logiciel qui permet au produit de fonctionner comme prévu, et il est dans le champ au même titre que le matériel.
Ce que les utilisateurs obtiennent
Les utilisateurs ont le droit d'accéder aux données du produit et aux données des services connexes générées par leur utilisation, facilement, en toute sécurité, gratuitement, dans un format complet, structuré, couramment utilisé et lisible par machine. Lorsque c'est techniquement faisable, cet accès doit être direct et continu plutôt qu'un export périodique.
Ils peuvent aussi exiger que le détenteur de données les partage avec un tiers qu'ils désignent. Ce tiers peut être le service d'un concurrent, un réparateur, un assureur ou un fournisseur d'analytique. Le détenteur ne peut pas bloquer cela par des clauses contractuelles, ni utiliser les données partagées pour concurrencer l'utilisateur.
Ce qui change le 12 septembre 2026
À partir de cette date, les produits connectés mis sur le marché et leurs services connexes doivent être conçus et fabriqués de manière que les données du produit et des services connexes soient accessibles à l'utilisateur par défaut et, lorsque c'est pertinent et techniquement faisable, directement.
Ce mot « conçus » fait de ceci une échéance d'ingénierie et non juridique. Une obligation de conception ne se satisfait pas d'un processus de support. Elle doit être dans le produit.
À quoi cela ressemble en travail
Pour la plupart des équipes, l'écart n'est pas dans l'API, il est dans tout ce qui se trouve en dessous.
Modèle de données. Vous devez distinguer les données générées par l'utilisation du produit par l'utilisateur de celles que vous dérivez, enrichissez ou inférez. Les utilisateurs ont un droit sur les premières. Cette distinction n'existe souvent pas dans les schémas actuels, où télémétrie, métriques dérivées et analytique interne cohabitent dans les mêmes tables.
Interfaces d'accès. Une véritable API avec authentification, autorisation, pagination et limitation de débit, plus un parcours en libre-service pour les utilisateurs non techniques. Un CSV envoyé par e-mail sur demande ne satisfait pas « facilement et, lorsque c'est pertinent et techniquement faisable, directement ».
Délégation à un tiers. L'utilisateur peut désigner un destinataire. Cela suppose un modèle de consentement et d'autorisation où l'utilisateur accorde un accès limité à une partie avec laquelle vous n'avez aucune relation, et peut le révoquer. Si votre plateforme n'a pas de notion d'accès délégué, c'est le chantier le plus important.
Traitement des secrets d'affaires. Le règlement tente d'équilibrer accès aux données et protection des secrets d'affaires. Vous pouvez exiger des mesures proportionnées pour préserver la confidentialité et, dans des cas restreints, refuser ou suspendre le partage. Cela doit être une position documentée et défendable plutôt qu'un refus général, et il vaut mieux impliquer vos conseils tôt.
Information précontractuelle. Avant la vente, vous devez indiquer à l'acheteur quelles données le produit génère, comment y accéder, si c'est continu et en temps réel, et si vous comptez les utiliser vous-même. C'est du contenu de fiche produit et de documentation, et cela relève de la même revue que les obligations d'information produit qui arrivent en septembre 2026.
Changement de fournisseur cloud : la fin du verrouillage
La seconde moitié du Data Act vise les services de traitement de données, ce qui couvre IaaS, PaaS et SaaS.
Les fournisseurs doivent :
- Supprimer les obstacles commerciaux, techniques, contractuels et organisationnels au changement.
- Achever un changement dans une période transitoire maximale, généralement 30 jours après un préavis pouvant aller jusqu'à deux mois, prolongeable lorsque c'est techniquement infaisable.
- Prendre en charge l'export de toutes les données et actifs numériques exportables dans un format structuré, couramment utilisé et lisible par machine.
- Fournir des interfaces ouvertes et, pour les services d'infrastructure, une équivalence fonctionnelle après le changement.
- Offrir une période minimale de récupération de 30 jours après résiliation.
Sur les frais, les coûts de changement ont été réduits dès la date d'application et sont totalement supprimés à partir du 12 janvier 2027. Après cette date, un fournisseur ne peut plus rien facturer pour le processus de changement.
Les conditions contractuelles doivent refléter cela, y compris la procédure de changement, la période transitoire, la liste exhaustive des catégories de données exportables et l'assistance offerte.
Si vous achetez des services cloud
C'est un vrai levier, et la plupart des acheteurs ne l'utilisent pas.
Au prochain renouvellement, demandez la clause de changement, les catégories de données exportables et les engagements d'assistance à la sortie. Vous y avez droit. Si la réponse est vague, cela vous renseigne sur la difficulté réelle d'une sortie.
Il vaut aussi la peine de faire un test d'export plutôt que de faire confiance à une page de documentation. Exportez tout, essayez d'en tirer du sens, et voyez si cela reconstituerait réellement votre service ailleurs. L'écart entre ce qu'un fournisseur dit exportable et ce qui est utilisable est généralement l'endroit où vit le verrouillage.
Si vous vendez des services cloud
Il vous faut la clause de changement dans vos contrats, une procédure de changement documentée, un mécanisme d'export produisant quelque chose de réellement utilisable, et un plan pour le point de gratuité de janvier 2027 si vous facturez aujourd'hui des frais de sortie ou d'egress.
La tarification de l'egress mérite une attention particulière. Facturer le trafic sortant est une pratique ancienne du secteur, et la distinction entre frais d'egress ordinaires et frais de changement est de celles que les régulateurs examineront.
Accès du secteur public et conditions interentreprises
Deux points plus modestes à connaître.
Le règlement donne aux organismes publics le droit de demander des données aux entreprises privées en cas de besoin exceptionnel, principalement lors d'urgences publiques. C'est étroit, mais si vous détenez des données d'intérêt public, vous devriez savoir que la procédure existe.
Il introduit aussi un test de déloyauté pour les clauses contractuelles relatives à l'accès et à l'utilisation des données imposées unilatéralement à une autre entreprise. Une clause qui s'écarte grossièrement des bonnes pratiques commerciales n'est pas contraignante. C'est un garde-fou utile contre les clauses de données à prendre ou à laisser dans les contrats fournisseurs.
Ce que nous ferions maintenant
Si vous fabriquez des produits connectés, la date de septembre 2026 devrait déjà être dans un plan de sprint. L'obligation de conception s'applique aux produits mis sur le marché à partir de cette date, donc tout ce qui est en développement est concerné. Commencez par la séparation dans le modèle de données, car tout le reste en dépend.
Si vous exploitez un service de traitement de données, revoyez vos contrats, votre outillage d'export et votre structure tarifaire. Le point de gratuité de janvier 2027 n'est pas loin, et les conséquences sur le chiffre d'affaires demandent une décision au niveau de la direction plutôt qu'en ingénierie.
Si vous achetez des services cloud, utilisez votre levier au renouvellement et testez votre chemin d'export. Cela coûte une journée et vous apprend quelque chose de précieux sur votre risque réel.
Tous les autres devraient tout de même vérifier le périmètre. La définition d'un produit connecté est plus large que l'expression ne le suggère, et des entreprises qui se voient comme éditeurs de logiciel livrent parfois du matériel sans que ce fait soit enregistré en interne.
L'image d'ensemble
Le Data Act fait partie d'un ensemble de règles qui, ensemble, reconstruisent les hypothèses sur lesquelles repose le logiciel européen. Le guide de la conformité numérique européenne 2026 cartographie toute la surface, y compris les échéances qui arrivent en même temps.
Il y a de vrais recoupements à exploiter. Les API d'accès aux données bâties pour le Data Act partagent leur infrastructure avec les demandes de portabilité RGPD. Les inventaires de composants bâtis pour le Cyber Resilience Act vous disent où résident réellement les données produit. Construire cela comme une capacité de plateforme plutôt que trois projets fait la différence entre un trimestre et un an.
Nous concevons et construisons des plateformes de données, des API et de l'infrastructure cloud pour des entreprises opérant en Europe, y compris la mécanique d'accès délégué et d'export que ce règlement présuppose. Si vous voulez de l'aide pour cadrer ce que l'obligation de conception de septembre 2026 signifie pour un produit précis, écrivez à office@c9group.dev, ou lisez-en davantage sur notre travail avec l'infrastructure AWS et l'entrée sur le marché européen.
Nous construisons des systèmes plutôt que de donner des avis juridiques. Le périmètre et les positions sur les secrets d'affaires appartiennent à vos conseils.