Télémétrie des Git GUI : qui vous traque en 2026

Télémétrie des Git GUI comparée : qui vous traque en 2026

La plupart des applications desktop collectent des données d'usage. Les Git GUI ne font pas exception. Cet article compare le comportement de télémétrie de quatre clients Git populaires — GitKraken, Fork, SourceTree et GitSquid — sur la base du trafic réseau observable. Les chiffres proviennent d'une session de capture de paquets de 24 heures sur chaque application, avec le même dépôt ouvert et une interaction utilisateur minimale.

Transparence : cet article est publié sur le site de GitSquid. La méthodologie est décrite en détail pour que vous puissiez reproduire les chiffres vous-même.

Pourquoi c'est important

"Télémétrie" est un mot doux pour "votre application envoie des données à son éditeur sans que vous le lui demandiez activement". Souvent les données sont véritablement bénignes : un compteur d'usage anonyme, un rapport de crash, une vérification de feature flag. Parfois c'est plus : sur quels boutons vous cliquez, quels dépôts vous avez ouverts, quelles fonctionnalités vous avez essayées.

Pour la plupart des utilisateurs ce n'est pas un problème. Pour trois catégories d'utilisateurs, c'est une contrainte forte :

• Industries régulées. Santé, finance, défense, gouvernement. Les processus de revue IT bloquent systématiquement tout outil qui téléphone à la maison avec des données identifiables.
• Travail sous NDA / propriétaire. Si vos noms de dépôts ou noms de branches contiennent des informations clients ou produits, les fuiter via la télémétrie est une vraie préoccupation.
• Développeurs soucieux de leur confidentialité. Certaines personnes ne veulent simplement pas que leur télémétrie de workflow soit collectée, peu importe à quel point elle se prétend anonymisée.

Méthodologie

Pour chaque application :

1. Installation fraîche sur un Mac (M2, macOS 15) sans historique préalable.
2. Configurée avec un dépôt local (le dépôt source de GitSquid, un clone synthétique sans remote).
3. Ouverture du dépôt dans l'application, puis application laissée focalisée mais inactive pendant 24 heures.
4. Capture du trafic réseau avec mitmproxy en mode transparent, certificat de confiance au niveau système.
5. Comptage des requêtes par domaine de destination. Exclusion des vérifications de mise à jour automatique (comptées séparément).

Le dépôt n'avait aucun remote configuré, donc tout trafic sortant pendant la fenêtre de 24 heures était soit de la télémétrie, soit de la validation de licence, soit la vérification de mise à jour automatique. Distinguer les trois est simple : la validation de licence touche un seul endpoint de serveur de licence une fois ; l'auto-updater touche une URL de manifeste de release connue une ou deux fois ; tout le reste est de la télémétrie.

Résultats

Deux des quatre applications n'envoient essentiellement rien. Deux envoient des dizaines à des centaines de requêtes par jour, même sans interaction utilisateur.

Où vont les requêtes

GitKraken

Destinations observées pendant la fenêtre de 24 heures :

• api.gitkraken.com — heartbeat de licence, rafraîchissement de session de compte, et vérifications de feature flag.
• analytics.gitkraken.com — analytics d'usage. Chaque navigation, ouverture de panneau et opération Git génère un événement.
• sentry.io — rapport d'erreurs (déclenché aussi sur les warnings, pas seulement les crashes).
• statsig.com — évaluation de feature flag et de tests A/B.
• logrocket.com sur certaines sessions — rejeu de session, quand activé.

SourceTree

• id.atlassian.com — rafraîchissement de session de compte, appelé périodiquement.
• sourcetree.atlassian.com — analytics d'usage des fonctionnalités.
• sentry.io — rapport d'erreurs.
• analytics.atlassian.com — analytics Atlassian inter-produits.

Fork

• git-fork.com/sparkle — manifeste de mise à jour automatique. Deux vérifications dans la fenêtre de 24h. Aucun endpoint de télémétrie contacté.

GitSquid

• github.com/TheMax98000/gitsquid-releases — manifeste de mise à jour automatique (`latest.json`). Une requête au lancement. À partir de la v2.7, cette vérification est obligatoire et non désactivable par l'utilisateur (un toggle dans les paramètres est sur la roadmap).
• gitsquid.dev/api/validate-license — validation de licence. Une requête au lancement uniquement pour les utilisateurs Pro (les utilisateurs Free ne touchent pas cet endpoint). Le corps de la requête contient uniquement la clé de licence en paramètre de query — pas d'identifiant machine, pas de données d'usage, pas de télémétrie. Si l'API est inaccessible, l'application bascule sur un résultat récent mis en cache, puis sur une vérification locale du checksum de la clé. Donc une licence Pro continue de fonctionner hors ligne, mais la vérification en ligne est le chemin par défaut quand le réseau est disponible.
• Aucun endpoint de télémétrie contacté à aucun moment. Pas d'analytics, pas de tracking d'événements, pas de service de rapport de crash, pas de service de feature flag.

À quoi ressemblent les données

Le nombre de requêtes est une chose. Le contenu de chaque requête en est une autre. Nous avons échantillonné quelques POST analytics de GitKraken :

• Chemin du dépôt (chemin local complet, hashé mais réversible si vous avez le sel).
• Nom de la branche actuellement checkée.
• Nombre de commits dans le dépôt.
• Quelles opérations Git ont été effectuées et à quelle fréquence.
• Quels panneaux d'UI ont été ouverts.
• Système d'exploitation, version de l'application, résolution d'écran.

Rien de tout cela n'est malveillant, et la politique de confidentialité de GitKraken le divulgue. Mais pour un utilisateur sous NDA, "le nom de la branche actuellement checkée" peut fuiter `feature/customer-acme-bug-fix` vers un serveur tiers, ce qui est exactement ce que les NDA interdisent typiquement.

Les payloads de SourceTree sont plus petits et plus anonymisés mais incluent toujours une empreinte du dépôt et des événements d'usage des fonctionnalités.

Peut-on la désactiver ?

Pour GitKraken et SourceTree, "télémétrie désactivée" n'est pas la même chose que "pas de trafic sortant". Le rafraîchissement de licence / session de compte continue indépendamment.

Pour les revues IT

Beaucoup de départements IT d'entreprise revoient les outils desktop avant de les approuver. Les questions qu'ils posent :

• Requiert-il un compte ? — Non pour GitSquid et Fork. Oui pour GitKraken et SourceTree.
• Téléphone-t-il à la maison ? — Pour GitSquid : oui, mais uniquement au lancement (1 vérification de mise à jour + 1 validation de licence pour Pro). Pas d'analytics, pas de trafic récurrent en arrière-plan. Pour Fork : uniquement le manifeste de mise à jour automatique. Pour GitKraken et SourceTree : oui, de manière récurrente tout au long de la session.
• La validation de licence est-elle capable hors ligne ? — Pour GitSquid : essaie en ligne d'abord (Pro uniquement), bascule sur un résultat récent mis en cache, puis sur le checksum local si les deux échouent. Une clé Pro continue de fonctionner sans internet ; la vérification en ligne est le chemin par défaut quand le réseau est disponible. Pour Fork : licence à vie, aucune validation nécessaire. Pour GitKraken : en ligne requis.
• Fuite-t-il des noms de dépôts / branches ? — Non pour GitSquid et Fork. Oui pour GitKraken (dans les payloads analytics), partiellement pour SourceTree.

Pour un environnement air-gapped, la vérification de mise à jour automatique et la validation de licence de GitSquid échoueront simplement silencieusement et basculeront sur le chemin mis en cache / hors ligne. L'application continue de fonctionner, mais les équipes IT peuvent vouloir être informées de ces deux requêtes sortantes au lancement. Un futur toggle dans les paramètres pour ignorer les deux simplifiera les déploiements dans les environnements stricts.

Pour un environnement strictement régulé, GitSquid et Fork sont les plus faciles à faire approuver — le seul trafic sortant est borné (lancement uniquement, pour GitSquid) ou limité aux mises à jour (Fork). GitKraken et SourceTree ne passent généralement pas sans accords de traitement de données négociés.

Reproduire ceci

Les chiffres ci-dessus ont été mesurés avec mitmproxy en mode proxy transparent. Pour reproduire sur votre propre machine :

1. Installer mitmproxy : brew install mitmproxy sur Mac, équivalent du gestionnaire de paquets sur Linux.
2. Configurer votre système pour router HTTPS via `localhost:8080`.
3. Faire confiance à la CA de mitmproxy au niveau système.
4. Lancer votre client Git, ouvrir un dépôt local, laisser focalisé.
5. Regarder le log de requêtes en direct dans l'UI de mitmproxy.

Vous verrez le compteur de requêtes monter en temps réel pour les clients riches en télémétrie, et rester plat pour les autres.

Le verdict honnête

La télémétrie n'est pas mauvaise en soi. Les éditeurs de logiciels l'utilisent pour corriger des bugs, prioriser des fonctionnalités et comprendre qui sont leurs utilisateurs. La politique de confidentialité de GitKraken est transparente sur ce qui est collecté, et les données les aident effectivement à construire un meilleur produit.

Le choix est de savoir si vous voulez ce compromis. Pour les outils grand public (navigateurs, lecteurs de musique), la plupart des gens l'acceptent. Pour des outils de développement tournant sur du code potentiellement sensible, davantage de développeurs disent non — surtout à mesure que les alternatives sans télémétrie deviennent aussi capables que celles qui traquent.

Si "trafic sortant minimal, pas d'analytics, pas de trackers tiers" est sur votre liste d'exigences, téléchargez GitSquid. Le lancement déclenche 1 à 2 requêtes (vérification de mise à jour + validation de licence pour Pro), puis plus rien pour le reste de la session. La même contrainte s'applique grosso modo à Fork (59 $ à vie, pas de Linux). Les deux passent la revue IT là où GitKraken et SourceTree ne passent généralement pas.