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. 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.

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.

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.

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.