Accueil › Glossaire › Multi-turn

Multi-turn

Le multi-turn (ou multi-tour) désigne un mode d’interaction avec un LLM dans lequel la conversation comporte plusieurs échanges successifs entre l’utilisateur et le modèle, chaque tour s’appuyant sur le contexte des tours précédents pour maintenir la cohérence de l’échange.

Ce que multi-turn signifie concrètement

Un « tour » (turn) dans une conversation LLM correspond à un cycle complet : l’utilisateur envoie un message (user prompt), le modèle génère une réponse (assistant message). Une interaction multi-turn comporte au minimum deux tours, c’est-à-dire que l’utilisateur revient au moins une fois pour poser une question de suivi, apporter une précision, ou demander une modification.

La puissance du multi-turn réside dans la continuité contextuelle. Au deuxième tour, l’utilisateur peut dire « Peux-tu raccourcir le deuxième paragraphe ? » sans spécifier de quel texte il parle. Le modèle le sait grâce à l’historique de conversation. Cette capacité de résolution de références implicites (anaphores, déictiques, ellipses) est ce qui rend les conversations avec un LLM naturelles.

Multi-turn vs single-turn

En pratique, la majorité des applications LLM grand public sont multi-turn. Quand vous utilisez ChatGPT, Claude.ai, ou Gemini, vous êtes en multi-turn : chaque message que vous envoyez s’inscrit dans le fil de la conversation. Les usages single-turn se retrouvent surtout dans les pipelines automatisés (batch processing, classification de tickets, extraction de données) où chaque requête est indépendante.

Implémentation technique

Le modèle est stateless, votre code ne l’est pas

Le point fondamental à comprendre : les LLM via API n’ont aucune mémoire entre les requêtes. Chaque appel API est traité comme un événement isolé. C’est votre application qui doit maintenir l’état de la conversation en accumulant les messages dans un tableau et en le renvoyant intégralement à chaque requête.

import anthropic

client = anthropic.Anthropic()
conversation = []

def chat(user_message):
    # Ajouter le message utilisateur à l'historique
    conversation.append({"role": "user", "content": user_message})
    
    # Envoyer l'historique complet au modèle
    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=1024,
        system="Vous êtes un assistant technique.",
        messages=conversation
    )
    
    # Ajouter la réponse du modèle à l'historique
    assistant_text = response.content[0].text
    conversation.append({"role": "assistant", "content": assistant_text})
    
    return assistant_text

# Tour 1
print(chat("Comment configurer Nginx ?"))
# Tour 2 (le modèle sait qu'on parle de Nginx)
print(chat("Et pour ajouter HTTPS ?"))
# Tour 3 (le modèle sait qu'on parle de HTTPS sur Nginx)
print(chat("Quel certificat recommandes-tu ?"))

Ce code minimal illustre le mécanisme central du multi-turn : à chaque tour, l’historique complet (tous les messages user + assistant précédents) est renvoyé au modèle. C’est ce qui lui permet de « se souvenir » de la conversation.

Gestion de l’alternance des rôles

Chez Anthropic, les messages doivent strictement alterner entre user et assistant. Le premier message doit être un user. Cette contrainte influence l’implémentation du multi-turn : si votre logique applicative a besoin d’injecter du contexte entre deux tours (résultat d’un outil, information externe), elle doit le faire dans un message user (ou fusionner le contenu avec le message user existant).

Chez OpenAI, cette contrainte est plus souple : les messages consécutifs du même rôle sont autorisés, ce qui simplifie certains cas comme l’injection de résultats d’outils multiples.

Défis du multi-turn

Croissance du coût en tokens

Le coût d’une conversation multi-turn croît de manière significative avec le nombre de tours. À chaque tour N, vous renvoyez tous les tokens des tours 1 à N-1, plus le nouveau message. Le coût total en tokens d’entrée pour une conversation de N tours est proportionnel à N² (la somme des préfixes successifs).

Exemple concret : une conversation de 10 tours sur Claude Opus 4.6, avec une moyenne de 300 tokens par tour (user + assistant), accumule environ 3 000 tokens d’historique au tour 10. Le coût total des tokens d’entrée pour les 10 tours est d’environ $0,083 sans caching. Avec le prompt caching Anthropic (cache read à ~10 % du prix), ce coût descend à environ $0,02. L’économie est encore plus significative pour les conversations de 50 ou 100 tours.

Dérive contextuelle

Au fil des tours, le sujet de conversation peut évoluer. Le modèle continue de traiter l’historique entier, y compris les échanges sur des sujets désormais obsolètes. Cette « dette contextuelle » peut diluer la pertinence des réponses. Les solutions incluent le résumé périodique de l’historique et la segmentation explicite des sujets (« Changeons de sujet : parlons maintenant de… »).

Débordement de la fenêtre de contexte

Pour les conversations très longues (sessions de coding multi-heures, support technique complexe, sessions d’analyse), l’historique peut dépasser la fenêtre de contexte du modèle. Les stratégies de gestion sont détaillées sur la page conversation history : troncation, résumé, compaction automatique (Claude Opus 4.6), ou approche hiérarchique.

Effet Lost in the Middle

Dans un historique long, les informations situées au milieu de la séquence de messages reçoivent moins d’attention du modèle que celles au début et à la fin. C’est le phénomène Lost in the Middle. En pratique, si l’utilisateur fait référence à un échange ancien situé au milieu d’une longue conversation, le modèle peut ne pas le retrouver correctement. Les conversations critiques peuvent bénéficier d’un rappel explicite des points importants dans le dernier message user.

Multi-turn dans les systèmes agentiques

Les agents IA poussent le multi-turn à l’extrême. Un agent peut maintenir des conversations de dizaines, voire centaines de tours, incluant non seulement les échanges textuels mais aussi des appels d’outils (function calling), des résultats de recherche, des exécutions de code, et des interactions avec des sous-agents.

Dans ce contexte, la gestion du multi-turn devient un problème d’orchestration. Le protocole MCP (Model Context Protocol) et les frameworks agentiques comme l’Anthropic Agents SDK structurent les interactions multi-turn avec des primitives dédiées : mémoire persistante, planification multi-étapes, et routage entre agents spécialisés. Le system prompt d’un agent agentique définit non seulement le comportement conversationnel, mais aussi la stratégie de gestion de l’historique sur de longues sessions.

Claude Opus 4.6 intègre des fonctionnalités spécifiquement conçues pour le multi-turn agentique : la compaction automatique de contexte (résumé transparent de l’historique long), l’adaptive thinking (raisonnement ajusté à la complexité du tour), et les Agent Teams (coordination de plusieurs instances). Ces fonctionnalités reflètent le fait que le multi-turn n’est plus uniquement un problème d’interface chat, mais un composant fondamental de l’architecture des systèmes IA autonomes.

Évaluation de la qualité multi-turn

Évaluer un système multi-turn est plus complexe qu’évaluer des réponses single-turn. Les critères incluent la cohérence contextuelle (le modèle se contredit-il entre les tours ?), la résolution de références (comprend-il correctement « il », « ça », « le document précédent » ?), la gestion des corrections (si l’utilisateur corrige une erreur, le modèle intègre-t-il la correction ?), et la robustesse sur de longues conversations (la qualité se maintient-elle au tour 50 comme au tour 5 ?).

Les benchmarks comme MT-Bench (Multi-Turn Benchmark) évaluent spécifiquement la qualité multi-turn des LLM en posant des questions de suivi qui testent la capacité du modèle à maintenir la cohérence et à approfondir un sujet. Les systèmes d’évaluation LLM-as-judge (où un autre LLM évalue la qualité des réponses) sont particulièrement utiles pour le multi-turn, car ils peuvent vérifier la cohérence sur l’ensemble de la conversation.

Multi-turn dans les interfaces grand public

Les interfaces comme ChatGPT, Claude.ai et Gemini gèrent le multi-turn de manière transparente pour l’utilisateur. L’historique de conversation est maintenu côté serveur, et chaque nouveau message l’enrichit automatiquement. L’utilisateur n’a pas à se soucier de la gestion des tokens ou de la troncation.

Toutefois, même dans ces interfaces, les limites du multi-turn se manifestent. Sur les très longues conversations, les utilisateurs constatent parfois que le modèle « oublie » des instructions données en début de session, ou qu’il se contredit sur des détails évoqués bien plus tôt. Ce n’est pas un bug : c’est la conséquence du biais positionnel (Lost in the Middle) et, dans certains cas, de la troncation ou compaction automatique de l’historique par la plateforme.

Claude.ai et les applications Claude Desktop proposent des fonctionnalités mémoire qui persistent entre les conversations (souvenirs du profil utilisateur, préférences). C’est un mécanisme complémentaire au multi-turn intra-conversation : la mémoire persiste entre les sessions, tandis que l’historique multi-turn ne concerne qu’une seule conversation.

Patterns d’architecture multi-turn

Pattern direct (historique complet)

Le pattern le plus simple : accumulez tous les messages dans un tableau et renvoyez-le intégralement à chaque requête. C’est adapté aux conversations courtes (moins de 20 tours) sur des modèles avec de grandes fenêtres de contexte. L’avantage est la simplicité d’implémentation. L’inconvénient est la croissance du coût et de la latence.

Pattern sliding window (fenêtre glissante)

Conservez uniquement les N derniers tours dans l’historique envoyé au modèle. Le modèle perd le contexte des tours anciens, mais le coût et la latence restent bornés. Ce pattern convient aux chatbots de support où les interactions sont relativement indépendantes d’un tour à l’autre. Le risque : si l’utilisateur fait référence à un échange qui a été tronqué, le modèle ne pourra pas répondre correctement.

Pattern résumé + récent

Maintenez un résumé glissant de la conversation ancienne (généré par le LLM lui-même) et les 5 à 10 derniers tours en détail. Ce pattern offre un bon compromis entre préservation du contexte et contrôle des coûts. Le résumé est régénéré périodiquement (tous les 10 tours ou quand l’historique dépasse un seuil). C’est le pattern recommandé pour la plupart des applications multi-turn de production.

Pattern hiérarchique (agents)

Pour les agents IA avec des sessions de dizaines ou centaines de tours : combinez un résumé global, les messages récents en détail, et une base vectorielle pour la mémoire à long terme. L’agent peut interroger sa mémoire vectorielle pour retrouver des faits spécifiques mentionnés en début de session. C’est l’approche la plus robuste mais aussi la plus complexe à implémenter.

Bonnes pratiques

Pour une implémentation multi-turn robuste, suivez ces principes :

Surveillez la taille de l’historique en temps réel. Implémentez un compteur de tokens (via tiktoken pour OpenAI ou le tokenizer Anthropic) qui suit la taille totale de l’historique à chaque tour. Déclenchez votre stratégie de troncation ou de résumé avant d’atteindre la limite de la fenêtre de contexte, pas quand l’API retourne une erreur.

Activez le prompt caching. Le caching réduit dramatiquement le coût des conversations multi-turn. Chez Anthropic, structurez vos requêtes avec le contenu stable en premier (system prompt + historique existant) et le nouveau message en dernier. Le préfixe stable est caché (cache read à ~10 % du prix), et seul le nouveau message est traité au prix plein.

Nettoyez les résultats d’outils. Les appels d’outils peuvent injecter des milliers de tokens de résultats dans l’historique (résultats de recherche, contenus de fichiers, réponses d’API). Une fois que le modèle a traité ces résultats et produit sa réponse, résumez ou tronquez les blocs tool_result dans l’historique pour les tours suivants. Un résultat d’outil de 5 000 tokens qui reste dans l’historique pendant 20 tours coûte 100 000 tokens d’entrée cumulés.

Testez sur des conversations longues. Ne vous contentez pas de tester sur 3 tours. Simulez des conversations de 30, 50, 100 tours et vérifiez que la qualité des réponses se maintient, que les références contextuelles sont correctement résolues, et que les corrections utilisateur sont intégrées. Identifiez votre point de dégradation et adaptez votre stratégie de gestion d’historique en conséquence.

Gérez les fins de conversation. Implémentez une logique de détection de fin de conversation ou de changement de sujet majeur. Quand l’utilisateur passe à un tout autre sujet, envisagez de commencer un nouvel historique (avec éventuellement un résumé de la session précédente) plutôt que de continuer à accumuler un historique de plus en plus hétérogène.

Journalisez pour diagnostiquer. Enregistrez la taille de l’historique (en tokens et en nombre de messages), les stop_reason des réponses, et les éventuels événements de troncation/résumé. Quand un utilisateur signale une réponse incohérente, la première chose à vérifier est l’état de l’historique au moment de cette requête.

Verdict

Le multi-turn est le mode d’interaction naturel avec un LLM pour la plupart des applications conversationnelles. Il transforme un modèle de complétion de texte en un partenaire de dialogue cohérent. Mais cette cohérence a un coût (tokens cumulatifs) et des limites (fenêtre de contexte, Lost in the Middle, dérive contextuelle). Les développeurs qui traitent le multi-turn comme un détail d’implémentation plutôt que comme un composant architectural se retrouvent avec des applications qui fonctionnent bien pendant 5 tours et se dégradent à 50. Investissez dans une gestion d’historique solide, exploitez le prompt caching, et testez systématiquement sur des conversations longues.