Chaîner les prompts

Quand un seul prompt ne suffit plus

La leçon précédente montrait comment empiler les techniques dans un prompt unique. Cette approche a une limite : certaines tâches sont trop complexes pour tenir en un seul appel, et l’on s’en aperçoit à un symptôme précis — le prompt fonctionne sur les deux ou trois premières étapes puis se dégrade sur les suivantes, comme si le modèle perdait de vue le début de sa consigne.

Le chaînage consiste alors à décomposer la tâche en plusieurs étapes, où la sortie d’un prompt devient l’entrée du suivant. Vous ne demandez plus « extrais, analyse et rédige » ; vous demandez trois fois une seule chose.

Ce que vous y gagnez

La précision d’abord : chaque prompt se concentre sur une sous-tâche unique, avec ses propres instructions et son propre format de sortie, sans arbitrage interne entre des objectifs concurrents. Le déboguage ensuite — et c’est souvent le gain décisif en production. Quand un pipeline en trois étapes produit un mauvais rapport, vous savez lire les sorties intermédiaires et identifier exactement où le processus a échoué ; avec un prompt monolithique, vous n’avez qu’un résultat décevant et aucune piste.

Vient ensuite la flexibilité : modifier l’étape de synthèse ne touche pas à l’étape d’extraction, et vous pouvez les faire évoluer séparément. Enfin, le chaînage vous rend le contrôle, puisque vous pouvez injecter de la logique métier entre les étapes — filtrer, compléter avec une base de données, refuser de continuer si l’extraction est vide.

Le schéma classique

Prompt 1 : Extraire les informations cles d'un document
    ↓ sortie
Prompt 2 : Analyser les informations extraites
    ↓ sortie
Prompt 3 : Generer un rapport structure

Cette progression du brut vers le synthétique se retrouve dans la plupart des chaînes réelles. Notez que chaque flèche est un endroit où votre code reprend la main.

L’implémentation

# Etape 1 : Extraction
response1 = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=2000,
    messages=[
        {"role": "user", "content": f"Extrais les faits cles de ce texte : <texte>{document}</texte>"}
    ]
)
faits = response1.content[0].text

# Etape 2 : Analyse
response2 = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=2000,
    messages=[
        {"role": "user", "content": f"Analyse ces faits et identifie les tendances : <faits>{faits}</faits>"}
    ]
)
analyse = response2.content[0].text

# Etape 3 : Rapport
response3 = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=2000,
    messages=[
        {"role": "user", "content": f"Redige un rapport executif base sur cette analyse : <analyse>{analyse}</analyse>"}
    ]
)

Le motif est toujours le même : on récupère response.content[0].text, on le range dans une variable, on l’injecte dans le prompt suivant entre balises. Rien d’autre ne circule entre les étapes — chaque appel repart d’un contexte vierge, ce qui explique à la fois la propreté de la méthode et la nécessité de transmettre explicitement ce dont l’étape suivante a besoin.

Quelques réflexes de production

Structurez systématiquement les entrées et sorties de chaque étape avec des balises XML : c’est ce qui rend le passage de témoin fiable. Validez la sortie intermédiaire avant de passer à l’étape suivante, ne serait-ce qu’en vérifiant qu’elle n’est pas vide et qu’elle contient les balises attendues, sans quoi une erreur silencieuse se propagera jusqu’au rapport final. Pensez aussi à utiliser des modèles différents selon les étapes — Haiku pour une extraction mécanique, Sonnet pour une analyse qui demande du jugement — car toutes les sous-tâches n’exigent pas la même puissance. Gardez enfin un historique des sorties intermédiaires : le jour où un utilisateur signale un rapport aberrant, cet historique vous fait gagner des heures.

Où le chaînage s’impose

Il devient naturel sur l’analyse de documents longs, où l’on extrait avant de synthétiser. On le retrouve dans la génération de contenu en plusieurs passes — brouillon, révision, formatage —, dans le traitement de données avec ses phases de nettoyage, de transformation puis d’analyse, et dans les workflows de décision qui enchaînent classification, routage et action. Dans chacun de ces cas, un humain procéderait exactement de la même façon : par étapes, en vérifiant au passage.