L’Agent Development Environment : une nouvelle unité de travail

This blog post is also available in 🇬🇧 English: The Agent Development Environment: A New Unit of Work.

Régulièrement, quelque chose arrive et change ce que « écrire du code » veut dire. Cette fois, il se pourrait que ça ne veuille plus dire écrire du tout.

Section intitulée d-ou-je-viensD’où je viens

Ce qui suit est mon parcours, pas une histoire de PHP. D’autres ont vécu ces mêmes années très différemment.

Mon histoire commence en 2013, quand PHP n’était pas le choix évident qu’il allait devenir, donc j’ai appris le C : pointeurs, gestion mémoire manuelle, segfaults. Ensuite je suis passé à l’Objective-C pour du développement iPad, avec un peu de Smalltalk à côté, pour maintenir un vieux site interne.

Pendant cette période, je suis tombé amoureux du web. J’ai rejoint une entreprise qui faisait du PHP, un langage complètement nouveau pour moi. La stack là-bas, c’était PHP 5.x, pas d’autoloading, presque aucune librairie, et pas de framework. Composer et Symfony existaient déjà, on ne les utilisait simplement pas. Chaque projet démarrait de zéro, et on réinventait beaucoup de roues. C’était plus dur, oui, mais c’était comme ça chez nous.

Puis j’ai déménagé à Paris, et c’est là que j’ai découvert les frameworks. Laravel et Symfony faisaient tous les deux du bruit, et j’ai commencé par Laravel. D’un coup, une communauté entière avait déjà résolu les problèmes que je résolvais seul. Pour moi, les frameworks n’étaient pas juste des outils, c’était un multiplicateur.

J’ai fini par passer à Symfony, que j’utilise et que j’aime toujours aujourd’hui. Tout ce dont vous avez besoin est faisable avec, et même plus.

Avec le recul, un motif se répète : j’ai suivi là où la technique m’emmenait. Chaque époque a changé l’unité de mon travail : des lignes de C, aux librairies, aux frameworks. Cet article parle de ce que je pense être l’étape suivante, celle qu’on est en train de vivre.

Section intitulée la-vague-des-llmLa vague des LLM

Pendant des années, les frameworks ont eu l’air d’être le bout de la route. Puis un nouveau type d’outillage est apparu.

La première vague est arrivée en 2021, avec GitHub Copilot : de l’auto-complétion sous stéroïdes. Vous commenciez une ligne, la machine la finissait. Ça semblait magique. En 2023, Cursor a relevé le niveau : toujours de l’auto-complétion de notre code, mais avec beaucoup plus de choses intégrées, comme discuter avec sa codebase, faire des éditions inline, et écrire des blocs entiers de code depuis une simple instruction. Et depuis 2025, Claude Code a pris la tête sur les agents IA, avec des modèles capables de livrer des features complètes tout seuls.

La progression est claire : d’abord un outil qui complétait notre code plus vite, puis un outil qui en écrivait une partie pour nous, et maintenant des agents qui construisent des features entières. L’unité de travail a encore changé : des frameworks aux features.

Cette vague n’est pas restée entre les mains de quelques gros acteurs. La concurrence a explosé, et les modèles open-weight ont rejoint la course : DeepSeek, en particulier, a secoué le monde de l’IA en délivrant des performances de niveau frontier pour une fraction du coût, et il était loin d’être seul. Pour nous, développeurs, ça a changé la question de l’accès : les modèles puissants ne sont plus enfermés chez un seul fournisseur. Vous pouvez choisir le modèle qui correspond à chaque tâche, mélanger les fournisseurs dans le même workflow, ou faire tourner des modèles plus petits sur votre propre machine avec des outils comme Ollama.

Chacune de ces vagues a redéfini une partie de notre métier. Mais à mon avis, ce n’était que le lever de rideau : le vrai changement n’est pas l’agent en lui-même, c’est l’environnement dans lequel on le fait tourner.

Section intitulée entree-en-scene-de-l-adeEntrée en scène de l’ADE

Le premier indice est venu de Cursor lui-même. Avec Cursor 2.0, il s’est mis à cacher les choses qu’on croyait essentielles : l’arborescence de fichiers, le panneau git, l’éditeur au centre. Ce qui restait, c’était une conversation avec un agent. Sans le nommer, c’est ça un ADE : un Agent Development Environment. Là où un IDE est construit autour de vous en train d’éditer des fichiers, un ADE est construit autour de vous en train de diriger des agents, et de discuter avec eux pour construire des produits.

Le nom est nouveau et pas encore très répandu, mais je l’aime bien, justement parce qu’il trace une ligne claire entre la façon dont on développe aujourd’hui avec des IDE et ce qui arrive ensuite.

Après Cursor, Jean est allé loin dans le paradigme ADE. Le raisonnement est simple : si les agents travaillent pour vous, vous devriez pouvoir lancer plusieurs tâches en même temps. Jean embarque donc une gestion native des git worktrees : chaque tâche vit dans sa propre copie isolée du dépôt. Combiné à l’intégration des pull requests et des issues GitHub, vous pouvez prendre une issue, obtenir un worktree tout neuf, et avoir un agent qui travaille dessus en quelques secondes.

Puis un collègue m’a parlé d’Orca. Il fait tout ce que fait Jean, avec encore plus d’intégrations : Jira et Linear sont supportés nativement, donc pendant que je travaille sur quelque chose je peux attraper une issue et créer immédiatement un worktree pour l’attaquer. Chaque tâche a son propre terminal, son navigateur et son contexte, et c’est du bring-your-own-subscription : Claude Code, Codex, OpenCode et les autres, côte à côte.

Rien de la vague des agents n’est perdu en route non plus. Agents, commands, skills : tout ce qu’on a construit se transpose. Un ADE ne remplace pas cette boîte à outils, il se pose par-dessus, et ça ne fait que la renforcer.

C’est pour ça qu’un ADE, ce n’est pas « un IDE avec un panneau IA greffé dessus ». Les primitives sont différentes : pas des fichiers et des buffers, mais des tâches, des worktrees et des agents. L’IDE partait du principe d’un développeur, une copie de travail, un fil de travail. L’ADE part du principe que vous en orchestrez plusieurs à la fois.

Section intitulée mon-setup-au-quotidienMon setup au quotidien

Un avertissement avant de plonger : mon agent CLI principal est OpenCode, donc tous les exemples de cette section tournent autour de lui. Mais rien ici n’est spécifique à OpenCode : la plupart de ces astuces se transposent directement à Claude Code, Codex, ou l’agent que vous préférez.

Section intitulée orca-lui-memeOrca lui-même

Orca embarque beaucoup de features pensées pour vous simplifier la vie, et la première c’est l’intégration avec les outils de suivi d’issues : GitHub issues, Jira et Linear sont tous supportés. De là, vous pouvez prendre une nouvelle issue ou consulter celles sur lesquelles vous travaillez déjà, lire tous les détails, et créer un worktree directement depuis l’issue. Quand vous faites ça, le prompt par défaut est le lien de l’issue (ça va beaucoup nous servir plus loin, gardez le en tête).

Quand vous jonglez avec plusieurs features ou issues en même temps, chacune dans son worktree, il devient vite difficile de se souvenir de ce qu’il reste à faire sur laquelle. C’est pour ça qu’Orca vous donne un kanban board. Chaque colonne est entièrement personnalisable ; dans mon cas j’en ai quatre :

• « Todo » contient les features et les issues à traiter ;
• « Waiting » est pour les tâches bloquées où j’ai besoin d’un retour de la personne liée à l’issue ;
• « In progress » est ce sur quoi je travaille activement ;
• « Draft » est pour les tâches où j’ai ouvert une draft pull request sur GitHub. Comme je travaille sur beaucoup de features en même temps, je lance rarement toute la suite de tests en local, donc je laisse la CI le faire sur la draft PR et je reviens vérifier les résultats (quand il y a trop d’échecs, je lance quand même les tests en local). Une fois que tout est vert, j’ouvre la PR pour review et je supprime le worktree local.

Dans la continuité de mon état « Draft », une autre chose que j’aime bien dans Orca, c’est le dock de droite. Il contient un explorateur de fichiers du projet où vous pouvez éditer les fichiers directement, comme dans un IDE. Un deuxième onglet liste toutes les sessions d’agents du worktree courant : quand je suis passé à Orca, il a immédiatement retrouvé toutes mes sessions OpenCode en cours à ce moment-là, donc j’ai pu reprendre sans rien perdre. Un troisième onglet couvre git : fichiers modifiés et stagés, et vous pouvez commit depuis là (ou demander à votre agent de le faire). Et le dernier onglet montre les runs GitHub Actions de votre pull request, donc quand j’ai une draft PR, je peux vérifier où en est la CI sans jamais quitter Orca.

Ce sont les trois features que j’utilise le plus, mais il y en a plein d’autres. Les quick commands permettent de préparer des scripts complets à lancer sur un worktree : j’ai une command « Install deps » qui installe tout ce qu’il faut quand j’ai besoin d’outils comme PHP CS Fixer ou PHPStan. Il y a aussi l’intégration mobile, qui ouvre un tunnel sur le réseau local pour que vous puissiez atteindre vos agents Orca depuis votre téléphone (ajoutez un VPN et ça marche de partout ; je m’en suis servi de temps en temps à la salle de sport). Et ce n’est qu’une fraction de ce qu’Orca propose, il y a beaucoup plus à découvrir.

Section intitulée mes-agentsMes agents

C’est dans les agents que j’ai le plus investi. Encore un avertissement : je travaille principalement avec Jira, donc certains agents ci-dessous sont orientés Jira, mais ils peuvent facilement être adaptés aux GitHub issues ou à Linear si besoin. Voici le détail complet de ce à quoi ressemble mon sélecteur d’agents :

• build est l’agent intégré qui fait les modifications. C’est le seul agent de cette liste autorisé à toucher au code.
• plan est l’autre agent intégré, utilisé simplement pour planifier.
• heavy-plan est le même que plan, mais adossé à un modèle plus performant : si plan tourne sur un modèle de classe Sonnet, celui-ci tourne sur un équivalent Opus. Je le garde pour les travaux importants ou risqués.
• jira-analyst prend un lien Jira, regarde tous les détails de l’issue, ses parents, et les PR ouvertes à son sujet, puis résume ce qui est demandé, ce qui a déjà été fait, et ce qui pourrait être fait dans le code. C’est mon point de départ numéro un, 95 % du temps.
• jira-feedback couvre le tour suivant : la QA a testé une de mes pull requests et a trouvé une erreur. Cet agent revérifie le ticket Jira depuis son lien, trouve la PR associée, checkout la branche en local, et essaie de comprendre le feedback et de faire de premières hypothèses.
• pr-review-planner intervient quand une PR est ouverte en review et que quelqu’un a laissé des commentaires : il les lit tous et propose comment je pourrais les traiter. Répondre à une review arrête d’être une séance d’archéologie et devient l’exécution d’une checklist.
• pr-reviewer est pour l’autre côté des reviews : quand j’ai une grosse PR à review, je la review toujours moi-même, et en parallèle je lance cet agent pour qu’une review IA attrape ce que j’aurais, peut-être, manqué.

Vous avez peut-être remarqué un motif : à part build, ce sont tous des agents d’analyse. Ils lisent, résument et planifient, mais ils ne touchent pas au code. Cette contrainte est inscrite dans la définition de l’agent elle-même. Voici un extrait abrégé de jira-analyst :

---
mode: primary
model: opencode-go/deepseek-v4-flash
temperature: 0.2
---

You are a technical analyst for Jira issues. When given a Jira issue URL or
issue key, you analyze the ticket and deliver exactly two things: a clear
summary of what the issue is about, and a concrete list of actions the
developer must take to resolve it.

You are strictly read-only. You NEVER modify the codebase: no edits, no file
creation, no refactoring, no "quick fixes". Your only output is analysis and
explanation.

### Investigating the codebase

The action plan must be grounded in the real code, not generic advice:

- grep/glob for the classes, routes, services, config keys, or error messages
  mentioned in the ticket.
- Use `git log`/`git blame` on the affected area to find recent related
  changes: regressions are often introduced by an identifiable commit.
- Check `gh pr list --search "<KEY>"` for existing or past PRs referencing
  the ticket.

La règle read-only n’est pas qu’une promesse dans le prompt : le même fichier porte un bloc de permissions qui rend les éditions impossibles dès le départ.

Section intitulée les-permissions-dans-opencodeLes permissions dans OpenCode

OpenCode résout chaque appel d’outil vers une action parmi trois : allow l’exécute sans demander, ask me demande d’abord, et deny le bloque purement et simplement. Ce qui compte ici, c’est qu’il part de valeurs par défaut permissives, la plupart des permissions sont en allow d’origine, donc un agent d’analyse n’est read-only que si vous le dites explicitement. Dans le frontmatter de l’agent, ça donne ça :

---
description: Analyze a Jira ticket and produce an action plan
mode: subagent
permission:
  edit: deny
  webfetch: deny
  bash:
    "*": deny
    "git *": allow
    "gh *": allow
    "jira *": allow
---

La clé permission est indexée par nom d’outil : read, glob, grep, list, bash, task, skill, webfetch, websearch. Vous les passez en revue un par un et vous décidez ce que chacun a le droit de faire, et une entrée "*" fixe la valeur par défaut pour tout ce que vous n’avez pas nommé. Notez que edit est la seule exception à la règle une clé pour un outil : elle couvre tout ce qui écrit sur le disque, donc edit, write, patch et multiedit se retrouvent tous derrière ce deny unique. Le reste reste ouvert, donc l’agent peut toujours lire, grep, glob et lancer les commandes dont il a besoin pour enquêter, et c’est tout ce qu’il fera jamais.

C’est dans le bloc bash que ça devient intéressant. Les règles sont matchées par pattern et la dernière règle qui matche gagne, donc le catch-all passe en premier et les règles spécifiques viennent après :

bash:
  "*": deny           # défaut : rien ne s'exécute
  "git *": allow      # ...sauf git
  "git push *": deny  # ...mais jamais push

Lisez de haut en bas, chaque ligne restreint ou rouvre celle du dessus. Inversez l’ordre et le catch-all avale silencieusement tout le reste. Un dernier piège : les patterns matchent la commande parsée, arguments compris, donc "git" seul ne matche qu’un git nu, tout ce qui a des arguments a besoin du wildcard.

Ce bloc est ce qui transforme « merci de seulement analyser » en quelque chose que l’agent ne peut pas contourner, même si le prompt dérive ou si le ticket essaie de l’entraîner ailleurs.

Et comme ces agents ne font qu’analyser, ils n’ont pas besoin du modèle le plus cher avec une grosse créativité : un modèle rapide et pas cher à faible température fait le travail, de manière déterministe. Si vous voulez les prompts complets, tous mes agents sont disponibles dans ce gist.

Section intitulée quand-orca-et-les-agents-s-emboitentQuand Orca et les agents s’emboîtent

Vous vous souvenez du détail d’Orca que je vous avais demandé de garder en tête : quand vous créez un worktree depuis une issue, le prompt par défaut est le lien de l’issue. C’est ici que ça paie. Comme jira-analyst et jira-feedback prennent tous les deux un lien d’issue en entrée, je n’ai presque rien à faire. Je sélectionne mon issue dans l’intégration Jira d’Orca, il ouvre un nouveau worktree, démarre mon agent, et copie le lien. Il ne me reste qu’à basculer sur le bon agent et à le lancer. De « je prends ce ticket » à « un agent l’analyse dans un worktree isolé », il y a deux clics et zéro copier-coller.

La même astuce marche dans l’autre sens, une fois que le worktree a déjà disparu. Quand une PR revient à la vie, parce que la QA a trouvé une erreur ou qu’un reviewer a laissé des commentaires, je crée un nouveau worktree depuis la PR elle-même, dans l’intégration GitHub d’Orca cette fois. L’agent s’ouvre avec le lien de la PR comme prompt, je lance jira-feedback ou pr-review-planner dessus, et tout le reste se fait automatiquement.

Pour vous donner une idée du rythme que tout ça crée : au début de la journée, je vérifie si mes draft PR en cours ont des erreurs. Si ce n’est pas le cas, je prends jusqu’à trois ou quatre issues Jira et je lance mon agent jira-analyst sur toutes, puis je fais généralement de la code review pendant qu’elles tournent. Quand un agent a fini d’analyser, une grosse lecture m’attend : l’idée est de me concentrer d’abord sur la première tâche terminée, de l’envoyer en exécution, puis de prendre la deuxième pendant que la première est occupée, et ainsi de suite, jusqu’à ce que je n’aie plus de tâches et que je reprenne de nouvelles issues.

Section intitulée mes-commandesMes commandes

Là où les agents portent un rôle complet, les commands sont plus proches de recettes : de petits prompts répétables que je lance à la demande. Deux des miennes sont généralistes :

• /commit-and-pr est plutôt direct : elle génère un message de commit et une description de pull request. Si le dépôt courant a une template GitHub disponible, elle l’utilise comme base pour la description de la PR.
• /activity récupère toute mon activité Jira et GitHub sur les dernières 24 heures, pour m’aider à ne rien oublier pendant mes daily stand-ups. Les autres commands sont très liées à mes projets, et pour les comprendre il faut savoir une chose de notre workflow : une PR est ouverte, la PR est reviewée, puis elle est mise dans une milestone pour être déployée sur un environnement de qualification à des fins de test. C’est comme ça que j’en suis venu à ces commands :
• /github-awaiting-review récupère toutes les pull requests ouvertes et en attente de review, sous forme de liste prête à être copiée dans Slack.
• /github-milestone-triage récupère toutes les pull requests qui ont leur review et qui doivent être testées, et sort une jolie liste que je peux copier dans Slack aussi.
• /milestone-build prend un lien de milestone en argument, rassemble toutes les PR de cette milestone, et crée une release branch pour qu’on puisse déployer chaque changement qu’elle contient. Elle gère aussi les conflits de merge en chemin.

Section intitulée mes-skillsMes skills

Côté skills, je n’en ai aucune faite maison. J’utilise plutôt un catalogue : la plupart des miennes viennent de superpowers-symfony, une collection de skills orientées Symfony, complétée par quelques skills liées aux projets qui décrivent, par exemple, comment un message de commit ou une description de pull request doit être écrite sur chaque projet. C’est aussi ce qui garde la command commit-and-pr simple : la command n’explique pas comment écrire quoi que ce soit, elle fait juste le travail, et les conventions viennent de ces skills. Ce n’est pas grand-chose, et c’est volontaire : j’ai toujours eu le sentiment qu’on se tourne trop souvent vers les skills, alors que ce qu’on veut vraiment est une command ou un agent.

Section intitulée la-philosophie-des-permissionsLa philosophie des permissions

Vous l’avez peut-être deviné en lisant le détail de mes agents : tout mon outillage IA est read-only par défaut, et build est le seul agent autorisé à écrire du code. Ce n’est pas un accident, c’est la règle dont tout le reste découle. Les agents proposent, l’humain décide. Considérez ça comme mon contrepoint à la mode des « YOLO agents », où on laisse un agent partir en roue libre avec toutes les permissions.

Derrière cette règle, il y a une conviction : tout code généré avec une IA vous appartient. Le modèle l’a écrit, mais c’est votre nom sur le commit. Être généré par une IA n’exempte pas une seule ligne de review : vous devez toujours vérifier ce qu’elle fait, et comment elle le fait, exactement comme du code que vous auriez écrit vous-même.

La meilleure façon de garder cette review supportable est d’investir avant que le code existe. Je lis les sorties de plan en entier, à chaque fois. Je discute des détails avec l’IA, je conteste les parties qui ne correspondent pas à ce que j’avais en tête, et j’ajuste parfois les prompts de mes agents en chemin, pour que l’exécution atterrisse au plus près de ce que j’ai réellement demandé.

Ensuite je lis le code. Tout le code, diff par diff, de la même façon que je reviewerais la PR d’un collègue : est-ce que ça fait ce que le plan disait, est-ce que ça le fait comme je l’aurais fait, et est-ce qu’il y a là-dedans quelque chose que je ne saurais pas expliquer dans six mois ? Investir dans le plan fait qu’il reste très peu de problèmes à ce stade, mais c’est bien le but. La review reste courte parce que le travail a eu lieu en amont, pas parce que je l’ai bâclée.

Section intitulée pourquoi-ca-me-rend-productifPourquoi ça me rend productif

Il est temps d’appuyer tout ça avec quelque chose de plus concret que de l’enthousiasme. Les gains ne sont pas uniformes : certains sont spectaculaires, d’autres sont marginaux, et ça vaut la peine d’être honnête sur qui est quoi.

Le cœur de tout ça, ce sont jira-analyst et jira-feedback, les deux agents qui m’ont fait aimer ce workflow. Là où je travaille, on a une équipe « focus » : tout le monde peut travailler sur tout, des stocks au retail en passant par la gestion client. Le changement de contexte entre les issues est énorme, et c’est exactement ce que jira-analyst absorbe : il m’explique tout ce que j’ai besoin de savoir avant de plonger dans ma tâche. Selon l’issue, ça me fait gagner jusqu’à une demi-journée, parfois une journée entière. C’est aussi l’agent dans lequel j’ai le plus investi : son prompt a été amélioré itération après itération pour arriver au point actuel.

pr-review-planner est une bénédiction du même ordre. Traiter les retours de review me prenait beaucoup de temps, parce que chaque commentaire demande son contexte : quel code il vise, ce que le reviewer voulait dire, quelles sont les options. Maintenant je lance l’agent, je lis la sortie, et j’ai tout ce qu’il me faut pour décider quoi faire, commentaire par commentaire.

Côté commands, github-awaiting-review et github-milestone-triage ont remplacé une corvée : parcourir toutes les PR, vérifier qui a créé chaque issue et qui la review, construire le message Slack, l’envoyer. Selon le nombre de PR ouvertes, ça pouvait me coûter jusqu’à 20 minutes. Maintenant je lance la command, je reviens plus tard, et c’est fait. Et les minutes ne sont même pas le vrai gain : le vrai gain, c’est que je ne casse plus mon focus pour ça. Un truc aussi simple appartient à un prompt, et mon attention reste sur mes tâches. Et je vais être honnête sur milestone-build : le gain de temps brut est faible, puisque avant elle je faisais simplement un git merge de chaque branche dans une release branch, puis un push. Ce qu’elle enlève, c’est tout ce qu’il y a autour des merges : je ne gère plus les conflits, ni la vérification de quelles PR doivent être dedans, tout ça est automatisé.

Et puis il y a Orca lui-même. La majorité de ma routine quotidienne vit maintenant dedans : je n’ouvre Jira que pour m’assigner des tickets, GitHub pour review les PR des autres développeurs, et Slack pour partager les listes que mes commands préparent (et si un jour je peux faire tout ça depuis Orca, je serai content). Moins d’outils veut dire moins de choses auxquelles penser, et tout va plus vite. Et la gestion des worktrees mérite un dernier mot : j’ai essayé de créer les worktrees à la main, puis de demander à un agent de les créer pour moi. Que des outils comme Jean et Orca s’en occupent nativement est une avancée formidable pour cette philosophie ADE.

Section intitulée conclusionConclusion

En regardant tout ce chemin, le motif du début tient toujours : j’ai suivi là où la technique m’emmenait, une fois de plus. Des lignes de C aux librairies, des librairies aux frameworks, des frameworks aux features. Sauf que cette fois, la technique n’est ni un langage ni un framework : c’est un collègue. Il lit les tickets, analyse le code, propose des plans ; je dirige, je review, et je décide.

Et pour être honnête jusqu’au bout : tout n’est pas encore fluide. Les worktrees sont une bénédiction, mais il reste des trous, et le plus gros pour moi est l’infrastructure locale. Faire tourner plusieurs copies du même site veut dire des conflits Docker, donc quand je travaille dans un worktree, j’évite au maximum de lancer Docker. On a travaillé sur de l’outillage pour adoucir ça : nos conteneurs sont maintenant préfixés avec le nom du worktree, par exemple. Mais certaines pièces résistent : on utilise Traefik comme routeur HTTP, et vous ne pouvez pas en faire tourner plus d’un, donc il faudra encore du travail d’outillage avant que tout ça tourne bien côte à côte.

Des aspérités comme celles-ci sont le signe d’un écosystème jeune, pas d’une mauvaise direction. Les IDE ont mis des décennies à devenir ce qu’ils sont ; les ADE commencent à peine, et ils ont déjà changé mon quotidien plus que n’importe quel outil depuis les frameworks. Je ne sais pas quel ADE va gagner, ni si ceux que j’utilise aujourd’hui seront encore là dans cinq ans. Mais je sais que je ne reviendrai pas à un environnement construit pour moi seul : les agents ont rejoint l’équipe, et ils méritent un bon bureau eux aussi.