Vuisio vs BigBlueButton : le comparatif complet 2026

Vuisio et BigBlueButton sont tous les deux open source, fonctionnent dans le navigateur et s’intègrent à Moodle. La comparaison s’arrête là. Sur l’architecture, la performance, la souveraineté et le coût réel d’exploitation, les deux solutions jouent dans des catégories différentes. Ce comparatif détaille chaque critère, sources à l’appui.

Qu’est-ce qui rapproche Vuisio et BigBlueButton ?

Les deux solutions partagent un socle commun qui explique pourquoi la comparaison revient souvent.

Vuisio comme BigBlueButton sont des logiciels libres : BigBlueButton est publié sous licence LGPL 3.0 (FAQ officielle BigBlueButton), Vuisio sous AGPL 3.0 pour le cœur (docs.vuis.io). Les deux fonctionnent entièrement dans le navigateur via WebRTC, sans installation côté utilisateur. Et les deux s’intègrent à Moodle : BigBlueButton y est intégré nativement depuis la version 4.0 (Moodle), et Vuisio expose une API compatible via son module compat-api (docs.vuis.io).

C’est sur tout le reste que les chemins divergent.

En quoi les architectures sont-elles différentes ?

L’architecture est la différence la plus structurante. Elle explique à elle seule les écarts de performance, de consommation et de complexité d’administration.

BigBlueButton : une dizaine de composants imbriqués

La page Architecture de la documentation officielle détaille la pile : NGINX (reverse proxy), FreeSWITCH (serveur audio en mode MCU, qui décompresse et mixe les flux), Kurento Media Server (serveur vidéo en mode SFU), Redis (bus de messages), MongoDB (état des réunions), Node.js/Meteor.js (client HTML5 et serveur), Akka (gestion d’état, Scala), bbb-webrtc-sfu (pont WebRTC vers Kurento), Etherpad (notes partagées), et LibreOffice (conversion de documents, exécuté dans un conteneur Docker). La documentation de customisation recommande trois instances parallèles de Kurento pour la stabilité.

Un bbb-conf --status affiche plus de dix services actifs. Si l’un tombe, le service est dégradé ou interrompu.

Vuisio : un SFU Rust et un orchestrateur

Vuisio se décompose en deux briques principales (docs.vuis.io) :

Le SFU (core/server/) est un relais WebRTC écrit en Rust. Il reçoit les paquets audio et vidéo et les redistribue sans jamais les décoder ni les réencoder (« relai RTP brut »). Chaque thread dispose de son propre socket UDP, et les participants sont répartis par hachage de (salle, client) pour paralléliser le traitement. Les files inter-threads sont bornées avec un budget de temps pour éviter qu’une salle chargée ne bloque les autres.

L’orchestrateur (bin/vuisio/) démarre le SFU, expose un registre de modules via gRPC (port 50050) et branche les hooks selon les capacités déclarées par chaque module. Le SFU expose quatre hooks génériques (on_command, on_media_out, on_media_transform, on_lifecycle) sans aucune connaissance des modules. C’est la « règle d’or » du projet : le cœur reste autonome et ne dépend jamais du SDK ni des modules.

Critère	BigBlueButton	Vuisio
Composants serveur	~12 (nginx, FreeSWITCH, Kurento, Redis, MongoDB, Meteor, Akka, bbb-webrtc-sfu, Etherpad, LibreOffice, bbb-fsesl-akka, bbb-apps-akka)	2 (SFU + orchestrateur) + modules optionnels (lobby, whiteboard, compat-api, anonymizer)
Langages serveur	Java, JavaScript/Node.js, Scala (Akka), C/C++ (FreeSWITCH, Kurento), Ruby (Greenlight)	Rust (cœur), Next.js (client web)
Traitement audio	MCU (FreeSWITCH décompresse et mixe)	SFU (relai brut, zéro mixage)
Traitement vidéo	SFU via Kurento (traitement en mémoire)	SFU (relai RTP brut, zéro décodage)
Communication interne	Redis pub/sub, MongoDB, websockets Meteor	gRPC (Protobuf), files bornées inter-threads
Extension	Modification du code source	SDK Rust + hooks, modules déclaratifs via gRPC

Quelles performances pour quel matériel ?

Les conséquences de l’architecture se mesurent directement en capacité et en coûts.

Critère	BigBlueButton	Vuisio
OS serveur	Ubuntu 22.04 uniquement (doc d’installation BBB)	Debian 11+ ou Ubuntu 22.04+ (docs.vuis.io)
RAM minimum production	16 Go (doc d’installation BBB)	Quelques Go (un Raspberry Pi à 1 Go suffit pour 10 utilisateurs)
CPU minimum production	8 cœurs, bare metal recommandé (doc d’installation BBB)	2 cœurs suffisent, VM ou VPS acceptés
Stockage minimum	500 Go pour les enregistrements (doc d’installation BBB)	Proportionnel à l’usage (pas de conversion documentaire)
Bande passante serveur	250 Mbit/s symétrique minimum, 1 Gbit/s recommandé (FAQ BBB)	Proportionnelle au nombre de participants
Capacité par serveur	~200 participants simultanés (FAQ BBB)	450 à 500 participants sur 6 vCPU / 24 Go RAM
Charge CPU du relai média	FreeSWITCH : 4,5 à 7 threads ; Kurento : 1 à 2,5 threads ; Meteor : 2 threads (retour Octopuce, test 167 utilisateurs)	« Quelques pour cent du processeur » pour le relai média (docs.vuis.io)
Seuil CPU critique	70 %, au-delà l’audio se dégrade (FAQ BBB)	Mémoire stable sous charge soutenue, pas de seuil documenté
Montée en charge	Cluster Scalelite (répartiteur multi-serveurs)	Architecture multi-thread native, parallélisation par hachage (salle, client)

Le harnais de test de charge de Vuisio est une contribution à part entière (docs.vuis.io) : des bots de rejeu utilisent la même bibliothèque str0m que le serveur (indiscernables d’un vrai client au niveau réseau), et de vrais navigateurs Chromium mesurent la qualité réellement vécue (images par seconde, gigue, gels, perte audio). La méthodologie est volontairement conservatrice : les bots émettent à débit constant sans régulation, ce qui impose au serveur une charge supérieure ou égale à celle de vrais clients.

Qui protège le mieux les données ?

Critère	BigBlueButton	Vuisio
Éditeur	Blindside Networks, Canada (Wikipedia)	Geezot, France
Hébergement	Auto-hébergement uniquement	Cloud souverain France ou auto-hébergement on premise
Compte utilisateur requis	Oui (via Greenlight ou LMS)	Non. Un participant est un identifiant numérique aléatoire, le temps de la session (docs.vuis.io)
Cookies	Oui (session Meteor, Greenlight)	Aucun cookie imposé par le cœur (docs.vuis.io)
Pistage comportemental	Logs serveur, Learning Dashboard (temps de parole, participation)	Aucun pistage. La seule empreinte est le certificat DTLS (vérification crypto standard) (docs.vuis.io)
Chiffrement en transit	Oui (DTLS-SRTP via WebRTC)	Oui (DTLS-SRTP via WebRTC)
Chiffrement des données au repos	Non documenté	AES-256-GCM, clé fournie par l’exploitant (docs.vuis.io)
Persistance des données	MongoDB + Redis + enregistrements sur disque	Optionnelle (Redis). Sans Redis, les salles sont éphémères et vivent en mémoire uniquement (docs.vuis.io)
Nettoyage automatique	Enregistrements supprimés après 14 jours par défaut (docs BBB)	Salle vidée = données effacées à la fermeture (docs.vuis.io)
Certificat TLS	Let’s Encrypt (américain)	Actalis (européen, italien) par défaut, ou Let’s Encrypt, ou certificat propre (docs.vuis.io)
STUN par défaut	Google (stun.l.google.com)	Nextcloud européen (stun.nextcloud.com:443) (docs.vuis.io)

Deux détails révèlent la profondeur de la démarche souveraine de Vuisio. Le serveur STUN par défaut est européen (Nextcloud), là où BigBlueButton pointe vers Google. Et l’autorité de certification proposée par défaut est Actalis (italienne), pas Let’s Encrypt (américain). Ce sont des choix qui ne changent rien à l’usage, mais tout à la chaîne de confiance.

Comment se passe la migration depuis Moodle ?

Vuisio implémente le protocole API de BigBlueButton via son module compat-api (docs.vuis.io). Toute plateforme configurée pour BBB peut basculer vers Vuisio sans modification de l’intégration.

En pratique :

1. Déployer Vuisio (cloud souverain ou vuisio-installer sur votre serveur).
2. Installer le module compat-api : vuisio module add compat-api.
3. Dans Moodle (Administration > Plugins > BigBlueButton), remplacer l’URL et la clé secrète par celles de Vuisio.
4. Tester. Les salles, rôles (enseignant/élève) et liens d’accès fonctionnent comme avant.

Côté BigBlueButton, la montée de version elle-même peut être un chantier : le passage de BBB 2.x à 3.0 impose de repartir d’un serveur Ubuntu 22.04 neuf et de migrer les enregistrements manuellement (doc d’installation BBB). Côté Vuisio, vuisio upgrade met à jour de façon atomique avec retour arrière automatique en cas d’échec (docs.vuis.io).

Combien ça coûte vraiment ?

Critère	BigBlueButton	Vuisio
Licence logicielle	Gratuite	Gratuite (cœur AGPL 3.0)
Infrastructure pour 200 utilisateurs	Serveur dédié ~70 à 140 USD/mois (estimation Webhostingzone)	Serveur bien plus modeste, ou cloud souverain inclus
Cloud clé en main	Non disponible	Gratuit (réunions 1h, participants illimités) ou Pro 7,90 €/mois par animateur
Facturation	Par serveur (infrastructure à votre charge)	Par animateur (pas par participant)
Administration système	Lourde (12 services, Ubuntu uniquement, mises à jour manuelles)	Légère (CLI vuisio, mises à jour atomiques, vuisio doctor)
Montée en charge au-delà de 200	Cluster Scalelite (infrastructure supplémentaire)	Architecture multi-thread native

En résumé

BigBlueButton a ouvert la voie de la visioconférence open source pour l’éducation, et c’est un projet respectable avec une large communauté. Mais son architecture à douze composants, ses exigences matérielles élevées et l’absence de chiffrement des données au repos le placent dans une autre époque face aux besoins de 2026. Ce face-à-face n’est qu’un point de départ : notre comparatif des alternatives à BigBlueButton situe Vuisio parmi les autres options du marché.

Vuisio reprend ce qui fait la force de BigBlueButton (open source, navigateur, Moodle) et repense tout le reste : un SFU Rust minimaliste qui tient sur un Raspberry Pi, du chiffrement AES-256-GCM au repos, un cloud souverain hébergé en France avec STUN européen et certificat TLS européen par défaut, et une migration depuis BBB qui se fait en installant un module et en changeant une URL. Le tout sans compte utilisateur, sans cookie, et sans facturation par participant.

Si vous utilisez BigBlueButton aujourd’hui, le plus simple est de tester Vuisio gratuitement : la migration est réversible, et vos utilisateurs ne verront pas la différence. Sauf peut-être la fluidité.