28 mai 2026
Prompt engineering en 2026 : ce qui compte vraiment
Retour d'expérience honnête sur le prompt engineering en production : ce qui compte encore, ce qui casse à la première mise à jour de modèle, et ce qui a réellement changé avec les sorties structurées, les outils et les evals.
Le prompt engineering n'est pas mort. Il a juste quitté le théâtre.
Il y a deux mauvaises lectures du sujet en 2026. La première dit que le prompt engineering est mort parce que les modèles sont meilleurs. La seconde dit qu'il faut des templates toujours plus complexes pour tirer quelque chose d'un LLM. D'après mon expérience en production, les deux sont fausses. L'ingénierie des prompts compte toujours, mais elle ne ressemble plus au concours de formules magiques de 2023. Elle ressemble davantage à un travail d'interface entre un système logiciel, un modèle de langage, des outils, et un niveau de qualité attendu.
Quand j'écris un prompt aujourd'hui, je ne cherche pas à impressionner un benchmark Twitter. Je cherche à rendre un comportement stable assez longtemps pour qu'il survive à la vraie vie : trafic irrégulier, données sales, changements de modèle, contraintes produit, et utilisateurs qui ne formulent pas leur besoin proprement. Le prompt engineering utile n'est pas un art ésotérique. C'est une discipline de production.
Ce qui compte encore : un prompt système clair, de bons exemples, et des contraintes nettes
La base reste étonnamment simple. Un prompt système bien écrit compte encore énormément. Si le système doit être prudent, structuré, concis, ou capable de refuser certains cas, cela doit être explicite. Les meilleurs résultats viennent rarement d'un grand monologue inspiré. Ils viennent d'instructions courtes, hiérarchisées, reliées au vrai rôle du système. Dire au modèle ce qu'il est censé faire, ce qu'il ne doit jamais faire, et à quoi ressemble une bonne sortie reste du travail réel, que l'on soit sur Claude, GPT ou un autre modèle.
Les exemples few-shot comptent encore, mais seulement quand ils apprennent une forme utile. Trois exemples propres valent mieux qu'un empilement de cas moyens. Même logique pour la chain-of-thought : en production, je veux surtout une procédure fiable, pas un long raisonnement exposé. Le bon levier est souvent de demander une méthode ou des étapes de vérification. Ce n'est pas la longueur du raisonnement qui crée la qualité. C'est la qualité des contraintes.
Ce qui est surcoté : les templates fragiles qui cassent au premier changement
Ce que je vois le plus surévalué aujourd'hui, ce sont les énormes templates de prompt engineering censés tout résoudre : rôle détaillé, ton, arbre de décision caché, menaces absurdes, XML artisanal, mémoire simulée, checklist, puis une dizaine de placeholders injectés par-dessus. Oui, cela peut marcher sur une démo. Oui, cela peut parfois améliorer un cas précis pendant une semaine. Mais dès qu'un modèle évolue, qu'un paramètre change, ou qu'un produit ajoute un nouvel outil, ce genre de mécanique devient cassante.
Le problème est simple : beaucoup de ces templates compensent un défaut d'architecture par de la prose. On demande au prompt de porter la logique métier, la validation, l'orchestration, et parfois même le contrôle de sortie. C'est une mauvaise répartition des responsabilités. Si votre pipeline dépend d'une chorégraphie textuelle trop fine, il n'est pas solide. Il est juste temporairement aligné.
Ce qui est réellement nouveau : sorties structurées, appels d'outils, evals
Le vrai changement depuis deux ans n'est pas que les gens savent écrire de plus longs prompts. Le vrai changement, c'est que les meilleurs systèmes déplacent une partie du travail hors du texte libre. Les structured outputs et les patterns de tool-calling changent profondément la pratique. Quand vous demandez au modèle de produire un schéma clair, puis de décider quand appeler un outil et comment réintégrer le résultat, vous rendez le système plus testable, plus branchable, et plus facile à corriger. Le prompt devient alors une pièce d'orchestration dans un système, pas un texte isolé.
Et surtout, le prompt engineering sérieux est désormais piloté par les evals. Je ne crois plus aux longues sessions d'édition de prompt sans boucle de mesure. On change une instruction, on lance un set d'evals, on regarde les régressions, on compare à la baseline. C'est moins romantique que le mythe du prompt parfait, mais c'est ce qui marche. Le prompt engineering mature ressemble de plus en plus à une pratique d'itération guidée par des tests.
Mon point de vue de builder : le prompt est une pièce du système, pas le système lui-même
Au fond, mon opinion est assez directe. Le prompt engineering reste une compétence importante, mais il faut arrêter de le traiter comme une magie autonome. Un bon prompt peut faire gagner beaucoup. Un mauvais prompt peut faire dérailler un flux entier. Mais ni l'un ni l'autre ne remplacent une bonne architecture. Ce qui compte en production, c'est l'ensemble : prompt système, structure de sortie, choix d'outils, contexte métier, evals, logs, et arbitrage humain là où il faut.
J'écris les prompts, je code le pipeline, je déploie, je debug. Vu depuis ce terrain-là, le sujet est plus simple qu'on ne le raconte souvent. En 2026, le bon prompt engineering n'est ni mort ni héroïque. C'est une forme de rigueur appliquée à un système LLM réel. Si vous voulez quelque chose qui tienne en production, écrivez moins pour impressionner le modèle, et davantage pour rendre le système lisible, mesurable et corrigeable.