Toute comparaison de logiciel de visioconférence open source est la même liste de fonctionnalités. Salles, partage d'écran, chat, tableau blanc, enregistrement. Elles ont toutes cela.
Rien de tout cela ne tranche.
Ce qui tranche, c'est la façon dont le logiciel fait circuler la vidéo entre les gens, et vous vous engagez là-dessus dès que vous choisissez une plateforme. Si vous vous trompez, aucune configuration ultérieure ne vous sauvera. Cet article est donc écrit du côté serveur : sept plateformes que vous pouvez héberger vous-même, ce que chacune fait à votre facture de bande passante, quelle part d'une machine elle exige pour elle seule, et où chacune atteint ses limites.
L'essentiel en bref
Aller à une section
Pourquoi l'architecture décide de tout
Il y a trois façons d'acheminer la vidéo d'une personne vers plusieurs. Tout ce qui suit est une variante de l'une d'elles.
Le peer to peer relie chacun directement à tous les autres. Trois personnes, trois connexions. Huit personnes, vingt-huit connexions, et chacun envoie maintenant sept copies de sa propre caméra. Excellent pour un appel en tête à tête. Fini vers quatre participants sur une connexion domestique normale. Jami est le seul outil de la liste qui fonctionne ainsi volontairement.
Un SFU, une unité de transfert sélectif (selective forwarding unit), place un serveur au milieu. Vous envoyez un flux, le serveur le copie vers tous les autres, et rien n'est décodé ni réencodé en chemin.
Ce dernier point est toute l'astuce. Transmettre coûte peu de CPU et beaucoup de bande passante : une instance modeste porte donc une salle plus grande qu'on ne le croirait, pendant que votre trafic sortant grossit en silence. Jitsi Videobridge, mediasoup, Janus et LiveKit sont tous des SFU, et à eux quatre ils forment le moteur de presque tout ce dont parle cet article.
Un MCU décode chaque flux entrant, les mélange en une seule image et renvoie un unique flux. Doux pour la bande passante des clients, brutal pour le CPU du serveur. Il est largement tombé en désuétude pour la conférence généraliste, et rien ici n'en utilise un par défaut.
C'est pourquoi « combien de personnes cela peut-il gérer » est une question sur le serveur média, pas sur le logo. Notre explication de l'architecture WebRTC creuse sérieusement les compromis, et comment Jitsi est construit montre à quoi ressemble un déploiement SFU une fois qu'il est réel.
Les sept serveurs
Jitsi Meet
Apache 2.0, et ce qui se rapproche le plus d'une réponse par défaut dans ce domaine.
Ce sont quatre services plutôt qu'un : un frontend web, Prosody pour la signalisation XMPP, Jicofo pour gérer les conférences, et le videobridge qui fait réellement circuler les flux média. Les paquets Debian vous mettent en route sur Ubuntu en une quinzaine de minutes, et le guide de démarrage rapide du manuel Jitsi est la version à suivre. La pile Docker Compose est la meilleure voie si vous préférez ne pas céder tout l'hôte.
Ses points forts : aucun compte requis, fonctionne dans n'importe quel navigateur et s'intègre proprement à d'autres produits grâce à l'API iframe. Son point faible : un videobridge unique n'est pas un plan de montée en charge. Par défaut, Jicofo déplace une conférence vers un autre bridge autour de quatre-vingts participants, donc une très grande réunion signifie plusieurs bridges avec des relais entre eux. Nous avons détaillé comment atteindre mille utilisateurs et le même problème sur Kubernetes.
Une chose à savoir avant votre première installation. Les flux média sortent sur UDP 10000, et ce port doit atteindre directement le bridge. Quand la vidéo n'apparaît pas, vérifiez cela d'abord, avant de lire les journaux ou de modifier la configuration. C'est la raison la plus courante pour laquelle une installation toute neuve a du son pour deux personnes et du silence pour trois.
BigBlueButton
LGPL, et conçu pour enseigner plutôt que pour tenir des réunions. Ce n'est pas du positionnement, cela se voit dans le produit : un tableau blanc partagé sur des diapositives importées, des salles de sous-groupes, des sondages, des notes partagées, une file pour lever la main, et un enregistrement qui rejoue la session au lieu de vous remettre un fichier vidéo. Il parle LTI, donc Moodle et Canvas s'y branchent directement. mediasoup s'occupe des flux média, et la documentation de BigBlueButton est d'une qualité inhabituelle pour un projet de cette taille. Si un serveur ne suffit plus, nous traitons la configuration multiserveur dans faire évoluer BigBlueButton sur AWS.
L'installation tient en un seul script, et c'est réellement le premier démarrage le plus facile de tout ce qui figure ici.
Avec une condition. Il attend un serveur Ubuntu vierge et dédié, et le projet l'énonce comme une exigence, non comme une suggestion. Prévoyez de lui donner toute la machine.
Vous voulez le comparer directement à Jitsi ? Nous l'avons fait dans une comparaison séparée.
Nextcloud Talk
AGPL, intégré à Nextcloud, et c'est tout son argument. Les appels se trouvent à côté de vos fichiers : vous pouvez en lancer un depuis un document et partager ce document dans l'appel sans quitter la page. Si votre organisation utilise déjà Nextcloud, ajouter Talk est presque gratuit.
La montée en charge est là où l'on se fait piéger. Par défaut, Talk utilise la signalisation propre à Nextcloud, qui convient pour quelques personnes et pas davantage. Au-delà, il faut le High Performance Backend, un serveur de signalisation autonome avec Janus derrière. Il est open source et la documentation d'administration de Talk le couvre. C'est aussi un second déploiement avec ses propres exigences, et presque toutes les plaintes sur la qualité des appels de Talk remontent à quelqu'un qui ne l'a jamais installé.
Vous devez d'abord monter Nextcloud lui-même ? Notre guide de déploiement de Nextcloud couvre cette moitié.
plugNmeet
Open source, construit sur LiveKit et destiné à un travail différent de tout le reste de cette liste. Il part du principe que vous avez déjà une application et que vous voulez de la conférence à l'intérieur. L'API passe d'abord, et l'interface n'est qu'un consommateur parmi d'autres de cette API, ce qui est l'inverse de la conception des autres. Des intégrations Moodle et WordPress existent, et la documentation de plugNmeet part de l'API plutôt que de l'interface, ce qui vous dit quel genre de projet c'est.
Le bon choix quand vous placez des appels dans un produit qui vous appartient et que vous voulez piloter salles, permissions et cycle de vie depuis votre propre backend. Le mauvais si ce que vous voulez vraiment, c'est une URL à envoyer aux gens.
Jami
GPL, maintenu par Savoir-faire Linux, et la seule véritable entrée peer to peer ici.
Il n'y a pas de serveur. Les comptes sont des identités cryptographiques qui vivent sur l'appareil, les pairs se trouvent via une table de hachage distribuée, et les flux média vont directement d'un participant à l'autre. Rien de ce que dit quiconque ne passe par une infrastructure qu'un tiers exploite, ce qui est une affirmation différente de « nous l'hébergeons nous-mêmes » et mérite d'être traitée comme telle.
Le coût, c'est l'échelle et la prévisibilité. La vidéo de groupe fonctionne, mais le débit montant de chaque participant est un plafond, et la connectivité dépend de la réussite du franchissement de NAT, sans aucun serveur à vous pour prendre le relais. Linux, Windows, macOS, Android, iOS, tout est couvert dans la documentation de Jami. Utilisez-le pour de petits groupes où l'absence de serveur est l'exigence réelle, et non une jolie phrase de brochure.
Apache OpenMeetings
Apache 2.0, Java, et le vétéran du groupe. Il offre plus de surface que la plupart : tableau blanc, gestion de fichiers, enregistrement, sondages, un calendrier de planification, LDAP. Kurento s'occupe des flux média, et tout part du site d'Apache OpenMeetings.
Cela dit, le développement avance lentement comparé à Jitsi ou à BigBlueButton, et la pile est plus lourde à monter, parce que vous gérez Java, Kurento et une base de données au lieu de lancer un seul installateur. Il mérite sa place si vous voulez précisément la planification et la gestion de documents intégrées, ou si votre équipe exploite déjà des services Java et que c'est un terrain familier plutôt qu'une nouveauté à apprendre.
Element et Matrix
Element est un client pour Matrix, un protocole ouvert et fédéré de communication en temps réel : auto-héberger ici veut dire exploiter un serveur domestique (homeserver) plutôt qu'un produit de conférence. Vous obtenez plus que de la vidéo : messagerie chiffrée, espaces, fédération avec d'autres serveurs Matrix et appels construits sur un SFU LiveKit. Commencez par la documentation de Matrix plutôt que par Element, car le protocole est ce à quoi vous vous engagez.
C'est le déploiement le plus lourd de l'article. Mauvais outil si la visioconférence est tout ce qu'il vous faut. Bon outil si vous remplacez Slack et Zoom dans le même projet et que la messagerie est l'essentiel.
À noter aussi : Element a cessé de s'appeler Riot en 2020. Toute documentation qui emploie encore l'ancien nom a six ans de retard, vérifiez-la donc par rapport à la documentation actuelle avant de la suivre.
Comparaison côte à côte
| Plateforme | Licence | Architecture média | Mode d'installation | Taille de salle confortable | Meilleur usage |
|---|---|---|---|---|---|
| Jitsi Meet | Apache 2.0 | SFU (Jitsi Videobridge) | Paquets Debian ou Docker Compose | Des dizaines par bridge, des centaines avec plusieurs | Salles généralistes, intégration |
| BigBlueButton | LGPL | SFU (mediasoup) | Script d'installation, serveur dédié | Taille d'une classe, des dizaines de caméras actives | Enseignement et formation |
| Nextcloud Talk | AGPL | SFU (Janus, via le HPB) | Application Nextcloud, plus HPB pour la montée en charge | Petite sans HPB, des dizaines avec | Équipes déjà sur Nextcloud |
| plugNmeet | Open source | SFU (LiveKit) | Docker, piloté par vos propres appels d'API | Des dizaines, LiveKit monte plus haut | Conférence à l'intérieur de votre propre produit |
| Jami | GPL | Peer to peer, sans serveur | Applications de bureau et mobiles uniquement | Une poignée | Petits groupes, confidentialité maximale |
| Apache OpenMeetings | Apache 2.0 | Serveur média Kurento | Java, Kurento et une base de données | Petite à moyenne | Planification et documents intégrés |
| Element / Matrix | Apache 2.0 | SFU (LiveKit) sur Matrix | Homeserver, client et SFU | Des dizaines | Messagerie d'abord, appels inclus |
Ce que coûte réellement l'exploitation d'un logiciel de visioconférence open source
La licence est gratuite. Le serveur ne l'est pas, et la facture n'a pas la forme à laquelle la plupart des gens s'attendent.
La bande passante s'épuise avant le CPU. Un SFU transmet au lieu de transcoder : chaque participant supplémentaire vous coûte donc du trafic sortant bien plus vite que du processeur. Dix personnes avec la caméra allumée signifient que le serveur reçoit dix flux et en renvoie quatre-vingt-dix. Cette courbe est quadratique, et c'est pourquoi une salle de cinquante n'est pas cinq fois une salle de dix. Le simulcast et la transmission des seules personnes actuellement regardées atténuent l'effet. Ni l'un ni l'autre n'en change la forme. Pour chiffrer vos propres salles, essayez le calculateur de bande passante pour appels vidéo.
Il vous faut aussi du TURN. Une partie de vos utilisateurs se trouve derrière un NAT symétrique ou un pare-feu d'entreprise qui bloque les ports UDP dont WebRTC a besoin, et pour eux l'appel ne se dégrade pas, il échoue purement et simplement. Coturn est la réponse standard. C'est un service distinct, et les flux relayés le traversent dans les deux sens : il a donc un coût de bande passante réel qui lui est propre. Les concepts sont dans STUN, TURN et ICE, la mise en place dans configurer un serveur TURN pour Jitsi Meet, et une fois qu'il tourne, le testeur ICE WebRTC montre s'il fournit réellement des candidats de relais.
Viennent ensuite les ports, là où les déploiements meurent vraiment. La signalisation est du HTTPS ordinaire sur le port 443 et ne pose de problème à personne. Les flux média veulent de l'UDP et ne passeront pas par un reverse proxy classique. Ce décalage est derrière la plupart des signalements du type « ça marche à deux, ça casse à trois » que vous trouverez dans les forums, et quels ports Jitsi Meet doit avoir ouverts est à lire avant l'installation plutôt qu'après.
Pour les tailles d'instance et les chiffres mensuels selon la taille de salle, nous les avons détaillés à part dans ce que coûte réellement l'auto-hébergement de Jitsi Meet.
Si vous construisez au lieu de déployer
Beaucoup de gens qui cherchent un logiciel de serveur de visioconférence ne veulent pas du tout d'une plateforme finie. Ils veulent la couche média et comptent construire eux-mêmes l'interface. Aucune des sept ci-dessus n'est la bonne réponse pour cela, et c'est un niveau plus bas qu'il faut regarder :
- LiveKit. SFU sous licence Apache 2.0 avec des SDK clients pour le web, le mobile et les langages serveur. C'est le backend média à l'intérieur de plugNmeet et d'Element Call, ce qui en dit plus long sur sa maturité que n'importe quelle page de fonctionnalités.
- mediasoup. Une bibliothèque SFU Node.js plutôt qu'une application. Bas niveau, bien documentée, et ce sur quoi tourne BigBlueButton.
- Janus. Construit autour de plugins, il gère donc les passerelles SIP et le streaming en plus de la conférence. C'est le SFU derrière le backend haute performance de Nextcloud Talk.
- Jitsi Videobridge seul, sans le reste de la pile, si vous voulez garder le bridge et écrire votre propre signalisation autour.
Nous les avons comparés en détail dans les serveurs média WebRTC open source, qui est le meilleur point de départ si vous construisez au lieu de déployer.
Faire son choix
Quatre questions vous y mènent plus vite que n'importe quelle matrice de fonctionnalités.
Quelle est la taille de la plus grande salle que vous utiliserez réellement ? Pas la plus grande que vous puissiez imaginer. En dessous de cinq personnes, le peer to peer est viable et Jami devient intéressant. Jusqu'à quelques dizaines, n'importe quel SFU d'ici fait l'affaire. Au-delà de cent, vous concevez un déploiement multibridge, et cela désigne Jitsi, qui a le chemin le plus éprouvé pour cela.
Est-ce une réunion ou un cours ? Si votre réponse comprend des diapositives, des mains levées, des sous-groupes et des présences, BigBlueButton a été conçu exactement pour cela et tout le reste en est une imitation.
Doit-il vivre à l'intérieur d'autre chose ? L'intégrer à votre propre produit désigne plugNmeet ou l'API iframe de Jitsi. Ajouter des appels à un Nextcloud existant désigne Talk. Remplacer en même temps votre plateforme de chat désigne Matrix.
Et puis celle que tout le monde saute. Qui fait tourner tout cela le jour où ça va mal ? L'auto-hébergement n'est pas une installation, ce sont les renouvellements TLS, les mises à niveau de version, la capacité quand la réunion générale de toute l'entreprise tombe sur un seul bridge, et quelqu'un de joignable quand un appel tombe en plein moment important. Si personne ne s'en charge, payez une formule hébergée. C'est une décision d'ingénierie légitime, pas une capitulation.
Pour la plupart des équipes qui posent la question générale, la réponse est Jitsi Meet. Licence permissive, un chemin de déploiement éprouvé, une sortie quand un seul bridge ne suffit plus, et bien plus de savoir-faire opérationnel mis par écrit que pour tout le reste ici, pour le moment où quelque chose casse à une heure inopportune. Les autres gagnent sur des cas particuliers. Ces cas particuliers sont réels. Ils restent des cas particuliers.
Questions fréquentes
Qu'est-ce qu'un serveur de visioconférence open source ?
C'est la partie serveur d'un système d'appels vidéo que vous faites tourner vous-même au lieu de le louer à Zoom ou à Google. En pratique, c'est un serveur média qui reçoit l'audio et la vidéo de chaque participant et les renvoie à tous les autres, plus une couche de signalisation qui gère qui se trouve dans quelle salle. Comme le code source est ouvert, vous pouvez le lire, le modifier et l'exécuter sur votre propre matériel, sans licence par utilisateur.
Combien de participants un serveur de visioconférence auto-hébergé peut-il gérer ?
Cela dépend bien plus de l'architecture média que de la marque du logiciel. Un outil peer to peer comme Jami s'en sort bien avec quelques personnes. Un SFU tel que Jitsi Videobridge ou mediasoup gère des dizaines de participants par salle sur une seule machine, et par défaut Jicofo déplace une conférence Jitsi vers un autre bridge autour de 80 participants. Au-delà de quelques centaines, vous faites tourner plusieurs bridges avec des relais entre eux, et c'est une question de conception du déploiement, pas un réglage.
Ai-je aussi besoin d'un serveur TURN ?
Presque toujours, oui. Une minorité de vos utilisateurs se trouvera derrière un NAT symétrique ou un pare-feu d'entreprise qui bloque les ports UDP dont WebRTC a besoin, et pour eux le flux média doit être relayé par TURN, faute de quoi l'appel ne s'établit tout simplement pas. Coturn est le choix standard, et c'est un service distinct que vous hébergez à côté du serveur de visioconférence.
La visioconférence auto-hébergée est-elle vraiment moins chère que Zoom ?
Elle supprime les licences par utilisateur, et c'est de là que vient l'économie, mais elle les remplace par le coût du serveur, celui de la bande passante et votre propre temps d'exploitation. Pour une petite équipe, le calcul penche souvent en faveur d'une formule hébergée. Pour quelques centaines d'utilisateurs réguliers, ou pour qui doit garder les flux média sur sa propre infrastructure pour des raisons de conformité, l'auto-hébergement l'emporte généralement.
Quel serveur de visioconférence open source est le plus facile à installer ?
BigBlueButton, si vous acceptez sa contrainte. Son script d'installation met en place toute la pile en une seule passe, mais il attend un serveur dédié et vierge, et n'aime pas partager. Jitsi Meet est le plus facile à intégrer dans un environnement existant, car avec Docker Compose vous lancez les quatre services sans prendre possession de l'hôte.
Puis-je en intégrer un dans ma propre application ?
Oui. Jitsi Meet dispose d'une API iframe qui place une conférence complète dans une page avec quelques lignes de JavaScript, et plugNmeet est conçu dès le départ pour être piloté par une application externe via son API. Si vous voulez construire vous-même l'interface plutôt que d'intégrer celle de quelqu'un d'autre, c'est plutôt une bibliothèque SFU comme LiveKit ou mediasoup qu'il vous faut, pas une plateforme finie.
La visioconférence open source prend-elle en charge le chiffrement de bout en bout ?
En partie, avec des réserves. Jitsi Meet propose le E2EE via les flux insérables du navigateur, ce qui exige des navigateurs compatibles et désactive tout ce qui oblige le serveur à voir les flux média, y compris l'enregistrement. Jami est chiffré de bout en bout par conception, puisqu'il n'y a aucun serveur au milieu. Matrix et Element traitent le chiffrement comme une fonctionnalité de premier plan. Tout le reste chiffre en transit, mais déchiffre sur le serveur.
Jitsi Meet sur AWS, déjà configuré
Une image Jitsi Meet prête pour la production, avec le réseau du videobridge, TLS et TURN déjà réglés, si vous voulez le résultat auto-hébergé sans passer une semaine sur les ports.
Obtenir Jitsi Meet sur AWS Marketplace
