L’échéance approche : le 19 novembre, la Commission européenne devrait présenter son « omnibus numérique ».

Un brouillon, non daté, a filtré avant l’heure. Il est proposé d’y amender 5 textes :

• Data Act (règlement 2023/2854)
• RGPD (règlement 2016/679)
• AI Act (règlement 2024/1689)
• ePrivacy (directive 2002/58/EC)
• SRI 2 (directive 2022/2555)

Il s’agit aussi d’en abroger 4 :

• Data Governance Act (règlement 2022/868)
• Directive Open Data (2019/1024)
• Règlement sur la libre circulation des données à caractère non personnel au sein de l’UE (2018/1807, dit FFDR)
• Règlement promouvant l’équité et la transparence pour les entreprises utilisatrices de services d’intermédiation en ligne (2019/150, dit P2B)

Le Data Act va « absorber » plusieurs autres textes

Data Governance Act, directive Open Data et règlement FFDR seraient consolidés au sein du Data Act. Une démarche d’autant plus logique, à en croire Bruxelles, que ces textes se chevauchent sans que leurs interactions soient toujours claires. Le FFDR, par exemple, a en partie été remplacé par le chapitre VI du Data Act (relatif au changement de services de traitement de données). Quant au chapitre II du Data Governance Act (réutilisation de certaines catégories de données détenues par des organismes du secteur public), il complète les dispositions de la directive Open Data.

La proposition d’omnibus numérique identifie quatre éléments « importants » pour assurer un équilibre entre disponibilité des données et droits/intérêts de leurs détenteurs  :

• Nécessité de renforcer les garde-fous contre le risque de fuite de secrets commerciaux vers des pays tiers dans le contexte des dispositions sur le partage de données des produits connectés
• Risque d’ambiguïtés juridiques au vu du périmètre étendu du cadre business-to-government
• Risque d’incertitude en lien avec les exigences essentielles pour les smart contracts exécutant des accords de partage de données
• Insuffisance de prise en compte, dans le cadre du changement de fournisseur de traitement de données, des services adaptés aux besoin d’un client ou fournis par des PME/small caps

Vers la fin des exigences sur les smart contracts

Les exigences concernant les smart contracts se trouvent au chapitre VIII du Data Act (« Interopérabilité »). Elles touchent au contrôle de l’accès, à l’archivage des données, à la résiliation en toute sécurité, etc. L’omnibus numérique les supprimerait.

Données IoT : une protection renforcée du secret des affaires

Le chapitre II du Data Act régit le partage de données relatives aux produits connectés et aux services connexes. Actuellement, il permet à un détenteur de données de refuser de les communiquer au nom du secret des affaires s’il démontre qu’il existe un risque de préjudice économique grave.
L’omnibus numérique ajouterait un motif de refus supplémentaire : l’existence d’un risque élevé d’acquisition ou d’usage par des pays tiers qui ne garantissent pas un niveau de protection des données équivalent à celui de l’UE.

Un régime « spécial très grandes entreprises » pour l’open data public

Une simplification du cadre business-to-government serait effectuée au niveau du chapitre V du Data Act. Celui-ci régit la mise à disposition de données au bénéfice d’organismes du secteur public, de la Commission européenne, de la BCE ou d’un organe de l’UE « sur le fondement d’un besoin exceptionnel ».
L’omnibus numérique préciserait le champ d’application en remplaçant « besoin exceptionnel » par « urgence publique ».

La fusion des dispositions de la directive Open Data et du Data Governance Act en un chapitre sur la réutilisation des données du secteur public s’accompagnerait d’évolutions. Parmi elles, la possibilité de facturer plus l’accès aux très grandes entreprises – en première ligne, les « contrôleurs d’accès » tels que définis dans le DMA – et d’y assortir des conditions spécifiques.
En parallèle, les règles du Data Governance Act concernant certaines catégories de données protégées seraient introduites dans le Data Act sous forme simplifiée, avec une clarification sur les règles applicables dans les cas où des données personnelles ont été rendues anonymes.

Des facilités pour les PME qui fournissent de services traitement de données…

Le changement de fournisseur de traitement de données est encadré par le chapitre VI du Data Act.

L’omnibus numérique créerait un régime spécifique plus « léger » pour les services « personnalisés » (non commercialisés sur étagère et qui ne fonctionneraient pas sans une adaptation préalable aux besoins de l’utilisateur) à l’exception du IaaS. Ceux faisant l’objet d’un contrat signé avant le 12 septembre 2025 ne seraient soumis à aucune des obligations du chapitre (information, bonne foi, transparence sur les accès internationaux…) sauf celle relative à la suppression progressive des frais de changement.

Ce régime s’appliquerait aussi aux services fournis – dans le cadre de contrats signés avant cette même date – par des PME et des small caps. Ces dernières auraient la possibilité d’inclure, dans les contrats à durée déterminée, des pénalités de résiliation anticipée.

… et pour les fournisseurs de services d’intermédiation de données

L’omnibus numérique incorporerait dans le Data Act deux régimes actuellement inscrits dans le Data Governance Act. D’une part, le chapitre III, qui impose une notification des autorités compétentes par les prestataires de services d’intermédiation de données. De l’autre, le chapitre IV, qui établit un mécanisme d’enregistrement volontaire des organismes altruistes en matière de données au sein de registres publics nationaux.

Vu la nature émergente des services d’intermédiation de données, leurs prestataires ne devraient pas être obligés de notifier les autorités, estime Bruxelles. Le brouillon de l’omnibus numérique va dans ce sens. Il élimine par ailleurs l’obligation de séparation juridique vis-à-vis d’autres services, la remplaçant par une exigence de séparation fonctionnelle.
En ce qui concerne les organisations altruistes en matière de données, les obligations de transparence et de reporting seraient supprimées.

Règlement FFDR : un seul principe préservé

Du règlement FFDR ne serait conservé qu’un principe : celui qui interdit les exigences de localisation des données sauf si elles sont justifiées par des motifs de sécurité publique.

Illustration générée par IA

The post Omnibus numérique : le grand chantier du Data Act appeared first on Silicon.fr.

Il y a SWIPO et OpenAPI ; point n’est besoin de réinventer la roue.

On pourrait résumer ainsi les recommandations de l’Arcep sur l’interopérabilité et la portabilité des services cloud.

En toile de fond, la loi SREN (« sécuriser et réguler l’espace numérique »), promulguée en mai 2024. Elle a introduit de manière anticipée dans le droit français certaines mesures du Data Act, qui ne serait applicable qu’au 12 septembre 2025.

L’article 28 impose aux CSP de se conformer à des exigences d’interopérabilité et de portabilité, tout en fournissant gratuitement des API pour mettre en œuvre ces exigences. L’idée est de favoriser à la fois les usages multiclouds et le changement de fournisseur.

La loi SREN charge l’Arcep de préciser les règles et les modalités de mise en œuvre des exigences. Notamment par l’édiction de spécifications.
L’autorité a finalement opté pour des bonnes pratiques, en l’objet de cette recommandation « dépourvue de toute portée normative ». Elle laisse ainsi la main à la Commission européenne pour élaborer les spécifications en question. Plusieurs éléments ont motivé ce choix. Les contributions à la consultation publique menée entre octobre et décembre 2024 en sont un. Le calendrier d’application de la loi SREN en est un autre (les dispositions sur l’interopérabilité ne s’appliqueront que jusqu’au 12 janvier 2027). Tout comme les délais que supposerait la mise en conformité à d’éventuelles règles contraignantes auxquelles pourraient, de surcroît, se superposer des actes d’exécution de Bruxelles.

L’Arcep s’en remet au socle SWIPO

En matière d’interopérabilité et de portabilité, une majorité de contributions à la consultation publique a suggéré de prendre en compte des travaux déjà menés au sein du secteur. En première ligne, les codes SWIPO (Switching Cloud Providers and Porting Data). L’initiative a pris fin, mais l’écosystème en reconnaît encore largement la pertinence. L’Arcep en a par conséquent repris les grandes lignes, à commencer par celles du code relatif au IaaS. Elle invite les CSP à publier, dans un format libre (page web ou PDF) et dans un format lisible par ordinateur, les informations suivantes :

1. Données (brutes ou dérivées) et actifs numériques qui peuvent être transférés dans le cadre d’une migration ou d’une utilisation simultanée des services de différents fournisseurs
2. Procédures pour initier une migration depuis le service cloud
3. Procédures pour initier une migration vers le service cloud
4. Méthodes (téléversement, API, expédition de disques) disponibles pour la migration et l’utilisation simultanée des services de différents fournisseurs, y compris les protections disponibles (chiffrement) et les restrictions et limitations techniques connues ; méthodes pour garantir la sécurité des données lors du transfert (contrôle d’accès, authentification des utilisateurs, confidentialité et intégrité)
5. Procédures pour tester les différents mécanismes de migration, notamment ceux de sauvegarde (snapshot), de restauration (rollback) et de vérification de l’intégrité des données
6. Processus disponibles pour garantir l’intégrité des données, la continuité de service et prévenir la perte de données pendant la migration
7. Processus de résiliation d’un service cloud existant, lorsque le client souhaite mettre fin à son utilisation du service après la migration
8. Outils de supervision disponibles pour la migration et coûts associés à leur usage
9. Formats disponibles, recommandés ou utilisés dans le cadre d’une migration ou d’une utilisation simultanée des services de différents fournisseurs, ainsi que les spécifications et la documentation relatives à ces formats
10. Référence de la documentation des API permettant de la mise en œuvre de la portabilité et de l’interopérabilité
11. Description et documentation des dépendances, dont les bibliothèques de code, les données connectées à d’autres services cloud du fournisseur, et les services et outils tiers nécessaires à l’export des données dans le cadre d’une migration ou d’une utilisation multicloud

API : un préavis de 12 mois pour les mises à jour sans rétrocompatibilité

Pour ce qui est de la mise à disposition d’API stables et documentées, des contributions ont mis en avant la spécification OpenAPI, utilisée par quantité de fournisseurs cloud. L’Arcep a considéré que la promouvoir permettrait d’éviter des adaptations majeures et d’assurer une certaine flexibilité. Elle laisse toutefois la voie ouverte à l’adoption de specs équivalentes, notamment dans le cas d’API ne reposant pas sur le protocole HTTP.

Par rapport à la version préliminaire de ses recommandations, soumises à consultation en juin-juillet 2025, l’autorité a précisé la notion de rétrocompatibilité. Elle estime que celle-ci n’est pas garantie si une mise à jour :

• provoque l’échec d’une requête ou d’une opération qui aurait préalablement réussi ;
• obliger les clients ou les fournisseurs tiers à prendre des mesures pour éviter une interruption de service ;
• ou suppriment une caractéristique ou une fonctionnalité du service utilisée par les clients ou les fournisseurs tiers.

L’Arcep conseille, en cas d’exécution de mises à jour sans rétrocompatibilité, d’avertir les utilisateurs au moins 12 mois en amont. Sauf s’il existe des obligations légales ou des impératifs en matière de sécurité (découverte d’une faille dans une API).

Illustration © VICHIZH – Adobe Stock

The post Loi SREN : l’Arcep se raccroche à SWIPO et OpenAPI appeared first on Silicon.fr.

Le Data Act s’applique dès septembre 2025. Accès, portabilité et contrats : un tournant européen majeur aux forts enjeux cyber et économiques.