# Note au CSF : plan d'action détaillé sur l'interopérabilité Auteur : Stefane Fermigier (Abilian SAS) Date : 6 novembre 2025 Ce plan d'action vise à structurer une initiative ambitieuse pour faire de l'interopérabilité une réalité sur le marché du cloud, en s'appuyant sur les travaux et réflexions menés au sein de l'écosystème (avec le workshop de septembre à Bercy comme point de départ). L'objectif est de passer de constats partagés à des actions concrètes, en fédérant les acteurs de la filière pour créer et/ou adopter des standards de fait et peser sur le cadre réglementaire. Un objectif de plus haut niveau est de promouvoir et, in fine, de faire adopter, la notion d'**interopérabilité opposable**, garantissant la souveraineté, la concurrence et la liberté de choix pour les utilisateurs. ## Axe 1 : Structuration et promotion de l'initiative Cet axe a pour but de formaliser l'initiative, de définir sa mission et de commencer à diffuser ses objectifs pour mobiliser l'écosystème. 1. **Officialiser le groupe de travail « Interopérabilité »** * **Action :** Rédiger le document de cadrage du groupe de travail. * **Détails :** Ce document fondateur précisera la mission, les objectifs, la gouvernance et la feuille de route du groupe. Il s'appuiera sur les enjeux identifiés : lutter contre le **verrouillage par les fournisseurs (vendor lock-in)**, renforcer la **souveraineté numérique** et maîtriser **la complexité et les coûts**. Il actera l'ambition de ne pas se contenter de recommandations, mais de préparer le terrain pour un cadre réglementaire contraignant, inspiré par des textes comme le **Data Act** (entré en vigueur le 12 septembre 2025) et l'**Interoperable Europe Act**. 2. **Créer et diffuser les supports de l'initiative** * **Action :** Consolider une base documentaire et des supports de communication. * **Détails :** Il s'agit de produire un corpus de contenus pour évangéliser le marché et les institutions : * **Livre blanc :** Un document de synthèse sur les enjeux et la vision, expliquant le concept d'« interopérabilité opposable » et son impact économique. * **Guides de bonnes pratiques :** Des notes techniques destinées aux DSI et architectes, promouvant des patrons d'architecture **cloud-agnostiques** et des designs de microservices qui facilitent la portabilité, à l'image du cas d'Uber capable de changer de IaaS à volonté. * **Argumentaires :** Des fiches synthétiques sur les standards clés (OpenAPI, OCI, OpenTelemetry, etc.) et leur rôle dans la prévention du verrouillage technologique. * **Animation :** Animer un réseau d'experts et d'entreprises pour partager les expériences de migration et collecter les besoins des clients publics et privés. 3. **Organiser les rencontres de l'écosystème et mener des actions d'influence** * **Action :** Planifier et organiser des événements fédérateurs et porter les travaux auprès des instances réglementaires. * **Détails :** * **Événementiel :** Mettre en place des rencontres trimestrielles de l'écosystème pour partager les avancées des chantiers techniques et recueillir les retours du terrain. * **Influence européenne :** Présenter formellement les travaux et recommandations à la **Commission européenne** (notamment à la DG CNECT) pour nourrir les futures régulations. L'objectif est de démontrer que la filière est capable de s'organiser pour proposer des solutions concrètes, renforçant la légitimité d'un cadre réglementaire plus strict. Cela peut notamment être fait en coopération avec la Fondation EuroStack, l'APELL, OpenForum Europe, etc. qui sont pertinents sur ces questions. ## Axe 2 : Chantiers techniques prioritaires Cet axe se concentre sur la définition de standards ouverts et d'API communes pour adresser des points de friction concrets identifiés comme prioritaires pour l'interopérabilité IaaS et PaaS. 4. **Interopérabilité des logs : définir un standard de supervision inter-cloud** * **Action à cadrer :** Lancer un groupe de travail technique pour définir un format de log commun et une API de consultation standard. * **Détails :** Face à l'hétérogénéité des systèmes de logs qui complexifie la supervision multi-cloud, ce chantier vise à : * **Spécifier un format de log unifié :** S'inspirer fortement du standard de fait **OpenTelemetry** et de formats structurés comme **JSON-L**, pour couvrir les logs d'infrastructure et de sécurité (hors logs applicatifs). * **Définir une API de consultation minimale :** Rédiger une spécification **OpenAPI** pour une API RESTful permettant d'interroger, filtrer et récupérer les logs de manière standardisée auprès de n'importe quel fournisseur compatible. * **Livrables :** Spécification technique du format et de l'API, et potentiellement une implémentation de référence open source. 5. **Interopérabilité des secrets : standardiser l'accès via un « coffre-fort européen »** * **Action à cadrer :** Définir une API standard pour le stockage et le partage de secrets (clés d'API, certificats, mots de passe). * **Détails :** La gestion propriétaire des secrets est un point de verrouillage majeur. Ce chantier propose de : * **S'inspirer des solutions existantes :** Analyser les API de solutions comme HashiCorp Vault ou son fork communautaire **OpenBao** pour en extraire un sous-ensemble de fonctionnalités essentielles. * **Publier une spécification d'API :** Créer un standard d'API permettant aux applications de gérer leurs secrets de façon portable, sans dépendre de l'implémentation spécifique du fournisseur de cloud. * **Livrables :** Une spécification OpenAPI décrivant l'API du « coffre-fort », accompagnée de recommandations d'implémentation. 6. **Interopérabilité des infrastructures : vers un langage de description unifié** * **Action à cadrer :** Lancer un chantier de recherche et développement pour la création d'un langage standard de description d'infrastructures et de services cloud. * **Détails :** Il s'agit du chantier le plus stratégique, visant à résoudre le problème de l'absence d'API IaaS unifiée. * **Objectifs :** Ce langage doit permettre de décrire l'architecture d'une application (services, réseaux, stockage, relations) de manière agnostique. Il servira de base pour : * **Garantir la portabilité :** Faciliter la migration d'un cloud à un autre en « recompilant » la description pour la cible. * **Créer un « dataspace » d'infrastructure :** Permettre la collecte et la comparaison des offres des fournisseurs sur une base commune. * **Développer un outillage commun :** Créer des outils pour valider, optimiser et déployer ces descriptions. * **Établir un indicateur d'interopérabilité :** Mesurer objectivement la capacité d'un fournisseur à s'intégrer dans cet écosystème standardisé, un besoin prioritaire identifié lors des ateliers. * **Inspirations :** Les travaux s'inspireront de projets d'abstraction existants comme **CAPI (Cluster API)**, **Crossplane** ou **libcloud**, mais en visant un niveau de standardisation formel et soutenu par la filière. * **Livrables :** Un document de spécification pour le langage, un schéma formel (par exemple, en JSON Schema), et une preuve de concept avec des « compilateurs » pour au moins deux fournisseurs de cloud européens. ## Références - https://cnll.fr/news/interoperabilite-cloud-le-cnll-prend-position/ - https://euro-stack.com/blog/2024/12/interoperability-thoughts - https://euro-stack.com/blog/2025/2/cjeu-vs-google-interoperability - [Réponse du CNLL à la consultation de l’ARCEP](https://pad.cloud.abilian.com/dOlieWAjRZm4ncNv7v34Qg) - [Euclidia response to ARCEP consultation](https://pad.cloud.abilian.com/29b4KEX2TCGHB0OSFUFwtg#) - "L’interopérabilité, clé de l’efficacité collaborative et de la souveraineté" (PDF) - "Notes sur l'étude OPIIEC sur l'Interopérabilité" (PDF)