Discussion :

[Anthony]

L'interface CLI de GitHub collecte et transmet désormais par défaut des données de télémétrie pseudonymisées, ce qui suscite des inquiétudes quant à la protection de la vie privée au sein de la communauté

L'interface en ligne de commande (CLI) de GitHub a récemment commencé à envoyer par défaut des données de télémétrie pseudonymisées. Ce changement a été mis en lumière par des signalements d'utilisateurs et a suscité des inquiétudes quant à la protection de la vie privée au sein de la communauté, ainsi que des critiques concernant le fait que cette fonctionnalité soit activée par défaut.

GitHub est une plateforme propriétaire destinée aux développeurs qui leur permet de créer, stocker, gérer et partager leur code. Elle utilise Git pour assurer un contrôle de version distribué et offre elle-même des fonctionnalités de contrôle d'accès, de suivi des bogues, de gestion des demandes de fonctionnalités logicielles, de gestion des tâches, d'intégration continue et de wikis pour chaque projet. GitHub, dont le siège social est situé à San Francisco, est exploité par GitHub, Inc., une filiale de Microsoft depuis 2018.

Selon GitHub, la collecte de ces données a pour but d'aider l'équipe de développement à comprendre comment les fonctionnalités sont adoptées, ce qui lui permet de hiérarchiser les améliorations en fonction des habitudes d'utilisation réelles. L'entreprise souligne que ces retours d'expérience l'aident à orienter ses décisions, par exemple pour déterminer s'il convient de revoir la conception des fonctionnalités ou de se concentrer sur l'amélioration de domaines spécifiques si les données d'utilisation mettent en évidence une demande pour certaines commandes ou certains drapeaux.

« À mesure que l'adoption de GitHub CLI par les développeurs s'étend, notre équipe a besoin de savoir comment ces fonctionnalités sont utilisées dans la pratique. Nous utilisons ces données pour hiérarchiser nos priorités et déterminer si les fonctionnalités répondent aux besoins réels des utilisateurs », a indiqué GitHub sur son site. « Par exemple, lorsque nous lançons une nouvelle sous-commande, nous voulons savoir si quelqu'un l'utilise et comment. Si son adoption est faible, nous savons que nous devons revoir la visibilité ou la conception de cette fonctionnalité. Si une sous-commande est très utilisée avec certains paramètres, cela nous indique où nous devons investir pour améliorer l'expérience utilisateur. »

Quelles sont les données collectées

Les champs suivants sont inclus dans les événements de télémétrie. Les champs comportant une valeur "Portée de la commande" ne sont envoyés que pour les commandes relevant de cette portée.

• agent : Agent IA appelant gh, si présent (exemple : copilot-cli)
• architecture : Architecture CPU d'exécution (exemples : amd64, arm64).
• ci : Indique si gh fonctionne dans un environnement CI (exemple boolean).
• command : Nom de la commande gh (exemples : gh, pr, create).
• device_id : Identifiant aléatoire unique généré et stocké localement pour chaque combinaison utilisateur/appareil (pas un ID machine) (exemple : UUID).
• flags : Liste séparée par des virgules des noms des indicateurs utilisés pour appeler gh (exemple : body,title).
• github_actions : Indique si gh fonctionne dans GitHub Actions (exemple : boolean).
• invocation_id : Identifiant aléatoire unique généré à chaque invocation de gh (exemple : UUID).
• is_tty : Indique si gh fonctionne en mode TTY (exemple : boolean).
• os : Type de système d'exploitation hôte (exemples : darwin, linux, windows).
• timestamp : Horodatage de l'événement.
• version : Version de gh (exemple : 2.91.0).
• agent_hosts : Type d'agent du skill à récupérer (portée de la commande : skill, exemple : github-copilot).
• repo_visibility : Visibilité du dépôt du skill à récupérer (portée de la commande : skill, exemples : public, private, internal, unknown).
• sample_rate : Taux d'échantillonnage pour la télémétrie (portée de la commande : skill, exemple : int).
• skill_host_type : Catégorie d'hôte GitHub du dépôt du skill (portée de la commande : skill, exemples : github.com, ghes, tenancy, uncategorized).
• skill_names : Liste séparée par des virgules des noms de skill à récupérer (uniquement pour un dépôt public) (portée de la commande : skill, exemple : git-commit).
• skill_owner : Propriétaire du dépôt du skill (uniquement pour un dépôt public) (portée de la commande : skill, exemple : github).
• skill_repo : Nom du dépôt du skill (uniquement pour un dépôt public) (portée de la commande : skill, exemple : awesome-copilot).
• from_owner : Propriétaire du dépôt amont du skill (uniquement pour un dépôt public) (portée de la commande : skill, exemple :github).
• from_repo : Nom du dépôt amont du skill (uniquement pour un dépôt public) (portée de la commande : skill, exemple : awesome-copilot).
• upstream_source : Indique si le dépôt du skill est la source ou le rééditeur (portée de la commande : skill, exemples : none, republisher).
• install_count : Nombre de skills sélectionnés pour l'installation (portée de la commande : skill, exemple : int).

Les événements de télémétrie sont envoyés à l'infrastructure d'analyse interne de GitHub.

Comment vérifier les données transmises

En matière de transparence, GitHub souligne que l'interface CLI est open source et que les utilisateurs peuvent examiner directement l'implémentation de la télémétrie dans le dépôt cli/cli.

De plus, les utilisateurs ont la possibilité d'activer un mode log (journalisation) à l'aide d'une option de configuration ou d'une variable d'environnement. Ce mode leur permet de voir exactement quelles données seraient envoyées sans pour autant transmettre aucune information.

1. Variable d'environnement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export GH_TELEMETRY=log

2. Configuration de l'interface CLI :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gh config set telemetry log

En mode journalisation, GitHub CLI affiche le contenu de la charge utilse JSON (qu'il enverrait normalement) sur stderr. Cela permet d'examiner chaque champ avant de décider de conserver ou non la télémétrie activée. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ GH_TELEMETRY=log gh pr edit 42 --title "bug fix" --body "fixed a bug"
...
Telemetry payload:
{
  "events": [
    {
      "type": "command_invocation",
      "dimensions": {
        "agent": "",
        "architecture": "arm64",
        "ci": "false",
        "command": "gh pr edit",
        "device_id": "d80dc1eb-5c66-4bcd-bbc8-568e173bb977",
        "flags": "body,title",
        "github_actions": "false",
        "invocation_id": "51b4383c-23b1-47da-91d7-dcc8aa79dd1c",
        "is_tty": "true",
        "os": "darwin",
        "timestamp": "2026-04-22T00:00:00.000Z",
        "version": "2.91.0"
      }
    }
  ]
}

Cette commande ne peut journaliser les données de télémétrie que pour la commande et le contexte précis dans lesquels elle a été exécutée. Par exemple, la modification des variables d'environnement ou des comptes authentifiés peut modifier les événements et les dimensions d'événement inclus dans la charge utile.

Comment désactiver la télémétrie

Pour ceux qui préfèrent ne pas participer à la télémétrie, une option de désactivation est disponible et peut être configurée soit via une variable d'environnement, soit via un fichier de configuration. Lors de l'utilisation de variables d'environnement, il est également possible de recourir à la convention DO_NOT_TRACK.

Il existe trois façons de désactiver la télémétrie :

1. Définir la variable d'environnement GH_TELEMETRY (n'importe quelle valeur fausse convient : 0, false, disabled ou une chaîne vide) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export GH_TELEMETRY=false

2. Utiliser la convention DO_NOT_TRACK :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

export DO_NOT_TRACK=true

3. Utiliser la configuration via l'interface CLI :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gh config set telemetry disabled

Les variables d'environnement (options 1 et 2) ont priorité sur la valeur de configuration.

Malgré ces mesures, certains utilisateurs restent mécontents, notamment parce que la télémétrie est activée par défaut. Ironisant sur le sujet, un utilisateur a écrit sur un forum en ligne : « Je veux dire, c'est logique, bien sûr. Comment pourraient-ils autrement savoir ce que veulent les utilisateurs ? Utiliser un outil de suivi des bogues ? Utiliser leur propre logiciel ? Avoir un temps de disponibilité supérieur à 99,999 % ? /s »

Sources : GitHub (Télémétrie, Désactivation de la télémétrie)

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous cette initiative de GitHub crédible ou pertinente ?

Voir aussi :

GitHub annonce qu'à partir du 24 avril, les données d'interaction des utilisateurs de Copilot Free, Pro et Pro+ seront utilisées pour entraîner et améliorer les modèles d'IA de Copilot, sauf refus explicite

GitHub sous tension : certains utilisateurs mécontents se rebellent contre les fonctionnalités IA Copilot imposées, quand l'aide optionnelle au codage se transforme en prison numérique

Workflows GitHub Agentic offre l'automatisation des référentiels, l'exécution des agents de codage, tels que Copilot, Claude ou OpenAI Codex, avec des garde-fous solides dans GitHub Actions

[qvignaud]

Si la télémétrie se comprends dans l'absolu, là quand même dans la CLI avec toutes ces informations c'est gros.

Alors bon, ok Github étant Microsoft, pour ceux qui sont sous Windows niveau vie privée (j'ai même plutôt envie de parler d'« intimité ») ça change pas grand-chose, mais la CLI j'ai un peu de mal à me faire à l'idée de me faire pister dedans… Le terminal sur mon laptop c'est l'équivalent de ma chambre chez moi.
Les variables d'environnement et les secrets qu'elles peuvent contenir, que ce soit sur ma machine ou dans l'infra qui aurait gh dans ses script ?

D'ailleurs c'est même presque ça le plus gros problème que je vois : tous les scripts d'infra sans la variable DO_NOT_TRACK/GH_TELEMETRY qui vont tranquillement faire remonter les infos internes "pseudonymisées" (sauf qu'avec l'IP d'où ça vient on sait très bien à quelle orga ça correspond). Pour le moment c'est l'arch, l'OS, les agents, les skills, ce qui est déjà beaucoup pour savoir ce qui est fait et jusque là non exposé, mais qui sait ce qui sera rajouté plus tard ?

Ça veut améliorer les choses mais on est sans doute dans un bon cas d'enshitification… Et si on parle en plus des histoires de runners externes que Github a voulu commencer à facturer (ok ils ont fait machine arrière, mais bon ça reste un sujet qui rôde), l'utilisation du code pour entraîner les modèles, peu importe que le dépôt soit public ou privé, etc. Baaah bof quoi. Puis point de vue nouveautés vraiment utiles c'est pas forcément ça non plus.

Mine de rien heureusement ça bouge sur ces sujets du côté de l'Europe.
Nous par exemple on fait Cadence.CI pour tout ce qui est DevOps et run d'intégrations.

[weed]

Mine de rien heureusement ça bouge sur ces sujets du côté de l'Europe.
Nous par exemple on fait Cadence.CI pour tout ce qui est DevOps et run d'intégrations.

La principale problématique que je vois est la position dominante. Quand on est en position dominante, on a ensuite tendance à être plus curieux. Pour Github, nous avons même de plus en plus de projet libre hébergé sur les dépots.
Qu'est ce que Cadence.CI ? Tel que je comprends des scripts qui s'interfacerait avec github et bypasserer les commandes de base de github, tout en profitant de l'infrastructure de Githhub. AI je bien résumé ?

Au même titre que l'Europe commence à se réveiller qu"il serait bien de ne pas faire appel à une unique entreprise : Microsoft pour son administration (le Danemark, certains Länder Allemand, la sécu Française, les impôts Français, ...) , il serait peut être intéressant d'avoir se propre infrastructure avec son propre dépôt.