Comment désactiver la télémétrie et les connexions externes dans Collabora CODE

En bref : Collabora Online Development Edition (CODE) ne propose pas d’option de télémétrie générale que les administrateurs doivent désactiver pour les analyses courantes. Collabora précise que la version auto-hébergée d’Online ne nécessite ni télémétrie ni notifications d’analyse. Les activités sortantes à contrôler sont distinctes : vérifications périodiques des mises à jour, intégrations optionnelles, points de terminaison de surveillance et fonctionnalités documentaires qui récupèrent des données distantes. Désactivez les fonctionnalités optionnelles que vous n’utilisez pas, puis appliquez une liste blanche de trafic sortant tout en conservant la connexion WOPI à votre serveur de stockage.

Ceci s'applique aux instances CODE auto-hébergées, comme celles intégrées à Nextcloud ou ownCloud. Bloquer complètement le trafic sortant peut empêcher le chargement et l'enregistrement des documents, car CODE doit pouvoir accéder à son hôte WOPI. Les noms de configuration ci-dessous ont été vérifiés par rapport au modèle amont de Collabora le 6 octobre 2026 ; le packaging et les valeurs par défaut peuvent varier selon la version.

Qu’est-ce qui est considéré comme de la télémétrie ou une connexion externe ?

La télémétrie désigne généralement les données d'utilisation ou de diagnostic d'un produit envoyées à un fournisseur. Collabora affirme que son produit Online auto-hébergé ne nécessite ni télémétrie, ni analyses, ni connexion à un service externe. Le coolwsd.xmlmodèle source ne présente ni collecteur de télémétrie global, ni mécanisme de transmission des données au serveur.

Il affiche une vérification périodique de la version : fetch_update_checkpar défaut toutes les 10 heures. Désactivez 0cette vérification en définissant cette option sur « None ». allow_update_popupCette option contrôle l’affichage des notifications de mise à jour dans l’éditeur ; la désactiver masque falsela notification, mais ne remplace pas la désactivation de la vérification elle-même. Si votre version prend en charge les deux options, activez-les toutes les deux.

D'autres connexions dépendent des fonctionnalités. Elles peuvent inclure un moniteur externe configuré, des services de correction orthographique et grammaticale à distance, la traduction DeepL, des fournisseurs d'IA, la configuration de polices à distance et des données externes demandées par un document. Le modèle d'origine indique que les API LanguageTool et Duden distantes sont désactivées par défaut ; DeepL l'est également. Utilisez les paramètres fournis avec votre version de CODE lorsque vous examinez les options d'IA ou d'intégration.

Étape 1 : Identifier les destinations essentielles et facultatives

Cartographiez le fonctionnement de l'édition avant de modifier le réseau. Par exemple, supposons que Nextcloud soit installé à l'adresse `http:// cloud.example.comlocalhost:8080` et CODE office.example.comà l'adresse `http://localhost:8080`. Le navigateur charge l'éditeur depuis CODE, tandis que le serveur CODE communique également avec Nextcloud via WOPI pour récupérer et enregistrer le document. Conservez cette route serveur à serveur, le schéma et le port utilisés par votre installation, ainsi que les services DNS ou proxy requis par votre déploiement.

Ensuite, recensez les services optionnels de votre configuration. Recherchez <monitors>les adresses de surveillance explicitement configurées. Vérifiez la correction orthographique à distance, DeepL, l'IA, la configuration des polices à distance et les URL de configuration à distance. Supprimez les points de terminaison personnalisés qui ne font pas partie d'un flux de travail approuvé. Si un point de terminaison est nécessaire, documentez son nom d'hôte et sa fonction avant de créer l'exception réseau correspondante.

Examinez également ce paramètre lok_allow. Il contrôle les hôtes que les documents modifiés peuvent utiliser comme sources de données externes, notamment les URL utilisées pour les graphiques insérés ou les fonctions de tableur WEBSERVICE(). Il ne s'agit pas d'un pare-feu universel. La configuration en amont indique que les hôtes WOPI et POST autorisés peuvent également être considérés comme des sources de données permises ; il est donc important de distinguer cette politique des contrôles de sortie réseau.

Étape 2 : Désactiver les vérifications de mise à jour périodiques

Pour le conteneur Collabora CODE, configurez les options via sa extra_paramsvariable d'environnement. Fusionnez-les avec la valeur existante ; conservez les paramètres de terminaison TLS, de proxy inverse ou d'hôte dont votre installation dépend. Épinglez une étiquette d'image CODE approuvée pour votre environnement au lieu de vous fier à une latestétiquette dynamique.

services:
  collabora:
    image: collabora/code:<approved-tag>
    environment:
      extra_params: >-
        --o:fetch_update_check=0
        --o:allow_update_popup=false

Ceci est un exemple de configuration Docker Compose, et non un déploiement complet. Conservez vos restrictions de domaine, identifiants d'administrateur, paramètres TLS et configuration de proxy existants. Dans Kubernetes, le graphique Helm d'origine expose collabora.extra_paramset prend en charge coolwsd.xmlle contenu personnalisé ; utilisez le fichier de valeurs et les instructions correspondant à la version du graphique que vous avez installée.

Si vous gérez directement le fichier XML, placez les valeurs à l'intérieur de son <config>élément principal :

<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>

Ne modifiez pas manuellement le fichier dans un conteneur en cours d'exécution, sauf s'il est persistant. Un redémarrage, une mise à jour d'image ou un déploiement d'orchestration peut le remplacer. Modifiez la source de configuration Compose, Helm ou montée persistante, puis recréez ou déployez CODE selon votre procédure habituelle.

Étape 3 : Désactivez les intégrations inutilisées et limitez les récupérations de documents.

Laissez <monitors>ce champ vide si vous n'utilisez pas de service de surveillance externe. Le fichier en amont contient un exemple de surveillance commenté ; une entrée commentée est un exemple et non une connexion active. Supprimez les entrées de surveillance actives ajoutées localement si elles ne sont plus nécessaires.

Désactivez la correction orthographique et grammaticale à distance, DeepL et les fonctionnalités de l'IA, sauf si les utilisateurs en ont besoin. La vérification linguistique à distance peut envoyer le texte sélectionné du document au service configuré ; son activation a donc des conséquences sur la connectivité et le traitement des données. Si une intégration est nécessaire, n'autorisez que son point de terminaison approuvé via la politique de sortie.

Pour le contenu distant demandé par les documents, supprimez les hôtes publics <lok_allow>et ne conservez que les destinations nécessaires à vos utilisateurs. Ne supprimez pas la route WOPI pour ce faire. WOPI est la connexion de stockage requise pour l'édition normale. Notez également que des entrées de réseau privé trop larges peuvent autoriser la récupération de documents vers un nombre d'hôtes internes supérieur à celui prévu ; restreignez-les en fonction de la configuration de votre réseau et de votre version de code.

Étape 4 : Appliquer les règles de sortie en dehors du code

Les paramètres de l'application désactivent certains comportements ; ils ne garantissent pas qu'aucun autre processus ou système d'exploitation ne puisse ouvrir d'autres connexions. Pour une protection renforcée, appliquez des règles de trafic sortant au niveau du pare-feu hôte, du réseau de conteneurs, de la stratégie réseau Kubernetes ou d'un pare-feu externe. Utilisez le blocage par défaut pour le code, puis autorisez uniquement la destination WOPI et les dépendances explicitement approuvées. Autorisez le DNS via le service réseau utilisé par votre plateforme.

Dans l'exemple ci-dessus, CODE pourrait être autorisé à accéder cloud.example.comau schéma et au port configurés pour WOPI, tandis que les destinations publiques non liées seraient bloquées. Évitez d'utiliser une adresse IP fixe si l'hôte de stockage se trouve derrière un équilibreur de charge ou si ses adresses changent. Un groupe de destinations permanent ou un proxy de sortie contrôlé est plus facile à gérer. Assurez-vous que tout proxy est configuré de manière cohérente pour le conteneur.

Veillez à bien séparer les flux entrants et sortants. Le navigateur doit pouvoir accéder au point de terminaison CODE publié, et le serveur de stockage peut avoir besoin d'accéder à CODE pour les sessions de découverte ou de documents. Une politique de sortie autorisant CODE à appeler WOPI n'établit pas ces routes entrantes. De même, une modification lok_allowne désactive pas tous les types de connexions sortantes.

Étape 5 : Redémarrez et vérifiez la politique

Redémarrez ou déployez CODE pour que la configuration effective soit chargée. Consultez les journaux de démarrage pour vérifier les valeurs de configuration chargées et les avertissements concernant les paramètres ignorés. Ouvrez ensuite un document de test modifiable via l'intégration de stockage habituelle, apportez une modification, enregistrez-la, fermez le document et rouvrez-le. La modification devrait être conservée.

• Consultez les journaux du pare-feu, du proxy ou des règles réseau lors du démarrage et de la modification. Le trafic WOPI attendu doit être autorisé.
• Vérifiez que les destinations externes que vous souhaitiez bloquer sont bien bloquées. Un journal d'événements vide ne prouve pas à lui seul que toutes les routes possibles sont bloquées.
• Une fois l'intervalle de vérification des mises à jour écoulé, vérifiez si le conteneur CODE a tenté une recherche de mise à jour. Assurez-vous que la fenêtre contextuelle de mise à jour est absente si elle était également désactivée.
• Testez toutes les fonctionnalités nécessaires aux utilisateurs, notamment les polices distantes, la traduction, les outils linguistiques, les liens vers des documents et les formules qui récupèrent des données externes. Ne restaurez que la destination approuvée spécifique requise par une fonctionnalité donnée.

Si l'ouverture ou l'enregistrement de documents échoue, vérifiez d'abord le DNS et la route WOPI entre serveurs. Si seule une image externe ou une formule de feuille de calcul pose problème, examinez le problème lok_allowindépendamment de la règle du pare-feu. Bloquer une source de données publique tout en maintenant le fonctionnement de WOPI est le comportement attendu ; bloquer les enregistrements indique que la règle de sortie est trop permissive.

Ce que la désactivation de ces connexions peut et ne peut pas garantir

La désactivation de la vérification des mises à jour et des intégrations inutilisées réduit l'activité sortante attendue de CODE. Une politique réseau de refus par défaut définit le périmètre d'application. Aucune de ces mesures ne régit le trafic distinct de votre hôte, de votre environnement d'exécution de conteneurs, de votre plateforme d'orchestration, de votre proxy inverse ou de votre agent de surveillance. Si l'exigence concerne l'ensemble du serveur, auditez également ces composants.

Les paramètres de configuration par défaut peuvent varier d'une version à l'autre, et les intégrations peuvent ajouter des options. Avant le déploiement, comparez le modèle fourni avec votre image épinglée avec le modèle amont actuel et effectuez des tests en environnement de préproduction. Les principales références sont le modèle de configuration coolwsd.xml amont de Collabora , les valeurs officielles de son graphique Helm et sa déclaration concernant les déploiements auto-hébergés et les services externes .