Agent IA ou automatisation classique : comment choisir ?

« Faut-il un agent IA ? » est presque toujours la mauvaise question. Elle suppose que l'agent est l'aboutissement naturel d'un projet d'automatisation, et que le reste serait une version dégradée. En pratique, la plupart des tâches qu'on veut automatiser n'ont pas besoin d'autonomie : elles ont besoin d'être exécutées de la même façon mille fois.

La bonne question est : quelle est la part d'imprévu dans cette tâche ? C'est elle qui détermine l'architecture, pas l'inverse. Ce guide donne la matrice, l'arbre de décision et les contrôles qui vont avec.

Le seul critère qui compte : la variabilité des entrées

Quatre familles d'outils, classées par degré d'autonomie croissante. Chacune répond à un niveau d'incertitude différent.

Le script exécute une suite d'opérations fixes. Même entrée, même sortie, toujours. Il ne « comprend » rien et c'est précisément sa force : il ne peut pas se tromper d'interprétation. Un script casse quand l'entrée change de forme, pas quand elle change de sens.

Le workflow orchestre plusieurs étapes, avec des branchements prévus à l'avance. Il gère la variété connue — trois formats de facture, deux types de demande — mais il faut avoir anticipé chaque cas.

L'appel LLM inséré dans un workflow ajoute une étape de compréhension ou de rédaction à un endroit précis, avec une entrée et une sortie délimitées. C'est le meilleur rapport valeur/risque de la famille : on garde le contrôle déterministe du flux et on délègue uniquement ce qui résiste à la règle.

L'agent décide lui-même des étapes, choisit ses outils, itère jusqu'à un objectif. Il gère l'imprévu — au prix de la prévisibilité. On ne sait pas à l'avance combien d'étapes il fera, ni ce qu'il tentera.

Le critère de choix tient en une phrase : si vous pouvez écrire la procédure, vous n'avez pas besoin d'un agent. L'agent ne sert que lorsque la procédure dépend du contenu rencontré.

La matrice de comparaison

	Script	Workflow	LLM dans le flux	Agent
Entrées	Format fixe	Formats prévus	Variable, bornée	Imprévisible
Fiabilité	Déterministe	Déterministe	Bonne si sortie structurée	Variable, à mesurer
Coût unitaire	Quasi nul	Faible	Quelques appels LLM	Plusieurs appels par tâche
Coût d'exploitation	Faible	Moyen (maintenance des cas)	Moyen	Élevé (surveillance, évaluation)
Débogage	Simple	Simple	Moyen (sorties non déterministes)	Difficile (chemin variable)
Échec typique	Casse sur un format inattendu	Cas non prévu	Hallucination sur une valeur	Boucle, dérive, action non voulue
Quand le choisir	La règle est stable	Les cas sont énumérables	Il faut comprendre ou rédiger	Il faut chercher, décider, itérer

Une remarque sur la ligne « fiabilité » : elle ne veut pas dire qu'un agent est peu fiable en soi, mais que sa fiabilité se mesure au lieu de se démontrer. Un script se prouve par relecture ; un agent se prouve par un jeu de tests exécuté en continu.

L'arbre de décision

Cinq questions, dans cet ordre. La première qui tranche arrête le raisonnement.

La tâche produit-elle toujours la même sortie pour la même entrée ? → script.
Peut-on énumérer à l'avance les cas possibles ? → workflow, avec un cas par branche.
La difficulté est-elle de comprendre un texte ou d'en produire un ? → appel LLM borné dans le flux, avec une sortie structurée et validée.
La tâche exige-t-elle de chercher une information, de choisir entre plusieurs actions, puis de vérifier le résultat ? → agent, avec périmètre d'outils restreint.
L'erreur est-elle coûteuse ou irréversible ? → dans tous les cas, validation humaine sur l'action finale, quel que soit l'outil.

La question 5 n'est pas une alternative aux autres : c'est un filtre qui s'applique à la fin. Un agent peut préparer une décision ; il ne doit pas l'exécuter seul quand l'action est irréversible.

Quand un agent est inutile

Cinq situations où l'agent est le mauvais outil, et ce qu'il faut faire à la place.

L'extraction de champs dans des documents. Un LLM avec un schéma de sortie, appelé une fois par document, fait le travail. Un agent qui « réfléchit » à la structure du document ajoute du coût et de la variance sans gagner en précision. Si les documents sont homogènes, un extracteur classique reste plus fiable.

Le routage de demandes. Classer un message entrant dans cinq catégories est une tâche de classification, pas d'autonomie. Un appel avec sortie contrainte suffit, et se mesure avec une matrice de confusion.

Les tâches dont la procédure est écrite. Si un manuel d'exploitation décrit les étapes, l'agent réinventera la procédure à chaque exécution. Le workflow la suit exactement, pour un coût constant.

Les calculs et les agrégations. Un agent qui additionne des montants est un agent qui peut se tromper d'arithmétique. Les nombres se calculent en code, pas en langage naturel. Le LLM formule, le code calcule.

Les actions à conséquence irréversible. Payer, envoyer, supprimer, publier : un agent peut préparer, jamais déclencher sans validation explicite.

Quatre architectures concrètes

A. Chaîne déterministe. fichier → parseur → validation → base. Aucun LLM. C'est l'architecture par défaut de tout ce qui est stable, et celle qu'on regrette de ne pas avoir choisie quand un projet dérive.

B. Flux avec compréhension ponctuelle. message entrant → classification LLM (sortie contrainte) → routage déterministe → traitement. Le LLM ne décide que d'une étiquette ; tout le reste est du code. C'est l'architecture la plus rentable dans la majorité des projets d'assistance.

C. Boucle bornée. objectif → appel LLM avec outils → résultat → vérification → (si échec et essais < N) → nouvel essai. La différence avec un agent complet tient à trois bornes : un nombre maximal d'itérations, une liste fermée d'outils, un budget de tokens. Sans ces trois bornes, la boucle peut tourner.

D. Agent multi-étapes. plan → recherche → actions → vérification → synthèse. À réserver aux tâches où le chemin dépend réellement de ce qu'on découvre. Coût et latence par tâche sont variables par construction : il faut instrumenter avant de généraliser.

Ce que coûte réellement un agent

Le coût ne se résume pas au prix du modèle. Il se compose, et chaque terme est mesurable :

coût_tâche = appels × (tokens_entrée × prix_entrée + tokens_sortie × prix_sortie)
             + reprises × coût_appel
             + coût de vérification humaine

Trois mécanismes font diverger la facture par rapport à un appel simple :

La conversation est renvoyée à chaque étape. Un agent qui fait six appels ne paie pas six fois une question : il paie six fois l'historique accumulé, qui grossit à chaque tour.
Les résultats d'outils sont des tokens. Une recherche qui renvoie une page entière coûte plus cher que la question posée.
Les reprises multiplient. Une tâche qui échoue deux fois avant de réussir a coûté trois fois son prix nominal.

Exemple de calcul, à titre d'illustration et non de tarif : une tâche qui demande 5 appels, avec un historique moyen de 4 000 tokens en entrée et 500 en sortie par appel, consomme 20 000 tokens d'entrée et 2 500 de sortie. Le même travail fait par un appel unique avec un schéma de sortie coûterait environ cinq fois moins en entrée et une fois en sortie. Le rapport dépend des tarifs en vigueur, mais l'ordre de grandeur — un agent coûte plusieurs fois un appel unique — est structurel, pas conjoncturel.

La conséquence pratique : on ne dimensionne pas un agent au coût d'un appel. On le dimensionne au coût par tâche réussie, reprises incluses, mesuré sur un échantillon réel avant mise en production.

Les contrôles indispensables

Un agent sans ces sept contrôles n'est pas un prototype, c'est un incident en attente.

Liste fermée d'outils. L'agent ne doit pouvoir appeler que ce qui a été explicitement autorisé, jamais l'ensemble des outils disponibles.
Budget par tâche et par jour. Un plafond de tokens et un plafond d'appels, qui coupent l'exécution au lieu de la ralentir.
Nombre d'itérations borné. Un maximum d'étapes, avec sortie propre en cas de dépassement.
Idempotence des actions. Rejouer une étape ne doit pas produire deux fois l'effet — sinon une reprise crée un doublon.
Journalisation des étapes. Chaque appel, chaque outil, chaque résultat : sans trace, un échec est indébogable.
Sorties structurées et validées. Un schéma explicite, vérifié avant usage. Une réponse en texte libre n'est pas exploitable par un système.
Validation humaine sur l'irréversible. Une étape d'approbation avant toute action qui ne se défait pas.

Deux contrôles supplémentaires deviennent nécessaires dès que l'agent touche à des données réelles : la séparation entre lecture et écriture — un agent qui lit beaucoup et écrit peu est plus sûr qu'un agent aux droits larges — et un interrupteur d'arrêt accessible sans redéploiement.

Comment trancher en pratique

Avant d'écrire une ligne de code, cinq réponses à poser par écrit :

Quelle est la tâche exacte, avec un exemple d'entrée et la sortie attendue ?
Combien de cas réels sont disponibles pour la tester ?
Quelle est la part d'imprévu, mesurée sur ces cas ?
Que se passe-t-il si la sortie est fausse : détecté, corrigé, ou invisible ?
Quel coût par tâche rend le projet viable ?

Si la réponse à la dernière question est inférieure au coût actuel de la tâche faite à la main, l'architecture se choisit sur les quatre premières. Si elle est supérieure, la question n'est pas technique.

Un dernier point, souvent négligé : le coût de la surveillance. Un agent en production demande un jeu de tests, une mesure de qualité par version, et quelqu'un qui regarde les échecs. Ce coût d'exploitation dépasse fréquemment le coût des appels. C'est lui qui décide entre un workflow bien fait et un agent élégant.

Guide rédigé par Théo Sagniez. Les ordres de grandeur de coût sont donnés à titre de méthode de calcul : ils dépendent des tarifs en vigueur et du volume réel, et doivent être recalculés sur votre propre échantillon.

Si le sujet est en amont — décider s'il faut engager le chantier, et sur quelles hypothèses — la même logique de challenge s'applique : Comment challenger une décision stratégique avant de s'engager ?

Une question précise sur votre architecture ? Une consultation d'une heure suffit souvent à trancher entre ces quatre familles avant d'engager un développement.