Au-delà du prompting : les 4 disciplines qui multiplient par 10 tes résultats avec l'IA
#Tout le monde a appris le prompting. Presque personne n'a appris le reste.
Pendant deux ans, le prompting a été la compétence IA par excellence. Écrire le bon prompt, ajouter "pense étape par étape", structurer ses instructions avec des sections claires — c'était la recette pour obtenir de bons résultats d'un LLM.
Sauf que cette compétence est devenue le minimum syndical. Les modèles récents sont suffisamment intelligents pour interpréter des instructions approximatives. Et les systèmes IA ne sont plus des chatbots passifs : ce sont des agents multi-étapes avec des outils, de la mémoire et des sources de données externes.
Le résultat : deux personnes utilisant exactement le même modèle obtiennent des résultats radicalement différents. Pas parce que l'une formule mieux ses prompts — parce que l'une maîtrise des compétences que l'autre ignore complètement.
C'est la thèse défendue par Nate B. Jones, créateur de contenu spécialisé en implémentation IA : ce qu'on appelait "prompting" s'est scindé en 4 disciplines distinctes. La plupart des gens ne pratiquent que la première.
#Discipline 1 : le Prompt Craft — les fondations
Le prompt craft, c'est la base. C'est ce que tout le monde connaît : rédiger des instructions claires, structurées et précises pour un LLM.
Ça inclut :
- Le cadrage — donner un rôle ou un contexte au modèle
- La structuration — organiser ses instructions en sections logiques
- Les exemples — fournir des few-shot examples pour guider le format de sortie
- Le raisonnement — demander au modèle de réfléchir étape par étape (chain-of-thought)
Un bon framework pour calibrer ses prompts est le Goldilocks prompting : des prompts de 50 à 100 mots. Assez de direction pour cadrer la réponse, pas assez pour sur-contraindre le modèle.
Le prompt craft est une compétence nécessaire — mais ce n'est plus là que se joue l'écart de performance. C'est la table d'entrée, pas le facteur différenciant.
Le problème, c'est que beaucoup de praticiens s'arrêtent là. Ils optimisent leurs prompts mot par mot alors que le vrai levier est ailleurs.
#Discipline 2 : le Context Engineering — ce que l'IA sait
Le context engineering va au-delà de ce que tu demandes au modèle. Il concerne ce que le modèle sait au moment où il répond.
Le prompt que tu écris n'est qu'une fraction de ce que le LLM voit au moment de l'inférence. Le contexte complet inclut :
- Le system prompt
- L'historique de conversation
- Les documents récupérés dynamiquement (RAG)
- Les outils et leurs descriptions
- La mémoire entre sessions
- Les résultats d'appels d'API
Nate Jones décrit une architecture à deux couches :
| Couche | Ce qu'elle contient | Qui la contrôle |
|---|---|---|
| Déterministe | Prompts, bases de connaissances curées, instructions explicites | Toi — le développeur |
| Probabiliste | Résultats de recherche web, données RAG, sorties MCP | L'agent — de manière autonome |
Le point clé : quand un agent autonome tourne, ton prompt initial représente peut-être 0.1% de ce que le LLM traite réellement. Le reste vient de la couche probabiliste — les données que l'agent va chercher lui-même.
La qualité de tes résultats dépend donc moins de la formulation de ta question que de l'infrastructure d'information que tu as construite autour du modèle. Un CLAUDE.md bien structuré, des fichiers de règles modulaires, des connexions MCP pertinentes — c'est du context engineering en action.
La précision du contexte bat la compression du contexte. Obséder sur le nombre de tokens est moins utile que de s'assurer que chaque information fournie au modèle est pertinente et correcte.
#Discipline 3 : l'Intent Engineering — ce que l'IA veut
L'intent engineering est la discipline la moins connue — et potentiellement la plus importante. Elle ne concerne pas ce que tu demandes au modèle, ni ce qu'il sait, mais ce qu'il cherche à optimiser.
Le cas Klarna illustre parfaitement le problème. L'entreprise suédoise a déployé un système IA qui a géré 2.3 millions de conversations par mois et économisé 60 millions de dollars. Un succès spectaculaire, en apparence.
Sauf que l'IA optimisait ce qui était mesurable — la vitesse de résolution — plutôt que ce qui était stratégique : la fidélité client. Le CEO de Klarna a fini par réembaucher des humains parce que l'IA résolvait les tickets rapidement mais détruisait la relation client.
L'IA optimise ce que tu mesures, pas ce que tu veux. Si tes objectifs stratégiques ne sont pas encodés explicitement, le système optimisera les métriques les plus faciles à quantifier.
L'intent engineering consiste à rendre les objectifs, les valeurs et les arbitrages de ton organisation lisibles par la machine :
- Définir les priorités — qu'est-ce qui compte le plus ? Vitesse, qualité, fidélité ?
- Créer des boucles de feedback — comment le système sait-il qu'il avance dans la bonne direction ?
- Encoder les arbitrages — quand deux objectifs sont en conflit, lequel l'emporte ?
C'est la raison pour laquelle, selon le MIT, 95% des pilotes d'IA générative échouent — et selon Gartner, 40% des projets agentiques seront abandonnés d'ici 2027. Le problème n'est pas technique. C'est un problème d'intention : les systèmes ne savent pas quoi vouloir.
#Discipline 4 : le Specification Engineering — le plafond de qualité
La dernière discipline est celle qui sépare les projets qui fonctionnent des projets qui génèrent ce que Nate Jones appelle du "elegant garbage" — du code ou du contenu techniquement correct mais fondamentalement inutile.
Le specification engineering, c'est l'art de pré-encoder les exigences avant que l'agent ne commence à travailler.
Pourquoi c'est crucial ? Parce que les agents autonomes peuvent tourner pendant des heures sans intervention humaine. Impossible de corriger le tir en cours de route. Tout doit être spécifié en amont :
- Les cas limites — que se passe-t-il si l'utilisateur n'est pas connecté ? Si la base de données est lente ? Si l'API ne répond pas ?
- Les critères d'acceptation — comment l'agent sait-il que sa tâche est terminée et réussie ?
- Les contraintes de réversibilité — quelles actions sont annulables et lesquelles ne le sont pas ?
- Les dépendances — dans quel ordre les sous-tâches doivent-elles s'exécuter ?
| Approche | Résultat |
|---|---|
| Spec floue — "crée-moi une page de login" | L'agent produit quelque chose qui fonctionne techniquement mais ignore la gestion d'erreurs, l'accessibilité et les cas limites |
| Spec précise — critères d'acceptation, contraintes, edge cases | L'agent livre un résultat de qualité production parce que chaque décision a été prise en amont |
Les praticiens expérimentés posent les questions que les débutants oublient. Ils encodent les réponses dans la spécification avant de lancer l'agent. C'est la raison pour laquelle des équipes avec les mêmes outils livrent des résultats de qualité radicalement différente.
Dans un monde agentique, la compétence la plus valorisée n'est plus le coding — c'est la spécification. Les équipes qui spécifient bien livrent vite. Les équipes qui spécifient mal génèrent du déchet élégant.
#Pourquoi l'écart va se creuser
Ces 4 disciplines forment une pyramide. Chaque étage s'appuie sur le précédent :
La plupart des utilisateurs maîtrisent le niveau 1. Certains développeurs avancés pratiquent le niveau 2. Les niveaux 3 et 4 sont encore quasi inexistants en dehors des équipes les plus matures.
Avec l'arrivée d'agents de plus en plus autonomes — qui tournent pendant des heures, prennent des décisions et enchaînent des dizaines d'appels d'outils — la valeur migre inexorablement vers le haut de la pyramide. Un prompt parfait ne compense pas un contexte pauvre, une intention floue ou une spécification incomplète.
#Par où commencer concrètement
Tu n'as pas besoin de tout maîtriser d'un coup. Voici une progression pragmatique.
Prompt Craft — tu le fais probablement déjà. Continue à structurer tes prompts, utiliser des exemples et demander du raisonnement. Mais arrête d'y passer 80% de ton temps d'optimisation.
Context Engineering — commence par auditer ce que ton modèle voit réellement. Quand tu utilises Claude Code, ton CLAUDE.md, tes fichiers de règles et tes connexions MCP sont ton contexte. Quand tu utilises l'API, le system prompt, le RAG et les descriptions d'outils forment le contexte. Améliore ces éléments plutôt que de reformuler tes prompts.
Intent Engineering — la prochaine fois que tu déploies un système IA, écris explicitement ce qu'il doit optimiser. Pas juste la tâche, mais les arbitrages : "Priorise la satisfaction client sur la vitesse de résolution. En cas de doute, escalade plutôt que de deviner."
Specification Engineering — quand tu confies une tâche à un agent, pense comme un architecte. Liste les cas limites, définis les critères d'acceptation, identifie ce qui est réversible et ce qui ne l'est pas. Plus l'agent est autonome, plus la spécification doit être précise.
#Ce qu'il faut retenir
- Le prompting s'est scindé en 4 disciplines : Prompt Craft, Context Engineering, Intent Engineering et Specification Engineering
- La majorité des praticiens ne maîtrisent que la première — c'est la source de l'écart de performance 10x
- Le context engineering détermine ce que le modèle sait ; l'intent engineering détermine ce qu'il cherche à optimiser ; le specification engineering détermine la qualité plafond de ses résultats
- Avec des agents de plus en plus autonomes, la valeur migre vers la spécification — savoir formuler un prompt ne suffit plus quand l'agent tourne pendant des heures sans supervision
- Tu peux progresser dès maintenant : audite ton contexte, encode tes intentions, et spécifie tes exigences avant de lancer un agent
#Pour aller plus loin
- Nate B. Jones — The Only Prompt Engineering Guide You Will Ever Need détaille l'évolution du prompting vers les 4 disciplines
- Beyond the Perfect Prompt: The Definitive Guide to Context Engineering approfondit l'architecture à deux couches du contexte
- Klarna Saved $60 Million and Broke Its Company est le cas d'étude fondateur de l'intent engineering
- Le guide Anthropic sur le context engineering pour les agents reste la référence technique pour la discipline 2