Si vous cherchez un bureau virtuel open source, vous n'avez pas besoin qu'on vous explique le « pourquoi ». Un prix par siège pour un outil que toute l'entreprise garde ouvert toute la journée, des données de présence que vous préférez garder sur vos propres serveurs, une catégorie avec un historique de pivots et de fermetures : vous êtes ici pour un mélange de tout cela.
Le plus difficile, c'est qu'il n'y a pas beaucoup de vraies options, et que l'étiquette « open source » cache de grandes différences. Certains outils sont open-core avec les parties utiles derrière une édition payante, et certains ont besoin d'une petite flotte de services pour être auto-hébergés. Cet article fait donc deux choses. D'abord, il vous donne une liste de cinq points pour évaluer n'importe quel bureau virtuel open source. Ensuite, il passe en revue un candidat concret : Hiroba, un bureau virtuel sous Apache-2.0 avec un serveur Rust auto-hébergeable en un seul binaire et un client de bureau natif.
Ce qu'il faut regarder dans un bureau virtuel open source
Un point à clarifier avant la liste : à quoi doit servir cet outil. Les réunions sont déjà couvertes ; Zoom et Google Meet ne vont nulle part. Ce qu'un bureau virtuel restaure, c'est le moment avant une conversation : voir qu'un collègue est là, s'approcher et demander « t'as deux minutes ? ». Cela se réduit à deux missions, la présence d'un coup d'œil et la conversation sans cérémonie. Les outils qui greffent visioconférence, enregistrement et tableaux blancs par-dessus ces deux missions deviennent lourds à faire tourner et lourds à héberger, alors la liste ci-dessous prend ces deux missions comme étalon.
Cela posé, voici les questions qui séparent vraiment les options. « Open source » sur l'étiquette ne dit pas grand-chose en soi.
1. Que couvre vraiment la licence ?
Vérifiez deux choses : la licence elle-même (permissive comme Apache-2.0/MIT contre copyleft comme AGPL, ce qui compte si vous prévoyez de la modifier et de la proposer comme service), et ce qui en est exclu. Certains produits « open source » sont open-core : les parties intéressantes, comme le SSO, les contrôles d'administration et la montée en charge, vivent dans une édition fermée payante. Lisez la section licence du dépôt, pas la page marketing.
2. Combien de travail représente vraiment l'auto-hébergement ?
C'est là que les bureaux virtuels diffèrent le plus. Certains exigent une pile docker-compose : un serveur d'application, une base de données, un serveur média (SFU), un serveur TURN, Redis. C'est un vrai engagement opérationnel ; chaque composant mobile demande des correctifs et de la surveillance. À l'autre extrémité, certains serveurs sont un seul binaire que vous copiez sur une VM et lancez. Avant de vous engager, trouvez le guide d'auto-hébergement et comptez les boîtes du schéma d'architecture.
3. Par où passe réellement l'audio ?
Une question sous-estimée. Si la voix est routée par un serveur média (SFU), votre serveur a besoin de la bande passante et du CPU pour chaque conversation simultanée, et il touche techniquement l'audio. Si la voix est en WebRTC pair-à-pair, le serveur ne fait que négocier les connexions, reste peu coûteux à exploiter et ne manipule jamais un seul paquet audio. Le P2P a des limites (l'audio en maille ne monte pas en charge pour les grandes salles), mais pour les petites conversations spontanées pour lesquelles un bureau virtuel existe, c'est un bon compromis.
4. Peut-il rester ouvert toute la journée sur des portables ordinaires ?
Un bureau virtuel n'est utile que quand tout le monde y est, et le moyen le plus rapide de tuer l'adoption est un client qui fait tourner les ventilateurs. Les onglets de navigateur et les applications Electron peuvent convenir, mais ils luttent contre le poids de leur plateforme. Cherchez des chiffres publiés de CPU et de mémoire au repos, et testez sur la machine la plus ancienne de votre équipe, pas la plus récente.
5. Qu'envoie-t-il à l'éditeur ?
L'open source rend cela vérifiable, alors vérifiez-le : quelle télémétrie existe, où elle est documentée, et si un déploiement auto-hébergé contacte l'éditeur tout court.
Hiroba : un bureau virtuel open source et auto-hébergeable
Hiroba (« place publique » en japonais) est notre tentative du bureau virtuel à deux missions décrit ci-dessus, construit pour bien répondre exactement à ces cinq questions.
À quoi ressemble son utilisation
Votre organisation reçoit un étage : un hall partagé au centre, des salles d'équipe autour. Quand vous ouvrez Hiroba, votre avatar apparaît sur l'étage, et cela seul dit à votre équipe que vous êtes là.
- La présence d'un coup d'œil. L'étage montre qui est actif, absent, occupé ou déjà en appel.
- S'approcher pour parler. Déplacez votre avatar près d'un collègue et la voix spatiale monte. Pas de lien, pas d'invitation, pas de cérémonie.
- Appeler n'importe qui en un clic. Pour quelqu'un dans une autre salle, cliquez sur Call à côté de son nom dans la liste. C'est la version logicielle d'une tape sur l'épaule.
- Partage d'écran et caméra quand vous en avez besoin. Dans un appel, les deux sont à un clic et passent en pair-à-pair. Le reste du temps, rien ne tourne, et c'est en partie pourquoi le client reste léger.
Comment il est construit (et pourquoi cela le garde léger)
Le serveur est écrit en Rust (axum + tokio) et se compile en un seul binaire statique. Il ne fait transiter que des données de contrôle : la liste, les positions des avatars, les décisions de proximité et la négociation WebRTC. L'audio ne passe jamais par le serveur. La voix est une maille WebRTC pair-à-pair (Opus), donc le serveur reste minuscule et peu coûteux au repos, et vos conversations se connectent directement entre les personnes qui les tiennent.
Le client est une application native Tauri (une enveloppe Rust autour du WebView du système, avec un frontend en TypeScript vanilla + Canvas 2D) plutôt qu'un paquet Electron qui embarque sa propre copie de Chromium. Dans nos mesures, il tourne au repos autour de 100 Mo de mémoire (mesuré sur macOS ; varie selon l'environnement) avec un CPU au repos quasi nul. Il est conçu pour rester en arrière-plan du matin au soir sans concurrencer votre vrai travail.
Licence et télémétrie, en termes simples
Hiroba est sous Apache-2.0 sur GitHub : code, documentation et protocole, avec concession de brevets. Une réserve honnête : le nom « Hiroba », le logo et les icônes de l'application sont exclus de la licence, donc un fork ne peut pas être distribué sous notre marque. Tout ce qui est fonctionnel est ouvert.
La télémétrie se limite à la vérification de mise à jour dans les builds officiels, documentée dans le README : une ligne par appareil et par jour (plateforme, architecture, version, pays approximatif), impossible à relier d'un jour à l'autre et supprimée après 90 jours. Il n'y a aucune autre télémétrie : rien sur votre organisation, votre étage, vos collègues ou vos appels. Les déploiements auto-hébergés qui compilent leur propre client ne nous contactent jamais.
Auto-héberger Hiroba en pratique
La version courte : copiez un binaire sur un serveur et lancez-le.
- Pas de dépendances auxiliaires. Pas de serveur média, pas de Redis, pas de base de données externe. La persistance est un SQLite optionnel, activé par une variable d'environnement. Le schéma d'architecture a une seule boîte.
- Pas de limite de sièges ni de fonctions bridées. Le serveur auto-hébergé est le produit complet, pour autant de personnes que vous voulez amener.
- Les clients se compilent depuis le même dépôt. Vous compilez le client de bureau avec l'URL de votre serveur intégrée ; les installateurs officiels visent macOS et Windows.
- Les notes réseau sont documentées. Comme la voix est en P2P, la plupart des configurations n'ont besoin de rien de particulier, mais les NAT restrictifs peuvent exiger un serveur TURN ; le guide d'auto-hébergement couvre le déploiement, la configuration et les détails pare-feu/NAT.
Et si le produit vous plaît mais que vous ne voulez pas l'exploiter : il existe une édition hébergée et gérée avec connexion OAuth, invitations et facturation à 2 $ par utilisateur et par mois, avec 30 jours d'essai gratuit et sans carte. Les détails sont sur la page des tarifs. Le même cœur open source dans les deux cas.
Le moyen le plus rapide d'en juger est de le faire tourner une journée de travail à côté de votre vrai travail et de voir s'il est encore ouvert à la fin. L'application de bureau est un simple téléchargement, et l'essai de 30 jours de l'édition hébergée démarre à la connexion, sans carte.
Télécharger Hiroba→Questions fréquentes
Existe-t-il une alternative gratuite et open source à Gather ou oVice ?
Hiroba en est une : sous licence Apache-2.0, avec un serveur auto-hébergeable et sans limite de sièges, et bien plus légère que l'un ou l'autre, puisqu'elle tourne comme une application de bureau native avec un CPU au repos proche de 0 % plutôt que dans un onglet de navigateur. Les réunions planifiées restent dans votre outil de réunion. Nous la comparons à Kumospace, SoWork et WorkAdventure dans Meilleures alternatives à Gather en 2026.
Hiroba est-il vraiment gratuit, ou open-core ?
Le code, la documentation et le protocole sont sous Apache-2.0, et le serveur auto-hébergé est le produit complet, sans limite de sièges ni fonctions bridées. Ce que vous payez, en option, c'est l'édition hébergée et gérée (2 $/utilisateur/mois) où nous exploitons le serveur et gérons la connexion, les invitations et la facturation. La seule chose que la licence ne couvre pas est la marque : le nom Hiroba, le logo et les icônes ne peuvent pas être réutilisés par un fork.
Mon audio passe-t-il par le serveur ?
Non. La voix est en WebRTC pair-à-pair entre les clients ; le serveur ne gère que la liste, les positions et la signalisation des connexions, et ne touche jamais aux médias. Rien n'est enregistré.
De quoi ai-je besoin pour faire tourner le serveur ?
Une petite VM et un binaire Rust statique. La persistance est un SQLite optionnel via une variable d'environnement ; il n'y a ni base de données externe, ni serveur média, ni file de messages. Les NAT d'entreprise restrictifs peuvent en plus nécessiter un serveur TURN, et le guide d'auto-hébergement du dépôt explique quand et comment.
Quelles plateformes le client prend-il en charge ?
Des installateurs officiels existent pour macOS et Windows, donc les équipes au matériel hétérogène n'ont pas de souci.