Quand un agent IA ne devrait pas être un agent : les 4 signaux qui doivent vous arrêter

Le terme "agent" est devenu un label marketing. Dès qu'un LLM appelle une fonction ou enchaîne deux étapes, on parle d'agent. Cette inflation sémantique cache un problème concret : beaucoup d'équipes construisent des agents là où un script déterministe aurait suffi, en ajoutant de la complexité, de l'imprévisibilité, et un coût de débogage que personne n'avait budgété.

Nous avons fait cette erreur. Plusieurs fois. Voici les signaux qui nous ont appris à nous arrêter avant de construire.

Ce qu'un agent fait réellement

Un agent au sens technique : un LLM qui décide lui-même quels outils appeler, dans quel ordre, et quand s'arrêter. La décision est prise à l'exécution, pas à la conception.

C'est précieux quand le problème est mal défini, le flux non linéaire, et les outils nombreux. C'est un anti-pattern quand le problème est structuré, le flux prévisible, et les outils limités.

La question n'est pas "est-ce qu'un agent pourrait faire ça ?" mais "est-ce que l'agent apporte quelque chose qu'un workflow fixe ne peut pas apporter ?"

Signal 1 : vous pouvez dessiner le flux à l'avance

Si vous pouvez écrire les étapes sur un tableau blanc sans hésiter, "d'abord on récupère X, ensuite on transforme avec Y, enfin on écrit en Z", c'est un workflow. Pas un agent.

Un workflow déterministe se code avec des fonctions ordinaires et quelques appels LLM pour les étapes qui nécessitent du raisonnement ou de la génération. L'orchestration reste dans votre code, pas dans le modèle.

# Workflow : flux fixe, le LLM ne décide pas de l'ordre
def process_contract(document: str) -> ContractSummary:
    extracted = extract_fields(document)      # appel LLM
    validated = validate_fields(extracted)    # logique déterministe
    summary = generate_summary(validated)     # appel LLM
    return summary

# Agent : le LLM décide quels outils appeler et dans quel ordre
# Justifié seulement si le flux varie selon le contenu du document

Si vous construisez un "agent" dont l'outil appelé est toujours le même dans le même ordre, vous avez un workflow déguisé en agent. Déguisement coûteux : chaque décision du modèle coûte des tokens et ajoute une source de variabilité.

Signal 2 : une erreur de l'agent est difficile à repérer et coûteuse à corriger

Les agents échouent silencieusement. Un script lève une exception. Un agent choisit un mauvais outil et continue.

Avant de construire un agent, posez la question : que se passe-t-il si le modèle prend la mauvaise décision à l'étape 3 sur 7 ? Est-ce que l'erreur est détectable ? Est-ce qu'elle est réversible ?

Si la réponse est non à l'une des deux, vous avez besoin de déterminisme, pas d'autonomie. Cela s'applique en particulier aux workflows qui écrivent des données, base de données, e-mails envoyés, commandes passées. Un agent qui hallucine une action destructrice dans une séquence de 10 étapes peut avoir causé des dommages avant que votre monitoring ne l'attrape.

Nous avons eu un agent de traitement de commandes qui, sur un document ambigu, appelait à la fois l'outil "créer commande" et l'outil "annuler commande" dans le même run. Les deux ont abouti. Le workflow équivalent n'aurait pas eu accès à ces deux outils dans le même contexte.

Signal 3 : votre "agent" n'a en réalité qu'un ou deux outils

La puissance d'un agent vient de sa capacité à choisir parmi plusieurs outils selon le contexte. Un agent avec un seul outil, ou dont le choix entre deux outils est trivial, n'a pas besoin d'être un agent.

Une règle pratique : si vous pouvez remplacer la décision du modèle par un if/else sur un champ structuré, faites-le. C'est plus rapide, plus prévisible, et gratuitement testable.

# Anti-pattern : agent avec deux outils dont le choix est trivial
tools = [summarize_tool, translate_tool]
# Le modèle "décide" lequel appeler selon la langue du document

# Pattern correct : décision explicite dans le code
def process_document(doc: Document):
    if doc.language != "fr":
        doc = translate(doc)
    return summarize(doc)

Le coût de cette mauvaise décision architecturale s'accumule : plus de tokens de contexte (la liste des outils est dans le prompt), plus de latence (un appel LLM pour décider, puis un autre pour exécuter), et un comportement que vous ne pouvez pas tester unitairement.

Signal 4 : vous ne savez pas comment tester l'agent

C'est le signal le plus révélateur. Un workflow déterministe se teste avec des inputs/outputs fixes. Un agent qui prend des décisions variables produit des outputs non déterministes : le même input peut donner des chemins d'exécution différents.

Si votre équipe ne peut pas répondre à "comment on teste que l'agent se comporte correctement sur ce cas limite ?", l'agent n'est pas prêt pour la production.

Les tests d'agents nécessitent :

• Des traces d'exécution capturées et comparables.
• Des assertions sur la séquence d'outils appelés, pas seulement sur l'output final.
• Un système d'évaluation capable de détecter des régressions de comportement, pas seulement des erreurs.

Construire tout ça prend du temps. Si le flux est fixe, vous n'en avez pas besoin.

Quand l'agent est réellement justifié

Ce n'est pas un argument contre les agents. C'est un argument pour les construire au bon endroit.

Un agent est justifié quand :

• Le flux dépend de la sémantique du contenu, pas de règles codifiables.
• Le nombre d'outils possibles est grand et leur composition variable.
• L'espace des cas est trop large pour être couvert par des règles exhaustives.
• L'erreur est détectable et le coût d'une mauvaise décision est acceptable ou réversible.

Un assistant de recherche qui doit choisir entre chercher dans une base de données, appeler une API externe, ou demander une clarification selon le contexte : c'est un agent. Un pipeline d'ingestion qui extrait, valide et insère des données selon des étapes fixes : ce n'en est pas un.

La question finale que nous posons maintenant avant tout nouveau projet "agent" : si on remplaçait l'agent par un humain qui exécute les mêmes outils, est-ce que cet humain aurait besoin de prendre des décisions non triviales à chaque étape ? Si non, le workflow suffit.