Jitsi Meet ou BigBlueButton : choisir pour une classe virtuelle

Pour une réunion vidéo simple, Jitsi Meet est le choix le plus direct. Pour un cours animé avec présentations, sondages et travail en groupes, BigBlueButton réunit des fonctions conçues pour l’enseignement. Le choix engage aussi des ressources différentes lorsque la séance doit être enregistrée.

Deux scénarios hypothétiques permettent de préciser la décision : une réunion de vingt personnes et une classe enregistrée de deux cents personnes. Leur taille ne suffit pas à prédire la charge. Le nombre de caméras actives, les flux reçus par chaque participant et le travail effectué après le direct comptent autant que le nombre de connexions.

Réunion de vingt personnes : partir de l’usage réel

Dans la réunion envisagée, les participants parlent, quelques-uns ouvrent leur caméra et une personne partage ponctuellement son écran. Jitsi Meet répond à cette forme d’échange sans imposer à l’organisateur de structurer la séance comme un cours. Une association qui réunit son équipe ou un établissement qui tient une réunion pédagogique peut ainsi choisir l’outil en fonction de la conversation attendue, plutôt que de fonctions qui resteront inutilisées.

La documentation d’hébergement de Jitsi Meet indique que quatre cœurs dédiés peuvent suffire pour un serveur de base et que huit gigaoctets de mémoire sont généralement conseillés ; elle place la qualité de la liaison réseau au premier rang des besoins. Ces indications sont des repères d’installation, pas une capacité garantie pour la réunion décrite. Le débit dépend notamment des résolutions choisies et du nombre de vidéos transmises simultanément.

BigBlueButton peut également accueillir une discussion. Son intérêt apparaît lorsque l’animateur veut déposer un support, annoter une présentation, interroger le groupe ou répartir les participants dans des salles distinctes. Pour une réunion essentiellement orale, ces possibilités ne compensent pas automatiquement les exigences supplémentaires de l’hébergement : c’est l’activité prévue qui donne leur valeur aux fonctions pédagogiques.

Classe de deux cents personnes : distinguer présence et activité

Imaginons maintenant un enseignant qui présente un support, lance des sondages, organise un travail en groupes et souhaite rendre la séance consultable ensuite. BigBlueButton rassemble ces opérations dans la classe virtuelle. L’enseignant peut conduire les interactions autour de la présentation, tandis que l’établissement doit prévoir leur capture et leur restitution après le cours.

Les deux cents personnes de ce scénario sont des personnes connectées, pas autant de caméras qui émettent en permanence. Si la plupart regardent une présentation et que quelques intervenants prennent la parole, la circulation des médias diffère d’une discussion où chaque élève diffuse sa vidéo. Les salles de groupes changent encore la répartition des échanges. Décrire ces comportements est indispensable avant d’attribuer une capacité à un serveur.

Le même raisonnement vaut pour les participants. Suivre des diapositives avec une connexion limitée, recevoir plusieurs vidéos ou partager son propre écran ne sollicite pas leur réseau de la même façon. Un cours fluide pour l’enseignant peut rester difficile à suivre pour certains élèves si la diffusion demande trop de débit à leur connexion.

Pourquoi le test de Jitsi ne donne pas une taille de classe

L’évaluation de performance publiée par Jitsi rapporte 1 056 couples de flux audio et vidéo, un débit moyen de 550,4 Mbit/s et 20,3 % d’utilisation du processeur pour une installation Jitsi Meet inchangée sur le serveur Xeon à quatre cœurs décrit. Le test portait sur une seule conférence alimentée principalement par des générateurs de charge ; chaque flux était transmis aux autres points de connexion.

Les 1 056 flux ne représentent donc pas 1 056 élèves. Plusieurs flux sortants peuvent provenir d’un même participant lorsqu’une vidéo est distribuée à plusieurs destinataires. Le protocole mesure la capacité de transfert de cette configuration et de cette manière de diffuser les médias. Il ne mesure ni un cours avec sondages et salles de groupes, ni la production d’un enregistrement après la séance.

Le test éclaire néanmoins une décision utile : compter seulement les personnes masque la quantité de vidéo effectivement transportée. Pour comparer les deux scénarios, il faut préciser qui émet, combien de vidéos chacun reçoit et pendant quelle partie de la séance. Un chiffre de performance devient pertinent lorsqu’il décrit une charge proche de l’usage envisagé.

Le serveur doit aussi absorber l’enregistrement

Pour BigBlueButton 4.0, les prérequis officiels de production recommandent un serveur dédié sous Ubuntu 24.04 en 64 bits avec un noyau Linux 6.x, huit cœurs, seize gigaoctets de mémoire, au moins 250 Mbit/s symétriques et 500 gigaoctets d’espace libre pour les enregistrements. Si l’enregistrement est désactivé, la valeur indiquée pour le disque est de 50 gigaoctets. Il s’agit de minimums recommandés pour installer le service en production, sans garantie qu’une classe particulière de deux cents personnes tiendra sur une seule machine.

Chez Jitsi Meet, l’enregistrement fait intervenir Jibri, qui capture et encode la réunion. L’architecture demande une instance Jibri pour chaque réunion enregistrée simultanément. Ce travail consomme du processeur, de la mémoire et du disque ; l’héberger sur le serveur de réunion peut dégrader la visioconférence. Une installation légère pour des échanges non enregistrés ne décrit donc plus toute l’infrastructure dès que plusieurs séances doivent être conservées.

Pour l’établissement, le coût technique ne se réduit pas au nombre de cœurs affiché par l’hébergeur. Il faut réserver du débit pendant le direct, de l’espace pour les médias et de la capacité pour fabriquer les enregistrements. La configuration minimale constitue un point de départ ; la charge du cours dépend de la combinaison précise des webcams, du partage d’écran, des groupes et des séances enregistrées en parallèle.

Après le direct : que pourra-t-on revoir ?

Avec Jibri, le résultat recherché est principalement une vidéo de ce qui a été affiché pendant la réunion. Cette forme convient lorsqu’une association veut conserver une intervention ou lorsqu’un cours ne demande qu’une captation de l’appel. Elle suppose de prévoir l’encodage et le stockage associés à chaque séance enregistrée.

La chaîne d’enregistrement de BigBlueButton conserve les médias et les événements de la séance, archive les éléments bruts, puis les traite et les publie pour la lecture. Elle peut restituer notamment les diapositives, les annotations, le son, les webcams, le partage d’écran, les échanges et les résultats des sondages. Cette publication demande un traitement après la fin du cours : la fermeture de la classe ne rend pas immédiatement l’enregistrement disponible.

Dans le format de restitution par présentation, le résultat n’est pas par défaut un fichier vidéo unique ; un traitement vidéo distinct peut produire ce type de fichier. L’établissement doit donc choisir ce qu’il veut conserver et organiser le stockage des données brutes et des versions publiées. Pour la réunion simple, Jitsi Meet garde l’avantage de la sobriété fonctionnelle. Pour la classe qui doit préserver le déroulement des activités, BigBlueButton répond plus directement au besoin, avec une exploitation plus exigeante.