← retour à l'accueil
root@souverainete:~$ cat etude-de-cas/matrix.md
étude de cas — stack: matrix

Sortir de Slack sans perdre le contrôle de sa communication

Déploiement d'une infrastructure Matrix/Synapse complète — deux serveurs dédiés, ponts vers WhatsApp et Telegram, base de données mutualisée — pour une structure qui voulait garder ses échanges chez elle, sans sacrifier le confort d'usage.

Type de structureAssociation, 40 salariés
DéclencheurFin de contrat Slack
Contrainte cléAucune donnée hors UE
StackDebian · Docker · Ansible
// contexte

Le problème

La structure utilisait Slack depuis plusieurs années. À l'approche du renouvellement du contrat, la direction a voulu évaluer une alternative hébergée en Europe — sans renoncer à ce que les salariés utilisent déjà au quotidien : discussions par équipe, messages directs, et surtout les groupes WhatsApp utilisés avec des partenaires externes qui, eux, ne changeraient pas d'outil.

Le vrai enjeu n'était donc pas seulement de remplacer Slack, mais de le faire sans imposer une rupture aux interlocuteurs externes — ce qui a orienté le choix vers Matrix avec des ponts applicatifs plutôt qu'une simple migration.

// enjeux

Ce qu'il fallait concilier

Souveraineté

Aucune donnée hébergée hors Union européenne, hébergeur choisi et audité par la structure elle-même.

Continuité

Les contacts externes sur WhatsApp et Telegram ne devaient rien changer à leurs habitudes.

Sécurité

Séparation stricte entre les comptes internes et les ponts vers des services tiers.

Évolutivité

Pouvoir ajouter un futur pont (Signal, Discord) sans remettre l'architecture à plat.

// architecture

Les choix qui structurent le déploiement

// 4 VM dédiées — base de données, homeserver utilisateurs, homeserver + ponts, infrastructure partagée (hors périmètre du rôle)
Séparer users / bridges

Le homeserver utilisé au quotidien par les salariés tourne isolé du homeserver qui porte les ponts — une panne ou une mise à jour d'un pont WhatsApp ne peut jamais affecter la messagerie interne.

Base de données mutualisée

Une seule VM PostgreSQL, une base par composant, ajout d'un futur composant en une entrée de variable — sans nouvelle tâche Ansible ni redémarrage de serveur.

Proxy hors périmètre

Le rôle ne gère jamais le reverse proxy, le DNS ou les certificats TLS — ces responsabilités restent dans l'infrastructure partagée de la structure, pour rester réutilisable ailleurs.

Tokens jamais régénérés

Les jetons d'authentification des ponts sont générés une fois et conservés — un rejeu du déploiement ne casse jamais une connexion déjà active.

// mise en œuvre

Ce qui a été fait

01

Provisionnement des 4 VM

Base de données, homeserver utilisateurs, homeserver + ponts, infrastructure partagée — chacune avec un rôle unique et documenté.

02

Déploiement Synapse en double instance

Un homeserver pour les comptes internes, un second dédié aux ponts — jamais mélangés, jamais sur la même base applicative.

03

Connexion des ponts WhatsApp et Telegram

Chaque pont dans son propre conteneur, sa propre base, son propre fichier d'enregistrement — ajout du prochain pont sans toucher aux existants.

04

Validation en conditions réelles

Vérification que chaque bot répond, que les messages passent dans les deux sens, avant toute bascule des équipes.

05

Bascule progressive des équipes

Migration par service, avec Slack maintenu en lecture seule le temps que chacun prenne ses marques sur Element.

// résultat

Ce que ça change

Toutes les données de messagerie restent hébergées en Europe, sur une infrastructure dont la structure garde la clé — sans que les contacts externes sur WhatsApp ou Telegram n'aient rien remarqué du changement.

0interruption ressentie par les contacts externes
4VM déployées de façon reproductible et documentée
1commande pour ajouter un futur pont
// limites

Ce qui reste hors périmètre

La configuration métier de chaque pont (connexion WhatsApp par QR code, liaison Telegram) reste une étape manuelle, propre à chaque compte — non automatisable côté infrastructure.

Le reverse proxy, le DNS et les certificats TLS ne sont pas gérés par ce déploiement — ils appartiennent à l'infrastructure partagée existante de la structure.

L'authentification forte (SSO/MFA) n'est pas encore intégrée sur cette installation — un chantier possible avec un fournisseur d'identité que la structure aura elle-même validé.

La sauvegarde des messages est déléguée à la politique de sauvegarde déjà en place chez l'hébergeur — ce déploiement ne réinvente pas ce qui existe déjà correctement.

ansible-role-matrix-stack
Le rôle Ansible complet, documenté et open source, utilisé pour ce déploiement.
Voir le code sur GitHub →

Un besoin de communication souveraine similaire ?

Chaque structure a ses propres contraintes — parlons de la vôtre avant de parler de solution.

Me contacter →