Structure de base d'un prompt

L’API Messages

Tout échange avec Claude passe par l’API Messages. Le principe tient en une phrase : vous transmettez une conversation, le modèle y ajoute le tour suivant. Avant de parler de techniques de rédaction, il faut donc comprendre le contenant, parce que la plupart des prompts qui « ne marchent pas » sont en réalité des prompts mal placés dans la structure.

Au minimum, chaque appel nécessite trois paramètres :

• model : le nom du modèle (ex: claude-sonnet-5)
• max_tokens : le nombre maximal de tokens à générer
• messages : une liste de messages avec role et content

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Bonjour, Claude !"}
    ]
)

Notez que max_tokens est un plafond et non une consigne de longueur : il borne ce que le modèle a le droit de produire, il ne lui demande pas d’être bref. Si vous voulez une réponse courte, c’est dans le texte du prompt que cela se dit, pas dans ce paramètre.

L’alternance des rôles

La liste messages obéit à deux règles de formatage strictes. Les messages user et assistant doivent alterner, et la conversation doit toujours commencer par un message user. Ce n’est pas une coquetterie de l’API : c’est ce qui permet au modèle de savoir qui a dit quoi, et donc à qui il est censé répondre.

Cette contrainte ouvre deux possibilités très utiles. La première : vous pouvez simuler une conversation multi-tours en empilant plusieurs paires user/assistant, même si ces échanges n’ont jamais eu lieu. Imaginez que vous construisiez un assistant de support qui doit se souvenir d’un numéro de commande donné trois messages plus tôt — vous reconstituez cet historique à la main et vous le passez en entrée.

La seconde possibilité est plus subtile : vous pouvez pré-remplir un message assistant en fin de liste. Le modèle considère alors qu’il a déjà commencé à parler et poursuit à partir de ce point exact. Nous exploiterons cette mécanique en détail plus tard ; retenez pour l’instant qu’elle existe et qu’elle découle directement de la structure user/assistant.

Le prompt système

Le prompt système se passe dans un paramètre distinct, system. Il fournit un contexte global, des instructions et des directives à Claude avant la conversation. Concrètement, ce qui y figure vaut pour tous les tours de l’échange, alors qu’une consigne glissée dans un message user risque d’être comprise comme valable pour ce seul message.

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system="Tu es un assistant qui repond uniquement en haikus.",
    messages=[
        {"role": "user", "content": "Parle-moi des chats."}
    ]
)

Dans cet exemple, la contrainte du haiku tiendra à la dixième question comme à la première. Placez-y ce qui relève de l’identité et des règles permanentes ; gardez les messages user pour la demande du moment. Un bon prompt système améliore la capacité de Claude à suivre des règles et des instructions.

Deux manipulations pour ancrer tout cela

Prenez dix minutes et écrivez vous-même les appels. D’abord, en utilisant le bon formatage user/assistant, composez un prompt qui amène Claude à compter jusqu’à trois : la difficulté n’est pas la tâche, c’est de placer correctement les rôles. Ensuite, reprenez l’appel avec system et modifiez le prompt système pour que Claude réponde en espagnol — puis posez-lui deux ou trois questions successives pour vérifier que la consigne tient sur toute la conversation, et pas seulement sur le premier tour.