Quelle alternative auto-hébergée à Slack choisir ?

Quelle alternative auto-hébergée à Slack devriez-vous utiliser

Les alternatives auto-hébergées à Slack qui valent le temps d’une petite équipe sont Mattermost, Rocket.Chat, Matrix avec Synapse et Zulip. Pour un outil d’équipe interne sur un seul serveur, utilisez Mattermost. Pour une communauté publique, utilisez Zulip. Utilisez Matrix avec Synapse lorsque vous devez communiquer avec des serveurs administrés par d’autres personnes, et uniquement dans ce cas, car la fédération est la seule fonctionnalité que les autres ne peuvent pas reproduire. C’est aussi celle qui modifie votre travail d’administrateur.

Les listes de fonctionnalités ne permettent pas de départager ces quatre solutions. Elles proposent toutes des canaux, des fils de discussion, une recherche, l’envoi de fichiers et des applications mobiles. Ce qui les distingue, c’est ce qu’elles vous demandent chaque mois : de la mémoire, une base de données à maintenir en fonctionnement, un service de push mobile que vous ne contrôlez peut-être pas, ainsi qu’une licence qui détermine si la fonctionnalité dont vous avez besoin est payante. La comparaison ci-dessous s’appuie sur ces critères, pour dix utilisateurs et pour cent utilisateurs.

Ce que sont réellement les quatre solutions

Mattermost est un serveur Go avec une base de données PostgreSQL. Un binaire, une base de données, un fichier de configuration. Son fonctionnement rappelle celui de Slack, avec les threads et les slash commands, et c’est le moins intéressant des quatre à exploiter, ce qui est un compliment.

Rocket.Chat est une application Node.js qui utilise MongoDB. C’est la solution la plus complète des quatre, notamment avec les appels audio et vidéo, ainsi qu’une boîte de réception omnicanale qui regroupe les conversations clients provenant des e-mails et des réseaux sociaux dans la même interface. Si cette boîte de réception motive votre recherche, comparez-la d’abord à un helpdesk Chatwoot dédié, car un serveur de chat utilisé pour le support ne répond pas au même besoin qu’un serveur de chat destiné au travail en équipe.

Matrix est un protocole, pas un produit. Synapse est le serveur de référence (Python, PostgreSQL) et Element est le client utilisé par la plupart des utilisateurs. C’est la seule option des quatre avec laquelle votre serveur peut communiquer avec des serveurs que vous n’administrez pas.

Zulip est un serveur Python (Django et Tornado) qui s’appuie sur PostgreSQL, RabbitMQ, memcached et Redis. Son propre script installe l’ensemble comme une seule unité. Son modèle repose sur des sujets dans des canaux : une conversation du mardi reste donc facile à retrouver le vendredi. La version 12.0 est sortie en avril 2026.

Quelle quantité de RAM et quelle base de données pour 10 et 100 utilisateurs

Tous les chiffres du tableau ci-dessous proviennent de la documentation des projets, consultée en août 2026. Aucun ne vient de mes propres mesures et aucun n'est inventé. La base est la même pour chaque ligne : la plus petite configuration publiée par le projet, en incluant la base de données lorsque le projet la dimensionne séparément.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

Les lignes ne décrivent pas toutes la même configuration, et c'est le premier point important. Les 1 Go de Synapse constituent un minimum pour le processus Synapse, avec une condition : la documentation demande au moins cette quantité de RAM libre si vous voulez rejoindre de grandes salles publiques. PostgreSQL n'est pas inclus dans ce chiffre. Les 2 Go de Mattermost couvrent l'ensemble de la machine, base de données comprise, pour 1 à 1 000 utilisateurs sur un seul vCPU. Zulip documente 2 Go et un CPU pour moins de 100 utilisateurs, avec 2 Go de swap, puis 4 Go et deux CPU à partir de 100 utilisateurs. Rocket.Chat publie ici le chiffre le plus élevé, 8 Go, car il dimensionne l'application à 4 GiB et MongoDB à 4 GiB. Ce niveau est prévu pour jusqu'à 500 utilisateurs simultanés.

À 10 utilisateurs, les 4 solutions fonctionnent sur un matériel auquel vous ne réfléchiriez pas à deux fois. À 100 utilisateurs, les besoins divergent : Mattermost reste dans son niveau de 2 Go, Zulip demande 4 Go et un deuxième CPU, et le plus petit niveau documenté de Rocket.Chat reste fixé à 8 Go, car l'appétit mémoire de MongoDB dépend de la machine, pas du nombre d'utilisateurs.

Le choix de la base de données détermine davantage vos futures mises à niveau que vos performances quotidiennes. Mattermost nécessite PostgreSQL 14 ou une version ultérieure et a déprécié la prise en charge de MySQL à partir de la v11. Une installation MySQL aujourd'hui implique donc une migration demain. Synapse fonctionne avec SQLite, mais sa documentation précise que SQLite n'est acceptable que pour les tests, car ses performances sont mauvaises dans les grandes salles. Rocket.Chat 8 nécessite MongoDB 8.0. La mise à niveau de la base de données et celle du service de chat constituent donc un seul projet, et non deux.

Ce qu’un VPS de 2 GB vous offre réellement

L’offre de 2 GB est la configuration d’entrée de gamme chez la plupart des fournisseurs. Elle convient réellement à deux de ces quatre solutions.

• Mattermost convient. C’est le seul dont la documentation indique précisément cette configuration, pour un maximum de 1 000 utilisateurs, avec PostgreSQL sur le même serveur. Dix personnes sur 2 GB disposent d’une marge confortable.
• Zulip convient, avec du swap. La documentation recommande du swap sous 5 GB et avertit que les machines disposant de peu de RAM rencontrent des erreurs de mémoire insuffisante pendant les mises à niveau. Dans ce cas, tools/webpack est l’étape qui échoue. C’est un problème réel que vous rencontrerez lors d’une mise à niveau, pas lors de l’installation.
• Synapse convient tant qu’il reste peu sollicité. Sa consommation au repos est faible. Le problème vient du pic de consommation. La section consacrée à la fédération ci-dessous en explique l’origine.
• Rocket.Chat est celui qu’il faut éviter avec 2 GB, à cause du moteur de stockage de MongoDB. WiredTiger dimensionne son cache interne selon la plus grande valeur entre 50 % de (RAM moins 1 GB) et 256 MB. Sur une machine de 2 GB, il réserve donc environ 512 MB avant même le démarrage de Node.js. Le résultat n’est pas un refus immédiat. L’installation réussit, le service fonctionne, puis il ralentit à mesure que l’historique augmente. Finalement, le kernel out of memory killer arrête le processus qui consomme le plus de mémoire à ce moment-là.

Vérifiez ce dont vous disposez réellement avant de choisir, car les fournisseurs comptabilisent la RAM différemment de free :

free -h
swapon --show

N’oubliez pas que le serveur de chat n’est pas le seul service exécuté sur la machine. La terminaison TLS (transport layer security), les sauvegardes et un runtime de conteneurs consomment également de la mémoire. Placez le serveur choisi derrière un reverse proxy que vous maîtrisez, Nginx, Caddy ou Traefik, et si vous le déployez avec des conteneurs, commencez par mettre en place correctement les bases de Docker Compose pour un VPS.

Les applications mobiles ont-elles besoin de votre propre serveur push

C’est le point que l’on découvre après le déploiement, et c’est souvent lui qui détermine la réponse.

Voici le mécanisme. Apple Push Notification service (APNs) et Firebase Cloud Messaging (FCM) n’acceptent une notification que de la part de la personne qui détient les identifiants de signature de l’application concernée. Votre serveur ne peut pas envoyer de notification à une application que vous n’avez pas créée. Un serveur de chat auto-hébergé qui utilise la build App Store de l’éditeur doit donc transmettre ses notifications à la gateway de l’éditeur, qui en fixe les conditions.

• Mattermost. La solution gratuite est le Test Push Notification Service (TPNS) à https://push-test.mattermost.com. La documentation précise qu’il n’est pas recommandé pour la production et qu’il ne fournit aucun service level agreement (SLA). Il fonctionne uniquement avec les builds de l’App Store et du Play Store. Le Hosted Push Notification Service (HPNS) est adapté à la production et nécessite un abonnement payant. La troisième solution consiste à compiler vous-même le push proxy, ce qui nécessite ensuite vos propres builds d’application avec vos propres identifiants APNs et FCM.
• Rocket.Chat. L’envoi de notifications push nécessite d’enregistrer le workspace auprès de Rocket.Chat Cloud. Les workspaces communautaires sont limités à 10,000 notifications push par mois. Cela représente environ 330 notifications par jour pour l’ensemble du workspace. Une fois le quota épuisé, les notifications n’arrivent plus jusqu’à la réinitialisation mensuelle. Pour les utilisateurs, l’application semble alors ne plus fonctionner.
• Matrix avec Element. Synapse envoie les notifications à une gateway push. Les applications Element officielles utilisent la gateway gérée par matrix.org à https://matrix.org/_matrix/push/v1/notify. La charge utile contient les identifiants de l’événement et de la room, mais pas le texte du message. L’application récupère le contenu auprès de votre serveur. La gateway voit donc des métadonnées, et non les conversations. Vous pouvez gérer votre propre gateway Sygnal. Cela implique de créer et de distribuer vos propres applications. Sur Android, une solution intermédiaire consiste à utiliser UnifiedPush avec un serveur ntfy que vous hébergez.
• Zulip. Le forfait gratuit inclut le service de notifications push mobiles pour 10 utilisateurs maximum. Au-delà de 10 utilisateurs, vous avez besoin d’un forfait. Le forfait Community gratuit couvre de nombreuses organisations non commerciales. Zulip 12.0, en avril 2026, a ajouté le chiffrement de bout en bout des charges utiles push.

Avec 10 utilisateurs, toutes ces solutions fournissent des notifications fonctionnelles sans coût. À 100 utilisateurs, la situation change : Zulip nécessite un forfait, Mattermost continue de fonctionner avec le service de test, sans SLA ni support, le plafond mensuel de Rocket.Chat devient la contrainte, et Matrix n’est pas affecté, car sa gateway est gratuite.

Lesquels proposent l’authentification unique sans frais

C’est avec l’authentification unique (SSO) que le modèle économique open core apparaît le plus clairement.

• Zulip inclut SAML (Security Assertion Markup Language) et LDAP (Lightweight Directory Access Protocol) dans le serveur auto-hébergé, sans frais. Il n’existe pas de niveau séparé à acheter.
• Synapse prend en charge OpenID Connect (OIDC), SAML et CAS dans son propre fichier de configuration, gratuitement. Les nouvelles installations utilisent de plus en plus le Matrix Authentication Service, un service distinct avec une migration à sens unique depuis l’authentification classique de Synapse. Planifiez donc cette migration au lieu de la découvrir plus tard.
• L’édition communautaire de Rocket.Chat prend en charge les connexions LDAP et SAML de base. La synchronisation des attributs utilisateur étendus, le mappage des groupes et des équipes ainsi que la synchronisation en arrière-plan nécessitent une licence entreprise.
• L’édition Team gratuite de Mattermost fournit GitLab OAuth, et rien d’autre. SAML, AD/LDAP et OpenID Connect sont des fonctionnalités payantes.

Si vous prévoyez d’exécuter plusieurs services derrière une même connexion, placez un fournisseur d’identité Authentik auto-hébergé devant eux et vérifiez lesquels des quatre peuvent réellement communiquer avec lui avec la licence que vous détenez.

Le coût réel de la fédération

La fédération est la raison d’être de Matrix. Votre utilisateur rejoint un salon hébergé sur le serveur d’une autre personne et échange avec des personnes dont les comptes y sont hébergés, comme les serveurs de messagerie échangent des e-mails. Aucune autre option présentée ici ne le permet. Si vous en avez besoin, aucune autre solution de cette page ne peut la remplacer.

C’est aussi la raison pour laquelle Synapse correspond à une charge de travail différente. Lorsqu’un utilisateur rejoint un salon fédéré, votre serveur conserve une copie de l’état et des événements de ce salon. Il met également en cache les médias publiés par les utilisateurs d’autres serveurs : avatars, images et fichiers. L’espace disque utilisé dépend alors de salons que vous n’avez pas créés et de personnes qui n’ont pas de compte sur votre serveur. C’est pourquoi les installations Synapse développent un media store bien plus volumineux que le volume de messages envoyés par leurs propres utilisateurs. C’est aussi pourquoi la documentation associe précisément la mémoire à l’opération qui consiste à rejoindre un grand salon public.

Définissez la politique de rétention dès le premier jour, et non le jour où le disque est plein :

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse a ajouté media_retention dans la version 1.61, avec des durées de conservation distinctes pour les médias locaux et distants. Les médias distants sont un cache. Si un utilisateur demande de nouveau un fichier purgé, Synapse le demande à nouveau au serveur d’origine. Les médias locaux ne sont pas un cache. Une valeur local_media_lifetime courte supprime définitivement les fichiers envoyés par vos propres utilisateurs.

En résumé : si vos utilisateurs discutent uniquement entre eux, la fédération ne vous apporte rien. Elle consomme de l’espace disque et de la bande passante, et rend les mises à niveau plus complexes. Désactivez-la ou choisissez un autre serveur.

Comment se déroulent les mises à niveau

Zulip est le plus simple. Un script suffit, et l’interruption documentée reste inférieure à 30 secondes, sauf si une migration importante de la base de données est nécessaire. L’installation et la mise à niveau se présentent ainsi, à exécuter par vous sur le serveur :

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

Exécutez l’installateur en tant que root. L’option --push-notifications enregistre le serveur auprès du service de notifications push mobile pendant l’installation. Elle vous demande alors d’accepter les conditions d’utilisation. Lisez-les avant de commencer.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

Les mises à niveau suivantes utilisent le même tarball et une seule commande :

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost est prévisible. Remplacez le binaire, redémarrez le service, puis les migrations s’exécutent au démarrage. Depuis les releases d’août 2025, la branche Extended Support Release (ESR) est publiée tous les 9 mois et bénéficie de 12 mois de support. Les mises à niveau d’une ESR vers la suivante constituent le parcours testé. Passer plusieurs ESR d’un coup est pris en charge, mais ce parcours n’est pas testé. En pratique, c’est donc vous qui le testez.

Rocket.Chat couple trois mises à niveau. En août 2026, la branche 8.x est la branche actuelle. La version 8.7.0 est sortie le 6 août 2026. Elle nécessite MongoDB 8.0 et une version correspondante de Node.js. Sauter une version majeure est le meilleur moyen de se retrouver avec une base de données que l’application refuse d’ouvrir. Le guide d’installation de Rocket.Chat avec Docker Compose verrouille ces versions ensemble pour vous. C’est le principal argument en faveur des conteneurs dans ce cas.

Synapse nécessite de lire la documentation. Chaque release comporte des notes de mise à niveau. Vous devez lire les notes de chaque version traversée, et pas seulement celles de la version cible. Après la mise à niveau, Synapse exécute des mises à jour en arrière-plan sur la base de données. Sur un petit serveur, elles peuvent ralentir la machine pendant plusieurs heures. C’est un comportement attendu, pas une défaillance.

Conditions de licence, en termes simples

Mattermost distribue ses builds compilés de Team Edition sous licence MIT, tandis que le code source est proposé sous AGPLv3 ou sous une licence commerciale. Certaines parties du dépôt sont soumises à la Mattermost Source Available License, qui exige une licence payante pour les exécuter en production. Rocket.Chat est sous licence MIT, à l’exception des répertoires ee/, qui disposent de leur propre licence entreprise. Synapse est passé d’Apache 2.0 à AGPLv3 avec la version 1.99.0. Les contributeurs signent un CLA qui permet à Element de commercialiser des exceptions à cette licence. Zulip est sous licence Apache 2.0 et ne contient pas de répertoire entreprise. C’est pourquoi sa prise en charge du SSO ne comporte pas d’astérisque.

En pratique, l’AGPL ne vous concerne que si vous prévoyez de modifier le serveur et de le proposer à d’autres utilisateurs sous forme de service. Pour une petite équipe, le point bien plus important est le modèle open core : quelles fonctionnalités sont absentes de la build gratuite. Zulip en a le moins, Mattermost en a le plus.

Lequel choisir

Un outil pour une équipe interne. Mattermost. C’est celui dont l’empreinte documentée est la plus faible, dont les mises à niveau sont les plus prévisibles et dont l’interface familière ne nécessite aucune explication. Prévoyez une offre payante dès que le SSO devient nécessaire, car cette situation finit par se présenter dans la plupart des équipes.

Un serveur communautaire. Zulip. Les sujets permettent de garder lisible un canal public très actif, même plusieurs mois plus tard. SAML et LDAP sont gratuits, et la mise à niveau se fait avec une seule commande. Si votre communauté utilise davantage des publications et des réponses que du chat en direct, comparez d’abord les logiciels de forum auto-hébergés, car un forum est mieux indexé par les moteurs de recherche et ne nécessite aucune infrastructure push. Choisissez plutôt Rocket.Chat si vous avez besoin des fonctions de voix, de vidéo et d’omnicanal, et si vous pouvez lui attribuer les 8 GB demandés dans sa propre documentation.

Un réseau qui doit interagir avec d’autres systèmes. Matrix avec Synapse et Element. Tenez compte de l’augmentation du volume des médias, configurez la rétention dès le premier jour, utilisez PostgreSQL et prévoyez plus d’espace disque que vous ne le pensez nécessaire. Vous tirerez alors une réelle valeur des échanges avec des serveurs que vous ne contrôlez pas. Choisir Synapse pour une équipe qui ne fédère jamais son serveur revient à supporter ce coût sans en tirer aucun bénéfice.

FAQ

Quelle est la meilleure alternative auto-hébergée à Slack pour une petite équipe ?

Mattermost, dans la plupart des équipes internes. Sa documentation couvre de 1 à 1,000 utilisateurs sur 1 vCPU et 2 GB de RAM, avec PostgreSQL sur la même machine. Il convient donc au plan VPS d’entrée de gamme proposé par la plupart des fournisseurs. Le point limitant est le single sign-on : l’édition Team gratuite prend uniquement en charge OAuth GitLab, tandis que SAML, AD/LDAP et OpenID Connect nécessitent tous une offre payante. Si le SSO gratuit est plus important que l’interface proche de Slack, utilisez plutôt Zulip.

Puis-je exécuter un serveur de chat auto-hébergé sur un VPS de 2 GB ?

Oui avec Mattermost, et oui avec Zulip si vous ajoutez du swap, ce que recommande la documentation de Zulip en dessous de 5 GB. Rocket.Chat vous décevra en revanche, car le moteur WiredTiger de MongoDB réserve pour son cache la plus grande valeur entre 50 % de (RAM moins 1 GB) et 256 MB. Environ 512 MB d’une machine de 2 GB sont donc consommés avant même le démarrage de l’application. L’installation réussira, puis les performances se dégraderont à mesure que l’historique augmentera, jusqu’à un kill pour manque de mémoire. Le plus petit niveau publié par Rocket.Chat prévoit 4 GiB pour l’application et 4 GiB pour MongoDB.

Les serveurs de chat auto-hébergés ont-ils besoin de leur propre serveur de notifications push mobiles ?

En général, non. Les APNs d’Apple et le FCM de Google acceptent uniquement les notifications provenant de l’éditeur qui a signé l’application. L’application de l’éditeur utilise donc sa propre gateway. Les conditions varient. Mattermost propose un service de test gratuit sans SLA et un service hébergé payant. Rocket.Chat limite les workspaces communautaires à 10,000 notifications push par mois. La distribution s’arrête ensuite jusqu’à la réinitialisation mensuelle du quota. Zulip inclut gratuitement les notifications push jusqu’à 10 utilisateurs et exige une offre supérieure au-delà. Les homeservers Matrix envoient les notifications push via la gateway utilisée par les applications Element, sans frais. Vous n’avez besoin de votre propre gateway que si vous distribuez également vos propres builds de l’application.

Dois-je auto-héberger Matrix et Synapse pour une équipe qui ne communique jamais avec d’autres serveurs ?

Non. La fédération est la raison d’être de Synapse et elle rend également son exploitation plus lourde. Rejoindre des rooms sur d’autres serveurs récupère leur état et met leurs médias en cache sur votre disque. Le stockage augmente donc pour des raisons sans rapport avec vos propres utilisateurs. Configurez media_retention avec un remote_media_lifetime court avant que cela ne se produise. Une équipe qui communique uniquement en interne supporte le coût opérationnel sans en tirer de bénéfice. Mattermost ou Zulip fournira le même service avec moins de matériel.

Quelle alternative auto-hébergée à Slack propose un single sign-on gratuit ?

Zulip et Synapse. Zulip inclut SAML et LDAP gratuitement dans son serveur auto-hébergé. Synapse prend en charge OpenID Connect, SAML et CAS dans sa configuration, les nouvelles installations utilisant de plus en plus le Matrix Authentication Service séparé. L’édition communautaire de Rocket.Chat prend en charge l’authentification LDAP et SAML de base, mais réserve la synchronisation des attributs, la correspondance des groupes et la synchronisation en arrière-plan à une licence Enterprise. L’édition Team gratuite de Mattermost prend uniquement en charge OAuth GitLab.