L’Arcep change de ton dans le cloud. Avec sa nouvelle recommandation sur l’interopérabilité et la portabilité, l’Autorité entend poser les bases d’un marché plus fluide et mieux aligné sur les ambitions européennes du Data Act. Derrière la transparence technique et la documentation des API, c’est la possibilité même de quitter un fournisseur dominant qui se joue.
Le document publié par l’Arcep balise le terrain réglementaire à venir, dans le sillage de la loi SREN et à peine trois semaines après l’entrée en vigueur du règlement européen sur les données. Loin d’un texte purement consultatif, il cristallise la volonté du régulateur de rendre la réversibilité des services cloud crédible et opérationnelle. L’Arcep s’y appuie sur les contributions de l’écosystème pour pousser trois exigences structurantes : clarifier les conditions de migration, encadrer les modifications d’API, et imposer des formats d’export lisibles et standards.
Un autre signal fort accompagne cette publication, l’Autorité propose de plafonner à 0 € les frais de transfert de données en cas de changement de fournisseur. Selon elle, ce coût est aujourd’hui négligeable lorsque la migration respecte les conditions prévues par le Data Act. Le message implicite est clair : les barrières à la sortie doivent être levées, ou dénoncées comme telles.
Une trame commune pour éclairer les migrations cloud
La première recommandation concerne la transparence. L’Arcep invite les fournisseurs à publier une grille d’information harmonisée sur la portabilité et l’interopérabilité de leurs services : outils de transfert, formats exploitables, dépendances critiques, délais d’export ou restrictions techniques connues. Cette grille, proposée en JSON, s’inspire des référentiels SWIPO et CISPE. Elle vise à donner aux entreprises la possibilité d’évaluer concrètement les efforts à fournir pour changer de fournisseur. Lancée par la Commission européenne dans le cadre du Règlement sur la libre circulation des données non personnelles en 2018, Switch and Portability of data (SWIPO) est une initiative pour encadrer les pratiques des fournisseurs cloud et faciliter le changement de prestataire et la récupération des données. CISPE (Cloud Infrastructure Services Providers in Europe) est l’association professionnelle européenne qui regroupe plusieurs fournisseurs d’infrastructure cloud opérant en Europe.
Pour nourrir cette recommandation, l’Arcep a mené une consultation publique au cours de l’été 2025. Les principaux fournisseurs de services cloud opérant en France, AWS, Microsoft, Orange, OVHcloud, Dassault Systèmes (Outscale), Scaleway, Hexatrust ou encore Eurocloud, ont été invités à réagir aux propositions de l’Autorité, notamment sur les modalités d’interopérabilité, de portabilité et de documentation des services. Certaines contributions sont techniques, d’autres plus politiques. Toutes traduisent les positions stratégiques des acteurs concernés dans un marché en recomposition.
Vers une stabilité contractuelle des API
Scaleway se félicite de cette approche structurante : « L’Arcep joue un rôle clé dans l’animation concurrentielle du marché, via la levée des barrières techniques et tarifaires au changement de fournisseur ». Pour l’opérateur, cette transparence devient un levier stratégique face aux géants du cloud. À l’inverse, Orange insiste sur la nécessité d’enrichir la documentation pour refléter la complexité réelle des environnements cloud : « Une application critique typique combine des services IaaS, PaaS et auxiliaires. Il faut documenter les interdépendances, les flux multiples de données, les impacts de performance. »
L’Arcep propose également un cadre pour encadrer l’évolution des interfaces. Toute modification d’API non rétrocompatible devrait être précédée d’un préavis de douze mois. Cette exigence permettrait aux utilisateurs de tester les nouvelles versions, d’adapter leurs configurations, et de garantir une continuité de service, y compris dans des environnements critiques.
Dassault Systèmes (Outscale) juge cette proposition équilibrée, mais appelle à distinguer les usages : « Il est irréaliste d’imposer une portabilité intégrale sur les couches PaaS et SaaS ». L’éditeur distingue les API utilisées en continu (authentification, accès) des API activées ponctuellement pour migrer (export ou bascule). Le même niveau d’exigence ne peut s’appliquer aux deux. Orange, de son côté, soutient le préavis de 12 mois, qu’il estime aligné sur les cycles de mise à jour des grands systèmes : « La planification débute souvent 6 à 8 mois avant, suivie de tests, validation et stabilisation ».
Faire d’OpenAPI une passerelle vers l’interopérabilité
Pour documenter ces API de façon standardisée, l’Arcep recommande d’adopter la spécification OpenAPI, ou une équivalence lisible par machine. Plusieurs acteurs français, dont Hexatrust, se montrent favorables à cette approche, tout en appelant à une certaine prudence. « Il serait risqué d’isoler les fournisseurs français si le Data Act venait à privilégier une autre norme », rappelle l’association, qui plaide pour une exigence de métamodèle ouvert plutôt qu’un format.
OVHcloud insiste de son côté sur la nécessité de « ne pas figer les pratiques industrielles », et d’adopter une documentation suffisamment souple pour s’adapter aux évolutions technologiques. Scaleway, plus direct, considère qu’OpenAPI répond aux attentes actuelles du marché et qu’il constitue un compromis acceptable entre standardisation et flexibilité.
Portabilité : donner corps à la réversibilité
Au-delà des API, l’Arcep entend donner corps à une portabilité effective. Cela suppose de publier, en plus des formats d’export, des éléments sur la durée de migration, la granularité des données récupérables, les services résiliables, et les coûts associés. Sur ce point, Orange estime que cette documentation doit rester proportionnée : « Le format JSON proposé ne doit pas devenir une charge réglementaire de plus. Il doit rester un outil d’aide au choix. »
OVHcloud exprime une position plus offensive : « Il faut permettre aux clients de migrer sans engager un chantier d’ingénierie lourd ou recréer de zéro leur environnement ». Ce plaidoyer pour une portabilité accessible correspond à une stratégie plus large de différenciation face aux géants américains, perçus comme verrouillant l’accès aux données à travers des formats propriétaires, des dépendances intégrées et des coûts de sortie dissuasifs.
Les fournisseurs américains temporisent, sans contester le fond...
AWS, Microsoft et Google ont également répondu à la consultation, avec un ton mesuré, mais révélateur. Aucun ne s’oppose frontalement à la démarche de l’Arcep : tous reconnaissent la légitimité d’un cadre de transparence, mais cherchent à en influencer le rythme et la portée. Microsoft explique ainsi que « toute obligation légale d’utiliser une technologie donnée, aussi populaire soit-elle, pourrait freiner l’innovation et ralentir la croissance économique ». L’éditeur préfère des recommandations souples plutôt qu’un standard imposé, rappelant l’évolution passée du marché : « Les acteurs avaient adopté SOAP/XML dans les années 2010 avant que REST ne s’impose ; l’histoire montre qu’il faut garder la porte ouverte à la prochaine innovation. »
L’argument est connu : laisser le marché choisir la meilleure technologie. Pourtant, l’histoire récente de l’informatique regorge de contre-exemples : de nombreux standards imposés ont justement permis d’accélérer l’innovation et d’éviter la fragmentation. Le protocole TCP/IP, imposé par le Département de la Défense américain dans les années 1980, a unifié les réseaux militaires et universitaires, ouvrant la voie à Internet. Les standards du Web définis par le W3C (HTML, HTTP, CSS) ont empêché la domination d’un navigateur unique et rendu le Web universel. Il en va de même pour les protocoles 4G et 5G, où la concurrence sauvage des protocoles aurait rendu la connectivité chaotique et l’itinérance exorbitante. Ces exemples rappellent qu’une normalisation peut devenir un moteur d’efficacité collective, à condition qu’elle fixe un socle d’interopérabilité sans brider la différenciation des services.
... pour se ménager une marge de manœuvre
Pour sa part, AWS adopte une position comparable : l’entreprise ne conteste pas la transparence exigée, mais estime que les pratiques contractuelles existantes suffisent déjà à garantir la portabilité. Dans sa réponse, le fournisseur évoque « des mécanismes de sortie éprouvés » et des « outils de migration standardisés disponibles pour la majorité des services ». En creux, le message est clair : pas besoin d’intervention publique supplémentaire. Google, pour sa part, soutient le principe de portabilité, mais insiste sur « la nécessité de préserver la diversité des architectures » et de ne pas réduire l’innovation à une conformité documentaire.
Ces prises de position ne visent pas tant à s’opposer au régulateur qu’à garder la main sur la définition des standards. En se montrant coopératifs, mais prudents, les hyperscalers se ménagent une marge de manœuvre pour adapter leurs propres écosystèmes, et, le moment venu, influencer les spécifications européennes que la Commission pourra rendre obligatoires dans le cadre du Data Act.
Convergence réglementaire : éviter l’éclatement européen
Enfin, l’Arcep positionne clairement cette recommandation comme une brique dans l’édifice européen en construction. Depuis le 12 septembre, le Data Act encadre les contrats cloud, impose des obligations de portabilité et d’interopérabilité, et autorise la Commission à rendre certaines normes contraignantes. La France a d’ailleurs anticipé certaines de ces mesures dans la loi SREN, dont plusieurs dispositions sont transitoires jusqu’en janvier 2027.
En s’alignant sur ces textes tout en gardant une posture de préfiguration, l’Arcep veut pousser les fournisseurs à s’autoréguler avant qu’un cadre plus strict ne leur soit imposé. Ceux qui jouent la transparence aujourd’hui se positionnent pour modeler les futures règles ; ceux qui temporisent prennent le risque de subir des obligations uniformes sans possibilité d’adaptation.
