Rappel des techniques essentielles

Cette leçon rappelle les six techniques de prompting que le reste du cours combine dans des prompts de production, chacune avec un mauvais et un bon exemple tirés du cours officiel, puis dit ce qui a changé depuis sa rédaction : les modèles actuels raisonnent nativement, les sorties structurées remplacent le JSON demandé « à la main », et la documentation de référence n’est plus le tutoriel mais la page « Prompting best practices ».

Mise à jour du 5 novembre 2026. Ce cours adapte les cinq carnets Jupyter « Real world prompting » du dépôt anthropics/courses, écrits en 2024 pour Claude 3 (le dépôt privilégiait Claude 3 Haiku pour limiter les coûts) ; le dépôt est archivé en lecture seule depuis le 15 septembre 2026, dernier changement le 13 novembre 2025. Les techniques restent valables, mais le code et les repères ont été relus contre la documentation actuelle, qui couvre la famille Claude 5.5 et Fable 5.1 : les exemples de code utilisent claude-opus-5-5, la réflexion adaptative et les sorties structurées.

Ce que ce cours suppose

Le cours officiel s’adresse à des développeurs qui ont déjà pratiqué l’ingénierie de prompt, idéalement en ayant suivi le tutoriel interactif (Prompt Engineering dans notre catalogue). Il ne reprend pas les bases : il les renforce en montrant leur importance dans des environnements de production à fort enjeu et à grande échelle. Tant que vous itérez à la main, une formulation approximative se corrige en relançant la requête ; dès que le même prompt est appelé des milliers de fois par jour, cette approximation produit des sorties inutilisables que personne ne relit. Tout ce qui suit découle de ce changement d’échelle.

Sortir de la page blanche

Le cours de 2024 commençait par le générateur de prompts de la Console : on décrit sa tâche en langage naturel et Claude rédige un prompt de bonne facture. La documentation actuelle renvoie pour cela au carnet « metaprompt » du Claude Cookbook, qui fait la même chose depuis un notebook. L’exemple du cours reste parlant : pour « déterminer si un article est une fausse nouvelle », le prompt généré définit la tâche sans ambiguïté, place l’article dans une balise <article>, liste les signaux à examiner (langage sensationnaliste, absence de sources, biais extrême, affirmations invraisemblables, erreurs factuelles), demande le raisonnement dans une section <reasoning> et la décision FAKE ou REAL dans une section <answer>. Trois techniques y sont déjà à l’œuvre : définition claire de la tâche, structure de sortie, balises XML. Mais un prompt généré est un point de départ à itérer, jamais une solution livrable : il ignore vos cas limites, votre vocabulaire métier et le format qu’attend le service en aval. Avant même d’ouvrir le générateur, formulez vos exigences exactes.

Six techniques, et quand les employer

Être clair et direct. La technique la plus importante est la plus simple : des consignes explicites et détaillées qui ne laissent aucune place à l’ambiguïté, en précisant format, longueur et style, sans supposer que Claude connaît votre contexte. La documentation propose un test : montrez votre prompt à un collègue qui ignore tout de la tâche ; s’il serait perdu, Claude le sera aussi. Le cours oppose « voici des retours clients, que pensent les gens ? » à un prompt qui décrit l’entrée (retours sur une version logicielle dans <feedback>), impose cinq sections (résumé de 50 à 100 mots, trois fonctionnalités les plus louées et les plus critiquées, trois problèmes d’usage avec un correctif suggéré, répartition du sentiment en pourcentages, trois à cinq enseignements) et demande des balises de sortie pour l’analyse automatique. À utiliser toujours, surtout pour les tâches complexes, les sorties très précises et les processus à plusieurs étapes.

Structurer avec des balises XML. Les prompts complexes mélangent consignes et données injectées dans une seule chaîne ; le modèle peut alors lire une donnée comme une consigne ou manquer un point clé. Les balises séparent les deux. L’exemple du cours est un rapport de défauts de la montre SmartTime 3000 : en vrac, données de défauts, stocks et prix se confondent ; balisé (<defect_report>, <inventory>, <financials>), chaque information est identifiée, et les sections de sortie demandées (<defect_analysis>, <financial_impact>, <action_plan>) sont faciles à relire et à exploiter. Les balises XML ne sont pas obligatoires, n’importe quelle syntaxe de séparation convient, mais elles sont courtes, parlantes, et c’est l’approche la plus « Claude ».

Fournir des exemples. Montrer vaut souvent mieux que décrire : un ou deux exemples de sortie transmettent le ton, la structure et le jargon qu’une description n’épuise jamais. Le cours compare une demande de courriel d’annonce produit sans exemple à la même demande avec deux courriels modèles dans <examples> (objet accrocheur, fonctionnalités chiffrées, bénéfices, prix, appel à l’action) : la sortie est prête à l’emploi. Trois règles : des exemples pertinents, proches de vos vraies entrées et sorties ; diversifiés, couvrant les cas limites ; en quantité, trois à cinq pour commencer, sachant qu’un seul vaut mieux qu’aucun. Les exemples allongent le prompt, mais ils valent presque toujours leur place dans un prompt de production.

Laisser Claude réfléchir. Sur les tâches à fort enjeu, le chemin compte autant que la décision : décomposer le problème améliore la précision, laisse les développeurs relire le raisonnement, réduit le risque en finance, droit ou santé, et fournit une trace pour les audits. L’exemple du cours est AcmeFlow, éditeur américain qui envisage de s’étendre en Asie : au lieu de « est-ce une bonne idée ? », le prompt fournit données de l’entreprise et études de marché balisées, demande d’examiner marché, concurrence, réglementation et projections, le raisonnement dans <thinking> et la recommandation dans <recommendation>. En 2024, c’était le seul moyen d’obtenir un raisonnement ; aujourd’hui, les modèles raisonnent nativement, voir plus bas.

Donner un rôle. Le rôle, placé dans le prompt système, fixe la perspective, le registre et le niveau d’expertise ; le cours recommande d’y mettre le rôle, et d’y mettre surtout cela. Exemple : AcmeEV découvre un bogue d’accélération involontaire ; « écris un communiqué, fais en sorte que ça sonne bien » ne dit rien du ton ni du public. Le bon prompt fait de Claude le directeur de la communication, vingt ans de gestion de crise, empathique et ferme, puis fournit les faits (70 % des voitures du trimestre, correctif sous deux semaines), les sept règles de communication de crise, les étapes à suivre, et demande l’analyse dans <analysis> et le communiqué dans <statement>. La documentation actuelle confirme : une seule phrase de rôle fait déjà une différence.

Les prompts à long contexte. Quand vous combinez beaucoup de données avec vos consignes, balisez chaque document et placez les documents en haut, consignes et exemples ensuite : la documentation actuelle parle de 20 000 jetons et plus, et d’une qualité de réponse qui peut gagner jusqu’à 30 % dans ses tests quand la question vient en fin de prompt, surtout avec plusieurs documents. Elle conseille aussi de demander à Claude de citer d’abord les passages pertinents avant d’exécuter la tâche. L’exemple du cours, une analyse de lancement pour le CRM AcmeAI, imbrique trois rapports dans <reports> puis demande cinq sections balisées.

Ce qui a changé depuis 2024

Les techniques tiennent ; leur mise en œuvre a bougé sur trois points que les leçons suivantes appliquent. La réflexion d’abord : les modèles actuels utilisent la réflexion adaptative (thinking: {"type": "adaptive"}), et sur Claude Opus 5.5, Fable 5 et Fable 5.1 elle est toujours active, réglée par le paramètre effort. La documentation prévient qu’un prompt demandant au modèle d’écrire son raisonnement, par exemple dans des balises <thinking>, peut être décliné sur ces modèles : laissez-le raisonner dans ses blocs de réflexion et ne balisez que la réponse finale. Les sorties structurées ensuite : pour obtenir du JSON fiable, la bonne pratique n’est plus de décrire un schéma dans le prompt mais de le passer au paramètre output_config.format, ou d’utiliser client.messages.parse() avec un modèle Pydantic. Le préremplissage enfin : commencer la réponse de l’assistant pour forcer un format renvoie une erreur 400 depuis les modèles 4.6 ; on contrôle le format par les consignes et les sorties structurées.

À vous de jouer

Auditer un de vos prompts. Prenez un prompt que vous utilisez vraiment et passez-le au crible des six techniques : la tâche est-elle définie sans ambiguïté, avec format, longueur et style ? Les données sont-elles séparées des consignes ? Y a-t-il au moins un exemple, et couvre-t-il un cas limite ? La tâche justifie-t-elle un raisonnement visible, ou un simple niveau d’effort ? Le rôle est-il dans le prompt système ? Les documents longs sont-ils en tête ? Puis appliquez le test du collègue.

Générer un point de départ. Ouvrez le carnet « metaprompt » du Claude Cookbook, décrivez une tâche de votre contexte en deux phrases, et comparez le prompt généré à ce que vous auriez écrit : quelles techniques applique-t-il d’office ? Que manque-t-il de votre métier ?

Sources officielles : 01_prompting_recap.ipynb (anthropics/courses, archivé) · Prompting best practices (documentation Claude, novembre 2026) · Prompt engineering overview · Carnet metaprompt (Claude Cookbook)

Points clés à retenir

• Un prompt généré est un point de départ à itérer : formulez vos exigences avant de le demander.
• Être clair et direct reste la technique la plus importante : le test du collègue ne ment pas.
• Les balises XML séparent consignes, données et exemples ; les sorties balisées s’extraient par programme.
• Trois à cinq exemples pertinents et diversifiés valent mieux qu’une longue description.
• En 2026 : réflexion adaptative plutôt que balises de raisonnement, sorties structurées plutôt que JSON décrit, plus de préremplissage.

Crédits et licence — Adaptation française du cours « Real world prompting » du dépôt anthropics/courses (Anthropic), archivé en lecture seule le 15 septembre 2026 et publié sous licence CC BY-NC 4.0 ; cette adaptation, qui le traduit, le remanie et met son code à jour pour les modèles de novembre 2026, est diffusée sous la même licence.