Vous avez rédigé un bon prompt système. Vous avez ajouté la chaîne de pensée.#CoT Vous obtenez des résultats raisonnables sur des tâches simples. Puis une véritable exigence tombe : analyser un document de 40 pages, identifier les trois risques les plus critiques, les confronter à une checklist de conformité, rédiger un résumé des mesures correctives et formater le tout sous forme de rapport structuré. Vous essayez en un seul prompt. Le modèle produit quelque chose qui semble plausible — et qui est faux d'une manière facile à ignorer.
Il ne s'agit pas d'un problème de capacité du modèle. C'est un problème de décomposition de la tâche. Le chaînage de prompts est la réponse structurée à ce défi.
1. Qu'est-ce que le chaînage de prompts ?
Le chaînage de prompts est la pratique consistant à diviser une tâche complexe en une séquence de sous-tâches plus simples, chacune gérée par un prompt dédié, où la sortie d'une étape devient une partie de l'entrée de la suivante. Le modèle ne voit jamais le problème dans sa globalité ; il ne voit que le sous-problème dont il est actuellement responsable.
Le concept est explicité par Wu et al. (2022), qui définissent une chaîne de prompts comme "une séquence de prompts où la sortie d'un prompt est utilisée comme entrée du suivant."#CHI Leur approche des "AI Chains" a rendu ces séquences transparentes et contrôlables — un modèle mental précis qui préfigurait les frameworks d'agents basés sur les graphes orientés acycliques (DAG) comme LangGraph aujourd'hui.#LangChain
Le principe fondamental
Un modèle qui fait une chose de manière fiable a plus de valeur qu'un modèle qui essaie de faire dix choses à la fois. Le chaînage n'est pas une question de capacité du modèle — il s'agit de contraindre chaque appel à un périmètre où le modèle peut être excellent plutôt que simplement adéquat.
L'anatomie d'une étape de chaîne individuelle reste toujours la même, quelle que soit la complexité finale du pipeline :
Dohan et al. (2022) formalisent cela davantage sous le terme de cascades de modèles de langage — des programmes probabilistes où chaque étape est conditionnée par les sorties des étapes précédentes et où chaque transition peut incorporer une logique déterministe.#Cascade Ce cadre est utile : une chaîne n'est pas seulement une séquence d'appels LLM, c'est un programme dans lequel les appels LLM sont les opérations et l'état formaté en chaînes de caractères constitue la mémoire.
2. Pourquoi les prompts monolithiques échouent à grande échelle
Avant d'opter pour une chaîne, il convient de comprendre précisément pourquoi un prompt unique échoue sur des tâches complexes. L'échec n'est pas aléatoire ; il suit des schémas prévisibles.
Diffusion de l'attention
L'attention des transformers est répartie sur tous les jetons (tokens) de la fenêtre de contexte. Lorsqu'un prompt contient simultanément une description de tâche, un long document, plusieurs exemples, des règles de formatage et des contraintes de sortie, l'attention effective du modèle sur chaque composant individuel diminue. Les instructions situées au milieu d'un long prompt sont systématiquement sous-pondérées par rapport à celles du début et de la fin — un résultat confirmé par de nombreux benchmarks.#Middle Une chaîne localise l'attention de chaque étape sur les seuls jetons qui comptent pour elle.
Conflits de contrat de format
Les tâches complexes exigent souvent que le modèle raisonne, récupère, classifie et formate simultanément. Ces exigences imposent des contraintes contradictoires. Un modèle à qui l'on demande d'"analyser ce contrat, identifier les clauses de responsabilité, les vérifier par rapport à une grille et produire un rapport JSON avec un commentaire de soutien" doit écrire dans trois registres — prose analytique, données structurées et commentaire évaluatif — en un seul passage de génération. La fiabilité se dégrade car le modèle ne peut pas se consacrer pleinement à un seul format.
Compositions d'erreurs
Dans un prompt monolithique, une inférence incorrecte dans la première moitié de la réponse a tendance à se propager. Comme le modèle génère de manière autorégressive, une affirmation erronée devient le contexte de tout ce qui suit. Dans une chaîne, les erreurs sont locales à l'étape où elles se produisent et peuvent être interceptées à la limite avant de contaminer les étapes en aval.
La métaphore du plafond
Imaginez que chaque prompt possède un plafond de fiabilité — un niveau de complexité au-delà duquel la qualité de la sortie devient imprévisible. Le chaînage ne rehausse pas ce plafond ; il garantit que vous ne l'atteindrez jamais en maintenant chaque prompt individuel bien en dessous.
3. Les quatre architectures de chaîne
Quatre architectures couvrent la majorité des besoins de chaînage en conditions réelles. Elles ne sont pas mutuellement exclusives — les pipelines de production les combinent souvent toutes les quatre — mais il est utile de comprendre chacune d'elles isolément en premier lieu.
Séquentielle
Les étapes s'exécutent les unes après les autres dans un ordre fixe. La sortie de l'étape N est l'entrée de l'étape N+1. Le modèle le plus simple et le plus courant.
Branchement
La sortie d'une étape détermine quel chemin le pipeline emprunte ensuite. Une étape de classification pilote différentes chaînes spécialisées en aval.
Bouclée / Itérative
La sortie d'une étape est réinjectée en entrée jusqu'à ce qu'une condition d'arrêt soit remplie. Utilisé pour les cycles génération–critique–révision.
Map-Reduce
Une entrée volumineuse est divisée en fragments traités indépendamment (map), puis fusionnés par une étape d'agrégation finale (reduce).
Chaînes séquentielles
La chaîne séquentielle est le modèle canonique : un pipeline ordonné et fixe où chaque étape a un seul travail. C'est le choix par défaut pour toute tâche pouvant être exprimée comme une série de transformations sur du texte.
Un exemple pratique : produire une analyse concurrentielle à partir d'un ensemble de notes de recherche brutes. Le pipeline pourrait être : (1) extraire des faits structurés de chaque source, (2) normaliser les entités entre les sources, (3) identifier les contradictions, (4) classer les résultats par pertinence, (5) rédiger l'analyse. Chaque étape est petite, vérifiable et déboguable indépendamment.
Chaînes de branchement
Une chaîne de branchement utilise une étape de classification ou de routage dont la sortie détermine quelle sous-chaîne s'exécutera ensuite. C'est l'architecture correcte lorsque le même type d'entrée peut nécessiter des traitements qualitativement différents selon son contenu.
L'exigence critique est que l'étape de classification produise un ensemble fini et déterministe de labels qui correspondent clairement aux chaînes en aval. Si l'espace des labels est flou, la logique de branchement devient peu fiable. Contraignez le classificateur à un vocabulaire fixe et utilisez une sortie structurée pour l'imposer.
Chaînes bouclées / itératives
Une chaîne bouclée renvoie la sortie d'une étape à cette même étape (ou à une étape précédente) jusqu'à ce qu'une condition d'arrêt soit remplie. Le cas d'usage canonique est la boucle génération–critique–révision : un prompt rédige le contenu, un second l'évalue par rapport à une grille, et le brouillon est révisé jusqu'à ce qu'il soit validé ou qu'un nombre maximum d'itérations soit atteint.
Madaan et al. (2023) formalisent cela sous le nom de Self-Refine — un modèle améliore itérativement sa propre sortie en utilisant les retours qu'il génère lui-même.#Refine Le résultat clé est qu'un modèle agissant comme critique et réviseur dans des prompts dédiés et séparés surpasse un modèle à qui l'on demande de produire une réponse finale en un seul passage, même lorsque le budget total de jetons (tokens) est maintenu constant.
Définissez la condition d'arrêt avant de rédiger la boucle. Les trois options standard sont : une
porte
pass/fail (une étape de validation renvoie pass: true), un plafond
d'itérations
fixe (exécuter N fois au maximum, quelle que soit la qualité), ou un seuil de rendements
décroissants (s'arrêter lorsque le delta de score entre les itérations descend en dessous de ε). En
production, combinez toujours une porte de qualité avec un plafond strict — une boucle infinie est un incident
majeur en attente.
Chaînes Map-reduce
Lorsque l'entrée dépasse ce qu'une fenêtre de contexte unique peut traiter de manière fiable — ou lorsqu'un traitement parallèle indépendant est souhaitable — le modèle map-reduce s'applique. L'entrée est divisée en fragments (chunks), chaque fragment est traité par le même prompt (l'étape map), et un prompt final fusionne les résultats (l'étape reduce).
L'étape de réduction (reduce) est la plus difficile à réussir. Un prompt de réduction naïf de type "résumer tous les résumés" produit un résultat aplati et générique. Une meilleure approche consiste à faire effectuer par l'étape de réduction une opération d'agrégation spécifique — classement, détection de contradictions, extraction de thèmes — plutôt qu'une fusion libre.
| Architecture | Idéal pour | Risque clé | Terminaison |
|---|---|---|---|
| Séquentielle | Pipelines de transformation fixes, traitement de documents | Propagation d'erreurs sans validation aux limites | Fixe — la dernière étape termine |
| Branchement | Routage de requêtes, tri de contenu, tâches multi-domaines | Ambiguïté des labels provoquant un mauvais routage | Fixe — la branche se termine normalement |
| Bouclée | Rédaction, génération de code, sorties à qualité contrôlée | Boucles infinies ; rendements décroissants après 2-3 passages | Conditionnelle — porte ou plafond |
| Map-Reduce | Documents longs, résumé par lots, extraction parallèle | L'étape reduce perd les nuances ; artefacts aux limites des fragments | Fixe — la réduction se termine |
4. Le modèle de routeur et de répartiteur (dispatcher)
Le modèle de routeur mérite sa propre section car il apparaît au point d'entrée de pratiquement tout système multi-chaîne non trivial et sa qualité détermine la fiabilité de tout ce qui suit. Un routeur est un prompt (ou une fonction légère enveloppant un prompt) qui reçoit une entrée entrante et décide quelle chaîne doit la gérer.
La tentation est d'écrire un routeur qui essaie de comprendre l'entrée en profondeur. Résistez-y. Le seul travail d'un routeur est la classification dans un ensemble fini de catégories. Les catégories doivent être mutuellement exclusives et, dans la mesure du possible, collectivement exhaustives — avec un fourre-tout explicite pour les entrées qui ne rentrent dans aucune catégorie définie — et mappées directement à des chaînes nommées dans votre couche d'orchestration.
Ce modèle "décider puis agir" préfigure l'architecture ReAct (Yao et al., 2023), abordée dans la leçon sur la conception d'agents.#ReAct
Deux décisions d'ingénierie importent plus que le texte du prompt lui-même. Premièrement, la sortie
structurée : forcez le routeur à produire un objet JSON avec un schéma fixe. Un routeur qui produit
de
la prose comme "cela ressemble à une demande de résumé" nécessite un parsing de chaîne fragile. Un routeur qui
produit {"type": "summarisation", "confidence": 0.91} peut être traité par un simple appel à
JSON.parse. Deuxièmement, un seuil de confiance : tout appel de routeur avec une
confiance inférieure à un seuil configurable ne doit pas router — il doit déclencher une clarification ou un
chemin de repli. Un mauvais routage est nettement plus coûteux qu'un routage différé.
Répartiteur (Dispatcher) vs Routeur
Un routeur classifie. Un répartiteur agit sur cette classification. Conservez ces deux fonctions séparément. Le routeur doit être une fonction pure — une entrée, un label en sortie. Le répartiteur est la logique d'orchestration — il possède le mapping du label vers la chaîne, les règles de repli et les seuils de confiance. Mélanger les deux produit des prompts difficiles à tester et à modifier.
5. État et contexte à travers les étapes
Chaque étape de la chaîne reçoit un certain état et produit un certain état. Gérer cet état avec soin est ce qui distingue un pipeline de production d'une preuve de concept qui s'effondre sur les cas limites.
Quoi transmettre
L'instinct par défaut est de transmettre la sortie complète de chaque étape précédente dans chaque étape suivante. Cet instinct est erroné. Il conduit à des fenêtres de contexte qui gonflent à chaque étape, augmente le coût en jetons et — point crucial — dégrade la qualité de la sortie en forçant le modèle à analyser un contenu antérieur non pertinent pour trouver ce dont il a réellement besoin.
Le bon principe est celui du contexte minimum nécessaire : chaque étape ne reçoit que la sortie de son prédécesseur direct plus tout contexte global réellement requis (ex: l'intention initiale de l'utilisateur, une grille commune, un ensemble de contraintes fixes). Si une étape ultérieure a besoin d'une information provenant de trois étapes auparavant, c'est le signal que les étapes intermédiaires auraient dû la préserver explicitement dans leur sortie structurée.
Le modèle de schéma d'état (state schema)
Définissez un schéma d'état partagé dès le début de la conception du pipeline, avant de rédiger le prompt de chaque étape. Le schéma est un objet JSON qui accumule des données au fur et à mesure de son passage dans la chaîne. Chaque étape y lit, y apporte sa contribution et y écrit en retour. Les étapes ne communiquent pas par prose — elles communiquent via des champs.
Compression du contexte
Pour les pipelines longs traitant des documents volumineux, même la transmission du contexte minimum nécessaire peut produire des états qui approchent les limites de jetons (tokens). La solution est une étape de compression — un prompt dédié dont le seul travail est de résumer l'état accumulé sous une forme compacte qui préserve toutes les informations requises par les étapes en aval tout en écartant tout le reste. Khattab et al. (2023) traitent cela systématiquement dans DSPy, qui compile des pipelines LM déclaratifs en optimisant automatiquement les prompts et les exemples few-shot à travers les étapes — supprimant le besoin d'instructions inter-étapes rédigées à la main.#DSPy
6. Modes d'échec et propagation d'erreurs
Une chaîne n'est aussi fiable que sa limite la plus faible. Les modes d'échec dans les systèmes chaînés sont différents de — et souvent plus insidieux que — les échecs dans les systèmes à prompt unique. Ils ont tendance à être silencieux, différés et difficiles à attribuer.
Violations du contrat de format
L'étape N promet de renvoyer du JSON. L'étape N+1 appelle JSON.parse sur la sortie. Si le modèle
enveloppe sa sortie dans un bloc de code markdown, ajoute un préambule d'excuse ou renvoie un JSON malformé,
le
parsing échoue et toute la chaîne s'arrête — pas à l'étape N où l'erreur a pris naissance, mais à l'étape N+1
où
elle est consommée. Validez toujours le schéma de sortie à chaque limite d'étape avant de le transmettre en
aval. Des bibliothèques comme Zod (TypeScript) ou Pydantic (Python) rendent cela trivial. Si la validation
échoue, routez vers un prompt de réparation qui tente de reformater la sortie malformée avant de lever à
nouveau
l'erreur.
Héritage d'hallucinations
Une erreur factuelle générée à l'étape 2 n'est pas corrigée à l'étape 3, à moins que l'étape 3 ne valide explicitement par rapport à une source de vérité terrain. Dans la plupart des pipelines, ce n'est pas le cas — elle est traitée comme une entrée faisant autorité et sert de base à la suite. Un nom d'entité erroné dans une étape d'extraction devient un nom d'entité erroné dans un résumé, qui devient un nom d'entité erroné dans un rapport final. Insérez des vérifications d'ancrage (grounding checks) à toute étape produisant des affirmations factuelles : demandez à l'étape de citer la phrase spécifique du document source qui soutient chaque affirmation. Les affirmations non étayées font échouer la validation aux limites et déclenchent une nouvelle tentative ou une sortie signalée.
Amplification d'erreurs dans les boucles
Les chaînes bouclées sont particulièrement sensibles à l'amplification. Si l'étape de critique dans une boucle génération–critique–révision est mal calibrée — trop indulgente, trop sévère ou incohérente — l'étape de révision agit sur un retour erroné et peut produire une sortie pire que celle qu'elle remplace. Évaluez toujours le prompt de critique indépendamment avant de l'intégrer dans une boucle. Testez-le sur un ensemble de brouillons reconnus comme bons et mauvais pour vérifier sa précision avant de lui faire confiance comme porte de terminaison.
L'impératif du logging
Logguez l'entrée et la sortie complètes de chaque étape de la chaîne en production. Un pipeline qui échoue à l'étape 5 n'est déboguable que si vous pouvez inspecter ce que les étapes 1 à 4 ont produit. Le logging des appels LLM n'est pas une surcharge optionnelle — c'est l'outil de débogage principal des systèmes agentiques.
7. Quand ne pas chaîner
Le chaînage n'est pas universellement meilleur qu'un prompt unique bien conçu. Il comporte des coûts réels — latence, dépense en jetons (tokens), complexité d'ingénierie et multiplication des surfaces d'échec — et ces coûts ne valent pas la peine d'être payés pour des tâches qu'un prompt unique gère de manière fiable.
Ne construisez pas de chaîne lorsque :
- La tâche tient proprement dans un seul prompt. Résumer cet e-mail. Traduire cette phrase. Classifier ce ticket de support. Ce sont des tâches à étape unique. Ajouter une chaîne ajoute de la complexité sans ajouter de fiabilité.
- La latence est la contrainte principale. Chaque étape d'une chaîne représente au minimum un aller-retour LLM supplémentaire. Pour un budget de latence inférieur à deux secondes, une chaîne à deux étapes est souvent irréalisable aux vitesses d'inférence typiques. Un prompt unique soigneusement élaboré sera toujours plus rapide.
- La structure de sortie est simple et le modèle est cohérent. Si vous avez vérifié empiriquement qu'un prompt unique renvoie le schéma exact dont vous avez besoin sur 99% des entrées, l'ajout d'une étape de correction de format est une optimisation prématurée.
- Vous ne pouvez pas maintenir le pipeline. Une chaîne de cinq étapes sans logging, sans validation de schéma et sans contrats d'étape documentés est plus difficile à réparer qu'un seul prompt monolithique. Si votre équipe ne peut pas supporter la complexité ajoutée, la chaîne se dégradera silencieusement au fil du temps avec les mises à jour des modèles et les glissements sémantiques des prompts.
Utilisez une chaîne quand
La tâche comporte plusieurs sous-tâches qualitativement différentes. La sortie d'une étape est vérifiable indépendamment. La fiabilité sur le monolithe est inférieure à votre seuil de qualité. La localisation de l'erreur est importante.
Restez monolithique quand
La tâche est une transformation unique. La latence est critique. Le modèle est déjà cohérent. L'équipe ne peut pas supporter la complexité supplémentaire d'un système multi-étapes.
La règle de décision pratique : tentez d'abord la tâche avec un prompt unique bien conçu. Mesurez sa fiabilité sur un échantillon représentatif d'entrées. S'il atteint votre barre de qualité, livrez-le. Si ce n'est pas le cas, identifiez précisément quelle sous-tâche échoue — puis externalisez uniquement cette sous-tâche dans sa propre étape de chaîne. Construisez la chaîne minimale viable, pas la chaîne maximale imaginable.
Le chaînage est un outil pour gérer la complexité à grande échelle, pas une architecture par défaut. La meilleure chaîne est la chaîne la plus courte qui répond à votre exigence de fiabilité.
Prêt à vous tester ?
10 questions. Pas de limite de temps. Partagez votre score avec vos amis.
Faire le Quiz →Questions fréquemment posées
Qu'est-ce que le chaînage de prompts ?
Le chaînage de prompts décompose une tâche complexe en une séquence de sous-tâches plus simples, chacune gérée par un prompt dédié, où la sortie d'une étape devient une partie de l'entrée de la suivante. Le modèle ne voit jamais le problème entier d'un coup — chaque appel est contraint à un périmètre où il peut être excellent plutôt que simplement correct.
Pourquoi les prompts monolithiques échouent-ils sur les tâches complexes ?
L'échec est prévisible plutôt qu'aléatoire : les instructions interfèrent entre elles, l'attention se dilue entre des objectifs concurrents, le format de sortie dérive, et une erreur précoce contamine toutes les exigences en aval. Décomposer la tâche isole chaque responsabilité, de sorte que les échecs restent locaux et diagnosticables.
Quelles sont les quatre architectures de chaîne ?
Les chaînes séquentielles transmettent la sortie de chaque étape à la suivante ; les chaînes en branches exécutent des sous-tâches indépendantes en parallèle avant de fusionner les résultats ; les chaînes en boucle itèrent des cycles générer–critiquer–réviser jusqu'à atteindre un seuil de qualité ; et les chaînes map-reduce appliquent le même prompt à de nombreux segments avant d'agréger. Un routeur en amont peut classifier chaque entrée et l'orienter vers le bon pipeline.
Comment empêcher la propagation des erreurs dans une chaîne ?
Définissez un contrat de sortie structuré pour chaque étape et validez-le avant de transmettre le résultat en aval. Une couche d'assertions peu coûteuse entre les étapes intercepte tôt les sorties malformées — sans elle, les ruptures de format se propagent en cascade et les détails hallucinés sont réaffirmés comme des faits par les étapes suivantes.
Quand ne pas utiliser le chaînage de prompts ?
Quand la tâche tient proprement dans un seul prompt, quand la latence est la contrainte principale (chaque étape ajoute un aller-retour LLM complet), quand un prompt unique renvoie déjà le bon schéma sur la quasi-totalité des entrées, ou quand l'équipe ne peut pas maintenir la complexité ajoutée. La règle pratique : construisez la chaîne viable minimale, pas la chaîne imaginable maximale.
Références
- #CHI Wu, T., Terry, M., & Cai, C. J. (2022). AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts. CHI 2022. arXiv:2110.01691
- #Cascade Dohan, D., Xu, W., Lewkowycz, A., Austin, J., Bieber, D., Lopes, R. G., Wu, Y., Michalewski, H., Saurous, R. A., Sohl-Dickstein, J., Murphy, K., & Sutton, C. (2022). Language Model Cascades. arXiv preprint arXiv:2207.10342. arxiv.org
- #Middle Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. arxiv.org
- #Refine Madaan, A., Tandon, N., Gupta, P., Hallinan, S., Gao, L., Wiegreffe, S., Alon, U., Dziri, N., Prabhumoye, S., Yang, Y., Gupta, S., Majumder, B. P., Hermann, K., Welleck, S., Yazdanbakhsh, A., & Clark, P. (2023). Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023. arxiv.org
- #DSPy Khattab, O., Singhvi, A., Maheshwari, P., Zhang, Z., Shrivastava, K., Sharma, S., Colby Dodds, Z., Strubell, E., Naous, T., Gupta, R., Lerer, A., Zaharia, M., & Potts, C. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv preprint arXiv:2310.03714. arxiv.org
- #ReAct Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arxiv.org
- #CoT Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., Chi, E. H., Le, Q. V., & Zhou, D. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022. arxiv.org
- #LangChain Chase, H. (2022). LangChain [logiciel]. GitHub. github.com/langchain-ai/langchain