Conversations multi-tours

Un concept fondamental, à intégrer avant toute application de chat : Claude ne conserve aucun historique de conversation. Chaque requête API est complètement indépendante, sans mémoire des échanges précédents. Si les interfaces comme claude.ai donnent l’impression d’une mémoire, c’est parce que l’application renvoie l’historique en coulisses — et c’est exactement ce que votre code va devoir faire.

Le problème des conversations sans état

Voyez ce que donne l’oubli en pratique. Vous demandez « Qu’est-ce que l’informatique quantique ? », Claude répond. Vous enchaînez avec « Écris une autre phrase » dans une nouvelle requête : Claude n’aura aucune idée de ce à quoi vous faites référence — la requête précédente n’existe plus nulle part côté API. Il écrira une phrase sur un sujet complètement aléatoire, en toute bonne foi. Aucun paramètre magique ne règle cela : la continuité d’une conversation est entièrement à votre charge.

Comment gérer le multi-tour

La solution tient en deux disciplines :

1. Maintenir manuellement une liste de tous les messages dans votre code
2. Envoyer l’historique complet à chaque requête

Autrement dit, chaque appel API raconte la conversation depuis le début. Claude relit tout, et répond au dernier message en connaissance de tous les précédents. C’est aussi pourquoi les longues conversations coûtent de plus en plus cher : chaque tour refacture l’intégralité de l’historique en tokens d’entrée.

Fonctions utilitaires

Comme ces manipulations reviendront sans cesse, isolons-les dans trois petites fonctions :

def add_user_message(messages, text):
    user_message = {"role": "user", "content": text}
    messages.append(user_message)

def add_assistant_message(messages, text):
    assistant_message = {"role": "assistant", "content": text}
    messages.append(assistant_message)

def chat(messages):
    message = client.messages.create(
        model=model,
        max_tokens=1000,
        messages=messages,
    )
    return message.content[0].text

Rien de sophistiqué — deux constructeurs de dictionnaires et un appel API emballé — mais ces trois fonctions seront les briques de tout le cours : chaque section les réutilisera, et certaines les enrichiront (prompt système, température, outils) sans jamais changer leur interface.

Mise en pratique

Assemblons une vraie conversation à deux tours :

# Liste de messages vide
messages = []

# Question initiale
add_user_message(messages, "Définis l'informatique quantique en une phrase")

# Réponse de Claude
answer = chat(messages)

# Ajouter la réponse a l'historique
add_assistant_message(messages, answer)

# Question de suivi
add_user_message(messages, "Écris une autre phrase")

# Claude comprend maintenant le contexte
final_answer = chat(messages)

Suivez la liste messages au fil du script : un message, puis deux après l’ajout de la réponse, puis trois avec la question de suivi. Le deuxième appel chat envoie donc ces trois messages — question, réponse, relance — et Claude comprend que « Écris une autre phrase » se rapporte à l’informatique quantique, car vous lui avez fourni le contexte complet. L’étape la plus souvent oubliée est add_assistant_message : omettez-la, et Claude verra deux questions sans sa propre réponse entre elles — le fil de la conversation est déjà rompu.

Points clés à retenir

• Chaque appel API est indépendant : l’API n’a aucune mémoire entre les requêtes
• Stockez tous les messages localement et renvoyez l’historique complet à chaque tour
• N’oubliez pas d’ajouter les réponses de Claude à l’historique — sinon le fil est rompu
• Les rôles "user" et "assistant" doivent refléter fidèlement qui a dit quoi
• L’historique refacturé à chaque tour explique le coût croissant des longues conversations