Jitsi self-hosted vs Zoom : ce qui change vraiment
Les services de visioconférence grand public (Zoom, Google Meet, Teams) imposent des limites de durée sur les plans gratuits, des quotas de participants, et conservent vos enregistrements sur leurs serveurs. Jitsi Meet, auto-hébergé, supprime ces contraintes : salles sans limite, durée sans limite, aucun compte requis pour rejoindre une réunion, flux vidéo qui restent sur votre infrastructure. C'est particulièrement pertinent pour une organisation soucieuse de la confidentialité de ses réunions, pour un cabinet qui traite des données sensibles, ou pour intégrer la visio dans une application tierce (Jitsi propose une API iframe stable). Le coût de fonctionnement se résume à la facture du VPS — aucun abonnement par siège, aucun surcoût logiciel.
Bénéfices concrets d'un Jitsi auto-hébergé
- Réunions sans limite de durée ni de nombre de salles — aucun minuteur qui coupe la réunion.
- Aucun compte requis pour les participants : un lien suffit pour rejoindre.
- API iframe pour intégrer la visio directement dans votre application ou votre site.
- Chiffrement du transport (DTLS-SRTP) et contrôle total sur les éventuels enregistrements.
- Personnalisation complète de l'interface : logo, couleurs, nom de domaine des salles.
- Aucune télémétrie envoyée à un tiers — les flux vidéo ne quittent pas votre VPS.
Prérequis chiffrés avant de commencer
Jitsi est dimensionné par la bande passante, pas par le CPU. Pour des réunions jusqu'à 10 participants : 2 vCPU, 4 Go de RAM minimum, trafic sortant généreux (100 Mbps conseillés). Au-delà de 20 participants simultanés, comptez 8 Go de RAM et surveillez la charge réseau du JVB. Trois ports doivent être joignables depuis internet : TCP 443 (HTTPS et TURN/TLS), TCP 80 (renouvellement Let's Encrypt), UDP 10000 (média JVB). Ajoutez TCP 3478 si vous exposez coturn sur son port natif. Il faut Docker 24+ et Compose V2, un nom de domaine meet.votredomaine.com avec un enregistrement A pointant vers l'IP publique du VPS, et une IP publique dédiée et stable — une IP partagée complique sérieusement la config coturn.
Déploiement pas à pas : Docker, .env, coturn et premier test
Récupérer docker-jitsi-meet
Clonez le dépôt officiel :
git clone https://github.com/jitsi/docker-jitsi-meet. Copiezenv.examplevers.env, puis exécutez./gen-passwords.sh— ce script génère tous les secrets internes (Prosody, Jicofo, JVB). Ne sautez pas cette étape : les valeurs par défaut ne sont pas des secrets. La branchestable-11146-2(août 2026) est la dernière stable ; évitezmainen production, les composants internes changent sans préavis.Configurer PUBLIC_URL et DOCKER_HOST_ADDRESS
Dans
.env, deux variables sont critiques :PUBLIC_URL=https://meet.votredomaine.com(utilisée par le client web pour construire les URL de salles) etDOCKER_HOST_ADDRESS=<IP_PUBLIQUE_DU_VPS>(l'adresse que le JVB annonce aux clients pour établir la connexion média directe). SansDOCKER_HOST_ADDRESS, le JVB annonce une adresse interne Docker et aucun client extérieur ne peut l'atteindre.Activer Let's Encrypt dans .env
Ajoutez dans
.env:ENABLE_LETSENCRYPT=1,LETSENCRYPT_DOMAIN=meet.votredomaine.com,[email protected]. Vérifiez que le port 80 est bien ouvert avant de démarrer — Let's Encrypt utilise un challenge HTTP-01 qui requiert une réponse sur ce port. Pour le renouvellement automatique, le conteneur web de docker-jitsi-meet appelle certbot en cron interne : vérifiez que le volume~/.jitsi-meet-cfg/web/letsencryptest bien monté et persistant entre les redémarrages.Configurer coturn (TURN server)
C'est l'étape que la plupart des guides survolent et qui fait échouer l'installation. Dans
.env, activez :ENABLE_TURN=1,TURN_HOST=meet.votredomaine.com,TURN_PORT=443,TURN_TRANSPORT=tls. Le port 443 en TLS permet de traverser les pare-feux les plus restrictifs, qui bloquent les ports non standard mais laissent passer ce qui ressemble à du HTTPS.Ajoutez ensuite :
TURN_CREDENTIALS=un_secret_fort,TURN_TLS_CERT=/etc/letsencrypt/live/meet.votredomaine.com/fullchain.pem,TURN_TLS_KEY=/etc/letsencrypt/live/meet.votredomaine.com/privkey.pem. Si coturn tourne dans un conteneur séparé, montez ces fichiers en volume.Dernier point souvent oublié : coturn bloque par défaut les plages RFC1918 (192.168.x.x, 10.x.x.x, 172.16.x.x). Si votre VPS a une interface réseau interne dans ces plages, ajoutez
no-multicast-peerset vérifiez quedenied-peer-ipn'inclut pas l'adresse du JVB.Lancer la stack et vérifier le JVB
Exécutez
docker compose up -d. Attendez 30 secondes, puis :docker compose logs jvb 2>&1 | grep -E 'register|connected|error'. Vous devez voir une ligne indiquant que le JVB s'est enregistré auprès de Jicofo. Si vous voyezFailed to registerouConnection refused, le Prosody n'est pas encore prêt — relancez après une minute. Vérifiez ensuite que coturn répond :nc -zv meet.votredomaine.com 443(TCP) etnc -zvu meet.votredomaine.com 10000(UDP).Premier test vidéo depuis deux réseaux différents
Ouvrez
https://meet.votredomaine.comdepuis votre poste habituel et depuis un second appareil sur un réseau différent (téléphone en 4G par exemple). Si les deux participants se voient et s'entendent, le TURN fonctionne. Un test depuis deux postes sur le même réseau local ne valide pas coturn — il réussit en pair-à-pair sans jamais solliciter le relais.
Configuration avancée : enregistrement, authentification et limites
Enregistrement des réunions. Jitsi intègre Jibri pour l'enregistrement local ou le streaming RTMP. Jibri requiert un second VPS ou au minimum 4 vCPU supplémentaires, car il capture le rendu navigateur en temps réel. Activez ENABLE_RECORDING=1 dans .env et déployez un conteneur Jibri séparé pointant vers votre Jicofo. Authentification des organisateurs. Par défaut, n'importe qui peut créer une salle. Activez AUTH_TYPE=internal pour exiger un compte côté organisateur tout en laissant les invités rejoindre librement. Créez les comptes hôtes avec docker exec <prosody-container> prosodyctl --config /config/prosody.cfg.lua register admin meet.votredomaine.com motdepasse. Limiter les participants anonymes. Ajoutez ENABLE_LOBBY=1 pour qu'un modérateur valide chaque entrée avant d'accéder à la salle. Combiné à AUTH_TYPE=internal, cela donne un contrôle complet sur qui accède à quoi.
Durcissement : fail2ban sur le service TURN
coturn expose un service accessible depuis internet. Installez fail2ban et créez un filtre sur les tentatives d'authentification TURN échouées : les logs coturn écrivent ERROR: 401, realm à chaque échec. Une jail fail2ban avec maxretry=10 et bantime=600 suffit à décourager les scans automatiques sans impacter vos utilisateurs légitimes. Vérifiez que fail2ban surveille /var/log/coturn.log (chemin par défaut si coturn tourne en natif) ou montez ce fichier depuis le conteneur.
Dépannage : les quatre erreurs les plus fréquentes
Son absent ou vidéo bloquée sur « connecting » — coturn + UDP 10000. C'est la panne la plus fréquente. Vérifiez dans cet ordre : (1) ufw status — les ports TCP 443 et UDP 10000 sont-ils ouverts ? (2) docker compose logs coturn | grep -i error — coturn démarre-t-il sans erreur de certificat ? (3) Depuis une machine externe : curl -v telnet://meet.votredomaine.com:3478 — coturn répond-il ? (4) Dans les logs du navigateur (F12 → Console) : voyez-vous ICE failed ou failed to gather candidates ? Si oui, coturn n'est pas joignable depuis l'extérieur. Comparez TURN_HOST dans .env avec l'IP réelle du VPS. Connexion refusée sur TCP 443. Si le certificat Let's Encrypt n'a pas pu être émis (port 80 fermé lors du premier démarrage), le conteneur web tente de servir en HTTPS avec un certificat auto-signé que le navigateur refuse. Solution : ouvrez le port 80, supprimez le volume ~/.jitsi-meet-cfg/web et relancez docker compose up -d. Partage d'écran refusé par le navigateur. Le partage d'écran exige un contexte sécurisé (HTTPS valide). Si vous voyez getUserMedia is not supported, le certificat est invalide ou le domaine n'est pas en HTTPS. Vérifiez PUBLIC_URL — elle doit commencer par https:// avec un domaine dont le certificat est valide, pas une IP brute. Erreur « ICE failed » persistante malgré coturn opérationnel. Vérifiez la variable DOCKER_HOST_ADDRESS : elle doit contenir l'IP publique du VPS, pas l'IP interne du conteneur Docker (172.17.x.x). Si votre VPS est derrière un NAT cloud (rare mais existant), vous avez besoin de l'IP NAT externe, pas de l'IP de l'interface réseau.
Monitoring : surveiller la bande passante et les participants
Le pont vidéo JVB expose une API de statistiques en temps réel sur http://localhost:8080/colibri/stats. Cette endpoint JSON rapporte le nombre de conférences actives, de participants, la bande passante entrante et sortante en bits/s, et le nombre de paquets perdus. Pour une surveillance continue, activez le support Prometheus dans .env (JVB_ENABLE_STATS=1, PROSODY_ENABLE_METRICS=1) et connectez un Prometheus + Grafana : un tableau de bord Jitsi officiel est disponible sur Grafana Labs (ID 11925) et couvre CPU, mémoire, bande passante et métriques de qualité vidéo.
En l'absence de Prometheus, une surveillance minimale s'obtient avec un cron qui interroge /colibri/stats et alerte si le débit dépasse un seuil : docker exec jvb curl -s http://localhost:8080/colibri/stats | python3 -c "import json,sys; s=json.load(sys.stdin); print(s.get('bit_rate_download',0), s.get('bit_rate_upload',0))".
Pour estimer la capacité avant d'atteindre la saturation : un JVB gère confortablement 200 à 250 participants interactifs à qualité vidéo modérée sur un VPS bien connecté. Au-delà, les métriques packet_loss_fraction et rtt_aggregate grimpent et la qualité perçue chute avant que le CPU sature — c'est le signal pour ajouter une instance JVB.
Votre Jitsi est en place — gérez la bande passante
Jitsi fonctionne en mode SFU : le pont vidéo (JVB) relaie chaque flux vers chaque participant, donc la bande passante sortante grimpe proportionnellement au nombre de participants multiplié par le nombre de flux. Pour 10 participants à 720p, comptez 20 à 40 Mbps sortants en continu. Activez lastN=5 (dernières N vidéos actives) pour limiter les flux côté client sur les grosses réunions, et surveillez docker stats jvb pour anticiper la saturation. Au-delà d'une vingtaine de participants simultanés réguliers, déployez plusieurs instances JVB sur des VPS distincts derrière un seul Jicofo : c'est l'architecture de passage à l'échelle horizontale native de Jitsi. Pour les déploiements multi-organisations ou multi-domaines, Jitsi supporte plusieurs PUBLIC_URL via le mécanisme de tenant Prosody : chaque organisation dispose de son espace de salles isolé sur la même installation, sans infrastructure supplémentaire.