Le prompt engineering est-il vraiment mort ?

Le terme reste utile, mais une application fiable exige de concevoir tout ce que le modèle reçoit et tout ce qui contrôle son action, au-delà de la seule formulation de la demande. Le prompt reste l'instruction visible. Le contexte ajoute données, exemples, historique, outils et règles. Les évaluations déterminent si l'ensemble fonctionne sur les cas métier.

Faut-il utiliser XML dans tous les prompts ?

XML aide à séparer les parties d'un contexte complexe, tandis qu'une prose claire, des titres Markdown ou un schéma natif peuvent mieux convenir à d'autres tâches. Une demande courte peut rester en prose. Des documents multiples gagnent souvent à être délimités explicitement. Une sortie machine doit privilégier le mode structuré ou l'appel d'outil proposé par l'API.

Quelle différence entre prompt engineering et context engineering ?

Le prompt engineering travaille la consigne, alors que le context engineering organise l'ensemble des informations et capacités disponibles au moment où le modèle doit répondre ou agir. La consigne décrit la tâche et ses contraintes. Le contexte rassemble références, exemples, état et historique utiles. Les outils, permissions et schémas bornent les actions et les sorties.

Une équipe non technique doit-elle apprendre XML ?

Une équipe métier doit surtout apprendre à définir une tâche vérifiable, tandis qu'un référent peut traduire cette définition dans le format adapté au modèle et à l'application. Le métier fournit les critères de réussite et les cas limites. Le référent maintient le gabarit et le jeu d'évaluation. Les utilisateurs remplissent des champs stables plutôt que de réécrire la consigne.

Une consigne structurée protège-t-elle d'une injection de prompt ?

La séparation des instructions et des données réduit certaines ambiguïtés, mais elle ne constitue qu'une couche d'une défense qui doit aussi limiter les droits et valider les actions sensibles. Traiter tout contenu externe comme non fiable. Limiter les outils et les données accessibles. Imposer une validation humaine lorsque l'action a des conséquences élevées. Tester les attaques représentatives du processus.

Le balisage remplace-t-il le RAG ou le fine-tuning ?

Le balisage organise une requête, le RAG sélectionne des références et le fine-tuning modifie le comportement du modèle ; ces techniques répondent donc à des problèmes distincts. Utiliser le RAG pour apporter des connaissances à jour ou privées. Utiliser un schéma pour garantir une sortie exploitable quand l'API le permet. N'envisager le fine-tuning qu'après avoir défini des exemples et une évaluation stables.

Management de transition

Après le prompt engineering : concevoir un contexte fiable pour l'IA

19 mai 2026 · Mis à jour le 6 septembre 2026 · 9 min de lecture · Paul-Antoine Tual

context engineering prompt engineering IA Méthode Junyr PME agents IA

Par Paul-Antoine TUAL, AI Transformation Leader, Croissance et Transitions. Mise à jour le 6 septembre 2026.

Le prompt n’est qu’une partie du système

L’interface de ChatGPT, lancée le 30 novembre 2022, a rendu l’IA accessible sous la forme d’une conversation, mais un usage professionnel dépend moins d’une « formule parfaite » que de la qualité de l’ensemble transmis au modèle.

Une demande isolée peut suffire pour explorer, reformuler ou résumer un texte court.
Une application ajoute des références, des exemples, un historique, des outils, des permissions et un format de sortie.
Chaque élément consomme une partie de la fenêtre de contexte et peut renforcer, contredire ou noyer une instruction.
La discipline consiste donc à construire puis tester ce contexte, souvent appelée context engineering [1].

Cette évolution ne signe pas la disparition du prompt engineering ; elle le replace dans un cycle d’ingénierie où les critères de réussite et les évaluations précèdent l’optimisation de la consigne [2].

Le prompt formule la tâche, le ton, les contraintes et le résultat attendu.
Le contexte fournit seulement les informations nécessaires à cette tâche.
L’évaluation mesure la qualité, la robustesse, le coût et la latence sur des cas représentatifs.
Une erreur persistante peut appeler un meilleur modèle, un meilleur retrieval, un outil ou une règle métier plutôt qu’un prompt plus long.

Ce qu’un dirigeant doit retenir du fonctionnement d’un LLM

Un LLM produit une réponse token par token à partir de son contexte et de paramètres d’inférence, ce qui explique à la fois sa fluidité, sa variabilité et la nécessité de vérifier ses sorties.

Tokenisation : le texte est découpé en unités que le modèle représente numériquement.
Prédiction : le transformeur calcule une distribution de probabilités pour le token suivant.
Attention : le modèle pondère les relations entre les éléments présents dans le contexte.
Génération : la réponse résulte d’une suite de choix probabilistes, sans garantie intrinsèque de vérité ni de conformité métier.

La longueur disponible ne garantit pas que chaque information sera utilisée avec la même fiabilité, car les expériences dites lost in the middle montrent que la position d’un fait pertinent peut affecter les performances sur certaines tâches de contexte long [3].

Placer la question et les contraintes essentielles à un endroit conforme au guide du modèle utilisé.
Retirer les documents sans rapport direct avec la décision demandée.
Identifier les sources et séparer clairement données, exemples et instructions.
Tester plusieurs positions et volumes de contexte sur le jeu métier au lieu d’appliquer une règle universelle.

Ce que l’interface de chat masque en production

Une conversation tolère la reformulation et la correction au tour suivant, tandis qu’un processus automatisé doit rendre explicites les hypothèses, les entrées, les sorties et le traitement des erreurs dès sa conception.

La politesse ou une persona peuvent orienter le ton, mais ne remplacent pas une définition vérifiable de la tâche.
Un terme comme « urgent », « complet » ou « risque élevé » doit être relié à une règle ou à un seuil métier.
Les données injectées par un utilisateur ou un document externe doivent être traitées comme des entrées non fiables.
Une sortie destinée à un logiciel doit respecter un schéma contrôlé, idéalement via la fonction de sortie structurée de l’API.

Les recommandations des éditeurs convergent sur la clarté, pas sur un format unique

Anthropic, OpenAI et Google recommandent tous des instructions précises et des parties clairement séparées, mais leurs guides laissent plusieurs moyens valables de les exprimer selon le modèle, la complexité et la sortie attendue [4][5][6].

Anthropic propose notamment des balises XML descriptives pour distinguer instructions, contexte, documents et exemples dans les prompts complexes [4].
OpenAI met l’accent sur des instructions simples, directes, cohérentes et sur l’itération à partir d’évaluations [5].
Google cite les balises XML, les titres Markdown et les séparateurs comme options de structuration, à utiliser de façon cohérente [6].
Pour une sortie JSON consommée par un programme, les fonctions de sortie structurée ou d’appel d’outil sont plus sûres qu’une simple demande textuelle de « répondre en JSON ».

Les résultats de recherche sur un domaine précis peuvent éclairer une conception sans fournir un pourcentage transférable à tous les processus, modèles ou secteurs.

Une étude clinique combine RAG et prompt engineering pour interpréter des recommandations relatives à l’hépatite C ; elle ne permet pas d’isoler l’effet du seul balisage ni de prédire le gain d’une PME [7].
Les benchmarks de sortie structurée comparent des modèles, des formats et des tâches définis ; leur score ne remplace pas un test sur les documents réels de l’entreprise [8].
Une décision de formation doit partir des tâches, erreurs et contrôles de l’entreprise plutôt que d’un taux générique de salariés formés.

Quand le balisage apporte peu

Le balisage devient utile quand il clarifie une frontière ou une hiérarchie réelle, mais il ajoute du bruit lorsqu’il enveloppe mécaniquement une demande courte déjà non ambiguë.

Prose courte : une reformulation ou une classification simple peut tenir dans une phrase avec le format attendu.
Markdown : des rubriques lisibles conviennent souvent à un prompt maintenu conjointement par métiers et développeurs.
XML : des balises descriptives aident à isoler plusieurs documents, exemples ou blocs de données.
Schéma natif : une API de sortie structurée convient mieux lorsqu’un système aval exige des champs et types précis.

Le choix doit venir d’une comparaison contrôlée plutôt que d’une préférence esthétique, car un gabarit gagne sa place seulement s’il améliore un critère utile sans dégrader excessivement le coût ou la maintenabilité.

Construire un petit jeu de cas normaux, difficiles et interdits.
Comparer la version simple et la version structurée sur le même modèle et les mêmes paramètres.
Mesurer exactitude métier, respect du format, omissions, coût et latence.
Conserver la forme la plus simple qui franchit les seuils convenus.

Les modèles plus capables réduisent-ils le besoin de structure ?

Un meilleur modèle peut réussir davantage de demandes en prose, mais une production gouvernée a toujours besoin d’un contrat explicite entre le métier, l’application et le modèle.

La structure rend les champs variables et les responsabilités visibles aux humains.
Le versionnage permet de relier une modification à une variation mesurée des sorties.
Les cas limites évitent de confondre une bonne démonstration avec une qualité stable.
La réévaluation à chaque changement majeur de modèle remplace toute prédiction arbitraire sur la durée de vie d’XML.

Quatre décisions pratiques pour une PME

Une PME peut professionnaliser ses usages sans transformer tous ses collaborateurs en spécialistes du prompting, à condition d’attribuer les responsabilités et de concentrer l’effort sur les processus qui ont un véritable enjeu.

Former les métiers à la spécification : définir l’objectif, les références autorisées, les critères de réussite et les cas à escalader.
Maintenir les gabarits critiques : nommer un propriétaire, versionner les changements et associer chaque version à des tests.
Gouverner les agents : limiter leurs outils, leurs données et leurs droits, puis exiger une validation humaine pour les actions à conséquence élevée.
Préparer la portabilité : séparer la logique métier des particularités du fournisseur et tester au moins une solution de repli lorsque la continuité le justifie.

Trois questions pour auditer vos consignes

Trois questions simples révèlent rapidement si les prompts critiques sont encore des astuces individuelles ou déjà des composants pilotés du processus.

Quels prompts influencent une décision, un client, un paiement, un document officiel ou une action sur un système ?
Qui possède chacun de ces gabarits, ses sources, ses droits d’accès et son jeu de tests ?
Quel test de non-régression est exécuté après une modification du prompt, du modèle, du retrieval ou d’un outil ?

Le socle opérationnel proposé par la Méthode Junyr™

Au niveau 3 « Orchestre » de la Méthode Junyr™, les usages récurrents sont traités comme des actifs opérationnels : leur consigne, leurs entrées, leurs contrôles et leur propriétaire deviennent inspectables.

Un gabarit minimal sépare la tâche, les références, les règles de traitement et la sortie attendue.
Une bibliothèque versionnée relie chaque gabarit à un responsable, un historique et un jeu d’évaluation.
Un cadre de délégation limite les outils et prévoit les validations, journaux et procédures de reprise adaptés au risque.

Le gabarit suivant illustre une tâche multi-document ; ses balises sont descriptives, mais leur nom et leur présence doivent être adaptés au modèle et au cas d’usage.

<task> formule le livrable et la décision qu’il doit éclairer.
<documents> regroupe les sources avec un identifiant stable.
<rules> décrit la méthode, les exclusions et les conditions d’escalade.
<output> fixe les sections, les citations et les champs attendus.

<task>Comparer les documents et produire une note de décision.</task>
<documents>
  <document id="1">…</document>
  <document id="2">…</document>
</documents>
<rules>
  Citer chaque divergence avec l'identifiant du document.
  Signaler toute information insuffisante sans la compléter par supposition.
</rules>
<output>Résumé, divergences, informations manquantes, recommandation.</output>

Conclusion : spécifier, tester, gouverner

La compétence durable n’est ni une tournure magique ni XML en soi, mais la capacité à transformer un besoin métier en contexte contrôlé, en sortie vérifiable et en processus dont une personne reste responsable.

Commencer par une consigne courte et des critères de réussite observables.
Ajouter contexte, exemples ou balises seulement lorsqu’ils résolvent une erreur identifiée.
Employer les fonctions natives de schéma et d’outils quand le modèle doit interagir avec un logiciel.
Rejouer les évaluations après chaque changement susceptible d’affecter le comportement.

Faire le point en 30 minutes

L’audit gratuit de maturité IA Junyr est un échange vidéo de 30 minutes, sans engagement, qui situe l’entreprise sur l’échelle, identifie le principal blocage et le premier projet raisonnable, puis fournit un récapitulatif d’une page.

Réserver l’audit
Préparer un processus concret, son responsable et un exemple de sortie actuelle pour rendre l’échange plus utile.

Sources

[1] Andrej Karpathy, publication sur le context engineering, 25 juin 2025. x.com
[2] Anthropic, Prompt engineering overview. platform.claude.com
[3] Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023. arxiv.org
[4] Anthropic, Prompting best practices. platform.claude.com
[5] OpenAI, Prompting. developers.openai.com
[6] Google, Prompt design strategies. ai.google.dev
[7] So et al., Optimization of hepatological clinical guidelines interpretation by large language models, 2024. Nature
[8] Jiao et al., StructEval: Benchmarking LLMs’ Capabilities to Generate Structural Outputs, 2025. arxiv.org

Paul-Antoine TUAL est AI Transformation Leader. Il dirige Croissance et Transitions et développe la suite Junyr™.

Questions fréquentes

Le prompt engineering est-il vraiment mort ?: Le terme reste utile, mais une application fiable exige de concevoir tout ce que le modèle reçoit et tout ce qui contrôle son action, au-delà de la seule formulation de la demande.

Le prompt reste l'instruction visible.
Le contexte ajoute données, exemples, historique, outils et règles.
Les évaluations déterminent si l'ensemble fonctionne sur les cas métier.
Faut-il utiliser XML dans tous les prompts ?: XML aide à séparer les parties d'un contexte complexe, tandis qu'une prose claire, des titres Markdown ou un schéma natif peuvent mieux convenir à d'autres tâches.

Une demande courte peut rester en prose.
Des documents multiples gagnent souvent à être délimités explicitement.
Une sortie machine doit privilégier le mode structuré ou l'appel d'outil proposé par l'API.
Quelle différence entre prompt engineering et context engineering ?: Le prompt engineering travaille la consigne, alors que le context engineering organise l'ensemble des informations et capacités disponibles au moment où le modèle doit répondre ou agir.

La consigne décrit la tâche et ses contraintes.
Le contexte rassemble références, exemples, état et historique utiles.
Les outils, permissions et schémas bornent les actions et les sorties.
Une équipe non technique doit-elle apprendre XML ?: Une équipe métier doit surtout apprendre à définir une tâche vérifiable, tandis qu'un référent peut traduire cette définition dans le format adapté au modèle et à l'application.

Le métier fournit les critères de réussite et les cas limites.
Le référent maintient le gabarit et le jeu d'évaluation.
Les utilisateurs remplissent des champs stables plutôt que de réécrire la consigne.
Une consigne structurée protège-t-elle d'une injection de prompt ?: La séparation des instructions et des données réduit certaines ambiguïtés, mais elle ne constitue qu'une couche d'une défense qui doit aussi limiter les droits et valider les actions sensibles.

Traiter tout contenu externe comme non fiable.
Limiter les outils et les données accessibles.
Imposer une validation humaine lorsque l'action a des conséquences élevées.
Tester les attaques représentatives du processus.
Le balisage remplace-t-il le RAG ou le fine-tuning ?: Le balisage organise une requête, le RAG sélectionne des références et le fine-tuning modifie le comportement du modèle ; ces techniques répondent donc à des problèmes distincts.

Utiliser le RAG pour apporter des connaissances à jour ou privées.
Utiliser un schéma pour garantir une sortie exploitable quand l'API le permet.
N'envisager le fine-tuning qu'après avoir défini des exemples et une évaluation stables.

Paul-Antoine Tual

AI Transformation Leader · Méthode Junyr™ · Manager de transition IA pour PME et ETI françaises. Ingénieur des Mines de Nantes, juriste, développeur depuis 1993.

Audit de maturité IA gratuit →

← Tous les articles