Méthodes agentiques : coder avec des agents IA, concevoir pour des agents

TL;DR

« Méthodes agentiques » recouvre deux réalités distinctes qui se percutent en ce moment : des agents IA qui codent avec l'équipe (lire, écrire, exécuter, vérifier en boucle), et des architectures agentiques qu'on conçoit dans nos propres systèmes (orchestration d'agents autonomes côté produit). Dans les deux cas, le même principe : un agent n'est utile que si les contrats sont explicites — périmètre, erreurs, permissions, points d'arrêt. Le rôle du Tech Lead ne disparaît pas, il se déplace : moins de lignes tapées, plus de spécification, de revue et de gouvernance. Le sujet de fond n'est pas l'outillage, c'est la clarté — exactement comme pour un flux métier bien modélisé.

Sommaire

Introduction — deux sens pour un même mot
Coder avec des agents IA : ce que ça change vraiment
Concevoir des architectures agentiques
Là où l'humain reste indispensable
Une checklist Tech Lead pour adopter ces méthodes
Conclusion — les agents révèlent la maturité de l'équipe

Introduction — deux sens pour un même mot

Depuis quelques mois, « agentique » revient partout, mais recouvre deux choses différentes selon qui parle :

Coder avec des agents IA : un outil qui lit le code, écrit des diffs, exécute des commandes, lance les tests, et recommence jusqu'à obtenir un résultat correct — au lieu de suggérer une ligne à la fois.
Concevoir des systèmes agentiques : une architecture logicielle où des agents autonomes (souvent eux-mêmes basés sur des LLM) prennent des décisions, appellent des outils, et coopèrent pour accomplir une tâche métier — un chatbot support qui déclenche des remboursements, un pipeline de traitement de documents qui route lui-même les cas complexes vers un humain.

Ce sont deux sujets séparés, mais un même principe de fond les traverse : un agent — humain, IA, ou service — n'est fiable que s'il opère dans un cadre explicite. C'est le même terrain que j'évoquais à propos de la modélisation d'un flux métier : l'outil compte moins que la clarté du contrat qu'on lui donne.

Coder avec des agents IA : ce que ça change vraiment

De l'autocomplétion à la boucle agentique

La différence n'est pas la qualité du code généré, c'est la boucle : percevoir → planifier → agir → vérifier → recommencer.

Un agent de code peut :

lire plusieurs fichiers pour comprendre le contexte réel,
proposer un plan avant de modifier quoi que ce soit,
exécuter les tests et lire les erreurs,
corriger sa propre proposition sans intervention,
s'arrêter et demander une décision quand l'ambiguïté est trop grande.

Ce n'est plus « complète ma ligne », c'est « prends en charge la tâche, dans un périmètre donné ». Le changement d'échelle change aussi la manière dont on doit cadrer le travail : une tâche mal définie donnera un résultat mal défini, agent ou pas.

Le rôle du dev glisse vers la relecture

Ce que produit un agent doit être lu, compris, et validé — pas seulement accepté parce que les tests passent au vert.

Concrètement, ça déplace le travail :

moins de temps à taper du code mécanique,
plus de temps à écrire des spécifications précises,
plus de temps en revue — et une revue plus exigeante, pas moins,
une responsabilité qui reste entièrement humaine : ce qui part en production, c'est l'équipe qui le signe, pas l'agent.

Un agent qui va vite sur une tâche mal cadrée ne fait qu'accélérer la production de dette technique. La vitesse n'est un gain que si le cadrage est déjà bon.

Des garde-fous explicites

Un agent qui peut lire, écrire et exécuter est un agent qui peut aussi se tromper à grande échelle. Les garde-fous ne sont pas optionnels :

permissions explicites — ce que l'agent peut faire seul, ce qui nécessite une validation,
environnements isolés — sandbox, container jetable, jamais d'accès direct à la prod,
actions réversibles par défaut — préférer une branche à un push --force, un commit à un reset --hard,
revue de sécurité systématique — un agent ne remplace pas une revue humaine sur les changements sensibles (auth, paiement, données personnelles).

C'est exactement le réflexe qu'on a avec un junior en développement : un cadre précis, le temps que la confiance se construise sur des résultats.

Concevoir des architectures agentiques

Un agent, c'est une boîte avec un contrat

Quand on conçoit un système où des agents (IA ou non) coopèrent, la première question n'est pas « quel framework d'orchestration ? » mais :

quel est le périmètre exact de chaque agent ?
quelles erreurs peut-il renvoyer, et sous quelle forme ?
quels outils a-t-il le droit d'appeler, et avec quelles permissions ?
que se passe-t-il quand il ne sait pas quoi faire ?

Un agent sans contrat explicite, c'est un service sans interface : ça fonctionne en démo, ça s'effondre en production dès que le cas réel diverge du cas testé.

Orchestration ou autonomie : un choix, pas un réflexe

Deux grandes familles de design reviennent tout le temps :

Orchestration : un agent chef d'orchestre distribue des sous-tâches à des agents spécialisés, et arbitre les résultats. Prévisible, traçable, plus facile à déboguer.
Chorégraphie / autonomie : les agents décident eux-mêmes de leurs prochaines actions en fonction du contexte, sans chef. Plus flexible, mais plus difficile à borner et à auditer.

Comme pour n'importe quel pattern d'architecture, le risque du « patternisme » existe ici aussi : rendre un système autonome parce que c'est le sujet à la mode, alors qu'un pipeline classique aurait suffi. Tous les métiers ne sont pas non plus adaptés à une architecture agentique — un processus simple et déterministe n'a souvent besoin ni d'agent, ni d'IA.

Observabilité : si tu ne peux pas le rejouer, tu ne peux pas le déboguer

Un système agentique prend des décisions dynamiques — le même input peut produire des chemins différents. Sans traçabilité fine, un bug devient impossible à reproduire :

logguer chaque décision et chaque appel d'outil,
garder une trace du raisonnement intermédiaire, pas seulement du résultat final,
pouvoir rejouer un scénario avec les mêmes entrées,
mesurer le coût (tokens, latence, appels externes) comme une métrique de production à part entière.

Un agent qu'on ne peut pas observer est un agent qu'on ne peut pas faire évoluer sereinement.

Là où l'humain reste indispensable

Aucun agent — de code ou de produit — ne remplace :

le jugement métier sur une règle ambiguë ou un cas limite non documenté,
les décisions d'architecture qui engagent le projet sur plusieurs années,
l'arbitrage entre plusieurs solutions valides, quand le choix dépend du contexte business,
la responsabilité finale de ce qui est livré aux utilisateurs.

Un agent exécute bien un cadre qu'on lui a donné. Il ne remplace pas la personne qui décide de ce cadre.

Une checklist Tech Lead pour adopter ces méthodes

Avant d'introduire des agents dans une équipe ou une architecture, quelques questions valent la peine d'être posées à voix haute :

Le périmètre de chaque agent est-il écrit noir sur blanc ?
Les permissions (lecture, écriture, exécution, réseau) sont-elles explicites et minimales ?
Existe-t-il un point d'arrêt clair quand l'agent rencontre une ambiguïté ?
Les actions sensibles passent-elles par une validation humaine ?
Le système est-il observable : logs, rejeu, coût mesuré ?
La revue de code et de sécurité reste-t-elle obligatoire sur les changements produits par un agent ?
L'équipe sait-elle encore lire et comprendre ce que l'agent produit, sans en dépendre aveuglément ?

Une réponse floue à l'une d'elles pointe rarement vers un problème d'agent. Elle pointe vers un problème de cadrage qui existait sans doute déjà avant.

Conclusion — les agents révèlent la maturité de l'équipe

Les méthodes agentiques ne vont pas transformer une équipe à elles seules. Mais elles révèlent, plus vite que jamais, si les fondamentaux sont là : spécifications claires, erreurs explicites, périmètres bien découpés, gouvernance assumée.

Une équipe qui avait déjà un flux métier lisible et des contrats clairs verra les agents — IA comme architecturaux — amplifier ce qui fonctionnait déjà bien. Une équipe qui naviguait à vue verra les mêmes outils amplifier le flou existant, juste plus vite.

Les agents ne sont que des outils. La vraie valeur reste dans la clarté qu'on met derrière : les contrats, les spécifications, les garde-fous que l'équipe choisit d'assumer.