Pourquoi héberger son propre serveur Matrix
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.
Ce que vous gagnez avec un Matrix auto-hébergé
- Fédération : vos utilisateurs joignent ceux de n'importe quel autre serveur Matrix, sans compte supplémentaire.
- Chiffrement de bout en bout par salon, indépendant de la confiance envers l'hébergeur.
- Identifiants à votre nom de domaine, qui deviennent une adresse durable.
- Applications officielles Element sur mobile, bureau et web.
- Historique et fichiers stockés sur votre machine, sans limite de rétention imposée.
- Passerelles possibles vers d'autres réseaux (IRC, XMPP…) via des bridges.
Le point à comprendre AVANT d'installer : le nom de domaine
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.
Prérequis matériels
La pile complète — Synapse, PostgreSQL, Element 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.
Déployer Matrix avec Docker, PostgreSQL et Element
Choisir et pointer le domaine
Décidez du sous-domaine définitif (par exemple matrix.votre-domaine.com) et faites-le pointer vers votre VPS par un enregistrement A. C'est ce nom qui deviendra l'identité du serveur.
Générer la configuration et la clé de signature
Le premier démarrage de l'image Synapse génère homeserver.yaml et surtout la CLÉ DE SIGNATURE du serveur, celle qui authentifie ses événements auprès des autres serveurs. Sauvegardez-la : la perdre revient à perdre l'identité du serveur.
Basculer la base sur PostgreSQL
L'image ne sait générer qu'une configuration SQLite. Ajoutez un fichier dans conf.d/ qui redéfinit le bloc database vers PostgreSQL — Synapse lit plusieurs --config-path et les clés répétées écrasent les précédentes. Créez la base avec un collationnement C : Synapse refuse de démarrer sur une base au collationnement différent, et ce choix ne se change pas après création.
Placer un reverse proxy devant
Servez Element à la racine et l'API Matrix sous /_matrix et /_synapse/client, derrière un seul domaine en HTTPS. Relayez bien les en-têtes Upgrade/Connection : Matrix maintient des connexions longues, sans quoi le temps réel ne fonctionne pas.
Publier la délégation .well-known
Exposez /.well-known/matrix/server et /.well-known/matrix/client sur votre domaine. C'est ce qui permet aux autres serveurs et aux applications mobiles de trouver votre homeserver sans configuration manuelle. Vérifiez ensuite sur federationtester.matrix.org.
Configurer Element sur VOTRE serveur
Point d'attention : Element embarque une configuration d'usine qui pointe sur matrix.org. Si votre config.json n'est pas servi correctement, l'interface s'affiche parfaitement… et connecte vos utilisateurs au serveur public au lieu du vôtre. Element demande config.<domaine>.json AVANT config.json : les deux doivent répondre votre configuration.
Se connecter la première fois
Synapse ne crée aucun compte tout seul et les inscriptions doivent rester fermées. Créez le compte administrateur avec register_new_matrix_user, puis connectez-vous sur https://votre-domaine. Sur ServOrbit, ce compte admin est créé automatiquement au premier démarrage et son mot de passe généré est lisible dans votre espace client.
Fermez les inscriptions, et gardez-les fermées
Un serveur Matrix dont les inscriptions sont ouvertes est rapidement découvert et utilisé comme relais par des tiers : comptes de spam, salons indésirables, et une base qui gonfle sans que vous ayez rien demandé. Laissez enable_registration à false et créez les comptes à la main, ou passez par une authentification externe. Si vous ouvrez les inscriptions, exigez au minimum une vérification par e-mail.
La documentation officielle
Pour la configuration avancée — workers, bridges, modules d'authentification, purge d'historique — référez-vous à la documentation officielle de Synapse. Ce guide couvre la mise en ligne sur VPS ; la doc amont reste la référence pour les réglages fins et les montées de version majeures.
