OpenInterop : état de l'art des standards d'interopérabilité¶

Version 0.3 · 30 octobre 2026 · draft · PDF

Ce document recense les standards, protocoles et formats existants pertinents pour chaque domaine de l'initiative OpenInterop. L'objectif est de ne pas réinventer la roue : pour chaque besoin, identifier les standards existants, suffisants ou à adapter, ainsi que les vrais manques.

Définition retenue d'un standard ouvert (EIFv1, 2004) : une spécification publiée et librement accessible, dont l'usage n'est soumis à aucune restriction juridique ou financière, qui permet des mises en œuvre concurrentes et relève d'une gouvernance indépendante et transparente. Cette définition est conforme à l'article 4 de la LCEN, selon lequel les spécifications techniques d'un standard ouvert sont « publiques et sans restriction d'accès ni de mise en œuvre ». Elle est celle de la doctrine proposée (cf. doctrine, §2 et principe 2), qui exclut les licences FRAND.

Au-delà des interfaces : l'interopérabilité ne se limite pas aux APIs techniques. Elle couvre cinq niveaux, définis dans la doctrine (§2) :

• technique (connectivité) ;
• syntaxique (formats) ;
• sémantique (signification des données) ;
• organisationnel (processus) ;
• juridique (cadres légaux).

Ce document se concentre sur les trois premiers niveaux, mais les contrats sémantiques (comportements attendus au-delà de la simple interface) sont aussi importants que les API.

1. Standards transverses¶

Ces standards sont pertinents pour tous les domaines d'OpenInterop.

1.1 Identité, authentification et autorisation¶

Identité décentralisée et EUDI Wallet¶

Le projet EuroID Connect vise à fournir les outils open source manquants pour l'implémentation d'eIDAS 2.0 : stacks turnkey pour émetteurs/vérificateurs, SDKs pour OpenID4VP, bibliothèques SCIM pour provisioning consenti. L'écosystème européen est encore fragmenté et manque d'outillage accessible aux PME.

Évaluation : Le socle OIDC + OAuth 2.0 (avec les bonnes pratiques du RFC 9700) + SCIM est solide et suffisant pour la plupart des cas d'usage. SAML reste nécessaire pour la compatibilité legacy. eIDAS 2.0 / EUDI Wallet est un chantier stratégique pour le secteur public mais l'outillage open source est encore immature.

1.2 APIs et communication inter-services¶

Formats hypermedia et conventions REST¶

Au-delà d'OpenAPI, plusieurs formats structurent la manière dont les APIs REST exposent leurs ressources et leurs liens :

Évaluation : OpenAPI + REST forme le socle commun. Le choix d'un format hypermedia (HAL, JSON:API, etc.) dépend du contexte ; JSON:API et HAL sont les plus adoptés. AsyncAPI est à promouvoir pour les cas asynchrones. gRPC est très utilisé mais moins interopérable que REST.

1.3 Formats de données généraux¶

1.4 Formats documentaires¶

1.5 Sémantique et données liées¶

1.6 Réseau et transport¶

2. Outils collaboratifs¶

2.1 Gestion documentaire et fichiers¶

Évaluation : WebDAV reste le standard de base pour l'accès aux fichiers. CMIS est mature mais son adoption faiblit. WOPI est un cas intéressant. Microsoft pilote seul la spécification, mais l'écosystème d'implémentations serveur open source s'est diversifié (cs3org/wopiserver, WOPIX, Karadav). La spécification est donc ouverte dans les faits par la pratique ; sa gouvernance la place pourtant hors de la définition du standard ouvert retenue (cf. doctrine, §2 et §6.1). OCM (désormais en cours de normalisation à l'IETF) et CS3APIs, issus de la CS3 Community européenne (depuis 2014, recherche + industrie), apportent la couche manquante de fédération inter-fournisseurs et constituent un précédent direct à articuler plutôt qu'à dupliquer. Pour l'édition souveraine, le consortium Euro-Office développe un fork AGPLv3 d'ONLYOFFICE, brique d'édition libre embarquable (version 1.0 en juin 2026). Annoncé en mars 2026 et emmené par IONOS et Nextcloud, il réunit notamment Abilian, EuroStack, XWiki, OpenProject, Open-Xchange, Soverin, BTactic et Office.EU ; Proton soutient le projet.

2.2 Calendrier, contacts, tâches¶

Évaluation : CalDAV/CardDAV + iCalendar/vCard est un socle solide et bien implémenté. JMAP est prometteur mais l'adoption reste limitée.

2.3 Messagerie et communication¶

Évaluation : Matrix est le standard le plus prometteur pour la messagerie instantanée interopérable, avec une adoption significative dans le secteur public français et européen. ActivityPub ouvre des perspectives pour les usages sociaux / flux d'activité.

2.4 Syndication et flux d'activité¶

2.5 Composition d'interfaces et portlets¶

Évaluation : Le problème de la composition d'interfaces (intégrer des composants issus de plusieurs éditeurs dans une expérience unifiée) n'a pas de standard universel moderne. OpenSocial a tenté de le résoudre pour les portails sociaux mais a été abandonné ; ses concepts vivent dans ActivityPub. Web Components (W3C) est le socle natif côté navigateur. RenderJS et XBlock illustrent des approches intéressantes de composants autonomes et isolés, respectivement document-centric et runtime-à-services. Les patterns micro-frontends (Module Federation, import maps) sont prometteurs mais pas encore standardisés. LTI 1.3 est un bon modèle d'intégration sécurisée d'applications tierces, transposable au-delà de l'éducation.

2.6 Édition collaborative temps réel¶

Évaluation : L'édition collaborative temps réel repose sur des algorithmes (CRDTs, OT) mais il n'existe pas de protocole standard d'interopérabilité entre éditeurs collaboratifs. C'est une lacune potentielle si l'on souhaite que des documents puissent être co-édités entre solutions différentes.

2.7 Recherche et découverte¶

Note : Apache Solr API et Elasticsearch / OpenSearch (Amazon fork) API sont des interfaces de fait de moteurs de recherche d'entreprise, pas des standards d'interopérabilité. Le protocole OpenSearch ci-dessus n'a rien à voir avec le moteur OpenSearch (fork Amazon d'Elasticsearch), son homonyme.

Évaluation : la recherche fédérée d'entreprise (interroger simultanément plusieurs solutions hétérogènes depuis un seul point d'entrée) est un domaine mal standardisé. OpenSearch (protocole) est trop pauvre pour des résultats riches. SRU/CQL est mûr mais cantonné aux bibliothèques ; Solr et Elasticsearch sont des APIs de facto propres à des moteurs spécifiques. MCP émerge mais cible les agents IA. C'est un vrai trou, comparable au constat sur la co-édition.

3. Cloud¶

3.1 Conteneurisation et orchestration¶

Spécifications d'images de conteneurs (OCI)

Plateformes d'orchestration et de virtualisation

Évaluation : Au niveau image (OCI), l'interopérabilité est effective et la gouvernance est neutre. Au niveau orchestration et virtualisation, l'écosystème comprend plusieurs plateformes matures aux paradigmes variés (décentralisé / centralisé, IaaS / virtualisation, conteneurs / VMs). OpenInterop conçoit ses profils d'interopérabilité (SECA, observabilité, secrets…) pour qu'ils restent implémentables au-dessus de chacune. Les vrais problèmes de lock-in se situent au niveau des services managés (cf. 3.4), couche orthogonale à la plateforme d'orchestration retenue.

3.2 APIs de gestion d'infrastructure cloud (Control Plane)¶

L'absence d'API IaaS unifiée est le point de verrouillage structurel du cloud. Plusieurs initiatives tentent d'y remédier :

SECA vs. alternatives : SECA se distingue par son modèle déclaratif (spec/status), son RBAC intégré (JWT + rôles), sa hiérarchie Tenant/Workspace et son alignement avec les pratiques GitOps. OCCI était précurseur mais n'a pas atteint l'adoption critique. OpenStack fournit des APIs de fait mais impératives et liées à une implémentation spécifique.

Complémentarité SECA / TOSCA : TOSCA décrit le "quoi" (topologie applicative), SECA fournit le "comment" (API d'exécution). Un orchestrateur TOSCA pourrait cibler des fournisseurs SECA-compatibles pour une portabilité complète.

3.3 Infrastructure as Code (IaC)¶

Approche fonctionnelle et reproductible (Nix, Guix)

À côté de l'IaC "impératif descriptif" (HCL et dérivés), une approche fonctionnelle issue de la gestion de paquets s'est imposée pour la description déclarative d'environnements et de systèmes complets, avec une garantie de reproductibilité bit-à-bit :

Ces deux approches débordent du périmètre strict de l'IaC pour adresser aussi la supply chain logicielle (cf. 4.2) en fournissant des builds reproductibles par construction.

Note : Terraform, OpenTofu, Pulumi, Crossplane, SlapOS, Nix et Guix sont des logiciels implémentant des approches déclaratives, pas des standards en soi. HCL est l'interface sous-jacente la plus proche d'un standard de fait.

Évaluation : Il n'existe pas de standard d'IaC au sens strict. HCL (via OpenTofu) est le standard de fait pour l'IaC impératif descriptif. TOSCA est trop académique. Nix et Guix offrent une approche fonctionnelle et reproductible complémentaire, avec une forte assise européenne (INRIA pour Guix, Utrecht/NixOS Foundation pour Nix). Un langage de description d'infrastructure unifié et plus simple, soutenu par la filière, pourrait être un livrable OpenInterop (cf. note CSF, axe 2, chantier 6).

3.4 Services managés et portabilité¶

C'est le point de verrouillage principal. Les hyperscalers proposent des services managés propriétaires (bases de données, files d'attente, fonctions serverless, etc.) dont les APIs ne sont pas standardisées.

Standards et approches existants :

3.4.1 Réversibilité du stockage objet¶

Aucun organisme de normalisation (IETF, ISO/IEC, ETSI, CEN) ne travaille sur l'API S3. Les références utiles pour en vérifier la réversibilité relèvent de plusieurs familles : normes de vocabulaire, programmes de tests, formats d'empaquetage et obligations réglementaires.

Le Data Act (chapitre VI, applicable depuis septembre 2025) et la loi SREN fixent les obligations de changement de fournisseur ; les moyens techniques de les vérifier manquent encore. OpenInterop a engagé ce travail lors de l'atelier Track 6 du 9 octobre 2026 : profil de réversibilité, exigences, scorecard et scénarios de test (cf. fiche cloud, §1.4), ainsi qu'un premier kit de test (projet S4).

Lacunes identifiées (chantiers potentiels OpenInterop) :

• Stockage objet : pas de profil ouvert de l'API S3, pas de format d'export standard, pas de suite de tests de réversibilité. Chantier engagé (cf. 3.4.1).
• Logs : pas de standard de format ni d'API de consultation unifié. OpenTelemetry fournit un modèle de données et un protocole (OTLP) stables pour les logs, mais les formats applicatifs restent hétérogènes et aucune API de consultation n'est standardisée. Un format commun + une API OpenAPI de consultation serait un livrable concret (cf. chantier 4 de la note CSF).
• Secrets / coffre-fort : gestion propriétaire des secrets = point de lock-in. L'API de HashiCorp Vault / OpenBao pourrait servir de base à un standard ouvert (cf. chantier 5 de la note CSF).
• API IaaS unifiée : c'est le chantier stratégique. SECA (cf. 3.2) est la tentative européenne la plus récente. Un langage de description agnostique permettant de décrire services, réseaux et stockage, puis de "recompiler" pour chaque cible cloud serait un livrable stratégique (cf. chantier 6 de la note CSF).

3.5 État du marché cloud européen¶

Une matrice compare les fonctionnalités de douze fournisseurs cloud européens (Upcloud, IONOS, Leaseweb, Hetzner, OVH, StackIT, Scaleway, Exoscale, Fuga Cloud, CloudSigma, Open Telekom Cloud, Rapid.Space). Elle montre que :

• Les services de base (VMs, stockage bloc, stockage objet S3-compatible) sont largement disponibles
• Les services d'orchestration managée sont proposés par la majorité des fournisseurs
• Les services avancés (serverless, NoSQL managé, files d'attente, PaaS) sont très inégalement couverts
• L'interopérabilité effective entre fournisseurs européens est limitée : chacun a ses propres APIs pour les services managés

Cela confirme que les chantiers de standardisation les plus urgents se situent au niveau des services managés et de la portabilité applicative, pas au niveau des conteneurs (déjà standardisés).

4. Cybersécurité¶

4.1 Threat intelligence et réponse¶

4.2 Supply chain logicielle¶

Note : Sigstore/cosign sont des logiciels implémentant des mécanismes de signature d'artefacts, pas des standards en soi. Reproducible Builds (initiative et critères) constitue par ailleurs une approche complémentaire à la garantie d'intégrité de la chaîne de build, avec deux gestionnaires de paquets fonctionnels qui en sont des implémentations de référence : Guix (GNU, France/INRIA) et Nix (Pays-Bas, NixOS Foundation), cf. 3.3.

4.3 Sécurité réseau et Zero Trust¶

4.4 Sécurité applicative (WAF)¶

4.5 Cryptographie post-quantique¶

• Agilité cryptographique : les systèmes doivent permettre le remplacement des primitives cryptographiques
• Standards NIST publiés en août 2024 : FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) ; suivi des algorithmes suivants (FN-DSA, HQC)
• Schémas hybrides (classique + post-quantique) recommandés en transition
• Pertinent pour les données à durée de vie >10 ans

Évaluation : Les standards de threat intelligence (STIX/TAXII) et de SBOM (SPDX, CycloneDX) sont matures. Les chantiers OpenInterop en cybersécurité pourraient se concentrer sur l'interopérabilité des SOC (échange d'alertes, formats de logs de sécurité communs) et la standardisation des pratiques SBOM dans la filière.

5. Santé¶

5.1 Échange de données cliniques¶

5.2 Identité et consentement patient¶

5.3 Interopérabilité pharmaceutique et administrative¶

5.4 Cadre réglementaire santé¶

• Espace européen des données de santé (EHDS) : règlement (UE) 2025/327, en vigueur depuis le 26 mars 2025, applicable par étapes à partir de mars 2027 ; impose un format européen d'échange des dossiers de santé informatisés, dont les spécifications techniques seront fixées par actes d'exécution
• CI-SIS (Cadre d'Interopérabilité des SI de Santé, ANS) : référentiel français
• Ségur du Numérique en Santé : programme de financement de l'interopérabilité

Évaluation : FHIR est le standard de référence pour les nouveaux développements. Le secteur santé est l'un des plus avancés en matière de standardisation d'interopérabilité, avec des cadres réglementaires contraignants (EHDS, Ségur). Les chantiers OpenInterop en santé pourraient se concentrer sur les interfaces entre le SI de santé et les outils collaboratifs / cloud (partage sécurisé de documents, messagerie professionnelle interopérable, hébergement HDS).

6. Collectivités locales¶

6.1 Échanges de données et démarches¶

6.2 Données géospatiales¶

6.3 Open Data¶

6.4 Facturation électronique¶

Évaluation : Le domaine des collectivités locales repose largement sur des standards nationaux spécifiques (ACTES, PES, Hélios). L'interopérabilité entre éditeurs de solutions pour collectivités pourrait se concentrer sur : les échanges de données usagers (avec FranceConnect comme socle), la portabilité des données entre solutions de GED/GRC/démarches en ligne et les formats d'échange de données métier (état civil, urbanisme, etc.).

7. Technologies émergentes transverses¶

7.1 Intelligence artificielle¶

7.2 Signatures et confiance numérique¶

8. Synthèse des manques¶

Standards suffisants (à adopter, pas à réinventer)¶

• Identité : OIDC + OAuth 2.0 (avec RFC 9700) + SCIM
• APIs : OpenAPI 3.1+ + REST
• Conteneurs : OCI (gouvernance Linux Foundation neutre). Au niveau orchestration et virtualisation, plusieurs plateformes matures coexistent : CloudStack, Kubernetes, OpenNebula, OpenStack, Proxmox VE, SlapOS, XCP-ng
• Formats documentaires : ODF, PDF, JSON
• Santé : FHIR
• Facturation : Factur-X / EN 16931
• Sécurité transport : TLS 1.3

Standards existants mais adoption insuffisante (à promouvoir)¶

• CalDAV / CardDAV pour le collaboratif
• SCIM 2.0 pour le provisioning d'identités (maillon manquant critique)
• Matrix pour la messagerie interopérable
• OpenTelemetry pour l'observabilité
• SBOM (SPDX / CycloneDX) pour la supply chain
• AsyncAPI pour les échanges asynchrones
• DCAT-AP pour les catalogues de données
• CloudEvents pour les notifications inter-applications
• Sigma pour les règles de détection portables
• OCSF pour les logs de sécurité normalisés
• Nix et Guix pour la description fonctionnelle d'environnements et les builds reproductibles

Lacunes identifiées (chantiers potentiels OpenInterop)¶

Paradigme data-centric vs. app-centric¶

Un constat transversal : la plupart des solutions actuelles suivent une approche app-centric où les données sont enfermées dans les applications, créant des silos et des duplications. L'interopérabilité suppose une transition vers une approche data-centric où les données sont un actif partagé, gouverné indépendamment des applications qui les traitent. OpenInterop doit promouvoir ce changement de paradigme par : - Des formats de données ouverts et des schémas partagés - Des APIs d'exportation/importation complètes et sans dépendances propriétaires - Des mécanismes de portabilité centrés sur les données autant que sur les applications

Références¶

Cadres européens d'interopérabilité¶

• EIF (European Interoperability Framework) — Commission européenne. Une proposition de cadre technique (EIF-TS, projet de l'auteur, voir plus bas) le décline en 7 profils d'interopérabilité concrets. https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/european-interoperability-framework
• EIFv1 (2004) — Définition stricte des normes ouvertes (à privilégier sur l'EIFv2 de 2010). https://ec.europa.eu/idabc/servlets/Docd552.pdf?id=19529
• Interoperable Europe Act — Règlement (UE) 2024/903. https://eur-lex.europa.eu/eli/reg/2024/903
• ETSI, Interoperability Best Practices (2011-2013) — brochure méthodologique sponsorisée par la Commission européenne. Décrit la démarche top-down (objectifs / fonctionnels / détaillés, ITU-T I.130), les proformas ICS/IFS, le langage TTCN-3, le modèle Plugtests™ et la chaîne validation/tests. Les proformas ICS/IFS servent de modèle à la déclaration de conformité, et les Plugtests à l'essai croisé de la doctrine (cf. doctrine).
• ETSI White Paper N°3 — Achieving Technical Interoperability — the ETSI Approach.

Réglementations européennes¶

• Data Act — Règlement (UE) 2023/2854, entré en vigueur le 11 janvier 2024, applicable depuis le 12 septembre 2025. Chapitre VI : changement de fournisseur de services de traitement de données. https://eur-lex.europa.eu/eli/reg/2023/2854
• Cyber Resilience Act — Règlement (UE) 2024/2847. https://eur-lex.europa.eu/eli/reg/2024/2847
• NIS2 — Directive (UE) 2022/2555 sur la sécurité des réseaux et des systèmes d'information. https://eur-lex.europa.eu/eli/dir/2022/2555
• AI Act — Règlement (UE) 2024/1689. https://eur-lex.europa.eu/eli/reg/2024/1689
• eIDAS 2.0 — Règlement (UE) 2024/1183 modifiant le règlement eIDAS. https://eur-lex.europa.eu/eli/reg/2024/1183
• EHDS (European Health Data Space) — Règlement (UE) 2025/327, en vigueur depuis le 26 mars 2025. https://eur-lex.europa.eu/eli/reg/2025/327
• Arrêt CJUE Alphabet e.a. (C-233/23, 25 février 2025) — Une entreprise dominante qui refuse l'interopérabilité de sa plateforme avec l'application d'un tiers peut abuser de sa position ; seules une impossibilité technique ou une atteinte à l'intégrité ou à la sécurité de la plateforme justifient le refus. https://curia.europa.eu/juris/liste.jsf?num=C-233/23

Cadre français¶

• RGI v2.0 (Référentiel Général d'Interopérabilité), approuvé par arrêté du 20 avril 2016 — En vigueur mais reconnu comme "en friche" par le CNLL ; à actualiser. https://www.numerique.gouv.fr/publications/interoperabilite/
• Assemblée nationale, rapport n° 3054 de la commission d'enquête sur les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique, juillet 2026 — Proposition n° 12 : rendre le RGI obligatoire dans les marchés publics.
• LCEN (Loi pour la confiance dans l'économie numérique), 2004 — Définition des normes ouvertes (art. 4). https://www.legifrance.gouv.fr/loda/id/JORFTEXT000000801164
• Circulaire du Premier Ministre du 5 février 2026 sur la commande publique numérique.
• Loi SREN (loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l'espace numérique) — Encadrement des services cloud ; l'ARCEP précise les exigences d'interopérabilité et de portabilité.

Documents de travail OpenInterop / CSF¶

• Stefane Fermigier, "Note au CSF : plan d'action détaillé sur l'interopérabilité", nov. 2025. https://pad.cloud.abilian.com/s/HLoX9YJ7V
• "Plan d'actions CSF Cloud — Synthèse d'idées prospectives", 5 piliers (socle technique, conformité, levier économique/juridique, écosystème, Design Authority, que la doctrine nomme désormais « autorité technique »).
• Stefane Fermigier, "Matrice des fonctionnalités du cloud européen" — Comparaison de 12 fournisseurs européens. https://pad.cloud.abilian.com/s/z3OQJl9ZP
• Stefane Fermigier, "Cadre Interopérabilité Européen – Spécification Technique (EIF-TS)" — Draft de cadre technique modernisé. https://pad.cloud.abilian.com/s/cjGr8FIsT

Prises de position et analyses¶

• Stefane Fermigier, « L'interopérabilité, clé de l'efficacité collaborative et de la souveraineté », Abilian, novembre 2025 — Concept d'interopérabilité opposable, approche data-centric vs. app-centric. https://abilian.com/fr/news/interoperabilite-efficacite-collaborative-souverainete/
• Stefane Fermigier, "A Note on Interoperability" — Analyse des critères EIFv1, processus IETF, interopérabilité opposable. https://pad.cloud.abilian.com/s/PML5HPAYB
• Stefane Fermigier, "Notes sur l'étude OPIIEC sur l'interopérabilité" — RGI en friche, compétences, IA sémantique. https://pad.cloud.abilian.com/s/kIoq65kWU
• CNLL, "Interopérabilité cloud : le CNLL prend position". https://cnll.fr/news/interoperabilite-cloud-le-cnll-prend-position/
• Stefane Fermigier, "Interoperability Thoughts", déc. 2024. https://euro-stack.com/blog/2024/12/interoperability-thoughts

Projets et initiatives¶

• SECA (Sovereign European Cloud API) — API ouverte de gestion d'infrastructure cloud, lancée en mars 2025 par Aruba, IONOS et Dynamo. https://www.secapi.cloud/
• EuroID Connect — Projet d'outillage open source EUDI Wallet / eIDAS 2.0. https://pad.cloud.abilian.com/s/FmVO8D__9
• CS3 Community — Communauté européenne (depuis 2014) de fournisseurs, développeurs et utilisateurs de services Sync & Share et de stockage cloud. 70+ institutions, conférences annuelles. https://www.cs3community.org/
• ScienceMesh — Plateforme d'interopérabilité (IOP) inter-fournisseurs EFSS, pilotée dans le cadre de la CS3 Community. https://sciencemesh.io/
• Reva — Implémentation de référence des CS3APIs (en Go). https://reva.link/
• Euro-Office — Suite bureautique collaborative souveraine (fork AGPLv3 d'ONLYOFFICE) annoncée en mars 2026 par un consortium européen emmené par IONOS et Nextcloud (avec Abilian, EuroStack, XWiki, OpenProject, Open-Xchange, Soverin, BTactic, Office.EU ; Proton en soutien). https://github.com/Euro-Office
• Guix — Gestionnaire de paquets fonctionnel et distribution (projet GNU, France / INRIA) ; builds reproductibles. https://guix.gnu.org/
• Nix / NixOS — Gestionnaire de paquets fonctionnel et distribution (Pays-Bas, NixOS Foundation) ; builds reproductibles. https://nixos.org/
• OpenNebula — Plateforme IaaS unifiée (Espagne), utilisée notamment au CERN. https://opennebula.io/
• OpenStack — Plateforme IaaS open source à forte empreinte européenne (OpenInfra Foundation). https://www.openstack.org/
• Proxmox VE — Plateforme de virtualisation KVM+LXC (Autriche). https://www.proxmox.com/en/proxmox-virtual-environment/
• SlapOS — Orchestration distribuée décentralisée (Nexedi, France) ; utilisée en production par Rapid.Space. https://slapos.nexedi.com/
• XCP-ng — Fork open source de XenServer (Vates, France). https://xcp-ng.org/
• Laboratoire I4C (Interoperability 4 Cloud) — Laboratoire commun IMT-TSP / industriels de l'interopérabilité ; pourrait contribuer à constituer l'autorité technique (cf. doctrine, §7).
• OW2 — Communauté de logiciels libres européenne hébergeant OpenInterop. https://www.ow2.org/
• ETSI — Organisme européen de standardisation (protocoles, télécoms, IoT, eIDAS) ; modèle méthodologique sur la validation/tests (CTI, Plugtests™). https://www.etsi.org/
• Fondation EuroStack. https://eurostack.eu/
• APELL (Association Professionnelle Européenne du Logiciel Libre). https://apell.info/

Documents OpenInterop¶

• Note de vision OpenInterop
• Fiche transverse
• Fiche collaboratif
• Fiche cloud
• Fiche cybersécurité
• Doctrine OpenInterop (proposition)
• Atelier cloud du 9 octobre 2026 (réversibilité du stockage objet), documents de travail