La plupart des conseils de prompting sont évidents. Soyez précis. Donnez des exemples. Ajoutez du contexte.

Ça vous amène peut-être à 60 % d’un output utile, et les 40 % restants sont là où ça devient intéressant — parce que c’est là que les modèles de langage commencent à échouer de façon prévisible, et qu’il faut une autre manière de réfléchir.

Les techniques ci-dessous ne sont pas secrètes. Elles sont bien documentées dans des papers et discutées en boucle sur Hacker News et Reddit. Mais savoir quand les appliquer — et surtout quand ne pas les appliquer — sépare ceux qui obtiennent régulièrement de bons résultats de ceux qui accusent le modèle dès que ça dérape.

Pourquoi les modèles de langage échouent de manière prévisible

Le problème de base est simple. Les LLM génèrent du texte de gauche à droite, un token à la fois. Chaque token contraint ce qui suit. Une fois que le modèle s’engage sur une trajectoire de raisonnement, il fait rarement marche arrière.

Ça marche très bien pour les questions simples. Ça échoue dès qu’il faut explorer.

Un commentateur Hacker News, cube2222, a illustré le problème des erreurs qui s’additionnent : “if each step has a 97 % chance of being completed correctly, if your task requires 10 steps one after the other, the chance of success falls to 97 %*10=74 %.” Dix étapes avec 3 % d’erreur par étape vous font tomber à 74 % de réussite. Vingt étapes ? Environ 54 %.

Les patterns qui suivent attaquent tous cette limitation fondamentale. Ils ajoutent de l’exploration là où il n’y avait que de l’engagement. De la vérification là où il n’y avait que de la génération. Du branching là où il n’y avait que de la linéarité.

Self-Consistency : demander plusieurs fois, faire confiance à la majorité

La technique avancée la plus simple. Vous exécutez le même prompt plusieurs fois avec une température plus élevée. Vous récupérez la réponse finale de chaque run. Vous prenez celle qui apparaît le plus souvent.

Ça marche parce que les modèles sont probabilistes. La même question produit des chemins de raisonnement différents à chaque exécution. Parfois, ces chemins contiennent des erreurs qui se propagent. Mais les runs différents font des erreurs différentes. Quand vous agrégerez, le raisonnement correct se renforce pendant que les erreurs s’annulent.

Les maths sont simples. Si votre modèle donne la bonne réponse 60 % du temps en une seule exécution, cinq runs indépendants avec un vote majoritaire poussent l’exactitude vers 80 %. La technique a été proposée par Wang et al. et a montré des gains importants sur le raisonnement arithmétique et le bon sens.

La self-consistency brille quand il existe une seule bonne réponse vérifiable. Énigmes logiques. Questions factuelles. Tout ce que vous pouvez contrôler. Elle marche moins bien sur les tâches créatives (pas de “bonne” réponse) ou quand le modèle fait la même erreur systématique quelle que soit la trajectoire.

Le coût est évident. Vous payez 5 à 10 fois plus de tokens. Pour un système de production avec des millions de requêtes, l’économie ne tient pas. Pour des requêtes individuelles à fort enjeu où l’exactitude compte plus que le coût, ça délivre.

Tree of Thought : quand le raisonnement linéaire ne suffit plus

Le chain-of-thought, ou vous demandez au modèle de “montrer son travail”, aide sur beaucoup de problèmes. Mais une fois que le modèle a démarré un chemin, il s’y engage.

Le Tree of Thought change ça. Au lieu de générer une seule trajectoire, vous générez plusieurs étapes suivantes possibles à chaque point de décision. Vous les évaluez. Vous ne poursuivez que les branches prometteuses. Vous pouvez revenir en arrière quand une piste ne mène nulle part.

Sur certains problèmes, les gains sont spectaculaires. Sur le puzzle “Game of 24”, ou vous utilisez quatre nombres et des opérations de base pour atteindre exactement 24, des chercheurs de Princeton ont trouvé que GPT-4 avec un chain-of-thought standard ne résolvait que 4 % des problèmes. Avec Tree of Thought ? 74 %.

Ce n’est pas une amélioration marginale. C’est la différence entre inutile et utile.

Mais la technique a des coûts réels, au-delà des tokens. Sur Hacker News, l’utilisateur startupsfail a pointé des contraintes très concrètes : “it is: costly, slow, there is node collapse, it impacts context length, it injects biases.” Le surcoût des générations multiples par étape, l’évaluation de chaque branche, et le suivi de toute la structure en arbre s’additionnent vite.

Le Tree of Thought mérite son coût pour des problèmes de planification, des puzzles avec plusieurs approches valides, et des tâches créatives où la première idée est rarement la meilleure. Pour des questions factuelles simples, c’est excessif et ça brûle des tokens sans améliorer les résultats.

Prompt chaining : découper un travail complexe en étapes

Certaines tâches sont trop complexes pour un seul prompt. Pas parce que le modèle ne peut pas gérer la complexité, mais parce que le problème a vraiment des phases distinctes qui bénéficient d’approches différentes.

Le prompt chaining découpe le travail en étapes où la sortie d’un prompt devient l’entrée du suivant. Extraire des citations pertinentes d’un document dans le prompt 1. Utiliser uniquement ces citations pour répondre à une question dans le prompt 2. Le premier se concentre sur la recherche. Le second, sur le raisonnement.

Cette séparation fait plusieurs choses. Elle garde chaque prompt sur un seul job, ce que les modèles gèrent mieux que des instructions multi-parties. Elle vous permet d’inspecter les résultats intermédiaires, et de stopper les erreurs avant qu’elles se propagent. Et elle autorise des configurations différentes selon les étapes — températures différentes, voire modèles différents, chacun joué sur ses forces.

Un utilisateur Hacker News, coolKid721, a décrit ce workflow : “Breaking it down into parts and having multiple prompts with smaller context that all have structured output you feed into each other.”

La technique se casse quand les étapes ont des dépendances serrées qui ne se séparent pas proprement, ou quand un output intermédiaire perd du contexte dont vous avez besoin plus tard. Vous pouvez passer plus d’informations dans la chaîne, mais ça augmente les tokens et crée de nouveaux points de défaillance.

Commencez avec deux étapes. Faites-les bien fonctionner. N’ajoutez des étapes que quand vous avez des preuves claires que la séparation aide.

Reflection : faire vérifier son travail au modèle

Si ChatGPT peut “penser”, il ne peut penser qu’à voix haute.

Tout ce que le modèle considère doit apparaître dans sa sortie. Il n’y a pas de délibération interne cachée. Les prompts de reflection exploitent ça en rendant la vérification explicite. Vous demandez au modèle de résoudre un problème, puis vous lui demandez de relire sa solution et d’identifier des erreurs.

Sur Hacker News, l’utilisateur nate partageait une observation courante : “I constantly ask chatGPT: ‘are you sure?’ to it’s replies, and it almost always corrects a mistake.” Simple. Et souvent efficace.

Pourquoi ça marche, alors que ce sont les mêmes poids, la même training, le même modèle ? Une partie de la réponse est l’allocation d’attention. Quand il génère une réponse, le modèle doit comprendre le problème, planifier une approche, et produire un output cohérent en même temps. Quand il relit, il n’a qu’un job : vérifier si ce qui existe est correct. C’est plus simple.

Mais la reflection a un piège. Le même thread HN contient un avertissement de dr_kiszonka : “it also corrects ‘mistakes’ if there aren’t any.” Quand vous demandez “are you sure?”, vous impliquez un doute, et les modèles sont entraînés à adresser les inquiétudes. Parfois, ça veut dire changer une réponse correcte en une réponse incorrecte juste pour sembler utile.

Des prompts de reflection plus sophistiqués réduisent ce problème. Au lieu d’un doute vague, essayez “review your solution step by step and verify each logical move” ou “identify any assumptions you made that might not hold.” Donnez des critères d’évaluation spécifiques plutôt qu’une invitation ouverte à tout remettre en question.

Le framework Réflexion formalise ça en boucle : tentative, évaluation, reflection sur ce qui a échoué, nouvelle tentative avec cette reflection comme contexte. Le modèle génère une courte explication de pourquoi il a probablement échoué, et cette explication devient une partie du contexte pour l’essai suivant.

Méta-prompting : utiliser l’IA pour écrire vos prompts

Pourquoi écrire vos prompts vous-même si le modèle peut les écrire ?

Le méta-prompting demande au modèle de générer ou d’améliorer des prompts pour une tâche donnée. Vous décrivez ce que vous voulez accomplir, et le modèle produit un prompt conçu pour y arriver. Puis vous pouvez lui demander de critiquer et d’affiner ce prompt avant même de l’utiliser.

La technique est née d’une observation : les modèles savent souvent ce qui fait un bon prompt même quand l’utilisateur ne le sait pas. Ils ont été entraînés sur d’innombrables exemples d’instructions efficaces. Leur demander d’appliquer cette connaissance à la conception de prompts rend cette expertise accessible.

Des chercheurs de Stanford ont publié un travail sur “Meta-Prompting: Enhancing Language Models with Task-Agnostic Scaffolding” qui formalise ces idées. La technique a des avantages en efficacité de tokens et permet de comparer de façon plus équitable différentes approches de résolution de problèmes.

Tout le monde n’est pas convaincu. Un commentateur Hacker News, lexandstuff, a été cash : “Role prompting is totally useless imo…Be clear with your requirements. Add examples, if necessary.” Le scepticisme n’est pas absurde. Le méta-prompting marche mieux quand vous n’êtes pas sûr de la structure du prompt, mais que votre objectif est clair. C’est moins utile quand votre problème, c’est surtout de comprendre ce que vous voulez, ou quand la connaissance du domaine compte plus que le format.

Là où le méta-prompting brille : générer des variations de prompts à tester, améliorer des prompts qui fonctionnent “presque” mais sont maladroits, apprendre quels éléments rendent un prompt efficace en examinant les suggestions du modèle.

Modèles de raisonnement : ces patterns, mais intégrés

Le modèle o1 d’OpenAI et des “reasoning models” similaires chez d’autres labos intègrent essentiellement ces patterns directement dans le modèle. Tree of Thought. Self-consistency. Reflection. Chain-of-thought qui fait réellement marche arrière.

Une discussion Hacker News a montré le compromis. L’utilisateur arthurcolle notait que “they aren’t letting you see the useful chain of thought reasoning that is crucial to train a good model.” OpenAI cache les traces de raisonnement, en ne montrant que des résumés. Vous avez les bénéfices sans comprendre comment le modèle est arrivé à la réponse.

Les reasoning models coûtent plus cher et tournent plus lentement que les modèles de base. Pour beaucoup de tâches, c’est trop. Les patterns de prompting de cet article vous permettent d’ajouter des capacités de raisonnement de façon sélective, uniquement là où ça compte, au niveau de coût adapté à chaque requête.

Savoir quoi utiliser, et quand

Ces techniques résolvent des problèmes différents. Les mélanger au hasard gaspille des tokens et du temps.

Self-consistency vous donne de la confiance quand vous pouvez vous permettre plusieurs runs. Utilisez-la pour les maths, la logique, les questions factuelles. Tout ce qui a une bonne réponse vérifiable profite du vote majoritaire.

Tree of Thought mérite son coût quand les problèmes ont plusieurs approches valides. Problèmes de planification. Tâches créatives où votre première idée n’est pas forcément la meilleure. Puzzles qui récompensent l’exploration.

Prompt chaining colle aux tâches avec des phases distinctes. Workflows complexes. Tâches qui mélangent récupération d’info et raisonnement. La bonne question : est-ce que vous découperiez ça en étapes si vous le faisiez à la main ?

Reflection ajoute de la vérification quand l’exactitude compte. Génération de code. Arguments logiques. Tout output que vous voudriez naturellement re-check. La technique est peu coûteuse : un prompt de plus, et elle attrape souvent de vraies erreurs.

Méta-prompting aide quand vous ne savez pas comment prompter un nouveau type de tâche, ou quand vous voulez générer rapidement des variations à tester.

La vraie compétence, c’est la combinaison. Un système de prod peut utiliser du prompt chaining pour découper, du tree of thought pour planifier, de la self-consistency pour la réponse finale, et de la reflection pour attraper des erreurs avant sortie. Chaque technique cible un mode d’échec différent.

Ce vers quoi tout ça pointe

Chaque technique contourne la même limitation : les modèles génèrent de manière linéaire et n’explorent pas naturellement, ne vérifient pas, et ne reviennent pas en arrière.

La self-consistency ajoute de l’exploration via des runs multiples. Le Tree of Thought ajoute du branching et de l’élagage. La reflection ajoute de la vérification. Le prompt chaining ajoute de la décomposition.

Comprendre quand appliquer quoi, ce n’est pas collectionner des trivia. C’est apprendre à architecturer des systèmes qui “pensent” de manière différente selon ce que le problème exige. Un commentateur Hacker News, idopmstuff, a bien recadré la compétence : “prompting is basically the same thing as writing requirements as a PM. You need to describe what you want with precision and the appropriate level of detail.”

Les modèles vont continuer de s’améliorer. Le raisonnement va migrer plus loin “dans les poids”. Mais l’insight reste constant : des problèmes différents exigent des structures de pensée différentes. Savoir quelle structure colle à quel problème, c’est la vraie compétence.