De Emacs à Cursor, bientôt la fin de vos IDEs

Emacs en 1976, puis Vim, Sublime Text, JetBrains, VSCode, et aujourd'hui Cursor : pendant cinquante ans, l'éditeur de code n'a cessé d'évoluer, mais il est toujours resté sur la machine du développeur.

Et ce, pour une seule vraie raison : la latence entre le clavier et l'écran qui imposait que chaque caractère tapé donne un retour visuel immédiat.

Avec les agents, ce n'est plus nous qui tapons le code. On se contente d'écrire des prompts, de lancer des agents et de relire ce qu'ils produisent.

Autrement dit, le clavier ne sert plus qu'à écrire des instructions.

Du coup l'IDE local n'a plus aucune raison structurelle d'exister, et il introduit en prime tout un tas de problèmes qu'on ne devrait plus accepter en 2026 : machine saturée dès qu'on parallélise, secrets qui traînent partout, surface d'attaque supply chain qui explose.

Dans cet article, je détaille pourquoi je pense qu'on va arrêter de coder en local et à quoi devrait ressembler l'environnement de dev qui prend le relais.

Pourquoi on codait en local

L'IDE local existe parce qu'il faut zéro latence entre la frappe et le retour visuel.

Quand chaque caractère que tu tapes doit déclencher l'autocomplétion, le linter et le type-checker puis redessiner l'écran sans qu'on s'en rende compte, un éditeur distant à 80ms n'est tout simplement pas utilisable et le cerveau le sent immédiatement.

C'est la seule raison technique sérieuse de coder sur sa machine, parce que tout le reste de la stack avait migré dans le cloud depuis longtemps : les builds, les déploiements, l'exécution, la CI, le stockage.

L'éditeur, lui, était resté collé à la machine du dev uniquement pour cette histoire de latence à la frappe.

Mais on ne tape plus le code

Aujourd'hui, mon workflow quand je code ressemble à ça : j'écris un prompt, je lance un agent, je le laisse tourner pendant que je fais autre chose, je relis le diff qu'il produit et je le valide ou je le redirige vers une autre itération.

Le clavier ne sert plus à écrire du code, il sert à écrire des instructions.

Et écrire des instructions, c'est de la prose qui n'a aucun besoin de latence sub-frame. L'unique justification historique de l'IDE local vient de sauter.

Et si les agents arrivent à produire du code qu'on peut vraiment mettre en prod, c'est parce qu'on a appris à leur fournir le bon contexte au bon moment.

Sans cette stratification, ils partent dans tous les sens et tout le workflow ne tient pas.

Je l'écrivais déjà en 2023 dans La nouvelle ère de la programmation, à savoir que le dev deviendrait chef d'orchestre pendant que les LLM s'occuperaient des détails d'implémentation.

On y est, et un chef d'orchestre n'a pas besoin que son pupitre soit posé sur son MacBook personnel.

Ce que coûte vraiment de rester en local

Une fois que la justification "latence" tombe, on peut regarder honnêtement le bilan de ce qu'on garde en restant en local, et il n'est pas bon.

Une machine qui sature dès qu'on parallélise

Un agent qui code, c'est un build qui tourne en arrière-plan, des tests qui s'exécutent, un serveur dev qui se relance et tout un tas de fichiers watchés en permanence.

Donc si on en lance trois en parallèle sur un MacBook, on se retrouve avec les ventilateurs à fond, le swap qui s'envole, l'IDE qui rame, et généralement un des trois agents qui finit par timeout sur une commande.

Or le vrai gain des agents, c'est justement de pouvoir les paralléliser : pendant que l'un refactor un module, le second peut écrire les tests qui vont avec et le troisième préparer la PR.

La parade habituelle, c'est de passer par des git worktrees pour faire travailler chaque agent dans une copie isolée du repo. Ça règle proprement les conflits de branches, mais ne change rien au fait que les builds, les serveurs dev et les suites de tests se partagent toujours le même CPU et la même RAM.

On a juste poussé le problème d'un cran. On peut maintenant lancer trois agents sans qu'ils se marchent dessus sur Git, mais la machine reste plafonnée par ses ressources physiques.

En local on est plafonné par sa machine, alors qu'on devrait être plafonné uniquement par sa propre capacité à reviewer ce que les agents produisent.

Des secrets qui traînent partout

Si tu fais history | grep API_KEY sur n'importe quelle machine de dev qui tourne depuis quelques mois, le résultat est édifiant : des .env à la racine de chaque projet, des export OPENAI_API_KEY=sk-... lancés à la volée dans un terminal puis oubliés dans l'historique zsh, et les credentials AWS ou GCP en clair dans ~/.aws/credentials et ~/.config/gcloud/.

Aucune rotation, aucun audit, aucune isolation. C'est de l'amateurisme par rapport à n'importe quel standard de prod.

Et le pire, c'est que chaque agent qu'on lance sur cette machine hérite par défaut de tous ces accès sans qu'on s'en rende compte.

La surface d'attaque supply chain

Le cas qui m'a vraiment alerté récemment, c'est Get Shit Done (GSD), un outil compagnon de Claude Code dont le créateur s'est avéré malveillant et a glissé dans une mise à jour un malware qui exfiltrait les credentials de la machine.

La communauté a fini par forker le projet pour récupérer une version saine, mais entre-temps n'importe quel dev qui avait installé la mise à jour piégée passait directement ses clés à l'attaquant.

Et ce n'est pas un cas isolé, loin de là :

• Le code source de Mistral AI a été mis en vente sur des forums underground après une supply chain attack.
• GitHub a subi un breach à cause d'un plugin IDE compromis chez un de leurs développeurs.
• event-stream en 2018, ua-parser-js en 2021, et tous les paquets npm typosquattés qui sortent chaque mois.

Le problème de fond, c'est que quand un agent te demande l'autorisation d'installer un nouveau package, on valide la plupart du temps sans relire le diff de package-lock.json.

Et la vélocité des agents accélère mécaniquement le rythme auquel on installe du code tiers sur sa machine de travail.

Et l'enjeu n'a rien d'anecdotique. La cybercriminalité coûte déjà autour de 10 500 milliards de dollars par an en 2025, et le volume d'attaques sur début 2026 est en hausse de 10 à 20 % par rapport à l'an dernier, à des niveaux proches des records historiques. Au niveau d'une seule organisation, le coût moyen d'une fuite de données tourne autour de 4,5 à 4,9 millions de dollars, et chaque minute de downtime se chiffre entre 4 000 et 7 500 euros.

Notre machine de dev est devenue un environnement ultra-sensible sur lequel on installe n'importe quoi sans réfléchir, alors que c'est précisément l'endroit où traînent toutes nos clés d'accès aux systèmes de prod.

À quoi ressemble la suite

Des environnements cloud qui orchestrent des agents

L'éditeur disparaît au profit d'une interface dont le seul rôle est de lancer des agents, regarder leur travail au fil de l'eau, les interrompre et les rediriger quand ils partent dans la mauvaise direction.

Chaque agent tourne dans son propre sandbox jetable avec des credentials scopés et révocables, le code source ne touche jamais ta machine, et les npm install se font dans l'environnement isolé de l'agent et non pas dans le tien.

Il y a déjà des prémices avec Devin, les Cursor Background Agents, Codex Cloud ou Claude Code lancé dans des GitHub Actions, mais c'est encore positionné comme un complément à l'IDE local et non pas comme son remplaçant.

Je pense que la bascule va arriver vite parce que la pression vient des deux côtés à la fois : les devs veulent paralléliser plus de tâches pendant que les CISO veulent arrêter de voir des clés d'API et du code source de prod traîner sur des MacBook personnels qui ne respectent aucun standard de sécurité.

Ce qu'on construit chez Maleus

C'est précisément le vide qu'on cherche à combler chez Maleus, avec un environnement de dev cloud où les agents tournent dans des sandbox isolées et où on pilote tout depuis le navigateur, sans jamais avoir à ouvrir un terminal sur sa propre machine. Concrètement, ça veut dire :

• un cloud dev environment provisionné par projet, avec son backend, ses dépendances et son runtime gérés côté plateforme, qui remplace entièrement le setup local
• une isolation processus stricte où les secrets vivent dans l'environnement et ne sont injectés que dans le process backend qui en a réellement besoin, plutôt que d'être exposés sur le filesystem ou dans le shell de tous les outils périphériques qui tournent à côté
• un délai de grâce sur les npm install qui empêche un package fraîchement publié d'être exécuté immédiatement, pour neutraliser la fenêtre d'attaque typique d'une supply chain compromise
• une mise à jour automatique des packages déléguée à un agent cloud qui vérifie les diffs et les CVE avant d'appliquer, plutôt qu'un npm update local qui fait confiance aveuglément à la registry
• une sandbox kernel-level pour chaque agent, qui l'isole du reste de l'environnement et lui refuse l'accès à tout ce dont il n'a pas explicitement besoin pour la tâche en cours
• une visualisation du code directement dans le navigateur, avec les diffs et la review intégrés au même endroit que l'orchestration des agents
• un pilotage des agents depuis cette même interface web, où on lance un agent, on le regarde travailler, on l'interrompt ou on le redirige sans jamais sortir du navigateur

C'est probablement la direction que va prendre toute la chaîne d'outillage dev dans les deux ans qui viennent.

L'IDE local ne survivra plus que pour les cas particuliers où la latence à la frappe reste critique : jeu vidéo, embedded, certains contextes de debug bas niveau.

Conclusion

L'IDE local est un artefact d'une époque où on tapait le code, et ce n'est plus la nôtre.

Je ne dis pas qu'il disparaîtra demain, les habitudes mettent du temps. La transition se fera probablement par étapes : d'abord les agents long-running dans le cloud, puis la review dans le cloud, puis tout le reste.

Mais il n'a plus aucune raison structurelle d'exister, et il aggrave activement les problèmes de sécurité qu'on a tous sous les yeux sans vraiment vouloir les regarder.

L'environnement de dev des prochaines années sera cloud et multi-agents, et l'interface ressemblera plus à un orchestrateur qu'à un éditeur.

Ce qui veut dire que toute la chaîne de valeur "éditeur + extensions + linters locaux" est en sursis, et que c'est probablement là qu'il faut construire pour les prochaines années.