KanawatTH - stock.adobe.com

Actualites

Data Act, SREN : l’Arcep publie des recommandations âprement discutées

Un peu moins d’un mois après l’entrée en application du Data Act, l’Arcep livre ses recommandations en matière « d’interopérabilité et de portabilité » des services cloud. Les fournisseurs consultés, plutôt alignés avec ces principes, n’ont pas manqué de questionner plusieurs points mis en avant par l’Autorité.

Gaétan Raoul
par
Publié le: 03 oct. 2025

L’Autorité de régulation des communications électroniques articule les liens entre le Data Act, entré en application le 12 septembre 2025, et la loi SREN (« Sécuriser et Réguler l’Espace Numérique »), promulguée en mai 2024.

De fait, l’article 64 de la loi française prévoit que les dispositions des articles 27 à 30 (et 33 -1) relatifs au frais de transfert entre cloud et à l’interopérabilité et au multicloud ne s’appliquent que temporairement. Jusqu’au 12 janvier 2027.

La date n’est pas choisie au hasard. Elle correspond à l’application complète du Data Act européen qui interdira la facturation des frais de sortie du cloud. En France, la loi SREN prévoit que l’Arcep fixe, après consultation publique, le montant de ces frais de transfert de données. Ce qu’elle a fait : l’autorité a proposé un montant de « 0 euro » au Gouvernement. « Les travaux se poursuivent sur la rédaction des projets de lignes directrices sur les coûts susceptibles d’être pris en compte dans la détermination, d’une part, des frais de changement de fournisseur autres que ceux liés au transfert de données, et, d’autre part, des frais de transfert de données en cas de multicloud », précise l’Arcep.

L'Autorité anticipe des délais de mise en conformité des acteurs concernés et les possibles chevauchements entre le Data Act et la loi SREN. Elle suggère donc de bonnes pratiques en matière de transparence, d’interopérabilité, de portabilité dans le cloud et d’ouverture des API.

Transparence et interopérabilité des cloud : les recommandations de l’Arcep

Elles ne sont pas contraignantes, mais certaines d’entre elles correspondent à l’application des deux lois.

En matière de transparence, l’Arcep recommande de fournir des informations lisibles par les humains (PDF, Web) et par la machine (fichiers JSON de préférence) sur :

  • Les données brutes et actifs qui peuvent être transférés dans le cadre d’une migration ou d’un usage multicloud ;
  • Les procédures pour amorcer une migration depuis et vers un service cloud ;
  • Les méthodes disponibles pour assurer la migration ou les usages multicloud, ainsi que la sécurisation des données en transit et au repos ;
  • Les procédures de tests, de mécanismes de sauvegarde, de restauration et d’intégrité des données ;
  • Les procédures de continuité de services et de protection contre les pertes de données pendant la migration ;
  • Les processus de résiliation d’un service cloud existant après migration ;
  • Les outils de supervision et leur coût ;
  • Les formats de données disponibles et recommandées ;
  • Les documents de référence des API ;
  • La description des dépendances (code, données, services cloud) et les outils nécessaires à la migration ou l’interconnexion multicloud.

Les fournisseurs d’accord sur le principe, pas sur la méthode

L’Arcep s’appuie là sur les codes de conduite SWIPO (Switch Cloud Providers and Porting Data) IaaS et SaaS formulés par un groupe multipartite animé par la Commission européenne. Elle base également ses recommandations sur le CISPE Cloud Switching Framework, de l’association éponyme. Des suggestions qu’elle a ajustées en fonction des remarques de 14 acteurs consultés du 17 juin au 25 juillet 2025.

En réalité, deux préconisations ont sauté après la consultation publique. Les informations sur les méthodes de migration les plus adéquates selon les volumes de données et sur les délais de migration et durée de transfert de données. Elles ont été jugées peu pertinentes par IBM. D'une part, la migration en ligne (et non par livraison de disques) est en train de s’imposer. D'autre part, il s’avère difficile d’estimer la durée de migration, qui est dépendante de la situation de chaque client. Pour les mêmes raisons, AWS n’était pas « d’accord » avec l’inclusion de ces points dans les recommandations. OVHcloud jugeait lui aussi « complexe » de fournir ces informations aux clients.

Le délai de migration sera pourtant fixé à sept mois maximum, selon le Data Act.

Hexatrust, Numeum, AWS, OVHCloud, IBM insistent aussi sur le fait que certaines informations réclamées dépendent de la « responsabilité du client ». OVHcloud et AWS, Big Blue ont, par ailleurs, commenté la pertinence ou la faisabilité de chaque recommandation. L’AFNUM (Alliance Française des Industries du Numérique) considère que les informations listées ci-dessus ne peuvent être données qu’à titre indicatif. La migration de certaines technologies est impossible, tandis que la situation de chaque client serait différente.

Il n’y a pas d’opposition frontale aux principes fondamentaux de transparence et d’interopérabilité exposés plus haut. Certains acteurs se montrent plus réfractaires que d’autres concernant la méthode. Microsoft estime qu’il serait « excessivement contraignant pour l’industrie » que d’exposer toutes ces informations.

L’AFNUM, Numeum et IBM remarquent que les frameworks SWIPO et du CISPE ne sont pas reconnus par l’ensemble des acteurs de l’industrie. Et d’inciter l’Arcep à s’appuyer directement sur les normes internationales existantes. Pour mémoire, ces normes sont les sources d’inspiration des frameworks. Or, l’association EuroCloud et le Cigref considèrent que SWIPO, issu d’une démarche d’autorégulation du cloud, est un « échec ». L’Arcep, considère que ces frameworks demeurent pertinents pour permettre « aux clients d’exercer leur liberté de choix ».

Même la documentation des API fait débat

L’Arcep fournit deux autres recommandations concernant la mise à disposition d’API « stables et documentées ». D’abord, elle suggère aux fournisseurs de prévenir douze mois à l’avance leurs clients avant l’exécution de mise à jour sans rétrocompatibilité. Avec des exceptions en matière de sécurité, de protection de la propriété intellectuelle ou en lien avec toutes les autres obligations légales. Dans ce cas-là, les clients devraient être notifiés « le plus rapidement possible ». Orange, Dassault Systèmes (Outscale), OVHcloud, Numeum, IBM semblent d’accord sur le principe qui reflète une réalité opérationnelle. Scaleway a suggéré 6 mois. Microsoft ne veut pas de préavis sur la fin des API, considérant que ce serait un « frein à l’innovation ». AWS, plus subtil, suggère un « cadre plus souple ».

La dernière recommandation tient sur l’adoption généralisée d’OpenAPI « ou de spécifications équivalentes ». OpenAPI est un standard de documentation pour les API HTTP. Sur le principe, les fournisseurs sont d’accord. OVHCloud et IBM soutiennent la démarche, mais d’autres ne souhaitent pas qu’OpenAPI devienne obligatoire. Microsoft oppose encore le frein à l’innovation, AWS évoque l’incompatibilité de la norme avec certains services. Numeum a suggéré la notion de « spécifications équivalentes ».

La barrière de l’interopérabilité des services SaaS et PaaS

Mais au-delà des recommandations, plusieurs acteurs pointent une prise en compte partielle des spécificités des services PaaS et SaaS de la part de l’Arcep.

« Netalis souligne que la recommandation ignore une catégorie essentielle de services cloud : la messagerie électronique, pourtant pleinement concernée par les obligations de portabilité prévues par la loi SREN (article 28 II), et couvertes par le périmètre de la consultation », peut-on lire dans la consultation de l’hébergeur basé à Besançon.

« Nous émettons de fortes réserves quant à l’applicabilité de l’ensemble de ces éléments aux services PaaS, et plus encore aux services SaaS. La diversité, la spécialisation et l’ancrage métier des offres SaaS rendent toute tentative d’harmonisation largement illusoire », considère Outscale.  

Numeum fait peu ou prou la même remarque. Orange estime que les services PaaS et SaaS « nécessitent une documentation plus nuancée ». « Par exemple, la migration d’une base de données managée implique non seulement le transfert des données, mais aussi l’adaptation des paramètres de configuration et des processus de maintenance ».

Pour approfondir sur Réglementations et Souveraineté