Un mot d'ordre circule depuis quelques mois : oubliez votre éditeur, si vous ne travaillez pas encore avec des agents, vous avez déjà décroché. La formule est efficace parce qu'elle mélange deux affirmations très inégales. L'une est solidement mesurée. L'autre est démentie par les chiffres mêmes qu'on invoque pour la soutenir.
La première affirmation — l'usage d'agents est devenu la norme du métier — tient. La seconde — l'éditeur de code est devenu inutile — ne tient pas, et il suffit de lire la même enquête jusqu'au bout pour s'en apercevoir.
Ce qui s'est réellement produit est plus intéressant qu'un remplacement : le travail de code s'est réparti sur trois surfaces qui coexistent, et la plupart des outils sérieux se sont mis à occuper les trois à la fois. Savoir laquelle sert à quoi vaut mieux que de choisir un camp.
Ce que disent les chiffres
La mesure la plus large publiée à ce jour vient d'une enquête publiée par JetBrains et menée auprès de plus de 15 000 développeurs professionnels entre mai et juillet 2026 : 90 % lancent un agent de code au moins une fois par semaine, 68 % tous les jours. Sur ce point, le mot d'ordre a raison : l'usage occasionnel n'est plus la position par défaut du métier.
Un second relevé, publié en mai 2026 sur un échantillon plus modeste — environ 1 100 réponses — donne un chiffre plus bas, 59 % d'usage au travail, mais une progression du même ordre : ils étaient 31 % un an plus tôt. Deux méthodes, deux populations, une même direction.
C'est la suite du tableau qui contredit la conclusion qu'on en tire. Dans la première enquête, GitHub Copilot recule à 21 % — il était à 29 % un an avant — mais 39 % de ses usagers y accèdent par un environnement de développement. Cursor, qui a popularisé le mode agent, plafonne à 12 %, en recul lui aussi — et Cursor est un éditeur. Les assistants intégrés aux environnements de développement pèsent encore 9 %. Personne n'a désinstallé quoi que ce soit.
Le signal le plus parlant est ailleurs, dans une enquête annuelle de 2025 : à la question portant sur les environnements de développement utilisés, Claude Code, qui vit dans un terminal, a été coché par 9,7 % des répondants. Ils l'ont rangé parmi les éditeurs, faute d'une case pour lui. La catégorie a cédé avant l'outil.
Pourquoi le terminal est revenu
La bascule tient à la forme du travail, pas à la mode. Un agent utile ne complète pas une ligne : il lit le dépôt, modifie plusieurs fichiers, lance les tests, lit l'échec, recommence. Cette boucle a besoin d'un endroit où exécuter des commandes et récupérer leur sortie brute. Le terminal est cet endroit depuis toujours ; il n'a pas eu à se réinventer, il a simplement cessé d'être un accessoire de l'éditeur pour redevenir le lieu principal de l'exécution.
Les chiffres suivent cette logique. Claude Code passe de 18 % à 39 % en six mois, et 31 % des répondants le désignent comme leur outil principal ; Codex, son concurrent direct, passe de 3 % à 16 %. Ce ne sont pas des parts prises à l'éditeur — l'éditeur perd bien moins que ces deux-là ne gagnent. Ce sont des parts prises à rien : à du travail qui n'était pas délégué du tout.
Ce que l'éditeur fait, que le terminal ne fait pas
Deux capacités de l'éditeur n'ont pas d'équivalent dans une boucle d'agent, et elles expliquent qu'il tienne.
La première est la transformation sûre. Renommer un symbole dans un projet, extraire une fonction, changer une signature : l'éditeur ne le fait pas en remplaçant du texte, il le fait en interrogeant le service de langage qui connaît la portée, les types et les références réelles. La documentation de Visual Studio Code le formule sans détour : les refactorisations proposées viennent du service de langage installé. La garantie est donc conditionnelle — pas de service, pas de garantie — mais quand elle joue, elle est d'une autre nature qu'une recherche-remplacement bien intentionnée.
La seconde est le régime de preuve du débogueur. Points d'arrêt conditionnels, points d'arrêt sur données, journalisation sans modifier le code, pile d'appels navigable image par image, variables modifiables en pleine session : la documentation de débogage décrit un dispositif d'observation de l'état d'un programme en cours d'exécution. Un agent, lui, procède par hypothèses successives et par ajout de traces. C'est parfois plus rapide. Ce n'est jamais la même chose que regarder.
Il y a une troisième raison, moins technique : c'est là que la relecture se fait. Le rôle décrit dans Le développeur, réviseur plutôt que producteur a besoin d'une surface où l'on voit le code, pas d'une surface où l'on voit un compte rendu du code.
La troisième surface : déléguer à une machine qui n'est pas la vôtre
La nouveauté réelle de 2026 n'est ni l'éditeur ni le terminal, mais la surface qui n'existait pas : l'agent qui travaille ailleurs, pendant que vous faites autre chose, et rend une proposition de fusion. Le volume est déjà considérable — plus d'un million de propositions ouvertes par des agents sur quelques mois de 2025, et la pente n'a pas fléchi depuis.
Cette surface a sa propre discipline, décrite dans Confier une tâche de code à un agent en arrière-plan et dans Où s'exécute le code que votre agent écrit. Elle a surtout sa propre limite, écrite noir sur blanc par les éditeurs eux-mêmes : les brouillons de propositions ouverts par un agent distant doivent être relus et fusionnés par un humain, et l'agent ne peut ni approuver ni fusionner quoi que ce soit. La délégation s'arrête à la porte de la décision.
Un fait achève de démonter l'idée d'un remplacement : les produits eux-mêmes ont cessé de tenir à une seule surface. Claude Code se décline en ligne de commande, en extension d'éditeur, en application de bureau, en exécution distante et en intégration d'usine logicielle. Cursor a ajouté des agents distants à son environnement. Copilot couvre la complétion, la conversation, le mode agent, l'agent distant et une ligne de commande. Junie, l'agent de JetBrains, est sorti de bêta avec une version en ligne de commande et une intégration d'intégration continue. Le débat « éditeur ou terminal » oppose des surfaces que les fournisseurs vendent désormais ensemble.
Ce qui casse quand on supprime une surface
Retirer une surface ne fait pas gagner de temps : cela déplace la facture. Trois déplacements sont documentés.
La revue absorbe ce que la génération économise. Une analyse portant sur 8,1 millions de propositions de fusion chez 4 800 équipes relève des propositions assistées de plus de 400 lignes contre 157, une prise en charge par le relecteur qui passe de 200 minutes à plus de 16 heures, et surtout un taux de fusion à trente jours de 32,7 % contre 84,5 %. Une seconde analyse, sur 22 000 développeurs, mesure une hausse du temps médian passé en revue et une progression des propositions fusionnées sans revue. Le programme de recherche DORA a donné un nom à ce phénomène : la taxe de vérification. C'est très exactement le sujet de La dette de compréhension du code généré et de Revue de code assistée par l'IA : qui décide ?.
La qualité se déplace vers la duplication. Une étude portant sur 623 millions de changements relève une forte hausse des blocs dupliqués par rapport à 2023 et un effondrement de la part du code simplement déplacé — l'indice le plus direct qu'on refactorise moins. Or refactoriser est précisément ce que l'éditeur fait le mieux.
L'exécution devient une surface d'attaque. Anthropic écrit dans la documentation de Claude Code que le bac à sable « réduit le risque mais ne constitue pas une frontière d'isolation complète », et que l'agent s'exécute sans bac à sable si les dépendances nécessaires manquent. En août 2025, la compromission du paquet Nx a enrôlé les agents de ligne de commande installés sur les postes pour en extraire des secrets, exposant plus de 6 700 dépôts privés. Le sujet est traité de front dans Choisir son assistant de code IA sans se tromper de critère.
Se situer, sans croire le mot d'ordre sur parole
Aucune enquête publiée ne ventile le code écrit par surface. La répartition décrite ici se déduit de signaux convergents, pas d'une mesure directe, et il faut le dire avant de proposer quoi que ce soit. Ce qui suit n'est donc pas un verdict, c'est un protocole que vous seul pouvez exécuter — sur votre dépôt, avec vos contraintes.
Reprenez vos dix dernières tâches. Classez chacune selon ce dont elle avait besoin : une transformation garantie par les types, une boucle d'exécution répétée, ou une délégation longue. Si les trois catégories sont peuplées et qu'une seule surface est installée, le manque est identifié.
Mesurez la file de revue, pas la vitesse de production. Le seul indicateur qui distingue un gain d'un déplacement est le délai entre l'ouverture d'une proposition et sa fusion, comparé à ce qu'il était avant. Il monte ? Le temps n'a pas été gagné, il a changé de poste.
Vérifiez ce que l'agent exécute, et où. La question n'est pas s'il a le droit d'écrire, mais quelles informations d'authentification sont lisibles depuis l'endroit où il s'exécute. C'est la seule partie de ce protocole où l'erreur ne se rattrape pas.
Traitez la fragilité comme une donnée d'entrée. Ces outils bougent vite, et pas toujours vers le haut : Gemini CLI a vu son accès coupé pour la plupart des abonnements en juin 2026, tout en continuant de publier des versions sur son dépôt public. Une surface peut survivre à l'offre qui la finançait. Aucune décision d'outillage ne devrait supposer une stabilité sur douze mois.
Le mot d'ordre a le mérite de la clarté, et c'est tout ce qu'il a. Ce qui change réellement le rendement d'une équipe n'est pas de choisir la bonne surface, c'est de savoir laquelle porte quelle preuve — et de garder la main là où la preuve manque. Les déplacements du secteur sont suivis semaine après semaine dans le radar IA.
Une question, un projet IA ?
Votre équipe hésite entre outiller l'éditeur, le terminal ou la délégation distante, et vous cherchez sur quoi fonder l'arbitrage ? Échangeons sur votre contexte.
Prendre contact →