Conversations multi-tours

Jusqu’ici, chaque échange avec Claude était un aller-retour unique. Mais dans une vraie application, l’utilisateur pose des questions de suivi : si après « Combien font 1+1 ? » vous demandez « Et si j’ajoute 3 ? », Claude doit savoir que vous parlez du résultat précédent. Cette leçon construit le mécanisme qui rend cela possible — et qui sera le socle de toutes les applications du cours.

Aucun stockage de messages

Point fondamental, à graver avant d’écrire une ligne : ni Bedrock ni Claude ne conservent vos messages. Chaque appel API est totalement indépendant — aucune session, aucun identifiant de conversation, aucune mémoire côté service. La conséquence directe : c’est à votre code de maintenir l’historique de conversation et de le renvoyer intégralement à chaque requête.

Faites l’expérience inverse pour vous en convaincre : envoyez uniquement « Et si j’ajoute 3 ? » sans contexte. Claude ne sait pas de quoi vous parlez ; il tentera de répondre — les modèles répondent toujours — mais la réponse sera incohérente, construite sur une supposition. Si les interfaces de chat que vous connaissez semblent avoir de la mémoire, c’est que leur code applicatif fait exactement ce que nous allons écrire.

Construire le contexte conversationnel

Pour maintenir le contexte, incluez l’intégralité de l’historique dans chaque requête : tous les messages utilisateur ET toutes les réponses de l’assistant, dans l’ordre. Comme ces manipulations reviendront partout, isolons-les dans des fonctions utilitaires :

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

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

def chat(messages):
    response = client.converse(
        modelId=model_id,
        messages=messages
    )
    return response["output"]["message"]["content"][0]["text"]

Trois briques minuscules — deux constructeurs de messages, un appel API emballé — mais ne vous fiez pas à leur taille : ce trio sera réutilisé et enrichi dans chaque section du cours, du prompt système aux outils. Les écrire une fois proprement, c’est s’épargner de les réécrire cinquante fois.

Implémenter une conversation multi-tours

Voici le flux complet étape par étape :

# Initialiser la liste de messages
messages = []

# Ajouter la question initiale
add_user_message(messages, "Combien font 1+1 ?")

# Obtenir la réponse
answer = chat(messages)

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

# Poser une question de suivi
add_user_message(messages, "Et si j'ajoute 3 a ce résultat ?")

# Appeler chat avec l'historique complet
answer = chat(messages)
print(answer)

Suivez la liste messages au fil du script : un message, puis deux, puis trois. Le second appel chat envoie donc l’échange complet — question, réponse, relance — et avec l’historique complet, Claude comprend le contexte et répond correctement : « En partant du résultat de 1+1 = 2, si nous ajoutons 3, nous obtenons : 2 + 3 = 5. » L’étape la plus souvent oubliée est add_assistant_message : sans elle, Claude verrait deux questions sans sa propre réponse entre les deux — le fil est déjà rompu.

Alternance obligatoire des rôles

Une règle de protocole à connaître : l’API impose une alternance stricte des rôles dans la liste de messages — utilisateur, assistant, utilisateur, assistant. Deux messages consécutifs du même rôle provoqueront une erreur explicite. Ce schéma reflète le flux naturel d’une conversation, et il vous servira de garde-fou : une erreur d’alternance signale presque toujours un oubli d’add_assistant_message dans votre boucle.

Cette gestion manuelle de l’historique peut sembler fastidieuse au début — c’est le prix d’une API sans état, qui en échange ne vous impose aucune infrastructure de session. Et c’est un schéma fondamental : toute application conversationnelle avec Claude, du chatbot au système d’agents, repose exactement sur cette liste de messages que votre code entretient.

Points clés à retenir

• Aucune mémoire côté API : chaque requête est indépendante, l’historique est votre responsabilité
• Renvoyez l’intégralité des échanges à chaque tour — questions et réponses de l’assistant
• Les trois utilitaires (add_user_message, add_assistant_message, chat) serviront tout le cours
• N’oubliez jamais d’ajouter les réponses de Claude à l’historique avant la question suivante
• L’API exige l’alternance stricte user/assistant — une erreur d’alternance trahit un oubli dans la boucle