D'Eclipse a Zed : l'evolution des editeurs d'un developpeur

Encore une journee de travail ordinaire.

Je jonglais avec trois projets simultanement — un frontend Next.js, un backend FastAPI et une application mobile Flutter. VS Code avait cinq fenetres ouvertes, Chrome devorait une enorme partie de la memoire. Les ventilateurs se sont mis a tourner, la souris a commence a saccader, et la frustration est montee.

« Pourquoi un editeur de texte a-t-il besoin de 3 Go de memoire ? »

A cet instant, j'ai realise qu'il etait temps de reconsiderer mes outils de developpement.

Avec le recul, j'ai change d'editeur plusieurs fois depuis ma premiere ligne de code. Chaque changement n'etait pas simplement un changement de logiciel — c'etait toute ma maniere de travailler qui evoluait.

L'ere Java : Eclipse → IntelliJ IDEA

Ma carriere de programmeur a commence avec Java. Grace a la synchronisation de Microsoft, je peux encore retrouver mes notes d'etude d'il y a plusieurs annees.

Quand j'ai commence a apprendre a coder, Eclipse etait pratiquement le standard pour le developpement Java. Honnetement, Eclipse etait complet en termes de fonctionnalites, mais il avait une « lourdeur » caracteristique — demarrage lent, interface disgracieuse, extensions en conflit permanent. Ouvrir Eclipse, c'etait comme demarrer un petit serveur.

Plus tard, en explorant par moi-meme, j'ai decouvert IntelliJ IDEA.

La premiere fois que je l'ai ouvert, j'ai ete stupefait : comment l'auto-completion pouvait-elle etre aussi intelligente ? Comment le refactoring pouvait-il etre aussi fluide ? Des operations qui necessitaient de modifier manuellement une douzaine de fichiers dans Eclipse se faisaient en un seul raccourci clavier dans IntelliJ.

C'etait comme passer d'un Nokia a un iPhone.

Pour etre honnete, je n'ai pas programme longtemps en Java avant de passer a Python. Mais l'experience IntelliJ m'a laisse une impression positive de JetBrains, et j'ai naturellement adopte leur suite complete. WebStorm pour le frontend, PyCharm pour Python, DataGrip pour les bases de donnees. Chaque IDE offrait une experience profondement optimisee pour son langage specifique, ce qui etait vraiment appreciable. Meme apres etre passe a VS Code, j'ai garde tous ces outils JetBrains installes — je les ouvrais a peine, mais je ne pouvais pas me resoudre a les desinstaller.

Vers le full-stack

Le tournant est arrive quand j'ai commence le developpement full-stack.

Le full-stack signifie qu'il faut toucher a tout. Python pour le backend, Vue et React pour le frontend, Flutter pour le mobile, un script Shell de temps en temps, plus Docker et divers fichiers de configuration. Avec autant de langages, j'ai commence a reflechir a changer d'outil. Certes, IntelliJ IDEA pouvait supporter de nombreux langages via des extensions, mais il restait trop lourd. Personnellement, je prefere construire mon environnement de developpement piece par piece, comme un jeu de construction, plutot qu'utiliser un IDE entierement preconfigure.

J'avais besoin d'un editeur « polyvalent ».

Avant de trouver VS Code, j'en ai essaye d'autres.

J'ai telecharge Sublime Text pour l'essayer — c'etait rapide, certes, mais beaucoup trop depouille. Son seul avantage semblait etre la vitesse ; tout le reste palissait en comparaison de JetBrains. J'ai aussi regarde Notepad++, mais cela ressemblait davantage a un bloc-notes ameliore qu'a un veritable outil de developpement.

L'age d'or de VS Code

L'apparition de VS Code a parfaitement resolu mon probleme.

Un seul editeur, differentes extensions pour differents langages, et tout est gere. Pylance pour Python, l'extension Dart pour Flutter, Volar pour Vue — le tout dans une seule fenetre.

Puis a commence mon long parcours de personnalisation.

J'ai change de theme au moins dix fois, essaye plusieurs packs d'icones, configure et reconfigure les raccourcis clavier. Snippets de code, extensions Git, extensions Docker, divers linters et formateurs... Sans m'en rendre compte, j'avais installe plus de 200 extensions.

Pendant cette periode, configurer VS Code etait devenu un loisir en soi. Je frequentais regulierement les communautes et forums a la recherche d'extensions utiles, et chaque decouverte procurait un sentiment de « tresor trouve ». La marketplace etait incroyablement riche, et chaque extension apportait un veritable gain de productivite — rien que pour l'environnement de developpement Python, j'en avais probablement installe une douzaine. Bien sur, il y avait aussi des extensions farfelues, comme vscode-pets, qui vous permet d'avoir un petit animal de compagnie dans l'editeur. Zero valeur productive, mais impossible de resister.

J'ai meme achete un abonnement pour une extension de base de donnees — Database Client — afin de centraliser tout mon travail dans VS Code. Elle permet de se connecter a diverses bases de donnees directement depuis VS Code, de previsualiser les donnees et d'executer des operations. Avec cela, je n'avais meme plus besoin d'ouvrir DataGrip.

Encore aujourd'hui, je continue a explorer toutes sortes d'extensions. Ce bricolage fait partie integrante du plaisir.

C'etait l'age d'or de VS Code. Plus precisement, c'etait la periode ou j'etais le plus productif dans l'optimisation de mes outils.

L'ere de la programmation IA

Ma premiere rencontre avec la programmation assistee par l'IA s'est faite via GitHub Copilot.

Visiter

A l'epoque, Copilot n'avait pas encore de fonction Chat — il suggerait discretement ce que vous pourriez ecrire ensuite. Vous tapiez un commentaire, et il completait automatiquement un bloc de code entier. La premiere fois que j'ai vu cela, j'ai ete veritablement impressionne — comment cette chose sait-elle ce que je veux ecrire ?

Bien entendu, avec le recul, ce ne sont que les bases de la programmation IA.

Visiter

Puis Cursor a fait sensation. Honnetement, j'ai ete un peu en retard, car j'avais encore un pack etudiant Copilot gratuit, et comme Cursor est essentiellement un fork de VS Code alors que GitHub Copilot etait veritablement le premier a faire de la programmation IA, j'ai toujours pense que Copilot etait le meilleur et n'avais aucune motivation pour changer.

Jusqu'a ce qu'un collegue me recommande d'essayer Cursor.

Apres l'avoir telecharge et essaye, j'ai realise qu'il etait bien superieur au Copilot de VS Code. L'ensemble de l'interaction etait plus fluide, et la comprehension contextuelle de l'IA etait bien plus profonde. Je ne comprends vraiment pas comment Copilot a pu en arriver la — ils avaient une longueur d'avance, et pourtant ils se sont fait depasser par un nouvel arrivant.

Puis Claude Code est arrive.

Visiter

Quand j'ai commence a utiliser Claude Code pour programmer, tout a de nouveau change. L'ancien flux de travail etait : ecrire dans l'editeur → executer dans le terminal → corriger dans l'editeur. Desormais, c'est devenu : dire a l'IA ce que vous voulez dans le terminal → l'IA ecrit le code → vous relisez.

L'utilisation du terminal a explose.

Avant, le terminal servait uniquement a executer npm run dev et git push. Il est devenu mon interface de programmation principale. Je passe la majeure partie de mon temps a dialoguer avec Claude Code, lui demandant d'ecrire du code, de corriger des bugs et de faire du refactoring. L'editeur est passe au second plan, devenant un outil de « lecture de code ».

Parallelement, l'IA ayant accelere la programmation, le nombre de projets sur lesquels je travaillais simultanement a augmente. Avant, je travaillais sur un projet par mois ; desormais, j'en fais avancer trois ou quatre en meme temps.

Cela a directement conduit au probleme suivant.

VS Code n'a pas tenu le coup

Plusieurs projets simultanes + plus de 200 extensions = catastrophe.

Chaque fenetre VS Code supplementaire consommait plusieurs centaines de megaoctets de memoire. Cinq fenetres, et les 3 Go etaient facilement depasses. Les ventilateurs de mon MacBook tournaient a plein regime, l'interface perdait des images, et je pouvais sentir la latence en tapant.

Ce n'etait pas un probleme isole. Recherchez « VS Code high memory usage » en ligne et vous trouverez d'innombrables plaintes similaires. Architecture Electron + quantite massive d'extensions + fenetres multiples = explosion de la memoire, c'etait pratiquement inevitable.

J'ai essaye diverses optimisations — desactiver les extensions inutilisees, utiliser les Profils pour charger differents ensembles d'extensions par projet, limiter les processus en arriere-plan. Il y a eu des ameliorations, mais cela ne traitait que les symptomes.

En fin de compte, VS Code est une application basee sur Electron. Electron signifie que chaque fenetre execute une instance complete de Chromium. Cinq fenetres, cela equivaut a cinq Chrome.

Le terminal roi : decouverte de Warp

Puisque la majeure partie du travail de programmation se faisait deja dans le terminal, celui-ci devait etre a la hauteur.

Le Terminal integre de macOS etait trop rudimentaire, et iTerm2 m'avait longtemps servi mais commencait a faire son age. Puis j'ai decouvert Warp.

Visiter

Ma premiere impression de Warp : la rapidite. Demarrage rapide, rendu rapide, reponse rapide. Puis il y a le concept des Blocks — chaque commande et sa sortie forment un « bloc » independant que vous pouvez selectionner, copier et rechercher comme dans un editeur de texte.

Apres une utilisation quotidienne, impossible de revenir en arriere. Quelques details marquants :

La zone de saisie est un veritable editeur, avec support multi-curseur, coloration syntaxique et auto-completion. Auparavant, si vous faisiez une faute de frappe dans une longue commande, il fallait maintenir les touches directionnelles pour naviguer lentement. Desormais, vous cliquez directement a l'endroit de l'erreur — cela semble evident, mais les terminaux traditionnels en sont tout simplement incapables.

Chaque Block dispose d'un petit bouton en haut a droite pour copier l'integralite de la sortie en un clic. Selectionner du texte dans un terminal traditionnel exigeait de glisser la souris avec une precision chirurgicale — un leger ecart, et vous selectionnez trop ou pas assez. Ce n'est plus un souci.

Pour les utilisateurs intensifs du terminal, ces ameliorations de l'experience sont considerables.

A ce stade, mon flux de travail etait devenu : 90 % du temps a programmer avec Claude Code dans le terminal Warp, VS Code n'etant ouvert que pour consulter l'historique Git — principalement avec GitLens pour voir qui avait modifie quel code et quand.

La decouverte de Zed

Le probleme, c'est que meme en utilisant VS Code uniquement pour lire du code, il consommait tout autant de memoire.

Un jour, en parcourant Twitter, j'ai vu Zed. J'ai clique — « A high-performance, multiplayer code editor from the creators of Atom and Tree-sitter ». L'equipe fondatrice comprend les createurs originaux de l'editeur Atom, ce qui a pique ma curiosite.

Telechargement, installation, ouverture.

Rapide. Tres rapide.

Pas le genre de « ca semble un peu plus rapide », mais plutot « voila la vitesse qu'un editeur devrait avoir ». Demarrage, ouverture de fichiers, recherche, navigation vers les definitions — chaque operation est instantanee.

A quel point exactement ? Il existe de nombreux benchmarks en ligne :

Source : Zed vs VS Code Performance Benchmark (2024)

Zed est ecrit en Rust avec un rendu GPU natif — aucune surcharge liee a Electron. Il peut ainsi avoir une douzaine de projets ouverts simultanement, avec une consommation memoire totale inferieure a celle d'une seule fenetre VS Code.

Zed a recemment ajoute le support des onglets de fenetre natifs de macOS, permettant de fusionner plusieurs fenetres de projets en une seule et de passer de l'un a l'autre via des onglets. Pour quelqu'un comme moi qui a une douzaine de projets ouverts simultanement, le bureau n'a plus besoin d'etre encombre de fenetres. La communaute reclamait cette fonctionnalite depuis longtemps, et elle est enfin arrivee.

L'activation est simple — il suffit d'ajouter "use_system_window_tabs": true dans les parametres de Zed. Pas besoin de redemarrer ; la prochaine fenetre ouverte adoptera automatiquement le nouveau comportement. Cela suit egalement les preferences systeme de macOS pour le comportement des onglets (toujours / jamais / en plein ecran), restant ainsi coherent avec le systeme.

En toute honnetete, Zed a ses faiblesses. La plus evidente est son ecosysteme d'extensions — encore jeune, de nombreuses extensions que vous tenez pour acquises dans VS Code n'existent pas encore dans Zed. Pas d'outil de visualisation Git au niveau de GitLens, et le support de certains langages n'est pas encore totalement abouti.

Mais pour moi, aucun de ces points n'est redhibitoire. Mes besoins fondamentaux vis-a-vis d'un editeur se limitent desormais a deux choses : lire du code et effectuer des modifications rapides. Le gros du travail est confie a Claude Code dans le terminal.

Mon flux de travail actuel

Apres tout ce parcours, voici ma combinaison actuelle d'outils de developpement :

Zed + Claude Code — Outils de developpement principaux. Zed gere une douzaine de projets ouverts sans aucune difficulte, utilise pour lire le code, effectuer de petites modifications et naviguer vers les definitions. Claude Code s'execute egalement directement dans le terminal integre de Zed — ecriture de code, correction de bugs et refactoring, tout se fait dans une seule fenetre.

Warp — Le terminal a retrouve son role legitime. Sauf que ce terminal est bien meilleur que tous ceux que j'ai utilises auparavant — un terminal veritablement moderne. Je ne comprends vraiment pas pourquoi les terminaux par defaut des differents systemes d'exploitation semblent encore bloques des decennies en arriere. Parfois, je lance aussi Claude Code directement dans Warp, car il dispose d'un panneau de fichiers integre et d'un affichage Git, ce qui est tres pratique.

VS Code — Apparition occasionnelle. Principalement pour utiliser GitLens et consulter les graphes Git. Honnetement, je l'utilise de moins en moins frequemment.

Chaque outil a son role. Zed pour « lire » et « ecrire », Warp pour les commandes quotidiennes, VS Code pour « investiguer ».

La logique fondamentale de ce flux de travail : editeur leger, terminal intensif. A l'ere de l'IA, la veritable programmation se fait dans le terminal. L'editeur n'a qu'a vous permettre de lire confortablement le code et d'effectuer des modifications rapides.

Si vous utilisez egalement Claude Code, je vous recommande de lire Mes meilleures pratiques pour Claude Code pour des conseils d'utilisation efficace, ainsi que Mon processus de controle qualite pour Claude Code pour garantir la qualite du code genere par l'IA. Pour approfondir la conception de Claude Code, consultez Analyse complete de l'architecture du systeme Claude.

Pour conclure

En retrospective de ce parcours d'evolution des editeurs :

Eclipse → IntelliJ IDEA → Suite JetBrains → Sublime Text (de passage) → VS Code + Copilot → Cursor → Claude Code + Zed + Terminal

Chaque changement n'etait pas du au fait que les anciens outils etaient devenus moins bons — c'est ma maniere de travailler qui avait change.

Quand je faisais du Java, IntelliJ etait le choix optimal. Quand je faisais du developpement full-stack multi-langages, VS Code etait le choix optimal. Aujourd'hui, a l'ere de l'IA avec un flux de travail centre sur le terminal, Zed + Warp est le choix optimal.

Il n'existe pas d'editeur eternellement meilleur — seulement celui qui convient le mieux a votre flux de travail actuel.

Si vous utilisez encore un editeur qui vous semble « acceptable sans plus », posez-vous la question : votre maniere de travailler a-t-elle deja change alors que vos outils n'ont pas suivi ?

Les outils sont au service des personnes. Lorsqu'ils commencent a vous freiner, il est temps d'en changer.