Si vous construisez une plateforme de communication souveraine, deux équipes de conformité différentes vont vous interroger, et elles ne poseront pas du tout les mêmes questions.
Un responsable de la conformité dans la santé aux États-Unis veut savoir qui peut accéder aux informations des patients, et si vous pouvez le prouver. Un acheteur public européen veut savoir quel droit peut les atteindre. Le plus intéressant ? La réponse est la même pour les deux : du chat, de la vidéo, du téléphone, des fichiers et de l'e-mail open source, sur des serveurs que vous contrôlez, derrière un seul fournisseur d'identité.
Nous avons déjà traité chaque brique séparément : la visioconférence souveraine, la vidéo de télésanté conforme à HIPAA et neuf alternatives auto-hébergées à Microsoft Teams. Cet article explique comment les assembler en une plateforme qui passe les deux tests, et décrit les quelques endroits où les données s'échappent encore même quand chaque serveur vous appartient. C'est un guide technique, pas un conseil juridique.
En bref
Des outils open source sur une infrastructure que vous contrôlez passent les deux tests. Le vrai travail n'est dans aucune application en particulier : il est dans l'identité, la journalisation et les bords par lesquels les messages quittent vos serveurs.
Santé, juridique, secteur public
Keycloak, un serveur de chat, Jitsi, Nextcloud et mailcow sur les serveurs de votre choix. Chaque brique est mature et remplaçable.
Administration européenne sur Kubernetes
openDesk livre l'ensemble sous la forme d'un seul produit, conçu pour l'administration publique. Le déploiement est plus lourd que quelques serveurs.
HIPAA seulement, sans exigence de souveraineté
Microsoft signe un BAA. Si personne ne demande quel droit s'applique, une suite hébergée sous BAA peut être la réponse la plus simple.
Ni analyse de risques ni plan d'identité
Faites d'abord l'analyse de risques HIPAA ou l'AIPD du RGPD, et décidez où se fait la connexion. Tout le reste en découle.
Deux tests, une seule pile
La souveraineté est une affaire de juridiction. HIPAA est une affaire de garanties. Mettez les questions côte à côte, et elles portent sur les mêmes parties du système.
| Niveau | Ce que demande la souveraineté | Ce que demande HIPAA |
|---|---|---|
| Logiciel | Pouvez-vous le faire tourner sans l'éditeur, et changer de fournisseur ? | Prend-il en charge des identifiants utilisateur uniques, des journaux d'audit et le chiffrement ? |
| Infrastructure | Le droit de quel pays s'applique au propriétaire des serveurs ? | Existe-t-il un BAA avec le fournisseur qui stocke les données ? |
| Exploitation | Qui peut se connecter, appliquer les correctifs et répondre aux tickets de support ? | L'accès est-il limité, journalisé et revu ? |
| Clés | Qui peut déchiffrer les données ? | Les ePHI sont-elles chiffrées en transit et au repos ? |
La vraie différence, c'est avec qui vous signez. HIPAA est satisfait par un BAA avec votre fournisseur cloud, où qu'il soit établi. La souveraineté ne l'est par aucun contrat avec un fournisseur soumis à un droit étranger, car le CLOUD Act américain s'applique aux données détenues par des entreprises américaines, où qu'elles soient stockées. Les autorités américaines peuvent exiger des données auprès des fournisseurs concernés quel que soit leur emplacement, et la loi crée aussi un cadre permettant à des gouvernements étrangers d'accéder aux données détenues par des fournisseurs américains via des accords exécutifs.
La plateforme de communication souveraine, canal par canal
Voici un ensemble d'outils open source qui fonctionne. Chacun est remplaçable, et c'est en partie le but : si un projet change de licence ou d'édition gratuite, vous remplacez cette brique, pas toute la plateforme.
| Canal | Choix open source | Licence | Point de vigilance |
|---|---|---|---|
| Identité | Keycloak | Apache 2.0 | Il devient le serveur le plus important que vous exploitez. Sauvegardez-le et surveillez-le en premier |
| Chat | Mattermost, Zulip ou Element (Matrix) | MIT (Mattermost Team Edition), Apache 2.0 (Zulip), AGPL ou commerciale (Synapse) | Les éditions gratuites diffèrent nettement sur le SSO et l'usage en production ; vérifiez avant de vous engager |
| Vidéo | Jitsi Meet ou plugNmeet | Apache 2.0, MIT | Le serveur multimédia déchiffre pour relayer les flux, sauf si vous activez le chiffrement de bout en bout |
| Téléphone | Jigasi ou la passerelle SIP de plugNmeet | Apache 2.0, MIT | L'appel quitte votre périmètre chez l'opérateur |
| Fichiers | Nextcloud | AGPL-3.0 | Les aperçus, l'édition bureautique et la fédération ajoutent chacun un service à sécuriser |
| mailcow | GPL-3.0 | Les e-mails vers des destinataires externes transitent par des serveurs que vous ne contrôlez pas | |
| Relais TURN | Coturn | BSD-3-Clause | Sans votre propre TURN, certains appels échouent ou passent par le relais de quelqu'un d'autre |
Chat : le piège, c'est l'édition gratuite
Mattermost
Mattermost est ce qui se rapproche le plus des canaux de Teams, mais la v11 a nettement changé la donne. Team Edition reste sous licence MIT, mais la limite est tombée à 250 utilisateurs, et le SSO GitLab, Google OAuth et OpenID Connect ont tous été retirés de l'offre gratuite. HIPAA exige des identités uniques et gérées, donc le SSO n'est pas facultatif. Soit vous payez une édition commerciale, soit vous choisissez un autre serveur de chat.
Zulip
Zulip offre des conversations par fils, une licence Apache 2.0 sans ambiguïté et un auto-hébergement simple. Un bon choix pour les équipes qui se noient dans des canaux très actifs. Notre guide sur Zulip comme alternative à Slack détaille l'installation.
Element (Matrix)
Element (Matrix) propose des salons chiffrés de bout en bout et la fédération. Synapse est sous AGPL ou sous licence commerciale. Mais voici le piège : la suite gratuite ESS Community d'Element n'est explicitement « pas destinée à la production dans des environnements commerciaux » : aucune garantie de performance, aucune certification, aucun SBOM et aucune conformité au Cyber Resilience Act. Pour un usage sérieux, il faut regarder ESS Pro.
Vidéo et téléphone
Jitsi Meet est le moteur d'openDesk en Allemagne, et LiveKit tourne sous Visio en France : l'un comme l'autre est un choix défendable pour un acheteur attaché à la souveraineté. Pour les équipes qui enregistrent beaucoup, plugNmeet est l'option basée sur LiveKit avec accès téléphonique SIP intégré. Activez le chiffrement de bout en bout dans Jitsi Meet pour les réunions sensibles, et faites tourner votre propre serveur TURN pour que les appels qui traversent des pare-feu stricts ne passent pas par un tiers.
Fichiers et e-mail
Nextcloud couvre les fichiers, les agendas et les contacts sous AGPL-3.0, et son application Talk peut prendre en charge le chat et les appels pour les équipes qui veulent moins de serveurs. mailcow fait tourner un serveur de messagerie complet dans Docker sous GPL-3.0.
L'identité d'abord
Chaque application de la pile doit passer par un seul fournisseur d'identité pour la connexion. C'est le contrôle le plus important pour les deux tests : un seul endroit pour imposer l'authentification multifacteur, un seul endroit pour retirer tous ses accès à quelqu'un qui part, et un seul journal de qui s'est connecté où.
- Mettez en place Keycloak avant tout le resteIl parle OIDC, OAuth2 et SAML, que chaque application du tableau prend en charge dans au moins une édition. Notre guide sur Keycloak sur AWS détaille l'installation, et la documentation de Keycloak couvre chaque protocole.
- Exigez la MFA pour toute personne ayant accès à des données sensiblesHIPAA exige une identification unique des utilisateurs, et la mise à jour proposée de la Security Rule rendrait la MFA explicite. Les acheteurs attachés à la souveraineté la demanderont de toute façon.
- Connectez chaque application à sa mise en serviceLes clients de chat, de vidéo, de fichiers et de messagerie doivent tous s'authentifier auprès de Keycloak, pas avec leurs propres comptes locaux.
- Faites du départ d'un utilisateur une seule actionDésactiver un utilisateur dans Keycloak doit couper son accès partout. Testez-le avec un vrai compte avant le lancement.
Où l'héberger
Le même logiciel peut réussir ou échouer le test de souveraineté selon l'endroit où il tourne. HIPAA s'intéresse moins au pays qu'au BAA.
| Où elle tourne | Souveraineté | HIPAA |
|---|---|---|
| Votre propre matériel | Totale, si vous l'exploitez aussi | Aucun BAA cloud nécessaire ; les garanties physiques vous reviennent |
| Un fournisseur à capitaux européens | Forte : entreprise européenne, droit européen | Pertinent seulement pour des PHI américaines ; peu de fournisseurs européens proposent un BAA HIPAA |
| AWS European Sovereign Cloud | Partielle : entité et personnel dans l'UE, mais la maison mère américaine reste soumise au CLOUD Act | Vérifiez quels services et quels accords sont proposés |
| Une région standard d'AWS ou de Google Cloud | Faible : entreprise américaine, le CLOUD Act s'applique | Forte : BAA disponible, services éligibles HIPAA |
L'AWS European Sovereign Cloud mérite un examen attentif. Elle est isolée physiquement et logiquement dans l'UE, exploitée par du personnel résidant dans l'UE sous une nouvelle société mère allemande, et la gestion des identités reste dans l'UE. Le personnel d'AWS hors de l'UE n'a aucun moyen technique d'accéder à vos contenus. Mais la maison mère reste une entreprise américaine, et l'avenant sur les demandes gouvernementales, s'il engage AWS à contester les injonctions trop larges, ne revendique aucune immunité face aux procédures judiciaires américaines. D'où le « partielle » et non « totale ». Pour un ministère européen, la région standard échoue d'emblée ; le cloud souverain est un vrai progrès, mais pas une réponse complète.
Pour une clinique américaine, une région AWS standard sous le BAA d'AWS est un très bon point d'ancrage pour cette pile, et c'est la configuration que suppose notre guide des agents vocaux HIPAA.
Là où le périmètre fuit
Même en auto-hébergeant chaque serveur, il reste quelques chemins par lesquels le contenu échappe à votre contrôle. Ce sont ceux que trouvent les auditeurs.
Notifications push sur mobile
Par défaut, le contenu des notifications push de Mattermost passe par Apple Push Notification Service (APNS) ou Google Firebase Cloud Messaging (FCM) avant d'atteindre l'appareil. Si la notification contient le texte du message, ce texte transite par l'infrastructure d'Apple et de Google. Le mode « ID uniquement » de Mattermost, où le téléphone récupère le message sur votre serveur, est une fonction Enterprise, pas une option de l'offre gratuite. Utilisez l'option la plus confidentielle que permet votre édition.
Appels téléphoniques
Dès qu'un appel atteint le réseau téléphonique, il passe par les équipements d'un opérateur. Un opérateur qui se contente d'acheminer les appels peut relever de l'exception dite de « conduit » prévue par HIPAA ; cette exception est étroite et limitée aux services de transmission dont l'accès aux PHI est aléatoire ou peu fréquent. Un opérateur qui enregistre ou transcrit traite des PHI et a besoin d'un BAA. Pour la souveraineté, choisissez un opérateur dans votre juridiction.
E-mail vers des destinataires externes
Les e-mails entre vos propres utilisateurs peuvent rester sur votre serveur. Ceux envoyés à quiconque d'autre passent par son fournisseur. Le HHS autorise l'e-mail non chiffré vers des patients qui ont été avertis du risque et le préfèrent malgré tout. Pour tout le reste, utilisez un lien sécurisé vers un fichier dans Nextcloud plutôt qu'une pièce jointe.
Intégrations, bots et accès du support
Un bot SaaS dans un canal de chat, un assistant IA qui lit les messages, une sauvegarde copiée chez un fournisseur étranger ou un ingénieur d'un prestataire avec un accès SSH : chacun défait le niveau de souveraineté qu'il touche, et peut nécessiter son propre BAA.
Tracez le périmètre sur papier avant de construire. Listez chaque chemin qu'un message peut emprunter pour sortir de vos serveurs, puis décidez pour chacun : le bloquer, le chiffrer ou l'accepter par écrit.
Archives, conservation et journaux
Une plateforme de communication produit des archives à six endroits à la fois, et chaque application a son propre réglage de conservation. Réglez-les délibérément.
Conserver et protéger
- Les journaux de connexion et d'administration de Keycloak et de chaque application
- Vos politiques HIPAA et votre analyse de risques, pendant six ans selon le 45 CFR 164.316(b)(2)(i)
- Les sauvegardes, chiffrées, dans la même juridiction que les données en production
Limiter, et supprimer selon un calendrier
- Les enregistrements et transcriptions de réunions (la plupart des équipes n'en ont pas besoin)
- L'historique de chat au-delà de ce qu'exige votre politique
- Le contenu des messages dans les journaux, les rapports d'erreurs et les outils de supervision
La minimisation des données du RGPD et les règles de conservation de HIPAA peuvent tirer dans des directions opposées. Tranchez la question dans votre politique, canal par canal, avant d'activer quoi que ce soit.
Un ordre de déploiement qui fonctionne
- Analyse de risques ou AIPDNotez quelles données chaque canal transportera et qui en a besoin. Chaque choix ultérieur en découle.
- IdentitéKeycloak avec MFA, avant toute application destinée aux utilisateurs.
- Chat et vidéoLes outils que tout le monde utilise à chaque heure. Migrez d'abord une équipe et corrigez ce qu'elle trouve.
- FichiersNextcloud, avec des règles de partage fixées avant le premier envoi.
- TéléphoneAccès téléphonique ou trunk SIP, une fois la question de l'opérateur réglée.
- L'e-mail en dernierC'est le plus difficile à migrer : enregistrements MX, réputation DNS et des années de boîtes aux lettres. Faites tourner les deux en parallèle avant de basculer.
Une plateforme auto-hébergée vaut-elle le coup ?
Si quelqu'un aux achats demande quel droit s'applique à vos communications, oui. Aucun contrat avec un fournisseur américain ne répond pleinement à cette question, et les organisations qui ont franchi le pas (la France avec Visio, construit sur LiveKit ; l'Allemagne avec openDesk ; et la Cour pénale internationale, qui a quitté Microsoft Office après la suspension d'un compte liée à des sanctions) ont toutes choisi de l'open source exploité dans leur propre juridiction.
Si votre seule exigence est HIPAA, la décision est plus serrée. Une suite hébergée sous BAA peut être conforme et demande moins de travail d'exploitation. L'auto-hébergement se justifie quand vous voulez maîtriser où vivent les données, ce qui est journalisé et qui peut atteindre les serveurs, ou quand les licences par utilisateur finissent par peser lourd dans une grande organisation.
Dans tous les cas, commencez par l'identité et la liste des fuites. Ce sont elles qui décident si la plateforme passe vraiment les tests, pas le serveur de chat que vous avez choisi.
Questions fréquentes
Qu'est-ce qu'une plateforme de communication souveraine ?
Une plateforme dont le logiciel, l'infrastructure, l'exploitation et les clés de chiffrement relèvent tous du droit de votre juridiction, de sorte qu'aucun gouvernement étranger ne peut imposer l'accès à vos données.
Une même plateforme peut-elle être souveraine et conforme à HIPAA ?
Oui. Des outils open source sur une infrastructure que vous contrôlez peuvent satisfaire les deux, à condition d'avoir un BAA là où il le faut et de garder les clés et l'exploitation dans votre juridiction.
Microsoft Teams est-il souverain si j'utilise une région de données dans l'UE ?
Pas complètement. Microsoft est une entreprise américaine, donc le CLOUD Act s'applique quel que soit l'endroit où se trouvent les données.
Quels outils open source composent la pile ?
Keycloak pour l'identité, Mattermost/Zulip/Element pour le chat, Jitsi ou plugNmeet pour la vidéo, Jigasi pour le téléphone, Nextcloud pour les fichiers, mailcow pour l'e-mail et Coturn comme relais TURN.
Une entité soumise à HIPAA peut-elle écrire aux patients depuis un serveur auto-hébergé ?
Oui, si les patients ont été avertis du risque et préfèrent malgré tout un e-mail non chiffré. Pour tout le reste, utilisez un lien sécurisé plutôt qu'une pièce jointe.
Faut-il encore un BAA si tout est auto-hébergé ?
Pas pour votre propre matériel. Il en faut un avec tout fournisseur cloud, toute intégration SaaS ou tout prestataire ayant accès à des ePHI.
Quelle partie est la plus difficile à rendre souveraine ?
L'e-mail. Les enregistrements MX, la réputation DNS et des années de boîtes aux lettres en font le canal le plus lent à migrer, et les fournisseurs des destinataires externes restent toujours hors de votre contrôle.
Vous préparez une plateforme souveraine ou prête pour HIPAA ?
Nous déployons et exploitons du chat, de la vidéo, des fichiers et de l'e-mail open source sur une infrastructure que nos clients contrôlent. Dites-nous de quels canaux vous avez besoin et où les données doivent rester.
Parler à Meetrix