Concevoir des prompts efficaces pour les modèles de raisonnement

Le prompt engineering a profondément changé de nature depuis l’arrivée des modèles de raisonnement. Écrire un bon prompt en 2026 ne consiste plus seulement à choisir les bons mots, mais à concevoir le contexte, les outils et le format de sortie qu’un modèle va utiliser pour raisonner et agir.

Pourquoi le prompt engineering a changé#

Les premiers modèles de langage répondaient directement à partir du prompt, sans étape de raisonnement intermédiaire visible. Les techniques historiques (few-shot, chain-of-thought explicite, formulations très détaillées) compensaient cette limite en guidant pas à pas le raisonnement du modèle dans le prompt lui-même.

Les modèles de raisonnement actuels (Claude Opus, GPT en mode reasoning, Gemini Thinking) effectuent une réflexion interne avant de produire leur réponse. Cela change deux choses fondamentales pour la rédaction des prompts.

• Le chain-of-thought explicite devient souvent inutile, voire contre-productif : demander au modèle de réfléchir étape par étape peut interférer avec son propre raisonnement interne.
• La qualité du prompt dépend moins de la formulation exacte et davantage de la clarté du contexte fourni : objectif réel, contraintes, critères de succès, informations disponibles.

Les quatre piliers du prompt engineering actuel#

1. Contexte plutôt que instructions#

Un prompt efficace décrit une situation (qui, quoi, pourquoi, avec quelles contraintes) plutôt qu’une liste rigide d’instructions à suivre pas à pas. Les modèles de raisonnement excellent à déduire la bonne méthode à partir d’un contexte bien posé.

2. Function calling et outils structurés#

La majorité des cas d’usage professionnels reposent désormais sur des modèles capables d’appeler des outils (recherche, exécution de code, appels API) plutôt que de tout générer en texte libre. Le prompt engineering inclut la définition précise des schémas d’outils (nom, paramètres, description) autant que le texte adressé au modèle.

{
  "name": "rechercher_disponibilites",
  "description": "Recherche les créneaux disponibles pour un rendez-vous",
  "parameters": {
    "type": "object",
    "properties": {
      "date_debut": { "type": "string", "format": "date" },
      "duree_minutes": { "type": "integer" }
    },
    "required": ["date_debut", "duree_minutes"]
  }
}

3. Format de sortie contraint#

Demander une sortie structurée (JSON avec schéma strict, XML balisé) réduit fortement les erreurs d’interprétation en aval, en particulier lorsque la réponse du modèle est consommée par du code plutôt que lue par un humain.

4. Gestion du contexte long#

Les fenêtres de contexte dépassent désormais couramment 200 000 tokens. La compétence clé n’est plus de faire tenir l’information dans un espace réduit, mais de hiérarchiser cette information pour que le modèle identifie ce qui est réellement pertinent parmi un volume important de texte.

5. Évaluation systématique des prompts#

Un prompt qui fonctionne sur quelques essais manuels ne garantit rien sur la durée : un modèle mis à jour, une reformulation mineure de la demande utilisateur ou un cas limite non anticipé peuvent faire régresser silencieusement un comportement jugé acceptable. La pratique qui s’est généralisée en 2026 consiste à constituer un jeu de cas de référence (entrée attendue, sortie jugée correcte ou critères de correction) et à le rejouer systématiquement à chaque modification du prompt, plutôt que de valider un changement sur la seule impression d’un essai isolé.

Cette évaluation peut rester manuelle (relecture humaine d’un petit nombre de cas représentatifs) ou s’appuyer sur un modèle juge qui note automatiquement chaque réponse par rapport à des critères explicites, une pratique utile pour suivre une régression dans le temps sans relire chaque sortie à la main.

Prompt engineering pour les agents autonomes#

Un agent qui enchaîne plusieurs actions (recherche, décision, exécution, vérification) pose des exigences différentes d’un prompt à réponse unique.

flowchart TD
  A[Instruction utilisateur] --> B[Agent : planification]
  B --> C{Outil nécessaire ?}
  C -->|Oui| D[Appel d'outil]
  D --> E[Résultat de l'outil]
  E --> B
  C -->|Non| F[Réponse finale à l'utilisateur]

Trois points de vigilance spécifiques aux agents.

• Critères d’arrêt explicites : sans condition de fin clairement posée dans le prompt système, un agent peut boucler indéfiniment ou s’arrêter trop tôt.
• Gestion des échecs d’outils : le prompt doit préciser le comportement attendu si un outil retourne une erreur ou une réponse vide, plutôt que de supposer un scénario toujours favorable.
• Traçabilité du raisonnement : conserver une trace des décisions intermédiaires de l’agent facilite le débogage, même quand le raisonnement final n’est pas exposé à l’utilisateur.

Erreurs fréquentes en 2026#

• Sur-spécifier un raisonnement que le modèle sait déjà mener seul, ce qui alourdit le prompt sans gain de qualité.
• Négliger la description des outils, en supposant que leur nom suffit à en expliquer l’usage.
• Ne pas tester le prompt avec des cas limites (entrée vide, information manquante, demande ambiguë).

Pour aller plus loin#

Le TP associé à ce cours propose la construction progressive d’un prompt système pour un agent simple, avec vérification de son comportement sur plusieurs scénarios. Le quiz associé permet de vérifier votre compréhension des cinq piliers avant de passer au TP.