abonnel-www/f90417e1-5d05-49b1-8e36-33c6963286a6/index.md

De l'ejabberd à Matrix : pourquoi et comment migrer mon homelab de messagerie

Mise à jour de l'article original « ejabberd - service de messagerie Jabber XMPP » publié en novembre 2021.

Ce que faisait l'article original

https://www.abonnel.fr/post/ejabberd-service-de-messagerie-jabber-xmpp

L'article publié en 2021 documentait l'installation d'un serveur de messagerie XMPP avec ejabberd sur Debian 10. L'objectif était de monter un service Jabber complet pour mon homelab, avec :

• Un serveur ejabberd installé via les paquets Debian, complété par une mise à jour vers la version 21.07 issue de ProcessOne
• Une base MariaDB comme backend de stockage des comptes et messages
• Un certificat TLS Let's Encrypt mutualisé avec un serveur Apache sur le même domaine
• Une configuration multi-hôtes virtuels (im.domain.tld, xmpp.domain2.tld) avec authentification différenciée (interne pour l'un, SQL pour l'autre)
• Un ensemble de modules de base (mod_roster, mod_muc pour les salons, mod_ping, etc.)
• Le module mod_stun_disco pour annoncer aux clients XMPP des services STUN/TURN, en vue d'appels audio/vidéo

L'objectif sous-jacent était classique : disposer d'une messagerie auto-hébergée, ouverte, fédérée, indépendante des plateformes propriétaires. Sur le papier, XMPP cochait toutes les cases — protocole standardisé (RFC 6120), fédération native, écosystème de clients libres, chiffrement OMEMO disponible.

Pourquoi cet article n'est plus le bon point de départ

Quatre ans plus tard, en relisant ce tutoriel avec un regard critique, plusieurs limites apparaissent — certaines dues à l'article lui-même, d'autres au contexte plus large.

Les limites du tutoriel original

À la relecture, le tutoriel contenait plusieurs problèmes techniques : des erreurs de syntaxe YAML (listes mal formatées), des URLs cassées, un chemin de certificat tronqué, et un exemple MariaDB avec le mot de passe password en clair sans avertissement suffisamment appuyé. Plus important : la création du premier compte administrateur manquait, ainsi que la configuration du pare-feu et la création réelle d'un serveur TURN (le module mod_stun_disco se contente d'annoncer des services, il ne les fournit pas).

Ces points sont corrigibles, et ils l'ont été dans une réécriture intermédiaire. Mais le problème de fond n'est pas là.

Le vrai problème : XMPP ne répondait pas à mon besoin réel

L'objectif initial était une « messagerie ». En pratique, ce que je voulais — et ce que veulent la plupart des gens qui montent un homelab de communication aujourd'hui — c'est :

1. Échanger des messages texte de manière fiable
2. Passer des appels audio et vidéo de qualité
3. Faire de la visio à plusieurs
4. Avoir une expérience cohérente sur tous mes appareils, y compris iOS
5. Idéalement, intégrer l'authentification à mon IdP existant (Keycloak sur idp.a5l.fr)

XMPP fait correctement le point 1 et partiellement le 2. Sur les autres points, l'écosystème montre ses limites :

• iOS : très peu de clients XMPP de qualité, push notifications difficiles à mettre en place sans gateway tierce
• Visio de groupe : possible techniquement (Jingle + MUC), mais l'expérience est très en deçà de ce qu'on attend en 2026
• SSO OIDC : seuls 2-3 clients XMPP supportent SASL OAUTHBEARER ; sur iOS, c'est quasi-inexistant. Pour un vrai SSO avec Keycloak, on est obligé de retomber sur du LDAP, ce qui n'est plus du SSO mais de la délégation d'annuaire avec ressaisie du mot de passe
• Multi-appareils : l'historique synchronisé reste imparfait, OMEMO complique la donne

Ces frictions étaient déjà présentes en 2021, mais elles paraissaient acceptables. En 2026, des alternatives matures les ont supprimées.

Le détour par Linphone / Flexisip

Une piste explorée a été de remplacer XMPP par du SIP avec Flexisip et Linphone (l'écosystème français de Belledonne Communications, basé à Grenoble). C'est techniquement excellent pour les appels audio/vidéo — c'est leur métier depuis vingt ans — et Linphone offre une expérience iOS très propre avec push natif. Mais SIP est faible sur la messagerie moderne (pas de threads, partage de fichiers basique, fédération inexistante en pratique) et l'écosystème de clients est quasi-monoculture autour de Linphone lui-même.

La cible : Matrix avec Synapse, MAS et Element Call

Après analyse, Matrix est la pile qui répond le mieux à l'ensemble des besoins pour un homelab moderne.

Pourquoi Matrix

• Messagerie excellente avec E2EE par défaut, historique synchronisé multi-appareils, threads, réactions, édition de messages
• Appels audio/vidéo de qualité via Element Call (basé sur MatrixRTC + LiveKit), qui rivalise avec Zoom ou Meet
• Clients de qualité homogène sur toutes les plateformes : Element Web, Element Desktop, Element X iOS et Android — avec push natif fonctionnel
• SSO OIDC natif et bien documenté via MAS (Matrix Authentication Service), qui s'intègre proprement à Keycloak
• Fédération mature et écosystème grand public bien plus actif que XMPP en 2026
• Documentation et outillage self-hosting excellents, notamment le playbook matrix-docker-ansible-deploy de spantaleev qui automatise tout

Les contreparties à connaître

Honnêtement :

• Synapse consomme plus de RAM qu'ejabberd (compter 1-2 Go pour quelques utilisateurs)
• La base PostgreSQL grossit avec l'historique fédéré, surtout si on rejoint de gros salons publics
• La pile complète comporte plus de briques (Synapse + PostgreSQL + MAS + LiveKit SFU + lk-jwt-service + coturn) qu'un simple ejabberd
• Element X impose MAS pour l'authentification — l'OIDC direct sur Synapse ne suffit plus

Ces contreparties sont gérables. Sur un homelab modeste (4-8 Go RAM, 50 Go SSD), la pile tourne sans difficulté.

Architecture cible sur a5l.fr

a5l.fr                → délégation .well-known
matrix.a5l.fr         → Synapse (homeserver)
auth.a5l.fr           → MAS (délègue à Keycloak)
chat.a5l.fr           → Element Web
mrtc.a5l.fr           → MatrixRTC backend (LiveKit + lk-jwt-service)
turn.a5l.fr           → coturn (TURN dédié)
idp.a5l.fr            → Keycloak existant

Le flux d'authentification devient :

Client Matrix → MAS (auth.a5l.fr) → Keycloak (idp.a5l.fr)
                ↓
         Synapse (matrix.a5l.fr)

L'utilisateur s'authentifie une fois sur Keycloak — avec MFA, WebAuthn ou ce qui est configuré — et peut se connecter sur tous les clients Matrix de tous ses appareils sans ressaisir de mot de passe. C'est un vrai SSO, pas une délégation LDAP déguisée.

Faut-il jeter l'article ejabberd à la poubelle ?

Non. Plusieurs raisons de le conserver, éventuellement dans une rubrique « archives » :

• XMPP reste un protocole sérieux pour des cas d'usage spécifiques : messagerie texte pure, intégration IoT (MQTT-XMPP), bots, communautés déjà établies sur ce protocole
• Le tutoriel garde sa valeur pédagogique pour comprendre comment fonctionne un serveur de messagerie fédéré
• Si un jour je voulais monter un service de messagerie pour une association ou un usage pro où la complexité Matrix n'est pas justifiée, ejabberd ou Prosody resteraient pertinents — Prosody en premier choix d'ailleurs, beaucoup plus léger qu'ejabberd pour les petits déploiements

Mais pour le besoin réel d'un homelab de communication en 2026 — messagerie + appels + visio + tous appareils + SSO — Matrix est la bonne réponse.

Suite de la documentation

Les prochains articles documenteront le déploiement effectif :

1. Installation de Synapse et PostgreSQL avec Docker Compose
2. Configuration de MAS et intégration Keycloak
3. Déploiement d'Element Call (LiveKit SFU + lk-jwt-service)
4. Configuration de coturn pour les NAT difficiles derrière FAI
5. Sauvegarde et supervision
6. Migration éventuelle des données ejabberd vers Matrix (via les bridges mautrix-*)

L'option simplifiée — utiliser le playbook Ansible matrix-docker-ansible-deploy — sera également documentée en parallèle, car elle réduit drastiquement le travail manuel tout en restant complètement self-hosted.

---

Article rédigé en mai 2026. Liens utiles : documentation Matrix, Synapse, matrix-authentication-service, Element Call, matrix-docker-ansible-deploy.