Jitsi Meet sans compte : organiser une visioconférence privée grâce à l’auto-hébergement

Jitsi Meet sans compte permet d’organiser une visioconférence depuis un lien web : les invités rejoignent la salle dans leur navigateur, sans créer de profil ni installer de logiciel. Pour garder la maîtrise de l’accès, créez une salle au nom difficile à deviner, activez un mot de passe et, pour un usage durable, hébergez Jitsi Meet sur votre propre serveur.

Jitsi Meet est un logiciel de visioconférence libre qui peut être déployé sur un serveur privé avec Docker ou une installation Linux classique. Ce tutoriel explique comment choisir entre une instance publique et un Jitsi Meet auto-hébergé, préparer l’infrastructure, créer une salle, partager le lien et réduire les risques d’intrusion ou de problèmes de connexion.

Peut-on utiliser Jitsi Meet sans créer de compte ?

Oui. Jitsi Meet sans inscription permet aux invités d’ouvrir un lien de réunion depuis un navigateur compatible et de rejoindre la visioconférence sans compte personnel. L’absence de compte simplifie l’accès pour des clients, des partenaires ou des participants ponctuels, mais elle ne remplace pas les mécanismes de contrôle d’accès de la salle.

Une instance Jitsi peut être publique ou auto-hébergée. Une instance publique délègue l’infrastructure à son administrateur, tandis qu’une instance Jitsi Meet auto-hébergée place le serveur, les journaux et les réglages sous la responsabilité de votre organisation. Le vrai arbitrage ne porte pas sur le lien sans compte : il porte sur le niveau de contrôle que vous êtes prêt à administrer.

Un lien de réunion facilite l’entrée ; un mot de passe, une salle difficile à deviner et une modération limitent réellement l’accès.

Instance publique ou Jitsi Meet auto-hébergé : quelle solution choisir ?

Une instance publique convient à un besoin immédiat et ponctuel, sans administration serveur. Un Jitsi Meet auto-hébergé convient lorsqu’une équipe doit maîtriser le domaine utilisé, les règles d’accès, les mises à jour et l’emplacement de l’infrastructure. Dans les deux cas, les invités peuvent rejoindre la réunion sans compte si la configuration de l’instance l’autorise.

Option	Usage adapté	Avantage concret	Limite à accepter
Instance publique	Réunion ponctuelle ou test rapide	Aucune installation à réaliser	Règles, disponibilité et politique de données fixées par l’opérateur
Jitsi Meet auto-hébergé avec Docker	Équipe, association ou entreprise avec un administrateur	Déploiement reproductible et mises à jour plus structurées	DNS, sécurité, supervision et incidents restent à votre charge
Installation Linux classique	Infrastructure Debian déjà administrée	Intégration directe au système existant	Maintenance plus dépendante de la configuration locale

Utiliser une instance publique

Une instance publique évite le déploiement initial, mais il faut vérifier ses règles avant d’envoyer une invitation. L’administrateur de l’instance peut modifier les fonctions disponibles, limiter certains usages ou appliquer ses propres règles de conservation. Pour une réunion importante, testez le lien avec un participant externe avant l’horaire prévu.

Héberger sa propre instance

Un serveur Jitsi Meet auto-hébergé donne un nom de domaine maîtrisé, par exemple visio.votre-domaine.fr, et permet de définir les politiques d’accès. Cette option est pertinente si les réunions sont fréquentes, si les invités doivent utiliser une adresse stable ou si l’organisation veut intégrer une authentification interne pour les créateurs de salles.

Prérequis techniques avant d’installer Jitsi Meet sur un serveur

Un déploiement Jitsi Meet nécessite un serveur Linux accessible depuis Internet, un nom de domaine dirigé vers ce serveur et un certificat HTTPS valide. La documentation du projet et le dépôt officiel docker-jitsi-meet sur GitHub restent les références à consulter avant de choisir une version ou d’appliquer une configuration.

Le pare-feu doit autoriser les flux nécessaires à la visioconférence. Les valeurs souvent indiquées pour le déploiement sont les ports 443/TCP, 4443/TCP et la plage 10000-20000 pour les flux média. Vérifiez toutefois les paramètres de la version installée et les règles de votre hébergeur avant toute ouverture : une plage trop large ou mal filtrée augmente inutilement la surface d’exposition.

• Un VPS ou serveur Linux avec accès administrateur.
• Un nom de domaine ou sous-domaine, avec un enregistrement DNS pointant vers l’adresse publique du serveur.
• Docker et Docker Compose si vous retenez le déploiement par conteneurs.
• Un certificat TLS valide, par exemple via Let’s Encrypt, pour éviter les alertes de navigateur.
• Une règle de pare-feu documentée et testée depuis un réseau externe.

Un serveur TURN agit comme relais lorsque des participants se trouvent derrière un NAT restrictif ou un pare-feu. Le serveur TURN n’est pas requis dans chaque contexte, mais il est recommandé pour améliorer la fiabilité des connexions audio et vidéo, surtout si les invités se connectent depuis des réseaux d’entreprise, des hôtels ou certains réseaux mobiles.

La qualité perçue dépend autant du réseau, du pare-feu et du navigateur que de la puissance du serveur Jitsi.

Comment installer Jitsi Meet auto-hébergé avec Docker ?

Le déploiement Docker de Jitsi Meet consiste à récupérer le projet officiel, renseigner le nom de domaine et les paramètres d’environnement, puis démarrer les conteneurs avec Docker Compose. Cette méthode sépare plus clairement l’application, sa configuration et ses mises à jour qu’une installation manuelle dispersée dans le système.

Étape 1 : préparer le domaine et le serveur

Créez un sous-domaine dédié à la visioconférence et faites pointer son enregistrement DNS vers l’adresse IP publique du serveur. Connectez-vous ensuite au serveur avec un compte administrateur, appliquez les mises à jour système et vérifiez que Docker ainsi que Docker Compose sont installés et fonctionnels.

Le résultat attendu est simple : le domaine résout vers le serveur et l’environnement Docker peut lancer des conteneurs. Ne commencez pas le déploiement tant que le DNS n’est pas propagé et que le pare-feu n’est pas explicitement défini.

Étape 2 : récupérer le projet officiel Docker

Téléchargez l’archive ou clonez le dépôt officiel docker-jitsi-meet depuis GitHub dans un répertoire dédié du serveur. Utilisez la documentation associée au dépôt pour sélectionner la branche ou la version stable proposée au moment de l’installation, car les variables disponibles peuvent évoluer.

Le résultat attendu est un dossier de projet contenant les fichiers de composition Docker et un modèle de configuration. Évitez les copies de fichiers .env trouvées sur des forums : une variable obsolète peut produire un démarrage incomplet ou exposer un secret inutilement.

Étape 3 : renseigner le fichier de configuration

Créez le fichier d’environnement à partir du modèle fourni par le projet, puis indiquez le domaine public choisi, les paramètres réseau et les secrets nécessaires. Définissez des mots de passe générés aléatoirement pour les composants internes et conservez-les dans un gestionnaire de secrets ou un coffre-fort d’équipe.

Le résultat attendu est une configuration cohérente avec votre domaine et votre environnement réseau. Un certificat auto-signé peut suffire à un test interne, mais un certificat reconnu, par exemple Let’s Encrypt, est préférable pour les invités externes et les navigateurs modernes.

Étape 4 : démarrer les conteneurs et vérifier l’accès HTTPS

Lancez les services avec la commande Docker Compose recommandée par le dépôt officiel, puis consultez l’état des conteneurs et leurs journaux. Ouvrez ensuite l’URL HTTPS du domaine dans un navigateur depuis un réseau différent de celui du serveur afin de vérifier l’accès réel des participants.

Le résultat attendu est l’affichage de la page Jitsi Meet sans avertissement de certificat. Si la page apparaît mais que les appels échouent, le problème se situe souvent dans les ports média, la configuration NAT ou l’absence de relais TURN adapté.

Étape 5 : créer une salle Jitsi difficile à deviner

Ouvrez l’adresse de votre instance, puis saisissez un nom de salle long et spécifique, sans information prévisible comme le nom d’un service ou la date de réunion. Un nom tel que point-projet-2026 est faible ; une combinaison de mots non liés et d’un suffixe aléatoire réduit les tentatives d’accès par devinette.

Le résultat attendu est une URL unique que vous pouvez transmettre aux seuls participants concernés. La création d’une salle Jitsi ne garantit pas qu’elle restera réservée à vos invités si le lien circule ou si aucun contrôle d’accès n’est activé.

Étape 6 : protéger la salle avant de partager le lien

Activez le mot de passe de la réunion avant d’envoyer l’invitation, puis communiquez le lien et le secret par des canaux distincts lorsque le sujet est sensible. Utilisez également les fonctions de modération disponibles sur votre instance pour contrôler les entrées, couper un microphone perturbateur ou exclure un participant indésirable.

Le résultat attendu est une réunion vidéo privée dont l’accès reste limité aux personnes disposant du lien et du mot de passe. Une salle sans compte reste utilisable sans inscription, mais elle doit être administrée comme n’importe quel espace collaboratif exposé sur Internet.

Comment inviter des participants sur Jitsi Meet sans inscription ?

Pour inviter des participants sans inscription, copiez l’URL complète de la salle Jitsi, transmettez-la aux personnes attendues et indiquez le mot de passe dans un message séparé si la salle est protégée. Les invités ouvrent le lien dans leur navigateur, autorisent le microphone et la caméra si nécessaire, puis rejoignent la réunion sans compte utilisateur.

Une invitation utile précise l’horaire, le fuseau horaire, le lien, le mot de passe transmis séparément et un contact de secours. Laissez les invités rejoindre quelques minutes avant une réunion importante afin de traiter les autorisations du navigateur sans interrompre le début de séance.

1. Créez la salle depuis le domaine Jitsi Meet choisi.
2. Définissez un mot de passe avant toute diffusion du lien.
3. Copiez l’URL complète dans l’invitation calendrier ou le message dédié.
4. Envoyez le mot de passe dans un canal distinct lorsque le niveau de confidentialité l’exige.
5. Demandez aux invités de tester micro et caméra avant l’heure de début.
6. Accueillez les participants et vérifiez leur identité avant d’aborder un sujet sensible.

Sécuriser une salle Jitsi Meet et une instance auto-hébergée

La sécurité d’une instance Jitsi Meet auto-hébergée repose sur plusieurs couches : HTTPS, mises à jour, contrôle de l’accès aux salles et protection de l’administration serveur. Le chiffrement de bout en bout optionnel existe dans certains contextes, notamment sur les navigateurs Chromium compatibles, mais il ne dispense ni de vérifier les réglages ni de protéger les postes des participants.

Une organisation peut restreindre la création des salles via une authentification d’entreprise, par exemple LDAP, Active Directory ou un mécanisme SSO selon sa configuration. Cette approche laisse éventuellement les invités rejoindre une salle existante sans compte, tout en réservant la création de nouvelles salles à des utilisateurs autorisés.

• Installez les mises à jour de sécurité du système, de Docker et de Jitsi selon une procédure planifiée.
• Conservez des sauvegardes de la configuration et des secrets hors du serveur de production.
• Vérifiez les journaux pour identifier les erreurs répétées, sans y stocker plus de données personnelles que nécessaire.
• Limitez l’accès SSH, utilisez des clés d’accès et activez une authentification forte pour les comptes d’administration.
• Testez le renouvellement du certificat TLS avant son échéance.

Quelle puissance serveur prévoir pour une visioconférence Jitsi ?

Le dimensionnement dépend du nombre de participants simultanés, de la qualité vidéo demandée, du partage d’écran, des enregistrements et de la bande passante disponible. Comme ordre de grandeur, les recommandations souvent reprises pour Jitsi indiquent 2 Go de RAM pour un petit groupe de 2 à 5 participants, 4 Go pour 10 à 20 personnes, puis 8 Go ou plus avec un Jitsi Videobridge dédié pour 50 participants ou davantage.

La bande passante vidéo est fréquemment estimée entre 2 et 4 Mbit/s par participant. Pour une réunion de 10 personnes, cela représente un ordre de grandeur de 20 à 40 Mbit/s côté serveur selon les flux réellement transmis. Ces chiffres servent au cadrage initial : mesurez la charge CPU, la mémoire, les pertes réseau et la latence pendant vos propres tests.

Usage visé	Repère mémoire	Point de vigilance
2 à 5 participants	2 Go de RAM	Tester la qualité depuis un réseau externe
10 à 20 participants	4 Go de RAM	Surveiller CPU, bande passante et flux vidéo simultanés
50 participants ou plus	8 Go de RAM ou plus	Prévoir une architecture adaptée, dont un Videobridge dédié selon la charge

Utiliser les fonctions utiles pendant une réunion vidéo privée

Jitsi Meet propose les fonctions attendues d’un outil de réunion : activation du micro et de la caméra, partage d’écran, messagerie, gestion des participants et, selon la configuration, enregistrement. La fonction d’enregistrement local dépend du navigateur, tandis que l’enregistrement côté serveur requiert un composant tel que Jibri et des ressources supplémentaires.

Le partage d’écran est utile pour présenter un document, une application ou une démonstration. Avant une réunion externe, fermez les fenêtres contenant des informations sensibles et vérifiez que le bon écran ou la bonne fenêtre est sélectionné. Le partage d’écran montre souvent plus que prévu lorsque les notifications et les applications personnelles restent ouvertes.

Gérer le son et la caméra

Demandez aux participants de choisir explicitement leur microphone et leur caméra dans les réglages Jitsi. Les navigateurs peuvent conserver une ancienne autorisation ou sélectionner un périphérique par défaut incorrect, surtout après le branchement d’un casque USB ou d’une webcam externe.

Enregistrer une réunion

L’enregistrement doit être annoncé aux participants et encadré par une règle interne claire sur la finalité, la conservation et l’accès au fichier. Une instance Jitsi auto-hébergée ne supprime pas les obligations liées aux données personnelles : l’administrateur doit savoir où le fichier est stocké et qui peut le récupérer.

Erreurs fréquentes lors d’une configuration Jitsi Meet sans compte

Les incidents viennent rarement d’un seul réglage. Un lien qui fonctionne chez l’administrateur peut échouer pour un invité placé derrière un pare-feu d’entreprise, tandis qu’une salle protégée peut rester vulnérable si son mot de passe est transmis dans un fil public ou réutilisé.

• Utiliser un nom de salle prévisible. Le risque est une tentative d’accès non souhaitée. Utilisez une suite de mots non évidente et un suffixe aléatoire.
• Partager le lien avant d’activer le mot de passe. Le lien peut être transféré immédiatement. Réglez la protection avant l’envoi de l’invitation.
• N’ouvrir que le port HTTPS. La page peut s’afficher, mais les flux média peuvent échouer. Vérifiez les règles réseau prévues pour Jitsi.
• Ignorer les tests depuis un réseau externe. Une validation locale ne révèle pas les problèmes de NAT, de DNS ou de certificat. Faites un appel de test hors du réseau serveur.
• Reporter les mises à jour. Une image Docker ou un système non maintenu accroît le risque de vulnérabilités et de décalage de configuration.

Jitsi Meet, Zoom ou Google Meet : quelle option selon le besoin ?

Jitsi Meet, Zoom et Google Meet répondent à un même besoin de réunion vidéo, mais leur modèle d’exploitation diffère. Jitsi Meet auto-hébergé privilégie le contrôle de l’infrastructure et l’accès par lien, tandis que Zoom et Google Meet réduisent l’administration technique en s’appuyant sur leurs propres services et comptes.

Choisissez Jitsi Meet auto-hébergé si le contrôle du serveur, du domaine et des règles d’accès justifie l’effort d’exploitation. Choisissez Zoom ou Google Meet si l’objectif est de limiter la charge d’administration et que les politiques de l’éditeur sont compatibles avec vos contraintes internes.

Solution	Atout principal	Friction principale	Cas d’usage cohérent
Jitsi Meet auto-hébergé	Contrôle de l’infrastructure et du domaine	Administration, sécurité et capacité à superviser	Organisation disposant d’un serveur et d’une compétence technique
Zoom	Service hébergé et déploiement utilisateur rapide	Dépendance au fournisseur et à ses conditions	Réunions externes fréquentes avec peu d’administration interne
Google Meet	Intégration à l’écosystème Google Workspace	Dépendance à l’environnement Google et aux comptes associés	Équipes déjà structurées autour de Google Workspace

Sources utiles à consulter

Le dépôt officiel docker-jitsi-meet fournit les fichiers de déploiement, les variables de configuration et les consignes de mise à jour. Consultez-le avant chaque installation ou évolution, car les options de conteneurs peuvent changer.

Le site officiel Jitsi Meet présente le projet et ses usages. Pour les certificats TLS, la documentation de Let’s Encrypt aide à comprendre l’émission et le renouvellement des certificats HTTPS.

Questions fréquentes sur Jitsi Meet sans compte

Les invités doivent-ils créer un compte pour rejoindre Jitsi Meet ?

Non. Les invités peuvent ouvrir le lien de la réunion dans un navigateur compatible et rejoindre la salle sans créer de compte. Une instance peut toutefois imposer des règles spécifiques selon la politique de son administrateur.

L’organisateur doit-il obligatoirement avoir un compte Jitsi ?

Non, pas nécessairement. Une instance ouverte peut permettre la création d’une salle sans compte, tandis qu’une instance auto-hébergée peut réserver cette création à des utilisateurs authentifiés via LDAP, Active Directory ou SSO.

Une réunion Jitsi Meet sans inscription est-elle vraiment privée ?

Une réunion sans inscription n’est privée que si l’accès est contrôlé. Utilisez un nom de salle difficile à deviner, activez un mot de passe et vérifiez la liste des participants avant de partager des informations sensibles.

Combien de participants une instance Jitsi auto-hébergée peut-elle accueillir ?

La capacité dépend du processeur, de la mémoire, de la bande passante, de la qualité vidéo et de l’architecture choisie. Les repères de 2 Go, 4 Go et 8 Go de RAM servent à préparer un test, mais ne remplacent pas une mesure de charge sur votre usage réel.

Peut-on rejoindre une réunion Jitsi Meet depuis un téléphone ?

Oui, sous réserve de disposer d’un navigateur ou d’une application compatible selon l’environnement utilisé. Testez le lien, les permissions caméra et microphone ainsi que la qualité du réseau mobile avant une réunion importante.