Fédération inter-organisations : collaborer sans compromis

Note : Cet article décrit l’architecture et la conception de Mandraki. Certaines fonctionnalités évoquées sont déployées progressivement et peuvent ne pas être encore disponibles dans toutes les offres.

La collaboration d’entreprise ne se déroule pas en vase clos. Les organisations travaillent avec des partenaires, des clients, des régulateurs, des sous-traitants et des consortiums industriels. Les personnes avec qui vous devez communiquer se trouvent souvent en dehors de votre organisation, et fréquemment en dehors de votre plateforme de collaboration.

Les solutions traditionnelles à ce problème sont insatisfaisantes. Vous pouvez inviter des utilisateurs externes en tant qu’invités sur votre plateforme, ce qui brouille les frontières de sécurité et crée une charge administrative. Vous pouvez maintenir des comptes sur plusieurs plateformes, ce qui fragmente vos communications. Ou vous pouvez vous rabattre sur l’e-mail, qui ne fournit aucune des fonctionnalités de collaboration en temps réel que le travail moderne exige.

La fédération inter-organisations de Mandraki offre une meilleure approche : deux organisations peuvent collaborer dans des canaux et des appels partagés tout en conservant chacune une pleine souveraineté sur leurs propres données, politiques de sécurité et contrôle administratif.

Comment fonctionne la fédération

La fédération dans Mandraki est une relation bilatérale, basée sur le consentement, entre deux organisations. Aucune des deux parties ne peut imposer la fédération à l’autre. Le processus commence lorsqu’une organisation envoie une demande de fédération à une autre.

La demande précise quelles capacités de collaboration l’organisation demandeuse souhaite activer : messagerie, appels, partage de fichiers et canaux partagés. L’organisation cible examine la demande et peut l’approuver avec son propre ensemble d’autorisations. Les deux parties doivent être d’accord, et chacune peut modifier ou révoquer la relation à tout moment.

Une fois qu’une relation de fédération est établie, les utilisateurs des deux organisations peuvent participer à des canaux et des appels partagés. L’expérience est fluide — un canal partagé apparaît aux côtés des canaux internes de l’organisation, et les utilisateurs de l’organisation fédérée sont clairement identifiés par un badge « Externe ».

Propriété des données dans les canaux partagés

Un canal partagé dans Mandraki a une seule organisation propriétaire. Les politiques de l’organisation propriétaire régissent les paramètres de chiffrement du canal, les politiques de conservation et la disponibilité des fonctionnalités IA. Les autres organisations participent au canal mais ne contrôlent pas sa configuration.

Plus important encore, chaque message dans un canal partagé porte un originOrgId qui identifie à quelle organisation appartient l’expéditeur. Cela garantit la traçabilité : chaque organisation peut voir quels messages proviennent de ses membres et lesquels proviennent de participants externes.

À des fins de conformité, chaque organisation conserve l’accès aux messages envoyés par ses propres membres. Si une organisation quitte une fédération, elle conserve ses propres messages tout en perdant l’accès aux messages de l’autre organisation. La propriété des données suit la frontière de l’organisation, et non la frontière du canal.

Gouvernance et contrôles de politique

La fédération dans Mandraki est régie par des contrôles de politique granulaires au niveau de l’organisation.

Politique inter-organisations. Les administrateurs définissent la position de fédération de l’organisation : désactivée (aucune fédération autorisée), fédérée uniquement (fédération avec les organisations approuvées uniquement), ou ouverte (demandes de fédération acceptées par défaut, sous réserve d’une approbation individuelle).

Liste d’autorisation. Les organisations peuvent maintenir une liste explicite de partenaires de fédération approuvés. Seules les organisations figurant sur la liste peuvent établir des relations de fédération.

Exigence d’approbation. Lorsqu’elle est activée, toutes les demandes de fédération nécessitent l’approbation explicite de l’administrateur, même si l’organisation demandeuse figure sur la liste d’autorisation.

Autorisations par fonctionnalité. Les relations de fédération ont des bascules de fonctionnalités granulaires. Une organisation peut autoriser la messagerie avec un partenaire mais pas le partage de fichiers, ou autoriser les appels mais pas les canaux partagés. Ces autorisations peuvent être ajustées à tout moment.

Ces contrôles reflètent la réalité que différentes organisations ont des appétits de risque et des exigences réglementaires différents. Une institution financière peut se fédérer avec son auditeur pour la messagerie uniquement, sans partage de fichiers. Un ministère peut se fédérer avec un organisme professionnel pour les canaux partagés mais exiger une approbation pour chaque nouveau participant.

Frontières de sécurité

La fédération ne fusionne pas les domaines de sécurité de deux organisations. Chaque organisation conserve ses propres clés de chiffrement, sa propre gestion des utilisateurs, ses propres contrôles d’accès et ses propres journaux d’audit. Le SFU et le serveur API appliquent les frontières organisationnelles à chaque couche.

Lorsqu’un message est envoyé dans un canal partagé, il est chiffré avec le contexte de chiffrement du canal (qui appartient à l’organisation propriétaire). Les utilisateurs des organisations fédérées qui ont reçu l’accès peuvent déchiffrer et lire le message. Mais la relation de fédération n’accorde pas l’accès à d’autres données au sein de l’organisation propriétaire — les canaux internes, les messages directs ou les paramètres organisationnels restent complètement isolés.

Pour les appels dans des contextes fédérés, le même principe s’applique. Les participants des deux organisations rejoignent l’appel via le flux de signalisation WebRTC standard, authentifiés auprès de leurs organisations respectives. Le SFU achemine les médias entre les participants sans tenir compte de l’organisation à laquelle ils appartiennent, mais l’API applique que seuls les participants disposant d’autorisations de fédération valides peuvent rejoindre.

Identité de l’installation et fédération inter-installations

Le modèle de fédération de Mandraki s’étend au-delà des organisations au sein d’une seule installation pour prendre en charge la communication entre déploiements Mandraki distincts — ce que nous appelons la fédération inter-installations.

Chaque installation Mandraki a une identité unique, incluant une paire de clés Ed25519 pour l’authentification cryptographique. Les installations publient un descripteur well-known à /.well-known/eurocom-server qui inclut leur clé publique, leurs capacités et leur version.

Lorsque deux installations communiquent, toutes les charges utiles sont signées avec la clé privée de l’installation expéditrice et vérifiées avec la clé publique de l’installation réceptrice. Cela empêche l’usurpation d’identité et garantit que les messages de fédération sont authentiques.

La fédération inter-installations est particulièrement pertinente pour les organisations ayant des exigences de résidence des données. Une installation Mandraki en Allemagne peut se fédérer avec une installation en France, permettant une collaboration transfrontalière tandis que chaque installation maintient la résidence des données au sein de sa juridiction respective.

L’expérience utilisateur externe

Nous avons accordé une attention particulière à la façon dont les utilisateurs fédérés apparaissent dans l’interface. Les utilisateurs externes sont toujours visuellement distingués par un badge « Externe » clair. Ce n’est ni optionnel ni configurable — c’est appliqué par la plateforme pour éviter toute confusion sur qui participe à une conversation.

Lors de la rédaction d’un message dans un canal partagé, la zone de composition rappelle à l’utilisateur que les participants externes peuvent voir ses messages. Lors du démarrage d’un appel dans un contexte fédéré, les participants voient une indication claire des organisations représentées.

Ces décisions de conception reflètent un principe : la fédération doit rendre la collaboration inter-organisations facile, mais elle ne doit jamais la rendre invisible. Les utilisateurs doivent toujours savoir quand ils communiquent au-delà des frontières organisationnelles.

Le cas en faveur de la fédération plutôt que des comptes invités

De nombreuses plateformes de collaboration abordent la communication inter-organisations par le biais de comptes invités — les utilisateurs externes reçoivent des comptes limités au sein de l’espace de travail de l’organisation hôte. Cette approche présente plusieurs inconvénients que la fédération évite.

Les comptes invités créent une charge administrative : quelqu’un doit créer, gérer et finalement désactiver chaque invité. Les comptes invités brouillent les frontières de sécurité : l’invité existe au sein du domaine de sécurité de l’hôte, ce qui peut ne pas s’aligner sur les politiques de sécurité de sa propre organisation. Les comptes invités fragmentent la communication : l’invité doit maintenir des identités et des contextes séparés pour chaque organisation avec laquelle il collabore.

La fédération maintient chaque utilisateur au sein du domaine de sa propre organisation. Ils s’authentifient avec leurs propres identifiants, voient les canaux de leur propre organisation aux côtés des canaux partagés, et sont régis par les politiques de leur propre organisation. Aucun compte invité à gérer, aucune frontière brouillée, aucune identité fragmentée.

Pour les organisations européennes qui doivent collaborer au-delà des frontières tout en maintenant la souveraineté, la fédération est l’architecture qui rend cela possible sans compromis.