Comment désactiver la télémétrie et l'enregistrement des données dans Jitsi Meet

Si vous hébergez Jitsi Meet, vous pouvez désactiver les gestionnaires d'analyse de l'application et bloquer ses requêtes tierces optionnelles config.js. Cela réduit la télémétrie côté client, mais ne désactive pas les journaux du serveur web, de Docker, de Prosody, de Jicofo ou de Videobridge. Ces journaux suivent des chemins de données distincts, gérés par l'opérateur du serveur. Si vous rejoignez une réunion sur Jitsi Meet meet.jit.siou un autre service hébergé, vous ne pouvez pas modifier vous-même ses paramètres côté serveur.

Au 6 octobre 2026, la documentation de référence de configuration Jitsi actuelle décrit toujours les paramètres analytics.disabledet disableThirdPartyRequestsles contrôles. Aucune modification récente du produit ne requiert de procédure différente. Les étapes ci-dessous s'appliquent à un déploiement web auto-hébergé ; les kits de développement logiciel mobiles, les intégrations embarquées et les panneaux d'hébergement tiers peuvent proposer des contrôles différents.

Que signifient « télémétrie » et « journalisation » dans Jitsi Meet ?

Le client web de Jitsi peut charger des gestionnaires d'analyse ou se connecter à des services de statistiques externes configurés. La configuration inclut une option de désactivation globale des analyses et des options pour des services tels que rtcstats. Un paramètre de confidentialité distinct disableThirdPartyRequestsbloque les requêtes tierces et force la génération locale des avatars ; Jitsi précise que les intégrations de statistiques externes ne fonctionneront pas lorsque ce paramètre est activé.

WebRTC nécessite toujours l'échange de signaux et de flux multimédias pour qu'une réunion fonctionne. La désactivation des analyses ne masque pas l'adresse réseau d'un utilisateur auprès de l'infrastructure de réunion, ne retire pas un participant de la salle, n'empêche pas l'organisateur d'enregistrer ni n'efface les données déjà collectées. Les journaux d'accès au serveur et les journaux de diagnostic sont également indépendants des analyses du navigateur. Le guide de l'analyseur de journaux de Jitsi décrit une architecture distincte capable de collecter les journaux des composants via OpenTelemetry et Loki, ce qui explique pourquoi un seul paramètre client ne peut pas désactiver tous les journaux.

1. Confirmer qui contrôle le déploiement

Pour un serveur Jitsi que vous administrez, localisez le fichier de configuration web. Sur les installations Debian ou Ubuntu classiques, il se trouve généralement à l'emplacement /etc/jitsi/meet/<your-domain>-config.jsindiqué. Avec Docker, le fichier host est généralement monté dans le conteneur webconfig.js ; utilisez le chemin et le mappage de volume correspondants dans votre configuration Compose. Effectuez une sauvegarde avant toute modification et conservez la structure existante du fichier.

Si vous utilisez uniquement une réunion publique ou hébergée par un fournisseur, une option client peut vous permettre de limiter vos informations personnelles, mais l'organisateur décide de la journalisation, de la conservation et de l'analyse des données sur le serveur. Renseignez-vous auprès du fournisseur sur sa politique de confidentialité et de conservation des données lorsque ces paramètres sont importants.

2. Désactiver l'analyse des clients et les requêtes externes

Dans l'objet de niveau supérieur existant config, fusionnez ces entrées aux emplacements correspondants. Ne collez pas une deuxième copie d'une clé existante et ne remplacez pas l'intégralité du fichier de configuration.

disableThirdPartyRequests: true,
enableDisplayNameInStats: false,
enableEmailInStats: false,
gatherStats: false,
analytics: {
  disabled: true,
  rtcstatsEnabled: false,
  rtcstatsStoreLogs: false,
  scriptURLs: []
},

Les options d'analyse sont imbriquées sousanalytics ; les quatre autres entrées doivent être au niveau supérieur. Si votre fichier contient déjà un analyticsobjet, modifiez-le plutôt que d'en ajouter un autre. Supprimez les URL de scripts d'analyse personnalisés et les points de terminaison de service que vous avez configurés intentionnellement, ou laissez le tableau vide comme indiqué. Les valeurs explicites de rtcstats indiquent clairement l'état souhaité, tandis que analytics.disabledreprésente le principal paramètre des gestionnaires d'analyse.

Le guide utilisateur avancé de Jitsi mentionne également disableThirdPartyRequests: truecette option de configuration. Elle peut affecter les fonctionnalités dépendant de services externes, comme les avatars hébergés en externe ou les intégrations de statistiques. Testez les fonctionnalités de réunion utilisées par votre organisation avant de déployer la modification à grande échelle.

3. Appliquez la modification et vérifiez la configuration servie

Enregistrez le fichier et suivez la procédure de déploiement habituelle pour recharger ou redémarrer le composant web. Avec Docker, cela implique souvent de recréer ou de redémarrer le service web après avoir vérifié que la configuration montée sur l'hôte correspond bien au fichier modifié ; les déploiements basés sur des paquets peuvent servir le fichier directement. L'installation de Jitsi varie selon le paquet, la version et les modifications locales ; il est donc déconseillé de redémarrer systématiquement chaque composant.

Ouvrez la page de réunion dans une fenêtre de navigation privée ou videz le cache du site, puis examinez la configuration transmise au navigateur. Dans les outils de développement, chargez-la https://your-domain/config.jset vérifiez qu'elle contient les valeurs que vous avez définies. Si les anciennes valeurs apparaissent, vérifiez le nom de fichier spécifique au domaine, le point de montage du volume du conteneur, le cache du proxy inverse et assurez-vous que le navigateur accède bien au serveur prévu.

4. Examiner séparément les journaux côté serveur

Réalisez maintenant l'inventaire des journaux existants. Ils se trouvent généralement dans les journaux d'accès et d'erreurs du proxy inverse, la sortie des conteneurs Docker, ainsi que les journaux de Prosody, Jicofo et Jitsi Videobridge. Si vous avez installé la suite d'analyse de journaux optionnelle, examinez également sa configuration OpenTelemetry Collector et Loki. La documentation de Jitsi relative à l'analyse de journaux décrit le chemin d'accès au collecteur et au stockage séparément des analyses côté client.

Choisissez une politique opérationnelle plutôt que de supposer que tous les journaux peuvent être désactivés sans risque. Vous pouvez réduire la verbosité des journaux, restreindre leur accès, raccourcir leur durée de conservation ou désactiver un pipeline de transfert de journaux optionnel. Conservez suffisamment d'informations de diagnostic pour enquêter sur les pannes et les abus, et évitez de collecter les noms de salles, les adresses e-mail, les adresses IP ou l'intégralité des données de signalisation, sauf en cas de besoin spécifique. Appliquez la conservation au niveau de la couche de stockage réelle (proxy, environnement d'exécution des conteneurs ou système de journalisation), car le client config.jsne définit pas ces durées de conservation.

5. Vérifier le comportement sans considérer un panneau de contrôle réseau silencieux comme une preuve

Rejoignez une salle de test depuis une nouvelle session de navigateur et vérifiez que l'audio, la vidéo, le chat et le partage d'écran fonctionnent correctement. Dans le panneau Réseau de votre navigateur, examinez les requêtes adressées aux serveurs d'analyse ou de statistiques tiers pendant le démarrage et le déroulement de la réunion. Certaines requêtes sont nécessaires au bon fonctionnement de la réunion ; bloquer systématiquement tout nom d'hôte inconnu peut perturber la signalisation, la configuration multimédia, les avatars ou d'autres intégrations. Comparez les destinations avec votre propre configuration et architecture de déploiement ; l'absence de requête visible lors d'un test ne signifie pas qu'aucun journal serveur n'est généré.

Si le trafic indésirable persiste, recherchez une autre source : un script d’analyse personnalisé, une balise injectée par un proxy inverse, une page parente d’une iframe, une extension de navigateur ou l’instrumentation de votre hébergeur. Si le problème provient des journaux du serveur plutôt que des analyses côté client, vérifiez la configuration du service et du stockage concernés.

Ce que ce changement peut et ne peut pas garantir

Ces paramètres permettent de désactiver l'analyse client configurée pour Jitsi Meet et les requêtes tierces optionnelles sur un serveur que vous contrôlez. Ils ne garantissent pas l'anonymat, ne désactivent pas toutes les connexions réseau et ne suppriment pas automatiquement l'historique des données. Ils ne contrôlent pas non plus les données de télémétrie ajoutées par une version modifiée, un site web intégré ou votre hébergeur. Consultez la configuration correspondant à la version exacte de Jitsi que vous utilisez et revérifiez-la après chaque mise à jour, car les noms de configuration et les intégrations peuvent changer.

Pour les références principales, consultez le guide de configuration de Jitsi Meet , le guide de l'utilisateur avancé , l' exemple de configuration config.js en amont et le guide de l'analyseur de journaux auto-hébergé de Jitsi .