Analyse des performances et de la télémétrie de Trae IDE, le fork de VSCode par ByteDance

(github.com/segmentationf4u1t)

2 points par GN⁺ 2025-07-28 | 1 commentaires | Partager sur WhatsApp

Trae IDE est basé sur VSCode, mais présente des problèmes de consommation excessive de ressources et de confidentialité
Il envoie en continu des données de télémétrie vers les serveurs de ByteDance, indépendamment des paramètres définis par l’utilisateur
Son utilisation des ressources atteint 6 fois celle de VSCode, avec un nombre de processus lui aussi nettement plus élevé
Lorsque la communauté soulève des problèmes de sécurité ou de confidentialité, cela entraîne une censure automatique et des sanctions
Il existe un problème d’absence d’explication transparente ou de contrôle utilisateur concernant les chemins et les finalités de la collecte de données

Analyse des performances et de la télémétrie de Trae IDE : examen interne du fork de VSCode par ByteDance

Executive Summary

Cette analyse se concentre sur les problèmes de performances et de confidentialité de Trae IDE (fork de Visual Studio Code par ByteDance).
Les principales constatations portent sur une consommation de ressources excessive (9 processus pour VSCode contre 33 pour Trae), une transmission continue de données malgré la désactivation de la télémétrie par l’utilisateur, ainsi que des problèmes de censure dans la gestion de la communauté.

1. Contexte et méthodologie de l’analyse

Dans le cadre de l’évaluation d’environnements de développement pour des projets personnels, trois IDE ont été comparés : VSCode, Cursor et Trae.
L’environnement de test a été configuré de manière identique et l’analyse s’est concentrée sur les différences de performances et de comportement réseau.

OS : Microsoft Windows 11 Pro
CPU : Intel Core™ i7-14700KF
RAM : 64GB
Projet de test : chargement de la même base de code dans les trois IDE
Outils de surveillance : System Informer, Fiddler Everywhere

2. Analyse de la consommation de ressources

Nombre de processus et utilisation mémoire

Dès le premier test, une forte différence de consommation de ressources entre les IDE a été constatée.

IDE	Nombre de processus	Utilisation mémoire	Impact sur les performances
VS Code	9	env. 0.9 GB	Référence
Cursor	11	env. 1.9 GB	2,1× plus de mémoire
Trae	33	env. 5.7 GB	6,3× plus de mémoire

Trae affiche 3,7 fois plus de processus que VSCode et une consommation mémoire 6,3 fois supérieure.

Retours de la communauté et résolution partielle

Après signalement du problème sur le serveur Discord de Trae, l’équipe de développement a reconnu le problème et a commencé à travailler sur des améliorations.
La version 2.0.2 a apporté quelques progrès, notamment une réduction d’environ 20 processus, mais le niveau reste élevé.

Après mise à jour (2.0.2) : environ 13 processus et environ 2.5GB de mémoire.

3. Étude du trafic réseau et de la télémétrie

Analyse réseau initiale

La surveillance a montré que Trae IDE communique en continu avec les serveurs de ByteDance.

Principaux endpoints :

Expériences sur les paramètres de télémétrie

Tentative de désactivation de la télémétrie

Même en utilisant l’option de blocage de la télémétrie dans les paramètres, aucun changement n’a été observé dans le comportement réseau.

Résultats inattendus

Les connexions vers les serveurs existants se maintiennent même après désactivation de la télémétrie
La fréquence de transmission des données augmente même dans certains cas

4. Analyse du contenu des données transmises

Payload de télémétrie en lot

Même lorsque la télémétrie est désactivée, des données d’usage détaillées sont transmises en temps réel, comme ci-dessous.

Informations système : spécifications matérielles, détails de l’OS, architecture, etc.
Modèles d’utilisation : temps d’activité/inactivité de l’IDE, historique d’utilisation des fonctionnalités
Indicateurs de performance : vitesse de réponse, utilisation des ressources, etc.
Identifiants uniques : machine ID, user ID, informations d’identification de l’appareil
Informations sur l’espace de travail : informations du projet, chemins de fichiers (partiellement masqués)

Suivi de l’activité utilisateur

Via des endpoints supplémentaires, des informations très détaillées sur les interactions utilisateur sont également transmises.

Cela inclut l’état connecté/déconnecté, le temps d’activité, le focus de l’éditeur, les fichiers utilisés, etc.

5. Problèmes de gestion de la communauté

Censure automatique

Le simple fait d’évoquer ces problèmes sur le serveur Discord a entraîné une mise en liste noire automatique et un mute de 7 jours
Des mots-clés comme "track" sont définis comme termes soumis à la censure automatique
Il y a eu une réponse répressive face au signalement de problèmes techniques

6. Implications en matière de confidentialité et de sécurité

Souveraineté des données et contrôle d’usage

Une collecte et une transmission continues de données ont lieu même lorsque l’utilisateur refuse
Des informations très détaillées sur l’appareil et l’activité sont envoyées vers des serveurs externes
Le cheminement des données collectées et la finalité de leur traitement restent flous, sans contrôle réel pour l’utilisateur

Manque de fiabilité et de transparence

Les paramètres de télémétrie n’ont pas d’effet concret
Les annonces officielles et explications sur la collecte des données sont insuffisantes
La censure des critiques et des lanceurs d’alerte au sein de la communauté réduit la transparence

Résumé essentiel

Trae IDE affiche une consommation de ressources 6 fois supérieure à celle de VSCode
Le paramètre de désactivation de la télémétrie semble n’être qu’une option de façade qui ne fonctionne pas réellement
Les discussions techniques saines au sein de la communauté sont limitées par la censure
Il y a un manque d’explications sur la collecte et le traitement des données, ainsi qu’une absence de choix réel pour l’utilisateur

Cette analyse a été réalisée sur les versions PRE-2.0.2 et 2.0.2 de Trae IDE, sur la base de juillet 2025.
Le trafic réseau a été capturé avec des outils de surveillance standard, et tous les résultats sont reproductibles.
Il est recommandé aux membres de la communauté d’effectuer eux-mêmes les tests et de partager les résultats via des canaux de communication plus appropriés.

1 commentaires

GN⁺ 2025-07-28

Commentaires sur Hacker News

Il y a aussi TheiaIDE, une réimplémentation façon VSCode issue d’Eclipse : site officiel de TheiaIDE. Il y a quelques années, il y avait encore des lacunes, mais maintenant c’est plutôt solide. TI a reconstruit Code Composer Studio sur une base Theia, donc il y a aussi de gros utilisateurs. Support du LSP, backend de l’éditeur Monaco, etc. : il a tout ce dont j’ai besoin. C’est proche de VSCode, mais avec une petite sensation « Eclipse ». Ça peut plaire ou non, mais ça vaut le coup d’être considéré comme alternative.
- Si je continue à utiliser vscode, c’est à cause de son support du markdown. J’utilise souvent la fonction qui insère des liens en glisser-déposer pour les fichiers et les images, et aucun autre éditeur ne semble proposer ça. Description de la fonctionnalité
- Plutôt que de forker vscode, je pense qu’il vaut mieux utiliser Theia, car il est difficile à modifier. Theia est géré de manière modulaire et permet de construire l’IDE souhaité comme une bibliothèque.
- Google Cloud Shell repose aussi sur Theia. Il me semble que c’est assez populaire.
- Je suis surpris qu’Eclipse soit encore vivant.
Même avec une collecte de ce type, je ne me sens pas particulièrement offensé :
- Informations système : caractéristiques matérielles, informations sur l’OS, architecture
- Habitudes d’utilisation : heures d’activité, durée des sessions, historique d’utilisation des fonctionnalités
- Indicateurs de performance : réactivité, occupation des ressources
- Identifiants uniques : ID machine, ID utilisateur, empreinte de l’appareil
- Informations sur l’espace de travail : informations sur le projet, chemins de fichiers (obfusqués) Je me demande si je suis le seul à ne pas trouver ça suffisamment intrusif pour être dérangeant.
- Sur mon ordinateur, je ne veux pas qu’un programme, ni même l’OS, communique sur le réseau sauf si c’est directement lié à une action que j’ai explicitement demandée via GUI/CLI. Je ne veux autoriser les communications exceptionnelles que si j’ai explicitement choisi d’y participer. Je pense que la fenêtre d’Overton actuelle autour des communications distantes est faussée.
- Je ne veux pas partager les identifiants uniques (ID machine, ID utilisateur, empreinte de l’appareil), les informations sur l’espace de travail (informations sur le projet, chemins de fichiers) ni les informations sur l’OS. Je préfère ne rien partager du tout.
- Même avec l’option « telemetry désactivée » activée, j’ai eu l’impression qu’une quantité de données plus importante que prévu était envoyée.
- Je veux toujours décider moi-même si je fournis ou non des informations. J’ai déjà renoncé à apprendre le langage Dart quand j’ai vu que l’installateur indiquait que Google collectait de la telemetry. Je n’arrivais pas à comprendre pourquoi même un langage de programmation devait faire ça. Je n’y ai plus retouché depuis.
Excellente analyse de VSCode, Trae et Cursor. Je serais aussi curieux de voir une analyse de Kiro (fork d’AWS). J’aimerais savoir comment ses pratiques de collecte de données diffèrent.
- D’après mon expérience réelle, Kiro est bien plus simple et rapide à faire passer dans les processus d’achats d’entreprise que les produits comparables (quelques jours contre plusieurs mois). Ce n’est pas parce que le produit est meilleur, ni parce qu’il serait objectivement plus privé ou plus sécurisé. La plupart des entreprises ont déjà des accords de partage de données avec AWS, donc les TAM peuvent facilement guider l’adoption de Kiro. En matière de protection des données personnelles / de sécurité, je prends les choses comme elles sont, mais dans le cas des entreprises il est intéressant de voir à quel point l’acceptation varie selon le niveau de visibilité publique.
Excellente analyse. Je me demande si la réduction du nombre de processus, de 33 à 20, vient du fait que la logique de telemetry a été déplacée ailleurs, ce qui aurait augmenté l’activité vers les endpoints. Je me demande ce que Bytedance a à dire là-dessus.
Ils ne veulent pas que la telemetry soit désactivée ; même si seule une minorité la coupe, c’est pareil. Je me demande pourquoi.
- On peut l’interpréter comme si désactiver la telemetry était un signal de « quelqu’un qui a quelque chose à cacher », ce qui pousserait au contraire à collecter encore plus de données.
- Il est aussi possible que ce ne soit pas un comportement intentionnel, mais simplement un bug qui n’a pas été corrigé.
- Je pense que l’interrupteur de telemetry lui-même ajoute du bruit aux données. C’est pourquoi je considère qu’il vaut mieux ne pas avoir de telemetry côté client du tout. Bien sûr, les fournisseurs pensent exactement l’inverse.
- C’est simplement appliquer le rasoir d’Occam (l’explication la plus simple, donc l’intention fondamentale).
Je suis très satisfait d’être récemment revenu à un TUI (helix editor). J’essaie aussi ZED, mais j’imagine qu’en tant que produit commercial, il y a probablement de la telemetry. Cela dit, apprendre à utiliser des règles avancées de pare-feu personnel reste toujours utile.
Je me demande pourquoi les gens utilisent un spyware aussi évident alors qu’il existe des logiciels libres.
- Il existe aussi des éditeurs comme Sublime Text qui, sans être gratuits, sont excellents et n’envoient pas votre code / votre travail à l’extérieur (par exemple au gouvernement chinois), donc sont relativement à l’abri des problèmes de telemetry.
- Je me pose aussi la question pour les produits de sociétés comme Microsoft, Apple, Google ou Amazon.
- J’ai l’impression qu’il y a énormément d’argent investi pour discréditer le logiciel libre.
- Les logiciels libres aussi ont beaucoup de telemetry. Sauf que ces données appartiennent en grande partie à GitHub.
- telemetry n’est pas synonyme de surveillance des utilisateurs. Dans bien des cas, cela ne relève pas de la surveillance des utilisateurs, donc je comprends aussi pourquoi les gens utilisent ce type de produits.
J’ai deux réflexions :
1. J’ai essayé de bloquer l’endpoint concerné avec pi-hole (en forçant un échec de résolution DNS), et ça vaudrait le coup d’expérimenter pour voir si le programme fonctionne correctement quand il ne peut pas joindre le serveur de telemetry.
2. Entre le suivi excessif, le non-respect du paramètre de désactivation de la telemetry et les réactions sur Discord, on peut déjà se faire une idée de Bytedance. On ne changera pas cette entreprise ; si on ne veut pas être pisté, la réponse est d’éviter les produits Bytedance dès le départ.
- Au lieu de pihole, sur la plupart des OS il suffit souvent de modifier le fichier hosts pour bloquer facilement un domaine donné.
- Je me demande quelles autres entreprises devraient nous inquiéter sur le plan du suivi des données.
- Si les connexions réseau vous inquiètent, on peut aussi recommander OpenSnitch ou Portmaster. Pour ma part, je ne fais jamais confiance à l’opt-out, et je ne peux plus vivre sans ces deux outils.
Les captures d’écran et les payloads fournis par l’OP ont rendu l’ensemble crédible. Pour qu’un IDE inspire confiance, la bonne approche est d’avoir par défaut la telemetry désactivée (opt-in) et un vrai coupe-circuit fiable.
Je ne comprends pas pourquoi quelqu’un utiliserait un fork de VSCode par Bytedance.
- Les fonctions IA y coûtent deux fois moins cher que chez les autres éditeurs (10 $/mois), et le forfait gratuit est aussi assez généreux. On dirait que la différence se paie autrement.
- En pratique, à moins d’être employé en interne, je ne vois pas de raison de l’utiliser. La principale différence avec la version MS, c’est l’ajout de fonctions IA, donc ce n’est pas surprenant.