Héberger Jitsi sur votre propre VPS

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.

Jitsi est dimensionné par la bande passante, pas par le CPU. La documentation Jitsi conseille 8 Go de RAM (4 Go suffisent pour de petites réunions), environ 4 cœurs dédiés pour un serveur de base, et surtout un lien réseau fiable : un flux 720p consomme environ 2,5 Mbit/s, et un lien de 100 Mbit/s ne tient pas une vingtaine de participants en haute définition. Surveillez la charge réseau du JVB. Trois ports doivent être joignables depuis internet : TCP 443 (HTTPS), TCP 80 (challenge Let's Encrypt et redirection vers HTTPS), UDP 10000 (média JVB). Le port TCP 4443 cité par d'anciens guides ne figure plus dans la liste officielle. Si coturn tourne sur le même VPS, ajoutez ses ports : 3478 en UDP et TCP, 5349 en TLS (le 443 est déjà pris par le conteneur web). Il faut Docker avec Compose V2 (commande docker compose), 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.

Enregistrement des réunions. Jitsi intègre Jibri pour l'enregistrement local ou le streaming RTMP. Jibri capture le rendu d'un navigateur en temps réel : une instance n'enregistre qu'une réunion à la fois, et la documentation Jitsi demande au moins 8 Go de RAM par instance en 720p, de préférence sur un serveur séparé. Activez ENABLE_RECORDING=1 dans .env et lancez le conteneur Jibri fourni : docker compose -f docker-compose.yml -f jibri.yml up -d. Authentification des organisateurs. Par défaut, n'importe qui peut créer une salle : une instance publique laissée ainsi devient une visio gratuite pour des inconnus, sur votre bande passante. Activez ENABLE_AUTH=1, AUTH_TYPE=internal et ENABLE_GUESTS=1 pour exiger un compte côté organisateur tout en laissant les invités rejoindre librement. Créez les comptes hôtes avec docker compose exec prosody prosodyctl --config /run/prosody/config/prosody.cfg.lua register admin meet.jitsi <mot_de_passe> : meet.jitsi est le domaine XMPP interne, pas votre nom public, et le mot de passe se génère (openssl rand -base64 18) plutôt que de se réutiliser. Limiter les participants anonymes. ENABLE_LOBBY=1 rend disponible la salle d'attente : une fois activée par le modérateur, chaque entrée doit être validée avant d'accéder à la salle. Combiné à ENABLE_AUTH=1, cela donne un contrôle complet sur qui accède à quoi.

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) les journaux de coturn (journalctl -u coturn en natif, docker logs <conteneur-coturn> sinon) — 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. Vérifiez que TURN_HOST et TURNS_HOST dans .env résolvent bien vers l'IP réelle du serveur coturn. 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 s'arrête après le message Failed to obtain a certificate from the Let's Encrypt CA et plus rien ne répond sur le 443. Solution : ouvrez le port 80, vérifiez HTTP_PORT=80 et relancez docker compose up -d ; inutile de supprimer la configuration, et chaque nouvel essai compte dans les limites de Let's Encrypt. 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 JVB_ADVERTISE_IPS (anciennement 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.

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 kbit/s, et le RTT moyen (rtt_aggregate). Ce port 8080 n'est publié que sur 127.0.0.1 : gardez-le ainsi. Pour une surveillance continue, le JVB expose déjà ses métriques au format Prometheus sur /metrics (même port privé) ; côté Prosody, activez PROSODY_ENABLE_METRICS=1 dans .env. Connectez ensuite un Prometheus + Grafana : le dépôt fournit prometheus.yml et grafana.yml, qui publient les ports 9090 et 3000 sur toutes les interfaces. Limitez-les à 127.0.0.1 ou à un VPN, car les ports publiés par Docker contournent les règles ufw.

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 : curl -s http://127.0.0.1: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 : la capacité d'un JVB dépend d'abord du lien réseau et des résolutions envoyées ; mesurez-la sur votre propre charge plutôt que de vous fier à un chiffre générique. Quand la limite approche, rtt_aggregate grimpe et la qualité perçue chute avant que le CPU sature — c'est le signal pour ajouter une instance JVB.

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. Un flux 720p pèse environ 2,5 Mbit/s selon la documentation Jitsi : multipliez par le nombre de flux réellement envoyés à chaque participant pour estimer le débit sortant. Réglez channelLastN: 5 dans custom-config.js (dossier web de la configuration) pour ne recevoir que les N dernières 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, retenez qu'une installation docker-jitsi-meet n'a qu'une PUBLIC_URL : si chaque organisation doit disposer de ses propres comptes et d'un espace de salles isolé, prévoyez une instance par organisation, sur son propre sous-domaine.