3,7 fois moins de RAM que Cursor : ce que change une réécriture native

Sur r/programming, un développeur affirme être parvenu à diviser par 3,7 la consommation mémoire de son éditeur de code par rapport à Cursor, en abandonnant Electron au profit d'une architecture native. Le chiffre, mis en avant dans le titre même de son billet, relance un débat familier à tous les développeurs qui ont vu leur machine ralentir avec plusieurs fenêtres VS Code ou Cursor ouvertes en même temps.

Le contenu détaillé de ce fil Reddit n'étant pas intégralement accessible au moment de la rédaction, cet article s'appuie sur l'intitulé communiqué par l'auteur et sur l'architecture publique et documentée d'Electron pour expliquer, prudemment, ce qu'un tel gain implique concrètement. Ce qui suit ne prétend donc pas rapporter les détails d'implémentation de ce projet précis, mais décortique pourquoi ce type de résultat est plausible et ce qu'il change pour vous.

VS Code, Cursor et Electron : trois couches qui s'empilent

Rappel utile pour qui découvre le sujet. Visual Studio Code est bâti sur Electron, un framework qui permet d'écrire une application de bureau avec des technologies web (HTML, CSS, JavaScript) tout en l'exécutant dans un moteur Chromium complet. Cursor, de son côté, est un fork de VS Code : il hérite donc de la même fondation Electron, à laquelle s'ajoutent ses propres fonctionnalités de complétion et d'agents IA.

Concrètement, chaque fenêtre Electron embarque non pas un simple lecteur de texte, mais un navigateur web quasiment complet, avec son moteur de rendu Chromium, son moteur JavaScript V8 et un processus GPU dédié, plus un runtime Node.js séparé pour exécuter les extensions. C'est cette architecture, pensée avant tout pour la portabilité et la rapidité de développement, qui explique le poids en mémoire régulièrement pointé du doigt par les utilisateurs.

Pourquoi Electron consomme autant de mémoire

Le poids mémoire d'une application Electron ne vient pas d'un seul composant, mais de l'empilement de plusieurs éléments :

• Le processus principal, qui pilote le cycle de vie de l'application et communique avec le système d'exploitation.
• Un ou plusieurs processus de rendu, chacun exécutant une instance du moteur Chromium avec son propre tas mémoire V8, pour afficher l'interface.
• Un processus GPU dédié, hérité directement de Chromium, pour la composition et l'accélération graphique.
• Un extension host, un processus Node.js séparé qui exécute les extensions installées, chacune ajoutant sa propre empreinte.

Chacun de ces processus communique avec les autres par IPC (inter process communication), ce qui ajoute de la sérialisation, de la copie de données et donc, encore, de la mémoire allouée. Ouvrez plusieurs fenêtres ou plusieurs projets en parallèle, et vous multipliez une bonne partie de cet empilement à chaque fois.

Ce qu'une réécriture native change concrètement

Se passer d'Electron, c'est renoncer au confort de développer une seule fois en JavaScript, HTML et CSS pour cibler tous les systèmes d'exploitation. En échange, un éditeur natif peut :

• Dessiner l'interface directement, via les API graphiques du système ou un moteur de rendu GPU sur mesure, sans embarquer un navigateur complet pour afficher une barre latérale et un onglet de texte.
• Réduire le nombre de processus et donc de tas mémoire dupliqués, avec un seul runtime et pas de moteur JavaScript de navigateur à faire tourner en parallèle du reste.
• Limiter la surface d'IPC, puisque l'interface et la logique métier partagent le même espace mémoire au lieu de dialoguer à travers des canaux sérialisés.

C'est exactement la voie choisie par des éditeurs déjà publics comme Zed, développé en Rust avec un moteur de rendu GPU maison, ou Lapce, également écrit en Rust. Ces projets ne prouvent pas le chiffre de 3,7 avancé sur Reddit, mais ils illustrent la même logique : moins de couches entre le clavier et l'écran, moins de mémoire retenue par des composants qui ne servent pas directement à éditer du texte.

Comment vérifier tout ça sur votre propre poste

Vous n'avez pas besoin de croire quiconque sur parole : VS Code, et donc Cursor, embarque un outil pour observer sa propre consommation. Ouvrez la palette de commandes (Ctrl+Shift+P ou Cmd+Shift+P) et lancez :

Developer: Open Process Explorer

Vous verrez apparaître la liste de tous les processus de la fenêtre (main, renderer, extension host, GPU) avec leur consommation mémoire individuelle. Sur Linux ou macOS, un terminal ouvert sur ps aux, filtré sur le nom du processus, donne le même type de photographie, en plus brut. C'est le meilleur moyen de comprendre, sur votre propre poste, où part réellement la mémoire.

Si vous voulez comparer avec une architecture native, des éditeurs comme Zed ou Lapce s'installent en quelques minutes et permettent une observation directe, à charge de travail comparable, sans engagement ni réinstallation lourde.

Notre lecture chez CZSyn

Ce débat n'est pas nouveau, mais il revient régulièrement parce que le compromis d'Electron reste réel : vitesse de développement et écosystème d'extensions immense d'un côté, empreinte mémoire de l'autre. Pour une agence comme la nôtre, qui accompagne des développeurs et des équipes techniques sur des parcs de machines variés, la question n'a rien de théorique. Sur un poste vieillissant ou avec une quantité de RAM limitée, faire tourner Cursor ou VS Code avec plusieurs extensions actives, un serveur de développement et un navigateur ouvert en parallèle peut suffire à faire swapper la machine.

Notre position reste pragmatique. Electron n'est pas un mauvais choix : c'est un choix qui a permis à VS Code de devenir un éditeur de référence en quelques années grâce à son marketplace d'extensions et à sa portabilité. Mais si votre équipe travaille sur du matériel contraint ou si vous multipliez les fenêtres et les projets, tester une alternative native comme Zed ou Lapce sur un projet ponctuel coûte peu, et permet de juger sur pièces si le gain de fluidité justifie l'écosystème d'extensions plus restreint de ces outils plus jeunes.

Sources primaires

• Reddit, r/programming, « How I achieved 3.7x less memory usage than Cursor ».
• Documentation officielle Electron, electronjs.org.
• Visual Studio Code, site officiel, code.visualstudio.com.
• Zed, éditeur natif open source, zed.dev.