En décembre 2024, l’équipe d’Anthropic publiait sa recherche sur les agents effectifs avec un détail révélateur sur la réalité du prompt chaining en production. Un agent autonome chargé de corriger des tickets GitHub échouait systématiquement dès qu’il se déplaçait hors du répertoire racine : les chemins relatifs qu’il passait à ses outils devenaient invalides. La solution n’était pas de changer de modèle. Pas d’améliorer le prompt non plus. Il a suffi d’imposer les chemins absolus dans l’interface de l’outil. L’agent a fonctionné parfaitement. En prompt chaining, les problèmes viennent rarement du LLM. Ils viennent des interfaces entre les étapes, de ce qu’on transmet, de ce qu’on perd et de ce qu’on oublie de contextualiser.
Ce guide couvre les trois mécanismes fondamentaux du prompt chaining en 2026 : la décomposition des tâches complexes, la parallélisation des branches indépendantes et la gestion explicite de l’état entre les appels LLM. Comptez 20 minutes pour lire et appliquer les patterns à votre propre workflow.
Ce que le prompt chaining change concrètement
Un LLM appelé avec un prompt monolithique (« analyse ce document de 80 pages, identifie les risques légaux, propose des amendements et rédige le mail de synthèse ») produit un résultat médiocre. Le modèle essaie de tout faire en une passe, sans pouvoir vérifier ses propres intermédiaires. Les données publiées dans les ACL 2024 Findings comparant prompt chaining et approches stepwise montrent que le chaining surpasse le raffinement par étapes successives dans un seul prompt pour les tâches de génération multi-étapes.
Le principe : chaque appel LLM reçoit une tâche précise, produit un output structuré et cet output devient l’input contrôlé de l’appel suivant. La valeur n’est pas dans la séquence en elle-même. Elle est dans la vérification que vous pouvez insérer entre chaque étape, valider, filtrer, reformater avant de passer à la suite. C’est ce qui réduit la propagation des erreurs.
En 2024, LangChain a observé que le nombre moyen d’étapes par trace dans ses pipelines est passé de 2,8 à 7,7 en l’espace d’un an. Les workflows IA sont devenus structurellement plus profonds, pas forcément plus intelligents. La profondeur bien architecturée produit de meilleurs résultats. Mal architecturée, elle multiplie les points de défaillance.
Décomposer une tâche : les règles pratiques
La décomposition est la première décision d’architecture. L’objectif : identifier le moment où une tâche dépasse la fenêtre de raisonnement efficace d’un seul appel LLM ou nécessite des vérifications intermédiaires.
Quatre critères signalent qu’une tâche doit être décomposée :
- Longueur du contexte : si le document source dépasse 30 000 tokens et que le prompt de traitement est lui-même dense, la qualité chute en fin de contexte. Mieux vaut traiter par blocs avec une synthèse finale.
- Hétérogénéité des sous-tâches : extraction de données, raisonnement logique et rédaction requièrent des instructions système très différentes. Un seul prompt composite dilue chaque instruction.
- Points de validation obligatoires : si le résultat de l’étape A doit être vérifié (format JSON valide, absence d’hallucinations factuelles, cohérence interne) avant de passer à B, la décomposition s’impose.
- Réutilisabilité des modules : si la sous-tâche « nettoyer et normaliser les données d’entrée » s’applique à plusieurs workflows, en faire un maillon indépendant et réutilisable.
Sur le plan technique, chaque maillon doit avoir une responsabilité unique et un contrat d’interface clair : format d’entrée attendu, format de sortie garanti. Le piège classique est de transmettre l’intégralité du contexte accumulé d’une étape à l’autre. Le contexte gonfle, le coût en tokens explose et le modèle en fin de chaîne se noie dans les informations parasites des étapes précédentes.
La règle opérationnelle : transmettez uniquement ce dont l’étape N+1 a besoin.
Paralléliser les branches indépendantes
La parallélisation est le levier de performance le plus sous-exploité dans les workflows IA. Si deux sous-tâches ne dépendent pas l’une de l’autre, les exécuter en séquence multiplie inutilement la latence totale. Lancez-les en parallèle et attendez les deux résultats avant de les synthétiser.
Un exemple concret : un agent de veille doit analyser 5 documents PDF pour en extraire les faits clés, puis rédiger un rapport de synthèse. Les 5 extractions sont totalement indépendantes. Les lancer en parallèle divise le temps d’exécution par un facteur proche de 5 (limité par le temps de la plus lente). La synthèse finale attend les 5 outputs et s’exécute en une seule passe.
Trois patterns de parallélisation sont documentés dans les architectures de production en 2026 :
- Map-reduce : N appels parallèles sur N fragments, un appel de réduction sur les N outputs. Cas d’usage : analyse documentaire, classification multi-items, traduction par blocs.
- Voting / self-consistency : N appels parallèles avec le même prompt sur le même input, agrégation par vote majoritaire ou par score de confiance. L’article ICLR 2023 sur la self-consistency documente des gains de précision à deux chiffres avec cette approche.
- Spécialisation multi-agents : N appels parallèles avec des prompts système différents (agent juridique, agent financier, agent technique), puis un orchestrateur synthétise les perspectives. Utile pour les due diligences et les audits complexes.
À l’usage, la parallélisation suppose une gestion des erreurs par branche. Si l’une des branches échoue (timeout, réponse malformée, contenu filtré), l’orchestrateur doit décider de réessayer, d’ignorer cette branche ou d’interrompre le workflow. Définissez ce comportement avant de mettre en production.
Gérer l’état entre les étapes
La gestion de l’état est la partie la moins bien couverte dans les tutoriels et la plus critique en production. L’état d’un workflow est l’ensemble des données qui persistent entre les appels LLM et pilotent les décisions d’orchestration.
Deux approches coexistent. Comparaison directe :
| Critère | État en mémoire (dict/objet Python) | État persistant (base de données / fichier) |
|---|---|---|
| Latence | Nulle (accès local) | 10-100 ms selon le backend |
| Résistance aux crashs | Aucune (volatile) | Complète (reprise possible) |
| Cas d’usage | Workflows courts (< 30 s, < 10 étapes) | Workflows longs, multi-sessions, multi-agents |
| Complexité d’implémentation | Faible | Moyenne à élevée |
| Partage entre agents | Impossible sans coordination | Natif si schéma partagé |
En pratique, la plupart des workflows de production combinent les deux : un état en mémoire pour les variables rapides de la session courante, un état persistant pour les checkpoints importants (résultat de l’extraction, statut de validation, outputs coûteux à régénérer).
Trois variables d’état à tracker explicitement dans tout workflow sérieux :
- Les outputs intermédiaires coûteux : si une étape coûte 5 secondes ou 10 000 tokens, son résultat doit être persisté. Vous ne voulez pas le régénérer en cas d’échec d’une étape suivante.
- Le statut de chaque maillon : pending, running, completed, failed. Indispensable pour les workflows avec reprise et pour le débogage.
- Les métadonnées de traçabilité : quel modèle a produit quel output, avec quelle version de prompt, à quelle heure. Sans ça, l’audit d’un comportement inattendu en production devient un exercice de devinettes.
Les outils et frameworks en 2026
Plusieurs frameworks ont été conçus pour le prompt chaining avec gestion d’état. Les options les plus utilisées en production :
| Framework | Type de workflow | Gestion d’état native | Parallélisation | Courbe d’apprentissage |
|---|---|---|---|---|
| LangGraph | Graphe orienté (DAG ou cyclique) | Oui (StateGraph) | Oui (noeuds parallèles) | Élevée |
| Prefect / Airflow + appels LLM | Pipeline séquentiel ou DAG | Via artefacts de tasks | Oui (tasks parallèles) | Moyenne |
| AWS Step Functions + Bedrock | Orchestration serverless | Oui (execution context) | Oui (parallel states) | Moyenne |
| Code Python vanilla + asyncio | Libre | Manuelle | Oui (async/await) | Faible |
| Anthropic Workspaces API | Multi-agents avec outils | Oui (tool use context) | Via orchestrateur | Faible à moyenne |
Un workflow simple à 5 étapes séquentielles ne nécessite pas LangGraph. Python vanilla avec asyncio et un dictionnaire d’état suffit. La complexité du framework doit être proportionnelle à la complexité du workflow.
Les erreurs qui font échouer les workflows en production
L’adoption des workflows IA progresse vite. Une enquête PwC publiée en mai 2025 auprès de 300 dirigeants senior indique que 79% des entreprises ont déployé des agents IA et que 66% d’entre elles mesurent une valeur concrète en gains de productivité. Ce qui signifie que 34% investissent sans résultats mesurables. La cause principale, observée en pratique : des pipelines qui cassent en production pour des raisons d’architecture évitables.
Cinq erreurs reviennent systématiquement :
- Transmettre l’historique complet à chaque étape. Le contexte gonfle de manière quadratique dans un workflow long. Résumez ou sélectionnez les informations pertinentes avant de les passer.
- Ne pas valider les outputs intermédiaires. Un JSON malformé produit par l’étape 2 fera planter l’étape 4 avec un message d’erreur cryptique. Validez le format et les valeurs clés à chaque transition.
- Ignorer les chemins d’erreur. Que se passe-t-il si l’étape 3 produit une réponse vide ? Si le LLM refuse de répondre pour raisons de sécurité ? Si le timeout est atteint ? Ces cas doivent être gérés explicitement.
- Mélanger logique métier et instructions LLM dans le même prompt. Les conditions if/else appartiennent au code d’orchestration. Un prompt qui dit « si le document est en anglais, alors… » est un prompt fragile.
- Oublier la traçabilité. Sans logs structurés par étape (prompt utilisé, output reçu, durée), déboguer un comportement inattendu en production prend des heures.
Construire son premier workflow en 5 étapes
Voici un workflow de traitement de tickets de support en Python, applicable directement. Ce pattern couvre la décomposition, la parallélisation et la gestion d’état minimale.
Commencez par définir le schéma d’état. Avant d’écrire une ligne de code LLM, créez une dataclass ou un TypedDict qui représente l’état complet du workflow :
from dataclasses import dataclass, field
from typing import Optional
@dataclass
class WorkflowState:
ticket_id: str
raw_text: str
category: Optional[str] = None
sentiment: Optional[str] = None
draft_reply: Optional[str] = None
status: str = "pending"
errors: list = field(default_factory=list)
Ensuite, parallélisez classification et analyse de sentiment. Ces deux analyses sont indépendantes. Lancez-les avec asyncio.gather :
import asyncio
async def classify(state: WorkflowState) -> WorkflowState:
# appel LLM classification
state.category = await llm_call(CLASSIFY_PROMPT, state.raw_text)
return state
async def analyze_sentiment(state: WorkflowState) -> WorkflowState:
# appel LLM sentiment
state.sentiment = await llm_call(SENTIMENT_PROMPT, state.raw_text)
return state
# Exécution parallèle
results = await asyncio.gather(
classify(state),
analyze_sentiment(state),
return_exceptions=True
)
Vérifiez que les deux branches ont produit des valeurs valides avant de lancer la rédaction. Si une branche a échoué, loggez l’erreur et appliquez une valeur par défaut. Le prompt de rédaction reçoit uniquement category, sentiment et un extrait du raw_text, pas l’intégralité. L’état passe ces trois champs, pas tout le workflow.
Écrivez l’état final dans votre base de données avant de retourner au système appelant. Incluez le statut final et les éventuelles erreurs partielles.
Lancez un test. Vérifiez les logs de chaque étape. Mesurez la latence totale contre la latence séquentielle.
Ce que les workflows IA ne peuvent pas encore faire seuls
Les enquêtes sur l’adoption masquent une réalité plus nuancée. Les workflows prompt chaining fonctionnent bien sur les tâches à structure stable : les étapes sont connues à l’avance, les formats d’entrée et de sortie sont prévisibles, les cas d’erreur sont énumérables. Dès que la structure du problème est inconnue à l’avance, le prompt chaining classique cède la place aux architectures agentiques dynamiques où l’orchestrateur décide lui-même des prochaines étapes.
Le critère pratique en 2026 : si vous pouvez dessiner votre workflow comme un graphe avant d’écrire la première ligne de code, le prompt chaining est le bon outil. Si vous ne pouvez pas, il vous faut un agent avec boucle de réflexion.
Le prompt chaining reste la fondation. Maîtriser la fondation d’abord.
