Jabber, renommé XMPP, est un protocole de messagerie ouvert qui fait transiter des flux XML entre serveurs fédérés. Une PME peut l'auto-héberger ou passer par un prestataire, sans dépendre d'un éditeur unique. Le standard est documenté par des RFC publiques, ce qui permet à plusieurs logiciels de communiquer entre eux.
Qu'est-ce que le protocole XMPP et comment fonctionne-t-il ?
XMPP signifie Extensible Messaging and Presence Protocol. Le principe est simple : deux serveurs échangent des flux XML sur une connexion TCP, généralement sécurisée par TLS. Chaque utilisateur possède une adresse appelée JID, de la forme utilisateur@domaine, proche d'une adresse électronique.
Une session s'ouvre en trois temps. Le client se connecte au serveur, négocie le chiffrement, puis s'authentifie. Une fois la session établie, les échanges se font par stanzas, des blocs XML de trois types : message pour le contenu, presence pour l'état de disponibilité, IQ pour les requêtes et réponses. Cette architecture est décrite dans les RFC 6120 et 6121 publiées en 2011.
La fédération est la caractéristique centrale. Un serveur XMPP n'est pas une île : il peut dialoguer avec n'importe quel autre serveur du réseau, à condition que les deux respectent le standard. Une PME qui héberge son propre serveur peut donc échanger avec un partenaire équipé différemment, sans passer par une passerelle propriétaire.
Pour un lecteur qui veut vérifier un point technique dans les textes de référence, un guide éditorial en anglais consacré au protocole détaille l'ouverture de session, la construction des JID et les souscriptions de présence : guide XMPP en anglais.
Quels serveurs et clients choisir pour une PME ?
Le choix se fait en deux temps : le serveur, puis le client.
Côté serveur, trois logiciels libres dominent le paysage :
- ejabberd : écrit en Erlang, réputé pour la montée en charge et la clustering.
- Prosody : écrit en Lua, léger, adapté aux petites structures et aux serveurs modestes.
- Openfire : écrit en Java, avec une interface d'administration graphique qui facilite la prise en main.
Les trois gèrent TLS, la fédération et les extensions courantes. Le choix dépend surtout des compétences internes : un administrateur à l'aise avec Java préférera Openfire, une équipe qui veut un serveur sobre optera pour Prosody.
Deux points techniques conditionnent la mise en service. Le premier est le DNS : il faut publier des enregistrements SRV qui indiquent aux autres serveurs où joindre le service. Le second est le certificat TLS, nécessaire pour chiffrer les flux et pour que les clients mobiles acceptent la connexion sans alerte.
Côté client, le critère décisif en entreprise est la contrainte mobile. Un client de bureau et un client mobile n'ont pas les mêmes besoins : le premier gère plusieurs comptes et l'historique long, le second doit économiser la batterie et fonctionner derrière les restrictions réseau des systèmes mobiles. Il faut donc tester le client sur les terminaux réellement utilisés avant de généraliser.
Quelles extensions pour le chiffrement et les salons ?
Le protocole de base ne couvre ni le chiffrement de bout en bout ni les discussions de groupe. Ces fonctions viennent d'extensions, les XEP, proposées et discutées par la communauté selon un processus public.
Pour le chiffrement de bout en bout, OMEMO est l'extension la plus répandue. Elle s'appuie sur le chiffrement de type double ratchet et permet à deux clients de communiquer sans que le serveur puisse lire le contenu. Tous les clients ne l'implémentent pas de la même façon, ce qui impose de vérifier la compatibilité avant de déployer.
Pour les discussions de groupe, deux mécanismes coexistent :
- MUC, pour les salons multi-utilisateurs classiques, avec un salon hébergé sur un serveur et des participants identifiés.
- MIX, plus récent, qui vise à unifier les salons et les conversations individuelles sous une même logique d'adressage.
MUC est le plus largement supporté. MIX reste en cours d'adoption, et une PME qui a besoin de salons stables a intérêt à vérifier le support côté client avant de s'engager.
Pourquoi le nom Jabber et XMPP coexistent-ils ?
Jabber est le nom d'origine du projet, apparu au début des années 2000. Le protocole a ensuite été normalisé sous le nom XMPP, et la propriété du nom Jabber a fait l'objet de règles d'usage distinctes de celles du standard lui-même.
Cette dualité explique une confusion fréquente. Dans la pratique, les deux termes désignent souvent la même chose : une messagerie ouverte fondée sur des flux XML. La chronologie est instructive : des premiers serveurs jabberd aux RFC de 2004 puis 2011, le protocole a gagné en stabilité et en sécurité. Les extensions, elles, continuent d'évoluer au rythme des propositions de la communauté.
Pour une PME, l'enjeu n'est pas historique mais pratique : un protocole normalisé et documenté limite le risque de dépendance à un fournisseur unique. Si un prestataire disparaît, les données et les adresses restent exploitables ailleurs.
Quels cas d'usage en entreprise et quelles limites ?
XMPP convient à plusieurs besoins concrets :
- messagerie interne entre collaborateurs, avec présence et historique ;
- canal d'alerte technique, car un serveur peut envoyer des messages automatiques ;
- échange avec des partenaires équipés d'un serveur fédéré, sans compte chez un tiers.
Les limites doivent être connues. Le chiffrement de bout en bout dépend du client : si un poste utilise un logiciel sans OMEMO, la conversation n'est pas protégée de bout en bout. La fédération suppose une configuration DNS et TLS correcte, sinon les échanges avec l'extérieur échouent. Enfin, l'administration d'un serveur demande un suivi : mises à jour, certificats, sauvegardes.
Une alternative consiste à confier l'hébergement à un prestataire spécialisé. La PME garde alors ses adresses et ses données, mais délègue l'exploitation. Le choix dépend de la sensibilité des échanges et des compétences disponibles en interne.
Ce qu'il faut retenir avant de se lancer
Trois vérifications précèdent tout déploiement. D'abord, identifier les usages réels : messagerie interne seule, ou échanges fédérés avec l'extérieur. Ensuite, tester le client sur les terminaux utilisés, en particulier les mobiles. Enfin, vérifier le support des extensions nécessaires, notamment OMEMO pour le chiffrement et MUC pour les salons.
Un déploiement progressif, sur un groupe restreint, permet de mesurer la charge d'administration avant d'étendre à toute l'entreprise. Le protocole est stable et documenté ; c'est l'exploitation qui demande de la méthode.
Source a consulter : rfc-editor.org (RFC 6120).