GitHub CLI collecte désormais une télémétrie pseudonymisée

• La télémétrie pseudonymisée est envoyée par GitHub CLI afin d’obtenir de la visibilité sur l’usage des fonctionnalités et d’aider à améliorer le produit
• L’adoption des sous-commandes et les habitudes d’utilisation des flags servent à définir les priorités, à évaluer si les besoins des utilisateurs sont satisfaits, et à réexaminer la discoverability ainsi que le design
• Grâce à une implémentation open source, il est possible d’examiner directement le code de télémétrie dans le dépôt cli/cli, et le mode logging permet de voir la charge utile JSON avant tout envoi réel
• L’opt-out est possible via les variables d’environnement GH_TELEMETRY=false, DO_NOT_TRACK=true ou gh config set telemetry disabled, les variables d’environnement ayant priorité sur la configuration
• Les événements de télémétrie sont envoyés vers l’infrastructure d’analyse interne de GitHub ; cette page traite uniquement de la collecte de données côté client de gh, tandis que les extensions et Copilot CLI relèvent d’un cadre distinct

---

Télémétrie

• GitHub CLI envoie une télémétrie pseudonymisée afin de contribuer à l’amélioration du produit
• Des informations sont fournies pour permettre aux utilisateurs de comprendre quelles données sont envoyées et pourquoi

Pourquoi collecter la télémétrie

• La nécessité d’obtenir de la visibilité sur l’usage des fonctionnalités de GitHub CLI est mentionnée, en particulier avec l’augmentation de l’adoption agentique, afin de comprendre comment l’outil est réellement utilisé
  • L’équipe utilise ces données pour définir les priorités de travail
  • Elles servent à évaluer si les fonctionnalités répondent réellement aux besoins des utilisateurs
• L’objectif affiché est aussi de vérifier l’adoption après le lancement de nouvelles sous-commandes
  • Si presque personne ne les utilise, il peut être nécessaire de réexaminer la discoverability ou le design de la fonctionnalité
  • Si un usage élevé est constaté avec certains flags, cela permet d’identifier où investir pour proposer une meilleure expérience

Examiner la télémétrie

• GitHub CLI est open source, et l’implémentation de la télémétrie peut être examinée directement dans le dépôt cli/cli
• Pour voir les données qui seraient envoyées sans effectuer d’envoi réel, il est possible d’utiliser le mode logging
  • Méthode par variable d’environnement prise en charge
    • export GH_TELEMETRY=log
  • Méthode via la configuration CLI prise en charge
    • gh config set telemetry log
• En mode logging, la charge utile JSON qui serait normalement envoyée est affichée sur stderr
  • Cela permet de vérifier chaque champ avant de décider de laisser la télémétrie activée
  • Un exemple de commande est donné avec GH_TELEMETRY=log gh repo list --archived
• Les informations d’événement incluses dans l’exemple de payload sont précisées
  • Type d’événement : command_invocation
  • Les dimensions incluent agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
  • Les exemples de valeurs indiquent architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0
• Cette commande ne peut consigner en log que la télémétrie liée à la commande exacte exécutée et à son contexte
  • Si la variable d’environnement change, les events et les dimensions d’événement inclus dans le payload peuvent aussi changer
  • Les éléments inclus peuvent également varier si le compte authentifié change

Comment se désinscrire

• Il est possible de faire un opt-out de la télémétrie vérifiée en mode logging
• Méthode par variable d’environnement prise en charge
  • export GH_TELEMETRY=false
  • Les valeurs falsy 0, false, disabled, et la chaîne vide peuvent être utilisées
  • La convention DO_NOT_TRACK est également prise en charge, avec l’exemple export DO_NOT_TRACK=true
• Méthode via la configuration CLI prise en charge
  • gh config set telemetry disabled
• Les variables d’environnement ont priorité sur la valeur de configuration

Où les données sont envoyées

• Les événements de télémétrie sont envoyés vers l’infrastructure d’analyse interne de GitHub
• Pour plus d’informations sur le traitement des données, il est recommandé de consulter la GitHub General Privacy Statement

Informations supplémentaires

• GitHub CLI permet d’ajouter des fonctionnalités via l’installation d’extensions GitHub et tierces, y compris des agents
• Ces extensions peuvent collecter leurs propres données d’usage
  • Elles ne sont pas contrôlées par les paramètres d’opt-out
  • Il faut consulter la documentation de chaque extension pour savoir comment la télémétrie est envoyée et si elle peut être désactivée
• Cette page traite uniquement de la collecte de données côté client du CLI GitHub gh
  • Elle ne s’applique pas à GitHub Copilot ni à Copilot CLI
  • Copilot CLI gère séparément sa collecte de données
  • Les ressources indiquées sont Using GitHub Copilot CLI et Responsible Use of the GitHub Copilot CLI

[GN⁺]

Commentaires sur Hacker News

• Je me demande pourquoi les équipes de développement en entreprise veulent toujours observer les utilisateurs via la télémétrie
  J’aimerais demander si un bon travail d’ingénierie et de design ne suffit pas
  Git a très bien fonctionné pendant plus de 20 ans sans analyse détaillée de qui utilise quelles fonctionnalités et commandes, donc je me demande si la télémétrie l’aurait vraiment amélioré ou si elle n’aurait fait qu’ajouter des données parasites

  • Avant, moi aussi je pensais que c’était inutile, mais après avoir monté ma propre startup, j’ai changé d’avis
    Sans analytics, on a l’impression de conduire les yeux bandés
    On ne peut pas savoir ce que les utilisateurs jugent vraiment important, quels parcours il faut optimiser, et l’écart entre ce que les gens disent et la manière dont ils utilisent réellement le logiciel est étonnamment grand
  • Les développeurs et les utilisateurs ont des besoins et des points de vue différents, donc un bon design ne suffit pas à lui seul
    Il est souvent difficile d’obtenir un bon feedback des gens, et même si tout le monde dit aimer l’idée de la fonctionnalité X, il se peut qu’en pratique personne ne l’utilise
    De plus, une base de fans très bruyante ne se traduit pas forcément en revenus ni en usage réel
    Je pense que Git aurait probablement été meilleur avec de la télémétrie
    Git est célèbre pour avoir une mauvaise UI
    Les données auraient immédiatement montré à quel point les gens se perdent au début, et des améliorations comme git restore auraient probablement été introduites bien plus tôt à la place de commandes peu intuitives comme git checkout -- foo.txt
  • Malheureusement, je pense que ce phénomène vient du grand nombre de décideurs non techniques
    Comme les personnes qui n’utilisent pas elles-mêmes l’outil ne comprennent pas comment il est réellement utilisé, les PM en charge des outils de développement finissent par réclamer ce type de données pour faire leur travail
    Cela ressemble à la même logique que les PM e-commerce qui surchargent le front-end de scripts de suivi
    J’ai l’impression qu’avant, les ingénieurs pouvaient à eux seuls concevoir suffisamment bien les interactions utilisateur, mais qu’après l’arrivée du VC, on a figé un paradigme où des gens profondément non techniques dirigent des produits techniques
    Au final, les données leur reviennent, et quelqu’un peut ainsi justifier son salaire de PM
  • Je n’ai pas l’impression qu’on puisse affirmer avec certitude que la télémétrie n’aurait pas aidé Git
    Pour moi, ce n’est pas évident
  • Je trouve que Git est catastrophique en conception et en ergonomie
    C’est l’exemple type d’une interface conçue par des ingénieurs pour des ingénieurs, sans bonne boucle de retour
    Ironiquement, cet exemple montre justement que les développeurs devraient mieux comprendre comment leur produit est réellement utilisé
    Le scénario d’usage qu’un développeur a en tête diffère souvent pas mal de la réalité

• Je pense que la question de l’opt-out pour le CLI gh est plus complexe qu’il n’y paraît
  gh tourne aussi dans des pipelines CI/CD ou des environnements serveur, où l’on peut ne pas vouloir de connexions sortantes vers github.com, non pas pour des raisons de vie privée mais à cause de contraintes réseau
  Dans ce genre d’endroits, si la télémétrie est activée par défaut, le CI peut échouer ou un bastion host peut être totalement incapable d’atteindre GitHub
  Git, lui, fonctionne entièrement en local tant que l’utilisateur ne fait pas explicitement un push
  Le modèle de confiance est donc différent
  Git ne phone home jamais sans configuration explicite, alors que gh est un wrapper autour de l’API GitHub, donc j’admets que des appels sont nécessaires à son fonctionnement
  Mais indépendamment de cela, il faut quand même se demander s’il faut en plus collecter et envoyer les schémas d’usage des commandes

  • Je ne pense pas que le programme va planter avec une erreur fatale simplement parce qu’il ne peut pas envoyer la télémétrie
  • Je me demande si gh est en pratique inutilisable s’il ne peut pas se connecter à GitHub.com
    Ou bien est-ce que le principal cas d’usage est la connexion à GitHub Enterprise

• Si trois développeurs passent 80 % de leur temps sur une zone du codebase qui n’a en réalité aucun usage, et qu’il n’y a aucune perspective réaliste que cela change, il vaut peut-être mieux redéployer ces ressources ailleurs ou repenser la fonctionnalité elle-même
  Le problème avec ce type d’analytics, c’est qu’il repose sur l’idée qu’on peut l’utiliser de manière inoffensive, alors qu’en liant des identifiants uniques à des schémas de comportement, on peut reconstruire une identité via l’apprentissage automatique
  Avec des horodatages, c’est encore pire
  C’est pourquoi j’aimerais qu’on montre précisément quelle télémétrie est envoyée et quand
  On pourrait par exemple proposer une option qui n’envoie rien mais affiche en mode verbose ce qui serait transmis, afin que l’utilisateur puisse l’examiner avant de décider de l’activer
  Une approche du type Steam Hardware Survey, qui montre ce qui est envoyé, me semble la bonne

• Toutes les commandes gh ne sont au fond que des wrappers de l’API GitHub, ce qui rend ce débat encore plus confus à mes yeux

• J’aime bien les PR aussi courtes
  https://github.com/cli/cli/pull/13254
  Le contenu est simple, et je le lis comme la suppression de la variable d’environnement qui bloquait la télémétrie, pour passer à une activation par défaut

  • J’ai même l’impression que ce n’est pas seulement activé par défaut, mais carrément impossible à désactiver
    En dehors d’Enterprise, cela ressemble à quelque chose d’activé de force

• Je suis vraiment content d’avoir déployé gitea sur mon homelab le mois dernier
  Il y a même une fonction d’import depuis GitHub, et honnêtement je le trouve plus rapide que GitHub avec un meilleur uptime
  Claude fonctionne aussi très bien avec le CLI tea et Git, et même si c’est pratiquement un clone de GitHub, pour l’instant je le trouve plutôt meilleur

  • J’utilise Forgejo, qui partage le même code de base, et je le trouve vraiment excellent
    C’est rapide et l’uptime est bon
    Il tourne même sur un Pi 4 dans le meuble à côté de mon bureau, donc il continue de fonctionner même quand Internet tombe
    J’envoie les sauvegardes hors site avec borg et syncthing
    Il faut un peu mettre les mains dans la config, mais ensuite le temps de maintenance est proche de zéro
    Environ une fois toutes les deux semaines, je me connecte juste en SSH pour vérifier l’espace SSD, l’usage de la RAM, apt update, upgrade et les montées de version majeures

• Je me demande si les gens ne pensent pas déjà que GitHub collecte et agrège toutes les requêtes qui arrivent sur ses serveurs
  Après tout, la raison d’être du CLI gh est justement d’interagir avec ces serveurs
  Si on ne veut vraiment aucun suivi des requêtes, il faut probablement opt-out de bien plus de choses que de ce seul réglage

  • Puisque les données sont sur le serveur, j’imagine qu’ils les consultent déjà de toute façon
    Mais cette fois, ils semblent vouloir y ajouter des métriques côté client, pour mieux suivre non seulement ce qui va vers GitHub, mais aussi les flux qui vont vers GitLab, Codeberg et d’autres destinations

• Du point de vue de GitHub, ça peut être une bonne chose
  Toutes les entreprises ont besoin de ce type de données, certaines pour améliorer leur produit et d’autres pour des objectifs moins nobles
  Je sais que les utilisateurs de HN détestent la télémétrie, mais quand on a déjà construit un SaaS soi-même, on comprend que la telemetry est pratiquement indispensable

  • Pour moi, GitHub CLI n’est pas un SaaS, mais un utilitaire en ligne de commande
  • J’aurais préféré qu’on commence par demander directement aux utilisateurs
    Au fond, c’est l’absence de dialogue que je veux pointer
  • Je me demande quelle est la bonne pratique pour vérifier le contenu de la télémétrie d’un outil
    Tout se joue dans les détails, et je me demande s’il existe un service intermédiaire de confiance capable de créer un terrain d’entente acceptable à la fois pour les utilisateurs et pour les fabricants du produit
    Je précise que je rassemble mes recherches dans un Gist avec l’aide de Claude
  • J’ai l’impression que tous les défenseurs de l’IA ont le même ton

• Cela me fait penser au Embrace, extend, extinguish de Microsoft
  Les deux premières étapes sont déjà en cours, et je prédis que d’ici cinq ans, le CLI GH sera le seul moyen d’interagir avec les dépôts GitHub
  À ce moment-là, la troisième étape sera achevée et le cycle bouclé

  • Je suis prêt à parier contre cette prédiction
    J’ai presque envie de demander combien tu veux miser, tellement cela me paraît être une projection irréaliste
  • Ce genre d’affirmation est vraiment fatigant
    Les gens ont continué à plaquer le cadre EEE sur WSL, le support GPU, WSLg et PowerShell, mais rien de tout cela ne s’est produit
    C’est encore le cas aujourd’hui, et on voit à peine la moindre trace d’un tel plan
    Ce n’est pas quelque chose qu’on peut interpréter à l’intuition : je veux voir des preuves montrant où la méthode répétable réellement employée par Microsoft dans les années 90 se reproduit aujourd’hui
    Il n’y a pas de Microsoft Git verrouillé avec plus de fonctionnalités que l’open source, pas plus qu’il n’existe de Microsoft Linux dans ce sens
    GitHub est un wrapper autour de Git, avec comme conception fondamentale un serveur Git qui fonctionne sur HTTP et SSH
    Casser cette base pour verrouiller l’accès aux dépôts via gh uniquement serait un changement trop énorme pour être réaliste
    gh n’est qu’un outil qui simplifie les appels API, et la majorité des utilisateurs de GitHub ne savent même pas vraiment qu’il existe
    À mon avis, ce qui risque davantage de faire dérailler GitHub qu’un EEE malveillant, c’est une gestion incompétente
    J’ai l’impression qu’il est plus probable que le produit s’effondre à cause de dirigeants qui ne comprennent ni les utilisateurs ni le produit
  • Je ne doute pas complètement de cette prédiction
    Certains dépôts donnent déjà l’impression d’être pénibles à gérer sans gh, et je trouve qu’un flux imposé commence doucement à apparaître
    Je ne sais pas exactement ce que gh apporte de plus, car je ne l’ai pas utilisé, mais pour moi les commandes Git standard suffisent largement

• Je ne sais pas très bien si la pseudonymous telemetry dont il est question ici signifie de la télémétrie non identifiante, ou au contraire une télémétrie qui n’est pas vraiment anonyme
  Les deux expressions ont presque des sens opposés, et avec cette formulation on dirait qu’ils disent collecter des données identifiables

  • Sur la page en question, il n’y a que le terme pseudonymous, et pseudoanonymous semble être une expression inventée par l’auteur du post HN
  • Je comprends cela comme le fait que ce ne soit pas lié à l’identité d’une personne ni à un compte GitHub, mais qu’on puisse tout de même voir ensemble toute la télémétrie provenant d’une même machine
    Chaque machine semble recevoir un UUID, utilisé comme identifiant de cette machine