Codex et workflow multi-agents : travaillez avec des agents sans perdre le contrôle

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2La première fois qu’un agent de codage corrige un bug pour vous, la réaction est presque toujours la même : un mélange d’enthousiasme et de suspicion. Bien, bien sûr. Mais ensuite vous regardez la différence et vous vous demandez : "Ok, mais qu'est-ce qu'il a touché exactement ? Puis-je lui faire confiance ? Est-ce qu'il recommencera de la même manière demain ?".
3~
4C'est là que commence, je pense, la partie intéressante. Pas lorsque l'agent écrit une fonction, mais lorsqu'il devient suffisamment capable d'effectuer des tâches entières : lire le référentiel, créer un correctif, exécuter des tests, ouvrir un PR, revenir après un commentaire de révision. Le Codex évolue précisément dans cette direction : travail en arrière-plan, arbres de travail séparés, navigateur intégré, automatisations, plugins, mémoire et contrôles d'autorisation plus explicites.
5~
6Il ne s’agit pas d’imaginer un avenir dans lequel personne ne lit plus de code. Ce serait un avenir terrible et assez naïf. Le but est de trouver comment travailler avec des agents qui peuvent faire beaucoup de choses sans les laisser tout faire.
7~
8## Le changement d'habitude
9~
10Avec la saisie semi-automatique traditionnelle, vous étiez toujours au volant. L'IA a suggéré une ligne, vous avez décidé. En revanche, avec un agent, la relation change : vous lui donnez un objectif et il franchit tout seul plusieurs étapes.
11~
12C’est puissant, mais cela déplace le problème. La question n’est plus seulement « le modèle peut-il programmer ? ». La question devient :
13~
14- Est-ce que je lui ai donné une portée suffisamment petite ?
15- savez-vous comment vérifier le résultat ?
16- Est-ce que je travaille dans un environnement isolé ?
17- L’examen final est-il toujours humain et minutieux ?
18~
19Un flux de travail sain ressemble plus à ceci qu’à une baguette magique :
20~
21```mermaid
22flowchart LR
23    Idea[Tâche humaine] --> Scope[Objectif petit et vérifiable]
24    Scope --> Agent[Agent dans l'arbre de travail isolé]
25    Agent --> Checks[Test, lint, build, navigateur]
26    Checks --> Review[Examen humain]
27    Review --> Merge[Fusion ou nouvelle itération]
28    Review --> Iterate[Commentaires précis sur le différentiel]
29    Iterate --> Agent
30```
31~
32Cela semble moins romantique que "l'agent construit tout", mais cela fonctionne bien mieux. Et c'est aussi ainsi que fonctionnent les équipes qui sont à l'aise avec les humains : tâches claires, retours rapides, responsabilité explicite.
33~
34## La bonne invite est presque un bon ticket
35~
36L'invite la plus dangereuse est la plus vague mais confiante : "réparer la page des factures", "améliorer l'architecture", "nettoyer le module d'authentification". Ce sont des demandes qui semblent productives et génèrent d’énormes différences. Mais ensuite, vous vous retrouvez à faire de l'archéologie.
37~
38Une invite utile est plus ennuyeuse. Par exemple : implémentez l'export CSV pour la page des factures, sachant que la table est dans `app/(dashboard)/invoices/page.tsx`, les requêtes sont dans `src/server/invoices.ts` et il y a déjà un schéma similaire dans `app/(dashboard)/reports`.
39~
40Ajoutez ensuite des contraintes claires : ne modifiez pas le schéma de la base de données, n'ajoutez pas de dépendances si un petit utilitaire suffit, conservez le style d'interface utilisateur existant. Et terminez par la vérification : `npm test -- invoices` et `npm run build`.
41~
42Ce type de brief n'a pas pour but de « mieux expliquer à l'IA ». Il sert avant tout à vous faire comprendre plus clairement ce que vous déléguez. Si vous ne pouvez pas l'écrire concrètement, la tâche n'est peut-être pas encore prête pour un agent.
43~
44## Trois métiers que je délègue volontiers
45~
46Le premier est un travail répétitif mais vérifiable : ajout de tests, migration d'appels vers une nouvelle API interne, mise à jour des importations, remplacement de composants obsolètes, correction des erreurs TypeScript. Ici, l'agent peut gagner des heures et le risque est contrôlable.
47~
48Le second est un travail exploratoire : "trouver où est calculé ce total", "expliquez-moi pourquoi ce test est fragile", "reproduisez le bug et dites-moi quels fichiers semblent concernés". Même s’il ne produit pas de patch immédiatement, il peut effectuer une reconnaissance utile.
49~
50Le troisième est le travail de maintenance récurrent : petites mises à jour des dépendances, nettoyage des anciens indicateurs de fonctionnalités, résumé des PR bloqués, vérification des TODO oubliés. Ce n'est pas glamour, mais c'est exactement le genre de travail qui a tendance à s'accumuler.
51~
52## Trois métiers que je garde humains
53~
54Les décisions relatives aux produits restent humaines. Si un changement modifie la façon dont un utilisateur paie, supprime des données, voit les prix ou comprend une autorisation, je veux une personne responsable.
55~
56Les limites de sécurité méritent également une attention humaine : authentification, rôles, jetons, journalisation des données sensibles, migrations de bases de données. Un agent peut aider à la mise en œuvre, mais il ne doit pas nécessairement être le seul décideur.
57~
58Enfin, je garde tout ce qui demande un goût architectural humain. Un agent peut proposer un refactor, mais comprendre si une abstraction est vraiment nécessaire ou si l'on peaufine simplement un problème inexistant reste un travail.
59~
60## L'examen n'est pas facultatif
61~
62La tentation, lorsqu’un agent est bon, est de faire confiance au vert de l’IC. C'est compréhensible. C'est aussi là que les problèmes commencent.
63~
64Je regarde toujours au moins cinq choses :
65~
661. Le correctif résout-il uniquement la tâche demandée ?
672. A-t-il touché à des dossiers qui n'avaient rien à voir ?
683. Les tests couvrent-ils un comportement nouveau ou simplement un heureux hasard ?
694. Le code suit-il les modèles locaux ?
705. Les erreurs sont-elles gérées comme dans le reste du projet ?
71~
72Lorsque quelque chose ne va pas, les commentaires doivent être précis. « Réparez-le » est paresseux. Mieux : cet utilitaire duplique `parseMoney` dans `src/lib/money.ts` ; réutilisez cette fonction, ajoutez un test pour le cas EUR et ne modifiez pas l'API publique du module de facturation.
73~
74Les agents réagissent beaucoup mieux aux petits commentaires vérifiables. Curieusement, les gens aussi.
75~
76## Des garde-corps qui en valent la peine
77~
78Si un agent peut lire des fichiers, écrire du code et exécuter des commandes, il doit être traité comme un processus puissant. Il n’y a pas besoin de paranoïa, il faut de l’hygiène.
79~
80Utilisez des arbres de travail ou des branches séparés. Vous pouvez ainsi comparer les différences, jeter les expériences ratées et ne pas mélanger le travail de l'agent avec ce que vous faisiez.
81~
82Limitez les autorisations. Les commandes comme `rg`, `git diff`, `npm test` et `npm run build` peuvent être assez gratuites. Les déploiements, migrations de bases de données, accès aux secrets et commandes destructrices doivent rester explicites.
83~
84Réduisez l’accès au réseau lorsque vous n’en avez pas besoin. Pour de nombreuses tâches, la documentation officielle, le registre des packages et des services internes spécifiques suffisent. Moins de surface, moins de surprises.
85~
86Suivez les actions. Lorsqu'un correctif arrive en révision, vous devriez être en mesure de reconstruire les invites, les commandes exécutées, les tests réussis et les fichiers modifiés. Non pas pour créer de la bureaucratie, mais pour être capable de comprendre ce qui se passe en cas de problème.
87~
88## Un moyen simple de démarrer en équipe
89~
90Si je devais introduire des agents dans une petite équipe, je commencerais sans grandes révolutions.
91~
92Je créerais une étiquette `agent-ready` pour les problèmes ayant une portée claire. J'ajouterais un modèle avec le contexte, les contraintes et les commandes de vérification. Je demanderais de petits PR, idéalement sous quelques centaines de lignes. J'aurais besoin de tests ou de captures d'écran pour les changements visibles. Et surtout je garderais une personne responsable de la fusion.
93~
94Après deux semaines, j'examinais les données : quelles tâches étaient vraiment accélérées, quelles révisions étaient lourdes, quelles invites prêtaient à confusion, quelles parties de la base de code étaient trop fragiles pour être déléguées.
95~
96C'est une approche moins spectaculaire que "à partir d'aujourd'hui on fera tout avec les agents", mais c'est celle qui permet d'arriver à la troisième semaine sans regrets.
97~
98## La partie la plus humaine
99~
100Le plus drôle, c'est que plus les agents deviennent autonomes, plus les compétences classiques redeviennent importantes : rédiger un bon ticket, faire de petites coupes, créer des tests, lire des différences, communiquer des compromis. L'agent accélère ceux qui savent déjà bien travailler. Cela amplifie aussi le chaos de ceux qui délèguent mal.
101~
102Alors non, je ne vois pas les workflows multi-agents comme un raccourci pour arrêter de faire de l'ingénierie. Je les vois comme un moyen de consacrer plus d'énergie aux éléments qui comptent : décider quoi construire, s'assurer que cela fonctionne, garder le système compréhensible.
103~
104Les agents peuvent faire d’excellents collègues asynchrones. Mais un collègue asynchrone, pour être utile, a besoin de contexte, de limites et de révision. Comme tout le monde.
105~
106## Sources utiles
107~
108- [Un codex pour (presque) tout - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Exécuter le Codex en toute sécurité sur OpenAI](https://openai.com/index/running-codex-safely/)
110- [Présentation du Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Quoi de neuf avec l'agent de codage GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2La première fois qu’un agent de codage corrige un bug pour vous, la réaction est presque toujours la même : un mélange d’enthousiasme et de suspicion. Bien, bien sûr. Mais ensuite vous regardez la différence et vous vous demandez : "Ok, mais qu'est-ce qu'il a touché exactement ? Puis-je lui faire confiance ? Est-ce qu'il recommencera de la même manière demain ?".

4C'est là que commence, je pense, la partie intéressante. Pas lorsque l'agent écrit une fonction, mais lorsqu'il devient suffisamment capable d'effectuer des tâches entières : lire le référentiel, créer un correctif, exécuter des tests, ouvrir un PR, revenir après un commentaire de révision. Le Codex évolue précisément dans cette direction : travail en arrière-plan, arbres de travail séparés, navigateur intégré, automatisations, plugins, mémoire et contrôles d'autorisation plus explicites.

6Il ne s’agit pas d’imaginer un avenir dans lequel personne ne lit plus de code. Ce serait un avenir terrible et assez naïf. Le but est de trouver comment travailler avec des agents qui peuvent faire beaucoup de choses sans les laisser tout faire.

8## Le changement d'habitude

10Avec la saisie semi-automatique traditionnelle, vous étiez toujours au volant. L'IA a suggéré une ligne, vous avez décidé. En revanche, avec un agent, la relation change : vous lui donnez un objectif et il franchit tout seul plusieurs étapes.

11~

12C’est puissant, mais cela déplace le problème. La question n’est plus seulement « le modèle peut-il programmer ? ». La question devient :

13~

14- Est-ce que je lui ai donné une portée suffisamment petite ?

15- savez-vous comment vérifier le résultat ?

16- Est-ce que je travaille dans un environnement isolé ?

17- L’examen final est-il toujours humain et minutieux ?

18~

19Un flux de travail sain ressemble plus à ceci qu’à une baguette magique :

20~

21```mermaid

22flowchart LR

23 Idea[Tâche humaine] --> Scope[Objectif petit et vérifiable]

24 Scope --> Agent[Agent dans l'arbre de travail isolé]

25 Agent --> Checks[Test, lint, build, navigateur]

26 Checks --> Review[Examen humain]

27 Review --> Merge[Fusion ou nouvelle itération]

28 Review --> Iterate[Commentaires précis sur le différentiel]

29 Iterate --> Agent

30```

31~

32Cela semble moins romantique que "l'agent construit tout", mais cela fonctionne bien mieux. Et c'est aussi ainsi que fonctionnent les équipes qui sont à l'aise avec les humains : tâches claires, retours rapides, responsabilité explicite.

33~

34## La bonne invite est presque un bon ticket

35~

36L'invite la plus dangereuse est la plus vague mais confiante : "réparer la page des factures", "améliorer l'architecture", "nettoyer le module d'authentification". Ce sont des demandes qui semblent productives et génèrent d’énormes différences. Mais ensuite, vous vous retrouvez à faire de l'archéologie.

37~

38Une invite utile est plus ennuyeuse. Par exemple : implémentez l'export CSV pour la page des factures, sachant que la table est dans `app/(dashboard)/invoices/page.tsx`, les requêtes sont dans `src/server/invoices.ts` et il y a déjà un schéma similaire dans `app/(dashboard)/reports`.

39~

40Ajoutez ensuite des contraintes claires : ne modifiez pas le schéma de la base de données, n'ajoutez pas de dépendances si un petit utilitaire suffit, conservez le style d'interface utilisateur existant. Et terminez par la vérification : `npm test -- invoices` et `npm run build`.

41~

42Ce type de brief n'a pas pour but de « mieux expliquer à l'IA ». Il sert avant tout à vous faire comprendre plus clairement ce que vous déléguez. Si vous ne pouvez pas l'écrire concrètement, la tâche n'est peut-être pas encore prête pour un agent.

43~

44## Trois métiers que je délègue volontiers

45~

46Le premier est un travail répétitif mais vérifiable : ajout de tests, migration d'appels vers une nouvelle API interne, mise à jour des importations, remplacement de composants obsolètes, correction des erreurs TypeScript. Ici, l'agent peut gagner des heures et le risque est contrôlable.

47~

48Le second est un travail exploratoire : "trouver où est calculé ce total", "expliquez-moi pourquoi ce test est fragile", "reproduisez le bug et dites-moi quels fichiers semblent concernés". Même s’il ne produit pas de patch immédiatement, il peut effectuer une reconnaissance utile.

49~

50Le troisième est le travail de maintenance récurrent : petites mises à jour des dépendances, nettoyage des anciens indicateurs de fonctionnalités, résumé des PR bloqués, vérification des TODO oubliés. Ce n'est pas glamour, mais c'est exactement le genre de travail qui a tendance à s'accumuler.

51~

52## Trois métiers que je garde humains

53~

54Les décisions relatives aux produits restent humaines. Si un changement modifie la façon dont un utilisateur paie, supprime des données, voit les prix ou comprend une autorisation, je veux une personne responsable.

55~

56Les limites de sécurité méritent également une attention humaine : authentification, rôles, jetons, journalisation des données sensibles, migrations de bases de données. Un agent peut aider à la mise en œuvre, mais il ne doit pas nécessairement être le seul décideur.

57~

58Enfin, je garde tout ce qui demande un goût architectural humain. Un agent peut proposer un refactor, mais comprendre si une abstraction est vraiment nécessaire ou si l'on peaufine simplement un problème inexistant reste un travail.

59~

60## L'examen n'est pas facultatif

61~

62La tentation, lorsqu’un agent est bon, est de faire confiance au vert de l’IC. C'est compréhensible. C'est aussi là que les problèmes commencent.

63~

64Je regarde toujours au moins cinq choses :

65~

661. Le correctif résout-il uniquement la tâche demandée ?

672. A-t-il touché à des dossiers qui n'avaient rien à voir ?

683. Les tests couvrent-ils un comportement nouveau ou simplement un heureux hasard ?

694. Le code suit-il les modèles locaux ?

705. Les erreurs sont-elles gérées comme dans le reste du projet ?

71~

72Lorsque quelque chose ne va pas, les commentaires doivent être précis. « Réparez-le » est paresseux. Mieux : cet utilitaire duplique `parseMoney` dans `src/lib/money.ts` ; réutilisez cette fonction, ajoutez un test pour le cas EUR et ne modifiez pas l'API publique du module de facturation.

73~

74Les agents réagissent beaucoup mieux aux petits commentaires vérifiables. Curieusement, les gens aussi.

75~

76## Des garde-corps qui en valent la peine

77~

78Si un agent peut lire des fichiers, écrire du code et exécuter des commandes, il doit être traité comme un processus puissant. Il n’y a pas besoin de paranoïa, il faut de l’hygiène.

79~

80Utilisez des arbres de travail ou des branches séparés. Vous pouvez ainsi comparer les différences, jeter les expériences ratées et ne pas mélanger le travail de l'agent avec ce que vous faisiez.

81~

82Limitez les autorisations. Les commandes comme `rg`, `git diff`, `npm test` et `npm run build` peuvent être assez gratuites. Les déploiements, migrations de bases de données, accès aux secrets et commandes destructrices doivent rester explicites.

83~

84Réduisez l’accès au réseau lorsque vous n’en avez pas besoin. Pour de nombreuses tâches, la documentation officielle, le registre des packages et des services internes spécifiques suffisent. Moins de surface, moins de surprises.

85~

86Suivez les actions. Lorsqu'un correctif arrive en révision, vous devriez être en mesure de reconstruire les invites, les commandes exécutées, les tests réussis et les fichiers modifiés. Non pas pour créer de la bureaucratie, mais pour être capable de comprendre ce qui se passe en cas de problème.

87~

88## Un moyen simple de démarrer en équipe

89~

90Si je devais introduire des agents dans une petite équipe, je commencerais sans grandes révolutions.

91~

92Je créerais une étiquette `agent-ready` pour les problèmes ayant une portée claire. J'ajouterais un modèle avec le contexte, les contraintes et les commandes de vérification. Je demanderais de petits PR, idéalement sous quelques centaines de lignes. J'aurais besoin de tests ou de captures d'écran pour les changements visibles. Et surtout je garderais une personne responsable de la fusion.

93~

94Après deux semaines, j'examinais les données : quelles tâches étaient vraiment accélérées, quelles révisions étaient lourdes, quelles invites prêtaient à confusion, quelles parties de la base de code étaient trop fragiles pour être déléguées.

95~

96C'est une approche moins spectaculaire que "à partir d'aujourd'hui on fera tout avec les agents", mais c'est celle qui permet d'arriver à la troisième semaine sans regrets.

97~

98## La partie la plus humaine

99~

100Le plus drôle, c'est que plus les agents deviennent autonomes, plus les compétences classiques redeviennent importantes : rédiger un bon ticket, faire de petites coupes, créer des tests, lire des différences, communiquer des compromis. L'agent accélère ceux qui savent déjà bien travailler. Cela amplifie aussi le chaos de ceux qui délèguent mal.

101~

102Alors non, je ne vois pas les workflows multi-agents comme un raccourci pour arrêter de faire de l'ingénierie. Je les vois comme un moyen de consacrer plus d'énergie aux éléments qui comptent : décider quoi construire, s'assurer que cela fonctionne, garder le système compréhensible.

103~

104Les agents peuvent faire d’excellents collègues asynchrones. Mais un collègue asynchrone, pour être utile, a besoin de contexte, de limites et de révision. Comme tout le monde.

105~

106## Sources utiles

107~

108- [Un codex pour (presque) tout - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Exécuter le Codex en toute sécurité sur OpenAI](https://openai.com/index/running-codex-safely/)

110- [Présentation du Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Quoi de neuf avec l'agent de codage GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~