Fiche détaillée, domaine 1 : outils collaboratifs¶

Version 0.3 · 30 octobre 2026 · draft · PDF

1. État de l'art¶

1.1 Paysage des solutions en France¶

L'écosystème français des outils collaboratifs comprend une vingtaine d'éditeurs significatifs, parmi lesquels Abilian, BlueMind, EXO, Jalios, Jamespot, Linagora, Netframe, Talkspirit, Whaller, Wimi, Oodrive, LucCA, XWiki, etc. Des projets open source européens (Collabora, LibreOffice, Element/Matrix, Nextcloud, Rocket.Chat) et des initiatives consortiales comme Euro-Office complètent ce paysage.

Euro-Office est un fork d'ONLYOFFICE (AGPLv3) annoncé en mars 2026 par un consortium européen emmené par IONOS et Nextcloud, avec notamment Abilian, EuroStack, XWiki, OpenProject, Open-Xchange, Soverin, BTactic et Office.EU ; Proton soutient le projet. Il répond aux préoccupations de souveraineté et de gouvernance soulevées par l'éditeur original. La version 1.0 est parue le 9 juin 2026. L'éditeur d'ONLYOFFICE conteste le respect de sa licence par le fork et a mis fin à son partenariat avec Nextcloud.

L'État développe de son côté La Suite numérique (DINUM), un ensemble d'outils libres réservé aux agents publics, avec ProConnect pour l'authentification. Son « cœur de suite », que la DINUM développe et opère elle-même, comprend Tchap (messagerie fondée sur Matrix), Visio (visioconférence) et France Transfert ; Fichiers et Messagerie, en construction en 2026, doivent le rejoindre. D'autres outils, comme Docs (rédaction collaborative) ou Grist, sont co-construits avec la filière. La Cour des comptes (octobre 2026) juge ces développements « probants », mais relève l'absence d'interopérabilité entre les outils de La Suite eux-mêmes et avec les suites bureautiques des ministères. Elle recommande d'engager dès 2027 la convergence vers des outils bureautiques et collaboratifs libres et de s'appuyer davantage sur les entreprises du secteur. Deux circulaires du Premier ministre invitent les administrations à généraliser Tchap (25 juillet 2025) et Visio (28 janvier 2026). Pour OpenInterop, ces outils sont des solutions parmi d'autres : la doctrine leur applique les mêmes profils et les mêmes tests qu'aux offres privées ; aucune solution, publique ou privée, ne doit devenir un point de passage obligé (cf. doctrine, principes 7 et 8).

Face à eux, les suites intégrées dominantes (Microsoft 365, Google Workspace) imposent un verrouillage par l'intégration : chaque composant est interopérable au sein de la suite mais fermé vers l'extérieur. L'enjeu d'OpenInterop est de permettre aux solutions françaises et européennes de constituer, par assemblage, une alternative crédible et modulaire.

1.2 Adoption FR et manques par sous-domaine¶

Le panorama complet des standards collaboratifs (fonctions, maturité, références) figure dans l'état de l'art, §2. Cette fiche se concentre sur leur adoption dans l'écosystème français et les manques identifiés.

Gestion documentaire et fichiers¶

Standards de référence : WebDAV, CMIS, WOPI, OCM (Open Cloud Mesh), CS3APIs, ODF, OOXML (cf. l'état de l'art, §2.1).

Constat : la fédération inter-fournisseurs portée par la CS3 Community européenne (OCM, CS3APIs, Reva) est mature mais cantonnée à la recherche. OCM, déployé depuis 2016, fait désormais l'objet d'un groupe de travail IETF (ocm) qui prévoit de demander la publication de la spécification en RFC fin 2026. C'est un précédent direct pour OpenInterop (voir chantier C6). Côté édition souveraine, Euro-Office (fork AGPLv3 d'ONLYOFFICE) s'intègre aux solutions hôtes par WOPI ou par l'API de connecteur héritée d'ONLYOFFICE : Nextcloud l'embarque depuis sa version Hub 26 Spring, XWiki en annonce l'intégration pour fin 2026. La place de WOPI dans un profil OpenInterop reste à trancher au regard du principe 2 de la doctrine. Aucun protocole ouvert de co-édition inter-solutions n'existe à ce jour.

Calendrier, contacts, email¶

Standards de référence : CalDAV, CardDAV, iCalendar, vCard, SMTP/IMAP, JMAP (cf. l'état de l'art, §2.2).

Constat : le socle est solide. Le point douloureux en France est le free/busy entre solutions, que des implémentations divergentes rendent coûteux au quotidien (voir chantier C2).

Messagerie instantanée et visioconférence¶

Standards de référence : Matrix, XMPP, IRC, SIP/WebRTC (cf. l'état de l'art, §2.3).

Constat : les standards existent et sont matures ; le verrou est l'absence d'adoption par les suites collaboratives commerciales, chaque solution maintenant son silo (voir chantier C3).

Flux d'activité et réseaux sociaux d'entreprise¶

Standards de référence : Activity Streams 2.0, ActivityPub (cf. l'état de l'art, §2.4).

Constat : le standard est techniquement mature mais sous-exploité en collaboratif d'entreprise.

Composition d'interfaces¶

Standards de référence : Web Components, JSR 286 / Portlets, RenderJS, XBlock, LTI 1.3 (cf. l'état de l'art, §2.5).

Constat : les briques techniques existent ; le manque est un contrat de composition inter-éditeurs (voir chantier C5).

Édition collaborative temps réel¶

Les algorithmes de référence sont les CRDTs (matures, Yjs / Automerge en références de facto) et OT (mature). Voir l'état de l'art, §2.6.

Constat : les algorithmes sont matures, mais aucun protocole d'échange standardisé ne permet de co-éditer entre deux solutions différentes. Euro-Office fournit une brique d'édition souveraine intégrable dans plusieurs solutions hôtes ; il reprend le protocole de co-édition d'ONLYOFFICE et ne le standardise pas.

Recherche fédérée d'entreprise¶

Standards et conventions : OpenSearch (protocole), SRU/CQL, OData $search, SPARQL Federation, MCP, etc. Voir l'état de l'art, §2.7.

Constat : chercher simultanément dans XWiki + Jamespot + BlueMind + Nextcloud + Tchap depuis un point d'entrée unique n'est aujourd'hui possible que par développements spécifiques. Aucun standard n'est adopté par les suites collaboratives commerciales. Le manque est comparable à celui de la co-édition : technologies sous-jacentes matures, pas de protocole d'interopérabilité (voir chantier C7).

1.3 Synthèse de maturité¶

2. Analyse des besoins de l'écosystème français¶

2.1 Pain points identifiés (côté utilisateurs)¶

Les frustrations ci-dessous sont des retours qualitatifs issus des échanges du CSF, des discussions Cigref/TOSIT, des consultations ARCEP et de l'étude OPIIEC sur l'interopérabilité (cf. note de vision et état de l'art pour les références). Elles n'ont pas fait l'objet d'un sondage quantitatif dédié et seront à corroborer par un travail empirique ultérieur. Le cadrage stratégique général est celui de l'interopérabilité opposable (cf. note de positionnement Abilian, novembre 2025 : « L'interopérabilité, clé de l'efficacité collaborative et de la souveraineté »), que la doctrine proposée traduit en exigence de preuve par un résultat reproductible (doctrine, principe 1).

1. "Je ne peux pas voir les disponibilités de mes collègues qui utilisent une autre solution" : interopérabilité calendrier (free/busy) entre solutions.

2. "On a trois outils de messagerie instantanée selon les services" : silos de conversations entre Tchap (Matrix), Teams et les messageries intégrées aux suites collaboratives des éditeurs français.

3. "On ne peut pas co-éditer avec un partenaire qui n'a pas le même outil" : l'édition collaborative est fermée au sein de chaque solution.

4. "Migrer d'une solution à l'autre, c'est perdre l'historique" : la réversibilité (export/import) de l'historique (conversations, documents, tâches) est incomplète ou inexistante.

5. "Le portail intranet ne peut intégrer que les widgets de notre éditeur" : pas de composition d'interfaces inter-éditeurs.

6. "L'annuaire est synchronisé manuellement entre trois systèmes" : SCIM est peu implémenté par les éditeurs français.

2.2 Besoins structurels de la filière¶

• Construire une offre modulaire crédible face à Microsoft 365 / Google Workspace : cela suppose que les solutions françaises soient interopérables entre elles, pas seulement individuellement performantes.
• Répondre aux exigences de la commande publique : la circulaire du Premier ministre du 5 février 2026 compte la souveraineté numérique, la réversibilité et l'interopérabilité parmi les critères de choix des solutions, mais les administrations ont besoin de garanties d'interopérabilité et de réversibilité. La commission d'enquête de l'Assemblée nationale sur les dépendances structurelles dans le numérique propose de rendre le RGI obligatoire dans les marchés (rapport n° 3054, juillet 2026, proposition n° 12) ; des profils collaboratifs versables au RGI prendraient alors une portée contractuelle directe.
• Permettre le multi-sourcing : une administration doit pouvoir utiliser Jalios pour l'intranet, BlueMind pour l'email et le calendrier, XWiki pour la base de connaissances et Tchap pour la messagerie, sans friction.

2.3 Priorisation des besoins¶

3. Propositions concrètes¶

3.0 Cadre commun : un profil d'application par sous-domaine¶

Le groupe de travail collaboratif conduit, sous le pilotage de l'auteur, un projet transversal intitulé « Comment exploiter les standards ». Il découpe le domaine en sept sous-domaines et produit pour chacun un mini-profil d'application au sens de la doctrine (§2) : standards retenus, extensions ou profils nécessaires, points de vigilance. Ces profils donnent aux autres projets du groupe (Tchap, Visio, sélecteur de fichiers, co-édition, fédération documentaire, centre de notifications) une base commune de standards et de pratiques. Ils font aussi apparaître les manques qui justifient un chantier nouveau ; les chantiers C1 à C7 ci-dessous en sont la première liste.

Livrables du projet : un mini-profil par sous-domaine, des modèles de déclaration de conformité (ICS/IFS, sur la méthodologie de l'ETSI) utilisables par chaque éditeur participant, la cartographie des manques par sous-domaine, un ou plusieurs guides techniques et une proposition de mise à niveau du RGI. Les résultats sont consolidés dans la présente fiche et dans la fiche transverse.

Tous les chantiers suivent les règles de la doctrine. Un profil n'est complet qu'avec une implémentation de référence libre (quand il n'en existe pas déjà une), une suite de tests de conformité libre et un modèle de déclaration de conformité (principe 4). La conformité exige 100 % des critères obligatoires, sans compensation entre critères ; les autres mesures sont publiées à part. Aucune moyenne pondérée ne fonde la conformité (doctrine, §5.2). Chaque test rend l'un de quatre verdicts : « conforme », « non conforme », « non applicable » ou « non concluant ». Une solution qui se dit « compatible » avec un profil indique les fonctions revendiquées et produit un rapport de conformité sur ce périmètre. La preuve s'établit à trois niveaux (autoévaluation, vérification par un tiers, essai croisé sur le modèle des Plugtests de l'ETSI) ; seul l'essai croisé ouvre droit au badge délivré par l'autorité technique (doctrine, §5). Une suite de tests apporte la preuve technique ; son usage dans un contrat demande des clauses rédigées à cet effet, que la doctrine prévoit sous forme de clauses types.

3.1 Chantier C1 : SSO et annuaire interopérable (Quick Win)¶

Prérequis transverse : Ce chantier s'appuie sur le chantier T1 (Profil d'identité OpenInterop) de la fiche transverse. Le profil OIDC/SCIM est défini au niveau transverse ; le chantier C1 l'applique au domaine collaboratif.

Objectif : Tout utilisateur se connecte une seule fois et son identité est propagée à toutes les solutions collaboratives de la suite modulaire.

Standards : OIDC 1.0, OAuth 2.0 avec ses extensions de sécurité publiées (RFC 9700, BCP 240) et SCIM 2.0 (profil transverse T1). OAuth 2.1, encore à l'état de draft IETF, ne sera référencé qu'une fois publié.

Actions spécifiques au collaboratif : 1. Extension du profil T1 pour le collaboratif : claims OIDC supplémentaires pertinents (rôle dans l'espace de travail, préférences de notification, etc.), attributs SCIM spécifiques (espaces, droits documentaires). 2. POC multi-éditeurs collaboratifs : démontrer le SSO + provisioning automatique entre 3 solutions collaboratives (ex. : XWiki + BlueMind + Jamespot via un IdP commun comme Keycloak ou LemonLDAP::NG). 3. Essai croisé : valider que la suite de tests T1 passe sur les solutions collaboratives participantes.

Livrables : Extension du profil T1, POC démontrable, déclarations et rapports de conformité des solutions participantes. Le délai est de 3 à 6 mois, en parallèle de T1.

3.2 Chantier C2 : interopérabilité calendrier / contacts¶

Objectif : Partage de disponibilités (free/busy), invitation inter-solutions, synchronisation de contacts.

Standards à adopter : CalDAV + iCalendar (RFC 5545/6047) + CardDAV + vCard 4.0

Actions : 1. Profil d'interopérabilité calendrier : spécifier les fonctionnalités minimales CalDAV à implémenter (free/busy, invitations, délégation), les extensions iCalendar à prendre en charge, ainsi que les comportements attendus en cas de conflit. 2. Suite de tests et essai croisé : écrire une suite de tests de conformité libre, puis organiser une session de tests croisés entre éditeurs sur le modèle des Plugtests de l'ETSI et des Connectathons IHE de la santé. 3. Documentation des divergences : recenser et documenter les divergences d'implémentation CalDAV/CardDAV entre les solutions françaises, puis proposer des correctifs.

Livrables : Profil documenté, suite de tests, modèle de déclaration de conformité, rapport d'essai croisé, patches contribués aux solutions. Le délai est de 4 à 6 mois.

3.3 Chantier C3 : passerelle de messagerie instantanée (Matrix)¶

Objectif : Un utilisateur de Jamespot peut envoyer un message à un utilisateur de Tchap ou d'une autre solution participante et recevoir ses réponses.

Standard à adopter : Protocole Matrix (fédération)

Actions : 1. État de l'art des bridges Matrix : recenser les bridges existants (Slack, Teams, IRC, etc.) et évaluer leur maturité. 2. Spécification d'un bridge générique : définir une API minimale qu'une solution collaborative doit exposer pour s'intégrer à Matrix via un bridge, sans réécrire toute sa messagerie. 3. POC de fédération : démontrer l'échange de messages entre 2-3 solutions françaises via Matrix, avec historique et notifications. 4. Contribution à la spécification Matrix : remonter les besoins spécifiques (gestion de groupes, fils de discussion structurés, accusés de lecture) au projet Matrix par sa procédure de propositions (MSC).

Livrables : Cartographie des bridges, spécification de bridge avec sa suite de tests, POC fonctionnel. Le délai est de 6 à 9 mois.

3.4 Chantier C4 : format de réversibilité (export/import)¶

Objectif : Permettre la migration complète d'une solution collaborative à une autre, sans perte de données. La réversibilité s'entend au sens de la doctrine : données, métadonnées et structure récupérées dans un état directement utilisable par la solution d'arrivée (doctrine, §2 et principe 6). Pour les offres SaaS, le chantier rejoint les obligations de changement de fournisseur du Data Act, applicables depuis le 12 septembre 2025.

Actions : 1. Inventaire des données migrables : établir la liste des types de données à couvrir (documents + métadonnées, calendriers, contacts, conversations, tâches, wikis, espaces, permissions). 2. Spécification d'un format d'export OpenInterop : un format d'archive (ZIP structuré ?) regroupant, dans des formats ouverts, les documents (ODF), les événements (iCalendar), les contacts (vCard), les métadonnées et les conversations (JSON). 3. Implémentation de référence : développer un outil open source d'export/import prenant en charge au moins 2 solutions. 4. Suite de tests : des scénarios de migration entre deux solutions, avec jeux de données et verdicts, sur le modèle du kit de tests de l'atelier cloud du 9 octobre 2026 (cf. fiche cloud).

Livrables : Spécification du format d'archive, outil de référence, suite de tests de migration. Le délai est de 6 à 12 mois.

3.5 Chantier C5 : composition d'interfaces (exploration)¶

Objectif : Permettre d'assembler dans un portail des widgets/composants provenant de solutions différentes.

Actions : 1. Étude comparative : analyser les approches existantes (Web Components, RenderJS, LTI 1.3, iframes sécurisées, micro-frontends) et évaluer leur applicabilité au contexte collaboratif. 2. Spécification d'un "contrat de widget" : définir un protocole minimal (authentification, communication inter-widgets, cycle de vie) pour intégrer un composant d'un éditeur A dans le portail d'un éditeur B. 3. POC : démontrer l'intégration d'un widget calendrier (éditeur A) dans un portail intranet (éditeur B), avec SSO et échange de données contextuelles.

Livrables : Étude comparative, draft de spécification, POC. Le délai est de 9 à 12 mois. Ce chantier est plus exploratoire que les précédents.

3.6 Chantier C6 : fédération de fichiers (OCM) et articulation CS3¶

Objectif : Permettre le partage de fichiers et de dossiers entre instances de solutions collaboratives différentes (Nextcloud, ownCloud, OpenCloud, Seafile, Pydio et des solutions françaises), sans copie locale ni création de compte sur la plateforme distante. Articuler les travaux d'OpenInterop avec ceux, plus avancés, de la CS3 Community européenne et du groupe de travail ocm de l'IETF.

Standards à adopter : OCM (Open Cloud Mesh) pour le partage fédéré, en cours de normalisation à l'IETF (draft-ietf-ocm-open-cloud-mesh, version -07 de septembre 2026 ; demande de publication prévue fin 2026) ; CS3APIs pour l'API commune EFSS, avec Reva comme implémentation de référence.

Actions : 1. État des lieux : recenser la prise en charge d'OCM et des CS3APIs dans les solutions françaises et européennes pertinentes (Nextcloud, ownCloud, OpenCloud, Seafile, Pydio, ainsi que les éditeurs français participants). Identifier les écarts d'implémentation. 2. Liaison avec CS3 Community et l'IETF : prendre contact officiel avec la CS3 Community (CERN, ScienceMesh) pour articuler les travaux, éviter la duplication et identifier les points d'entrée européens (collaboration possible via OW2, lien avec la Fondation EuroStack et APELL). Remonter au groupe de travail ocm de l'IETF les besoins du secteur public et des entreprises françaises tant que la spécification est ouverte aux commentaires. 3. Profil OCM "entreprise/administration" : définir, le cas échéant, un profil d'application d'OCM adapté aux contraintes du secteur public et des entreprises françaises (politiques de sécurité, journalisation, intégration avec le profil d'identité T1), fondé sur la version IETF. 4. POC de fédération inter-éditeurs : démontrer un partage OCM entre une instance Nextcloud et une solution collaborative française (Jalios, BlueMind, XWiki, etc.). 5. Articulation avec C4 (réversibilité) : OCM offre une voie complémentaire au format d'archive d'export (C4) pour migrer progressivement sans transfert massif.

Livrables : État des lieux, mémorandum de coopération avec CS3 Community, profil OCM OpenInterop (si justifié) avec sa suite de tests, POC. Le délai est de 6 à 9 mois.

3.7 Chantier C7 : recherche fédérée d'entreprise (exploration)¶

Objectif : Permettre à un utilisateur de chercher simultanément dans plusieurs solutions collaboratives (wiki, intranet, GED, messagerie, calendrier, contacts) depuis un point d'entrée unique, avec des résultats agrégés et ordonnés.

Standards à mobiliser : OpenSearch 1.1 (description), profil hypermedia pour les résultats, mappings sémantiques pour les types d'entités (Document, Message, Event, Contact, etc.) alignés sur le chantier T3 de la fiche transverse.

Actions : 1. État de l'art ciblé : recenser les pratiques des éditeurs français (souvent un Solr ou Elasticsearch propre, sans interface fédérée) ; évaluer la pertinence de SRU/CQL (mature mais bibliothéconomique), MCP (émergent, axé agents IA) et de l'API OpenSearch (trop pauvre seule). 2. Profil "OpenInterop Search" : spécifier un protocole minimal de fédération : endpoint de description, syntaxe de requête simple, format de résultats hypermedia, mappings de types alignés sur les schémas T3. 3. Implémentation de référence : un agrégateur open source interrogeant plusieurs sources (3-4 éditeurs participants) et exposant les résultats via le profil. 4. Articulation avec MCP : évaluer s'il est pertinent d'exposer le profil également comme serveur MCP, pour qu'un agent IA puisse interroger l'ensemble. 5. Articulation avec C1 (identité) : la fédération doit honorer les droits utilisateur, chaque source appliquant son filtrage d'autorisation.

Livrables : État de l'art court, draft de profil, POC d'agrégateur. Délai : 9 à 12 mois. Ce chantier exploratoire sera confirmé après C1 et C2.

3.8 Vue d'ensemble et séquencement¶

Les dates ci-dessous sont indicatives ; elles supposent un démarrage en novembre 2026 et dépendent des engagements des participants (cf. doctrine, §5.1).

gantt
    title Séquencement des chantiers OpenInterop — domaine collaboratif (indicatif)
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    section Profils (7 sous-domaines)
    Mini-profils            :p1, 2026-11-02, 120d
    Modèles ICS/IFS         :p2, after p1, 60d
    Proposition RGI         :milestone, p3, after p2, 30d

    section C1 — OIDC/SCIM
    Profil OIDC/SCIM        :c1a, 2026-11-02, 90d
    Tests + POC             :milestone, c1b, after c1a, 90d

    section C2 — CalDAV
    Profil CalDAV           :c2a, 2026-11-02, 90d
    Essai croisé            :milestone, c2b, after c2a, 90d

    section C3 — Matrix bridge
    État de l'art           :c3a, 2026-11-02, 90d
    Spec bridge             :c3b, after c3a, 90d
    POC fédération          :milestone, c3c, after c3b, 90d

    section C4 — Réversibilité
    Inventaire + spec       :c4a, 2027-02-01, 90d
    Spec format             :c4b, after c4a, 90d
    Outil de référence      :milestone, c4c, after c4b, 90d

    section C5 — Composition UI
    Étude comparative       :c5a, 2027-05-03, 90d
    Spec + POC              :milestone, c5b, after c5a, 90d

    section C6 — Fédération OCM
    État des lieux          :c6a, 2026-11-02, 90d
    Liaison CS3 + profil    :c6b, after c6a, 90d
    POC OCM                 :milestone, c6c, after c6b, 90d

    section C7 — Recherche fédérée
    État de l'art ciblé     :c7a, 2027-05-03, 90d
    Profil + POC            :milestone, c7b, after c7a, 90d

Références¶

Standards et spécifications — Gestion documentaire et fichiers¶

• WebDAV — RFC 4918. https://datatracker.ietf.org/doc/html/rfc4918
• CMIS (Content Management Interoperability Services) — OASIS. https://www.oasis-open.org/committees/cmis/
• WOPI (Web Application Open Platform Interface) — Microsoft, [MS-WOPI]. https://learn.microsoft.com/en-us/openspecs/office_protocols/ms-wopi/ ; programme partenaires : https://learn.microsoft.com/en-us/microsoft-365/cloud-storage-partner-program/online/
• OCM (Open Cloud Mesh) — Spécification de partage fédéré entre fournisseurs EFSS, en cours de normalisation à l'IETF (groupe de travail ocm). https://datatracker.ietf.org/wg/ocm/about/ ; draft : https://datatracker.ietf.org/doc/draft-ietf-ocm-open-cloud-mesh/ ; dépôt historique : https://github.com/cs3org/OCM-API
• CS3APIs — API commune pour services Sync & Share, portée par la CS3 Community. https://github.com/cs3org/cs3apis
• ODF 1.3 et 1.4 — OASIS (ISO/IEC 26300 pour la version 1.2). https://docs.oasis-open.org/office/OpenDocument/v1.3/

Implémentations WOPI open source¶

• cs3org/wopiserver — Serveur WOPI en production au CERN, intégré à ScienceMesh. https://github.com/cs3org/wopiserver
• WOPIX — Serveur WOPI minimal en Java/Spring (Laurent Broto). https://linuxfr.org/news/wopix-un-serveur-wopi-libre-independant-simple-et-leger
• Karadav — Serveur WOPI en PHP.

Standards et spécifications — Identité¶

• OAuth 2.0 Security Best Current Practice — RFC 9700 (BCP 240). https://datatracker.ietf.org/doc/html/rfc9700

Standards et spécifications — Calendrier, contacts, email¶

• CalDAV — RFC 4791. https://datatracker.ietf.org/doc/html/rfc4791
• CardDAV — RFC 6352. https://datatracker.ietf.org/doc/html/rfc6352
• iCalendar — RFC 5545. https://datatracker.ietf.org/doc/html/rfc5545
• vCard 4.0 — RFC 6350. https://datatracker.ietf.org/doc/html/rfc6350
• JMAP — RFC 8620. https://datatracker.ietf.org/doc/html/rfc8620
• iMIP (iCalendar Message-Based Interop.) — RFC 6047. https://datatracker.ietf.org/doc/html/rfc6047

Standards et spécifications — Messagerie et communication¶

• XMPP — RFC 6120-6122. https://xmpp.org/rfcs/
• ActivityPub — W3C Recommendation. https://www.w3.org/TR/activitypub/
• Activity Streams 2.0 — W3C Recommendation. https://www.w3.org/TR/activitystreams-core/
• WebRTC — W3C / IETF. https://www.w3.org/TR/webrtc/
• Matrix — Spécification du protocole (v1.19, juillet 2026). https://spec.matrix.org/

Standards et spécifications — Composition d'interfaces¶

• Web Components — W3C (Custom Elements, Shadow DOM). https://www.w3.org/TR/custom-elements/ / https://www.w3.org/TR/shadow-dom/
• LTI 1.3 — 1EdTech / IMS Global. https://www.imsglobal.org/spec/lti/v1p3/
• RenderJS — Nexedi. https://renderjs.nexedi.com/
• XBlock — Open edX. https://github.com/openedx/XBlock
• JSR 286 (Portlet 2.0) — JCP. https://jcp.org/en/jsr/detail?id=286

Standards et spécifications — Édition collaborative¶

• Yjs — Framework CRDT. https://yjs.dev/
• Automerge — Bibliothèque CRDT. https://automerge.org/

Projets et solutions françaises/européennes¶

• BlueMind — Messagerie et calendrier. https://www.bluemind.net/
• Collabora Online — Édition de documents en ligne (LibreOffice). https://www.collaboraoffice.com/
• Element / Matrix — Client Matrix de référence. https://element.io/
• Euro-Office — Suite bureautique collaborative (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 ; soutien de Proton). Version 1.0 le 9 juin 2026. https://github.com/Euro-Office
• La Suite numérique — Outils collaboratifs libres de l'État (DINUM) : cœur de suite (Tchap, Visio, France Transfert, puis Fichiers et Messagerie), Docs, Grist, avec ProConnect. https://lasuite.numerique.gouv.fr/
• Cour des comptes, Les outils bureautiques et collaboratifs au sein de l'État, rapport d'initiative citoyenne, octobre 2026. https://www.ccomptes.fr/sites/default/files/2026-10/20261022_Outils-bureautiques-et-collaboratifs-des-minist%C3%A8res.pdf
• Nextcloud — Plateforme collaborative open source. https://nextcloud.com/
• Etc.

Initiatives et communautés liées¶

• 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/

Articles de positionnement¶

• Stéfane Fermigier, « L'interopérabilité, clé de l'efficacité collaborative et de la souveraineté », Abilian, novembre 2025. https://abilian.com/fr/news/interoperabilite-efficacite-collaborative-souverainete/

Documents OpenInterop¶

• Note de vision OpenInterop
• État de l'art des standards d'interopérabilité
• Fiche transverse (chantier T1 = prérequis de C1 ; T3 schémas Document/Workspace/Task ; T4 notifications d'activité)
• Fiche cloud
• Fiche cybersécurité
• Doctrine OpenInterop proposée (définitions, principes, niveaux de preuve, autorité technique)