Visioconférence auto-hébergée : quel VPS choisir ?

La visioconférence auto-hébergée sur un VPS est un problème de bande passante

La visioconférence auto-hébergée échoue sur les petits serveurs pour une seule raison, et ce n’est presque jamais l’installation. Le composant serveur utilisé par tous les outils modernes est un SFU (selective forwarding unit). Il reçoit un flux vidéo de chaque participant et en transmet une copie à tous les autres participants. Le trafic sortant du serveur augmente donc avec le carré du nombre de participants. Un VPS de 1 GB ou 2 GB sur une liaison montante partagée exécutera correctement le logiciel. En revanche, il ne pourra pas gérer la réunion générale que vous envisagez.

Procédez donc dans cet ordre. Comptez les participants, calculez le débit nécessaire, puis choisissez le serveur. L’installation prend vingt minutes de copier-coller. C’est la liaison montante qui détermine si les participants peuvent vous entendre.

Pourquoi la bande passante augmente-t-elle avec le carré du nombre de participants ?

Commençons par le mesh. Chaque navigateur encode la vidéo de sa caméra et envoie directement une copie à tous les autres navigateurs. Aucun media server n’intervient dans la vidéo. Un appel mesh à deux personnes nécessite uniquement un serveur de signalisation. C’est pourquoi les appels individuels coûtent presque rien à héberger. Le mesh cesse de fonctionner vers quatre ou cinq personnes, car un ordinateur portable connecté à une connexion domestique doit téléverser simultanément quatre ou cinq copies distinctes de sa propre vidéo.

Un SFU fonctionne autrement. Chaque navigateur téléverse une copie vers le serveur. Le serveur lit les en-têtes RTP (real-time transport protocol), puis retransmet ces paquets aux autres participants sans décoder la vidéo. C’est tout le principe. C’est pourquoi un SFU consomme peu de CPU, mais beaucoup de réseau.

L’ancienne architecture est un MCU (multipoint control unit). Il décode chaque flux entrant, les compose en une seule image, puis réencode cette image. La bande passante sortante est faible. Le coût CPU est énorme. Presque plus personne n’utilise de MCU pour la vidéo, et ce guide n’en utilise pas.

Passons maintenant aux calculs pour un SFU. Supposons que chaque personne envoie une vidéo à 1.2 Mbps et que personne n’ait coupé sa caméra. Le serveur reçoit N fois 1.2 Mbps. Cette valeur est linéaire et ne pose pas de problème. Le serveur envoie N fois (N moins 1) fois 1.2 Mbps, car chacune des N personnes doit recevoir les N moins 1 autres flux. C’est cette seconde valeur qui met fin aux projets.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Ces lignes correspondent à des calculs, pas à une mesure effectuée sur un serveur particulier. La colonne mensuelle suppose vingt heures d’appels par mois. Commencez par lire la dernière ligne. Cinquante personnes avec leur caméra activée nécessitent 2,940 Mbps de trafic sortant soutenu depuis une seule machine. Trente personnes nécessitent 1,044 Mbps. Quatre personnes nécessitent 14.4 Mbps, ce que n’importe quel VPS gère sans difficulté. Entre la ligne de quatre personnes et celle de trente personnes, le nombre de participants est multiplié par sept et demi, tandis que le trafic sortant est multiplié par plus de soixante-dix.

Les déploiements réels restent en dessous de ces valeurs. Il est utile de comprendre exactement pourquoi. Jitsi et LiveKit utilisent tous deux le simulcast : un émetteur publie simultanément plusieurs couches de qualité, et le SFU transmet une couche basse à toute personne qui n’est pas affichée à l’écran. Jitsi dispose également d’un paramètre last-N qui ne transmet la vidéo que des derniers intervenants. Ces deux mécanismes réduisent fortement le trafic. Aucun ne change la forme de la courbe. Ils cessent tous deux d’être utiles dès que tout le monde active sa caméra et épingle les autres participants.

Que vous apporte réellement la liaison montante d’un VPS ?

Une fiche d’offre indique « port à 1 Gbps ». Il s’agit du débit de la carte réseau virtuelle, et non d’une garantie concernant le routeur suivant. La liaison est partagée avec les autres locataires du même hôte physique. Le débit soutenu pendant une période de forte activité est donc inférieur au débit du port. Une conférence est précisément une charge soutenue. La plupart des offres incluent également un quota mensuel de transfert. Une fois ce quota dépassé, le débit est réduit ou la consommation est facturée.

C’est ce quota qui peut faire grimper la facture. Vingt heures de l’appel à trente participants sur un mois représentent 9.4 TB sortants du serveur, à 469.8 GB par heure. Vingt heures de l’appel à cinquante participants représentent 26.5 TB. Vérifiez le quota de transfert avant la quantité de RAM. Si la fiche de l’offre reste vague à ce sujet, cette imprécision constitue déjà une réponse. Lire correctement une offre de VPS à bas prix compte davantage pour cette charge que pour presque toute autre.

Jitsi Meet : le choix par défaut et ses prérequis

Jitsi Meet est le premier choix pour la plupart des utilisateurs. Il s’installe depuis le dépôt Debian du projet, configure nginx et un certificat pendant l’installation, et le videobridge (JVB) utilise un seul port UDP, ce qui limite le nombre de règles du pare-feu. Il nécessite Debian 11 ou une version ultérieure, ou Ubuntu 22.04 ou une version ultérieure.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

L’installateur demande un nom d’hôte, puis propose de choisir un certificat. Sélectionnez l’option Let's Encrypt et indiquez un nom de domaine qui résout déjà vers l’adresse publique de ce serveur. Le certificat est délivré au moyen d’un challenge HTTP. Un nom qui pointe ailleurs échoue donc à cette étape.

Ouvrez ensuite les ports. Ce sont ceux documentés dans le manuel, avec SSH en premier pour éviter que ufw enable ne vous bloque l’accès :

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 et 443 servent l’application web et permettent le renouvellement du certificat. UDP 10000 transporte tout l’audio et la vidéo. C’est le port que l’on oublie le plus souvent. UDP 3478 et TCP 5349 appartiennent au serveur coturn que le paquet Jitsi installe avec le bridge. Ils servent de chemin de secours lorsque le réseau d’un utilisateur bloque UDP.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

La première commande doit indiquer que le service est actif. La seconde doit afficher que le bridge écoute sur UDP 10000. Si elle n’affiche rien, le bridge n’a pas démarré et /var/log/jitsi/jvb.log indiquera pourquoi.

Pour le dimensionnement, le manuel de Jitsi publie son propre point de départ, tandis que BigBlueButton en publie un beaucoup plus élevé :

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

Le manuel de Jitsi recommande 8 Go de RAM et 4 cœurs dédiés pour un serveur sérieux. Une connexion réseau de 1,000 Mbps suffit souvent. Il précise aussi que des configurations plus modestes fonctionnent avec 4 Go ou 2 Go. Un détail de cette page mérite d’être retenu : Prosody, le serveur XMPP qui gère la signalisation, ne peut utiliser qu’un seul cœur. Les cœurs supplémentaires profitent au bridge, mais pas à la signalisation.

Pourquoi tout le monde rejoint l’appel, mais personne ne voit la vidéo ?

C’est le problème Jitsi classique sur un VPS. La liste des participants se remplit, le chat fonctionne et toutes les vignettes vidéo restent noires. Le videobridge annonce les adresses qu’il trouve sur ses propres interfaces. Chez un fournisseur qui attribue une adresse privée à la machine virtuelle et lui associe une adresse publique, JVB ne trouve que l’adresse privée. Chaque client essaie donc d’envoyer les flux média vers une adresse comme 10.0.0.5, et les paquets n’arrivent nulle part.

Indiquez les deux adresses au bridge. Ajoutez une correspondance statique dans /etc/jitsi/videobridge/jvb.conf :

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Redémarrez avec sudo systemctl restart jitsi-videobridge2. Récupérez l’adresse locale dans ip -4 addr show et l’adresse publique dans le panneau de contrôle de votre fournisseur. Les anciens guides configurent la même chose dans /etc/jitsi/videobridge/sip-communicator.properties avec les clés org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS et org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Ces paramètres fonctionnent toujours, mais les nouvelles installations doivent utiliser le bloc de correspondance ci-dessus.

L’autre cause possible est un pare-feu que vous n’avez pas configuré. La plupart des fournisseurs exécutent un pare-feu réseau dans le panneau de contrôle, séparé de ufw sur la machine. Le port UDP 10000 doit être ouvert dans les deux pare-feu. Pour déterminer quelle couche bloque les paquets, exécutez sudo tcpdump -ni any udp port 10000 sur le serveur pendant qu’une personne rejoint l’appel depuis l’extérieur. Si aucun paquet n’arrive, rien n’atteint la machine : le blocage se situe en amont du système d’exploitation. Si des paquets arrivent alors que les vignettes restent noires, le bridge répond avec une adresse inaccessible au client : le problème vient donc de la correspondance. Si vous avez un doute sur ufw lui-même, les règles ufw réellement nécessaires sur un VPS expliquent l’ordre des règles qui pose souvent problème.

BigBlueButton : lourd, directif et conçu pour utiliser tout le serveur

BigBlueButton est conçu pour l’enseignement. Il intègre un tableau blanc, des salles de réunion, des sondages et une zone de présentation. Son pipeline d’enregistrement est une fonctionnalité native, et non un module complémentaire. C’est aussi, de loin, l’option la plus lourde de cette liste. Ce n’est pas un paquet que vous ajoutez à un serveur existant.

En août 2026, la procédure prise en charge utilise BigBlueButton 3.0 sur Ubuntu 22.04, sélectionné avec le flag de version jammy-300. Les exigences de production indiquées par le projet sont 16 Go de mémoire avec le swap activé, 8 cœurs CPU avec de bonnes performances mono-thread, 250 Mbps de bande passante symétrique et 500 Go de disque si vous conservez les enregistrements (50 Go si vous les désactivez). Les ports requis sont TCP 80 et 443, ainsi que la plage UDP 16384 à 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Les exemples du projet transmettent directement ce script à bash. Téléchargez-le et lisez-le d’abord, car il réécrit votre configuration nginx, installe sa propre stack media et audio, bloque les versions des paquets et s’approprie le hostname. C’est le fonctionnement prévu, et non un défaut : BigBlueButton s’attend à contrôler la machine. Le flag -w configure le firewall, -s correspond au hostname, -e indique l’adresse enregistrée par Let’s Encrypt et -g ajoute le frontend Greenlight. Si cette même machine assure aussi la terminaison TLS d’autres services, déplacez BigBlueButton sur une autre machine ou assurez-vous de comprendre ce que fait votre configuration nginx de reverse proxy avant que le script ne la modifie.

Comparez attentivement les deux lignes de ce tableau. BigBlueButton demande deux fois plus de mémoire et deux fois plus de cœurs que la recommandation de Jitsi, tout en demandant un quart de la bande passante. Les deux valeurs ne sont pas mesurées de la même manière et supposent des tailles de salles différentes. Considérez donc chacune comme le point de départ de son propre projet, et non comme une comparaison directe. L’écart au niveau du CPU est réel. Il vient de tout ce que BigBlueButton fait en plus de la transmission de la vidéo.

Galène : l’option légère

Galène est un SFU compact écrit en Go. Il se compile en un binaire statique unique, fournit son propre client web et intègre un serveur TURN. Il n’y a donc pas de serveur XMPP, de runtime Java ni d’application Rails à maintenir en fonctionnement. Si vous avez besoin d’un appel fiable à dix personnes sur une machine modeste, essayez cette solution avant de conclure qu’il vous faut davantage de matériel.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Le package golang-go d’Ubuntu 24.04 fournit Go 1.22. Si go build signale que le module nécessite une version plus récente de Go, installez une toolchain actuelle depuis go.dev au lieu de vous battre avec le package de la distribution.

Un groupe est le terme utilisé par Galène pour désigner une salle, et un groupe est un fichier JSON :

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Ouvrez https://your.server:8443/group/night-watch/ et connectez-vous avec vimes. Ces identifiants proviennent directement du README du projet. Modifiez-les avant que le port soit accessible depuis un autre réseau. Pour un déploiement réel, le projet documente une unité systemd :

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Les ports sont TCP 8443 pour l’interface web, TCP et UDP 1194 pour le serveur TURN intégré, ainsi qu’une plage de ports UDP élevés pour les flux multimédias. Définissez cette plage afin de pouvoir écrire une seule règle de pare-feu pour celle-ci :

./galene -udp-range 40000-40100

L’option -turn est celle qui compte sur un VPS. -turn ':1194' écoute sur toutes les adresses IPv4 publiques. -turn '203.0.113.1:1194' indique à Galène l’adresse que les clients verront réellement. Cette option est nécessaire lorsque l’adresse de la machine est privée. -turn '' désactive le serveur intégré afin que vous puissiez utiliser un serveur externe via data/ice-servers.json. La valeur par défaut est auto, qui se comporte comme :1194 lorsqu’aucun ice-servers.json n’existe.

Vous pouvez placer nginx devant l’interface web en définissant proxyURL dans data/config.json et en proxyfiant l’emplacement /ws avec les en-têtes de mise à niveau WebSocket. Sachez ce que cela couvre : les clients ouvrent toujours des flux UDP directs et des connexions TCP directes vers le port TURN. Le reverse proxy ne gère donc que la page et la signalisation. Les flux multimédias ne le traversent jamais.

La documentation de Galène indique que le serveur nécessite des ressources très modérées, mais ne fournit aucun chiffre précis. N’en attendez donc pas. Les calculs de bande passante présentés plus haut restent entièrement applicables. Les économies concernent la mémoire et les composants de tout ce qui ne fait pas partie du SFU.

Owncast : diffusion d’une source vers plusieurs spectateurs, avec une bande passante linéaire

De nombreux besoins de « visioconférence » correspondent en réalité à une personne qui présente du contenu à un public utilisant le chat. Si c’est votre cas, un SFU n’est pas le bon outil et les coûts changent complètement. Owncast reçoit un flux RTMP depuis OBS ou un encodeur similaire, puis sert le flux HLS sur HTTPS standard. La bande passante par spectateur évolue de manière linéaire, et comme la sortie se compose de segments HTTP classiques, vous pouvez la placer derrière un stockage objet ou un CDN et ne plus la faire transiter par le serveur d’origine.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

La documentation du projet indique qu’il ne faut pas exécuter ce service en tant que root et qu’il faut examiner tout script distant avant de l’exécuter. C’est pourquoi le téléchargement constitue une étape distincte ci-dessus. L’installateur récupère la version actuelle ainsi qu’un binaire ffmpeg si vous n’en avez pas déjà un. Exécutez ./owncast depuis le répertoire d’installation, puis ouvrez le panneau d’administration à /admin sur le port 8080. L’identifiant par défaut est l’utilisateur admin, et la clé de stream par défaut abc123 sert de mot de passe. Modifiez-la avant de diriger un domaine vers le serveur.

La conception HLS entraîne deux conséquences. Les spectateurs ont quelques secondes ou quelques minutes de retard sur le direct, car HLS transmet des segments complets. Il n’y a donc pas de conversation interactive. De plus, le chemin ne comprend ni UDP ni TURN. Le service peut ainsi atteindre des réseaux auxquels un appel WebRTC ne peut pas se connecter.

Owncast est également le seul outil présenté ici qui transcode volontairement le flux. Chaque qualité de sortie activée ajoute un encodage ffmpeg du flux entrant, exécuté pendant toute la durée de la diffusion. Sur un petit VPS, proposez une ou deux qualités. Cinq qualités satureraient le CPU alors que le réseau resterait inutilisé.

Element Call sur un serveur Matrix que vous gérez déjà

Si vous gérez déjà Matrix, la vidéo s’ajoute à l’existant au lieu d’introduire un second produit à administrer. Il ne s’agit toutefois pas d’un seul package. Element Call a besoin de deux services derrière votre homeserver. Le premier est un SFU LiveKit, qui assure le transfert des flux multimédias. Le second est le service d’autorisation MatrixRTC, element-hq/lk-jwt-service, qui fournit au client l’URL WebSocket LiveKit et un JWT signé (JSON Web Token) pour s’y connecter. Ce service utilise l’API de fédération Matrix. Il doit donc être placé derrière un reverse proxy TLS et disposer d’un nom accessible depuis la fédération.

Ports documentés de LiveKit :

• TCP 7880 pour l’API et le WebSocket client, derrière un proxy qui termine TLS
• TCP 7881 pour ICE over TCP, utilisé lorsqu’un client ne peut pas sortir par UDP
• UDP 50000 à 60000 pour les flux multimédias, chaque participant d’une room utilisant deux ports
• UDP 3478 et TCP 5349 si vous activez le serveur TURN intégré ; le port 5349 doit alors être déplacé vers 443, sauf si un load balancer est placé devant

Deux ports par participant peuvent sembler préoccupants, mais ce n’est pas le cas. Une plage de 10,000 ports couvre des milliers de participants, et votre liaison montante sera saturée bien avant que la plage ne soit épuisée. Ouvrez tout de même la plage complète. Une plage partiellement ouverte échoue pour certains utilisateurs et fonctionne pour d’autres, ce qui produit le type de panne le plus difficile à diagnostiquer. La configuration côté homeserver est une tâche distincte, décrite dans gérer un homeserver Synapse sur un VPS.

Pourquoi une seule personne ne peut-elle jamais se connecter ? TURN et les réseaux qui bloquent l’UDP

Commençons par quelques termes, utilisés une seule fois chacun. ICE (interactive connectivity establishment) désigne le processus utilisé par deux endpoints WebRTC pour trouver un chemin fonctionnel entre eux. STUN (session traversal utilities for NAT) est un petit service qui indique à un client à quoi ressemble sa propre adresse publique depuis l’extérieur. TURN (traversal using relays around NAT) est un relais : lorsqu’aucun chemin direct n’existe, les deux côtés envoient leur média au serveur TURN, qui le retransmet.

Vous avez besoin de TURN pour les participants dont vous ne maîtrisez pas les réseaux. L’un d’eux peut se trouver sur un réseau d’entreprise ou de campus où l’UDP sortant est entièrement bloqué. Un autre peut être derrière un NAT de niveau opérateur qui attribue un port source différent pour chaque destination. Il s’agit d’un NAT symétrique, qui rend inutilisable l’adresse communiquée par STUN.

Le symptôme est caractéristique. La plupart des utilisateurs rejoignent la session et tout fonctionne. Une personne voit la liste des participants et le chat, mais obtient une tuile noire avec un indicateur de chargement. Son navigateur a recueilli des candidates, mais aucune paire n’a fonctionné, et ICE s’est terminé dans l’état failed. Dans Chrome, chrome://webrtc-internals ouvert pendant la tentative affiche les paires de candidates et cet échec. Demandez à cette personne de réessayer depuis un téléphone connecté aux données mobiles. Si cela fonctionne, son réseau est à l’origine du problème et TURN est la solution.

TURN over TCP sur 443 ou 5349 est le mécanisme de secours qui fonctionne presque partout, car un réseau qui bloque TLS sur 443 bloque aussi le Web. Le paquet Jitsi installe et configure coturn pour vous. C’est la raison pour laquelle ses règles de pare-feu documentées incluent UDP 3478 et TCP 5349. Galène intègre TURN sur 1194. LiveKit intègre un serveur TURN que vous activez dans la configuration. Si vous exécutez vous-même coturn :

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Sur Debian et Ubuntu, le service fourni par le paquet ne démarre pas tant que vous n’avez pas défini TURNSERVER_ENABLED=1 dans /etc/default/coturn. Un coturn installé mais jamais activé est indiscernable, depuis l’extérieur, de l’absence totale de TURN. C’est pourquoi cette ligne peut faire perdre des heures.

Il faut maintenant tenir compte d’un coût rarement mentionné. Un relais transporte l’intégralité du média de chaque participant relayé dans les deux directions. Lorsque coturn partage une machine avec le SFU, la majeure partie de ce trafic passe par la loopback et consomme le CPU plutôt que la bande passante montante. Le listener TLS chiffre également chaque paquet une seconde fois, en plus du chiffrement DTLS déjà utilisé par le média. Lorsque vous déplacez TURN sur une machine dédiée, cette machine a besoin d’une offre de bande passante dimensionnée comme celle du SFU. TURN over TCP transforme en outre le média temps réel en flux fiable. Un paquet perdu est retransmis au lieu d’être ignoré. Un participant relayé sur une liaison instable accumule donc du retard au lieu de subir une brève perturbation. Le relais permet de se connecter, mais avec une qualité que le chemin direct aurait été capable de fournir.

Quand le SFU transcode-t-il, et quel est le coût ?

Un SFU transfère les paquets sans jamais décoder la vidéo. C’est pourquoi quatre cœurs peuvent desservir une salle qui semble impossible à gérer sur le papier. Deux fonctionnalités rompent cette règle. Elles surprennent souvent les personnes qui les ont activées en cochant une case.

L’enregistrement est la première. Jitsi enregistre avec Jibri, et la documentation de Jibri décrit précisément son fonctionnement : il lance une instance de Chrome rendue dans un framebuffer virtuel, puis capture et encode la sortie avec ffmpeg. Un navigateur complet restitue ainsi toute votre réunion, avec un encodeur vidéo, et fonctionne en continu pendant toute la durée de l’appel. La même documentation précise qu’un seul enregistrement à la fois est pris en charge sur un même Jibri, et que Jibri doit fonctionner sur une machine ou une machine virtuelle distincte, sans autre application utilisant les périphériques d’affichage ou audio. L’enregistrement nécessite un deuxième serveur. Ce n’est pas une simple case à cocher.

L’accès par téléphone est la deuxième. Relier une ligne téléphonique à une conférence consiste à convertir Opus à 48 kHz dans les deux sens vers le format accepté par le réseau téléphonique, généralement G.711 à 8 kHz, et ce en continu pendant toute la durée de l’appel. Le transcodage audio coûte beaucoup moins cher que le transcodage vidéo, mais il s’exécute pour chaque branche d’appel et ne s’interrompt jamais. Le coût augmente donc avec le nombre d’appelants. Si vous voulez un numéro d’accès par téléphone, un serveur VoIP auto-hébergé est le composant qui effectue ce travail. Il doit fonctionner sur sa propre machine, pour la même raison que Jibri.

De quelle taille de serveur avez-vous réellement besoin ?

Pour deux personnes, presque aucune ressource. Jitsi active par défaut le mode pair à pair lorsqu’il y a exactement deux participants. Dans ce mode, la conférence n’envoie plus les données via le videobridge et utilise directement la connexion entre les participants. L’arrivée d’une troisième personne réactive le bridge. Ainsi, un VPS de 1 GB exécutant Jitsi convient très bien aux appels individuels, mais beaucoup moins à une conférence de quatre personnes. C’est pourquoi « cela fonctionnait lors de mon test » revient si souvent dans les rapports.

Jusqu’à environ dix personnes avec les caméras activées, 67.2 Mbps avec huit participants restent dans les capacités d’un uplink de VPS ordinaire. Deux CPU virtuels et 4 GB suffisent pour exécuter Jitsi ou Galène dans cette configuration, tant que vous n’enregistrez pas les conférences. Surveillez le compteur de transfert plutôt que le graphique d’utilisation du CPU.

Pour trente personnes, le pire cas atteint 1,044 Mbps en continu, et vingt heures représentent 9.4 TB. À cette échelle, vous devez évaluer le coût de la bande passante avant celui du serveur. Activez last-N afin que le bridge ne transmette que les derniers intervenants, désactivez les caméras par défaut pour les participants et placez le SFU chez un fournisseur dont le quota de transfert couvre ce volume.

Au-delà, un seul VPS n’est plus adapté. Soit l’événement est en réalité une diffusion, auquel cas Owncast avec un CDN coûte une fraction de ce montant, soit vous avez besoin de plusieurs videobridges derrière une même couche de signalisation. Il s’agit alors d’un projet différent de celui que vous aviez commencé.

Un dernier point concernant le routage. La plupart des équipes ont besoin du chat pendant bien plus d’heures dans la journée que de la vidéo. Le chat coûte peu à héberger et reste facile à maintenir. Mettre en place une alternative auto-hébergée à Slack pour le trafic quotidien et conserver un serveur de visioconférence uniquement pour les appels planifiés est l’organisation qui reste viable avec le budget d’un petit VPS.

FAQ

Pourquoi les participants peuvent-ils rejoindre ma réunion Jitsi sans se voir ni s’entendre ?

Le chat et la liste des participants passent par le canal de signalisation, qui utilise TCP sur le port 443. L’audio et la vidéo utilisent UDP 10000 pour communiquer avec le videobridge. Si la liste des participants se remplit mais que toutes les vignettes restent noires, le chemin média est interrompu alors que le canal de signalisation fonctionne. Vérifiez UDP 10000 dans les deux firewalls : celui du serveur et le firewall réseau distinct disponible dans le panneau de contrôle de votre fournisseur. Vérifiez ensuite que le bridge connaît son adresse publique : sur une machine virtuelle avec une adresse privée et une adresse publique mappée, ajoutez un mapping statique sous ice4j.harvest.mapping dans /etc/jitsi/videobridge/jvb.conf, puis redémarrez jitsi-videobridge2. Exécutez sudo tcpdump -ni any udp port 10000 pendant qu’un participant rejoint la réunion pour déterminer lequel des deux chemins est en cause. L’absence totale de paquets signifie que le blocage se situe en amont du système d’exploitation.

Quelle bande passante utilise un appel vidéo à 30 participants ?

Dans le pire des cas, lorsque tout le monde active sa caméra et que le SFU transmet une couche en pleine qualité à chaque participant, environ 1,044 Mbps sortent du serveur, soit 469.8 Go par heure. Il s’agit d’un calcul basé sur N fois (N moins 1) flux à 1.2 Mbps chacun, et non d’une mesure de votre installation. Le simulcast et le paramètre last-N réduisent fortement cette consommation en utilisation normale, car la plupart des participants ne sont pas affichés à l’écran à un instant donné. Dimensionnez tout de même l’installation pour un volume proche du pire cas. Le pire cas correspond à une réunion générale où tout le monde active sa caméra en même temps.

Puis-je exécuter Jitsi Meet sur un VPS de 1 GB ?

L’installation fonctionnera, et un appel à deux participants fonctionnera également. Jitsi utilise en effet le mode peer-to-peer avec exactement deux participants et n’utilise alors pas du tout le videobridge. Ce serveur ne convient toutefois pas à des appels de groupe. Prosody, le videobridge et le runtime Java ont tous besoin de mémoire. Le guide recommande lui-même 8 GB pour un déploiement sérieux. Le calcul de bande passante atteindra par ailleurs ses limites avant la mémoire. Si vous disposez uniquement d’un serveur de 1 GB, Galène est mieux adapté que Jitsi à cette capacité.

Ai-je toujours besoin d’un serveur TURN si mon VPS possède une adresse IP publique ?

Oui. Le problème résolu par TURN se trouve à l’autre extrémité de l’appel. Un participant sur un réseau d’entreprise qui bloque les connexions UDP sortantes, ou derrière un NAT de niveau opérateur qui attribue un port source différent selon la destination, ne peut pas établir de chemin média direct, quelle que soit la visibilité publique de l’adresse de votre serveur. TURN sur TCP 443 ou 5349 leur fournit un relais qui ressemble à du trafic web ordinaire pour leur firewall. L’installation du paquet Jitsi configure coturn de cette manière par défaut. C’est pourquoi les règles de firewall documentées autorisent UDP 3478 et TCP 5349.

Pourquoi BigBlueButton nécessite-t-il beaucoup plus de matériel que Jitsi Meet ?

Parce qu’il fait bien plus que transmettre de la vidéo. La configuration de production publiée requiert 16 GB de RAM et 8 cœurs, contre 8 GB et 4 cœurs dans le guide de Jitsi. BigBlueButton exécute une stack complète de conférence audio, un tableau blanc partagé, une couche de présentation, un pipeline d’enregistrement et de post-traitement, ainsi qu’une interface web avec des comptes utilisateur, le tout sur la même machine. Le projet impose également des contraintes précises sur la plateforme : en août 2026, l’installation prise en charge est la version 3.0 sur Ubuntu 22.04. Les deux ensembles de chiffres proviennent de la documentation de leurs projets respectifs. Ils constituent des points de départ, et non des mesures de votre charge de travail.