Héberger Rocket.Chat sur votre propre VPS

Rocket.Chat va bien au-delà d'une simple messagerie d'équipe : il propose un module omnicanal natif (WhatsApp Business, e-mail, widgets de chat sur site web), des appels audio et vidéo, et une fédération via le protocole Matrix permettant de communiquer avec d'autres serveurs. Pour une agence ou une PME qui veut centraliser à la fois la communication interne et le support client, l'auto-hébergement sur VPS évite de multiplier les abonnements et garde l'ensemble des échanges — y compris les conversations clients — sur une infrastructure que vous maîtrisez. Rocket.Chat s'appuie sur MongoDB, ce qui le rend un peu plus gourmand que Mattermost, mais ouvre la voie à de riches intégrations et à une marketplace d'extensions.

Rocket.Chat et MongoDB sont relativement exigeants en mémoire. Pour une équipe jusqu'à 50 utilisateurs, prévoyez un VPS de 2 à 4 vCPU et au moins 4 Go de RAM ; visez 8 Go pour une instance active avec omnicanal et appels vidéo. MongoDB doit impérativement tourner en mode replica set (même à un seul nœud) car Rocket.Chat utilise l'oplog pour le temps réel. Comptez 30 à 50 Go de SSD. Il vous faut Docker et Compose, un sous-domaine chat.votredomaine.com avec enregistrement A, et un reverse proxy gérant les WebSockets.

Une fois connecté en tant qu'administrateur, rendez-vous dans Administration > Rooms pour créer vos salons (canal public, groupe privé, canal de discussion). Définissez une convention de nommage dès le départ : par exemple #equipe-dev, #support-clients, #annonces-generales. Assignez les rôles via Administration > Roles : les rôles Admin, Moderator, User et Guest sont préconfigurés ; vous pouvez en créer de personnalisés avec des granularités fines (lire mais pas écrire, voir mais pas inviter, modérer mais pas administrer). Pour les grandes équipes, utilisez les groupes LDAP pour affecter automatiquement les rôles à la connexion. Les webhooks entrants permettent d'envoyer des notifications depuis des outils tiers (GitLab, Grafana, votre CRM) directement dans un salon : Administration > Integrations > New Integration > Incoming WebHook. Rocket.Chat génère une URL unique ; l'appelant envoie un POST JSON avec au moins le champ text. Un alias et un avatar optionnels permettent d'identifier la source du message d'un coup d'oeil. Vous pouvez aussi définir des scripts pour filtrer ou transformer les messages entrants avant affichage, et configurer des déclencheurs sortants (Outgoing WebHook) pour notifier un service tiers à chaque message posté dans un salon donné.

Le module omnicanal (Omnichannel) de Rocket.Chat unifie les canaux externes dans une file d'attente de tickets gérée par vos agents. Activez-le dans Administration > Omnichannel > Activation. Pour le widget web, allez dans Omnichannel > Livechat > Installation : Rocket.Chat génère un snippet JavaScript à coller sur votre site ; vous pouvez personnaliser sa couleur, son titre et les champs pré-remplis. Pour l'e-mail, configurez une adresse IMAP dans Omnichannel > Email Inbox : chaque e-mail entrant crée automatiquement un ticket assigné à votre département de support. Pour WhatsApp Business API, vous avez besoin d'un fournisseur officiel (BSP) comme 360dialog ou Twilio : dans l'App Marketplace, installez l'app WhatsApp et renseignez vos identifiants BSP. Les conversations WhatsApp arrivent alors dans la même file que le chat web et l'e-mail, avec historique unifié. Les agents basculent d'un canal à l'autre sans changer d'outil — c'est l'avantage principal d'un omnicanal natif.

Replica set non initialisé : c'est l'erreur la plus courante. Sans rs.initiate(), l'oplog est indisponible, le chat en temps réel est cassé et des fonctions d'administration échouent silencieusement. Si vous utilisez l'image Bitnami, passez MONGODB_REPLICA_SET_MODE=primary et MONGODB_REPLICA_SET_KEY dès le premier boot. WebSocket coupé : si les messages arrivent en polling HTTP plutôt qu'en WebSocket, vérifiez que votre reverse proxy transmet bien les en-têtes Upgrade et Connection. Avec Nginx, ajoutez proxy_http_version 1.1 et les directives proxy_set_header correspondantes. Assistant accessible publiquement : si vous n'avez pas passé OVERWRITE_SETTING_Show_Setup_Wizard=completed, n'importe qui peut créer le compte admin. RAM épuisée par MongoDB : WiredTiger peut consommer jusqu'à 50 % de la RAM disponible par défaut. Sur un VPS contraint, limitez avec --wiredTigerCacheSizeGB 0.5. Erreur de certificat SSL en interne : vérifiez que ROOT_URL contient bien votre domaine en HTTPS sans slash final ; un mauvais ROOT_URL casse les redirections OAuth et les e-mails de notification.

Pour détecter rapidement une panne, mettez en place trois couches de surveillance. Couche conteneur : docker stats --no-stream donne CPU, RAM et I/O réseau en temps réel. Configurez une alerte si un conteneur s'arrête avec docker events --filter event=die dans un script systemd ou supervisord ; une simple boucle qui relance automatiquement les conteneurs en échec peut aussi suffire pour les cas non critiques. Couche applicative : Rocket.Chat expose des métriques Prometheus sur /metrics (activez-les dans Administration > Settings > General > Enable Prometheus). Couplez à Grafana pour des tableaux de bord sur les utilisateurs connectés, le nombre de messages par minute, la latence de réponse WebSocket et la taille de la base MongoDB. Programmez des alertes sur les seuils critiques : consommation RAM de MongoDB supérieure à 80 %, queue de messages en attente, ou certificat SSL expirant dans moins de 14 jours. Couche infrastructure : un check HTTP externe (UptimeRobot, Better Uptime ou votre propre Blackbox Exporter) sur https://chat.votredomaine.com/ vous alerte en cas d'indisponibilité globale, y compris coupure réseau ou extinction du VPS. Pensez aussi à vérifier régulièrement la taille des volumes Docker : la base MongoDB et les fichiers téléversés par les utilisateurs peuvent croître rapidement sur une instance très active.