Appel LLM unique ou chaînes d'agents multi-étapes

Un appel LLM unique bien conçu surpasse presque toujours une chaîne d'agents multi-étapes en termes de coût, de latence et de fiabilité — sauf si la tâche exige réellement que le modèle observe un résultat intermédiaire avant de décider de la suite. La plupart des fonctionnalités « agent » que les fondateurs nous demandent de construire n'en ont pas besoin. Il leur faut un bon prompt avec une sortie structurée.

Pourquoi les chaînes s'imposent malgré tout par défaut

Les chaînes multi-étapes sont séduisantes parce qu'elles reproduisent la façon dont un humain résoudrait le problème : recherche, puis rédaction, puis relecture, puis révision. Les frameworks facilitent le câblage de quatre appels LLM avec un planificateur en amont, et ça impressionne en démo. Nous avons nous-mêmes construit exactement cette architecture pour notre propre système de cold outreach : extraire les informations sur l'entreprise, puis résumer, puis rédiger l'e-mail, puis une passe de « polish » distincte — quatre sauts, parce que c'est ainsi qu'une personne procéderait si on lui confiait la tâche étape par étape.

C'est aussi là que cette architecture se fracasse. Chaque saut représente :

• Un nouvel endroit où perdre le contexte. Notre étape de résumé ne voyait que la sortie de l'étape d'extraction, pas la page scrapée originale — si bien qu'au moment de rédiger l'e-mail, le modèle travaillait à partir d'un résumé dégradé d'un résumé.
• Une nouvelle taxe de latence. Quatre appels séquentiels de 2 à 3 secondes chacun, c'est plus de 10 secondes avant que l'utilisateur voie quoi que ce soit, avant même d'ajouter les tentatives de répétition.
• Une nouvelle surface de défaillance. Dans notre pipeline, l'étape de « polish » réécrivait régulièrement des détails que l'étape d'extraction avait correctement formulés, faute de visibilité sur pourquoi le brouillon disait ce qu'il disait — elle ne voyait qu'un brouillon et une consigne d'amélioration.

Les recommandations d'Anthropic sur ce point sont sans détour : commencez par la solution la plus simple, et n'ajoutez de la complexité agentique — planification multi-étapes, boucles d'outils — que lorsqu'un seul appel avec un bon contexte ne peut genuinement pas faire le travail (Building Effective Agents). Ce n'est pas une précaution rhétorique, c'est le modèle qui tient en production.

Ce que nous avons appris en opérant notre propre moteur d'outreach

Nous opérons notre propre système de cold outreach : il scrape le site d'un prospect avec une instance Firecrawl auto-hébergée et un LLM local, puis rédige un e-mail personnalisé par entreprise. Notre première version découpait ce processus en étapes — extraire les informations sur l'entreprise, puis résumer, puis rédiger l'e-mail, puis une passe de « polish » distincte. C'était plus lent, plus coûteux en tokens par lead, et l'étape de polish écrasait régulièrement des détails que l'étape d'extraction avait correctement formulés, faute de visibilité sur pourquoi le brouillon disait ce qu'il disait.

Nous avons tout regroupé en un seul appel : extraire les informations et rédiger l'e-mail dans un seul prompt, avec les champs d'extraction spécifiés en sortie structurée avant le corps de l'e-mail. Le coût par lead a baissé, et la qualité a augmenté — parce que le modèle conservait le contexte complet, c'est-à-dire la page scrapée réelle plutôt qu'un résumé dégradé, pendant toute la rédaction. La leçon dépasse largement le cas de l'outreach : si votre « agent » se résume à transformer une entrée en sortie sans décision de branchement au milieu, le découper en étapes n'est que du surcoût.

Un test simple avant de chaîner quoi que ce soit

Demandez-vous si la tâche comporte un point de décision qui dépend d'une information que le modèle ne possède pas encore. Si oui, vous avez probablement besoin d'au moins une boucle — le modèle doit agir, observer ce qui s'est passé, puis décider de la prochaine action. Si non, l'entrée de chaque étape est entièrement prévisible avant l'exécution du modèle, et tout appartient à un seul appel avec un bon prompt, ou à un pipeline de code déterministe dans lequel le LLM effectue une partie clairement délimitée.

Exemples qui nécessitent genuinement une itération :

• Un agent qui débogue du code contre une suite de tests en échec (il doit exécuter les tests pour savoir quoi corriger ensuite)
• Un agent qui navigue sur un site web dont le prochain clic dépend du contenu de la page courante
• Un agent support qui doit poser une question de clarification avant de pouvoir agir

Exemples qui n'en ont pas besoin, quelle que soit leur apparence « agentique » dans le pitch deck :

• Résumer un document et en extraire des champs structurés
• Classifier et router un ticket de support
• Rédiger un e-mail, une spec ou un point de situation à partir d'entrées connues

Nous abordons la version plus large de cette décision — quand une tâche est un workflow plutôt qu'un vrai agent — dans notre analyse des agents vs. workflows. Si vous hésitez entre construire en interne et acheter une plateforme, agent personnalisé vs. plateforme de chatbot couvre cette décision adjacente.

Le calcul des coûts qui intéresse vraiment les fondateurs

Les chaînes coûtent plus cher de trois façons qui se combinent — notre propre pipeline d'outreach les a toutes payées avant que nous le simplifiions :

1. Coût en tokens. Chaque appel renvoie le contexte (prompt système, sorties précédentes) qu'un appel unique n'aurait payé qu'une fois. Notre version en quatre étapes renvoyait le résumé de la page scrapée à chaque saut ; la version à appel unique paie la page complète une seule fois.
2. Coût des tentatives de répétition. Si une étape de la chaîne échoue ou retourne une sortie malformée, vous relancez soit cette étape (ajoutant de la latence), soit toute la chaîne (ajoutant du coût). Lorsque notre étape de « polish » retournait quelque chose de malformé, la correction consistait à la relancer — mais l'extraction et la rédaction avaient déjà été exécutées et facturées. Un appel unique échoue une fois, pas quatre.
3. Coût d'ingénierie. Notre version en quatre étapes nécessitait du code d'orchestration et le passage d'état entre extraction, résumé, rédaction et polish — du code qui a entièrement disparu une fois que nous avons fusionné le tout dans un seul prompt avec sortie structurée. C'est une surface de maintenance permanente, pas seulement un coût de construction initial.

Si vous estimez le coût d'exécution à grande échelle d'une fonctionnalité IA, modélisez les deux architectures sur de vraies entrées d'exemple avant de vous engager — consultez notre guide d'optimisation des coûts LLM pour structurer cette estimation. Nous avons également écrit sur la question de diligence qui surgit lorsqu'un fournisseur vous propose un système multi-agents : demandez-lui de justifier chaque saut, comme nous le décrivons dans les evals dans les contrats fournisseurs IA.

La sortie structurée fait la plupart de ce que les « étapes de planification » prétendent faire

Une grande partie de ce pour quoi les chaînes multi-étapes sont utilisées — extraire ceci, puis formater cela, puis valider l'autre — se résout mieux avec la sortie structurée : un schéma JSON ou une spec de function calling que le modèle remplit en une seule passe. Les modèles modernes sont fiables pour retourner des données structurées bien formées lorsque vous spécifiez clairement le schéma, ce qui supprime la principale raison pour laquelle les équipes ajoutent une « étape de validation » en premier lieu. Ajoutez une vérification déterministe au niveau du code après l'appel unique (ce champ se parse-t-il, cette valeur est-elle dans la plage attendue) plutôt qu'un deuxième appel LLM pour vérifier le travail du premier.

Notre conclusion

Par défaut, un seul appel. Donnez-lui le contexte complet dont il a besoin, demandez une sortie structurée, et validez de façon déterministe. Optez pour une chaîne — ou une vraie boucle agentique avec utilisation d'outils — uniquement lorsque la tâche comporte un vrai point de décision qui dépend de quelque chose que le modèle ne peut pas connaître avant d'agir. C'est une catégorie plus restreinte que la plupart des démos d'agents ne le laissent entendre, et c'est la différence entre une fonctionnalité IA bon marché et simple à opérer, et une fonctionnalité qui consume silencieusement du budget chaque fois qu'elle relit sa propre sortie.

Si vous cadrez une fonctionnalité IA et n'êtes pas sûr de quel côté de cette ligne elle se situe, parlons-en.