Michaël BIREPINTE for Onepoint

Posted on Oct 2 Edited on Oct 9

Y a t-il un (co)pilote dans l'avion de l'agentique?

#agents #ai #automation #productivity

Comme beaucoup de développeurs, à l'ère de l'IA agentique, il m'arrive régulièrement de travailler sur deux ou trois projets en parallèle, et plusieurs worktrees d'un même projet.
Ainsi, au moment où je pose les premières pierres de cet article, un agent traite une fonctionnalité client, un autre préanalyse les résultats de la campagne de tests de la veille, un troisième procède à une revue de code automatisée. Trois intentions de travail bien distinctes, donc — j'y reviens juste après —, lancées en parallèle sur trois terminaux différents.

Mon environnement de travail avant l'ADE : Zellij juxtapose LazyGit à gauche, pour suivre les modifications du code, et deux sessions GitHub Copilot CLI à droite, ouvertes sur des projets distincts. Le multiplexeur rassemble les terminaux à l'écran ; le suivi des intentions, de leur contexte et des résultats à relire reste à ma charge.

Agacé de jongler entre mes différents agents et mes sessions d'IDE, j'ai récemment découvert que le développement assisté par agents a finalement abouti à un nouvel environnement de travail pensé pour cette problématique : l'Agentic Development Environment, ou ADE.

Trois façons de développer avec un agent

Le développement agentique désigne aujourd'hui des réalités et des méthodes de travail très différentes. Au risque de procéder à quelques raccourcis, essayons d'en distinguer quelques-unes avant de nous intéresser à la pertinence de l'ADE.

Avant cela, un mot de vocabulaire que j'utiliserai tout au long de cet article : j'appelle intention un objectif de travail confié à un ou plusieurs agents — une fonctionnalité, l'analyse d'un bug, une revue de code, une exploration technique — avec son propre périmètre, son propre contexte et son propre critère de fin. Dans mon exemple d'introduction, la fonctionnalité client, la préanalyse de la campagne de tests et la revue de code automatisée sont trois intentions distinctes, qui peuvent porter sur un seul projet comme sur plusieurs. C'est bien cette multiplication des intentions — multi-projets, multi-tâches, multi-modèles, multi-harness — qui pose la vraie question de cet article : comment un développeur peut-il piloter correctement, avec un coût cognitif maitrisé, plusieurs agents à la fois ?

L'IDE augmenté

Cursor, Windsurf, Antigravity ou encore n'importe quel IDE équipé du plugin GitHub Copilot ou d'un équivalent : ce sont des outils très efficaces tant que le développeur travaille sur un projet ou une tâche unique. Le coût cognitif reste faible car tout le travail se déroule au même endroit.

Dès qu'il faut explorer plusieurs pistes en parallèle, comparer des variantes ou distribuer le travail entre plusieurs intentions, l'IDE montre ses limites :

les contextes se superposent ;
les branches se multiplient, souvent au détriment de la lisibilité ;
ouvrir deux ou trois instances de son IDE préféré peut considérablement réduire les performances de son poste de travail, à moins de disposer d'un calculateur du CEA, et porter préjudice au gain de vélocité promis par l'IA.

L'agent dans le terminal

L'agent-cli (Claude Code, GitHub Copilot CLI...) apporte une flexibilité supérieure. Il peut agir plus largement tout en étant plus économe en ressources système. Mais cette puissance ne résout pas le problème de l'organisation : les CLI modernes savent très bien créer et gérer des worktrees, ce n'est donc pas là que le problème se situe. La vraie limite reste la vue d'ensemble : suivre, comparer et arbitrer plusieurs intentions réparties dans autant de terminaux reste largement à la charge du développeur.

La code factory IA

La logique d'industrialisation est ici poussée à son maximum : un dispositif transforme une tâche de développement en un processus largement automatisé, de la spécification jusqu'à la production d'un résultat intégrable. Un ou plusieurs agents peuvent analyser la demande, écrire le code, exécuter les tests, corriger leurs erreurs et produire une branche ou une pull request. Suivant que l'on soit sur une logique human-in-the-loop ou non, le relecteur est soit un humain soit un autre agent.

Le modèle peut paraître alléchant pour des travaux répétitifs et bien spécifiés, mais il repose sur des conditions exigeantes. L'une de ces conditions, et pas la moindre, est de disposer de tâches suffisamment claires, découpées et testables. Or, dans la réalité des projets, beaucoup de tâches dépendent d'ambiguïtés métier, d'implicites ou d'un contexte non documenté, ou du moins plus à jour. Ce qui paraît industrialisable en théorie peut s'avérer beaucoup plus compliqué dans la pratique.

	IDE augmenté	Agent CLI	Code factory	ADE
Centre de gravité	L'éditeur	Le terminal	Le pipeline	L'orchestration des agents
Parallélisme	Faible	Possible avec multiplexeur	Élevé, automatisé	Elevé, un worktree par tâche
Isolation des contextes	Limitée	Possible moyennant configuration	Native (environnement jetable)	Native (environnement jetable)
Vue d'ensemble / supervision	Limitée au projet courant	Possible moyennant configuration	Partielle (résultat final)	Native

C'est à la lisière de ces trois méthodes de travail que l'ADE trouve sa pertinence. Il ne vise ni la simple assistance locale de l'IDE, ni l'industrialisation à outrance de la code factory. Il cherche plutôt à orchestrer plusieurs intentions de travail logiciel dans un cadre lisible, isolé et arbitrable. Son intérêt n'est pas seulement de faire intervenir un agent, mais d'éviter que leur multiplication ne fasse exploser la charge cognitive du développeur.

Vers une définition de l'ADE

L'émergence des Agentic Development Environments pose une difficulté de fond : l'appellation circule de plus en plus, mais elle ne désigne pas encore une catégorie parfaitement établie. Je ne vais pas prétendre trancher ce débat à la place du marché. Je choisis simplement d'aborder la définition sous un angle qui est le mien : considérer l'ADE comme une catégorie émergente, reconnaissable non par une norme déjà fixée, mais par un ensemble de propriétés convergentes.

Ce qui distingue d'abord un ADE, ce n'est pas la simple présence d'un agent dans l'environnement de développement. Un plugin Claude ou Copilot branché sur un IDE ne fait pas de ce dernier un ADE. Dans un ADE, l'environnement ne sert plus seulement à écrire du code, assisté ou non : il sert avant tout à piloter du travail agentique.

On passe d'un paradigme où l'IA assiste ponctuellement le développeur à un environnement où plusieurs intentions agentiques peuvent être lancées, coordonnées, isolées, comparées puis arbitrées.

Une grille de lecture

Plusieurs caractéristiques reviennent de manière suffisamment fréquente sur les différents produits du marché se revendiquant de la famille des ADE pour constituer une grille de lecture crédible.

Pour illustrer ces caractéristiques, je m'appuie ici sur Orca, l'ADE que j'utilise actuellement. Les captures ci-dessous proviennent de cet outil, qui rassemble dans un même environnement plusieurs agents, leurs terminaux et leurs espaces de travail.

Paralléliser : lancer plusieurs agents ou plusieurs tentatives sur des intentions distinctes.

Mes différents projets dans Orca : la barre latérale regroupe les espaces de travail par projet et permet de passer d'une intention à l'autre pendant que les agents travaillent en parallèle. (Documentation — Worktrees)

Isoler : donner à chaque tentative son propre contexte, sa branche ou son worktree.

Un worktree Git est un répertoire de travail supplémentaire rattaché au même dépôt, avec ses propres fichiers et sa propre branche, tout en partageant l'historique Git. Il permet de travailler sur plusieurs branches en parallèle sans devoir changer de branche dans son répertoire principal. Chaque agent peut ainsi modifier ses fichiers sans perturber le travail des autres ; leurs changements peuvent ensuite être relus et fusionnés.

Création d'un worktree dans Orca : je choisis le projet, la branche de départ et l'agent, ici GitHub Copilot, en associant l'espace de travail à un ticket Jira. Orca prépare un répertoire et une branche propres à cette tâche. (Documentation — Worktrees)

Superviser : suivre depuis un même environnement l'état et la progression des différentes intentions.

Le tableau de supervision d'Orca rassemble les agents de tous les worktrees selon leur état : « Vous concerne », « En activité » ou « Terminé ». Un aperçu des échanges permet de repérer les demandes d'intervention ; un clic sur une carte ramène au terminal de l'agent. (Documentation — Agent dashboard)

Comparer, arbitrer : disposer de résultats concrets — code, diff, tests, logs — permettant d'évaluer plusieurs solutions.

Orca embarque Monaco, l'éditeur utilisé par VS Code, pour éditer directement les fichiers et afficher leurs modifications en mode diff. Ici, les lignes ajoutées apparaissent en vert ; la vue de comparaison permet de relire les changements par rapport à une branche ou un commit de référence. (Documentation — Monaco, Diff viewer)

Ouverture : permettre de brancher différents agents, indépendamment de leur fournisseur ou de leur mode d’exécution, et intégrer les outils qui structurent le travail de l’équipe — Jira, Linear, GitHub ou d’autres systèmes. Une intention peut ainsi prendre naissance dans un ticket, être confiée à l’agent le plus adapté, puis voir ses résultats et son avancement réintégrés dans le workflow existant. L’ADE devient un point de convergence entre agents, projets et outils métier.

Le sélecteur d'agents propose notamment GitHub Copilot, Claude Code, Codex, OpenCode et Pi. Orca peut lancer tout agent disposant d'une interface en ligne de commande ; la profondeur du suivi et des intégrations varie selon l'agent. (Documentation — Supported agents)

Les sources de tâches connectent Orca à GitHub, GitLab, Linear et Jira. Elles permettent de retrouver les tickets dans l'environnement et de créer des espaces de travail associés ; les intégrations Linear et Jira permettent aussi de consulter et de mettre à jour les tickets. (Documentation — Worktrees, Linear, Jira)

Ce que ça change sur le marché

Cette grille permet de clarifier un marché encore confus. Tous les outils agentiques ne relèvent pas de la même catégorie.

L'IDE agentique reste principalement centré sur l'espace d'édition du développeur. Il enrichit l'IDE avec davantage d'autonomie, parfois de l'exécution en arrière-plan, parfois des actions plus complexes, mais son centre de gravité demeure l'expérience de codage dans l'éditeur.

La code factory, à l'inverse, est plutôt un agent d'exécution : on lui délègue une tâche, il agit dans un environnement isolé, puis il revient avec un résultat, un patch ou une pull request.

L'ADE occupe une autre place. Il ne se définit ni comme simple éditeur augmenté, ni comme agent autonome isolé, mais comme poste de pilotage d'un travail logiciel distribué entre plusieurs intentions agentiques.

Signe que ce mouvement dépasse le discours marketing : JetBrains vient d'annoncer JetBrains Air, un système ouvert pensé explicitement pour orchestrer, superviser et vérifier le travail de plusieurs agents (Claude, Codex, Copilot, Junie...) via un protocole commun. Qu'un éditeur de cette envergure construise une offre entière autour de ce besoin confirme que le pilotage multi-intentions n'est pas qu'une niche.

A mon sens, cette clarification est importante pour une raison très concrète : si l'on appelle ADE n'importe quel produit intégrant un agent, le terme perd immédiatement sa valeur descriptive. À l'inverse, si l'on réserve cette étiquette à des environnements capables d'orchestration, d'isolation, de multi-intentions, de gestion de contexte étendu et de convergence vers des sorties exploitables dans le même outil, alors la catégorie devient intelligible. Elle ne désigne plus une simple surenchère marketing autour de l'IA dans le développement, mais une transformation plus profonde de l'environnement logiciel du développeur.

Une transformation du métier

Bon, vous êtes parvenus jusqu'ici, et vous vous demandez encore probablement pourquoi se donner tant de mal à définir ce qui peut simplement apparaître de prime abord comme un outil de plus dans la boîte du développeur.

À mon sens, l'émergence de l'ADE ne marque pas seulement une amélioration de l'assistance au code ; il traduit un changement d'organisation du travail de développement. L'enjeu n'est plus uniquement d'aider un développeur à aller plus vite dans son éditeur, mais de créer un environnement où plusieurs intentions peuvent être produites, encadrées et arbitrées avec un coût cognitif maîtrisé.

Notre unité de travail n'est plus seulement la ligne de code ou la suggestion locale, mais la l'intention structurée : isolée, révisable et arbitrable.

Ainsi, qui sait si demain la compétence principale du développeur sera moins sa capacité à produire directement du code que sa capacité à piloter efficacement un système qui en produit.

DEV Community