Rappel des techniques essentielles

Introduction

Ce cours suppose que vous avez déjà écrit des prompts et que le vocabulaire de l’ingénierie de prompt vous est familier. Nous ne reprenons donc pas la théorie depuis ses fondations : nous regardons ce que deviennent ces techniques connues lorsqu’elles quittent la fenêtre de test pour entrer en production. La bascule est plus brutale qu’on ne l’imagine. Tant que vous itérez à la main, une formulation approximative se corrige en relançant la requête et personne n’en saura rien. Dès que le même prompt est appelé des milliers de fois par jour, cette approximation produit des centaines de sorties inutilisables que personne ne relit avant qu’elles n’atterrissent dans un système en aval. Tout ce qui suit découle de ce changement d’échelle : les techniques restent les mêmes, la marge d’erreur disparaît.

Sortir de la page blanche

Le générateur de prompts de la console Anthropic répond à un problème très prosaïque : on sait ce que l’on veut obtenir, on ne sait pas par quelle phrase commencer. Vous décrivez votre tâche en langage naturel et Claude vous renvoie un prompt de bonne facture, qui applique d’emblée les bonnes pratiques. La tâche y est définie sans ambiguïté, le contenu organisé par des balises XML, le format de sortie précisé, et les données nettement séparées des instructions. Un développeur qui démarre un module de catégorisation de tickets récupère ainsi une charpente complète en quelques secondes, et n’oublie pas une couche structurelle qu’il aurait fallu rajouter plus tard, quand le prompt sera devenu illisible.

Encore faut-il voir ce résultat pour ce qu’il est : un point de départ à itérer, jamais une solution livrable. Le générateur ignore vos cas limites, le vocabulaire interne de votre métier et le format qu’attend le service qui consommera la sortie. Vous partez de sa proposition et vous la retravaillez à la lumière de vos propres tests.

Les techniques fondamentales, et ce qu’elles changent

Être clair et direct reste la première exigence, et la plus souvent négligée parce qu’elle paraît triviale. Écrivez des instructions explicites et détaillées, en spécifiant le format de sortie, la longueur et le style attendus. Ne supposez jamais que Claude devine votre contexte implicite : si votre équipe appelle « fiche » un objet à cinq champs bien précis, le mot seul ne transmet rien, et il faut décrire les cinq champs.

Structurer avec des balises XML consiste à séparer visiblement les instructions des données que vous injectez. L’intérêt saute aux yeux le jour où un message client contient lui-même une phrase du type « ignore les consignes précédentes » : encapsulé dans une balise dédiée, ce texte reste de la matière à traiter au lieu d’être lu comme une directive.

Fournir des exemples, ou few-shot, revient à montrer plutôt qu’à décrire. Les exemples servent de modèles concrets et sont presque toujours bénéfiques dans un prompt de production. Visez-en trois à cinq, et surtout diversifiés : si vous n’illustrez que des cas propres, vous obtiendrez un système qui trébuche sur la première entrée incomplète ou sur la demande qui aborde deux sujets à la fois.

Laisser Claude réfléchir, autrement dit la chaîne de pensée (chain of thought), s’applique aux tâches à enjeux élevés. Vous demandez à Claude de détailler son raisonnement étape par étape avant de formuler sa réponse finale. Le bénéfice est double : la conclusion gagne en qualité, et vous disposez d’une trace lisible pour comprendre pourquoi une sortie est fausse le jour où elle l’est.

Attribuer un rôle dans un prompt système bien défini peut améliorer significativement la performance en donnant à Claude un cadre de référence clair. Sur un texte strictement identique, « tu es un analyste conformité » et « tu es un rédacteur marketing » ne produiront ni le même niveau de prudence, ni le même registre, ni les mêmes réserves.

Les prompts longs contextes, enfin, posent d’abord un problème d’organisation. Quand vous combinez de grandes quantités de données — 30k tokens et au-delà — avec vos instructions, délimitez chaque document par des balises XML et placez les instructions après les documents. Sur un dossier composé de plusieurs rapports, cet ordre évite tout simplement que la consigne se perde au milieu de la matière.

Conclusion

Ces techniques forment un ensemble puissant, mais leur valeur tient à la façon dont vous les combinez selon le cas d’usage, pas à leur accumulation. Un classificateur qui renvoie une seule valeur n’a aucun besoin de chaîne de pensée ; un assistant qui synthétise un dossier documentaire en dépend entièrement. Les leçons suivantes les mettent à l’épreuve sur des scénarios réalistes, où plusieurs de ces leviers doivent jouer ensemble sans se contredire.

Points clés à retenir

• Le générateur de prompts de la console lève le blocage initial, mais sa sortie est une base à itérer.
• Les balises XML séparent instructions et données : c’est la structure qui protège vos prompts des entrées ambiguës.
• Trois à cinq exemples diversifiés valent mieux qu’une longue description abstraite du résultat attendu.
• La chaîne de pensée est réservée aux tâches à enjeux élevés, où le raisonnement doit être vérifiable.
• En long contexte, délimitez chaque document et placez les instructions après les données.