[!NOTE] TL;DR Un agent IA se justifie quand ses entrées échappent aux branches énumérables, mais le coût de la preuve pèse autant que celui de l'exécution. Sur un calcul d'hypothèse à six appels, un agent coûte environ 8 fois plus cher par document qu'un pipeline à un seul appel, avant même les campagnes de rejeu. Décide avec six critères, réserve l'autonomie à la poche où elle paie, et chiffre la preuve avant d'écrire la première ligne.
Au commencement était le prompt, et le prompt avait une facture. Dans la plupart des cahiers des charges, le mot « agent » arrive bien avant la question des entrées, et jamais avant celle de la preuve.
Le cas qui me sert de fil conducteur est un pipeline serverless d'extraction sur des rapports réglementés, que j'ai étudié de près pour un grand groupe énergétique. Quatre fonctions Lambda Python 3.12 sont orchestrées par Step Functions, avec jusqu'à 20 pages traitées en parallèle. Le LLM n'intervient que dans des étapes bornées, et aucune étape ne choisit son chemin. Le mot « agent » traîne pourtant dans le code, et j'y reviendrai, parce que cette ambiguïté pèse plus lourd que je ne le pensais.
La question posée
Ma question tient en une phrase, mais sa réponse en demande plusieurs : à partir de quel niveau d'incertitude sur les entrées un agent devient-il préférable à un pipeline déterministe, une fois le coût de la preuve compté ? La grille de décision publiée sur ce blog traite la structure du problème. Je m'attache ici à ce qu'elle laisse de côté : la facture de la démonstration.
On imagine spontanément que l'agent est le choix moderne et le pipeline le choix de prudence. Les chiffres réunis ici suggèrent presque l'inverse, dès qu'on inclut la preuve dans le bilan.
Six critères de décision
Anthropic recommande de trouver « la solution la plus simple possible », et de n'ajouter de la complexité que lorsqu'elle devient nécessaire (Building effective agents). Je retiens cinq critères de terrain, puis un sixième que je propose d'ajouter.
La variance des entrées. Le guide d'OpenAI associe l'agent à des processus dont les règles sont devenues trop lourdes à maintenir, et à une forte dépendance aux données non structurées (A practical guide to building agents). Le test est concret : si tu peux dessiner l'arbre complet sur un tableau blanc sans mentir sur ce qui tient dans chaque case, tu n'as pas besoin d'un agent.
Le coût d'une erreur. Ce critère tranche plus souvent que les autres. Une action réversible tolère un agent muni d'un plafond, alors qu'une action irréversible exige une validation humaine, comme le recommande OpenAI pour les actions à fort enjeu.
Le budget de latence. Cinq appels de deux secondes donnent dix secondes de latence moyenne, avant la moindre reprise. Le budget se fixe avant le prototype, pas après la première démo, et c'est le sujet des budgets d'appels d'outils.
Le coût par invocation, et surtout sa dispersion. Anthropic indique qu'un agent consomme en moyenne environ 4 fois plus de tokens qu'une interaction de chat, et un système multi-agents environ 15 fois plus (How we built our multi-agent research system). La moyenne compte moins que la dispersion : Microsoft Research mesure, sur SWE-bench Verified, des écarts pouvant atteindre 30 fois en tokens entre deux exécutions d'une même tâche. Le détail des coûts réels fait l'objet d'un autre article.
Les multiplicateurs publiés par Anthropic se lisent ainsi :
{
"type": "bar",
"data": {
"labels": ["Chat (référence)", "Agent", "Système multi-agents"],
"datasets": [{ "label": "Multiplicateur de tokens", "data": [1, 4, 15], "backgroundColor": ["#94a3b8", "#3b82f6", "#f59e0b"] }]
},
"options": {
"responsive": true,
"plugins": { "title": { "display": true, "text": "Tokens consommés, relatifs à un chat (Anthropic, 2025)" } },
"scales": { "y": { "title": { "display": true, "text": "Multiplicateur" } } }
}
}
L'auditabilité. Si ton système relève de l'annexe III de l'AI Act, l'article 12 exige une capacité d'enregistrement automatique des événements, et les articles 19 et 26 une conservation d'au moins six mois. Le Règlement (UE) 2026/1744 repousse l'application de ces obligations au 2 décembre 2027 pour l'annexe III. Un pipeline journalise un chemin déjà écrit dans son code. Un agent doit journaliser des décisions, et ce travail ne se fait pas par accident.
Le coût de la preuve. C'est le critère que les grilles oublient le plus souvent. Il mesure ce qu'il faut dépenser pour démontrer, à chaque release, que le système tient toujours. Il porte l'argument principal de cet article, que je développe plus bas.
La matrice suivante compare les trois architectures sur ces six critères.
| Critère | Pipeline pur | Pipeline + étape LLM bornée | Agent à outils ouverts |
|---|---|---|---|
| Variance des entrées absorbée | Faible, les branches sont énumérées | Moyenne, un LLM classe ou extrait | Forte, le chemin se décide à l'exécution |
| Erreur tolérable | Bornée par le graphe | Bornée à l'étape LLM, à valider | À plafonner par outil et par budget |
| Coût par invocation | Infrastructure seule | Un appel par étape, coût connu | N appels, coût croissant à chaque tour |
| Auditabilité | Trace du chemin de code | Trace par étape, prompt versionné | Trace des décisions à construire |
| Coût de la preuve | Un cas par branche | Échantillon sur l'étape LLM | Échantillon sur les trajectoires, rejoué à chaque release |
Pour une décision rapide, l'arbre suivant suffit à trancher la plupart des cas.
flowchart TD
A["Le chemin est-il énumérable à l'avance ?"] -->|Oui| B["Pipeline déterministe avec étape LLM bornée"]
A -->|Non| C["L'erreur est-elle réversible ou détectable avant action ?"]
C -->|Non| D["Pipeline avec validation humaine, sans agent"]
C -->|Oui| E["Le coût de la preuve est-il chiffré et budgété ?"]
E -->|Non| F["Agent borné en étapes, à mesurer d'abord"]
E -->|Oui| G["Agent à outils ouverts avec journal complet"]
Le péage de la preuve
Imagine une autoroute à péages. Chaque étape stochastique est une barrière : tu paies à chaque passage, et le tarif, fixé par l'exploitant, change à chaque réfection de la chaussée. Un trajet dont l'itinéraire est connu se budgète une fois pour toutes, alors qu'un trajet dont l'itinéraire se décide à chaque carrefour se chiffre en intervalle.
Le problème ne se limite pas aux agents. Atil et al., de Penn State et Comcast, ont fait tourner cinq LLM configurés à température zéro sur huit tâches, dix fois chacun : l'exactitude varie jusqu'à 15% d'un run à l'autre, et l'écart entre meilleur et pire scénario atteint 70% (arXiv:2408.04667). Une étape LLM dans un pipeline porte donc déjà ce péage. La différence entre les deux architectures tient au nombre de barrières, pas à l'étiquette.
Zéro échec sur dix cas reste compatible avec un taux d'échec pouvant atteindre 26%. Pour borner l'échec sous 5% avec 95% de confiance, il faut soixante cas sans erreur, et trois cents pour passer sous 1%. Ces bornes sont mon calcul, en loi binomiale exacte. Les barrières se composent aussi : à 95% de réussite par décision, une chaîne de cinq décisions tombe à 77%, et une chaîne de vingt à 36%. Chaque release relance le compteur.
Dans le pipeline dont je parle, l'étape de normalisation des tableaux utilise un agent Pydantic AI au sens de la bibliothèque, mais sans aucun outil à choisir. Elle produit une sortie structurée, avec reprise automatique quand le schéma n'est pas respecté, et la procédure prévoit une campagne d'évaluation champ par champ avant chaque bascule de modèle. Mon estimation de maintenance chiffre une campagne sans régression à 1 à 3 jours-homme, et une campagne avec recalibrage des prompts à 5 à 10 jours-homme. Le mot agent y relève de l'héritage de vocabulaire, pas du comportement, et c'est précisément le genre d'écart qu'un critère de preuve rend visible.
Pour rendre le péage concret, prenons une hypothèse. Un document traverse six appels, avec un préfixe statique de 8000 tokens (instructions, schémas d'outils, extrait du document), et chaque résultat d'outil ajoute 3000 tokens que les appels suivants relisent. Le total d'entrée vaut N×S + r×N(N-1)/2, soit 93000 tokens pour l'agent, contre 8000 pour un pipeline qui lit le même préfixe une seule fois. Avec 3000 tokens de sortie côté agent et 1000 côté pipeline, la facture tombe à environ 0,22 USD contre 0,03 USD. Les tarifs sont ceux publiés par Anthropic pour Sonnet 5 : 2 USD par million de tokens en entrée, 10 USD en sortie. Le rapport de 8,3 dépasse le 4 fois moyen cité plus haut, parce que mon hypothèse fait grossir le contexte à chaque tour. Cache et traitement par lots sont ignorés, et passer à Opus 5.5 (4 USD et 20 USD) double les deux factures sans changer le rapport, mais réduire la longueur de la chaîne le modifie.
Je propose donc une hypothèse que j'appelle le péage de la preuve : le coût d'une décision stochastique ne se paie pas seulement à l'exécution, il se repaie chaque fois qu'il faut démontrer qu'elle reste juste. Ma formation en neurosciences cognitives m'a appris que la mémoire de travail a une capacité limitée. Mes agents, eux, n'ont jamais lu le cours.
D'où la règle que je retiens comme argument décisif : un agent se justifie si le gain de couverture sur les cas non énumérés dépasse à la fois le surcoût d'exécution et le surcoût de preuve, mesurés sur le même jeu de cas. Mes calculs ne disent pas que l'agent est mauvais. Ils montrent que la preuve est un poste de budget à part entière, et qu'elle se chiffre.
Les cas où la thèse plie
Bien que le péage soit réel, il n'est pas toujours dissuasif. Anthropic rapporte que son système de recherche multi-agents, avec Opus 4 en orchestrateur et des sous-agents Sonnet 4, dépasse de 90,2% un Opus 4 seul sur une évaluation interne. Le cas est favorable à l'agent : requêtes larges, parallélisables, chemin imprévisible à l'avance. Là, la couverture vaut la facture, et ma règle conclut correctement à l'agent.
Ma thèse plie davantage sur la maintenance. OpenAI cite les règles devenues trop complexes comme signal en faveur d'un agent, et je n'ai pas de chiffre comparatif qui dirait à partir de combien de branches l'arbre coûte plus cher à prouver qu'une boucle. C'est une limite de mon argument, pas une réfutation.
Second cas, qui plie la hiérarchie des leviers. Le préprint « Total Cost of Agency » (arXiv:2609.23790) juge que le coût total d'un workflow dépend surtout du choix du tier de modèle. Dans mes propres retours, l'extraction normée sur des documents hétérogènes préfère nettement les modèles à raisonnement aux modèles conversationnels. Si ta facture est dominée par le tier, le débat agent contre pipeline devient secondaire.
Un article de juillet 2026, The Harness Effect, rapporte qu'à modèles constants, une couche d'orchestration plus sobre réduit le coût par tâche de 41%, pour une qualité à parité sur 22 tâches, résultat directionnel. Le système évalué est le Writer Agent Harness, produit de l'éditeur Writer : il faut en tenir compte. Le message n'est pas que l'agent gagne, mais que l'orchestration pèse parfois plus que le choix même de l'agent.
Limites et ce qui reste à tester
Le ratio de 8,3 est une hypothèse, pas une mesure. Il dépend de mes paramètres (S, r, N) et des tarifs relevés sur la page officielle d'Anthropic, qu'il faut re-vérifier avant tout budget. Les mesures d'Atil et al. portent sur des modèles de début 2025 et sur des API hébergées, et non sur les modèles d'aujourd'hui. La projection de Gartner, selon laquelle plus de 40% des projets d'IA agentique seront annulés d'ici fin 2027 (communiqué du 25 juin 2025), reste une prévision d'analyste, et une analyse indépendante la rattache à un sondage en ligne de janvier 2025.
Mes bornes binomiales supposent des essais indépendants. Or un agent qui échoue pour la même raison, un outil mal décrit par exemple, produit des échecs corrélés, et il faut alors plus de cas que le calcul ne l'indique. Je n'ai pas non plus de mesure de latence p95 comparant les deux architectures sur un même trafic de production, et c'est le vrai trou de cet article.
Cela pourrait être facilement testé : rejouer un jeu de 300 cas réels sur les deux architectures, et journaliser le coût par cas résolu et le taux d'escalade humaine. Reste à savoir si le résultat tiendra quand le trafic changera de forme.
Ce qui survit aux cas particuliers
Plus généralement, l'autonomie n'est pas une propriété de l'architecture, mais une dépense récurrente, payée en tokens et en latence, et surtout en preuves. Garde-la dans la poche où elle rapporte davantage que son péage, et chiffre la preuve à chaque release plutôt que de la découvrir en production. Si tu veux chiffrer ce péage sur ton propre flux, écris-moi via la page de contact. Bref, paie le péage une fois par poche, pas à chaque carrefour.