Selon l'AI Index Report 2026 de Stanford HAI, 88 % des organisations utilisent désormais l'IA générative dans au moins une fonction métier. Le déploiement d'agents autonomes, lui, reste à un chiffre dans la quasi-totalité des fonctions, et les gains de productivité mesurés varient énormément d'un usage à l'autre : de 14 à 15 % dans le support client jusqu'à 50 % sur la production de contenu marketing. Le modèle utilisé n'explique pas cet écart à lui seul. Ce qu'on met dans le prompt, si.
Ce guide ne traite pas des astuces pour obtenir de meilleures réponses de ChatGPT en discutant. Il traite du prompt engineering tel qu'on le pratique quand un prompt doit tourner en production, dans un agent qui répond à de vrais utilisateurs sans supervision humaine sur chaque réponse. La précision, la structure et les tests comptent alors plus que n'importe quelle formule trouvée sur un forum.
Être précis change plus le résultat que n'importe quelle astuce
La règle la plus rentable du prompt engineering n'a rien d'exotique : être clair et explicite bat toute technique avancée. La documentation officielle d'Anthropic pour Claude résume ça par une règle qu'on applique telle quelle sur nos projets : montrer son prompt à un collègue qui n'a aucun contexte sur la tâche et lui demander de le suivre à la lettre. S'il hésite sur l'interprétation, le modèle hésitera aussi.
Concrètement, ça veut dire préciser le format de sortie attendu, les contraintes, et l'ordre des étapes quand l'ordre compte, plutôt que de laisser le modèle deviner. Demander de créer un tableau de bord produit un résultat générique. Demander un tableau de bord analytique avec un filtre par période, un export CSV et un graphique par indicateur, en gardant la même palette que le reste de l'application, produit un résultat qu'on peut livrer directement.
Un levier sous-estimé : expliquer la raison derrière une contrainte plutôt que de poser un interdit sec. Dire qu'une réponse sera lue à voix haute par un moteur de synthèse vocale qui ne sait pas prononcer les points de suspension fonctionne mieux qu'un simple "n'utilise jamais de points de suspension". Le modèle généralise à partir d'une raison mieux qu'à partir d'un ordre isolé. Sur un prompt système d'agent, cette différence se traduit par moins de cas limites où l'instruction est mal appliquée.
Le guide de prompt engineering d'OpenAI ajoute une nuance utile selon le type de modèle en face : un modèle de raisonnement se contente d'objectifs de haut niveau et travaille les détails lui-même, alors qu'un modèle généraliste a besoin d'instructions précises qui posent explicitement la logique et les données nécessaires. Mélanger les deux approches sur le mauvais type de modèle dégrade le résultat plus souvent qu'il ne l'améliore.
Le few-shot et les balises XML : structurer plutôt qu'écrire plus long
Quand une instruction textuelle ne suffit pas à cadrer le format de sortie, des exemples font le travail plus vite qu'un paragraphe d'explications supplémentaire. Cette technique, le few-shot ou multishot prompting, consiste à montrer deux à cinq exemples d'entrées et de sorties directement dans le prompt. La documentation Anthropic recommande entre trois et cinq exemples pour de meilleurs résultats, choisis pour être représentatifs du vrai cas d'usage et suffisamment variés pour ne pas faire apprendre au modèle un motif involontaire.
Le guide OpenAI recommande la même logique de structuration, avec des sections identifiées par des en-têtes ou des balises : identité, instructions, exemples, contexte. L'objectif est identique des deux côtés. Quand un prompt mélange consignes, contexte et exemples dans un seul bloc de texte, le modèle doit deviner où commence chaque partie. Des balises comme <instructions>, <context> ou <example> suppriment cette ambiguïté dès la lecture.
Sur un prompt système d'agent conversationnel, cette structuration change une chose très concrète au quotidien : la maintenance. Un prompt de plusieurs centaines de lignes en texte libre devient vite impossible à faire évoluer sans tout relire à chaque fois. Le même prompt organisé en sections balisées se modifie section par section, un avantage qui compte dès que plusieurs personnes touchent le même prompt dans la durée d'un projet.
Donner un rôle et bien gérer les documents longs
Fixer un rôle au modèle dès le prompt système oriente son ton et son comportement pour toute la conversation, même avec une seule phrase. Un agent chargé de répondre à des questions techniques ne se comporte pas comme un agent commercial, et le préciser explicitement évite d'avoir à corriger le ton réponse après réponse.
Le placement des éléments dans le prompt compte davantage qu'on ne le pense dès que le contexte devient long. Pour des entrées riches en données, au-delà d'environ 20 000 tokens, la documentation Anthropic recommande de placer les documents longs en haut du prompt et la question ou l'instruction tout en bas. Dans leurs tests internes, cet ordre améliore la qualité de réponse jusqu'à 30 %, en particulier sur des entrées à plusieurs documents. Un agent qui interroge une base de connaissances ou une documentation interne gagne directement à cette structuration.
Autre technique qui change la fiabilité sur des documents longs : demander au modèle de citer les passages pertinents dans une balise dédiée avant de produire sa réponse finale. Ça force le modèle à ancrer sa réponse dans le texte source plutôt que dans ce qu'il croit déjà savoir, et ça donne un moyen simple de vérifier la réponse a posteriori en relisant uniquement la citation retenue.
Découper la tâche plutôt que tout faire tenir dans un seul prompt
Un prompt qui essaie de tout faire en un seul appel, comprendre la demande, vérifier les données, rédiger la réponse et la mettre en forme, produit généralement un résultat moyen sur chaque étape plutôt qu'un bon résultat global. Découper la tâche en plusieurs appels distincts, chacun avec un objectif précis, donne un résultat plus fiable et surtout plus facile à déboguer : quand une étape rate, on sait laquelle.
Le schéma le plus utile en pratique reste l'auto-correction en trois temps. Un premier appel produit un brouillon. Un second appel évalue ce brouillon contre des critères explicites. Un troisième appel corrige à partir de cette évaluation. Chaque étape reste un appel API séparé, ce qui permet de logger et d'inspecter le résultat intermédiaire, un avantage réel quand un agent produit une réponse inattendue et qu'il faut comprendre à quelle étape le comportement a dérapé.
Cette logique de découpage s'applique aussi à la rédaction du prompt lui-même. Plutôt que d'écrire un prompt système monolithique de plusieurs centaines de lignes, le séparer en blocs testables indépendamment, rôle et identité, règles de sécurité, format de sortie, exemples, facilite la maintenance et limite le risque qu'une modification sur une règle vienne casser une autre partie du comportement.
Les pièges qu'on rencontre en vrai sur des agents en production
Sur les projets d'agents IA menés chez Noxcod, la même erreur revient souvent chez les équipes qui débutent en prompt engineering : sur-cadrer une instruction avec un langage trop autoritaire. Écrire qu'un modèle doit impérativement utiliser un outil dès qu'une condition survient fonctionnait bien sur d'anciens modèles, moins réactifs aux instructions. Sur les modèles récents, plus obéissants par défaut, la même formulation produit souvent l'effet inverse : l'outil se déclenche dans des situations où ce n'était pas nécessaire, ou le ton devient anormalement rigide. Une formulation neutre suffit largement et vieillit mieux d'une version de modèle à l'autre.
Deuxième piège fréquent : un prompt qui donne de bons résultats en démo et se dégrade en production parce qu'il n'a jamais été confronté à des cas limites réels. Un prompt qui gère bien la question type mais pas la question mal formulée, la demande hors périmètre ou l'utilisateur qui insiste après un refus, tient rarement plus de quelques semaines une fois exposé à de vrais utilisateurs.
Troisième piège, plus insidieux : changer de version de modèle sans revalider le prompt. Un prompt réglé finement pour un modèle donné peut se comporter différemment sur la version suivante, même quand l'éditeur annonce une simple mise à jour mineure. La réponse n'est pas d'éviter les mises à jour, mais de ne jamais les déployer sans repasser le prompt sur un jeu de tests avant de basculer en production.
Tester et versionner ses prompts comme du code
Un prompt qui pilote un agent en production mérite le même traitement qu'une fonction critique du code : versionné dans un dépôt git, avec un historique de modifications, et testé avant chaque changement. Concrètement, ça veut dire construire un jeu d'exemples représentatifs, avec la réponse attendue ou les critères de réussite pour chacun, et faire tourner ce jeu de tests à chaque modification du prompt, pas seulement au premier lancement.
Ce jeu de tests sert à deux moments distincts : quand on modifie le prompt soi-même, et quand l'éditeur du modèle diffuse une nouvelle version. Dans les deux cas, la question posée est la même, le comportement reste-t-il conforme à ce qu'on attend, ou un cas qui fonctionnait avant a-t-il silencieusement cassé. Sans ce filet, une régression sur un agent en production se découvre le plus souvent via une réclamation client plutôt que par un test.
Chez Noxcod, ce travail de développement sur mesure fait partie intégrante de la mise en place d'un agent IA. Le prompt n'est jamais livré comme un fichier texte figé, il est intégré dans un pipeline qui permet de le faire évoluer sans casser ce qui fonctionne déjà. Que l'équipe s'appuie sur un IDE avec IA comme Windsurf pour accélérer le développement ou sur un outil dédié comme Claude Code pour les tâches agentiques de code, la même discipline de test s'applique au prompt qui pilote l'agent final. Notre retour d'expérience sur la façon dont les équipes dev gagnent vraiment en productivité avec l'IA revient sur ce même constat : l'outil compte moins que la rigueur avec laquelle on l'intègre.
Si votre projet implique un agent IA qui doit répondre de manière fiable à de vrais utilisateurs, planifier un appel avec notre équipe permet de faire le point sur l'architecture de prompt la plus adaptée à votre cas avant de s'engager sur un développement complet.
Questions fréquentes
Le prompt engineering est-il un métier à part entière ?
Ça dépend du volume et de la criticité des agents IA en jeu. Pour une équipe qui construit et maintient plusieurs agents en production, la compétence mérite d'être portée par quelqu'un en continu, au même titre que les tests ou la supervision applicative. Pour un usage ponctuel, ça reste une compétence transverse à acquérir plutôt qu'un poste dédié à plein temps.
Faut-il tout réécrire quand un nouveau modèle sort ?
Pas tout réécrire, mais tout revalider. Un changement de version de modèle peut modifier subtilement le comportement d'un prompt réglé finement, même sans changement de votre côté. La bonne pratique consiste à faire tourner le jeu de tests existant sur la nouvelle version avant de basculer en production, puis à n'ajuster que ce qui a réellement changé de comportement.
Combien d'exemples faut-il mettre dans un prompt en few-shot ?
Entre trois et cinq exemples suffisent généralement, à condition qu'ils soient représentatifs du cas d'usage réel et assez variés pour couvrir les cas limites sans faire apprendre au modèle un motif involontaire. Au-delà, le gain devient marginal et le prompt devient plus coûteux et plus lourd à maintenir dans la durée.
Un bon prompt suffit-il à fiabiliser un agent IA en production ?
Non. Le prompt est une des couches, pas la seule. Un agent fiable combine un prompt testé, une gestion des erreurs quand le modèle ou un outil externe répond mal, une supervision qui détecte les dérives, et un circuit de remontée vers un humain quand la situation dépasse ce que l'agent peut traiter seul. Le prompt engineering améliore la qualité des réponses, il ne remplace pas l'ingénierie qui entoure l'agent.
Les techniques sont-elles les mêmes sur ChatGPT, Claude et Gemini ?
Les principes de base, clarté, exemples, structuration, découpage des tâches, s'appliquent aux trois. Les détails diffèrent : la structuration en balises XML est particulièrement mise en avant par la documentation Anthropic, tandis qu'OpenAI insère une hiérarchie explicite entre messages développeur et messages utilisateur. En pratique, un prompt bien structuré sur un modèle se transpose facilement sur un autre, avec quelques ajustements plutôt qu'une réécriture complète.
