Visioconférence auto-hébergée (Jitsi Meet)

Contexte et objectif

Dans le cadre du module R5.ROM.09 (Service Multimédia), j'ai déployé en binôme un serveur Jitsi Meet auto-hébergé, alternative souveraine aux services de visioconférence commerciaux. L'objectif était d'obtenir un service conteneurisé, accessible en HTTPS, réservant la création de salle aux comptes authentifiés, puis d'y ajouter l'enregistrement et la diffusion RTMP en direct via Jibri. J'ai réalisé l'ensemble des manipulations techniques.

Ce que j'ai réalisé

• J'ai créé une VM Debian 13 à IP statique (4 vCPU et 8 Go de RAM minimum) et installé Docker et Docker Compose depuis le dépôt officiel Docker.
• J'ai fait résoudre le nom de domaine interne par le fichier hosts du poste client et ouvert uniquement les ports 80, 443 et 10000/udp avec ufw.
• J'ai cloné le dépôt docker-jitsi-meet, généré les mots de passe internes, renseigné le fichier .env, puis démarré les quatre conteneurs (web, prosody, jicofo, jvb) et ouvert une première salle de test.
• J'ai généré un certificat wildcard local avec mkcert et l'ai monté dans le conteneur web.
• J'ai activé l'authentification interne de Prosody, créé deux comptes organisateurs et ajouté un lobby.
• J'ai chargé le module noyau snd-aloop, démarré Jibri, déclenché un enregistrement, puis une diffusion RTMP vers un serveur RTMP local.

Difficultés rencontrées et solutions

• Domaine interne sans nom public : j'ai retenu mkcert plutôt que Let's Encrypt, au prix d'une installation manuelle de la CA sur chaque poste client.
• Sans le module snd-aloop, Jibri démarre mais l'enregistrement échoue silencieusement : je l'ai chargé avant de lancer le conteneur.

Résultats

• Salle Jitsi accessible en HTTPS, sans avertissement du navigateur.
• Un organisateur authentifié peut ouvrir une salle, un invité ne peut que la rejoindre une fois ouverte.
• Fichier d'enregistrement récupéré après une réunion.