La mort de l’IDE ?

• Le centre de gravité du travail des développeurs se déplace de l’édition de code ligne par ligne dans l’IDE vers des interfaces d’orchestration et de supervision d’agents, et divers outils comme Cursor Glass, Claude Code Web et GitHub Copilot Agent accélèrent cette transition
• La nouvelle boucle de développement prend la forme « spécification de l’intention → délégation → observation → revue du diff → merge », où ce ne sont plus les fichiers mais les agents qui deviennent l’unité centrale de travail
• Des modèles comme l’isolation du travail (git worktree), la gestion de l’état des tâches, l’exécution asynchrone en arrière-plan et le routage de l’attention convergent dans l’ensemble des outils pour permettre l’exécution parallèle d’agents
• La fatigue de revue causée par des agents corrects à 90 % mais subtilement erronés, ainsi que la surcharge de sécurité et de gouvernance, émergent comme de nouveaux coûts
• L’IDE ne disparaît pas, il se décentre (de-centered) : il reste essentiel pour l’inspection fine, le débogage et les tâches complexes, mais n’est plus l’unique point de départ de la programmation

---

Du fichier édité au pilotage du flux de travail

• Les IDE traditionnels étaient optimisés pour une boucle interne serrée de type ouvrir un fichier → modifier → compiler → déboguer → répéter, mais comme les agents peuvent désormais exécuter de manière autonome l’essentiel de cette boucle, ils ne constituent plus l’unité dominante de la productivité
• La nouvelle boucle prend la forme « spécification de l’intention → délégation → observation → revue du diff → merge » ; ce qui la distingue d’un « autocomplétion avec fenêtre de chat », c’est l’association entre l’autonomie d’usage des outils et une interface qui rend cette autonomie contrôlable
• Claude Code Web (ou Desktop) et Codex reçoivent des tâches clairement définies à confier à des agents exécutés dans des environnements cloud isolés, avec suivi de l’avancement dans le navigateur — sans terminal ni configuration locale
• GitHub Copilot Agent planifie et implémente de manière autonome des changements multi-fichiers, puis va jusqu’à créer une branche, lancer les tests et soumettre une PR ; le rôle principal du développeur devient alors la revue du résultat et l’itération
• Conductor est une application de bureau qui exécute simultanément plusieurs agents Claude Code dans des espaces de travail isolés tout en fournissant un suivi en direct de leur progression
• Google Jules traite les tâches de façon asynchrone en arrière-plan — on assigne la tâche, puis on révise le résultat une fois le travail terminé
• Le modèle mental partagé par tous ces outils : l’unité de travail, c’est l’agent, pas le fichier — l’interface à optimiser n’est donc pas celle qui permet de taper plus vite, mais celle qui sert à diriger, surveiller et réviser les agents

La couche d’orchestration en train d’émerger

• L’isolation du travail (Work Isolation) s’impose comme primitive de base : puisque des agents parallèles ne doivent pas entrer en conflit, presque tous les grands outils adoptent git worktree (ou une approche comparable) — Conductor mappe chaque session d’agent à un espace de travail isolé, et Vibe Kanban applique la même approche à un workflow d’agents basé sur le kanban
• La planification et l’état des tâches deviennent l’interface de plus haut niveau : des outils comme Vibe Kanban remplacent les « onglets et fichiers » par des « tâches et états » — on crée des cartes de tâches (landing page, service backend, intégration e-mail, etc.), chacune étant assignée à un agent et à un modèle, puis on gère l’ensemble comme un tableau de projet léger où « l’équipe » exécute les tâches de manière autonome
• Agents en arrière-plan et conception orientée asynchrone : Cursor, Copilot, Antigravity et d’autres prennent en charge des agents en arrière-plan qui continuent à travailler sans intervention de l’utilisateur pendant l’exécution — on définit l’intention, on s’éloigne, puis on revient pour réviser le résultat ; Jules fonctionne de la même manière, sur l’idée que l’attention de l’utilisateur a trop de valeur pour rester fixée sur une barre de progression
• Gestion de l’attention pour les agents parallèles : quand plusieurs agents tournent simultanément, le vrai goulet d’étranglement consiste à identifier celui qui requiert une intervention immédiate — Conductor affiche la progression en direct entre les sessions, tandis que cmux introduit des anneaux de notification et des badges non lus dans les panneaux du terminal — « un agent a besoin d’attention » devient ainsi un événement de premier plan (first-class event) dans l’environnement de développement
• Des agents intégrés au cycle de vie logiciel : l’agent de codage GitHub Copilot est asynchrone, sécurisé par une couche de contrôle, et fonctionne sur la base de GitHub Actions — il ne se relie pas seulement à la façon dont le code est écrit, mais à la façon dont le code est réellement livré (issue → PR → CI → merge)
• Aucun de ces outils n’affirme que l’IDE est devenu inutile, et beaucoup restent interopérables avec les IDE ; mais les motifs récurrents — espaces de travail parallèles, revue centrée sur le diff, état des tâches, exécution en arrière-plan, intégration au cycle de vie — représentent précisément le déplacement du centre de gravité visé par l’idée de « mort de l’IDE »

Pourquoi les développeurs reviennent toujours à l’IDE

• Le contre-argument le plus solide à « l’IDE est mort » : l’IDE condense des problèmes difficiles — navigation de précision, raisonnement local, débogage interactif et compréhension du système par manipulation directe — dans une boucle de retour haute fidélité
• Même les outils d’orchestration les plus ambitieux conservent une porte de sortie vers l’édition manuelle — les workflows prévus incluent la revue du diff dans le fil, les commentaires sur les changements, puis les ajustements manuels dans l’éditeur
• Il existe aussi des domaines où les outils d’agents révèlent eux-mêmes leurs limites : les refactorings multi-fichiers dans de grands dépôts restent parmi les défis les plus difficiles pour les agents d’ingénierie logicielle — des situations qui exigent un modèle mental du système que l’agent ne peut pas entièrement reconstruire à partir du seul contexte
• Un mode d’échec continue de ramener les développeurs au niveau d’inspection d’un IDE : quand l’agent est correct à 90 % mais subtilement faux — le coût pour repérer le problème dépasse alors fréquemment celui de l’écriture directe, et pour les changements à haut risque, l’IDE reste l’outil le plus adapté à l’inspection de précision

Nouveau coût : fatigue de revue et surcharge de gouvernance

• Quand le développement devient une affaire de multiples agents exécutés en parallèle, le workflow hérite de problèmes de gestion de systèmes distribués plutôt que de simple édition de texte — observabilité, permissions, isolation, gouvernance
• Les workflows d’agents inversent la nature du travail : au lieu que l’écriture du code soit centrale, c’est la revue qui prend le dessus, et se retrouver en fin de journée face à 12 diffs produits par 12 agents parallèles fait de la fatigue de revue un problème bien réel — d’où l’attention portée par les outils les plus prudents au routage de l’attention, aux plans structurés et aux garde-fous de revue en amont
• À mesure que les agents accèdent à davantage d’outils — navigation web, requêtes base de données, écriture dans le système de fichiers, déclenchement de déploiements — la surface de sécurité s’élargit ; ce que l’agent est autorisé à faire devient aussi important que ce qu’il peut faire techniquement
• Du point de vue de l’observabilité et du contrôle, les modes d’agent intégrés aux IDE évoluent déjà vers des journaux d’outils explicites et des barrières d’approbation — dès qu’un agent agit de manière asynchrone et touche au pipeline CI, la gouvernance cesse d’être optionnelle

Ce qui survivra : IDE, control plane, ou les deux

• « La mort de l’IDE » est juste comme description d’un déplacement du centre de gravité, mais fausse comme prédiction littérale
• La version la plus forte de cette thèse : l’IDE recule du statut d’espace de travail principal pour devenir l’un de plusieurs outils subordonnés — il sert à l’inspection fine, au débogage et aux dernières retouches, tandis que la planification, l’orchestration, la revue et la gestion des agents migrent vers des tableaux de bord, des issue trackers, des terminaux d’observabilité et des control planes cloud
• Le cadrage du « plus grand IDE » est tout aussi défendable : le nouvel « IDE » est un système qui fournit orchestration multi-agents, espaces de travail isolés, permissions et journaux d’audit, revue centrée sur le diff, connectivité fiable aux outils et routage de l’attention — l’éditeur de fichiers existe toujours, mais ce n’est plus la porte d’entrée (front door)
• L’IDE ne meurt pas, il se décentre (de-centered) — le travail se déplace vers des surfaces d’orchestration, et l’humain consacre davantage de temps à définir l’intention, déléguer à des runtimes d’agents parallèles, puis superviser, réviser et gouverner
• L’IDE reste essentiel pour l’exactitude, la compréhension et les problèmes complexes que les agents peinent encore à résoudre, mais il n’est plus le seul lieu où la programmation se fait, ni même de plus en plus souvent le premier endroit où les développeurs se rendent