Héberger Matrix (Synapse) et Element sur votre propre VPS

Les messageries d'équipe classiques — Slack, Teams, et même leurs alternatives auto-hébergées — partagent une limite : on n'y parle qu'entre membres du même serveur. Matrix renverse cela. C'est un protocole FÉDÉRÉ : votre serveur dialogue avec tous les autres serveurs Matrix du monde, exactement comme une adresse e-mail joint n'importe quel autre domaine. Vos utilisateurs gardent un identifiant à vous (@alice:votre-domaine.com) tout en discutant avec des interlocuteurs hébergés ailleurs. À cela s'ajoute le chiffrement de bout en bout, activable salon par salon : même vous, administrateur du serveur, ne pouvez pas lire le contenu d'un salon chiffré. C'est le point qui distingue Matrix d'une messagerie simplement auto-hébergée — la souveraineté ne repose pas sur la confiance envers l'hébergeur, mais sur la cryptographie.

Element Web est une application web open source — vous pouvez l'héberger sur votre propre domaine au lieu d'utiliser app.element.io. Ce choix est souvent négligé, mais il compte. Quand vos utilisateurs ouvrent app.element.io, leur navigateur charge du JavaScript depuis les serveurs d'Element HQ : cela n'affecte pas la confidentialité des messages (le chiffrement reste local), mais cela crée une dépendance externe.

Héberger Element Web vous-même — typiquement derrière chat.votre-domaine.com — supprime cette dépendance. Vous maîtrisez la version déployée, vous pouvez personnaliser config.json pour que l'interface soit pré-configurée sur votre homeserver, et vos utilisateurs n'ont qu'une seule URL à retenir.

Point d'attention : Element Web lit config.<domaine>.json AVANT config.json. Si votre configuration n'est pas servie correctement, l'interface s'affiche parfaitement — et connecte vos utilisateurs au serveur public au lieu du vôtre. Vérifiez que les deux fichiers répondent votre configuration avant d'inviter des utilisateurs.

C'est la particularité de Matrix, et la source d'erreur la plus coûteuse. Le server_name de votre serveur — votre nom de domaine — n'est pas un réglage d'affichage : il est inscrit DANS l'identité de chaque objet que le serveur produit. Chaque identifiant d'utilisateur (@alice:votre-domaine.com), chaque identifiant de salon, chaque événement signé le contient. Le changer après coup ne se fait pas : il faut repartir d'un serveur vierge et recréer les comptes. Choisissez donc le sous-domaine définitif dès l'installation, et attachez-le au moment où vous installez l'application — pas après. Sur ServOrbit, l'installation refuse d'ailleurs volontairement de démarrer si aucun domaine n'est rattaché : mieux vaut un échec immédiat et clair qu'un serveur qu'il faudra refaire une fois les comptes créés.

La pile complète — Synapse, PostgreSQL, Element Web et le reverse proxy — consomme environ 300 Mo au repos, mesure faite sur une installation neuve. Un VPS de 2 Go de RAM et 2 vCPU convient donc largement à une équipe, une association ou une famille.

La consommation dépend surtout des salons PUBLICS que vous rejoignez : Synapse conserve l'historique et l'état de chaque salon fédéré, et rejoindre quelques grands salons communautaires peut faire croître la base de plusieurs gigaoctets. Si c'est votre usage, visez 4 Go de RAM et surveillez l'espace disque.

PostgreSQL est indispensable — Synapse accepte SQLite, mais ne le recommande pas au-delà d'un serveur d'essai. Prévoir aussi un certificat TLS valide : sans HTTPS, la fédération et les applications mobiles refusent de se connecter.

Synapse expose une API d'administration sous /_synapse/admin/v1 — réservée aux comptes marqués admin. Via cette API, vous pouvez désactiver un compte, purger l'historique d'un salon, forcer la déconnexion de tous les appareils d'un utilisateur ou consulter les statistiques de fédération.

Synapse Admin (interface web open source, déployable en conteneur séparé) repose sur cette même API et offre une vue graphique : liste des utilisateurs, salons, appareils enregistrés et taille de la base par salon. Pratique pour repérer un salon fédéré qui gonfle la base de plusieurs gigaoctets.

Pour les mises à jour, Synapse publie ses images sur ghcr.io/element-hq/synapse. Vérifiez les notes de release avant chaque mise à jour majeure : certaines migrations de base sont irréversibles, et Synapse documente explicitement les versions minimum requises pour passer d'une branche à l'autre.

Un serveur fédéré accumule l'historique de tous les salons rejoints — y compris les grands salons publics. Sans purge régulière, la base PostgreSQL peut atteindre plusieurs dizaines de gigaoctets en quelques mois.

Synapse propose deux leviers. La purge d'historique via l'API admin (POST /_synapse/admin/v1/purge_history) supprime les événements antérieurs à une date dans un salon donné — sans affecter les autres salons ni les messages que vous n'avez pas encore lus. La commande synapse_auto_compressor compresse ensuite les groupes de state_groups dans PostgreSQL, ce qui peut diviser la taille de la base par deux ou trois sur un serveur actif depuis plusieurs mois.

Activez aussi gc_thresholds dans homeserver.yaml pour piloter le garbage collector Python de Synapse : sur un serveur fédéré actif, le GC par défaut est rarement optimal pour la mémoire résidente.

L'un des avantages distinctifs de Matrix est son écosystème de bridges — des services qui font le lien entre votre homeserver et d'autres réseaux. Matterbridge, Beeper ou les bridges officiels du projet Matrix permettent de relayer des messages entre un salon Matrix et un groupe Telegram, un canal Slack ou une conversation WhatsApp.

Chaque bridge se déploie comme un service supplémentaire (un conteneur supplémentaire dans votre compose.yml) et s'enregistre auprès de Synapse via un fichier registration.yaml. Le bridge reçoit une portion de l'espace des identifiants (@telegram_*:votre-domaine.com) et traduit les messages dans les deux sens.

Pour Telegram, mautrix-telegram est le bridge le plus maintenu. Pour Signal, mautrix-signal. Ces deux bridges exigent un compte sur le réseau cible — pas de lecture sans compte. WhatsApp et Meta Messenger passent par mautrix-meta, qui utilise l'API non officielle : son fonctionnement dépend des décisions de Meta et peut être interrompu.