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.