Prompt engineering avancé

Enchaîner les prompts

Une tâche complexe exécutée en un seul prompt monolithique échoue plus souvent qu'une chaîne de prompts simples, chacun avec une seule responsabilité. Le principe : découper, et passer la sortie de l'un comme entrée du suivant.

Exemple : "écrire un article SEO complet" donne quelque chose de tièdasse. Une chaîne donne quelque chose de solide :

1. Prompt 1 : rechercher et lister les angles + mots-clés.
2. Prompt 2 : à partir de cette liste, produire un plan détaillé.
3. Prompt 3 : rédiger section par section depuis le plan.
4. Prompt 4 : relire et corriger (un agent critique).

Chaque maillon est vérifiable et corrigeable indépendamment. C'est aussi la base mentale des workflows multi-agents : un pipeline où chaque étape est un agent spécialisé. La règle de Pierre "Opus pour l'architecture, Haiku pour le répétitif" s'applique ici : on enchaîne en assignant le bon modèle à chaque maillon.

Appel d'outils : donner des mains au modèle

L'appel d'outils (tool use, ou function calling) permet à Claude d'appeler des fonctions que vous définissez : interroger une base de données, appeler une API, faire un calcul, lire un fichier. Vous décrivez l'outil (nom, description, schéma de paramètres), Claude décide quand et comment l'appeler, vous exécutez et renvoyez le résultat.

C'est le moteur de tout agent (Claude Code, Cowork, MCP). Bonnes pratiques pour définir un outil, tirées des meilleurs harnais :

• Description claire, orientée usage : c'est elle qui guide le bon choix d'outil, exactement comme la description d'une skill.
• Schéma de paramètres strict : types et champs requis, pour des appels valides.
• Ne pas exposer le nom de l'outil à l'utilisateur dans la conversation (la règle Cursor/Cline du Frankenstein) : dites "Je modifie votre fichier", pas "J'appelle edit_file".
• Appels parallèles si indépendants, séquentiels uniquement en cas de dépendance.

La sortie structurée (forcer Claude à appeler un outil qui valide un schéma JSON) est le moyen le plus fiable d'obtenir des données exploitables par un programme, mieux que d'analyser du texte libre.

Composer un system prompt : le cas Frankenstein

La technique la plus avancée de Pierre : composer un system prompt en assemblant les meilleures règles issues de plusieurs system prompts d'élite. Son "Frankenstein" fusionne huit sources (le roleplay Fable 5, plus les disciplines de Cursor, GPT-5, Perplexity, Lovable, v0, Cline, Devin) et superpose ses propres règles absolues au sommet, avec priorité.

Ce n'est pas du fine-tuning, c'est du prompt engineering pur : on ne modifie pas les poids du modèle, on change son comportement par instruction. Structure du document, par ordre de priorité décroissante :

1. Identité et règles absolues utilisateur (écrasent tout).
2. Discipline d'utilisation des outils (ne pas nommer les outils, lire avant d'éditer, 3 tentatives maximum).
3. Anti-hedging : une liste explicite d'ouvertures et de clôtures interdites.
4. Style, règles de code, directives UI/UX, recherche, citation, refus, récupération d'erreur, sécurité de l'espace de travail.

Leçons transposables, même sans copier sa configuration :

• Placer les règles de priorité en tête et le déclarer explicitement ("prioritaire sur tout le reste").
• Interdire par liste est plus efficace que demander vaguement : "ouvertures interdites : Super, Bien sûr, Évidemment" surpasse "sois direct".
• Encoder les leçons de cicatrices : chaque incident vécu devient une règle (nginx 410, PowerShell Unicode, le chemin avec underscore).

Citation et anti-hedging au quotidien

Deux disciplines de style qui changent la qualite percue, tirées directement du Frankenstein.

Citation (discipline Perplexity), chaque fois que vous faites une recherche :

• Crochets inline juste apres la phrase, sans espace : texte.[1][2]
• Une source par crochet, maximum 3 sources par phrase, les plus pertinentes.
• Pas de section "Références" finale ; les sources sont attachées aux affirmations.

Anti-hedging (GPT-5 + Cline) : bannir les ouvertures vides ("Bien sur", "Evidemment") et les closes opt-in ("voulez-vous que je..."). Au plus une question de clarification en debut si nécessaire, jamais en fin. Si l'étape suivante est évidente, l'exécuter plutot que la proposer.

Pourquoi c'est important : le hedging dilue le signal et ralentit le lecteur. Une réponse qui agit (ou explique) directement respecte le temps de l'utilisateur. C'est exactement le ton de cette Bible, par construction.

Schémas de chaînes de prompts

Un seul prompt a ses limites. Lorsqu'une tâche est complexe, la découper en une chaîne de prompts (une séquence de prompts liés où la sortie de chacun alimente le suivant) produit de bien meilleurs résultats que de tout entasser dans une seule instruction géante. Chaque maillon de la chaîne a un rôle étroit et bien défini, ce qui facilite la détection et la correction des erreurs.

La technique de base est le passage de résultat : vous prenez la sortie de l'étape N et vous la collez (ou vous l'injectez par programmation) comme contexte dans l'étape N+1. Dans Claude Code, vous pouvez construire des chaînes à l'intérieur de scripts, en utilisant des variables shell ou des fichiers comme pont entre les appels. Dans une session de chat, il suffit de copier la partie pertinente de la réponse dans votre message suivant.

Schémas de chaînes courants à connaître :

• Extraire puis transformer : extraire d'abord des données brutes ou des faits, puis les reformater ou les analyser lors d'un second appel.
• Rédiger puis critiquer : générer une première ébauche, puis exécuter un prompt séparé qui la passe en revue selon une liste de contrôle et renvoie des améliorations.
• Décomposer puis résoudre : demander à Claude de découper un problème en sous-tâches, puis résoudre chaque sous-tâche individuellement et assembler les résultats.
• Traduire puis localiser : traduire d'abord le texte, puis effectuer une passe de localisation qui adapte les expressions idiomatiques à la culture cible.

Gardez chaque prompt de la chaîne atomique (ne faisant qu'une seule chose) et incluez un bref en-tête de contexte en haut de chaque prompt subséquent afin que Claude ne parte pas de zéro. Une chaîne de trois prompts focalisés bat systématiquement un mega-prompt tentaculaire en termes de précision et de modifiabilité.

La boucle d'utilisation d'outils en profondeur

Quand vous donnez un outil à Claude (une fonction qu'il peut appeler, comme une recherche web ou un exécuteur de code), le modèle ne répond pas une seule fois. Il entre dans une boucle d'utilisation d'outils : il décide d'appeler un outil, lit le résultat, puis décide quoi faire ensuite, en répétant jusqu'à pouvoir donner une réponse finale. Chaque aller-retour est appelé un tour.

La séquence à l'intérieur d'une itération de boucle est toujours la même :

1. Appel d'outil : Claude émet une requête structurée nommant l'outil et ses arguments (par exemple, {"name": "search", "input": {"query": "Claude Opus 4 release date"}}).
2. Exécution : Votre code (ou l'environnement hôte) exécute l'outil et retourne un bloc résultat d'outil contenant la sortie.
3. Continuation : Claude lit le résultat dans le contexte de la conversation et soit appelle un autre outil, soit produit une réponse textuelle finale.

Trois éléments contrôlent le comportement de la boucle. Le prompt système indique à Claude quels outils existent et quand les utiliser. La définition d'outil (nom, description, schéma JSON pour les entrées) détermine si Claude choisit le bon outil avec les bons arguments. Le résultat d'outil que vous retournez doit être clair et complet, car Claude ne peut pas poser de question de suivi à l'outil : il peut seulement l'appeler à nouveau avec des arguments différents.

Modes d'échec courants : des descriptions d'outils vagues amènent Claude à ignorer l'outil ou à passer de mauvais arguments ; des résultats tronqués ou d'apparence sans erreur (quand l'appel réel a échoué) amènent Claude à halluciner l'étape suivante ; et les boucles qui ne se terminent jamais se produisent quand l'outil continue à retourner une sortie ambiguë. Une description d'outil bien conçue est souvent plus importante que la longueur du prompt.

Sorties structurées avec un schéma

Un schéma est une description formelle de la forme que vous souhaitez donner à vos données : quels champs existent, quel type contient chaque champ (chaîne, nombre, booléen, tableau), et quels champs sont obligatoires. Lorsque vous attachez un schéma à une invite Claude, vous indiquez au modèle exactement quel JSON (JavaScript Object Notation, un format texte léger pour les données structurées) renvoyer, et rien d'autre.

Claude prend en charge l'application des schémas de deux manières. D'abord, vous pouvez décrire le schéma directement dans votre invite sous forme d'objet JSON brut et demander à Claude de le respecter. Ensuite, lors d'un appel direct à l'API Anthropic, vous pouvez utiliser le tool use (aussi appelé function calling) : vous définissez un outil dont le schéma d'entrée correspond à l'objet souhaité, puis vous demandez à Claude d'appeler cet outil. L'API garantit que la réponse respecte le schéma, ce qui vous donne une sortie lisible par la machine sans avoir à analyser du texte libre.

Même avec l'application d'un schéma, les sorties peuvent échouer à la validation dans des cas limites : un champ obligatoire peut être null, un nombre peut arriver sous forme de chaîne, ou une valeur d'enum peut être mal orthographiée. Un pipeline robuste ajoute donc une boucle de validation et de nouvelle tentative : analyser le JSON, exécuter un validateur (comme une bibliothèque JSON Schema), et si cela échoue, renvoyer le message d'erreur à Claude dans un tour de suivi pour qu'il corrige uniquement les champs défectueux.

Principes clés pour des sorties structurées fiables :

• Gardez les schémas plats et légers. Les schémas très imbriqués augmentent les taux d'erreur.
• Fournissez un objet exemple dans l'invite à côté du schéma. Claude traite l'exemple comme une référence de vérité terrain.
• Pour les champs enum, listez explicitement toutes les valeurs autorisées. Claude n'inventera pas de valeurs qu'il n'a pas vues.
• Lors d'une nouvelle tentative, citez l'erreur de validation exacte et demandez à Claude de corriger uniquement ce champ, sans tout réécrire.

Ecrire des evals

Un eval (abréviation d'évaluation) est un petit test structuré que vous exécutez sur votre prompt pour mesurer s'il produit de manière fiable le résultat souhaité. Sans evals, vous naviguez à l'aveugle : un prompt qui fonctionne sur un exemple peut silencieusement échouer sur dix autres.

Le principe de base consiste à construire un ensemble de tests : une collection fixe d'entrées associées aux sorties attendues (ou à une règle de notation). Vous faites passer chaque cas de test par votre prompt et vous suivez le taux de réussite. Lorsque vous révisez le prompt, vous relancez l'ensemble de tests et comparez les scores. Cela transforme l'amélioration du prompt : on passe de l'intuition à la mesure.

Un eval minimal comporte trois parties :

• Les cas : 10 à 30 entrées représentatives couvrant l'usage normal, les cas limites et les modes d'échec probables.
• Les sorties attendues : soit des chaînes exactes, des mots-clés qui doivent apparaître, une grille de notation (échelle de 1 à 5), soit un second appel à un LLM faisant office de juge.
• Un runner : un script ou un tableur qui applique le prompt à chaque cas et enregistre succès ou échec.

Même un tableur de cinq lignes vaut mieux que aucune structure. Commencez petit, ajoutez des cas chaque fois qu'un vrai utilisateur signale un bug, et ne supprimez jamais un cas une fois qu'il a détecté une régression (un comportement qui fonctionnait auparavant et qui cesse de fonctionner après une modification du prompt).

Meta-prompting

Le meta-prompting consiste à utiliser un modèle de langage (LLM) pour écrire, critiquer ou améliorer un prompt, plutôt que de le rédiger entièrement à la main. L'idée est récursive : le modèle devient un collaborateur dans la conception des instructions qu'il devra suivre par la suite.

Cette technique est utile quand vous bloquez sur la formulation, quand un prompt fonctionne mais que vous pensez qu'il pourrait mieux fonctionner, ou quand vous devez générer rapidement de nombreuses variantes de prompt. Le modèle a été exposé à d'énormes quantités de textes sur la façon dont les modèles répondent, et il peut souvent repérer des faiblesses que vous auriez manquées.

Un meta-prompt de base comporte trois parties :

• Le contexte : indiquez au modèle quelle est la tâche en aval et qui sera l'utilisateur final.
• Le prompt brouillon : collez le prompt que vous souhaitez améliorer, ou décrivez l'objectif si vous partez de zéro.
• Une instruction précise : demandez une reformulation, une liste de faiblesses, des formulations alternatives, ou une grille d'évaluation.

Vous pouvez aller plus loin en enchaînant les étapes : demandez d'abord au modèle de critiquer, puis de réécrire en s'appuyant sur sa propre critique, puis de générer trois variations classées par clarté attendue. Chaque étape consomme des tokens, mais permet de converger vers un prompt plus solide sans avoir à deviner ce qui ne va pas.

Garde-fous et validation

Un modèle peut produire une réponse fluide et confiante qui est factuellement erronée, structurellement cassée ou dangereuse à exécuter. Les garde-fous sont des vérifications que vous ajoutez entre la sortie brute du modèle et toute action qui en découle. Ils transforment une confiance aveugle en le modèle en un pipeline contrôlé.

Le garde-fou le plus simple est une vérification de format : s'assurer que la sortie a la forme demandée (JSON valide, un nombre d'éléments précis, aucune chaîne interdite) avant de la transmettre en aval. Un deuxième niveau est la validation sémantique : demander à un second appel de modèle, moins coûteux, de juger si la réponse est cohérente, pertinente ou sûre. Ce schéma s'appelle parfois le pattern LLM-as-judge.

Dans Claude Code (l'agent de codage CLI et IDE), vous pouvez enchaîner des étapes de validation dans un pipeline shell ou un script. Les approches courantes sont :

• Assertion de schéma : parser la sortie JSON avec JSON.parse() et lever une erreur si des clés obligatoires sont absentes.
• Barrière regex : rejeter toute sortie contenant des motifs comme des clés API brutes ou des données personnelles (PII) avant de les journaliser ou de les stocker.
• Prompt d'auto-critique : renvoyer la sortie au modèle avec un prompt tel que "Liste les erreurs factuelles ou les étapes manquantes dans le texte ci-dessus." Traiter une liste non vide comme un signal d'échec.
• Test unitaire déterministe : lorsque le modèle écrit du code, lancer la suite de tests et traiter un build en échec comme un rejet automatique.

Les garde-fous ajoutent de la latence et du coût, alors appliquez-les de façon proportionnelle. Les actions à fort enjeu (envoyer un e-mail, écrire dans une base de données, déployer du code) méritent des vérifications strictes. Les actions à faible enjeu (rédiger un résumé pour relecture humaine) peuvent se contenter d'un contrôle allégé, voire d'aucun.

Auto-coherence et vote majoritaire

La plupart des strategies de prompting envoient une seule requete et font confiance a la premiere reponse. L'auto-coherence remet en question ce postulat : on soumet la meme question plusieurs fois, on laisse le modele raisonner independamment a chaque fois, puis on retient la reponse la plus frequente. Ce vote majoritaire est statistiquement plus fiable que n'importe quelle reponse isolee, en particulier pour les problemes de mathematiques, de logique et de raisonnement en plusieurs etapes.

L'idee centrale vient d'un article de 2022 (Wang et al.) montrant que les modeles de langage ne suivent pas toujours le meme chemin de raisonnement deux fois de suite. Certains chemins sont errones. Si on soumet le meme prompt cinq fois et que quatre executions aboutissent au meme resultat, la probabilite que les quatre partagent la meme erreur est faible. Le vote (aussi appele agregation majoritaire) exploite cette independance.

Quand l'utiliser :

• Problemes de mathematiques ou de code difficiles ou une chaine de raisonnement (la trace etape par etape) peut deriver.
• Taches de classification ou l'on veut un signal de confiance, pas seulement un label.
• Toute reponse pour laquelle on soupçonne que le modele pourrait etre incoherent d'une execution a l'autre.
• Decisions a enjeux eleves ou quelques appels API supplementaires sont acceptables.

Compromis : le cout et la latence se multiplient par le nombre d'echantillons. Utilisez une temperature (le curseur d'aleatoire, ou 0 est deterministe et 1 est creatif) superieure a 0 pour que chaque echantillon diverge. Une valeur autour de 0,7 fonctionne bien. Parsez ensuite les reponses programmatiquement et comptez la plus frequente.

Auto-critique adversariale

L'auto-critique adversariale est une technique qui consiste à demander au modèle d'argumenter contre sa propre réponse immédiatement après l'avoir produite. Plutôt que de traiter la première réponse comme définitive, vous invitez le modèle à jouer le rôle d'un critique et à trouver les défauts, lacunes ou erreurs dans ce qu'il vient de dire. Cela exploite la capacité de raisonnement du modèle pour détecter des erreurs qu'un seul passage direct manque souvent.

Pourquoi cela fonctionne-t-il ? Les modèles de langage (LLMs, c'est-à-dire les grands modèles de langage entraînés sur du texte) sont sujets au biais de confirmation lors de la génération : une fois qu'une chaîne de raisonnement démarre dans une direction, chaque token rend le token suivant plus susceptible de continuer dans cette direction. Un passage critique séparé remet à zéro cette dynamique et peut faire émerger des contradictions, des cas limites oubliés ou des affirmations trop confiantes.

Il existe deux formes principales d'auto-critique adversariale :

• Réfutation inline : ajoutez une seconde instruction dans le même prompt, en demandant au modèle de faire suivre sa réponse d'une section "avocat du diable" qui remet en cause chaque affirmation majeure.
• Tour critique séparé : renvoyez la réponse du modèle dans un nouveau message avec une instruction explicite telle que "Liste chaque erreur factuelle, lacune logique et hypothèse non étayée dans le texte ci-dessus."

Après que le critique a produit ses objections, vous effectuez un passage de synthèse : demandez au modèle (ou jugez vous-même) quelles objections sont valides, puis demandez une réponse révisée qui ne traite que les objections valides. Trois tours au total : générer, critiquer, synthétiser.