Matrix Synapse : messagerie fédérée self-hosted pour entreprise

Slack a rendu la messagerie d'équipe omniprésente. La facture aussi. Microsoft Teams a inondé le marché par bundling. Quand une organisation veut sortir de ces silos pour une raison de souveraineté, de coût ou d'audit, Matrix est l'option fédérée crédible. Et Synapse, en Python, reste l'implémentation serveur de référence.

Matrix n'est pas un produit. C'est un protocole ouvert, fédéré, chiffré bout en bout, standardisé par la Matrix.org Foundation. Synapse est l'implémentation historique. Dendrite (en Go) et Conduit (en Rust) émergent comme alternatives plus légères. Element est le client web et mobile dominant.

Côté ops, déployer un Synapse en production demande plus qu'un docker compose up. C'est une stack distribuée qui touche au DNS fédération, au reverse proxy, à la base PostgreSQL, au stockage media, au TLS, et à la conformité.

• Pourquoi Matrix, et pour qui
• Architecture Synapse et fédération
• Choix client : Element et alternatives
• Déploiement production avec Docker Compose
• Configuration fédération et bridges
• Hardening et opérations
• Synapse vs Dendrite vs Conduit
• Cas d'usage entreprise

Trois profils d'organisation pour qui Matrix fait sens.

Souveraineté forte. Secteur public, défense, santé, juridique : aucune messagerie cloud US n'est compatible avec les exigences. Matrix permet de garder toutes les données chez soi, avec chiffrement E2E, et de fédérer avec des partenaires externes sans donner les clés à un tiers.

Coût Slack/Teams hors de proportion. Au-delà de quelques centaines d'utilisateurs, l'addition Slack devient sérieuse. Matrix n'a pas de coût licence par siège. Le coût opérationnel reste, mais il est prévisible.

Stack open source cohérente. Quand on opère déjà du Nextcloud comme intranet et un mail souverain, ajouter Matrix complète la stack collab self-hosted. Element a un connecteur calendrier qui pointe sur du CalDAV.

Pour qui Matrix n'est pas la cible : une PME de 30 personnes qui a juste besoin de chat et de visio. La maintenance Matrix est non triviale. Mieux vaut accepter le coût Mattermost cloud ou un Slack Free dans ce contexte.

Synapse est un homeserver. Chaque homeserver gère :

• ses utilisateurs locaux (@alice:exemple.fr)
• les rooms qu'il héberge
• la fédération avec les autres homeservers (sortie et entrée)
• les médias (fichiers partagés, images, audio)

La fédération se fait via le protocole Matrix Server-Server API, transport HTTPS sur un port dédié. La découverte se fait par un enregistrement .well-known/matrix/server ou un SRV DNS _matrix._tcp.exemple.fr.

L'infra typique d'un Synapse de prod ressemble à ça :

Sur un déploiement avec 500+ utilisateurs actifs, scinder Synapse en workers est obligatoire. Le main process ne tient plus la charge sync seul.

Element (anciennement Riot) est le client de référence : web, desktop (Electron), iOS, Android. Maintenu par Element (la société, anciennement New Vector). Couvre 95% des cas en entreprise. Possibilité de self-hoster Element web côté reverse proxy pour éviter d'embarquer une dépendance vers app.element.io.

Alternatives notables :

• Cinny : client web léger en React, plus moderne visuellement.
• FluffyChat : multi-plateforme Flutter, orienté UX consumer.
• NeoChat : client KDE pour Linux/Plasma.
• Element X : nouvelle génération Element en Rust, mobile only en 2026, beaucoup plus rapide.

Pour une organisation : Element web + Element mobile + Element Desktop suffisent. Documenter le client officiel évite la fragmentation.

Stack Compose minimal :

version: '3.9'
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: synapse
      POSTGRES_USER: synapse
      POSTGRES_PASSWORD: <secret>
    volumes:
      - ./postgres:/var/lib/postgresql/data
  synapse:
    image: matrixdotorg/synapse:latest
    depends_on:
      - postgres
    volumes:
      - ./synapse:/data
    environment:
      SYNAPSE_SERVER_NAME: exemple.fr
      SYNAPSE_REPORT_STATS: 'no'
  element:
    image: vectorim/element-web:latest
    volumes:
      - ./element/config.json:/app/config.json

Devant : un Caddy ou Nginx avec deux vhosts. matrix.exemple.fr route vers Synapse. chat.exemple.fr sert Element. Le .well-known se sert sur https://exemple.fr/.well-known/matrix/server avec {"m.server": "matrix.exemple.fr:443"}.

Le PostgreSQL doit être tuné. Synapse génère beaucoup d'événements. Penser à shared_buffers, effective_cache_size, work_mem selon la RAM disponible. Voir notre article postgresql-performance pour les bases.

Pour le stockage média, configurer S3 backend dès le départ. Une instance Synapse mature accumule rapidement plusieurs centaines de Go de médias. Stocker en local sur le filesystem du conteneur n'est pas une option durable.

La fédération Matrix permet à @alice:exemple.fr de communiquer avec @bob:matrix.org sans configuration spéciale, dès lors que le DNS et le TLS sont propres.

Quelques contrôles à valider :

• https://federationtester.matrix.org/api/report?server_name=exemple.fr doit renvoyer "succès" sur tous les checks.
• Certificat TLS valide (Let's Encrypt suffit), CN qui couvre matrix.exemple.fr.
• Port 8448 fédération exposé OU délégation .well-known propre.
• Politique de fédération : par défaut ouverte, à restreindre via federation_domain_whitelist si on veut limiter aux partenaires connus.

Les bridges étendent Matrix vers d'autres protocoles : Slack, Discord, IRC, Telegram, Signal, WhatsApp, XMPP, mail. Maintenus par mautrix (Go) majoritairement. En entreprise, le pont qui revient le plus souvent : mautrix-slack pour absorber un Slack legacy pendant migration, ou mx-puppet-discord pour interopérer avec une communauté Discord.

Configuration d'un bridge typique : registration YAML déposé dans /data/appservices/, ligne app_service_config_files dans homeserver.yaml, restart Synapse, login bridge. Pas trivial mais bien documenté.

Quelques points qui distinguent un Synapse qui tient en prod d'un Synapse qui dérive.

Inscription publique fermée par défaut. enable_registration: false. Inscription par invitation ou par SSO Keycloak/Authentik. Sinon : ouvert aux spammeurs en quelques jours.

SSO. Synapse supporte OIDC, SAML, CAS. Connecter à un Keycloak existant ou Authentik évite de gérer les comptes en local.

Rate limiting. rc_message, rc_login, rc_registration à configurer pour bloquer les abus. Synapse expose ces seuils côté homeserver.

Backup. PostgreSQL dump quotidien chiffré, stockage médias S3 backed up via restic ou kopia. Restauration testée trimestriellement. Même contrainte que pour le mail : sans test de restore, le backup n'existe pas.

Workers. Au-delà de 500 utilisateurs actifs, ajouter au minimum un federation_sender_worker, pusher_worker, sync_worker. La doc Synapse détaille la séparation.

Monitoring. Synapse expose des métriques Prometheus complètes. Dashboard Grafana fourni. Alerter sur le retard de fédération sortante (events backlog), sur la latence sync, sur la taille de la DB qui croît.

State resolution. Les rooms anciennes ou très peuplées (rooms publiques sur matrix.org avec des milliers de membres) consomment énormément de CPU lors des resolutions d'état. Si l'instance home server rejoint ces rooms, la charge explose. Documenter et limiter.

Verdict 2026 : Synapse reste la cible entreprise par défaut. Dendrite est la promesse pour le scale (microservices natifs, écrit pour être horizontal), mais des features avancées manquent encore. Conduit est l'option élégante pour un home server perso ou une petite équipe (10-50 personnes).

Pour un déploiement neuf >100 utilisateurs avec ambition fédération multi-site : Synapse. Pour un cluster K8s qui veut déployer des homeservers à la chaîne : surveiller Dendrite.

Plusieurs scénarios où on a vu Matrix marcher.

Communications inter-administrations. Plusieurs entités de l'État français opèrent leurs propres homeservers Matrix et fédèrent. La discussion @agent:ministere-a.gouv.fr avec @partenaire:agence-b.gouv.fr fonctionne sans tiers cloud.

Collaboration secteur santé. Échanges médecins-patients, équipes hospitalières, avec audit trail et chiffrement E2E. Le respect HDS de l'hébergeur est la contrainte. Matrix lui-même est compatible techniquement.

Communautés open source. Matrix.org, K8s, Fedora, Mozilla : ces communautés opèrent leurs homeservers et fédèrent vers leurs membres.

Backbone de communication interne. Une fois bridge Slack en place, basculer progressivement les channels Slack vers Matrix natif sur 6 mois. Migration douce sans rupture utilisateur.

Sur les déploiements qu'on opère pour nos clients souverains, Matrix complète la stack collab open source à partir d'un seuil de 100 utilisateurs ou d'une exigence de fédération avec partenaires externes. La courbe d'apprentissage côté opérateur est réelle (workers, fédération, DB tuning), mais le résultat est une plateforme messagerie qui ne dépend ni de Slack ni de Microsoft. Si vous évaluez Matrix pour une organisation 200+ et que vous voulez sécuriser le déploiement avant d'engager, on peut auditer la cible et opérer la stack en prod pendant le warmup.

• Matrix.org documentation : protocole, spécifications, écosystème.
• Synapse documentation officielle : install, ops, workers, hardening.
• Element documentation : clients, configuration, intégration entreprise.
• GitHub element-hq/synapse : code, releases, issues.
• Matrix Federation Tester : outil de validation fédération.
• Mautrix bridges : passerelles vers Slack, Discord, Telegram, Signal, WhatsApp.