Prompt engineering : les bases qui marchent (sans être ingénieur)

On a collé « engineering » sur le fait de bien formuler une demande, et du coup tout le monde croit qu’il faut un diplôme pour parler à ChatGPT. C’est faux. Le prompt engineering, c’est l’art de cadrer une demande pour qu’un modèle de langage te donne ce que tu veux du premier coup — et 90 % du gain tient dans quatre réflexes que n’importe qui peut adopter en une après-midi. Cette page te donne ces quatre réflexes, les techniques qui marchent réellement (preuves à l’appui), et les mythes qui te font perdre ton temps. Pas de « formules magiques », pas de prompts à 2 000 mots vendus sur Gumroad. Juste le modèle mental correct, expliqué pour quelqu’un qui n’a jamais écrit une ligne de code.

La définition honnête : cadrer, pas incanter

Prompt engineering veut dire « ingénierie du prompt » — le prompt étant le texte que tu envoies à un modèle de langage (ChatGPT, Claude, Gemini). Définition courte et sans bullshit : c’est la pratique de formuler ta demande de façon à maximiser tes chances d’obtenir la bonne réponse.

Le mot « engineering » est trompeur. Il ne s’agit pas de coder ni de connaître des commandes secrètes. Il s’agit de faire ce qu’un bon manager fait avec un stagiaire brillant mais sans contexte : dire clairement quoi faire, donner les infos nécessaires, montrer un exemple, préciser le format attendu.

Pourquoi ça change quelque chose ? Parce qu’un LLM ne lit pas dans tes pensées : il prédit la suite la plus probable de ton texte. Si ton texte est vague, la suite probable est une réponse vague et générique — celle qui pourrait répondre à mille demandes différentes. Si ton texte est précis et cadré, tu déplaces la probabilité vers ta réponse. Tu ne « débloques » pas une intelligence cachée ; tu réduis l’ambiguïté.

Le « so what » : arrête de voir le prompt comme une formule à trouver, et vois-le comme un briefing à rédiger. Un mauvais prompt produit une réponse moyenne, pas parce que le modèle est bête, mais parce que tu lui as laissé trop de liberté sur ce que tu voulais.

Les 4 techniques qui marchent vraiment

Oublie les listes de 50 « hacks ». Quatre leviers expliquent l’essentiel de la différence entre une réponse médiocre et une réponse utile. Tous les guides officiels d’OpenAI et d’Anthropic tournent autour de ces quatre-là.

1. Le contexte — donne-lui ce qu’il ne peut pas deviner. Le modèle ne connaît ni ton entreprise, ni ton lecteur, ni ta contrainte. Au lieu de « écris un mail de relance », écris « écris un mail de relance à un client qui n’a pas payé une facture de 30 jours, ton ferme mais cordial, on veut préserver la relation, 5 phrases max ». La règle : chaque détail que tu omets, le modèle l’invente — et il l’invente vers la moyenne.

2. Les exemples (few-shot) — montre, ne décris pas. Montrer une ou deux fois le résultat attendu vaut mieux que dix lignes d’explication. C’est ce qu’on appelle le few-shot prompting : tu colles deux ou trois paires « entrée → sortie idéale » avant ta vraie demande. Cette capacité à apprendre d’une poignée d’exemples dans le prompt, sans réentraînement, est une propriété documentée des grands modèles depuis le papier fondateur d’OpenAI sur GPT-3 (Brown et al., 2020). Concret : tu veux classer des avis clients en positif/négatif/neutre ? Donne trois exemples classés avant de coller le quatrième. Le taux de réponses au bon format grimpe nettement.

3. Le rôle (et les instructions système) — pose le cadre une fois. Dire « tu es un avocat spécialisé en droit du travail français » oriente le vocabulaire, le niveau de détail et les angles de réponse. Attention au mythe (voir plus bas) : ça ne rend pas le modèle compétent, ça oriente son registre. Dans les outils, ce cadrage se met dans le system prompt — l’instruction permanente qui s’applique à toute la conversation, distincte de tes messages. C’est le bon endroit pour les règles stables (« réponds toujours en français, jamais de jargon »).

4. Le format de sortie — dis exactement ce que tu veux recevoir. Le levier le plus sous-estimé. « Réponds sous forme de tableau avec trois colonnes : risque, probabilité, mitigation. » « Donne-moi exactement 5 puces, une phrase chacune. » « Réponds uniquement par OUI ou NON, rien d’autre. » Plus la contrainte de format est explicite, moins le modèle part en roue libre — et plus la sortie est directement exploitable sans que tu la retravailles.

So what : la prochaine fois qu’une réponse te déçoit, ne réécris pas tout. Demande-toi lequel des quatre manque : contexte, exemple, rôle ou format. Neuf fois sur dix, c’en est un seul.

La structure d’un bon prompt (le squelette réutilisable)

Tu n’as pas besoin d’un template par tâche. Un seul squelette couvre l’immense majorité des cas. Empile, dans cet ordre :

1. Rôle / cadre — « Tu es [X]. » (optionnel mais utile)
2. Tâche — le verbe d’action précis : résume, traduis, classe, rédige, critique.
3. Contexte — qui, pour qui, contraintes, ton.
4. Le matériau — le texte, les données, le document à traiter, clairement délimité (« Voici l’avis client à classer : --- … --- »).
5. Exemple(s) — une à trois paires entrée → sortie, si le format compte.
6. Format de sortie — la forme exacte de la réponse attendue.

Deux principes qui font la différence et qu’on retrouve dans toutes les doc officielles :

• Sépare l’instruction du contenu. Délimite le texte à traiter (guillemets, balises, tirets) pour que le modèle ne confonde pas « ce que je dois faire » et « la matière sur laquelle je le fais ». C’est aussi une protection contre l’injection de prompt, où un document malveillant glisse une instruction.
• Préfère le positif au négatif. « Réponds en 3 phrases » marche mieux que « ne fais pas trop long ». Le modèle exécute mieux une consigne de ce qu’il doit faire que de ce qu’il doit éviter.

So what : garde ce squelette en note. Tu n’écriras plus jamais « fais-moi un truc sur X » — et tu verras la qualité décoller sans rien changer au modèle.

Une technique de pro accessible : « réfléchis étape par étape »

Une seule technique avancée mérite que tu la connaisses, parce qu’elle est gratuite et qu’elle marche : le chain-of-thought (« chaîne de pensée »).

L’idée, démontrée par une équipe de Google en 2022 (Wei et al.) : sur les problèmes qui demandent du raisonnement à étapes — un calcul, une déduction logique, un choix argumenté — demander au modèle de détailler son raisonnement avant de conclure améliore nettement la justesse. Concrètement, tu ajoutes « Raisonne étape par étape avant de donner ta réponse finale » ou « Explique ton raisonnement, puis conclus ».

Pourquoi ça marche ? Rappel du mécanisme : un LLM génère token par token. S’il doit cracher la réponse finale immédiatement, il « parie » sans avoir déroulé les étapes intermédiaires. En l’autorisant à écrire son raisonnement d’abord, tu lui donnes la place de poser les étapes qui mènent à la bonne conclusion — il s’appuie sur son propre texte au fur et à mesure.

Le piège à ne pas oublier : un raisonnement affiché paraît rigoureux, il ne l’est pas forcément. Le modèle peut produire une belle chaîne d’étapes et se tromper quand même, avec aplomb. Le chain-of-thought améliore les chances, il ne garantit rien — surtout sur les calculs exacts, où un vrai programme reste imbattable.

So what : pour toute tâche où la réponse demande de réfléchir (et pas juste de reformuler), ajoute « étape par étape ». C’est le meilleur rapport effort/gain du prompt engineering. Pour tout ce qui touche aux chiffres ou aux faits, vérifie quand même la conclusion à la source.

Les mythes à jeter à la poubelle

Le prompt engineering attire les vendeurs de poudre de perlimpinpin. Trois mythes coûtent du temps et de l’argent :

Mythe 1 : « Il existe un prompt magique secret. » Non. Il n’y a pas de séquence cachée qui débloque un mode « génie ». Il y a des demandes claires et des demandes floues. Les « packs de 1 000 prompts » vendus en ligne ne sont que des briefings pré-rédigés — utiles comme inspiration, mais tu fais aussi bien en appliquant le squelette de la section précédente. Méfie-toi de quiconque te vend une formule plutôt qu’une méthode.

Mythe 2 : « Dire ‘tu es un expert’ rend le modèle expert. » Le rôle oriente le style et le vocabulaire, pas la compétence. « Tu es un médecin » ne donne pas au modèle un savoir médical qu’il n’avait pas — ça le fait parler comme un médecin, ce qui inclut le risque de parler comme un médecin qui se trompe avec assurance. Le rôle est un réglage de registre, pas un upgrade de connaissances.

Mythe 3 : « Le prompt parfait élimine les erreurs. » Faux, et c’est le plus dangereux. Aucun prompt n’empêche un modèle d’halluciner — d’inventer un chiffre, une date ou une source qui sonne juste. Écrire « ne dis rien de faux » ou « sois factuel » aide à la marge et ne corrige rien. Un LLM optimise le plausible, pas le vrai ; ça reste vrai quel que soit ton prompt. Sur tout ce qui est chiffre, date, citation ou décision sérieuse : vérifie à la source, point.

So what : le prompt engineering améliore réellement tes résultats, mais dans une fourchette. Il ne transforme pas un modèle faillible en oracle. Garde tes attentes calibrées et tu ne te feras pas avoir.

Faut-il vraiment apprendre ça ? (la vue founder)

Pour un usage perso quotidien, les quatre réflexes de cette page suffisent à 95 %. Tu n’as ni à mémoriser du jargon, ni à suivre une formation à 500 €.

Mais si tu intègres l’IA dans un produit, le prompt engineering change de statut : il devient une brique de ton infrastructure. Le system prompt qui cadre ton assistant, les exemples que tu y glisses, le format que tu imposes — ça conditionne directement la qualité que voient tes utilisateurs et ta facture (un prompt plus long = plus de tokens = plus cher à chaque appel). Une nuance qui compte : à ce niveau, le prompt n’est qu’une couche. Pour faire répondre le modèle sur tes données, le bon outil n’est pas un prompt plus malin, c’est le RAG. Pour lui faire enchaîner des actions, c’est un agent IA. Le prompt est le cadrage ; il ne remplace ni l’un ni l’autre.

Dernier point qui fait gagner du temps : traite ton prompt comme du code. Garde-le versionné, teste-le sur une dizaine de cas réels avant de le déployer, et compare les versions au lieu de bricoler à l’instinct. C’est la différence entre « ça a l’air de marcher » et « ça marche, je l’ai mesuré ».

So what : le prompt engineering n’est pas un métier d’avenir mystérieux. C’est une compétence de base — comme savoir faire une recherche Google précise — qui prend une heure à acquérir et qui se rentabilise à chaque conversation. Le reste, c’est du marketing.