Le régulateur des télécoms a présenté une recommandation sur l’interopérabilité et la portabilité dans le cloud. Elle reprend les orientations des textes nationaux et européens, mais les différents fournisseurs ne sont pas d’accords sur la méthode.
Pendant que l’Autorité de la concurrence continue son enquête sur le marché du cloud, l’Arcep, en charge de la régulation du secteur vient de dévoiler ses recommandations pour favoriser l’interopérabilité et la portabilité dans le cloud. Cette initiative intervient quelques semaines après l’application du règlement européen sur les données (Data Act) et quelques mois après la loi SREN (sécuriser et réguler l’espace numérique).
Dans son document, le régulateur propose plusieurs moyens pour fluidifier le marché. En premier lieu, les frais de transfert de données seront fixés par l’Arcep et cette dernière a proposé la gratuité. Nonobstant, les principaux fournisseurs de cloud américains ont déjà annoncé la fin des frais de transfert en 2024. Mais il reste d’autres frais souligne l’Arcep qui vont faire l’objet de réflexion, « 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 ». Là encore, certains ont devancé l’appel comme Google avec son offre Data Transfer Essentials, mais pas encore AWS, ni Microsoft.
Des référentiels, OpenAPI et des débats
Toujours dans ses lignes directrices, le gendarme du cloud appelle à la transparence et à la mise en place d’une grille de d’informations harmonisée sur la portabilité et l’interopérabilité des services. Pour cela, il s’est appuyé sur des référentiels comme le code de bonne conduite du Swipo (switching Cloud Providers and Porting Data), un groupe multipartite mis en place par la Commission européenne ou le CISPE. Ce document recense des procédures et des méthodes pour initier une migration depuis et vers un service cloud, pour tester les mécanismes de migration (sauvegarde, restauration et vérification de l’intégrité des données), les outils de supervision, … Par ailleurs, le recours à des API stables est fortement recommandé en s’appuyant sur la spécification OpenAPI. Même si l’Arcep reconnait quelques limites. Ainsi, « lorsque le protocole employé par l’API n’est pas http, la spécification OpenAPI n’est pas applicable ».
Lors des consultations préalables publiques menées par l’Arcep d’autres problèmes ont été soulevés sur OpenAPI. L’Afnum précise par exemple que « les protocoles comme MQTT utilisés pour l’Internet des objets ou des services nécessitant une diffusion bidirectionnelle sur HTTP/2 ne peuvent pas être correctement décrits par OpenAPI ». Dans ce cadre précis, AWS prône l’utilisation de son outil nommé Smithy ou Microsoft plaide pour l’usage de son service TypeSpec et Goolgle mise sur Protocol Buffers. Les discussions ont aussi porté sur le délai de préavis pour mettre à jour les API. La majorité des répondants ont plaidé pour un délai minimal de 12 mois, même si certains ont réclamé des exceptions pour que le préavis soit plus court. C’est le cas lorsqu’une faille de sécurité est découverte dans une API et doit être corrigée au plus vite, notamment en application d’obligations légales.