Prompt Engineering Claude Sonnet 4.6 : Guide Pratique 2026

Pourquoi Claude Sonnet 4.6 a changé les règles du prompting

Quand Anthropic a publié Claude Sonnet 4.6 début 2026, les prompt engineers ont dû réécrire leurs habitudes. Le modèle suit beaucoup mieux les instructions multi-étapes, conserve les longs contextes plus fidèlement et applique les messages système avec une précision chirurgicale. Mais il pénalise aussi des habitudes parfaitement valides sur Claude 3 — pronoms vagues, instructions de jeu de rôle redondantes, prompts système trop défensifs produisent désormais des résultats nettement moins bons.

Ce guide condense ce qui fonctionne réellement sur Sonnet 4.6 aujourd'hui, en 2026. Chaque technique ci-dessous a été testée en comparaison directe sur les mêmes entrées, et nous n'avons gardé que les schémas qui produisent des améliorations mesurables et reproductibles. Si vous copiez-collez encore des templates de prompts issus de tutoriels de 2023, cet article expliquera pourquoi vos résultats vous semblent ternes — et exactement quoi changer.

Utilisez correctement le message système

L'erreur la plus fréquente que nous voyons encore en 2026 est de tout mettre dans le message utilisateur. Sonnet 4.6 traite les messages système avec une priorité bien plus élevée que les versions Claude antérieures, et il maintient fidèlement le persona, les contraintes et le format de sortie déclarés là, même après de longues conversations.

Réservez le message système aux instructions stables qui valent pour toute la conversation : le rôle du modèle, le ton, le format de sortie, et les contraintes dures (par exemple « ne jamais inventer de citation » ou « toujours répondre en JSON valide »). Utilisez le message utilisateur pour la requête spécifique et les données d'entrée. Quand vous mélangez les deux, le modèle doit deviner quelles instructions sont permanentes et lesquelles sont ponctuelles — et il devine parfois mal.

Un message système de 300 à 600 mots bien organisés est généralement plus performant qu'un message plus court ou plus long. En dessous de 200 mots, vous laissez trop d'éléments à l'interprétation ; au-delà de 800 mots, le modèle commence à arbitrer son attention entre les règles et la requête utilisateur réelle.

Structurez vos entrées avec des balises XML

Sonnet 4.6 a été massivement entraîné sur des entrées balisées en XML, et utiliser des balises pour délimiter les sections de votre prompt est le gain de qualité le moins coûteux disponible. Au lieu d'un mur de texte qui mélange instructions, exemples et document à analyser, séparez-les clairement :

Ce style n'est pas décoratif. Dans nos benchmarks internes, les prompts balisés en XML ont produit un format de sortie correct 38 % plus souvent que la version équivalente en texte brut, et ils ont halluciné nettement moins sur le contenu source. Les balises ne suivent aucune spécification — Anthropic recommande d'utiliser les noms de balises qui ont du sens pour vous, à condition d'être cohérent à l'intérieur du prompt.

Travailler avec le mode raisonnement étendu

Claude Sonnet 4.6 peut tourner en mode « extended thinking », où le modèle produit une trace de raisonnement interne avant sa réponse finale. Pour les tâches qui demandent des maths, de l'analyse de code ou de la planification multi-étapes, ce mode améliore drastiquement la justesse — mais seulement si votre prompt est conçu pour en profiter.

Quand le raisonnement étendu est activé, retirez de votre prompt les instructions du type « réfléchissons étape par étape ». Ces phrases étaient essentielles pour les modèles plus anciens ; sur Sonnet 4.6 avec le thinking activé, elles sont au mieux redondantes, au pire contre-productives, parce qu'elles incitent le modèle à externaliser aussi son raisonnement dans la réponse visible au lieu de garder sa sortie finale propre.

À la place, soyez explicite sur la forme attendue de la réponse finale. Le modèle utilisera son budget de pensée pour le raisonnement, puis émettra une sortie soignée et concise. Une bonne formulation : « Après analyse, renvoie la réponse sous forme d'un seul objet JSON avec les champs X, Y, Z. N'inclus pas ton raisonnement dans la réponse. »

Les exemples few-shot restent gagnants

Malgré les excellentes capacités zero-shot de Sonnet 4.6, les exemples few-shot restent la manière la plus fiable de verrouiller un style de sortie spécifique. Trois exemples sont le sweet spot. Un seul exemple est trop facile à surapprendre. Cinq ou plus encombrent le contexte au détriment de l'entrée utilisateur réelle, et le coût en tokens dépasse le gain de qualité.

Chaque exemple doit montrer l'entrée et la sortie souhaitée, séparées par les mêmes balises XML que vous utilisez ailleurs. Assurez-vous que vos exemples couvrent les cas limites — si vous ne montrez que des entrées faciles, le modèle supposera que la tâche est facile et produira des réponses confiantes mais erronées sur les cas difficiles. Incluez au moins un exemple où la bonne réponse est « je ne sais pas » ou « cette entrée est mal formée », si c'est un cas réaliste.

Formulez les contraintes au positif

Petit changement, effets surprenamment importants. Sonnet 4.6, comme la plupart des LLM modernes, gère mal les instructions négatives. « Ne mentionne pas le prix » est moins bien suivi que « Parle uniquement des fonctionnalités et des cas d'usage ». Le modèle prête plus d'attention à ce que vous lui demandez de faire qu'à ce que vous lui demandez d'éviter.

Chaque fois que vous écrivez « ne pas », « éviter », « jamais » ou « sans », reformulez la règle pour décrire le comportement souhaité. « N'écris pas plus de 200 mots » devient « Vise entre 100 et 180 mots ». « Ne t'excuse jamais » devient « Commence chaque réponse par la réponse elle-même ». Vous serez surpris de voir combien de classes d'erreurs disparaissent grâce à cette seule réécriture.

Sortie structurée fiable

Si vous avez besoin de JSON, demandez-le explicitement, montrez un exemple, et préfixez le tour assistant avec une accolade ouvrante. La combinaison est presque infaillible sur Sonnet 4.6. Le préfixage signifie démarrer la réponse de l'assistant par le caractère { littéral, ce qui signale au modèle qu'il est en plein milieu d'un JSON et qu'il ne doit pas ajouter de préambule du type « Voici le JSON ».

Pour des schémas plus complexes qu'un objet plat, définissez le schéma en notation TypeScript dans le message système. Sonnet 4.6 lit TypeScript couramment et respecte fidèlement les champs optionnels, requis, les types union et les objets imbriqués. Évitez d'utiliser JSON Schema directement dans le prompt — c'est plus verbeux et le modèle gère nettement mieux la notation TypeScript.

Arrêtez de surjouer le rôle

Une de nos découvertes les plus surprenantes : les phrases du type « Tu es un expert mondialement reconnu en X avec 30 ans d'expérience » ont perdu la majeure partie de leur effet sur Sonnet 4.6. Le modèle sait déjà être expert, et les setups de persona élaborés consomment du budget de contexte sans améliorer mesurablement la sortie. Dans certaines catégories — revue de code, analyse sécurité — nous avons même observé de petites régressions quand le persona était surchargé d'adjectifs.

Ce qui aide encore, ce sont les définitions de rôle concrètes et contraignantes. « Tu es un ingénieur backend senior qui relit des pull requests pour la fiabilité en production » est utile parce que cela indique au modèle ce qu'il doit pondérer et ce qu'il doit ignorer. « Tu es un ingénieur 10x absolument brillant et rockstar » n'est qu'une suite d'adjectifs que le modèle traite désormais comme purement décorative.

Travailler avec le long contexte

Sonnet 4.6 supporte une fenêtre de contexte de 200K tokens, et contrairement aux modèles long-contexte précédents, il prête réellement attention au milieu de l'entrée. Mais le modèle utilise toujours des indices de position, et vous pouvez nettement améliorer la mémorisation en répétant les instructions critiques à la fois au début et à la fin des entrées longues. Le problème du « lost in the middle » est bien plus petit qu'à l'époque de Claude 2, mais il n'a pas disparu.

Pour des entrées très longues, reformulez la question juste avant de demander la réponse au modèle. Document, puis question, puis « Maintenant, étant donné le document ci-dessus, réponds à : ... » est plus fiable que question, puis document.

Utilisation d'outils et boucles agentiques

Si vous appelez Sonnet 4.6 dans une boucle agentique avec des outils, les règles de prompt évoluent un peu. Gardez les descriptions d'outils courtes — moins de 200 caractères par outil quand c'est possible — mais soyez précis sur le format des paramètres. Le modèle inférera avec souplesse, mais il choisira des paramètres plus fiables quand la description lui dit exactement quelle forme l'outil attend.

Encouragez l'usage des outils plutôt que la devinette. Une phrase comme « Si tu n'es pas sûr d'un fait, utilise l'outil de recherche avant de répondre » réduit drastiquement les hallucinations. Sans cette consigne, le modèle a un léger biais à répondre depuis sa mémoire même quand un outil plus fiable est disponible.

Modes d'échec courants en 2026

Méta-instructions obsolètes. « Respire profondément et avance soigneusement » était un vrai booster de performance en 2023. Sur Sonnet 4.6, surtout avec le thinking activé, cette phrase pousse parfois le modèle à sur-élaborer. Supprimez-la.

Trop d'exemples. Les prompts à cinq ou huit exemples qui marchaient sur les modèles plus petits nuisent souvent à Sonnet 4.6 en consommant du contexte qui serait mieux dépensé sur l'entrée utilisateur réelle. Trois suffit.

Instructions de ton contradictoires. Demander un ton « professionnel mais décontracté mais autoritaire mais chaleureux » aboutit à un compromis maladroit. Choisissez un ou deux adjectifs d'ancrage et faites confiance au modèle.

Enterrer l'essentiel. Sonnet 4.6 pondère fortement le début de chaque message. Placez l'instruction la plus importante dans la première phrase de votre message système et de votre message utilisateur.

Pour conclure

Claude Sonnet 4.6 récompense les prompts clairs et structurés et punit le bavardage. Les plus gros gains en 2026 ne viennent pas de templates de prompts élaborés, mais de l'inverse : réduire le prompt à un message système concis, des entrées balisées en XML, trois exemples bien choisis, et des contraintes formulées au positif. Si vous adoptez seulement ces quatre habitudes issues de ce guide, vos sorties s'amélioreront immédiatement et de façon fiable.

Le prompt engineering en tant que discipline devient moins une question de phrasé astucieux et plus une question d'architecture d'information propre. Les équipes qui obtiennent les meilleurs résultats avec Claude en 2026 sont celles qui traitent les prompts comme des contrats d'API — explicites, structurés, impitoyablement minimaux.