Pourquoi le prompt engineering simple gagne ?

Le prompt engineering simple gagne parce qu’il laisse le modèle raisonner au lieu de l’enfermer dans des règles fragiles. Le vrai sujet n’est pas d’écrire plus d’instructions, mais de mieux séparer intention, contexte, vérification et architecture applicative.

Quelle est la leçon amère ?

La leçon amère dit que les méthodes générales qui exploitent la puissance de calcul et l’apprentissage à grande échelle finissent souvent par dépasser les solutions humaines très spécialisées.

Rich Sutton a formulé cette idée dans The Bitter Lesson, un essai publié en 2019. Son constat est simple, et assez désagréable pour les ingénieurs : en intelligence artificielle, les approches fondées sur des heuristiques humaines, c’est-à-dire des règles pratiques imaginées par des experts, peuvent donner de bons résultats pendant un temps. Mais elles se font régulièrement dépasser par des méthodes plus générales dès que celles-ci peuvent profiter du scale.

Le scale, dans ce contexte, désigne l’augmentation combinée de trois ressources : plus de données, plus de calcul et des modèles avec plus de capacité d’apprentissage. Autrement dit, au lieu d’encoder à la main tout ce qu’un système doit savoir, on construit une méthode capable d’apprendre davantage quand on lui donne plus de matière et plus de puissance.

Le lien avec les LLM est direct. Un LLM, ou grand modèle de langage, est un modèle entraîné sur de très grands volumes de texte pour prédire, générer, résumer, classer ou transformer du langage. GPT-4o, Claude 3.5 Sonnet ou Gemini 2.0 comprennent déjà beaucoup mieux l’intention générale, le contexte et les consignes de haut niveau que les générations plus anciennes. Cette progression ne vient pas d’une collection infinie de petites règles écrites à la main. Elle vient surtout de modèles plus puissants, mieux entraînés et capables de généraliser.

Cette leçon ne dit pas qu’il faut arrêter d’écrire de bons prompts. Elle dit plutôt qu’un bon prompt doit aider le modèle, pas le remplacer. Une instruction claire, hiérarchisée et testable vaut souvent mieux qu’une liste fragile de micro-règles.

• Une bonne consigne précise l’objectif.
• Une bonne consigne donne le contexte utile.
• Une bonne consigne indique les contraintes vraiment importantes.
• Une bonne consigne se vérifie facilement sur plusieurs exemples.

Le piège classique commence juste après la première erreur. Le modèle répond mal, alors on ajoute une règle. Puis une exception. Puis une interdiction. Puis une priorité contradictoire. À la fin, le prompt devient plus long, plus rigide, et parfois moins fiable que la version simple qu’il était censé améliorer.

Pourquoi surcharge-t-on les prompts ?

On surcharge les prompts parce qu’une règle ajoutée donne l’impression immédiate de reprendre le contrôle après une mauvaise sortie.

Le réflexe est très courant chez les développeurs, les product builders, les équipes data et les équipes automatisation. Le modèle répond mal, alors on ajoute une contrainte. Il oublie un format, alors on ajoute un exemple. Il sort du cadre, alors on ajoute une interdiction. À court terme, cela corrige souvent le cas visible. À moyen terme, le prompt devient une accumulation de rustines, difficile à relire, difficile à tester et parfois contradictoire.

Trois causes reviennent souvent.

• La réaction naturelle aux erreurs. Quand une sortie est mauvaise, le premier réflexe consiste à corriger localement. On traite le symptôme, pas le système. Au lieu de revoir l’objectif, les données fournies, le format attendu ou les critères de validation, on ajoute une phrase de plus.
• L’héritage des modèles plus faibles. Avec des modèles comme GPT-3, il fallait souvent davantage de scaffolding. Ce terme désigne une structure de guidage assez lourde : étapes imposées, exemples multiples, consignes détaillées, garde-fous répétés. Cette approche était parfois nécessaire, mais les modèles plus récents comprennent mieux les intentions simples et les contextes courts.
• Le faux sentiment de contrôle. Un prompt très long paraît plus sérieux. Il donne l’impression que tout est prévu. En pratique, il peut devenir moins lisible, moins maintenable et moins cohérent. Plus il contient de règles, plus il augmente le risque de conflit entre consignes.

Un exemple simple suffit. Pour un assistant de support client, on peut finir avec un prompt qui contient ces instructions : “Sois concis”, “Explique en détail”, “Ne pose jamais de question” et “Demande une précision si nécessaire”. Chaque règle paraît raisonnable isolément. Ensemble, elles créent un problème. Si le client décrit mal son souci, faut-il poser une question ou respecter l’interdiction ? Si la réponse nécessite une explication technique, faut-il être concis ou détaillé ? Le modèle doit arbitrer, mais il ne sait pas toujours quelle consigne prime.

Le problème n’est donc pas la longueur en soi. Un prompt long peut être utile s’il est clair. Le vrai problème, c’est l’absence de hiérarchie entre l’objectif, le contexte, les contraintes et les critères de validation.

Comment les prompts trop précis nuisent-ils ?

Les prompts trop précis nuisent parce qu’ils diluent l’intention, créent des contradictions et empêchent le modèle de s’adapter aux cas non prévus.

Instructions contradictoires. Un LLM, pour Large Language Model, est un modèle statistique entraîné à prédire la réponse la plus probable selon le contexte fourni. Il ne devine pas toujours quelle consigne doit passer avant les autres. Si vous demandez une réponse “très courte”, “très détaillée”, “créative” et “strictement factuelle” dans le même prompt, le modèle doit arbitrer entre des objectifs incompatibles. Résultat : la sortie varie, parfois fortement, d’un essai à l’autre.

Intention diluée. Un prompt verbeux peut noyer l’objectif principal dans des détails secondaires. C’est le même problème qu’une spécification produit mal priorisée : si tout est au même niveau, rien n’est vraiment prioritaire. Le modèle reçoit beaucoup de signaux, mais peu de hiérarchie. Il peut alors respecter une contrainte de style mineure tout en ratant la vraie demande métier.

Templates rigides. Un format strict aide pour une extraction structurée, par exemple récupérer un nom, une date et un montant dans une facture. Mais il devient nocif quand la tâche demande du jugement : analyse, diagnostic, synthèse, comparaison. Dans ces cas, le modèle doit choisir le bon angle selon le contexte. Un template trop verrouillé force une réponse mécanique, même quand le sujet exige une nuance ou une exception.

Maintenance difficile. Un prompt sur-construit devient vite un mini-logiciel sans tests, sans versioning clair et sans séparation des responsabilités. Chaque nouvelle règle peut entrer en conflit avec une ancienne. À force d’ajouter des rustines, personne ne sait plus quelle consigne produit quel effet.

Que faut-il mettre dans le prompt ?

Un bon prompt doit contenir l’objectif, le contexte utile, les contraintes prioritaires et le format attendu, sans transformer l’instruction en manuel de procédures. Plus le modèle comprend vite ce qu’il doit faire, moins il compense avec des suppositions.

Les bonnes pratiques publiques d’OpenAI et d’Anthropic vont dans ce sens : instructions claires, séparation des éléments, exemples seulement quand ils réduisent l’ambiguïté, puis tests sur plusieurs cas. Le point important n’est pas d’écrire plus. Le point important est de rendre la décision plus facile à prendre.

Voici un prompt trop chargé pour une classification d’avis client :

Classe cet avis client. Ne fais jamais d'erreur. Si le client parle de prix mais aussi de livraison, choisis prix sauf si la livraison est très négative. Si le ton est ambigu, sois prudent. Ne mets pas "autre" sauf si vraiment nécessaire. Ignore les fautes. Si le client utilise de l'ironie, détecte-la. Si plusieurs sujets sont présents, choisis le plus important. Ne réponds pas avec une phrase longue. Respecte toutes les règles précédentes. Avis : "{{avis}}"

Le problème saute aux yeux : trop de règles, pas de vraie hiérarchie, des exceptions subjectives comme “très négative” ou “vraiment nécessaire”. Une version simple tient mieux en production :

Objectif : classer l'avis client dans une seule catégorie.

Contexte : l'avis vient d'un site e-commerce.

Contraintes :
1. Utiliser uniquement ces catégories : "prix", "livraison", "qualite".
2. Si plusieurs catégories sont possibles, choisir celle qui correspond au problème principal.
3. Si le problème principal est impossible à déterminer, choisir la catégorie avec la confiance la plus faible.

Format : répondre uniquement en JSON valide avec ces champs :
{
  "categorie": "livraison",
  "confiance": 0.82,
  "raison": "Le client se plaint surtout du retard de livraison."
}

Avis : "{{avis}}"

Cette version est plus courte, mais elle n’est pas plus vague. L’objectif est clair, les catégories sont fermées, la règle de priorité est explicite et le JSON peut être lu directement par une API, n8n ou un script. Un prompt simple n’est pas un prompt pauvre. Il est plus court parce qu’il est mieux conçu.

Où placer la complexité utile ?

La complexité utile doit être placée dans l’architecture du système, pas empilée dans le prompt. Un prompt trop chargé devient fragile : il mélange les consignes métier, les règles de format, les exceptions, les contrôles qualité et parfois même la sécurité.

La bonne séparation des responsabilités évite ce piège. Le prompt sert à orienter le raisonnement ou la génération : ton, objectif, contexte, critères importants. Le code sert à valider, transformer, journaliser et sécuriser. Les tests servent à mesurer la qualité sur des cas connus. Les workflows d’automatisation servent à orchestrer les étapes : récupérer une donnée, appeler un modèle, vérifier la réponse, déclencher une action.

Cette logique compte beaucoup dans des outils no-code ou low-code comme n8n, où l’on relie des blocs visuels sans écrire toute l’application à la main. Elle compte autant dans une architecture classique avec API, base de données, files de messages et services applicatifs. Le principe reste le même : le prompt ne doit pas porter seul la fiabilité du système.

Cinq composants méritent d’être placés autour du prompt :

• Prétraitement : Nettoyer les données d’entrée, supprimer le bruit, harmoniser les dates, tronquer les textes trop longs.
• Routage : Choisir le bon modèle, la bonne instruction ou le bon workflow selon le type de demande.
• Post-traitement : Convertir la sortie en JSON, normaliser les champs, reformater une réponse pour un CRM ou une base de données.
• Validation : Détecter les erreurs de format, les champs manquants, les incohérences logiques ou les valeurs interdites.
• Évaluations : Comparer plusieurs versions de prompts sur un jeu de cas représentatifs.

Les évaluations, ou evals, sont simplement des tests réguliers. Elles mesurent si un modèle répond correctement sur des cas connus, au lieu de juger une sortie isolée au feeling. C’est la différence entre “ça a l’air bon” et “ça réussit 87 % des cas critiques sur notre jeu de test”.

Un plan simple suffit pour commencer :

• Étape 1 : Inventorier toutes les règles présentes dans le prompt actuel.
• Étape 2 : Supprimer les doublons et les consignes qui se contredisent.
• Étape 3 : Classer les contraintes par priorité : métier, format, sécurité, style.
• Étape 4 : Déplacer les contrôles déterministes dans le code, comme vérifier un email ou imposer un schéma JSON.
• Étape 5 : Créer un jeu de tests avec des cas simples, limites et franchement pénibles.

Et si le meilleur prompt était surtout mieux entouré ?

Le prompt engineering efficace ne consiste pas à écrire toujours plus de règles. La leçon amère appliquée aux LLM rappelle une idée simple : les modèles modernes exploitent mieux les instructions claires que les prompts surchargés, contradictoires et difficiles à maintenir. Le bon réflexe consiste à clarifier l’objectif, hiérarchiser les contraintes, tester les sorties et déplacer la complexité déterministe dans le système : code, validations, post-traitements, automatisations et évaluations. Vous gagnez alors en fiabilité, en lisibilité et en vitesse d’itération, sans dépendre d’un prompt fragile que personne n’ose modifier.

FAQ

• Qu’est-ce que la Bitter Lesson en IA ?
  La Bitter Lesson, formulée par Rich Sutton, explique que les approches générales qui tirent parti du calcul, des données et de l’apprentissage à grande échelle finissent souvent par dépasser les solutions très spécialisées conçues à la main. Appliquée aux LLM, elle invite à éviter les prompts sur-construits quand le modèle peut déjà comprendre une intention claire.
• Un prompt court est-il toujours meilleur ?
  Pas forcément. Un prompt court mais vague reste mauvais. L’objectif est d’écrire un prompt simple, clair et priorisé : objectif, contexte utile, contraintes importantes et format attendu. La simplicité vient de la conception, pas d’une limite arbitraire de longueur.
• Pourquoi les prompts trop longs deviennent-ils fragiles ?
  Ils accumulent souvent des règles ajoutées après chaque erreur. Avec le temps, certaines consignes se répètent, se contredisent ou masquent l’intention principale. Le modèle doit alors arbitrer entre des instructions de même niveau, ce qui peut produire des réponses instables.
• Que faut-il mettre dans le code plutôt que dans le prompt ?
  Tout ce qui est déterministe doit plutôt être géré par le système : validation de format JSON, contrôle de champs obligatoires, nettoyage de données, règles métier strictes, logs, alertes et post-traitements. Le prompt doit guider le raisonnement ou la génération, pas remplacer toute l’architecture applicative.
• Comment améliorer un prompt existant sans repartir de zéro ?
  Commencez par lister toutes les règles, supprimer les doublons, repérer les contradictions, classer les contraintes par priorité, puis tester plusieurs versions sur des cas réels. Si une règle peut être vérifiée par du code ou un workflow, sortez-la du prompt. Vous obtiendrez un système plus fiable et plus maintenable.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation no-code et low-code avec n8n, l’intégration de l’IA dans les processus métier, ainsi que le SEO et le GEO. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser vos usages IA, vos automatisations ou vos données business, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.