Auto-héberger un serveur Matrix

Si vous auto-hébergez Matrix, c'est d'abord pour qu'une entreprise ne détienne plus vos conversations — et sur ce point, la promesse est tenue. Ce qui vous surprendra plus tard, c'est la nature réelle de ce que vous avez installé : un serveur personnel (homeserver) n'est pas un boîtier privé qui fait aussi office de messagerie. C'est un nœud de réplication au sein d'un réseau public, et la fédération se comporte bien davantage comme un protocole de publication que la plupart des nouveaux administrateurs ne l'imaginent.

Rien de tout cela ne plaide contre l'auto-hébergement — cela plaide pour le faire délibérément. La confidentialité que vous gagnez est réelle mais précise : la garde des données vous revient, personne d'autre ne peut fermer votre compte, et les questions juridiques relèvent de la juridiction que vous avez choisie plutôt que de celle choisie par une entreprise. La confidentialité que vous ne gagnez pas est tout aussi précise, et elle tient presque entièrement dans l'écart entre « les messages sont chiffrés » et « personne ne peut savoir qui parle à qui ». Ce guide couvre les deux volets, puis les détails opérationnels qui détermineront si votre serveur sera encore sain dans un an.

Ce que change réellement le fait d'exploiter son propre serveur

Commencez par distinguer les menaces, car un serveur personnel n'y répond que partiellement selon les cas : complètement pour certaines, partiellement pour d'autres, pas du tout pour le reste. Le tableau ci-dessous est la version honnête de l'argumentaire, et il vaut mieux le lire avant de choisir votre matériel plutôt qu'après.

Relisez attentivement les deux dernières lignes : c'est là que les attentes se heurtent à la réalité. Si votre objectif est que personne ne puisse établir qu'un service existe, Matrix n'est pas le bon outil, et un service onion s'en rapproche bien davantage. Si votre objectif est la garde des données, le contrôle et la juridiction, un serveur personnel est un excellent instrument, et le reste de ce guide explique comment bien l'exploiter.

La fédération : un protocole de réplication déguisé en protocole de messagerie

Voici le mécanisme qui explique la plupart des surprises. Lorsqu'un de vos utilisateurs rejoint un salon hébergé ailleurs, votre serveur ne va pas chercher les messages à la demande comme le ferait un client de messagerie électronique. Il rejoint le salon en tant que participant à un graphe d'événements distribué, puis récupère et stocke une copie des événements du salon, de sa liste de membres, et de suffisamment d'historique d'état pour valider ce qui suit. À partir de cet instant, votre machine détient une réplique — et chaque autre serveur participant en détient une aussi.

Les conséquences jouent dans les deux sens, et aucune n'est intuitive. Les données produites par vos utilisateurs — nom affiché, avatar, arrivées et départs, horodatages, réactions — sont copiées vers chaque serveur ayant un membre dans ce salon, et elles restent dans leurs bases de données quoi que vous supprimiez ensuite sur la vôtre. Une rédaction (redaction) est une demande adressée aux pairs, pas un ordre. Il n'existe pas de « désenvoi » à l'échelle d'une fédération de serveurs exploités indépendamment, et croire le contraire est le malentendu le plus courant sur ce protocole.

Dans l'autre sens, rejoindre de grands salons publics revient à importer l'historique d'autrui sur votre disque. C'est pourquoi un serveur tout juste installé avec trois utilisateurs peut porter une base de données de plusieurs dizaines de gigaoctets : non pas parce que vos trois utilisateurs ont beaucoup écrit, mais parce qu'ils ont rejoint des salons de cinquante mille membres et des années d'état accumulé. Choisir ses salons avec discernement relève donc autant d'une décision de capacité que de confidentialité.

Ce que le chiffrement couvre, et ce qui reste en clair

Matrix chiffre le contenu des messages avec Megolm, activé par défaut dans les salons privés. Cela protège ce à quoi les gens tiennent le plus, et cela fonctionne réellement : votre serveur stocke un texte chiffré qu'il ne peut pas lire, une propriété concrète et utile lorsque le serveur tourne sur du matériel loué. L'enveloppe autour du message, en revanche, c'est une autre histoire — et l'écart est plus large que ne l'admettent la plupart des résumés.

En pratique : le chiffrement protège le quoi, la fédération publie le qui, quand et à quelle fréquence. Pour la plupart des communautés, ce compromis est parfaitement acceptable, et c'est justement cette franchise qui fait sa valeur. Mais pour un modèle de menace où le graphe social lui-même constitue l'information sensible, un protocole fédéré est structurellement inadapté, et aucun paramètre de configuration n'y changera rien.

Synapse, Dendrite ou Conduit : que faire tourner concrètement

Trois implémentations comptent en pratique, et le choix relève surtout d'une question de ressources que d'une question de philosophie.

• Synapse est le serveur de référence, écrit en Python, et le seul où chaque fonctionnalité marche dès le premier jour. C'est aussi le plus gourmand : la mémoire croît avec le nombre et la taille des salons que rejoignent vos utilisateurs, et un serveur très actif finit par avoir besoin d'être scindé en processus de travail (workers). Choisissez-le si vous avez besoin que les espaces, les outils de modération, les passerelles (bridges) et les API d'administration se comportent exactement comme documenté.
• Dendrite est la réécriture en Go. Nettement plus léger que Synapse et parfaitement utilisable pour un petit serveur, au prix d'un certain retard sur certaines fonctionnalités. Une option médiane raisonnable quand Synapse vous semble disproportionné par rapport au nombre réel d'utilisateurs.
• Conduit et son fork activement développé conduwuit sont écrits en Rust et se déploient comme un binaire unique avec base de données embarquée. Ils font tourner sans broncher un serveur familial ou de petite communauté sur notre offre la plus modeste. La contrepartie : un écosystème plus restreint — certains outils d'administration et quelques passerelles supposent Synapse.

Pour un premier serveur avec une poignée d'utilisateurs, un logiciel de la famille Conduit sur un petit VPS est la voie la moins pénible vers quelque chose qui fonctionne et reste bon marché. Pour tout ce qui est appelé à grandir — communauté publique, entreprise, projet avec passerelles — démarrez directement sur Synapse et évitez-vous la migration, car passer d'une implémentation à l'autre plus tard revient à exporter et reconstruire, pas à changer un paramètre.

Le paramétrage de délégation que tout le monde rate

Matrix sépare le nom présent dans vos identifiants utilisateur de la machine qui sert le trafic, et inverser les deux est l'erreur irréversible la plus courante en auto-hébergement. Votre server_name est le domaine qui apparaît après les deux-points dans chaque identifiant utilisateur de votre serveur. Il fait partie de votre identité dans la fédération dès que le premier événement est signé, et il ne peut plus être modifié ensuite sans abandonner tous les comptes et tous les salons de la machine.

Le montage que vous voudrez presque toujours : server_name est votre domaine nu, tandis que le logiciel tourne sur un sous-domaine. Vous reliez les deux par délégation, de l'une des deux façons suivantes. La plus simple est un fichier JSON statique servi à l'adresse /.well-known/matrix/server sur le domaine nu, indiquant l'hôte réel et le port. L'alternative est un enregistrement DNS, _matrix._tcp, pointant vers le même endroit. Servez également le fichier côté client à /.well-known/matrix/client, afin que les applications retrouvent le serveur à partir de l'adresse seule.

Dimensionner honnêtement

En fonctionnement normal, Matrix n'est pas limité par le CPU ; il l'est par la mémoire et par le comportement de la base de données. Les chiffres publiés pour Synapse constituent un plancher utile : environ 2 Go de RAM pour démarrer, environ 4 Go à partir de dix à cinquante utilisateurs actifs, et 8 Go ou plus au-delà de cent. Les serveurs de la famille Conduit se situent très en dessous. Ce que ces chiffres omettent, c'est que la consommation suit les salons rejoints, pas les comptes enregistrés — cinq utilisateurs dans une centaine de grands salons publics coûtent bien plus que cinquante utilisateurs dans une poignée de salons privés.

Deux règles pratiques en découlent. Placez la base de données sur un stockage rapide et laissez-lui de la marge pour grossir, car le schéma d'écriture est modeste et constant plutôt que par à-coups. Et ne dimensionnez pas pour le nombre d'utilisateurs d'aujourd'hui : dimensionnez pour les salons que ces utilisateurs rejoindront durant le premier mois, c'est généralement là que se cache la surprise. Notre offre d'entrée supporte confortablement un petit serveur Conduit ou Dendrite, tandis qu'une instance Synapse pour une vraie communauté relève d'une offre intermédiaire ou supérieure — la page dédiée à l'hébergement de messagerie détaille les paliers que nous recommandons pour chacun de ces profils.

La disponibilité compte ici davantage que pour la plupart des charges de travail, car un serveur de messagerie hors service n'est pas simplement indisponible : il manque silencieusement des événements que les pairs tenteront de lui livrer un moment avant de renoncer. La fédération pardonne les minutes, elle est impitoyable avec les jours.

Le stockage des médias : une bombe à disque à retardement

Chaque image, vidéo et fichier qui transite par un salon où se trouvent vos utilisateurs peut finir mis en cache sur votre disque — y compris des médias distants que vos propres utilisateurs n'ont jamais ouverts. La rétention par défaut de Synapse les conserve indéfiniment. Le résultat est prévisible et continue pourtant de surprendre : une base de données stable, mais un répertoire de médias qui grossit discrètement jusqu'à saturer le volume — et le symptôme n'est alors pas « disque plein » mais « le serveur se comporte bizarrement ».

Définissez une politique de rétention pour les médias distants dès le premier jour, plutôt qu'après la première panne. Synapse expose des paramètres de rétention dans homeserver.yaml, ainsi que des points d'API d'administration pour purger l'historique ancien et les fichiers mis en cache ; synapse-compress-state récupère une quantité surprenante d'espace sur les tables d'état d'un serveur ancien. Surveillez à la fois la base de données et le répertoire des médias, et alertez sur l'espace disque disponible plutôt que sur l'arrêt du service — le second symptôme n'arrive que des jours après le premier.

Un réglage mérite une décision réfléchie plutôt qu'une valeur par défaut. Les aperçus de liens (URL previews) obligent votre serveur à récupérer tout lien posté dans un salon, ce qui signifie que l'adresse IP de votre serveur effectue une requête sortante vers un tiers dès qu'un lien est collé — y compris un lien choisi spécifiquement pour voir qui mord à l'hameçon. Si votre serveur se trouve derrière une façade et que son adresse réelle importe, pesez cela avec soin ; notre guide sur la dissimulation d'une adresse d'origine traite plus en détail de cette même catégorie de fuite.

Inscriptions, spam et la réputation dont vous héritez

Laisser les inscriptions ouvertes sur un serveur public est une invitation — mais pas celle que vous souhaitez. Des inscriptions automatisées transforment un petit serveur en source de spam en quelques jours, et la conséquence n'est pas locale : d'autres serveurs ajoutent votre domaine à des listes de contrôle d'accès, et une fois votre nom présent sur suffisamment d'entre elles, vos utilisateurs légitimes ne peuvent plus participer aux salons hébergés ailleurs. Restaurer une réputation de domaine grillée est bien plus difficile que de l'éviter — exactement comme pour la délivrabilité des e-mails.

Les réglages par défaut défendables sont simples. Laissez enable_registration désactivé pour un serveur privé et distribuez vous-même les comptes. Si vous voulez ouvrir la porte, verrouillez-la : registration_requires_token transforme l'inscription en système sur invitation sans aucun service tiers, et un captcha aide contre la partie la plus grossière du problème. Pour les salons que vous administrez, les robots de modération de la famille Mjolnir et Draupnir vous permettent d'appliquer des listes de bannissement et des ACL de salon à l'échelle de toute une communauté plutôt que salon par salon.

Une chose vaut d'être sue dans l'autre sens : nos plages d'adresses ne figurent pas sur les listes de blocage ACL Matrix qui circulent entre serveurs, de sorte qu'un nouveau serveur démarre avec une réputation vierge. Ce qu'il advient ensuite de cette réputation dépend de la façon dont vous gérez les inscriptions, pas de l'emplacement de la machine.

Les passerelles, et la facture de métadonnées qui va avec

Les passerelles sont la vraie raison pour laquelle beaucoup restent sur Matrix : un seul client pour des salons qui vivent sur d'autres réseaux. Elles modifient aussi la posture de sécurité de votre serveur, d'une manière qu'il est facile de négliger. Une passerelle détient les identifiants du compte distant et, à la frontière où les protocoles se rencontrent, elle traite nécessairement les messages sous une forme qu'elle peut convertir — ce qui signifie que le processus de passerelle voit en clair un trafic pourtant chiffré de bout en bout de part et d'autre.

Ce n'est pas une raison d'éviter les passerelles. C'est une raison de traiter la machine qui les héberge comme une infrastructure sensible : c'est elle qui, en cas de compromission, expose les comptes pour lesquels elle parle. Chaque passerelle double à peu près l'empreinte mémoire d'un petit serveur — prévoyez la capacité en conséquence, et accordez au choix de son emplacement la même réflexion qu'au serveur lui-même — le raisonnement de notre guide sur le choix d'une juridiction s'applique avec encore plus de force à une machine détenant les identifiants de plusieurs réseaux à la fois.

Le garder en vie : clés, sauvegardes et mises à jour

Un serveur Matrix possède un fichier dont la perte est irrécupérable, et cela n'a rien à voir avec le volume de données. La clé de signature — signing.key sous Synapse — c'est ce par quoi votre serveur prouve que les événements se réclamant de votre domaine en proviennent réellement. La perdre, c'est ne plus pouvoir crédiblement être votre propre serveur ; les pairs rejetteront les événements signés par un inconnu portant votre nom. Sauvegardez-la séparément de tout le reste, et conservez cette copie hors de la machine.

Les mises à jour sont banales mais pas facultatives. Les nouvelles versions du serveur embarquent des migrations de schéma, et sauter de nombreuses versions transforme une mise à jour de cinq minutes en un après-midi entier. Lisez les notes de version avant de vous lancer, mettez à jour assez régulièrement pour que chaque étape reste petite, et appliquez l'hygiène de base décrite dans notre check-list de durcissement de la première heure — un serveur de messagerie est un service exposé sur Internet à long terme, doté d'une base de données, et il mérite le même traitement que n'importe quel autre.

L'emplacement du serveur reste déterminant

Tout ce qui précède relève de la configuration. Ce que la configuration ne peut pas toucher, c'est le système juridique qui reçoit une réquisition concernant vos utilisateurs — et pour un serveur de communication, cette question pèse plus lourd que pour un simple site web. Un serveur personnel conserve en clair les registres d'appartenance, les horodatages et les données de graphe social, même quand le corps des messages est chiffré — la juridiction qui l'héberge est donc celle qui régit l'accès à ces informations.

C'est l'argument pratique pour choisir un emplacement délibérément, et pas seulement en fonction de la latence. Nous en exploitons sept, et les compromis entre eux sont détaillés dans notre guide sur le choix d'une juridiction et sur la page des emplacements. L'autre moitié de la même question, c'est ce que le fournisseur sait de votre identité : un compte sans identité rattachée ne peut produire des documents d'identité qu'il n'a jamais collectés, ce qui explique tout simplement pourquoi l'hébergement sans KYC et les communications auto-hébergées reviennent sans cesse dans la même conversation. Ni l'un ni l'autre ne protège contre un tribunal qui possède déjà votre nom, et notre guide OpSec est sans détour sur l'endroit où se situe cette limite.

En résumé

Si vous ne retenez que six choses de cette page, retenez celles-ci :

• Choisissez le server_name avant d'installer quoi que ce soit — c'est la seule décision sur laquelle vous ne pourrez jamais revenir.
• Déléguez avec /.well-known/matrix/server ou un enregistrement SRV, et maintenez un certificat TLS valide sur les deux noms.
• Dimensionnez pour les salons que vos utilisateurs rejoindront, pas pour leur nombre.
• Réglez la rétention des médias dès le premier jour, et statuez sur les aperçus de liens plutôt que de subir la valeur par défaut.
• Gardez les inscriptions fermées ou verrouillées par jeton ; une réputation de domaine grillée coûte cher à réparer.
• Sauvegardez signing.key séparément, et ne restaurez jamais la base de données en retrait par rapport à vos pairs.

Faites cela, et votre serveur restera sans histoire — exactement ce qu'un serveur de messagerie devrait être. Ce que vous obtenez en échange mérite d'être regardé avec lucidité : non pas l'invisibilité, ni un protocole qui cache qui parle à qui, mais des conversations dont le contenu vous appartient, un compte que personne d'autre ne peut fermer, et une machine placée sous un système juridique que vous avez choisi délibérément. Installez votre serveur là où vous l'avez choisi, et laissez la fédération venir à vous.