Agent Development Environment

Un sigle avancé par des éditeurs, pas par une norme

ADE, pour Agent Development Environment, désigne la génération d'outils qui organisent le travail d'une flotte d'agents de codage sur un poste de développement. La formule vient des éditeurs eux-mêmes : la description du dépôt Orca l'emploie, « Orca is the ADE for working with a fleet of parallel agents », et le dépôt déclare simultanément les sujets GitHub ade et agent-ide.

La terminologie n'est pas stabilisée, et le même éditeur en emploie souvent plusieurs le même jour : ADE dans la description du dépôt, « AI Orchestrator » dans le README, « worktree IDE for AI coding agents » en pied de page, « desktop IDE for running multiple AI coding agents side by side » dans la documentation. D'autres acteurs préfèrent « runtime » ou « multiplexeur d'agents ». Le sigle circule assez pour être compris ; il désigne pour l'instant une intuition partagée plutôt qu'une catégorie établie.

Ce flottement de vocabulaire est un signal utile pour une DSI : la catégorie a moins d'un an, les produits qui la peuplent ont pour la plupart été créés en 2026, et aucun standard d'interopérabilité ne les relie. Le choix se fait donc sur des propriétés d'architecture, pas sur une conformité.

Ce que le sigle déplace : l'unité de travail

L'intérêt du terme tient à ce qu'il désigne un déplacement réel, indépendant des produits qui le revendiquent. Un environnement de développement classique s'organise autour du fichier ouvert : l'éditeur, l'autocomplétion, le débogueur et le terminal servent une personne qui écrit du code. Un ADE s'organise autour d'une unité plus grosse, produite par une machine et soumise à un jugement humain.

Deux définitions concurrentes de cette unité coexistent, et elles produisent des outils différents. Pour les uns, l'unité est la tentative : une tâche, une branche, un worktree git, un diff à arbitrer. C'est le modèle d'Orca, où l'on lance le même énoncé sur cinq agents pour ne fusionner que le meilleur résultat. Pour les autres, l'unité est la session longue : un processus qui tourne des heures ou des jours et qu'il faut retrouver vivant, avec son état. C'est le modèle de Herdr.

Dans les deux cas, le poste de travail cesse d'être un lieu de production pour devenir un lieu d'arbitrage. C'est le même mouvement que celui décrit par le passage du créateur au vérificateur, et il bute sur la même contrainte : multiplier les agents multiplie les sorties à juger, pas la capacité de les juger. L'effet miroir mesuré par DORA s'applique tel quel.

Deux familles d'implémentations

Les produits de la catégorie se répartissent selon ce qu'ils acceptent de posséder. La frontière est nette et elle prédit assez bien le coût d'adoption comme le coût de sortie.

Une analogie née d'un commentaire Hacker News résume le clivage et circule depuis dans la communauté : « Orca is like VSCode and herdr is like Sublime Text ». Riche et intégré d'un côté, léger et orthogonal de l'autre. Les deux familles partagent le modèle bring your own subscription : elles n'embarquent aucun modèle et lancent les agents auxquels l'équipe est déjà abonnée.

• Ceux qui possèdent l'environnement : éditeur, worktrees git, vues de diff, navigateur, suivi de tâches, application mobile. Orca, Conductor, Sculptor, Vibe Kanban. L'outil décide de l'organisation du travail, et son abandon emporte cette organisation.
• Ceux qui ne possèdent que le terminal : la session, son état, sa persistance, et une API pour la piloter. Herdr, cmux, ou tmux et zellij complétés de scripts. L'outil se retire sans rien emporter, mais ne prend en charge ni la revue ni l'isolation.

Ce qu'une DSI instruit avant le vocabulaire

Quel que soit le sigle retenu, l'usage en entreprise se décide sur des points dont aucun ne figure dans une démonstration produit.

Le dernier point mérite d'être pesé au moment de l'adoption plutôt qu'après. La catégorie compte une dizaine d'implémentations en un an, plusieurs financées par le même accélérateur, aucune avec un modèle économique publié ; Vibe Kanban, qui avait livré le premier plusieurs de ces fonctions, a fermé en avril 2026 avant d'être repris en communautaire. L'issue la plus probable tient moins à la victoire d'un produit qu'à l'absorption de la fonction par les agents eux-mêmes.

• Le mode de permission et le lieu d'exécution. Certains ADE préremplissent les drapeaux de contournement de permissions des agents qu'ils lancent, au motif qu'un worktree est jetable. Un worktree isole des fichiers versionnés, pas un système : l'agent garde le compte, les clés et le réseau de son opérateur.
• La capacité de revue de l'équipe. Combien de diffs par jour sont réellement absorbés aujourd'hui, tests et intégration continue compris.
• La fiabilité de l'état affiché. Un tableau qui annonce « bloqué » ou « terminé » repose soit sur des hooks officiels de l'agent, soit sur une inférence heuristique. Automatiser sur la seconde revient à promouvoir une heuristique en primitive d'orchestration.
• Le coût de sortie. Ce que devient le flux de travail si le produit s'arrête. Une réponse rassurante (git reste git, la licence autorise le fork) mérite d'être écrite avant l'adoption plutôt qu'après.