Héberger Mattermost : votre messagerie d'équipe souveraine (alternative à Slack)

Maîtriser sa communication interne, c’est aussi maîtriser l’emplacement des messages, des fichiers et des données d’identité de ses collaborateurs. Avec une plateforme SaaS classique, ces informations dépendent d’un fournisseur tiers, de ses conditions contractuelles et de ses choix d’hébergement.

Mattermost est une messagerie collaborative open source comparable à Slack ou Microsoft Teams. Auto-hébergée sur un serveur situé en France, elle permet à une PME ou à une équipe technique de conserver le contrôle de ses échanges et de mieux répondre à ses exigences de souveraineté et de conformité au RGPD.

Un hébergement français comme TalCloud complète cette démarche avec des serveurs en France, du stockage NVMe, une protection Anti-DDoS Netrix et un support humain. Les offres VPS TalCloud démarrent à 4,99 € par mois.

Que permet de faire Mattermost ?

Mattermost organise les utilisateurs en équipes. Chaque équipe peut disposer de plusieurs canaux publics ou privés, par exemple pour un projet, un service interne ou un client. Les canaux publics facilitent le partage d’informations, tandis que les canaux privés limitent l’accès aux personnes autorisées.

Les collaborateurs peuvent également échanger par messages directs, individuellement ou en petit groupe. Les fils de discussion évitent de mélanger plusieurs sujets dans un même canal et rendent les conversations plus faciles à suivre.

Mattermost prend notamment en charge :

• les équipes et les canaux publics ou privés ;
• les messages directs et les discussions de groupe ;
• les fils de discussion et les mentions ;
• le partage de documents, d’images et d’autres fichiers ;
• la recherche dans l’historique des messages ;
• les webhooks entrants et sortants ;
• les comptes bots et les intégrations applicatives ;
• les clients pour navigateur, ordinateur et mobile.

Cette couverture fonctionnelle en fait une alternative crédible à Slack ou Teams, particulièrement pour les organisations qui veulent intégrer leur messagerie à leurs outils de développement, de supervision ou de gestion interne.

Prérequis pour auto-héberger Mattermost

Mattermost doit être installé sur un serveur disposant d’une marge suffisante en mémoire vive. La consommation dépend du nombre d’utilisateurs, de l’activité, des intégrations et du volume de fichiers partagés. Il faut éviter de dimensionner le serveur uniquement pour la charge initiale.

Le déploiement présenté ici nécessite :

• un VPS Linux avec Docker et le module Docker Compose (voir installer Docker sur un VPS) ;
• un nom de domaine ou un sous-domaine, comme chat.example.fr ;
• un enregistrement DNS pointant vers l’adresse IP du serveur ;
• une base PostgreSQL ;
• un reverse proxy pour publier le service en HTTPS ;
• un espace de stockage persistant pour les messages, les fichiers et la configuration.

PostgreSQL sera exécuté dans un conteneur séparé. Son port ne doit pas être publié sur Internet. Mattermost communiquera avec lui à travers le réseau interne créé par Docker Compose.

Déployer Mattermost avec Docker Compose

Créez un répertoire de travail, puis placez-y un fichier .env contenant les paramètres sensibles et la version de Mattermost à utiliser :

POSTGRES_DB=mattermost
POSTGRES_USER=mmuser
POSTGRES_PASSWORD=remplacez-par-un-mot-de-passe-long
MATTERMOST_VERSION=10.5.3
MATTERMOST_SITEURL=https://chat.example.fr

La version indiquée est un exemple. Sélectionnez une version stable compatible avec votre environnement, puis conservez-la explicitement dans le fichier. Évitez le tag latest, qui peut provoquer une mise à niveau non planifiée lors d’un redéploiement.

Créez ensuite le fichier compose.yaml :

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - mattermost

  mattermost:
    image: mattermost/mattermost-team-edition:${MATTERMOST_VERSION}
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable&connect_timeout=10
      MM_SERVICESETTINGS_SITEURL: ${MATTERMOST_SITEURL}
    volumes:
      - mattermost-config:/mattermost/config
      - mattermost-data:/mattermost/data
      - mattermost-logs:/mattermost/logs
      - mattermost-plugins:/mattermost/plugins
      - mattermost-client-plugins:/mattermost/client/plugins
    ports:
      - "127.0.0.1:8065:8065"
    networks:
      - mattermost

volumes:
  postgres-data:
  mattermost-config:
  mattermost-data:
  mattermost-logs:
  mattermost-plugins:
  mattermost-client-plugins:

networks:
  mattermost:

La variable MM_SQLSETTINGS_DATASOURCE désigne le service postgres, et non localhost. Dans un réseau Docker, chaque conteneur possède sa propre interface locale.

La variable MM_SERVICESETTINGS_SITEURL doit contenir l’adresse publique définitive en HTTPS. Elle intervient dans les liens générés, les intégrations et le fonctionnement des clients.

Démarrez les services :

docker compose up -d
docker compose ps
docker compose logs -f mattermost

Mattermost écoute uniquement sur 127.0.0.1:8065. Il n’est donc pas directement exposé sur l’interface publique du serveur. Le reverse proxy se chargera de recevoir les connexions HTTPS.

Effectuer le premier accès

Une fois le service démarré et le reverse proxy configuré, ouvrez l’adresse publique de Mattermost dans un navigateur. Le premier utilisateur inscrit devient généralement administrateur système. Créez ce compte avec une adresse professionnelle protégée et un mot de passe unique.

Vous pourrez ensuite créer une première équipe, définir son nom et inviter les collaborateurs. Vérifiez rapidement les rôles attribués, les droits de création de canaux et les possibilités d’invitation. Un espace de discussion interne ne doit pas dépendre durablement de paramètres ouverts par défaut.

Conservez un compte administrateur dédié aux opérations sensibles. L’utilisation quotidienne d’un compte standard limite les conséquences d’une session compromise.

Configurer le domaine, les emails et les inscriptions

L’URL du site doit être strictement identique à l’adresse publique utilisée par les collaborateurs. Si le service est accessible sur https://chat.example.fr, cette même valeur doit être enregistrée dans MM_SERVICESETTINGS_SITEURL et dans la console système.

Configurez également un serveur SMTP. Mattermost l’utilise pour envoyer les invitations, les notifications, les confirmations et les procédures de récupération de mot de passe. Testez l’envoi depuis la console d’administration avant d’ouvrir le service aux utilisateurs.

Adaptez ensuite la politique d’inscription. Selon le contexte, vous pouvez limiter les comptes à certains domaines email, désactiver l’inscription publique ou imposer une création par invitation. Pour une messagerie interne, l’inscription libre est rarement souhaitable.

Connecter Mattermost à vos outils

Les webhooks entrants permettent à une application de publier un message dans un canal. Ils conviennent, par exemple, aux notifications de déploiement, aux alertes de supervision ou aux résultats d’une chaîne CI.

Les webhooks sortants transmettent certains événements Mattermost vers un service externe. Des bots peuvent aller plus loin en répondant à des commandes, en automatisant des tâches ou en relayant des informations depuis un outil métier.

Traitez les URL de webhook et les jetons de bots comme des secrets. Ne les placez pas dans un dépôt public et limitez leurs permissions aux canaux nécessaires. Une intégration compromise ne doit pas disposer d’un accès plus large que sa fonction.

Utiliser Mattermost sur ordinateur et mobile

Les collaborateurs peuvent accéder à Mattermost depuis un navigateur ou utiliser les applications dédiées pour ordinateur et mobile. Les différents clients se connectent tous à la même instance et retrouvent les équipes, les canaux et l’historique autorisé.

L’application mobile a besoin d’une URL publique valide et accessible en HTTPS. Une adresse locale comme http://127.0.0.1:8065 ne fonctionnera pas depuis un téléphone. Le certificat TLS doit être reconnu et la valeur de SITEURL doit correspondre au domaine présenté à l’utilisateur.

Publier Mattermost en HTTPS

Placez Mattermost derrière un reverse proxy tel que Nginx, Caddy ou Traefik. Le proxy doit terminer la connexion TLS, transmettre les requêtes vers 127.0.0.1:8065 et conserver les en-têtes décrivant le protocole et l’hôte d’origine.

Mattermost utilise également WebSocket pour les événements en temps réel. Le reverse proxy doit transmettre correctement les en-têtes de mise à niveau de connexion. Une mauvaise configuration peut produire une interface accessible, mais des messages ou notifications qui n’apparaissent qu’après actualisation de la page.

Après la mise en place, vérifiez que le domaine redirige systématiquement HTTP vers HTTPS, que le certificat est valide et que MM_SERVICESETTINGS_SITEURL correspond exactement à l’URL publique.

Sécuriser l’instance

Les conversations internes peuvent contenir des informations commerciales, techniques ou personnelles sensibles. Activez HTTPS sans exception et n’exposez ni PostgreSQL ni le port 8065 sur l’adresse publique, à l’aide du pare-feu.

Renforcez aussi les contrôles applicatifs :

• activez l’authentification multifacteur lorsque l’édition et la configuration utilisées le permettent ;
• révisez les permissions des équipes, canaux et comptes invités ;
• limitez la création d’intégrations aux personnes autorisées ;
• supprimez rapidement les comptes des collaborateurs sortants ;
• protégez les secrets présents dans .env ;
• surveillez les journaux et les tentatives de connexion ;
• appliquez régulièrement les correctifs du système, de Docker et de Mattermost.

La protection Anti-DDoS Netrix de TalCloud contribue à la disponibilité du serveur, mais elle ne remplace pas les mesures de sécurité applicatives, les mots de passe robustes ou la gestion rigoureuse des accès.

Mettre Mattermost à jour

Avant une mise à jour, consultez les notes correspondant aux versions intermédiaires et vérifiez la compatibilité de PostgreSQL. Sauvegardez la base et les volumes, puis modifiez MATTERMOST_VERSION avec la version choisie.

Appliquez ensuite la mise à jour :

docker compose pull mattermost
docker compose up -d
docker compose logs -f mattermost

Contrôlez la connexion, l’envoi de messages, le partage de fichiers, les WebSocket et les intégrations. Garder une version explicite de l’image facilite les tests et évite les changements surprises.

Sauvegarder les messages et les fichiers

Une sauvegarde Mattermost complète comporte au minimum la base PostgreSQL et le volume mattermost-data. PostgreSQL contient les comptes, les canaux, les messages et la configuration enregistrée en base. Le volume de données contient notamment les fichiers partagés.

Vous pouvez produire une sauvegarde logique de PostgreSQL avec :

docker compose exec -T postgres pg_dump \
  -U mmuser \
  -d mattermost \
  -Fc > mattermost-postgres.dump

Sauvegardez également les volumes persistants, en particulier les données, la configuration et les extensions. Stockez les copies sur un emplacement distinct du VPS, chiffrez-les et définissez une durée de conservation adaptée. Notre guide sur les sauvegardes chiffrées avec restic détaille l’automatisation.

Une sauvegarde non testée reste incertaine. Organisez périodiquement une restauration sur une instance isolée afin de vérifier le fichier PostgreSQL, les pièces jointes, les permissions et le redémarrage de Mattermost.

Avec un déploiement Docker Compose maîtrisé, un domaine HTTPS et une politique de sauvegarde testée, Mattermost fournit aux équipes une messagerie moderne tout en conservant leurs données sous contrôle. Hébergée sur une infrastructure française, l’instance s’inscrit dans une stratégie de souveraineté numérique cohérente et adaptée aux besoins des PME.