Choisir un serveur Matrix ne se résume pas à trouver le serveur avec le binaire le plus léger ; il s’agit plutôt de trouver les compromis opérationnels que vous êtes prêt à accepter. Synapse, Dendrite et Conduit sont tous compatibles avec Matrix, mais ils diffèrent par leur maturité, leur langage d’implémentation, leur modèle de base de données, leur capacité de mise à l’échelle et le niveau de risque de compatibilité que l’administrateur est prêt à accepter. Au 5 octobre 2026, le répertoire officiel des serveurs Matrix indiquait que Synapse était stable et que Dendrite et Conduit étaient en version bêta . Cette différence de maturité devrait être plus importante que de vagues affirmations selon lesquelles une option serait « légère ».
Cette comparaison pratique se concentre sur les éléments documentés et vérifiables à ce jour. Elle ne désigne pas de vainqueur universel en matière de RAM ou de processeur, car les projets ne publient pas de test de performance unique et contrôlé qui les représente équitablement dans les mêmes conditions : utilisateurs, salles, trafic de fédération, charge multimédia, optimisation de la base de données et matériel.
| Serveur | Émancipation officielle | Mise en œuvre | Chemin de stockage typique | Ajustement pratique |
|---|---|---|---|---|
| Synapse | Écurie | Python, avec des composants Rust dans la base de code actuelle | PostgreSQL est recommandé pour la production ; SQLite existe, mais sa documentation officielle indique qu'il est destiné aux tests. | Meilleure solution par défaut lorsque la compatibilité, la documentation, les intégrations et une stratégie de mise à l'échelle éprouvée sont primordiales. |
| Dendrite | Bêta | Aller | PostgreSQL dans le déploiement Docker documenté | À évaluer si vous souhaitez un serveur domestique basé sur Go et que vous pouvez accepter son niveau de maturité bêta. |
| Conduit | Bêta | Rouiller | RocksDB ou SQLite sont recommandés par sa documentation de déploiement. | Idéal pour les petites installations simples où de faibles coûts d'exploitation sont importants et où l'absence de certaines fonctionnalités est acceptable. |
Vérification des sources : consultez le répertoire officiel du serveur d’accueil Matrix , la documentation d’installation de Synapse , la documentation d’installation de Dendrite Docker et la documentation de déploiement générique de Conduit .
Le terme « léger » peut désigner au moins quatre choses différentes : l’utilisation de la mémoire en veille, la consommation du processeur lors de la synchronisation et de la fédération, la croissance du stockage ou le nombre de services auxiliaires qu’un administrateur doit exécuter. Ces mesures peuvent désigner des serveurs différents. Un serveur domestique mono-utilisateur qui se connecte à quelques salons privés se comporte très différemment d’un serveur qui se connecte à de grands salons publics, fait l’interface entre plusieurs réseaux, stocke des années de données multimédias ou participe activement à la fédération.
Pour cette raison, considérez les demandes de ressources comme dépendantes de la charge de travail, sauf si elles sont étayées par un test de performance reproductible correspondant à votre déploiement. L'action la plus utile consiste à définir au préalable votre charge de travail prévue : nombre d'utilisateurs locaux, taille maximale des salles auxquelles vous prévoyez de vous connecter, activation ou non de la fédération, besoin de ponts ou de services d'application, volume multimédia attendu et exigence de haute disponibilité.
Synapse demeure le choix de prédilection pour ceux qui recherchent une solution éprouvée. Matrix.org la qualifie de stable, tandis qu'Element assure la maintenance active du dépôt actuel. À l'heure où nous écrivons ces lignes, la dernière version stable disponible sur GitHub est Synapse 1.162.0 , publiée le 29 septembre 2026. Vous pouvez consulter les versions les plus récentes sur la page officielle des versions de Synapse .
Synapse est souvent décrit comme « lourd », mais cela doit être contextualisé. Le projet conserve délibérément des caches en mémoire pour améliorer les performances des requêtes. Sa FAQ d'administration indique clairement que son architecture peut être gourmande en RAM. Le guide d'installation recommande également de disposer d'au moins 1 Go de RAM libre pour rejoindre de grands salons publics. Il s'agit d'une estimation minimale utile, mais pas d'une exigence absolue pour chaque petit déploiement privé.
Synapse peut démarrer avec SQLite, mais la documentation d'installation officielle recommande l'utilisation de PostgreSQL dans la quasi-totalité des cas et déconseille l'utilisation de SQLite pour un serveur de production. Ce point est important car l'avantage d'une base de données simple à fichier unique disparaît en grande partie une fois Synapse correctement déployé pour une utilisation à long terme.
Synapse offre également la méthode de montée en charge horizontale la mieux documentée des trois. Les petites installations peuvent fonctionner comme un monolithe ; les installations plus importantes peuvent répartir la charge de travail sur plusieurs processus appelés workers. La documentation actuelle de Synapse relative aux workers explique que les déploiements de workers partagent PostgreSQL et peuvent répartir les charges de travail des clients et de la fédération entre les processus. Cela complexifie l'exploitation, mais offre une solution explicite lorsqu'un seul processus ne suffit plus.
Action : si l’utilisation des ressources est votre seul motif de refus de Synapse, testez-le avec PostgreSQL sur votre charge de travail réelle avant de conclure qu’il est trop important. La mémoire inactive à elle seule n’est pas un indicateur fiable des performances de la fédération ni du comportement des serveurs de grande capacité.
Dendrite a été créé en Go comme serveur d'hébergement Matrix de deuxième génération. L'ancien dépôt matrix-org a été archivé en novembre 2024, mais Dendrite n'a pas disparu pour autant. Son développement s'est poursuivi sur le dépôt Element Dendrite , qui reste actif. Le répertoire officiel des serveurs Matrix indique toujours que Dendrite est en version bêta.
Cette distinction est importante car les articles plus anciens peuvent laisser les lecteurs avec deux idées fausses opposées : soit que Dendrite est abandonné, soit qu’il a déjà remplacé Synapse. Aucune de ces affirmations n’est exacte en octobre 2026. Le projet est maintenu, mais sa version officielle reste bêta.
Le chemin d'installation Docker Compose documenté pour Dendrite utilise PostgreSQL comme dépendance et exécute le serveur d'accueil dans une configuration monolithique. Cela simplifie la compréhension de l'architecture de production de base : proxy inverse, Dendrite, PostgreSQL et configuration DNS/TLS Matrix classique.
L'implémentation Go de Dendrite séduit les administrateurs qui privilégient un binaire compilé et l'écosystème opérationnel de Go. Toutefois, le choix du langage à lui seul ne garantit pas une réduction de la consommation de ressources en conditions réelles. La résolution de l'état de fédération, la taille des salles, les médias, le comportement de la base de données et les modèles de synchronisation des clients restent prépondérants dans de nombreuses charges de travail Matrix.
La version 0.15.2 de Dendrite est présentée comme la plus récente dans la liste officielle des versions au moment de cet examen. La série 0.15 inclut des correctifs concernant la version 12 des salles et des problèmes de fiabilité, ce qui nous rappelle que les logiciels bêta peuvent évoluer rapidement. Consultez les versions officielles de Dendrite avant toute mise à jour ou déploiement.
Action : configurez Dendrite avec les clients et services applicatifs précis que vous prévoyez d’utiliser. Une liste de fonctionnalités est plus utile qu’une affirmation simpliste du type « plus léger que Synapse ».
Conduit est un serveur domestique Rust Matrix conçu pour être efficace, facile à installer et utilisable même sur de petits ordinateurs comme un Raspberry Pi. Le projet est actif sur son dépôt GitLab officiel et est indiqué comme étant en version bêta dans le répertoire de l'écosystème Matrix.
Dans ce comparatif, Conduit est manifestement le projet le plus axé sur la légèreté, mais sa documentation reste prudente quant à son état : la plupart des salles Matrix fonctionnent, mais toutes les fonctionnalités ne sont pas encore implémentées et des bogues peuvent survenir. La présentation officielle de Conduit liste les limitations actuelles ; les administrateurs devraient donc consulter cette page plutôt que de se fier à une ancienne matrice des fonctionnalités.
La documentation de déploiement générique de Conduit recommande actuellement RocksDB ou SQLite. Cela diffère sensiblement des recommandations de production de Synapse, centrées sur PostgreSQL, et de la documentation relative à l'installation de Dendrite avec Docker. Pour un serveur de petite taille, éviter un service PostgreSQL distinct permet de réduire le nombre d'éléments à maintenir, sauvegarder, surveiller et mettre à jour.
Conduit propose également une documentation native pour un déploiement systemd simplifié derrière un proxy inverse, ainsi que des images Docker. Sa documentation couvre la fédération, la délégation, TURN et les services d'application. De ce fait, il constitue une solution idéale pour un serveur familial, une petite équipe, un laboratoire ou un projet personnel où la simplicité prime sur une couverture exhaustive de l'écosystème.
Action : prenez connaissance des limitations actuelles dans l’introduction officielle de Conduit et testez vos plus grandes salles fédérées avant d’y transférer des utilisateurs réels. Le comportement de la fédération est le domaine où les hypothèses relatives aux « petits serveurs » sont le plus susceptibles d’être remises en question.
Si vous optez pour une application de production, les étiquettes de maturité constituent un premier filtre utile. Synapse est stable ; Dendrite et Conduit sont en version bêta. Bêta ne signifie pas inutilisable, et stable ne signifie pas sans ressources. Cela signifie simplement que le profil de risque est différent.
Un serveur léger dépourvu d'une fonctionnalité essentielle peut engendrer davantage de temps d'administration qu'un serveur plus performant au fonctionnement fiable. Citons par exemple le comportement des ponts, les services applicatifs, la gestion des comptes, les versions récentes des salles, les cas particuliers de fédération, les flux de travail de modération et les outils de mise à niveau. Il s'agit de questions de charge de travail et d'intégration, et non de langages de programmation.
Pour la plupart des administrateurs soucieux de minimiser les risques liés aux protocoles et à l'intégration, Synapse reste la solution recommandée par défaut . C'est la seule option stable parmi les trois proposées dans le répertoire Matrix officiel ; elle bénéficie d'une documentation complète, de recommandations pour la production avec PostgreSQL et d'une architecture de nœuds de calcul documentée pour les déploiements de grande envergure.
Dendrite représente une solution intermédiaire : une implémentation Go maintenue, dotée d’une architecture attrayante, mais encore officiellement en version bêta. Il est préférable de l’utiliser pour la valider avec vos clients et intégrations spécifiques plutôt que comme une version allégée et prête à l’emploi de Synapse.
Conduit est le candidat idéal lorsque « léger » signifie moins de services de support et une empreinte réduite sur une infrastructure auto-hébergée. Son modèle de déploiement RocksDB/SQLite et son implémentation en Rust sont attrayants pour les petits systèmes, mais son statut de version bêta et les fonctionnalités manquantes documentées rendent les tests de compatibilité indispensables.
Il n'existe pas de solution universellement reconnue pour la RAM, le processeur ou le disque, applicable à toutes les charges de travail Matrix. Le serveur le plus adapté à vos besoins fonctionnels est celui qui offre l'encombrement le plus réduit possible, tout en assurant une maintenance fiable.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
