Prompt engineering : la méthode pour obtenir de vrais résultats

« Résume-moi ce rapport. » Cette demande fonctionne, au sens où elle produit un texte. Elle ne produit presque jamais le résumé dont on avait besoin. Le prompt engineering, c'est tout ce qui se joue entre cette formulation et celle qui donne un livrable utilisable : pour qui, avec quel matériau, sous quelle forme, et avec quels interdits.

Cet article n'est pas une collection de prompts à copier. C'est une méthode : une structure réutilisable en six composants, un avant/après commenté sur une tâche réelle, cinq techniques qui changent effectivement la sortie, un tableau pour diagnostiquer un prompt qui ne donne rien, et quatre exemples adaptés à des tâches professionnelles courantes. Si vous souhaitez d'abord comprendre le fonctionnement des modèles, commencez par notre article sur l'intelligence artificielle générative.

Le prompt engineering, c'est quoi ?

La définition en une phrase

Le prompt engineering est la pratique qui consiste à formuler une demande à un modèle de langage de manière à obtenir, en une ou deux itérations, un résultat directement exploitable. En français, on parle d'« ingénierie de prompt » — terme correct, mais que presque personne n'utilise ni ne recherche.

La définition tient en une ligne ; l'essentiel est ailleurs. Il n'existe pas de formule magique ni de mot-clé secret. Un prompt est une instruction de travail. La compétence consiste à écrire des instructions complètes, comme vous le feriez pour un prestataire compétent qui ne connaît ni votre entreprise, ni votre dossier, ni vos habitudes de mise en forme.

Pourquoi la formulation change autant le résultat

Un modèle de langage produit la continuation la plus plausible de ce qu'on lui donne. Il ne devine pas les informations absentes : il les remplace par la moyenne de ce qu'il a vu. Si vous ne précisez pas le lecteur, il écrit pour un lecteur moyen. Si vous ne donnez pas de longueur, il produit la longueur habituelle du genre. Si vous ne dites pas ce que vous ne voulez pas voir, il inclut ce que les textes comparables contiennent d'ordinaire.

Chaque élément laissé implicite est donc comblé par une valeur par défaut. Un prompt vague ne donne pas un mauvais texte : il donne un texte lisse, correct et inutilisable, parce qu'il a été écrit pour personne en particulier. C'est exactement ce qui explique la déception fréquente après quelques semaines d'usage — l'outil n'est pas limité, la demande l'est.

Une limite doit être posée tout de suite : un bon prompt améliore nettement la qualité, il ne rend pas la sortie fiable. Un modèle peut inventer une donnée, une source ou un chiffre face à une instruction parfaitement écrite. La vérification reste à votre charge, et aucune technique de formulation ne la supprime.

Discipline technique ou compétence de tous les jours ?

Deux réalités portent le même nom. La première est un travail d'ingénierie : concevoir des prompts système, les versionner, mesurer leur effet sur des jeux de tests, les intégrer dans une application ou un automatisme. Elle concerne les équipes qui construisent des produits.

La seconde, qui concerne la grande majorité des professionnels, est une compétence de rédaction appliquée à un outil conversationnel. C'est celle que traite cet article. Ses principes valent quel que soit l'outil que vous utilisez au quotidien — ChatGPT, Claude, Gemini ou Mistral — parce qu'ils portent sur ce que vous devez dire, pas sur les particularités d'une interface. Le détail outil par outil se trouve dans notre panorama des outils IA et no-code.

L'anatomie d'un bon prompt

Un prompt exploitable contient six composants. Ils ne sont pas tous indispensables à chaque fois, mais en dessous de trois, le résultat redevient aléatoire. Voici le gabarit, à copier tel quel et à remplir :

• Rôle — Tu es [fonction précise] dans [type d'organisation].
• Contexte — Voici la situation : [ce qui a été fait, pour qui, avec quelles contraintes]. Voici le matériau : [texte, données, notes].
• Tâche — Ta mission : [un verbe d'action, un objet précis].
• Format attendu — Rends [structure exacte : nombre de parties, longueur, tableau, liste].
• Contraintes — N'utilise que les informations fournies. Évite [ce qui est proscrit]. Ton : [registre].
• Exemples — Voici un exemple du résultat attendu : [échantillon].

Le rôle

Le rôle ne donne aucune connaissance supplémentaire au modèle : il sélectionne un registre, un vocabulaire et un niveau de détail. C'est pour cette raison que « tu es un expert » ne sert à rien — c'est trop large pour orienter quoi que ce soit. « Tu es contrôleur de gestion dans une PME industrielle de 80 personnes » oriente réellement : le vocabulaire, les indicateurs cités, les objections anticipées.

Un rôle utile est un rôle spécifique. Si vous hésitez, décrivez la personne à qui vous confieriez la tâche dans votre organisation.

Le contexte

C'est le composant le plus rentable, et le plus souvent négligé. Le contexte répond à quatre questions : pour qui est le livrable, dans quel cadre il s'inscrit, ce qui a déjà été décidé ou tenté, et quelles contraintes de terrain existent.

Un réflexe change beaucoup de choses : coller le matériau source plutôt que le résumer. Si vous demandez une synthèse de compte rendu, collez le compte rendu. Si vous demandez une réponse à un client, collez son message. Chaque reformulation intermédiaire de votre part est une perte d'information que le modèle compensera par de la généralité.

La tâche

Une tâche est un verbe d'action appliqué à un objet précis. « Analyse ce document » ne dit rien : analyser selon quel axe, pour produire quoi ? « Identifie les trois objections récurrentes dans ces verbatims, puis propose une réponse argumentée pour chacune » est une tâche.

Une seule tâche par prompt. Deux demandes empilées dans un même message produisent presque toujours une réponse qui en traite une bien et l'autre à moitié.

Le format attendu

Décrivez la sortie comme vous décririez un gabarit : nombre de parties, présence ou non de titres, longueur en mots ou en signes, tableau plutôt que prose, liste plutôt que paragraphes. Le critère utile : la sortie doit pouvoir être collée dans son destinataire final sans remise en forme.

Le format est aussi ce qui rend un prompt réutilisable. Un gabarit de sortie stable permet de traiter dix dossiers successifs avec des livrables comparables entre eux.

Les contraintes

Les contraintes délimitent le périmètre : ce qu'il ne faut pas faire, ce qu'il ne faut pas inventer, quel ton éviter. C'est ici que se joue le principal levier contre les inventions du modèle. Une consigne du type N'utilise que les informations présentes dans le document fourni. Si une information est absente, écris « non précisé » au lieu de la déduire réduit sensiblement les affirmations fabriquées, sans jamais les éliminer complètement.

Les exemples

Un ou deux exemples du résultat attendu valent plus que trois lignes de description. C'est la technique que les ressources anglophones nomment few-shot prompting. Elle fonctionne parce qu'un exemple transmet simultanément la structure, le ton, le niveau de détail et la longueur — quatre choses difficiles à décrire.

Le point souvent manqué : l'exemple sert d'abord à montrer la forme. Un extrait d'un livrable que vous avez produit vous-même le mois dernier est un bien meilleur exemple qu'une description abstraite de ce que vous voulez.

Le même besoin, avant et après

Prenons une tâche réelle : produire un compte rendu de réunion client destiné à une équipe projet.

Avant. Fais-moi un compte rendu de cette réunion. [transcription collée]

Le résultat est un résumé chronologique fidèle, qui reprend l'ordre des échanges, mélange les remarques annexes et les décisions, ne distingue pas ce qui est arbitré de ce qui reste ouvert, et n'attribue aucune action. Il faut le relire intégralement et le réécrire pour l'envoyer.

Après. Tu es chef de projet dans une agence technique. Contexte : réunion de cadrage avec un client qui hésite encore sur le périmètre de la phase 2 ; l'équipe qui lira ce compte rendu n'était pas présente. Voici la transcription : [transcription collée]. Ta mission : produire le compte rendu destiné à l'équipe. Format : trois parties titrées — « Décisions actées », « Points encore ouverts », « Actions » ; la partie Actions sous forme de tableau avec les colonnes Action, Responsable, Échéance. 400 mots maximum. Contraintes : n'utilise que ce qui figure dans la transcription ; si un responsable ou une échéance n'est pas mentionné, écris « à confirmer » ; ne reformule pas les positions du client en les adoucissant.

Le résultat devient exploitable presque tel quel : la hiérarchie de l'information correspond à l'usage, les points non tranchés sont isolés au lieu d'être noyés, et les « à confirmer » signalent exactement les endroits à compléter. La différence ne vient d'aucun mot magique : elle vient de cinq informations que le premier prompt laissait au modèle le soin de deviner.

Pour voir ce gabarit appliqué de bout en bout, cette vidéo en déroule les composants sur des exemples concrets, en dix minutes.

Les techniques qui changent réellement le résultat

Une précaution avant de les détailler. Aucun de ces leviers n'est une règle absolue. Leur effet varie selon le modèle, la version, et la nature de la tâche, et les modèles évoluent vite : une consigne indispensable il y a deux ans peut être redondante aujourd'hui. Les exemples ci-dessous ont été formulés en juillet 2026 ; traitez-les comme des principes à tester sur vos propres cas, pas comme des recettes.

Donner des exemples

C'est le levier au meilleur rapport effort/résultat quand la forme compte, c'est-à-dire dans la plupart des tâches professionnelles. Deux exemples suffisent généralement à faire converger la sortie.

Voici deux réponses type que nous envoyons habituellement à ce genre de demande : [exemple 1] [exemple 2]. Rédige une réponse au message suivant en respectant la même structure et le même ton : [message].

Effet observable : la longueur, les formules d'ouverture et le niveau de politesse s'alignent, là où une description en prose du ton attendu donne des résultats instables.

Demander un raisonnement étape par étape

Connue sous le nom de chain of thought, cette consigne demande au modèle d'exposer les étapes intermédiaires avant de conclure. Elle est utile sur les tâches à plusieurs contraintes — un calcul, un arbitrage, une vérification de cohérence.

Avant de répondre, liste les critères que tu vas appliquer, évalue chaque option sur chaque critère, puis donne ta recommandation.

Deux nuances. D'abord, plusieurs modèles récents produisent déjà ce type de décomposition sans qu'on la demande ; la consigne devient alors surtout un moyen de rendre le raisonnement visible. Ensuite, c'est précisément ce qui la rend précieuse en contexte professionnel : un raisonnement affiché est un raisonnement auditable, où vous repérez l'endroit exact d'une erreur au lieu de constater une conclusion douteuse.

Découper une demande complexe

Un prompt qui demande d'analyser, de synthétiser, de rédiger et de mettre en forme dans le même message produit un résultat moyen sur les quatre. Le découpage en étapes successives, chacune validée avant de passer à la suivante, donne un résultat nettement supérieur — et vous laisse la main à chaque palier.

Concrètement : première demande, extraire les faits ; deuxième, les structurer ; troisième, rédiger à partir de la structure validée. Vous corrigez la structure avant qu'elle ne contamine 800 mots de texte. Lorsque cet enchaînement devient récurrent, il peut être outillé : c'est le terrain des agents IA, qui exécutent une suite d'étapes définies au lieu de répondre à un message unique.

Faire critiquer et reformuler par le modèle

Plutôt que de réécrire vous-même une sortie décevante, demandez son évaluation selon vos critères, puis sa réécriture.

Relis ta réponse et évalue-la sur trois points : les affirmations non appuyées par le document, les passages trop généraux, les répétitions. Liste les problèmes trouvés, puis propose une version corrigée.

Cette boucle a un intérêt secondaire : la liste des problèmes vous indique ce qui manquait dans votre prompt initial, et vous permet donc de l'améliorer pour les fois suivantes.

Fixer ce qu'il ne faut pas faire

Les interdits sont plus efficaces que les injonctions positives vagues. « Sois concret » ne veut rien dire pour un modèle ; « n'emploie aucun adjectif superlatif, aucune phrase d'introduction générale sur l'importance du sujet, et aucune conclusion qui résume ce qui vient d'être dit » produit un effet immédiat.

Constituez votre propre liste d'interdits à partir de ce qui vous agace dans les sorties que vous obtenez. Elle devient un bloc réutilisable dans tous vos prompts.

Diagnostiquer un prompt qui ne donne rien

Quand une sortie déçoit, le réflexe habituel est de reformuler la demande entière. C'est une perte de temps : chaque type de symptôme correspond à un composant manquant précis. Le tableau ci-dessous permet de corriger au bon endroit.

Le résultat est hors sujet

Neuf fois sur dix, la tâche contenait deux demandes. Relisez votre prompt et comptez les verbes d'action : s'il y en a plus d'un, séparez-les en deux messages. Vérifiez aussi que le verbe employé a un sens opérationnel — « travaille », « regarde », « occupe-toi de » n'en ont pas.

Le résultat est générique

C'est le symptôme d'un contexte manquant, jamais d'un modèle insuffisant. Testez rapidement : ajoutez uniquement le destinataire et la situation, sans rien changer d'autre. Si la sortie s'améliore nettement, vous avez identifié la cause et vous savez quoi compléter systématiquement.

Le résultat est inventé

Les inventions apparaissent surtout lorsque le modèle est mis en position de devoir répondre malgré une information absente. Deux corrections cumulables : restreindre explicitement le périmètre au matériau fourni, et autoriser le modèle à ne pas savoir. Une consigne qui prévoit une mention « non précisé » vaut mieux qu'une interdiction abstraite d'inventer. Aucune des deux ne rend la relecture facultative.

Le format n'est jamais respecté

Les descriptions de format en prose se perdent, surtout dans un prompt long. Montrez la structure au lieu de la décrire, placez-la en fin de prompt — ce qui est proche de la demande finale est mieux suivi — et donnez des repères vérifiables : « trois parties », « 400 mots maximum », « un tableau à trois colonnes ».

Ces symptômes se ramènent le plus souvent à quelques réflexes très répandus : cette vidéo revient sur les trois principaux, et sur la façon de les corriger.

Adapter sa méthode à ses tâches

Le gabarit ne change pas ; c'est la pondération de ses composants qui varie selon la nature de la tâche. Voici quatre familles de travail courantes, avec le composant à travailler en priorité et un prompt de départ.

Rédiger

Priorité aux exemples et aux contraintes de ton. C'est le cas où la description verbale échoue le plus systématiquement.

Tu es responsable marketing d'un éditeur de logiciels B2B. Contexte : nous publions une nouvelle fonctionnalité d'export comptable ; les lecteurs sont des directeurs financiers déjà clients. Voici deux de nos annonces précédentes, dont le ton nous convient : [exemple 1] [exemple 2]. Ta mission : rédiger l'annonce de la nouvelle fonctionnalité. Format : 250 mots, un titre, trois paragraphes, pas de liste à puces. Contraintes : aucun superlatif, aucun bénéfice non démontrable, pas de phrase d'introduction sur l'importance de la comptabilité. Informations à utiliser : [notes produit].

Synthétiser un document

Priorité aux contraintes de source et au format. Le piège est le résumé chronologique, fidèle mais inutile.

Tu es analyste dans un cabinet de conseil. Voici un rapport de 40 pages : [document]. Ta mission : produire la synthèse destinée à un comité de direction qui n'a pas lu le rapport et disposera de dix minutes. Format : cinq constats maximum, chacun en trois lignes, classés par importance pour une décision d'investissement ; puis une liste des points sur lesquels le rapport reste incertain. Contraintes : n'utilise que le contenu du rapport ; indique le numéro de page à l'appui de chaque constat ; n'ajoute aucune recommandation.

Analyser des données

Priorité au raisonnement explicite. Une conclusion chiffrée sans étapes visibles n'est pas vérifiable, et un modèle de langage n'est pas un tableur.

Tu es contrôleur de gestion. Voici les ventes mensuelles par région sur 24 mois : [données]. Ta mission : identifier les trois évolutions les plus significatives. Méthode : avant de conclure, indique les calculs que tu effectues et sur quelles lignes ; signale toute donnée manquante ou aberrante. Format : un tableau avec les colonnes Constat, Chiffres à l'appui, Interprétation prudente. Contraintes : ne fais aucune hypothèse sur les causes ; distingue clairement ce que les données montrent de ce qu'elles suggèrent.

Produire un livrable structuré

Priorité au découpage. Un cahier des charges, une trame d'atelier ou une proposition commerciale ne s'obtiennent pas d'un seul message.

Nous allons produire un cahier des charges en trois étapes. Étape 1, maintenant : à partir de ces notes d'entretien [notes], propose le plan détaillé — titres de parties et sous-parties, avec en une ligne ce que chacune contiendra. N'écris aucun contenu rédigé. Attends ma validation avant l'étape suivante.

Ces quatre familles ne couvrent pas tout. Pour un panorama des usages par outil et par type de tâche, notre guide sur comment utiliser l'IA générative complète cette méthode. Et lorsqu'un prompt structuré devient un réflexe hebdomadaire, la suite logique est de l'installer une fois pour toutes dans un assistant dédié plutôt que de le recoller : c'est l'objet de notre guide pour créer un custom GPT sur ChatGPT.

Le prompt engineering est-il un métier d'avenir ?

Ce que disent ceux qui l'annoncent condamné

L'argument est sérieux et mérite d'être pris au mot. Les modèles progressent, et une partie du travail de formulation qui était nécessaire hier ne l'est plus : ils demandent d'eux-mêmes des précisions, décomposent des tâches complexes sans qu'on l'exige, et tolèrent des demandes approximatives que les générations précédentes traitaient mal. Les artifices qui relevaient de la manipulation du modèle — enchaînements d'incantations, formulations censées débloquer des capacités cachées — perdent leur intérêt à chaque version.

S'ajoute une correction de marché. Les annonces de 2023 sur des postes de « prompt engineer » à rémunérations exceptionnelles décrivaient un moment très particulier, où très peu de personnes savaient faire fonctionner ces outils. Cette rareté a disparu. Le prompt engineering est en train de devenir ce que la maîtrise d'un tableur est devenue : une compétence attendue plutôt qu'un intitulé de poste.

Ce qui restera quoi qu'il arrive

Le raisonnement s'arrête toutefois trop tôt. Ce qui disparaît, ce sont les astuces liées aux limites d'un modèle donné. Ce qui reste est d'une autre nature : savoir formuler ce que l'on attend, fournir le contexte pertinent, définir un format de livrable, et juger si le résultat est bon. Aucune de ces quatre choses n'est un problème technique. Ce sont des compétences de cadrage, et aucun progrès de modèle ne peut deviner à votre place le destinataire de votre note ou l'arbitrage implicite que vous avez déjà rendu.

Le déplacement le plus probable n'est donc pas une disparition mais un changement d'échelle. À mesure que les usages passent de la conversation ponctuelle à des enchaînements automatisés, la formulation cesse d'être jetable : un prompt intégré dans un processus est exécuté des centaines de fois, ce qui fait de sa précision, de ses garde-fous et de sa vérifiabilité un vrai sujet professionnel. La compétence ne se dilue pas ; elle change de support.

Reste la conclusion pratique : cette compétence s'acquiert par la répétition sur des cas réels, pas par la lecture. Si vous voulez la construire dans le cadre d'un parcours structuré, sur vos propres tâches et avec un accompagnement, découvrez les formations d'Alegria.academy.