Ce qu’OpenClaw envoie à ses serveurs

Vous avez installé OpenClaw sur votre propre machine justement pour que rien n’en sorte. Puis vous lisez une note de version, ou vous regardez le journal du pare-feu, et il y a une requête sortante vers telemetry.openclaw.ai une fois par jour. Il vaut la peine de savoir exactement ce que cette requête transporte, ce que le serveur conserve, et quelles parties vous pouvez couper. La documentation est inhabituellement précise sur ces trois points.

Deux niveaux, et un seul est actif par défaut

• La vérification quotidienne des mises à jour est le niveau par défaut. C’est un simple GET vers https://telemetry.openclaw.ai/api/latest-version qui demande s’il existe une version plus récente, et il n’a aucun corps de requête.
• Tout ce qu’il indique au serveur voyage dans un seul en-tête. Un User-Agent du type openclaw/2026.8.2 (darwin; node/26.0.1; arm64; gateway) porte la version d’OpenClaw, le système d’exploitation, la version de Node.js, l’architecture du processeur, et le fait que l’appel vienne de la passerelle ou de la CLI.
• Aucun des deux niveaux ne contient de contenu de message, de prompt, de nom de modèle, de clé d’API, d’identifiant de compte, de chemin de fichier ou de nom d’hôte. Il n’y a pas davantage d’identifiant d’installation, de machine ou de suivi aléatoire : OpenClaw ne crée aucun identifiant client persistant pour ces requêtes, et c’est pourquoi des rapports répétés ne comptent ni des installations ni des utilisateurs.
• Les statistiques de fonctionnalités anonymes forment le second niveau, et elles sont désactivées par défaut. Quand vous les activez, la même requête quotidienne devient un POST portant un petit corps JSON en version de schéma 1, au lieu d’ajouter une seconde requête.

Refuser est un choix parfaitement normal et ne change rien au fonctionnement d’OpenClaw pour vous.

Ici, le consentement explicite est réellement explicite

L’installation interactive peut proposer un consentement unique, avec Non merci sélectionné par défaut, et le Quick Start guidé saute complètement cette question. OpenClaw enregistre votre réponse pour ne plus la reposer, mais ce n’est pas cette réponse qui décide quoi que ce soit : c’est le réglage enabled. Les installations non interactives et scriptées n’activent jamais rien d’elles-mêmes, donc une image construite dans un pipeline reste au niveau mise à jour seule tant qu’un opérateur n’active pas les statistiques délibérément. L’objectif annoncé du second niveau est étroit, orienter les priorités de maintenance, et la documentation précise qu’il ne mesure aucune invocation de plugin, aucun message, aucune requête de modèle et aucun utilisateur actif.

Le champ que le client ne contrôle pas

• Cloudflare fournit une localisation approximative au récepteur hébergé : pays, code de région, ville et fuseau horaire. Aucune adresse IP brute et aucune coordonnée précise ne sont stockées dans les analyses, et les champs manquants ou invalides restent simplement vides.
• Les vérifications enregistrées contiennent ces champs même lorsque les statistiques anonymes sont désactivées et même lorsque DO_NOT_TRACK est défini. Aucune charge utile supplémentaire ni aucune question n’interviennent, car ces valeurs sont dérivées à la périphérie plutôt qu’envoyées par vous.
• Analytics Engine conserve les enregistrements pendant trois mois. Les agrégats publics excluent la localisation, et couper les requêtes plus tard n’efface pas les enregistrements déjà présents.

Avant de changer quoi que ce soit, lancez openclaw telemetry show. La commande indique si les statistiques de fonctionnalités anonymes sont activées et pourquoi, le point de terminaison utilisé, et la dernière vérification réussie, et quand les statistiques sont désactivées elle affiche la requête de mise à jour seule avec son en-tête User-Agent. Ajoutez --json pour obtenir le même état et la même charge utile sous forme de document exploitable par une machine. Quand les statistiques sont activées, l’aperçu montre toute la charge utile, et elle est courte : schema, version, platform, node, surface, et un objet features contenant les identifiants de canaux configurés, les familles de fournisseurs, les identifiants de plugins publics, un total de plugins et sessionsLast24h. Ces noms de plugins couvrent les plugins fournis, les installations officielles de confiance et les entrées correspondant au catalogue officiel, si bien que les identités de plugins privés ne sont jamais nommées, et l’écart entre pluginsEnabled et le nombre de noms rapportés ne compte pas de façon fiable les plugins privés. Le chiffre de sessions correspond aux événements de création de session conservés et horodatés dans les 24 heures précédentes, et non à une activité de session. Deux limites comptent ici : l’aperçu de la charge utile est construit dans le processus CLI et non récupéré auprès de la passerelle en cours d’exécution, il ne garantit donc pas la prochaine charge utile exacte de la passerelle, et il décrit uniquement la requête cliente, il ne peut donc jamais vous montrer la localisation dérivée côté serveur. Si la sortie affiche Request: none, une automatisation ou une règle de vérification des mises à jour a déjà tout arrêté. La préférence elle-même est une clé ordinaire dans le fichier de configuration OpenClaw, et elle n’a rien à voir avec le suivi de consommation des fournisseurs, qui concerne les quotas et les coûts des fournisseurs.

Tous les moyens de couper les requêtes

La commande openclaw telemetry off désactive les statistiques de fonctionnalités anonymes, et telemetry.enabled: false fait la même chose depuis le fichier de configuration. DO_NOT_TRACK=1 ou DO_NOT_TRACK=true force les statistiques à l’arrêt même quand telemetry.enabled vaut true, mais laisse délibérément la vérification quotidienne en place sous la forme du GET sans corps. Pour arrêter toute requête automatique, réglez update.checkOnStart sur false, ce qui désactive les deux niveaux ainsi que l’avis de mise à jour même quand update.auto.enabled vaut true, et OPENCLAW_NO_AUTO_UPDATE=1 empêche lui aussi les requêtes de mise à jour automatiques. OpenClaw n’envoie par ailleurs rien du tout quand la variable d’environnement CI est vraie, au motif que les tâches de pipeline dépasseraient les opérateurs réels en nombre et rendraient les décomptes de versions et de plateformes inutilisables, même si définir OPENCLAW_TELEMETRY_ENDPOINT vers votre propre point de terminaison annule cette suppression, car un point de terminaison configuré signifie que l’exécution emprunte ce chemin exprès. Les commandes de mise à jour explicites restent disponibles quand vous choisissez de les lancer, donc la mise à jour volontaire d’OpenClaw restent entre vos mains, et tout cela se place naturellement à côté de les bonnes pratiques de sécurité OpenClaw.

Sur Diali

Diali exploite OpenClaw hébergé sur Diali en service hébergé. Chaque client reçoit un assistant distinct sur sa propre instance plutôt qu’une place sur une instance partagée, et la configuration d’exécution est générée depuis les réglages de votre tableau de bord puis réécrite à neuf à chaque version, si bien qu’une modification faite à la main dans le conteneur ne survit pas à une mise à niveau, tandis que tout ce qui est exprimé dans le tableau de bord survit. Les sessions, la mémoire et le reste de l’état vivent sur un volume persistant, là où se trouve aussi le résultat mis en cache d’une vérification réussie ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). Tarifs Diali présente les formules.

• La vérification quotidienne est active par défaut et tient entièrement dans un en-tête User-Agent.
• Les statistiques anonymes restent désactivées tant qu’un opérateur ne les active pas.
• La localisation approximative est conservée trois mois, et couper les requêtes ne l’efface pas.