Youssef ELMIZEB · fondateur de tekfold.com · mis à jour le 26 octobre 2026
Un modèle de langage ne fait qu’une chose : produire du texte à partir d’une entrée. Il ne peut ni cliquer, ni écrire un fichier, ni appeler une API, ni vérifier qu’il a réussi. Pourtant, on parle partout d’agents qui « agissent ». La différence tient à un assemblage simple à comprendre mais exigeant à construire : modèle + outils + boucle d’exécution. Comprendre cette mécanique, c’est savoir pourquoi un agent échoue, et donc où intervenir quand le tien dérape.
La boucle : ce qui transforme un texte en action
Un agent, c’est un programme qui enchaîne des cycles courts. À chaque tour, il reçoit un état, décide d’une action, exécute une action, observe le résultat, puis décide à nouveau — jusqu’à atteindre un objectif ou toucher une limite. Trois observations sur quatre en production viennent du mauvais fonctionnement de cette boucle, pas du modèle.
| Composant | Rôle | Symptôme de défaillance |
|---|---|---|
| Modèle | Comprend l’état, choisit l’action, rédige ses paramètres | Paramètres inventés, action hors périmètre, refus répété de la même tâche |
| Boucle d’exécution | Enchaîne les tours, gère les erreurs, applique les limites | Actions en boucle, coût qui dérive, tâche qui n’aboutit jamais |
| Outils | Passerelles vers le monde réel (API, fichiers, base, navigateur) | Résultats illisibles ou trop longs qui saturent le contexte suivant |
| Mémoire | Court terme (tour en cours) et long terme (préférences, historique) | Amnésie entre deux sessions, ou au contraire accumulation de brouillons |
| Garde-fous | Budgets, limites d’itérations, validation humaine, journal | Actions irréversibles, absence de trace exploitable après incident |
Quand un agent « ne fait pas le job », identifie d’abord la ligne du tableau concernée. On change rarement de modèle avant d’avoir vérifié la boucle et les outils.
Planification et appel d’outils : les deux goulots
La planification définit et révise la suite des étapes ; l’appel d’outils choisit la fonction, remplit les paramètres et émet une requête structurée. Deux faiblesses classiques en découlent.
D’abord, une planification trop fine : l’agent produit dix micro-étapes, chacune validée, ce qui triple la latence et multiplie les occasions d’erreur. Une planification trop grossière a l’effet inverse : une seule action ambitieuse, impossible à contrôler. Le bon réglage se voit sur les traces — visée une à trois actions par tour pour une tâche moyenne, et une révision de plan explicite quand un retour d’outil échoue deux fois.
Ensuite, des paramètres d’outil mal contraints : sans schéma de types strict (paramètres requis, enums, formats), le modèle comble les vides de façon plausible. Une erreur de schéma détectée par l’outil et renvoyée au modèle est bien plus efficace qu’une exécution qui échoue silencieusement. Voici la structure minimale d’une telle boucle :
def run_agent(task, tools, max_turns=8, budget=1.0):
state = [{"role": "user", "content": task}]
trace = []
for turn in range(max_turns):
step = llm(state, tools=schemas(tools)) # tool_call ou réponse finale
if step.type != "tool_call":
return {"result": step.text, "trace": trace} # objectif atteint
if not step.is_valid_schema():
state.append(tool_error(step, "paramètres invalides, corrige et recommence"))
continue # pas d'exécution à l'aveugle
cost = estimate_cost(step)
if cost > budget:
state.append(tool_error(step, "budget dépassé, propose une alternative"))
continue
observation = tools[step.name](**step.args)
trace.append({"turn": turn, "tool": step.name, "ok": observation.ok})
state.append(tool_result(step, truncate(observation, 1500)))
return {"error": "limite de tours atteinte", "trace": trace}
Trois lignes de ce code portent l’essentiel : la validation de schéma avant exécution, le budget explicite, et la troncature des observations. Sans ces trois garde-fous, un agent peut dépenser, tourner en rond et noyer son propre contexte.
Multi-agents : quand cela se justifie vraiment
Un agent généraliste suffit dans la majorité des cas. Le passage à plusieurs agents se justifie quand la tâche se décompose proprement et que des agents spécialisés surpassent un généraliste sur leur partie.
| Aspect | Agent unique | Système multi-agents |
|---|---|---|
| Coordination | Nulle : tout passe par un contexte partagé | À concevoir : rôles, contrat d’échange, arbitrage |
| Coût et latence | Faciles à estimer | Composés : chaque agent relit son propre contexte |
| Diagnostic | Une trace, une cause probable | Plusieurs traces à corréler ; un agent faible contamine le résultat |
| Cas d’usage pertinents | Tâches de bout en bout, rédaction, analyse, code ciblé | Sous-tâches indépendantes (recherche, code, vérification), rôles radicalement différents |
Le test pour décider : si tu peux écrire la frontière entre les sous-tâches et le format échangé en une phrase, le multi-agents est justifié. Sinon, tu n’ajoutes que de la coordination.
Les protocoles qui standardisent tout ça
Un agent isolé reste un gadget ; un agent connecté devient un composant. Trois couches de standardisation structurent aujourd’hui l’écosystème :
- Les protocoles d’accès aux outils et ressources (type MCP) : ils exposent fonctions et documents de manière uniforme, indépendamment de l’assistant qui les consomme. L’intérêt est le réemploi : un serveur écrit une fois fonctionne avec plusieurs clients.
- Les protocoles d’communication entre agents : ils définissent comment deux agents négocient une tâche, partagent un état et rendent compte — indispensable dès que des agents de fournisseurs différents doivent coopérer.
- Les formats de compétences réutilisables : instructions, scripts et exemples versionnés, que l’agent charge quand la tâche le demande. C’est l’équivalent des scripts qu’un humain garde dans un dossier procédures.
Ces standards ne rendent pas un agent plus intelligent : ils le rendent intégrable, maintenable et remplaçable. Pour un premier montage concret, le générateur de workflow n8n illustre bien la logique de boucle appliquée à des tâches métier — et les notions de boucle et de garde-fous sont détaillées dans notre hub Tech & IA.
Questions fréquentes
Un agent est-il simplement un prompt complexe ? Non. Un prompt n’a ni action, ni boucle, ni état persistant. L’agent est le programme qui entoure le modèle : c’est lui qui décide du nombre d’étapes, des budgets et de ce qui se passe en cas d’échec.
Faut-il un framework ou une boucle maison ? Pour une tâche ciblée, une boucle maison de cinquante lignes est souvent plus lisible et plus facile à déboguer. Les frameworks deviennent utiles quand tu as de nombreux outils, des états persistants et plusieurs agents à coordonner.
Comment tester la fiabilité d’un agent ? Avec un jeu de cas réels rejoué à chaque modification, en notant le taux de succès, le nombre de tours et le coût moyen. Sans ça, chaque changement se juge sur un unique essai favorable.
À quel moment ajouter un humain dans la boucle ? Sur toute action irréversible ou externe — envoi, paiement, suppression, publication — tant que le taux d’erreur réel n’est pas connu et acceptable. La validation humaine se retire au fur et à mesure des preuves, jamais d’un coup.
Un agent efficace se résume à une boucle courte, des outils au schéma strict, des garde-fous explicites et une traçabilité complète. Le modèle compte, mais c’est cette structure qui décide du résultat.
