Combien de tours de correction faut-il à ChatGPT pour transformer un brief approximatif en livrable que votre client valide ? Avec 14 prompts éparpillés dans un Notion que vous ne relisez plus, la réponse change à chaque mission. Chaque tour de re-prompt est du temps non facturé.
Le prompt engineering ChatGPT consiste à écrire des instructions assez précises pour que la première sortie soit exploitable. Pour un freelance, cela revient à fixer un cadre stable par client, à montrer le format attendu par l’exemple et à vérifier chaque sortie avant envoi.
La référence, lue le 16 octobre 2026, reste le guide Prompt engineering d’OpenAI, qui sert de base aux recommandations citées plus bas. Il s’adresse aux développeurs de l’API et cite gpt-6-astra, GPT-5 et GPT-4.1. Chaque technique ci-dessous le traduit en livrable facturé, avec un prompt avant/après à copier.
Le system prompt comme contrat de mission
Dans l’API d’OpenAI, le message de plus haut niveau s’appelle developer message. Le guide précise que ces messages sont « prioritized ahead of user messages » : ils l’emportent sur ce que vous tapez ensuite. Dans l’interface ChatGPT, l’équivalent se loge dans les instructions personnalisées ou dans les instructions d’un Custom GPT. C’est votre system prompt. Le guide recommande aussi de le structurer en Markdown ou en balises XML avec quatre rubriques : identité, instructions, exemples, contexte. Pour un client, cela donne un fichier de 15 à 20 lignes, rangé dans un dossier Google Drive ou un Notion au nom du client. Le principe est le même côté Claude, où les instructions custom d’un projet jouent le rôle du system prompt.
Le doute habituel : écrire tout cela prend plus de temps que de corriger à la main sur une mission de quelques semaines. Un system prompt s’écrit une fois par client et sert à chaque livrable suivant.
Avant :
« Écris un article de blog sur la cybersécurité pour mon client. »
Après, à coller dans les instructions :
« Tu rédiges pour [client], éditeur SaaS de gestion de paie. Lecteurs : DRH de PME de 50 à 250 salariés. Ton : direct, vouvoiement, phrases de 20 mots maximum. Format : HTML propre avec h2 et paragraphes. Si une donnée chiffrée manque, écris [DONNÉE À SOURCER] à la place d’un chiffre inventé. »
Vous obtenez la même voix d’une session à l’autre, des balises sans retouche et des trous signalés au lieu d’être comblés. Sur une mission d’une heure, un prompt direct suffit. Le system prompt se justifie dès que le client reviendra.
Le rôle opérationnel
Avant : « Tu es un expert en marketing. Que penses-tu de ce budget ? »
Après : « Tu es consultant en acquisition payante pour des éditeurs SaaS B2B. Tu raisonnes en CAC et en payback. Tu refuses de recommander un canal sans seuil chiffré. Évalue ce budget : [budget]. »
« Tu es un expert en marketing » ne contraint rien. Un rôle utile fixe un domaine, une grille de lecture et un refus précis. En retour, des recommandations avec seuils au lieu d’un panorama. Un rôle ne donne aucune connaissance que le modèle n’a pas. Sur une traduction ou une reformulation, il n’apporte rien.
Zero-shot, few-shot et spécificité du prompt
Le zero-shot donne une consigne sans exemple. Le few-shot y ajoute des paires entrée/sortie. Le guide d’OpenAI recommande de fournir une poignée d’exemples d’entrées variées avec la sortie voulue, en général dans le developer message, plutôt que de recourir au fine-tuning. La consigne seule suffit quand elle est spécifique : elle nomme l’audience et chiffre la longueur.
Avant, en zero-shot :
« Résume cette réunion client en compte-rendu. »
Après, en few-shot :
« Rédige le compte-rendu de la réunion ci-dessous sur le modèle des deux exemples. Exemple 1, notes brutes : [notes] / compte-rendu validé : [compte-rendu]. Exemple 2, notes brutes : [notes] / compte-rendu validé : [compte-rendu]. Notes à traiter : [notes de la réunion]. Reproduis la structure et la longueur des exemples. »
Choisissez deux exemples différents l’un de l’autre (un compte-rendu court et un long) et ajoutez-en seulement si la sortie dérive. La longueur et les titres s’alignent alors sur ce que le client a déjà validé.
Quand le format est difficile à décrire en mots, comme un compte-rendu au gabarit maison ou une fiche produit à champs fixes, l’exemple décrit mieux que la consigne. Collez-les entre balises XML (par exemple <exemple_1> et <exemple_2>), comme le recommande le guide d’OpenAI pour délimiter les blocs d’un prompt.
Évitez le few-shot sur les textes créatifs : le modèle recopie les tournures des exemples. Chaque exemple consomme aussi des tokens à chaque appel.
Le chain-of-thought pour les analyses
Avant : « Pourquoi ma campagne Meta Ads sous-performe ? »
Après : « Voici les données de la campagne : [export]. Décompose le problème en sous-questions : audience, créa, offre, tracking. Réponds à chacune à partir des données seules. Termine par une recommandation priorisée. »
Le chain-of-thought demande au modèle d’exposer son raisonnement avant sa conclusion. Il aide sur les diagnostics et les arbitrages. Une nuance vient du guide d’OpenAI : les modèles de raisonnement génèrent déjà une chaîne de pensée interne et répondent bien à des consignes de haut niveau (« a senior co-worker », dit la page). Sur ces modèles, répéter « raisonne étape par étape » n’ajoute rien. Sur les autres, la consigne reste utile.
L’analyse obtenue se conteste ligne par ligne. Sur un email ou un post LinkedIn, laissez le raisonnement de côté : il dilue la sortie.
Les contraintes négatives
Avant : « Écris une introduction d’article sur le télétravail. »
Après : « Écris une introduction de 80 mots sur le télétravail. Commence par un fait daté. Interdits : « dans un monde où », « à l’ère du numérique », une introduction qui résume l’article, une liste à puces. »
Les contraintes négatives suppriment les tics qui trahissent un texte généré. Associez chaque interdit à ce qu’il faut faire à la place : ici, ouvrir sur un fait. L’introduction attaque directement. Gardez cette liste courte dans le system prompt. 30 interdits se contredisent et pèsent dans le context window.
Le bloc de contexte client
Le modèle ignore le positionnement de votre client, ses objections de prospects et ce qu’il a refusé par le passé. Le RAG manuel consiste à coller ce contexte dans le prompt, sans infrastructure. Le context window désigne la quantité de texte que le modèle lit en une fois : le guide d’OpenAI cite des fenêtres allant jusqu’à un million de tokens pour la famille GPT-4.1. La page tarifs actuelle distingue un contexte court (jusqu’à 272 000 tokens) d’un contexte long. Un bloc client de quelques centaines de mots tient très largement dedans. Ce qui coûte, c’est de le recoller à chaque session : placez-le dans le system prompt ou dans un fichier de projet ChatGPT.
Avant : « Écris un email de relance pour ce prospect. »
Après : « Client : [nom], logiciel de facturation pour artisans. Promesse : [phrase]. Objection fréquente : [verbatim]. Refus passés : [exemples]. Email validé précédemment : [texte]. Écris une relance de 90 mots pour [prénom du prospect], qui n’a pas répondu depuis [date]. »
L’email qui sort parle comme le client et reprend ses arguments. Ne collez jamais de données personnelles brutes dans ce bloc : voir la section confidentialité plus bas.
L’itération structurée
Corriger au fil de l’eau avec « refais en plus court » produit des versions qui changent trois choses à la fois. Une boucle courte évite cela :
- Lancez le prompt sur trois entrées réelles de la mission.
- Notez chaque défaut en une phrase : trop long, ton, donnée inventée.
- Corrigez un seul défaut par version.
- Relancez les mêmes trois entrées.
- Enregistrez la version retenue avec le modèle utilisé et la date.
Avant : « C’est trop long, refais. »
Après : « Garde la structure et le ton. Ramène le texte à 120 mots en supprimant les deux exemples chiffrés les moins utiles. Conserve la date de livraison. »
Tenez le registre dans un Google Sheets, une ligne par entrée de test et une colonne par version. Au bout de quatre versions sans convergence, le défaut vient de la consigne de départ. Réécrivez-la. Le gain se mesure ensuite en tours de correction évités sur la mission suivante : comptez-les avant et après.
Le prompt chaining pour les livrables longs
Le prompt chaining découpe une mission en étapes dont chaque sortie alimente la suivante. Une analyse concurrentielle de deux pages gagne à passer par quatre appels : extraction des faits, plan, rédaction, relecture critique. Vous repérez l’erreur à l’étape où elle apparaît.
Avant, en un seul prompt :
« Fais une analyse concurrentielle du marché des logiciels de paie pour PME avec des recommandations. »
Après, en chaîne. Étape 1 :
« Voici trois documents sources : [textes collés]. Extrais uniquement les faits datés. Sortie : un tableau avec les colonnes fait, source, date. N’ajoute aucune information absente des documents. »
Étape 2, avec le tableau en entrée :
« À partir de ce tableau seul, propose un plan en quatre parties pour une analyse destinée à un directeur marketing. Indique pour chaque partie les lignes du tableau utilisées. »
Les étapes 3 (rédaction) et 4 (relecture critique : « Liste les affirmations que le tableau ne soutient pas ») suivent le même principe. Chaque affirmation du texte final renvoie à une ligne du tableau.
Chaque appel relit le contexte, donc la facture en tokens augmente. Le guide d’OpenAI consacre une section au prompt caching pour limiter ce surcoût. Sur gpt-6.1-sol, un million de tokens d’entrée en cache coûte 0,10 $ contre 2,00 $ hors cache, soit 20 fois moins (page tarifs OpenAI, 16 octobre 2026). Un system prompt et un bloc client identiques d’un appel à l’autre sont les premiers candidats au cache. Sur une tâche courte, la chaîne est un luxe : un seul prompt bien cadré suffit.
Vérifier les sorties avant envoi
Un modèle invente avec le même aplomb qu’il informe : chiffres, dates, citations, noms de sources. Ce sont ces hallucinations qui vous engagent devant le client. Pour un article de 1 500 mots, le contrôle porte sur chaque chiffre avant l’envoi au client. Deux garde-fous se combinent. Le premier est le marqueur [DONNÉE À SOURCER] du system prompt. Le second est un prompt d’audit lancé après la rédaction :
« Relis le texte ci-dessous. Liste chaque chiffre et chaque citation, avec la date associée. Pour chaque élément, indique s’il figure dans les sources fournies (oui ou non). N’ajoute aucune information nouvelle. Texte : [texte]. Sources : [sources]. »
Sur gpt-6-luna, cet audit de 3 000 tokens en entrée et 1 000 en sortie coûte environ 0,0008 $ (calcul de la section tarifs). Vous contrôlez un inventaire au lieu de relire le texte en entier. L’audit du modèle peut lui-même se tromper. Chaque chiffre facturé au client se vérifie donc à la source, par vous. Ouvrez la page d’origine, repérez la phrase exacte et recopiez l’URL dans la colonne prévue : si vous ne retrouvez pas la phrase, le chiffre sort du livrable. Collez l’inventaire dans un Google Sheets avec une colonne « vérifié le » et une colonne « lien source ».
Confidentialité des données client
La CNIL, dans ses questions-réponses sur l’utilisation d’un système d’IA générative, indique que les utilisateurs finaux « ne devraient soumettre que des informations qu’ils sont autorisés à partager ». Pour un service grand public, elle conseille de « ne jamais partager d’informations confidentielles telles que des données personnelles ». Elle évoque aussi la possibilité de désactiver la réutilisation des données d’usage par le fournisseur.
Remplacez les noms par des codes ([CLIENT A], [PROSPECT 12]) et retirez les coordonnées avant tout collage. Le RGPD (règlement UE 2016/679) s’applique dès qu’un prompt contient des données personnelles. Selon votre contrat, vous pouvez agir comme sous-traitant de votre client au sens de ce règlement : relisez la clause sur les outils tiers. À valider avec votre client ou un juriste. La désactivation de la réutilisation des données se règle dans les paramètres de confidentialité de ChatGPT.
Choisir le modèle et estimer le coût en tokens
Un token est le morceau de texte que le modèle facture et lit. L’interface ChatGPT ne vous facture pas au token. Le coût compte dès que vous passez par l’API ou par un outil d’automatisation comme n8n ou Make. D’après la page tarifs d’OpenAI consultée le 16 octobre 2026, les modèles les plus récents se répartissent ainsi (tarif standard, contexte court, dollars par million de tokens) :
| Modèle | Entrée | Entrée en cache | Sortie | Usage suggéré |
|---|---|---|---|---|
| gpt-6-luna | 0,10 $ | 0,01 $ | 0,50 $ | Reformatage, tri, tâches de volume |
| gpt-6.1-sol | 2,00 $ | 0,10 $ | 10,00 $ | Rédaction courante, chaînes de prompts |
| gpt-6-astra | 10,00 $ | 1,00 $ | 50,00 $ | Analyses sensibles, relecture finale |
Exemple de calcul avec une requête de 3 000 tokens en entrée (system prompt, contexte client, exemples) et 1 000 tokens en sortie : environ 0,0008 $ avec gpt-6-luna, 0,016 $ avec gpt-6.1-sol et 0,08 $ avec gpt-6-astra. La colonne « Usage suggéré » relève d’un choix éditorial de cet article et ne vient pas d’OpenAI. Le guide d’OpenAI prend gpt-6-astra pour modèle dans ses exemples et rappelle que les modèles GPT demandent des consignes précises.
Les noms et les prix changent vite : la page tarifs du 16 octobre 2026 liste encore gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna à côté de la génération gpt-6. Épinglez la version utilisée dans vos livrables récurrents : le guide conseille de figer un snapshot daté (il cite gpt-4.1-2025-04-14 en exemple) et de bâtir des évaluations pour suivre un prompt d’une mise à jour à l’autre. Vos trois entrées de test de la section itération jouent ce rôle.
Une bibliothèque de prompts datée
14 prompts dans un Notion ne forment pas une bibliothèque. Une fiche dans Notion ou Airtable porte le client, le livrable, le modèle, la date de dernière validation et les trois entrées de test. Les défauts connus s’y ajoutent au fil des missions. Pour amorcer la bibliothèque, 100 prompts de contenu marketing fournissent des modèles à tester sur vos trois entrées.
Un prompt non daté finit par mentir sur le modèle qui l’a validé.
