Les bonnes pratiques en matière de prompt engineering reposent sur quatre piliers : définir explicitement la tâche et ses contraintes, fournir au modèle le contexte et les exemples nécessaires, le laisser raisonner avant de répondre, et tester le prompt avec des données réelles avant sa mise en production. Tout le reste n'est que détail.
Considérez un prompt comme une fiche de mission que vous remettez à un prestataire extrêmement rapide, peu coûteux, mais qui prend chaque mot au pied de la lettre. Si vous écrivez « répare la porte », vous obtiendrez une porte qui s'ouvre, d'une manière ou d'une autre. Si vous précisez quelle porte, dans quel sens elle doit pivoter et quoi faire si le cadre est pourri, vous obtiendrez exactement le résultat souhaité. Il n'y a pas de seconde chance pour expliquer votre pensée : tout ce qui figure sur cette fiche constitue l'intégralité du brief.
C'est pourquoi les prompts ont une importance commerciale capitale. Un prompt est l'élément le moins coûteux à modifier dans une fonctionnalité d'IA, mais le plus coûteux à rater, car un mauvais prompt ne provoque pas d'échec immédiat. Il produit un résultat plausible. Quelqu'un, plus loin dans la chaîne, devra s'en apercevoir.
Cet article aborde les fondamentaux, les techniques permettant d'améliorer la qualité des résultats, les pratiques à standardiser au sein d'une équipe, les contrôles avancés tels que l'effort de raisonnement et les limites de jetons, ainsi que l'impact financier de la qualité des prompts. Il utilise la famille GPT-5 d'OpenAI comme exemple de travail (GPT-5.4 au moment de la rédaction), bien que ces pratiques soient transposables à tout grand modèle de langage doté d'une API comparable. Entrons dans le vif du sujet.
Développé par OpenAI, ChatGPT est un grand modèle de langage (LLM) entraîné sur un corpus textuel massif, ce qui lui permet de générer des réponses semblables à celles d'un humain. En termes simples : il prédit le jeton suivant dans une séquence, un jeton représentant environ les trois quarts d'un mot. C'est tout le secret, et cela a suffi à propulser cet outil auprès des professionnels de tous les secteurs imaginables.
Cela signifie-t-il que vous devez suivre chaque nouvelle version de modèle ? Non, et si vous avez observé le marché ces dix-huit derniers mois, vous savez pourquoi. OpenAI a retiré l'intégralité des gammes GPT-4 et GPT-4o début 2026 pour se concentrer sur la famille GPT-5 ; tous ceux dont le code contenait encore la référence en dur gpt-4-turbo l'ont appris à leurs dépens. Les noms des modèles changent plus vite que n'importe quel article ne peut le suivre. Concentrez-vous donc sur les trois spécifications qui déterminent ce que vous pouvez construire, plutôt que sur le nom de la version du trimestre :
La fenêtre de contexte, mesurée en jetons, définit la quantité de données que vous pouvez soumettre au modèle en une seule fois. Un modèle de pointe actuel comme GPT-5.4 dispose d'une fenêtre d'environ un million de jetons, soit plus de deux mille pages. C'est ce qui rend pratique le traitement de documents longs, comme le résumé d'un contrat ou l'historique complet d'un support, en un seul appel plutôt qu'en une chaîne d'appels. Surveillez toutefois les niveaux de tarification: sur les modèles à un million de jetons, tout ce qui dépasse environ 272 000 jetons d'entrée est facturé avec une prime pour l'ensemble de la session. Une fenêtre plus grande ne vous dispense donc pas de réfléchir à votre stratégie de récupération de données.
La date de coupure des connaissances est la date au-delà de laquelle le modèle ne possède aucune information. Chaque modèle en a une, et elle est toujours plus ancienne que vous ne le souhaiteriez. Tout événement postérieur à cette date doit être transmis au modèle via le prompt, par une recherche documentaire ou un appel d'outil. Un modèle répondant tranquillement à partir de données d'entraînement obsolètes est l'une des causes les plus fréquentes de réponses erronées données avec assurance. Vérifiez la fiche technique du modèle pour connaître la date exacte avant de vous y fier.
Le coût par jeton, facturé séparément pour l'entrée et la sortie, est désormais souvent segmenté selon la longueur du contexte et l'effort de raisonnement. GPT-5.4 coûte environ 2,50 $ par million de jetons en entrée et 15 $ par million en sortie pour un contexte court, avec une augmentation pour les appels à contexte long. Une variation de ces chiffres peut rendre un cas d'usage viable du jour au lendemain alors qu'il était trop coûteux. C'est précisément pour cette raison que vous devez recalculer le coût d'une fonctionnalité à chaque changement de gamme, et non une seule fois au lancement.
Une quatrième variable figurait autrefois aux côtés de ces trois-là ; elle se situe désormais au-dessus d'elles : l'intensité du raisonnement du modèle avant de répondre. Sur le Famille GPT-5 il s'agit d'un curseur (l'effort de raisonnement allant de nul au réglage maximal), qui effectue en interne ce que le prompt de chaîne de pensée ci-dessous demande à un ancien modèle d'exécuter à voix haute. Un effort plus important coûte plus cher par appel et ralentit la réponse. Lorsque la tâche nécessite réellement un raisonnement en plusieurs étapes, ce compromis est généralement avantageux et votre prompt est simplifié car vous n'avez plus besoin de définir les étapes. Lorsque ce n'est pas le cas, baisser le curseur permet de réaliser des économies.
Vérifiez Référence de l'API d'OpenAI pour obtenir les chiffres actuels avant de baser votre business case sur l'un d'entre eux. Ils évoluent chaque mois.
Le prompt engineering permet de transformer un modèle généraliste en un outil capable d'accomplir une tâche spécifique de manière fiable. Cette section explique ce dont il s'agit, pourquoi les prompts jouent un rôle aussi déterminant et ce qui motive le choix d'un prompt plutôt qu'un autre.
Le prompt engineering est le processus stratégique de conception et de rédaction de prompts visant à obtenir les réponses souhaitées d'un modèle comme ChatGPT. Il s'agit de définir les instructions et les données d'entrée qui contrôlent le comportement du modèle et déterminent la qualité et la pertinence des résultats obtenus.
Sa valeur réside dans la capacité à ajuster les réponses du modèle à une tâche précise sans modifier le modèle lui-même. Exprimez votre intention avec précision pour obtenir un résultat exact et contextuellement pertinent d'un système qui, autrement, répondrait à une question vague par une réponse vague. Posez une question vague, recevez une réponse vague. C'est aussi simple que cela.
Les prompts fournissent au modèle le contexte nécessaire pour produire une réponse pertinente et servent de point de départ à la conversation. Structurez clairement votre instruction et vous orienterez le modèle vers le résultat escompté.
Ceci est documenté dans les recherches d'OpenAI, et ne relève pas du simple folklore. Language Models are Few-Shot Learners, l'article sur GPT-3, a démontré que fournir quelques exemples concrets dans le prompt améliore considérablement les performances sur une tâche sans modifier les poids du modèle, et que ces performances augmentent avec le nombre d'exemples fournis. Des travaux antérieurs sur l'apprentissage multitâche non supervisé ont montré que ces mêmes modèles pouvaient accomplir des tâches pour lesquelles ils n'avaient jamais été explicitement entraînés, à condition que la tâche soit clairement énoncée dans l'entrée. Les modèles plus récents nécessitent moins d'exemples pour y parvenir, mais la conclusion demeure valable.
Comparez ces deux exemples :
Prompt 1
Résume ce ticket de support.
Prompt 2
Résume ce ticket de support en trois phrases à l'attention d'un ingénieur de niveau 2. Indique le domaine du produit, ce que le client a déjà tenté de faire et la prochaine action à entreprendre. Ne mentionne pas le ton du client.
Le second prompt fournit à l'ingénieur des éléments exploitables. Le premier ne propose qu'une paraphrase. Rien n'a changé, si ce n'est la précision.
Comprendre comment les prompts sont classés vous aide à les concevoir en fonction de la réponse que vous souhaitez réellement obtenir. Voici les principales catégories :
Quelques éléments déterminent la qualité, la pertinence et l'exactitude des résultats obtenus :
Le prompt engineering est un domaine en constante évolution ; attendez-vous donc à ce que les techniques ci-dessous évoluent au même rythme que les modèles.
Un prompt est l'interface entre un modèle généraliste et une tâche spécifique. Il contient la mission, le contexte que le modèle ne peut pas déduire, les contraintes de sortie et, lorsque cela est nécessaire, les exemples qui illustrent le résultat attendu. La précision de ces instructions est ce qui distingue un résultat exploitable par un ingénieur d'un résultat qui doit être réécrit. Les catégories ci-dessus constituent une liste de contrôle pour le type de réponse que vous sollicitez. Ces facteurs forment une liste de contrôle pour ce dont le modèle a besoin avant de pouvoir vous fournir un résultat.
Cinq techniques font l'essentiel du travail.
Des directives explicites améliorent la qualité des réponses de manière plus fiable que n'importe quel autre changement.
Prompt générique
Parle-moi de notre problème de taux d'attrition.
Prompt précis
Voici un tableau du taux d'attrition mensuel par segment de clientèle pour les 12 derniers mois. Identifie les deux segments ayant connu la plus forte augmentation, indique l'ampleur de cette hausse et liste trois questions que je devrais poser à l'équipe de compte avant de tirer des conclusions. Signale tout ce que les données ne permettent pas d'expliquer.
Le prompt générique renvoie une définition de l'attrition. Le prompt précis fournit un document exploitable en réunion.
Les contraintes sont des instructions supplémentaires qui façonnent le comportement du modèle et restreignent le champ des réponses acceptables. Vous voulez une procédure ? Demandez « un processus détaillé et séquentiel, avec chaque étape sur une ligne numérotée et aucune étape ne dépendant d'informations que le lecteur n'a pas encore ». Demandez simplement des « étapes » et vous obtiendrez un paragraphe contenant le mot « premièrement ».
Les contraintes constituent également la protection la plus simple et la plus efficace. Un prompt qui se termine par un état d'échec défini vous donne un résultat vérifiable par machine plutôt qu'une réponse inventée :
Résume la politique ci-jointe en 120 mots maximum, en anglais britannique, sous forme de texte simple sans puces. Si la politique n'indique pas de période de conservation, réponds exactement : NOT FOUND.
Le contexte est l'ajout le plus productif pour presque n'importe quel prompt. Comparez :
Prompt sans contexte
Rédige un e-mail concernant le retard.
Prompt avec contexte et résultat souhaité
Rédige un e-mail à un client dont la mise en service de l'intégration est retardée de deux semaines en raison d'une dépendance vis-à-vis de sa propre équipe informatique. Reconnais l'impact, indique la nouvelle date, nomme l'élément unique dont nous avons besoin de leur part pour tenir ce délai et propose un appel. Six phrases, pas de doubles excuses, anglais britannique.
Le second contient tout ce que le modèle n'aurait pas pu deviner. C'est là toute la technique. À vrai dire, la plupart des prompts qui « ne fonctionnent pas » sont simplement des prompts auxquels il manque cela.
Les questions de Système 1 suscitent des réponses rapides et instinctives. Les questions de Système 2 exigent un raisonnement réfléchi et détaillé. Combinez les deux dans un même flux de travail pour gagner en rapidité là où elle suffit, et en profondeur là où elle est nécessaire.
Un assistant de triage pour le support :
La requête Système 1 achemine le ticket en une fraction de seconde et pour une fraction du coût. La requête Système 2 est réservée aux tickets qui passent le triage, là où une mauvaise réponse coûte cher et où les jetons supplémentaires sont justifiés. Avec la famille GPT-5, cela correspond parfaitement à l'effort de raisonnement : acheminer avec un effort minimal, enquêter avec un effort élevé. Diviser un flux de travail de cette manière est généralement la plus grande source d'économie possible pour une fonctionnalité basée sur un LLM. À faire avant de chercher un modèle moins coûteux.
Le contrôle de la verbosité définit le niveau de détail et la longueur de la réponse, ce qui est crucial lorsque celle-ci doit tenir sur un écran ou dans un champ spécifique.
Verbosité faible
Donne-moi les étapes de déploiement sous forme de liste numérotée. Une ligne par étape, sans explication.
Verbosité élevée
Donne-moi les étapes de déploiement sous forme de liste numérotée. Sous chaque étape, explique ce qu'elle fait, de quoi elle dépend et ce qu'il faut vérifier avant de passer à la suivante. Pars du principe que le lecteur n'a jamais déployé ce service.
La même base de connaissances sert à la fois à un ingénieur expérimenté effectuant une mise à jour familière et à un nouvel arrivant qui le fait pour la première fois. La verbosité est la seule différence, et il s'agit d'une décision liée au prompt plutôt qu'au modèle.
Les techniques permettent d'améliorer un prompt unique. Les pratiques, elles, garantissent le bon fonctionnement d'une centaine de prompts au sein d'une équipe, malgré les mises à jour des modèles dont personne ne vous a averti.
Pour les fonctionnalités IA que nous déployons en production chez Imaginary Cloud, nous rédigeons nos prompts sous forme de spécifications en quatre parties. Nous appelons cela la « spécification de prompt », et c'est la structure qui sous-tend chaque exemple de cet article :
La quatrième partie est celle que les équipes négligent, et c'est précisément ce qui donne l'impression que le travail sur les prompts relève de la conjecture. Un prompt sans critères d'acceptation ne peut être ni relu, ni testé en régression, ni transmis à un autre ingénieur sans une discussion de vingt minutes. Le même échec se retrouve dans la dette technique en général : le travail sans définition de « terminé » s'accumule silencieusement jusqu'à ce que quelqu'un en paie le prix au pire moment possible.
Les bons prompts ne s'écrivent pas, ils s'itèrent. Examinez le résultat, ajustez, recommencez.
Itération 1 : Extrayez les points d'action de ce compte rendu de réunion. → le résultat inclut les décisions et les observations en plus des actions.
Itération 2 : Extrayez uniquement les points d'action. Un point d'action doit comporter un responsable et une échéance implicite. Excluez les décisions et les observations. → mieux, mais les responsables apparaissent sous forme de prénoms qui ne correspondent pas à l'annuaire.
Itération 3 : Extrayez uniquement les points d'action sous forme de tableau avec les colonnes Responsable, Action et Échéance. Faites correspondre chaque responsable au nom complet figurant dans la liste des participants. Excluez les décisions et les observations. Si aucune date d'échéance n'est indiquée, inscrivez À définir.
Trois essais ont permis de transformer un paragraphe en un tableau exploitable par un autre système. Conservez le même jeu de données au fur et à mesure : utilisez le même compte rendu de réunion pour chaque modification de prompt, afin de vérifier si la quatrième itération n'a pas compromis les acquis de la troisième.
Certaines tâches exigent une réponse unique et précise. D'autres nécessitent des options. Un assistant de rédaction qui propose un seul titre est moins utile qu'un assistant qui en propose six, tandis qu'un outil de synthèse de contrats qui génère six versions différentes n'est d'aucune utilité.
Générez six objets pour cet e-mail d'annonce de produit. Deux simples et factuels, deux axés sur les avantages, deux axés sur la curiosité. Moins de 60 caractères chacun. N'utilisez pas de points d'exclamation. Présentez-les sous forme de liste numérotée avec le style entre parenthèses.
Le prompt délimite le cadre. À l'intérieur de celui-ci, le modèle peut faire preuve d'autant d'inventivité que vous le souhaitez sans s'écarter de la consigne.
Un modèle ne peut pas connaître l'état de votre commande, vos niveaux de stock ou la météo du jour. Les appels d'outils et les intégrations d'API permettent de connecter la fiche de travail à des données en temps réel. Le prompt définit quand le modèle doit appeler l'outil et comment réagir en cas d'échec de l'appel :
Vous êtes un assistant de suivi de commande. Lorsqu'un client vous interroge sur une commande, appelez get_order_status avec la référence de la commande. Répondez uniquement à partir des valeurs renvoyées. Si la référence est manquante ou si l'appel échoue, demandez la référence au client. Ne tentez jamais d'estimer une date de livraison si l'outil ne l'a pas fournie.L'outil en lui-même est un code ordinaire :
def get_order_status(order_ref: str) -> dict:
response = requests.get(
f"https://api.example.com/orders/{order_ref}",
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=5,
)
response.raise_for_status()
data = response.json()
return {
"status": data["status"],
"carrier": data["carrier"],
"expected": data["expected_delivery"],
}Réponse générée : « La commande 4417 a été expédiée hier via DPD et devrait arriver le jeudi 12 mars. »
La valeur du modèle réside dans la division du travail. Les faits proviennent de votre système, la formulation du modèle, et aucun ne se substitue à l'autre.
L'API vous permet d'intégrer la même interaction dans votre propre produit :
from openai import OpenAI
client = OpenAI()
def ask(question: str, history: list[dict] | None = None) -> str:
messages = [{"role": "system", "content": SYSTEM_PROMPT}]
messages += history or []
messages.append({"role": "user", "content": question})
response = client.chat.completions.create(
model="gpt-5.4",
messages=messages,
temperature=0.2,
max_tokens=500,
)
return response.choices[0].message.contentLe prompt système contient les spécifications, l'historique contient la conversation, et temperature et max_tokens reflètent les décisions produit que nous détaillons ci-dessous. Une mise en garde importante : sur les modèles axés sur le raisonnement, temperature a moins d'impact que sur les modèles de l'ère GPT-4, et l'effort de raisonnement devient le paramètre clé. Considérez donc la valeur indiquée ici comme illustrative et vérifiez le comportement en consultant la fiche technique du modèle. Passer d'un tel extrait à une solution exploitable par vos clients est un processus plus long, que nous avons abordé dans un article dédié sur le passage d'un prototype IA à la production .
Lorsqu'un modèle intervient dans une décision concernant une personne, le biais ne relève plus seulement de la qualité, mais devient une question juridique. Prenons l'exemple d'un système utilisant un LLM pour résumer les réponses d'entretien pour un jury de recrutement. Ces étapes permettent de réduire les risques :
Plus les enjeux sont élevés, plus le principe de « l'humain dans la boucle » doit être réel plutôt que décoratif, et la rigueur reste la même, qu'il s'agisse d'un LLM ou de tout autre système. Lorsque nous avons conçu le Geo Matrix Decision Engine pour Aurora Analytica, un outil de planification de scénarios destiné aux équipes d'essais cliniques, l'objectif n'a jamais été que le logiciel semble convaincant. Il s'agissait de permettre à un analyste CRO d'examiner un résultat et de le vérifier avant qu'il n'influence une décision réelle lors d'un essai. Ce n'est pas une question de LLM (c'est un moteur de décision), mais c'est la raison pour laquelle le contrôle de validation figure dans nos spécifications de prompt : dans un environnement réglementé, un résultat qu'une personne ne peut pas vérifier constitue une responsabilité, quelle que soit la manière dont il a été généré. La même exigence s'applique à toute fonctionnalité basée sur un LLM qui atteint un client, un régulateur ou un contrat. Si vous travaillez dans un domaine réglementé tel que la santé ou le droit, notre équipe d'IA appliquée et d'apprentissage automatique considère l'évaluation comme une partie intégrante de la livraison, et non comme une phase ajoutée a posteriori.
L'ingénierie de prompts ressemble à un sujet artisanal, mais elle se traduit par une ligne budgétaire. Quatre chiffres permettent de convaincre un conseil d'administration :
Le délai de rentabilisation est la raison pour laquelle il faut se soucier de ces quatre points simultanément. Le travail au niveau des prompts est rapide, ce qui explique précisément pourquoi les équipes sautent les étapes qui ne le sont pas, pour ensuite passer les semaines économisées à gérer les incidents. Les choix de pile technologique liés à une fonctionnalité d'IA suivent le même schéma : le choix le moins coûteux au départ est rarement le plus économique sur trois ans.
Pour la famille GPT-5, le premier levier à actionner est l'effort de raisonnement, de nul au réglage le plus élevé. Un effort faible pour les tâches superficielles et à fort volume ; un effort élevé pour les rares appels où une erreur coûte cher. C'est le levier d'optimisation des coûts le plus efficace dont vous disposez.
La température contrôle toujours le caractère aléatoire là où il s'applique. Les valeurs faibles, comme 0,2, produisent des réponses ciblées et largement déterministes ; les valeurs plus élevées, comme 0,9, produisent des réponses plus variables et exploratoires. Le choix dépend de votre produit :
temperature=0.2: Extrayez les conditions de paiement de cette clause contractuelle et résumez-les en une seule phrase.temperature=0.9: Donnez-moi dix noms pour un outil interne qui rapproche les factures des bons de commande. Simple et mémorable plutôt qu'original.Tout ce qu'un client lira comme un fait doit être traité avec une température et un effort faibles. Tout ce parmi quoi une personne doit choisir peut se permettre les deux.
Les limites de jetons plafonnent la longueur de la réponse. Définir max_tokens permet de maintenir délibérément la sortie dans l'espace imparti et évite qu'une réponse trop longue ne soit tronquée en milieu de phrase dans une interface prévue pour trois lignes. Comme les jetons de sortie représentent la partie la plus coûteuse de la facture, limiter la longueur permet souvent de réaliser des économies plus importantes que de réduire l'entrée.
Le chaînage relie les prompts entre eux afin que chacun puisse faire référence aux entrées et sorties précédentes. C'est ce qui rend possible le travail en plusieurs étapes.
Un assistant d'intégration :
Le second tour dépend entièrement du premier. Le chaînage permet également de garder chaque prompt suffisamment court pour être relu par un collègue, ce qu'un prompt monolithique tentant d'effectuer les deux étapes ne permettrait jamais.
Adapter un prompt à un domaine consiste à intégrer son vocabulaire, ses contraintes et son profil de risque dans les instructions.
Un prompt général, Résume ce contrat, devient :
Vous assistez un avocat spécialisé en droit des affaires dans la relecture d'un contrat de fournisseur. Identifiez les clauses de résiliation, le plafond de responsabilité, les conditions de paiement et toute clause de renouvellement automatique. Citez le numéro de clause pour chacune d'elles. Si une disposition est absente, indiquez-le explicitement plutôt que d'en déduire une équivalence. Ne donnez aucun conseil juridique ni avis sur le caractère favorable des conditions.
La réponse est alors structurée de manière à ce que le relecteur puisse vérifier clause par clause :
L'adaptation au domaine ne concerne pas le ton. Il s'agit de la liste explicite des éléments à rechercher, ainsi que des instructions sur la marche à suivre en cas d'élément manquant.
Les utilisateurs font des demandes contradictoires, et un modèle qui résout la contradiction silencieusement se trompera inévitablement à certains moments.
Utilisateur : Donne-moi le chiffre d'affaires du dernier trimestre par région, mais uniquement pour les comptes entreprises, et inclus le pipeline.
Le chiffre d'affaires et le pipeline sont des mesures différentes, et « dernier trimestre » peut désigner le trimestre civil ou fiscal. Il faut donc demander au modèle de s'arrêter et de poser une question :
Si la demande est ambiguë, ne devinez pas. Posez une question de clarification et attendez.
Assistant : Souhaitez-vous que le chiffre d'affaires réalisé et le pipeline en cours apparaissent dans des colonnes distinctes, et le trimestre doit-il correspondre au T3 fiscal ou au T1 civil ?
Une fois que l'utilisateur a répondu, le modèle peut produire un résultat correct plutôt qu'un résultat simplement plausible. Intégrer cette étape de clarification dans le prompt empêche l'assistant d'inventer sa propre définition du « dernier trimestre » et de présenter des chiffres basés sur celle-ci avec assurance.
Le cours court de DeepLearning.AI Ingénierie de prompts ChatGPT pour les développeurs, enseigné par Isa Fulford et Andrew Ng, demeure l'introduction gratuite la plus claire pour les ingénieurs. Une remarque sur l'ancienneté : le cours a été enregistré avec GPT-3.5 Turbo, depuis retiré, considérez donc les spécificités du modèle comme datées ; les principes restent parfaitement valables pour la famille GPT-5. Voici ce que ce contenu apporte à chaque partie de la spécification de prompt, et où le travail en production nécessite d'aller au-delà de ce que couvre le cours.
Tâche : pourquoi les instructions précises surpassent les instructions courtes. Le premier principe du cours est de rédiger des instructions claires et précises, et sa correction la plus utile est qu'un prompt clair n'est pas nécessairement un prompt court. Deux de ses tactiques concernent la ligne de tâche. Délimiteurs marquent les différentes parties de l'entrée (triples guillemets, backticks, tirets, chevrons ou balises XML) afin que le modèle puisse distinguer vos instructions du texte de l'utilisateur, ce qui réduit également le risque d'injection de prompt. Few-shot prompting fournit des exemples de la tâche réalisée correctement avant de demander la véritable exécution. Ce que le cours ne couvre pas, c'est où placer la ligne de tâche : dans un appel API, le message système contient le rôle et les règles permanentes, tandis que le message utilisateur ne contient que l'entrée de cette requête. Les équipes qui insèrent les règles permanentes dans le message utilisateur constatent une dérive de leur prompt.
Contraintes : sorties structurées et échecs vérifiables par machine. La deuxième tactique du cours consiste à demander une sortie structurée, comme du JSON. Demander poliment du JSON est une approche faible. Les API actuelles appliquent un schéma pour vous : un mode JSON qui garantit un JSON valide, ou sorties structurées où vous fournissez le schéma et où le modèle est contraint de s'y conformer. Si la sortie alimente un autre système, utilisez le schéma. Une erreur d'analyse détectée à la frontière vaut mieux qu'un prompt qui se conforme « généralement ».
Preuves et acceptation : vérifiez les hypothèses, puis testez le lot. La troisième tactique du cours consiste à demander au modèle de vérifier ses conditions en premier et de signaler celles qui ne sont pas satisfaites, le contrôle d'acceptation, déplacé à l'intérieur du prompt. Sa boucle itérative applique la même idée à l'extérieur du prompt : tenter, analyser la divergence, clarifier, affiner par rapport à un lot. Le lot est l'ensemble de tests, et c'est ce qui fait la différence entre un prompt qui fonctionne sur l'exemple que vous aviez sous les yeux et un prompt qui fonctionne sur les entrées que vous recevez réellement. C'est ici que notre pratique se distingue du cours : un prompt de cours est terminé lorsque la sortie du notebook semble correcte ; un prompt de production est terminé lorsqu'il réussit un ensemble de tests, possède un responsable désigné et une réponse claire à la question : « que se passe-t-il le jour où le modèle sous-jacent change ? »
Chaîne de pensée : laissez au modèle l'espace nécessaire pour raisonner. Le deuxième principe consiste à laisser au modèle le temps de réfléchir. Demandez les étapes de raisonnement avant la conclusion, ce qui évite au modèle de s'engager sur une réponse qu'il n'a pas encore élaborée. Les modèles de raisonnement effectuent désormais cette opération en interne, ce qui modifie l'aspect économique plutôt que le principe : pour ces modèles, demander explicitement les étapes augmente les coûts sans gain de précision significatif. Testez donc d'abord une requête simple et n'ajoutez une structure de raisonnement que si vos évaluations démontrent une réelle utilité.
Ce que les LLM maîtrisent : résumer, déduire, transformer, développer. Ce cours regroupe les cas d'usage quotidiens en quatre catégories, constituant un outil de tri réellement efficace. Résumer peut se concentrer sur une dimension spécifique plutôt que de compresser uniformément. Déduire permet de déterminer un sentiment, d'extraire des noms ou d'identifier des sujets sans entraînement spécifique à la tâche. Transformer (traduction, grammaire, ton, conversion de format) est la plus fiable de ces quatre fonctions, car l'entrée contient déjà la réponse. Développer transforme une entrée courte en un texte plus long et comporte le plus de risques, car le modèle ajoute des éléments absents de l'entrée initiale, ce qui est précisément là où les erreurs de fabrication surviennent. Adaptez votre évaluation en conséquence.
Le prompt engineering est la couche où se jouent la majeure partie de la qualité et du coût d'une fonctionnalité basée sur un LLM. Les techniques ne sont pas complexes : soyez précis, fournissez du contexte, contraignez la sortie, laissez au modèle l'espace nécessaire pour raisonner, et définissez délibérément l'effort et la longueur. Ce qui sépare les équipes qui déploient des fonctionnalités d'IA fiables de celles qui se contentent de démos, c'est le travail ingrat. Rédiger des prompts comme des spécifications avec des critères de validation. Maintenir un jeu de données de test composé d'entrées réelles. Relancer les tests lorsque le modèle sous-jacent change, ce qui arrivera inévitablement en 2026.
Revenons à ce comptoir. L'entrepreneur ne vous demandera pas ce que vous avez voulu dire, et un nouveau remplace l'ancien tous les quelques mois sans vous prévenir. Votre fiche de travail doit donc être exhaustive, et vous devez être en mesure de prouver que la précédente fonctionne toujours. Les prompts rédigés comme des spécifications survivent à cela. Les prompts rédigés comme des phrases chanceuses, non.
Juste assez pour lever toute ambiguïté, pas plus. Un prompt court n'est pas forcément un prompt clair. La plupart des prompts en production font plusieurs centaines de mots, car ils doivent intégrer la tâche, les contraintes, les cas d'échec et un ou deux exemples. Le coût de ces jetons est réel, mais dérisoire comparé au coût d'un résultat qu'une personne doit corriger.
En le cadrant et en lui fournissant une base de travail. Fournissez le matériel source dans le prompt ou via un système de recherche, demandez au modèle de répondre uniquement à partir de ce contenu, et donnez-lui une instruction explicite en cas d'échec, comme répondre « NON TROUVÉ » si la réponse n'est pas disponible. Réduisez la température et l'effort de raisonnement pour tout ce qui est factuel. Rien de tout cela n'élimine totalement les hallucinations, c'est pourquoi toute tâche importante doit faire l'objet d'une vérification humaine.
Oui, bien que moins en tant qu'intitulé de poste qu'en tant que pratique d'ingénierie courante. Les meilleurs modèles nécessitent moins de guidage, mais ils ne connaissent toujours pas vos données, vos contraintes ou ce que vos utilisateurs entendent par « dernier trimestre ». Définir une tâche avec précision et décrire ce qu'est une réponse correcte reste le cœur du travail.
Le prompt engineering modifie l'instruction. Le fine-tuning modifie le modèle en l'entraînant davantage sur vos propres exemples. Le prompting est plus rapide, moins coûteux et réversible, c'est donc la première étape logique. Le fine-tuning devient pertinent lorsqu'une tâche est à fort volume, très spécifique et suffisamment stable pour que les exemples ne deviennent pas obsolètes, et lorsque le prompting a atteint ses limites.
Constituez un jeu de test de vingt à cinquante entrées réelles avec les sorties attendues, exécutez le prompt sur l'ensemble de ces données et examinez les résultats globalement plutôt qu'un par un. Relancez ces tests à chaque modification du prompt et après chaque mise à jour du modèle. C'est le seul moyen fiable de savoir si une modification a amélioré le prompt ou si elle a simplement déplacé l'erreur vers un endroit que vous ne surveilliez pas.
Contrôler l'effort de raisonnement, la température et les limites de jetons pour gérer le coût, le caractère aléatoire et la longueur ; enchaîner les prompts sur plusieurs tours ; adapter les prompts à un domaine spécifique avec son vocabulaire et ses contraintes ; et gérer les entrées ambiguës ou contradictoires en demandant au modèle de poser des questions plutôt que de deviner.
Si vous vous demandez si un LLM a sa place dans un flux de travail spécifique, la première question à aborder concerne généralement le contrôle de validation plutôt que le modèle lui-même : à quoi ressemble un résultat correct, qui détecte les erreurs et quel est l'impact pour vous. Nos équipes spécialisées en science des données et en développement sur mesure intégrant l'IA travaillent avec nos clients sur ces points précis, de l'évaluation d'un cas d'usage jusqu'à sa mise en production. Si vous avez un projet en tête, contactez-nous et nous vous dirons en toute franchise si cela vaut la peine d'être développé.
Alexandra Mendes est spécialiste senior de la croissance chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction de textes sur le développement de logiciels, l'IA et la transformation numérique. Après avoir suivi un cours de développement frontend, Alexandra a acquis des compétences pratiques en matière de codage et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la façon dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
