L’ère post-IDE

Je viens de résilier mon abonnement annuel à JetBrains.

Cela m’aurait paru presque impensable il y a quelques années. IntelliJ et le reste de la suite JetBrains étaient exactement le genre de logiciels pour lesquels je payais volontiers : des outils puissants et soignés, remplis de fonctions qui facilitaient considérablement l’écriture, la navigation, la refactorisation et le débogage de grandes bases de code. Pendant longtemps, pour moi, le développement logiciel se passait dans l’IDE.

Le problème, c’est que je n’en ouvre presque plus.

Ce n’est pas parce que j’ai arrêté de créer des logiciels. Au contraire, j’en crée probablement plus que jamais. La différence, c’est que j’interagis de moins en moins avec le code par l’intermédiaire d’un IDE. Je travaille avec Orgabot et d’autres environnements d’agents : je décris ce que je veux et laisse les agents examiner le dépôt, retrouver le code pertinent, modifier les fichiers, exécuter les tests, corriger les échecs, vérifier l’implémentation, ouvrir des pull requests, résoudre les conflits et poursuivre le travail.

Mon interface principale de programmation est progressivement passée d’un éditeur rempli de code source à une conversation sur l’intention. Le langage naturel est devenu mon langage de programmation.

L’IDE était une interface avec la complexité

Pendant des décennies, l’IDE a été le cockpit du développement logiciel. À mesure que les bases de code grandissaient et que les langages se perfectionnaient, les simples éditeurs de texte ne suffisaient plus. Les développeurs avaient besoin de navigation par symboles, de complétion intelligente, d’analyse statique, de refactorisation, de débogage, d’exécution des tests, d’explorateurs de bases de données, d’intégration du contrôle de versions, de gestion des dépendances et de dizaines d’autres commodités.

Des produits comme IntelliJ sont devenus extraordinairement efficaces pour résoudre ce problème, et lorsque je manipulais moi-même une base de code toute la journée, ces fonctions valaient largement leur prix. Mais, en prenant du recul, un IDE est surtout un outil qui aide une personne à comprendre et à modifier un vaste ensemble de fichiers source.

Le développement avec des agents change l’identité de celui qui effectue ces manipulations.

Le code est toujours là. Le compilateur aussi. Git, les tests, les analyseurs de code, les systèmes de types, les débogueurs, les gestionnaires de paquets et les outils de compilation n’ont pas disparu. Ce qui a changé, c’est que je suis de moins en moins celui qui les utilise directement. C’est l’agent.

Avez-vous encore besoin de lire le code ?

J’ai rarement besoin de regarder le code. C’est ce constat qui m’a finalement décidé à résilier JetBrains. Je n’ouvre presque plus jamais un IDE pour « coder ». Parfois, j’examine un fichier par curiosité pour une implémentation. Il m’arrive de faire une minuscule modification à la main, de regarder un diff ou d’enquêter sur quelque chose de particulièrement étrange.

Mais ces situations sont désormais des exceptions plutôt que mon mode de travail principal. Et lorsqu’il suffit d’examiner du texte, un éditeur basique convient parfaitement. Je n’ai pas besoin de plusieurs gigaoctets d’IDE et d’un abonnement annuel pour les rares fois où j’ouvre manuellement un fichier source.

L’immense majorité des fonctions d’IntelliJ dont je dépendais restent importantes. Je veux toujours une navigation intelligente, de la refactorisation, des tests, de l’analyse statique et de la revue de code. Je souhaite simplement de plus en plus que l’agent s’en charge au lieu de devoir manipuler chaque outil moi-même.

Les outils n’ont pas disparu. Ils sont passés sous la couche d’abstraction où je passe mon temps.

Pour ce que ça vaut, l’interface que je décris ici est documentée : Claude Code est construit autour du codage agentique depuis le terminal, et non autour d’une fenêtre d’éditeur.

Le langage naturel devient une interface de programmation

Les langages de programmation ont toujours essayé, à des degrés divers, de rendre les machines plus compréhensibles pour les humains. En nous éloignant du code machine et de l’assembleur, les langages sont devenus progressivement plus sémantiques. Nous avons obtenu des variables aux noms significatifs, des fonctions qui se lisent comme des actions, des structures orientées objet modélisant des concepts réels et des langages déclaratifs permettant de décrire davantage le résultat souhaité plutôt que chaque instruction nécessaire pour l’obtenir.

Mais cela restait des langages de programmation.

Si vous m’aviez dit il y a 30 ans qu’un jour je passerais une grande partie de mes journées à programmer en parlant ou en écrivant à un ordinateur en anglais courant, j’aurais pensé que vous racontiez des absurdités de science-fiction. Pourtant, c’est essentiellement ce que je fais aujourd’hui.

Évidemment, l’anglais ne remplace pas littéralement TypeScript, Python, Go, Java ou le langage qui implémente finalement le système. Mon processeur n’exécute pas un paragraphe que j’ai écrit à un agent. Mais cette distinction devient moins importante du côté humain de la pile technique.

Programmer a toujours consisté à traduire une intention humaine en quelque chose qu’une machine peut exécuter. Au fil du temps, nous avons constamment élevé le niveau d’abstraction du côté humain de cette traduction. Les humains manipulaient autrefois directement les instructions machine. L’assembleur leur a donné des noms. Les langages de haut niveau ont permis de décrire des algorithmes sans se soucier des registres. Les frameworks ont permis de décrire des applications sans implémenter chaque primitive. L’infrastructure sous forme de code a permis de décrire des environnements entiers plutôt que de configurer manuellement des serveurs.

Les agents ajoutent une couche. Au lieu d’exprimer nous-mêmes chaque détail d’implémentation, nous pouvons de plus en plus exprimer le résultat attendu :

• Ajoute la prise en charge d’OAuth pour ce fournisseur.
• Trouve pourquoi cet endpoint d’API renvoie parfois des données périmées et corrige-le.
• Refactorise ces services pour qu’ils partagent la même couche d’autorisation.
• Implémente cette epic GitHub et toutes ses sous-tâches.
• Vérifie les pull requests obtenues pour détecter les problèmes de sécurité et fusionne-les lorsqu’elles sont prêtes.

Ce sont des instructions de programmation. Le résultat peut représenter des milliers de lignes de code source classique, mais je n’en ai pas écrit personnellement la plupart. J’ai décrit le système souhaité, fixé des contraintes, évalué le résultat et laissé les machines traduire mon intention dans les langages dont elles ont besoin.

Il y a trente ans, placer l’anglais courant au sommet d’une pile de développement semblait relever de la science-fiction. Aujourd’hui, c’est ma manière habituelle de travailler. Le langage naturel ne remplace pas les langages de programmation sous le système ; il devient le langage de programmation que j’utilise.

La compétence précieuse n’a jamais vraiment été le langage

L’expérience de nombreux langages de programmation garde une valeur immense. Comprendre comment différents langages modélisent les types, la concurrence, la mémoire, l’état, les interfaces, les erreurs et l’abstraction donne un bien meilleur modèle mental pour évaluer ce qu’un agent produit. Cette expérience permet de reconnaître une mauvaise architecture, une complexité inutile, des interfaces fragiles et des choix d’implémentation susceptibles de poser problème par la suite.

Mais je pense que l’expérience de la construction de systèmes complexes est plus importante. Les langages ne sont, au fond, qu’un moyen d’atteindre un objectif.

Les difficultés du développement n’ont jamais simplement consisté à mémoriser la syntaxe ou à savoir quelle fonction d’une bibliothèque appeler. Elles consistent à placer les frontières, comprendre les interactions entre composants, anticiper les défaillances, gérer l’état, concevoir pour le changement, faire des compromis, déboguer les comportements émergents et reconnaître quand une implémentation apparemment raisonnable s’effondrera face à la complexité du réel.

Ces compétences survivent à la transition vers le développement avec des agents, et pourraient devenir encore plus importantes. Si un agent peut produire à la demande du TypeScript, Python, Go, Rust ou Java de qualité, la maîtrise d’une syntaxe particulière devient moins rare. Ce qui prend de la valeur, c’est de savoir quoi construire, comment assembler les éléments, quelles contraintes comptent et si le résultat est réellement bon.

C’est aussi pourquoi je ne pense pas que l’avenir appartienne uniquement aux personnes douées pour rédiger des prompts. Une consigne astucieuse ne remplace pas le jugement d’ingénierie. Quelqu’un qui construit des systèmes depuis des décennies peut examiner le plan d’un agent et constater que les frontières sont mal placées, que le modèle de données ne passera pas à l’échelle, que les hypothèses de sécurité sont faibles ou que l’architecture proposée résout le mauvais problème.

L’agent peut de plus en plus traduire l’intention en implémentation. L’humain doit toujours comprendre le système.

Pour moi, le véritable changement est là : le langage de programmation descend dans la pile, tandis que l’architecture, le jugement, l’orchestration et la pensée systémique remontent.

Cursor et Windsurf résolvent-ils cela ?

Cursor et Windsurf ne résolvent pas non plus ce problème. La réponse évidente consiste à dire que les IDE traditionnels déclinent peut-être, mais que les IDE natifs de l’IA comme Cursor et Windsurf représentent l’avenir. Je ne le pense pas.

Cursor et Windsurf restent fondamentalement des IDE. Ils supposent que le développement s’organise autour d’un humain qui regarde des fichiers source, parcourt un dépôt, sélectionne du code, examine des différences et dialogue avec l’IA dans un éditeur. Cela me paraît déjà être une étape intermédiaire.

Les deux ont depuis ajouté des agents en terminal et des interfaces d’automatisation, ce qui va réellement dans cette direction. Mais l’éditeur reste le produit : c’est là que les fonctionnalités atterrissent, là que va l’attention, et c’est ce que l’on paie.

Si je travaille avec Orgabot ou un autre environnement d’agents, je n’ai pas davantage besoin d’un éditeur enrichi par l’IA que d’un éditeur traditionnel. Je ne suis pas en train d’attendre la complétion, de sélectionner une fonction pour demander à l’IA de la réécrire ou de passer manuellement d’un fichier à l’autre pendant qu’un assistant regarde par-dessus mon épaule.

Je confie le travail à l’agent.

L’agent peut ouvrir les fichiers, chercher dans le code, examiner les dépendances, exécuter des commandes, lire les échecs des tests, modifier vingt fichiers, lancer des sous-agents, vérifier les changements et continuer à itérer jusqu’à la fin de la tâche. À ce stade, placer l’IA dans un IDE semble presque inverser la logique.

Le but n’est pas de rendre les humains considérablement plus rapides pour modifier du code. Le but est de leur demander d’en modifier considérablement moins.

Cette distinction compte. Cursor et Windsurf sont peut-être de meilleurs cockpits pour programmer avec l’IA, mais la direction que je prends nécessite de moins en moins un cockpit. L’interface principale devient la mission, le ticket, la spécification ou la conversation. Le code source reste essentiel, mais devient un artefact produit et manipulé sous cette interface, plutôt que l’endroit où je passe mes journées.

Quand j’ai résilié JetBrains, je ne l’ai donc pas remplacé par Cursor ou Windsurf. J’ai remplacé l’IDE par l’agent.

Je ne veux plus être le programmeur

Orgabot m’a fait aller encore plus loin. Quand j’utilise Orgabot pour créer une application ou une organisation, je n’aborde pas le travail comme un ingénieur logiciel mieux équipé pour coder. Je l’aborde du point de vue du directeur général.

Un directeur général n’ouvre pas un fichier source pour corriger une fonction. Il définit l’objectif, attribue les responsabilités, s’assure que les bonnes personnes ou les bons agents travaillent dessus, vérifie que le résultat répond à l’objectif et modifie l’organisation lorsque le processus se casse.

L’orchestration elle-même peut aussi être déléguée. Un directeur général peut demander au directeur technique de livrer un produit ; celui-ci coordonne alors l’ingénierie, la sécurité, l’infrastructure, la conception et les revues dans le cadre de cette mission. Le directeur général n’a pas besoin de savoir quel fichier contient le middleware d’authentification.

C’est de plus en plus ainsi que je construis des logiciels. Je peux dire :

• Construis ce produit.
• Résous cette epic et toutes ses sous-tâches.
• Cherche pourquoi ce système tombe en panne et corrige la cause profonde.
• Fais vérifier l’implémentation par la sécurité avant sa publication.
• Réduis le coût de ce processus sans dégrader la qualité.

Ces instructions créent du travail qui finit par produire du code, mais ce code se trouve plusieurs couches sous l’interface à laquelle j’opère.

Cela conduit à une règle utile : si le directeur général vérifie ou modifie du code source, un processus situé en dessous de lui est probablement défaillant.

L’agent d’ingénierie a peut-être échoué. Le processus de revue est peut-être faible. L’organisation n’a peut-être pas le bon rôle ou la bonne compétence. Les limites d’escalade sont peut-être mal définies. Quelle qu’en soit la cause, la réponse ne devrait pas être de ramener indéfiniment le directeur général dans l’implémentation. Il faut réparer le système pour que l’organisation gère correctement ce travail la prochaine fois.

C’est aussi pourquoi remplacer IntelliJ par Cursor, Windsurf ou un autre IDE avec IA m’intéresse peu. Ces outils rendent un programmeur plus efficace dans la couche du code. Orgabot cherche à faire de cette couche un endroit où je n’ai presque jamais besoin d’entrer.

L’IDE devient peut-être un détail d’implémentation

Voilà pourquoi je pense que nous entrons dans une ère post-IDE.

Cela ne veut pas dire que les IDE disparaîtront demain, ni même que les éditeurs graphiques de code disparaîtront. Il y aura toujours des moments où regarder directement le code sera le meilleur moyen de comprendre un problème. Mais je pense que l’IDE perd sa place d’interface principale entre le programmeur et le logiciel.

L’environnement d’agents devient cette interface, créant un problème stratégique délicat aussi bien pour les éditeurs d’IDE traditionnels que pour ceux d’IDE avec IA. La réponse évidente a consisté à mettre l’IA dans l’IDE : ajouter un panneau de discussion, de la complétion, un mode agent et la possibilité de modifier plusieurs fichiers à la fois.

Ces améliorations sont utiles, mais je me demande si leur architecture n’est pas inversée.

L’avenir n’est peut-être pas un IDE contenant un agent. C’est peut-être un agent contenant un éditeur.

L’agent devient l’environnement. Le dépôt, le terminal, le navigateur, le débogueur, l’éditeur, les tests, le système d’intégration continue, le gestionnaire de tickets et l’infrastructure de déploiement sont des outils à sa disposition lorsqu’il en a besoin. La plupart du temps, l’humain reste un niveau au-dessus.

Je n’ai pas résilié JetBrains parce que JetBrains s’est dégradé

Cette distinction compte. JetBrains ne m’a pas perdu parce qu’IntelliJ serait devenu un mauvais logiciel. Au contraire : IntelliJ reste une réalisation technique d’une puissance impressionnante.

J’ai résilié parce que ma manière de travailler a tellement changé que je n’ai plus besoin de 99 % de ses fonctions, et c’est une menace bien plus grande. Le problème concurrentiel le plus difficile n’est pas que quelqu’un construise une meilleure version de votre produit. C’est que le comportement des utilisateurs change au point de rendre la catégorie elle-même moins importante.

Pendant des années, je voulais le meilleur environnement possible pour modifier du code source. Puis j’ai voulu le meilleur environnement pour diriger des agents qui le modifient. De plus en plus, même cette description sous-estime la direction que nous prenons.

Je veux le meilleur environnement possible pour créer des organisations d’agents capables d’assumer des responsabilités, de déléguer le travail, de se vérifier mutuellement, de faire remonter les problèmes si nécessaire et de produire des logiciels sans m’obliger à descendre dans l’implémentation.

L’IDE n’est pas le centre de ce monde. C’est un outil qu’un des agents pourrait utiliser.

Après des années passées dans les IDE, je crois que je les ai peut-être enfin quittés.