Version intégrée et fonctionnelle

Session 3, prompting, lecture critique et comparaison des modes d’usage

On part d’abord de ce qu’un prompt peut et ne peut pas faire, on distingue ensuite LLM basique, agent d’IA et mode recherche approfondie, puis seulement on place Zero-shot, Few-shot, CoT et CARE dans une même grille de lecture. Les captures du problème du car wash et le report.md servent enfin d’appui empirique, avant un regroupement de toutes les sources en bas de page.

Ce que cette mise à jour corrige

  • La section sur les trois modes de prompting est remontée avant le comparatif Zero-shot, Few-shot, CoT et CARE.
  • Une galerie de captures du problème du car wash montre que l’erreur change de forme selon les interfaces.
  • Toutes les sources externes sont regroupées à la toute fin du document.
Session 3

Prompt engineering, prédictibilité et vigilance

Cette séance recentre le cours sur une question méthodologique simple mais décisive. Si un modèle prédit le token suivant, comment obtenir une sortie utile, stable et exploitable sans confondre amélioration du cadrage et garantie de vérité.

Point de départ du cas car wash Source reprise en fin de document

I want to wash my car. The car wash is 50 meters away. Should I walk or drive?

Reconstruction visuelle élargie du point de départ cité dans la séance. Le but ici n’est pas de décorer le cas, mais de rendre visible le type d’ambiguïté implicite qui piège le modèle.

Voir les références finales

Le problème est trivial pour un humain mais instructif pour un LLM. La distance est courte, donc marcher paraît plausible. Pourtant la tâche réelle consiste à amener la voiture au car wash. C’est précisément ce décalage entre heuristique locale et contrainte implicite que la séance utilise comme fil rouge.

Pourquoi cette séance compte

Le prompt engineering sert à réduire l’ambiguïté, à orienter le calcul du modèle, à cadrer le format de sortie et à améliorer la cohérence d’ensemble. En revanche, un prompt n’est jamais une preuve de vérité. Un bon prompt augmente la probabilité d’un bon résultat, mais il n’annule ni l’incertitude statistique, ni les raccourcis du modèle, ni les biais que nous introduisons nous-mêmes.

Il faut donc tenir ensemble deux idées. Premièrement, le prompt est une forme de programmation en langage naturel. Deuxièmement, cette programmation reste partielle. Elle contrôle le cadrage, pas le monde réel.

Ce qu’un LLM fait réellement

Un LLM n’accède pas directement au monde. Il traite une suite de tokens et calcule quelle continuation est la plus probable compte tenu du contexte reçu. C’est pour cela qu’une réponse peut être fluide, convaincante et grammaticalement propre tout en étant fausse sur le fond.

Ce que le prompt peut améliorer Ce qu’il ne garantit pas
La clarté de la tâche La vérité factuelle à elle seule
Le format de la réponse L’absence totale d’hallucination
La cohérence interne Une interprétation unique et universelle
La stabilité relative des sorties La suppression des biais du modèle ou de l’utilisateur
Différences de prompting

On ne prompt pas pareil un LLM basique, un agent d’IA et un mode recherche approfondie

Avant de choisir une technique de prompting, il faut d’abord savoir à quel type de système on parle. C’est l’erreur la plus fréquente chez les débutants. Ils appliquent la même logique de consigne à un LLM ponctuel, à un agent outillé et à un mode de recherche approfondie, alors que ces trois régimes de travail n’attendent pas le même niveau de cadrage.

Ordre de lecture conseillé

1. Identifier le système. 2. Définir le niveau d’autonomie attendu. 3. Choisir ensuite la famille de prompt adaptée. Sans cette étape, le comparatif Zero-shot, Few-shot, CoT et CARE perd une partie de son sens.

Type de système Logique de travail Ce qu’il faut préciser dans le prompt Erreur fréquente Bonne pratique
LLM basique Réponse directe à une consigne ponctuelle. Objectif, contexte immédiat, format attendu, contraintes de ton et de longueur. Empiler des demandes contradictoires dans un seul message. Faire court, net, observable, avec sortie vérifiable.
Agent d’IA Boucle plus outillée avec rôle, workflow, outils, vérification, parfois mémoire. Mission, responsabilités, outils autorisés, critères d’arrêt, tests, validation, gestion des erreurs. Le traiter comme un simple chatbot sans lui donner le cadre opératoire. Écrire un brief de mission, pas seulement une question.
LLM en recherche approfondie Travail itératif orienté collecte, recoupement, hiérarchisation et restitution sourcée. Périmètre, niveau de preuve attendu, sources prioritaires, forme du livrable, gestion des incertitudes. Demander une conclusion définitive avant d’avoir défini le protocole de recherche. Donner une question, un protocole, des critères de sélection de sources et une structure finale.
Comment le dire simplement dans le cours

Un LLM basique répond. Un agent exécute une mission. Un mode recherche approfondie enquête puis synthétise. Plus le système agit, plus le prompt doit préciser le rôle, la méthode, les outils, les critères de contrôle et la manière de traiter l’incertitude.

Exemple pédagogiquetriple différence de formulation
LLM basique
Explique le problème du car wash en 6 lignes pour un public débutant.

Agent d’IA
Analyse le problème du car wash, vérifie les conditions implicites, compare plusieurs réponses, puis rends un court rapport avec une section risques d’erreur.

Mode recherche approfondie
Étudie les sources disponibles sur le car wash problem, distingue résultats expérimentaux et interprétations, puis rédige une synthèse critique avec références et limites méthodologiques.
Étude arXiv

Ce que montre l’architecture du prompt

L’étude arXiv fournie est utile parce qu’elle n’oppose pas seulement des modèles. Elle isole plusieurs couches de prompt. À hyperparamètres contrôlés, une structure de raisonnement de type STAR fait passer la réussite de 0 pour cent à 85 pour cent. Le profil utilisateur seul atteint 30 pour cent. STAR plus profil monte à 95 pour cent, puis la pile complète atteint 100 pour cent dans ce protocole expérimental.

La bonne lecture méthodologique n’est pas de conclure qu’une formule marcherait partout. Le résultat montre plutôt ceci. La manière de poser la tâche change fortement la distribution des sorties. Autrement dit, le prompt agit sur le type de raisonnement que le modèle a une chance de dérouler.

Graphique pédagogique sur l'effet de l'architecture du prompt sur le problème du car wash
Cette figure reprend les résultats principaux signalés dans l’étude arXiv sur les six conditions testées autour du car wash problem.

Le prompt est important, mais la justesse n’est jamais garantie

Un prompt robuste doit être clair, non équivoque et cohérent avec lui-même. Il vaut mieux une consigne directe, un objectif unique, un contexte bien borné, un format explicite et un critère de réussite observable. À l’inverse, les formulations floues, contradictoires ou surchargées dispersent l’attention du modèle sur plusieurs lectures concurrentes.

Il faut toutefois éviter la caricature inverse. Toute reformulation n’est pas mauvaise. Une reformulation contrôlée peut renforcer la compréhension. Ce qui devient dangereux, c’est la paraphrase imparfaitement alignée qui déplace la cible sémantique.

Hyperparamètres et réplicabilité

Le prompt ne travaille jamais seul. La température, le top p et les autres réglages de décodage influencent eux aussi la forme finale de la sortie. Un même prompt peut donc produire des réponses plus stables ou plus variables selon le décodage retenu.

Pour un usage pédagogique, expérimental ou professionnel, la bonne pratique n’est pas seulement d’écrire un bon prompt. Il faut aussi documenter les réglages de génération lorsque l’on cherche de la réplicabilité.

Structure d’un prompt

Prompt structuré, ossature minimale

Une consigne robuste explicite généralement cinq éléments. L’objectif, le contexte, les contraintes, le format attendu et les critères de réussite. L’enjeu n’est pas la longueur. L’enjeu est la clarté et la non-contradiction.

Prompt structuré ossature minimale 
Objectif       ce que tu dois produire
Contexte       sur quoi tu dois te baser
Contraintes    règles à respecter
Format         forme de sortie attendue
Critères       comment on juge que c’est bon

Un prompt fourre-tout peut dégrader la qualité. Multiplier les consignes n’aide pas si elles se contredisent ou si elles déplacent la tâche d’une ligne à l’autre.

Grille de lecture

Zero-shot, Few-shot, CoT et CARE dans une même grille de lecture

Une fois le type de système clarifié, on peut comparer les grandes familles de prompting. Cette grille de lecture ne sert pas à sacraliser une méthode unique. Elle sert à comprendre quel problème chaque approche résout. Zero-shot aide à cadrer vite une tâche simple. Few-shot montre un comportement attendu. CoT explicite davantage le chemin. CARE stabilise un livrable à partir du contexte, de l’action, des critères et du format.

Approche Ce qu’elle fait Quand elle aide vraiment Risque principal Exemple de bonne logique
Zero-shot Décrire la tâche sans exemple. Questions simples, premier jet, reformulation rapide, demande peu ambiguë. Compréhension trop large ou trop vague de la consigne. Résume ce texte en 5 points, sans inventer d’information.
Few-shot Montrer quelques exemples d’entrée-sortie pour guider le comportement. Extraction, classification, format strict, style décisionnel à reproduire. Sur-ajustement aux exemples et transfert de biais. Voici 3 exemples du format attendu, applique ensuite le même schéma au texte suivant.
CoT Demander une articulation plus explicite du raisonnement ou des étapes. Tâches multi-étapes, arbitrages, chaînes de décision où l’on veut voir la logique suivie. Justification plausible mais fausse, donc illusion de compréhension. Décompose le problème en étapes, puis donne la conclusion séparément.
CARE Structurer la demande par contexte, action, règles, exemple de sortie. Production professionnelle, email, note, résumé cadré, rapport, contenu à contrainte forte. Prompt trop long ou trop rigide si le livrable réel n’est pas clair. Contexte, action, critères, format d’exemple.
Lecture pratique

Pour enseigner proprement, il vaut mieux présenter CARE comme une architecture simple de cadrage, Few-shot comme une architecture par démonstration, et CoT comme une architecture d’explicitation du chemin, pas comme une garantie de vérité.

Point à ne pas laisser passer

Un étudiant peut croire qu’un raisonnement long est plus exact. C’est faux. Il est souvent plus lisible, parfois plus utile, mais jamais automatiquement plus vrai.

Études de cas

Deux cas concrets pour comprendre ce que le prompt change

Cas 1, extraction d’informations

Mauvais prompt trop flou 
Extract the key info from this text.
Meilleur prompt structuré 
Objectif     extraire des champs précis
Contexte     texte ci-dessous
Contraintes  ne pas inventer, si absent mettre null
Format       JSON selon le schéma demandé

Ce que cela améliore surtout, c’est la conformité au format et l’exploitabilité. Ce que cela ne garantit pas, c’est la vérité si le texte source est ambigu ou bruyant.

Cas 2, rédaction avec contraintes fortes

Mauvais prompt demande naïve 
Write a detailed report about LLMs, don't make mistakes.
Meilleur prompt cadrage explicite 
But          rédiger une explication pour débutants
Public       non technique
Plan         sections imposées
Contraintes  définir chaque terme, donner un exemple, signaler les limites
Vérification checklist finale tokens / embeddings / attention / hallucinations

Ici encore, on réduit surtout le flou. On n’obtient pas automatiquement une exactitude factuelle parfaite si aucune source n’est fournie.

Erreurs fréquentes à éviter

  • Demander au modèle d’être exact sans fournir de sources ni de stratégie de vérification.
  • Mélanger objectifs et formats contradictoires, par exemple une réponse libre et un JSON strict dans la même consigne.
  • Penser que l’instruction ne pas halluciner suffit à empêcher le modèle de deviner.
  • Supposer que quelques exemples remplacent toujours une vraie décomposition de tâche, des outils ou une évaluation externe.
Exemples visuels

Le problème du car wash vu à travers plusieurs interfaces

Avant de lire le benchmark, il est utile de regarder les sorties elles-mêmes. Ces captures montrent une idée centrale pour le cours. L’erreur n’apparaît pas toujours sous la même forme. Tantôt la réponse est courte et tranchée, tantôt elle est structurée, argumentée, sourcée ou très fluide. Pourtant le défaut de lecture pragmatique peut rester le même.

Le point pédagogique n’est pas de ridiculiser un modèle particulier. Il est de montrer qu’une réponse peut sembler claire, polie, détaillée ou documentée sans pour autant résoudre correctement la tâche implicite.
Qwen3-Max, réponse immédiate et confiante

Qwen3-Max, réponse immédiate et confiante

Le modèle tranche très vite en faveur de la marche et transforme une question de finalité en simple calcul local de distance.

Réponse structurée mais lecture de tâche incomplète

Réponse structurée mais lecture de tâche incomplète

La réponse paraît méthodique, pourtant elle raisonne encore à partir du déplacement humain et non à partir de la contrainte réelle, à savoir amener la voiture au lavage.

Réponse persuasive, ton fluide, erreur intacte

Réponse persuasive, ton fluide, erreur intacte

Le style conversationnel renforce la persuasion, mais l’argument central reste erroné. C’est un bon support pour montrer qu’un ton convaincant n’est pas une preuve de justesse.

Réponse concise et littéraire

Réponse concise et littéraire

La formulation est élégante et brève, mais elle maintient le même contresens. Le problème n’est donc pas seulement la longueur ou le ton de la sortie.

Réponse organisée en sous-points

Réponse organisée en sous-points

La structuration en arguments ne suffit pas non plus. On peut obtenir une présentation très claire tout en restant bloqué sur une hypothèse de départ incorrecte.

Réponse sourcée et pourtant mal orientée

Réponse sourcée et pourtant mal orientée

Même lorsqu’une interface affiche des sources ou des appuis externes, la réponse peut rester prise dans une mauvaise lecture pragmatique du problème.

Lecture recommandée pour les étudiants. Commencer par décrire ce que chaque interface semble bien faire, puis isoler le point précis où la lecture de la tâche bifurque.
Benchmark complémentaire

Ce que montre car-wash-evals

Le benchmark GitHub ajoute une information décisive. Le cadrage du prompt change fortement l’issue, mais l’apparence d’une bonne réponse ne suffit pas. Dans la synthèse fournie, les prompts de raisonnement atteignent 56,5 pour cent de réussite contre 24,0 pour cent pour les prompts simples. Le même rapport signale aussi 127 réponses confiantement fausses sur 400 essais.

Le dépôt montre aussi un écart entre la réussite mesurée sur la réponse complète et la réussite mesurée sur une réponse directe et cohérente. Une sortie peut donc ressembler à une bonne réponse tout en contenant un raisonnement ou une justification qui ne tient pas.

Graphique du benchmark car-wash-evals, taux de réussite et de récupération pour différents modèles
Lecture pédagogique du benchmark car-wash-evals. Ce graphique illustre pour chaque modèle le taux de réussite primaire et le taux de récupération après challenge.

Ce que cela change dans l’écriture d’un prompt

Il faut viser une entrée claire et stable. Cela suppose un objectif explicite, un contexte utile mais pas bavard, des contraintes visibles, un format annoncé et, si nécessaire, une indication sur ce que le modèle doit faire lorsqu’une information manque.

Il faut aussi surveiller les biais que nous injectons nous-mêmes. En voulant aider, on peut sur-spécifier la scène, suggérer une lecture morale ou enfermer le modèle dans une piste trop étroite.

Un bon prompt n’est pas un texte décoratif. C’est un instrument de contrôle partiel. Il sert à cadrer, pas à garantir.

Rapport GitHub cible

Présentation commentée du fichier report.md

Après les distinctions conceptuelles et les exemples visuels, le fichier report.md sert de point de fixation empirique. Il permet de passer d’une lecture qualitative des réponses à une lecture mesurée du benchmark.

9essais totaux
11,1%taux de réussite primaire
37,5%récupération après challenge
Modèle ID résolu Pass rate primaire Fails Ambigus Recovery Confident-wrong Latence médiane
ChatGPT 5.2 Instantopenai/gpt-5-mini0%110%021 843 ms
ChatGPT 5.2 Thinkingopenai/gpt-50%110%022 179 ms
ChatGPT 5.2 Proopenai/gpt-5-pro0%110%076 201 ms
Gemini 3 Fastgoogle/gemini-2.0-flash-0010%10100%03 824 ms
Gemini 3 Thinkinggoogle/gemini-2.5-pro0%100%011 380 ms
Gemini 3 Progoogle/gemini-2.5-pro0%100%09 959 ms
Claude Haiku 4.5anthropic/claude-3.5-haiku0%10100%04 586 ms
Claude Sonnet 4.5anthropic/claude-3.7-sonnet100%00n/a03 143 ms
Claude Opus 4.6anthropic/claude-3.7-sonnet0%10100%17 697 ms
Ce que le tableau permet de voir tout de suite

Un seul modèle passe du premier coup dans ce rapport cible. Plusieurs autres récupèrent après contestation, ce qui suggère que leur première réponse n’est pas toujours une absence totale de compétence, mais un mauvais cadrage initial du problème.

Ce que le tableau ne permet pas de dire à lui seul

On ne peut pas inférer ici une hiérarchie stable et universelle entre modèles. L’échantillon est très petit, la tâche est unique, et le résultat dépend fortement du protocole exact de questionnement puis de relance.

Commentaires critiques

Commentaire méthodologique sur le car wash problem

La bonne logique pédagogique est désormais complète. On part de la structure du prompt, on distingue les types de systèmes, on compare les familles de consignes, on observe des sorties réelles, puis on termine par une lecture critique du benchmark. Cette dernière étape évite de confondre élégance rédactionnelle et justesse méthodologique.

Forces du support

  • Cas immédiatement compréhensible par des étudiants non spécialistes.
  • Très bon révélateur de contrainte implicite non dite.
  • Permet de distinguer réponse persuasive et réponse réellement adaptée.
  • Montre l’intérêt du cadrage, du raisonnement structuré et de l’évaluation.

Limites du support

  • Tâche unitaire, donc généralisation prudente.
  • Effet potentiellement sensible à la formulation exacte.
  • Petit nombre d’essais dans le rapport cible.
  • Le bon résultat observable ne donne pas automatiquement accès au mécanisme interne réel.
Interprétation défendable en cours

Le prompt engineering compte. L’architecture du prompt peut déplacer très fortement la distribution des sorties. Mais le prompt n’abolit ni les limites du modèle, ni les effets du décodage, ni les erreurs d’interprétation, ni les enjeux d’alignement plus profonds. La bonne posture pédagogique est donc double. Mieux écrire les prompts, puis vérifier ce qu’ils produisent.

Parenthèse de vigilance

Pourquoi parler de désalignement dans une séance sur les prompts

La vigilance ne porte pas seulement sur la formulation du prompt. Elle porte aussi sur l’état du modèle lui-même. Le travail d’OpenAI signalé dans la séance montre qu’un modèle peut généraliser de mauvais comportements à partir d’un réglage étroit sur des données incorrectes. Le prompt peut aider, mais il ne neutralise pas ce type de dérive à lui seul.

La séance retient surtout trois repères simples. Des signaux internes peuvent apparaître très tôt, parfois dès 5 pour cent de données incorrectes. Le désalignement visible peut émerger plus largement selon le domaine. Et un ré-alignement relativement court sur des données correctes peut déjà réduire fortement le problème.

Schéma de synthèse sur le désalignement et le ré-alignement, évolution du score de désalignement en fonction du nombre d’étapes de SFT
Schéma de synthèse pédagogique autour du désalignement et du ré-alignement. Le graphique montre comment le score de désalignement décroît au fur et à mesure des étapes de finetuning.
Fin de séance

Ce qu’il faut retenir

  • Le prompt engineering est fondamental parce qu’il change la manière dont la tâche est représentée pour le modèle.
  • Cette importance ne doit jamais être confondue avec une garantie de justesse absolue.
  • La réplicabilité dépend du couple prompt plus décodage, pas du prompt seul.
  • Une réponse persuasive peut rester fausse, et un modèle peut sembler cohérent tout en suivant une logique mal ancrée.
  • Il faut donc écrire des prompts plus propres, mais aussi garder une culture d’évaluation, de vérification et de comparaison de sorties.
Pourquoi structurer un prompt améliore souvent le résultat
Parce que cela réduit l’ambiguïté, précise la tâche, stabilise le format attendu et rend le résultat plus vérifiable.
Pourquoi un bon prompt ne garantit-il pas la vérité
Parce que le modèle prédit des continuations probables et n’accède pas directement au monde réel.
Quand le few-shot devient-il utile
Quand il faut montrer un comportement attendu, un format strict ou une logique de décision difficile à imposer par simple description.
Pourquoi les prompts de raisonnement doivent-ils être traités avec prudence
Parce qu’ils peuvent améliorer certaines tâches tout en produisant des étapes plausibles qui ne constituent pas une preuve de vérité interne.
Pourquoi la parenthèse sur le désalignement est-elle utile ici
Parce qu’un bon prompt ne suffit pas si le modèle a lui-même dérivé à cause de son réglage ou de ses données.
Références

Références intégrées dans cette version

  1. car_wash_core9 Report, tableau cible des neuf essais et métriques globales.
  2. Dépôt GitHub car-wash-evals, contexte général du problème du car wash.
  3. Prompt Architecture Determines Reasoning Quality, étude isolant les effets de STAR, profil et RAG.
  4. OpenAI Prompt Engineering Guide, few-shot, structured outputs, guidage explicite des workflows.
  5. Toward understanding and preventing misalignment generalization, repères pédagogiques sur le désalignement et le ré-alignement.
  6. Post Mastodon d’origine, point de départ du cas.
Toutes les sources externes du cours sont volontairement regroupées ici afin de ne pas fragmenter la lecture principale. Le corps du document sert à construire le raisonnement du cours.