Codex et workflow multi-agents : travaillez avec des agents sans perdre le contrôle
· 7 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
La 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 ?".
C'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.
Il 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.
Le changement d'habitude
Avec 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.
C’est puissant, mais cela déplace le problème. La question n’est plus seulement « le modèle peut-il programmer ? ». La question devient :
- Est-ce que je lui ai donné une portée suffisamment petite ?
- savez-vous comment vérifier le résultat ?
- Est-ce que je travaille dans un environnement isolé ?
- L’examen final est-il toujours humain et minutieux ?
Un flux de travail sain ressemble plus à ceci qu’à une baguette magique :
Cela 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.
La bonne invite est presque un bon ticket
L'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.
Une 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.
Ajoutez 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.
Ce 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.
Trois métiers que je délègue volontiers
Le 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.
Le 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.
Le 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.
Trois métiers que je garde humains
Les 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.
Les 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.
Enfin, 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.
L'examen n'est pas facultatif
La 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.
Je regarde toujours au moins cinq choses :
- Le correctif résout-il uniquement la tâche demandée ?
- A-t-il touché à des dossiers qui n'avaient rien à voir ?
- Les tests couvrent-ils un comportement nouveau ou simplement un heureux hasard ?
- Le code suit-il les modèles locaux ?
- Les erreurs sont-elles gérées comme dans le reste du projet ?
Lorsque 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.
Les agents réagissent beaucoup mieux aux petits commentaires vérifiables. Curieusement, les gens aussi.
Des garde-corps qui en valent la peine
Si 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.
Utilisez 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.
Limitez 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.
Ré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.
Suivez 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.
Un moyen simple de démarrer en équipe
Si je devais introduire des agents dans une petite équipe, je commencerais sans grandes révolutions.
Je 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.
Aprè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.
C'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.
La partie la plus humaine
Le 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.
Alors 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.
Les 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.