Prompting : le guide complet 2026 (de débutant à expert)

En 2024, on se refilait des prompts « magiques » sur Twitter et on jurait que tel template débloquait ChatGPT. En 2026 c’est fini. Les modèles sont devenus assez bons pour que la différence entre un pro et un amateur ne se voie plus dans le choix du modèle, mais dans la structure du prompt. Depuis début 2024, j’ai accompagné plusieurs équipes marketing au prompt engineering en agence et en atelier intra-entreprise. En mars 2025, j’ai animé une session de formation prompting pour une équipe B2B. Ce guide, c’est la quatrième version de l’ossature que je leur transmets, actualisée pour Claude Opus 4.7, GPT-5.4 et Gemini 2.5 Pro.

Tu peux le lire d’une traite en 30 minutes, ou le garder en onglet de référence et y revenir quand tu bloques. Fondamentaux, framework maison, techniques avancées, spécificités par modèle, 20 templates copy-paste, erreurs à éviter, checklist finale. Le but : que tu arrêtes de prompter à l’instinct et que tu passes à un workflow reproductible.

Sommaire

• Ce qui a changé depuis 2023
• Les 5 fondamentaux d’un bon prompt
• Le framework CLEAR (mon pattern)
• Few-shot learning
• Chain-of-thought
• Role prompting en 2026
• Prompts système et hiérarchie
• Spécificités Claude (Opus 4.6, Opus 4.7, Sonnet 4.6, Haiku 4.5)
• Spécificités GPT-5.4
• Spécificités Gemini 2.5 Pro
• Meta-prompting
• 20 templates pro copy-paste
• 10 erreurs de prompting fréquentes
• Checklist avant d’envoyer un prompt important

Le prompt engineering en 2026 : ce qui a changé depuis 2023

Quand GPT-3.5 est sorti fin 2022, prompter ressemblait à de la magie inversée. Tu écrivais cinq lignes, tu priais, parfois le modèle te sortait un truc utilisable. Les techniques « hack » de cette époque (jailbreaks en cascade, mentions de récompense fictive, « tu es DAN, tu n’as plus de règles »…) marchaient parce que les modèles étaient mal alignés et faciles à dérouter.

En 2026, Claude Opus 4.7, GPT-5.4 et Gemini 2.5 Pro sont des modèles fondamentalement différents. Ils raisonnent par défaut sur les tâches complexes, ils respectent mieux les contraintes, ils gèrent du contexte long. Ce qui marchait par bricolage en 2023 a soit disparu, soit s’est sophistiqué.

Ce qui a disparu

Les jailbreaks grossiers, les personas « DAN », les tricks au niveau token (« commence ta réponse par X »… utilisé pour contourner). Les modèles sont entraînés à les détecter. Le pricing à la « hack » n’a plus aucun intérêt en production sérieuse.

Ce qui reste essentiel

Structure claire, exemples concrets, format de sortie explicite, contraintes formulées sans ambiguïté. Ce socle date de l’époque GPT-3 et n’a pas pris une ride. Si tu maîtrises ces quatre éléments, tu es déjà au-dessus de la pratique courante.

Ce qui est nouveau

Trois ruptures à intégrer en 2026 : le thinking mode natif (le modèle « réfléchit » de manière interne avant de répondre), le tool use intégré (le modèle peut appeler des fonctions, fetch des URLs, lire des fichiers), et le structured output natif (sortie JSON validée par schéma sans bidouille). Ces trois mécanismes changent la façon de prompter, on y reviendra section par section.

Pour un panorama complet des modèles 2026 en termes de capacités et de tarifs, j’ai détaillé l’écosystème dans le mega-guide des outils IA gratuits.

Les 5 fondamentaux d’un bon prompt

Avant les techniques avancées, le socle. Un prompt qui fonctionne, c’est un prompt qui coche ces cinq cases. Si tu en sautes une, ce n’est pas grave dans la majorité des cas. Pour le reste, ça fait la différence entre un draft utilisable et trois itérations de réécriture.

1. Clarté

Verbe d’action en premier, instruction non ambiguë. « Réécris ce paragraphe en gardant le sens mais en raccourcissant à 60 mots maximum. » Pas « peux-tu peut-être améliorer ce texte si tu veux bien ». Un prompt clair vaut mieux qu’un prompt poli.

2. Contexte

Qui tu es, pour qui tu écris, dans quel cadre. « Je suis chef de projet dans une boîte SaaS B2B, je m’adresse à mon équipe commerciale qui n’est pas technique. » Ce contexte n’a pas l’air de servir à grand-chose. Il sert pourtant. Sans contexte le modèle généralise ; avec contexte il personnalise.

3. Format attendu

Markdown, JSON, tableau, liste à puces, paragraphes. Dis-le. Si tu ne le dis pas, tu auras parfois un paragraphe, parfois un tableau, parfois cinq bullet points. La variabilité, c’est ce qui te fait perdre du temps en post-traitement.

4. Exemples

Au moins un exemple de ce que tu veux. Pour les formats non triviaux (un texte avec ton particulier, une structure de réponse spécifique, un classement), un exemple vaut mille mots d’instruction. C’est la base du few-shot, on y reviendra.

5. Contraintes

Longueur, ton, vocabulaire à éviter, niveau d’expertise du lecteur. « Pas de jargon. Pas plus de 300 mots. Tutoiement. Pas de phrases qui commencent par « Dans un monde de plus en plus connecté ». » Plus tu es précis sur les contraintes négatives, mieux le modèle filtre.

Une remarque qui revient à chacune de mes formations : « la question qui revient en premier chaque session, c’est comment ne pas sonner comme une IA quand on utilise une IA ». La réponse tient dans ces cinq fondamentaux appliqués proprement, plus une relecture humaine. Pas de raccourci miracle.

Le framework CLEAR (mon pattern personnel)

Les cinq fondamentaux ci-dessus, je les ai longtemps enseignés en vrac. En 2024, à force de répéter les mêmes choses en atelier, j’ai construit un acronyme pour les rendre mémorables : CLEAR. Ce n’est pas un framework breveté ni publié dans un papier académique, c’est juste mon pattern de formatrice. Mais il a tenu sur cinquante sessions et les retours sont stables, donc je le partage.

• Contexte — qui tu es, pour qui, dans quel cadre métier
• Limites — ce que le modèle doit ET ne doit PAS faire
• Exemples — au moins 1, idéalement 2 ou 3 pour amorcer du few-shot
• Action — verbe clair au début, sortie attendue concrète
• Rendu — format de sortie précis (markdown, JSON, tableau, liste)

Avant CLEAR

« Écris-moi un post LinkedIn sur l’IA générative en B2B. »

Résultat type : 250 mots fadasses qui auraient pu être écrits en 2023 par n’importe qui. Aucune accroche, structure mainstream, conclusion vide.

Après CLEAR

« Contexte : je suis CMO d’une scale-up SaaS française qui vend à des DSI de grandes entreprises. Mes prospects sont sceptiques sur l’IA générative et fatigués des promesses creuses. Limites : pas de buzzwords (transformation, révolution, paradigme), pas de structure « 3 raisons pour lesquelles… », pas de conclusion en « En somme ». Exemple de ton attendu : direct, contre-intuitif, 1 chiffre vérifiable, 1 anecdote terrain. Action : rédige un post LinkedIn de 180 à 220 mots qui prend à contre-pied l’idée que l’IA générative remplace les rôles seniors. Rendu : markdown, 4 paragraphes courts, première phrase en hook punchy. »

Le post sorti est immédiatement utilisable, ou nécessite une seule passe de retouche. Le temps gagné est massif quand tu enchaînes dix posts dans la semaine.

CLEAR n’est pas le seul framework qui existe. Tu trouveras RACE, CRAFT, RTF, RICE et d’autres variantes sur LinkedIn. Tous racontent la même chose. Prends celui que tu retiens, applique-le systématiquement, c’est ça qui compte.

Few-shot learning : quand et comment l’utiliser

Le few-shot, c’est donner au modèle quelques exemples d’entrée et de sortie avant de lui poser la vraie question. La technique est documentée depuis le papier GPT-3 (Brown et al., 2020) et n’a pas perdu en pertinence. Les modèles 2026 sont toujours sensibles aux exemples qu’on leur fournit.

Zero-shot vs one-shot vs few-shot

Zero-shot, tu balances la consigne sans exemple. Marche bien pour les tâches « générales » (résume ce texte, traduis en anglais). One-shot, tu donnes un exemple. Suffisant pour les formats simples non triviaux. Few-shot (3 à 5 exemples typiquement), tu cadres la sortie quand le format est spécifique ou que la nuance compte.

Comment structurer tes exemples

Trois critères : similaires (même type d’input que ce que tu vas envoyer pour la vraie question), variés (couvrir les cas limites, pas trois fois le même exemple), bien annotés (séparer entrée et sortie attendue avec des balises ou un format clair).

Le piège du « too many shots »

Au-delà de 5 ou 6 exemples, tu n’améliores plus rien et tu consommes du contexte pour rien. Pire, tu peux surcontraindre le modèle qui finit par recopier la structure de tes exemples sans saisir l’intention. Cinq exemples bien choisis valent souvent mieux que vingt exemples redondants.

Exemple concret : classer des tickets support

Tu veux classer des tickets support entrants en trois catégories (bug, demande feature, question commerciale). Tu donnes trois exemples : un ticket type bug clair, un ticket feature ambigu, un ticket commercial. Sortie attendue annotée. Le modèle classera ensuite tes 200 tickets quotidiens avec une précision élevée sans que tu aies besoin d’un classifier dédié. Coût marginal : zéro.

Chain-of-thought : faire « réfléchir » le modèle étape par étape

Le chain-of-thought (CoT) est la technique qui a fait la réputation des LLM modernes sur les tâches de raisonnement. Wei et al. ont publié le papier fondateur chez Google Research en 2022 (« Chain-of-Thought Prompting Elicits Reasoning in Large Language Models »). Le principe est simple : demander au modèle de détailler son raisonnement avant la réponse finale améliore significativement la qualité sur les tâches multi-étapes.

Le CoT classique

« Réfléchis étape par étape avant de répondre. » Cette phrase ajoutée à la fin d’un prompt complexe, c’était la magie pour GPT-3.5. C’est encore utile pour les modèles non-reasoning ou pour expliciter ce que tu attends.

CoT vs thinking mode natif

En 2026, la donne change. Claude 4.6 et 4.7 disposent d’un mode thinking (extended thinking sur 4.6, adaptive thinking sur 4.7 selon la doc Anthropic officielle). GPT-5.4 introduit des reasoning tokens avec des niveaux de profondeur. Gemini 2.5 Pro effectue automatiquement du thinking interne d’après la doc Google AI. Sur ces modèles, demander explicitement de raisonner étape par étape est souvent redondant. Tu actives le mode thinking via paramètre API, le modèle gère.

Cas où le CoT fait plus de mal que de bien

Tâches créatives courtes (titre d’article, accroche pub, slogan). Le raisonnement explicite dilue la spontanéité et tu obtiens un résultat plus pondéré, plus tiède, moins surprenant. Pareil pour les requêtes factuelles immédiates (« quelle est la capitale du Vanuatu »). Le CoT n’est pas une recette universelle, c’est un outil qu’on dégaine pour les vraies tâches de raisonnement.

Quand l’activer concrètement

Calculs complexes, problèmes logiques, analyse multi-critères, debugging de code étape par étape, choix stratégique avec plusieurs contraintes. Sur ces familles de tâches, l’écart de qualité entre avec et sans thinking est visible immédiatement.

Role prompting en 2026 : toujours utile ?

Pendant des mois, on lisait des conseils du type « commence par « Tu es un expert en X avec 20 ans d’expérience » et la qualité bondit ». C’était vrai en 2023 sur GPT-3.5. C’est devenu marginal en 2026. Les modèles modernes sont mieux alignés par défaut, ils n’ont pas besoin qu’on leur explique qu’ils doivent « être experts » pour répondre correctement.

Mon verdict tranché après deux ans à mesurer ça en formation : le role prompting est aujourd’hui surcoté. Quand tu le mets par réflexe, il apporte une part modeste de l’effet que tu crois. Les 70 % restants viennent du contexte précis et du format de sortie. Allouer ton attention en conséquence.

Ce qui marche encore

Persona très ciblée avec contexte métier précis. « Tu es éditrice spécialisée dans l’édition académique en sciences humaines, tu travailles depuis dix ans avec des chercheurs en sociologie qualitative. » Ce niveau de précision oriente vraiment le ton et les références. Le modèle calibre le vocabulaire, les références implicites, le niveau de prudence épistémique.

Ce qui ne sert plus

Les méga-formules génériques : « Tu es le meilleur expert mondial en growth marketing, tu as conseillé Google, Apple et Tesla. » Le modèle s’en fout, et toi tu ajoutes du bruit dans le contexte sans gain de qualité. L’effet du role prompting basique sur les modèles 2026 me paraît faible à modéré, mais à ma connaissance aucun benchmark public ne mesure ça spécifiquement — c’est un constat d’observation, pas un résultat chiffré.

Conseil opérationnel

Garde le role prompting quand tu cibles vraiment un métier précis avec un vocabulaire spécifique. Abandonne-le quand tu veux juste « du bon contenu ». Investis ce budget de tokens dans des exemples concrets, c’est dix fois plus rentable.

Les prompts système : structure, hiérarchie, XML tags vs blocs

La séparation entre system prompt (les règles persistantes) et user prompt (la requête du moment) est la deuxième chose à intégrer après les cinq fondamentaux. Tous les providers majeurs supportent cette distinction via leur API. C’est aussi le point où Claude, GPT et Gemini divergent dans leur style de prompting recommandé.

Pourquoi séparer system et user

Le system prompt définit qui est le modèle, ce qu’il doit toujours faire, ce qu’il ne doit jamais faire, le format de sortie par défaut, le ton, les guardrails. Le user prompt, c’est la requête spécifique du moment. Cette séparation a deux bénéfices concrets : tu peux réutiliser le system prompt sur des dizaines de conversations sans le retaper, et le modèle accorde plus de poids aux instructions système qu’aux instructions utilisateur (utile pour les guardrails).

Claude : syntaxe XML tags native

La doc Anthropic recommande de structurer les prompts longs avec des balises XML — tu choisis les noms de balises qui font sens (`<context>`, `<instructions>`, `<example>`, `<response_format>`, etc.) et tu y enveloppes les sections du prompt. Ce n’est pas une liste fermée de tags officiels, c’est la cohérence des noms qui compte. Le modèle est entraîné à reconnaître ces structures et à les traiter comme des sections distinctes. Sur des prompts longs (au-delà de 500 mots), c’est ce qui te sauve la vie. Je détaille le pattern dans le guide technique des system prompts.

GPT-5.4 : blocs markdown et hiérarchie

Côté OpenAI, la convention est plus markdown : titres avec `###`, sections séparées par lignes vides, listes à puces. Le system message est un champ dédié dans l’API (`role: system`). Tu peux y mettre du markdown structuré, ça fonctionne très bien.

Gemini : style direct, structures positionnelles

Côté Gemini, XML tags ou Markdown headers fonctionnent indifféremment, avec une règle d’or rappelée par la doc Google : placer le contexte volumineux en premier et la requête à la fin. Le modèle est sensible au placement dans le contexte long. C’est moins de la syntaxe que de l’architecture de prompt.

Spécificités Claude (Opus 4.6, Opus 4.7, Sonnet 4.6, Haiku 4.5) : prefill, thinking, XML

Claude est, à mon goût, le modèle qui récompense le plus le prompt engineering structuré. La doc Anthropic est probablement la plus dense de l’industrie sur le sujet, et les patterns sont systématiquement validés sur les modèles récents : Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5 (sources : platform.claude.com/docs).

Structurer avec des XML tags

Tu prends ton prompt long, tu identifies les sections (contexte, données fournies, instructions, exemples, format de réponse), et tu enveloppes chacune dans une balise XML choisie. Le modèle traite chaque bloc comme une zone sémantique distincte. Sur un prompt de 2000 mots, c’est la technique qui transforme la qualité de sortie.

Extended thinking et adaptive thinking

Sur Claude Opus 4.6 et Sonnet 4.6, le paramètre API est `thinking: {type: « enabled », budget_tokens: N}`. Tu fixes le budget de tokens « internes » que le modèle peut dépenser à raisonner avant de répondre. Sur Claude Opus 4.7, le mode manuel renvoie une erreur 400 — il faut utiliser `thinking: {type: « adaptive »}`, où le modèle décide lui-même de l’effort à allouer. Détail prix : tu paies les tokens de thinking complets, pas juste le résumé visible.

Prefill de la réponse assistant

Technique peu connue mais redoutable. Tu peux pré-remplir le début de la réponse du modèle. Concrètement : tu envoies un message `role: assistant` avec un début de texte (par exemple `{` pour forcer une sortie JSON, ou « Voici le résumé en trois points : ») et le modèle continue à partir de là. Garantit le format. Très utile en production pour éviter les variations de structure.

Tool use et prompting orienté agent

Claude est particulièrement à l’aise avec le tool use (function calling). Le pattern recommandé : décrire chaque outil dans le system prompt avec une section dédiée, donner un ou deux exemples d’usage, laisser le modèle décider quand appeler quel outil. Sur des workflows agentiques (lecture de fichiers, recherche web, exécution de code), Claude orchestre proprement.

Spécificités GPT-5.4 (reasoning, tool use, structured output)

Côté OpenAI, le pattern de prompting est moins « structuré » qu’avec Claude. Tu peux faire du markdown standard, le modèle s’en sort très bien. Les vraies spécificités sont du côté des paramètres API.

Reasoning tokens et niveaux

GPT-5.4 introduit des modes de raisonnement avec différents niveaux de profondeur (typiquement `low`, `medium`, `high` selon la doc OpenAI consultable sur platform.openai.com/docs). Plus le niveau monte, plus tu paies, plus la qualité monte sur les tâches de raisonnement. Sur une tâche créative simple, garde `low`. Sur du raisonnement multi-étapes, monte à `medium` voire `high`. La règle économique : commence bas, monte si la qualité ne suit pas. Vérifie le pricing exact au moment où tu lis ces lignes — il évolue.

JSON mode et structured output

OpenAI a poussé tôt le structured output natif via `response_format: {type: « json_schema », json_schema: {…}}`. Tu décris le schéma de sortie en JSON Schema, et tu reçois une réponse validée par le runtime OpenAI. Plus besoin de parser du markdown approximatif. C’est la fonctionnalité qui a poussé un grand nombre de devs à intégrer OpenAI dans des pipelines de production.

Function calling et tool use

Tu fournis un schéma de fonction (nom, description, paramètres typés), le modèle décide quand l’appeler. Pattern identique à Claude dans le principe, légères différences dans la syntaxe d’invocation. Si tu maîtrises l’un, tu maîtrises l’autre en quelques heures.

Custom instructions

Sur l’interface ChatGPT (pas l’API), tu peux définir des instructions persistantes qui s’appliquent à toutes tes conversations. Pratique pour le prompt-de-soi : « je suis growth marketeuse, je préfère les réponses concises avec exemples concrets, pas de prudence excessive ». Tu gagnes 30 secondes par requête, multiplié par 50 requêtes par jour.

Spécificités Gemini 2.5 Pro (long context, Google AI style)

Gemini 2.5 Pro est le modèle « long context » de référence du marché : sa fenêtre est de 1 million de tokens, ce qui en fait le candidat naturel quand tu dois ingérer un livre entier ou plusieurs heures de transcription. La doc Google AI précise les bonnes pratiques.

Exploiter le 1M de contexte sans saturer le modèle

Règle empirique : plus tu mets de contexte, plus le placement compte. Google recommande de placer le gros bloc de contexte en début de prompt et la requête à la fin. Le modèle a tendance à mieux suivre les instructions terminales sur des prompts très longs. Inverser ce placement dégrade la qualité même si toutes les informations sont présentes.

Le style « Google » de prompting

Plus direct, moins XML-isé que Claude. Markdown headers ou XML tags fonctionnent, mais le pattern Google insiste sur la précision et la concision des instructions plutôt que sur la structure visuelle. Les exemples few-shot sont fortement recommandés.

Multimodalité native

Texte, image, vidéo et audio sont des « inputs equal-class » d’après la doc officielle. Tu peux mettre une image et lui demander de l’analyser, ou uploader une vidéo et demander un résumé temporel. Sur des cas comme l’analyse d’un screencast de démo produit ou un brief vidéo client, Gemini est imbattable côté praticité.

Quand choisir Gemini par défaut

Long context massif (analyse de codebase, longs documents juridiques, archives), multimodalité fluide, prix compétitif sur les volumes. Pour comparer côte à côte avec ChatGPT, le comparatif ChatGPT vs Gemini détaille les cas d’usage.

Meta-prompting : faire générer des prompts par l’IA

Le meta-prompting, c’est demander à un modèle d’écrire ou d’améliorer un prompt pour toi. Tu lui décris ton objectif, ta contrainte, ton format attendu, et il te sort un prompt optimisé que tu pourras réutiliser. Cette technique a longtemps été considérée comme gadget, y compris par moi. Les ateliers récents m’ont montré qu’elle fait gagner du temps sur les tâches récurrentes — j’ai revu ma position.

Le prompt-de-prompt (méta-template)

Pattern type que j’utilise :

« Tu es un spécialiste en prompt engineering. Je vais te décrire un objectif, et tu vas me proposer un prompt optimisé que je pourrai ensuite copier-coller dans Claude ou ChatGPT. Mon objectif : [décris]. Mon audience : [décris]. Mon format attendu : [décris]. Contraintes : [liste]. Donne-moi le prompt final entre balises XML, suivi de 2 variantes d’A/B test et une suggestion d’optimisation. »

Quand ça marche

Tâches récurrentes qu’il faut industrialiser, optimisation d’un prompt existant qui fonctionne mal, exploration rapide de l’espace de solutions. En moins de cinq minutes tu obtiens trois versions à tester.

Quand ça foire

Tâches créatives uniques (un essai personnel, une fiction, un texte intime). Là le meta-prompting produit du générique parce qu’il optimise sur la moyenne, pas sur ta voix. Tâches très courtes (un slogan, un titre) : tu vas plus vite à itérer directement qu’à demander un prompt pour le faire.

Combiner avec l’automatisation via n8n ou Make

Dans un workflow d’automatisation où tu génères 50 variantes par jour, le meta-prompting initial te fait gagner du temps composé sur des mois.

20 templates pro copy-paste (par use case)

Les templates ci-dessous, je les utilise vraiment. Ce ne sont pas des squelettes vagues, ce sont des prompts testés en agence et en formation. Adapte les variables entre crochets à ton contexte. Tu peux aussi piocher dans la sélection complémentaire des meilleurs prompts ChatGPT du blog.

Marketing et Sales

1. Post LinkedIn B2B avec hook 3 points. « Tu rédiges pour [poste, secteur]. Cible : [audience LinkedIn]. Rédige un post de 180-220 mots structuré ainsi : hook contre-intuitif en 1 phrase, 3 points concrets numérotés, question d’engagement finale. Ton : direct, pas de buzzwords, 1 chiffre vérifiable ou 1 anecdote. Sujet : [sujet]. »

2. Réécriture landing page framework PAS. « Voici le texte actuel de ma landing page : [texte]. Réécris-la en suivant le framework PAS (Problem, Agitation, Solution). 3 sections distinctes en H2, 60-80 mots chacune. Vocabulaire concret, exemple chiffré dans la section Problem, témoignage fictif crédible dans la section Solution. Cible : [persona]. »

3. 10 sujets newsletter depuis une URL. « À partir du contenu de [URL ou texte collé], génère 10 sujets de newsletter. Format : titre accrocheur de 6-10 mots + sous-titre de 15-20 mots qui explique l’angle. Évite les titres en mode « 5 raisons de… ». Une seule colonne markdown. »

4. Analyse concurrent SWOT depuis site. « Voici le site de mon concurrent [URL ou texte scrappé]. Produis une analyse SWOT en tableau markdown. 4 colonnes (Forces, Faiblesses, Opportunités, Menaces). Sois précis : pas « communication efficace » mais « page produit avec 6 vidéos témoignages ». Conclus par 1 paragraphe sur ce qu’on peut leur piquer. »

5. 20 variantes ligne sujet email (A/B). « Cible : [audience]. Sujet général : [sujet]. Génère 20 variantes de ligne sujet. Mélange : court (3-5 mots), question, chiffre, urgence, curiosité, personnalisation. Tableau markdown avec colonne « angle » expliquant l’intention de chaque variante. »

Dev et Tech

6. Refactor avec explications. « Voici une fonction [langage] : [code]. Refactor-la en suivant ces principes : noms explicites, fonctions courtes (max 20 lignes), gestion d’erreurs, type hints. Fournis le code refactoré dans un bloc de code, puis sous le code une liste de 3-5 changements significatifs et pourquoi. »

7. Tests unitaires Jest/Vitest. « Voici une fonction [langage/framework] : [code]. Génère une suite de tests unitaires couvrant : cas nominal, 3 cas limites, 1 cas d’erreur. Framework : [Jest/Vitest/PyTest]. Mock les dépendances externes. Réponds avec uniquement le fichier de tests, prêt à coller. »

8. Documenter une API REST depuis le code. « Voici les routes d’une API : [code]. Génère la doc OpenAPI 3.1 en YAML. Pour chaque route : path, méthode, paramètres typés, request body schema, responses avec status codes, exemples. Pas d’explication en dehors du YAML. »

9. Debug structuré. « J’ai ce bug : [description précise + code + message d’erreur]. Avant de proposer une solution, pose-moi 3 questions diagnostiques qui te manquent. Ensuite seulement, propose 2 hypothèses ordonnées par probabilité, et la première étape à tester pour chacune. »

10. Code review structurée. « Voici un PR : [diff ou code]. Analyse-le sur 3 axes : bugs potentiels, performance, lisibilité. Pour chaque axe, donne 0 à 3 remarques classées par criticité (bloquant, suggestion, nit). Ne propose pas de réécriture, juste l’identification. »

Learning et Research

11. Résumé papier scientifique 3 niveaux. « Voici un abstract ou un papier court : [texte]. Produis trois résumés du même papier : ELI5 (5 ans, 60 mots, métaphore concrète), pro non-spécialiste (150 mots, vocabulaire grand public), expert (250 mots, méthodologie + résultats chiffrés + limites). »

12. Plan d’apprentissage 30 jours. « Je veux apprendre [sujet] en 30 jours. Mon niveau actuel : [débutant/intermédiaire]. Mon temps : [X minutes/jour]. Produis un plan jour par jour avec : objectif du jour, ressource recommandée (livre, vidéo, exercice), critère de validation (qu’est-ce que je sais faire à la fin du jour). Format tableau markdown. »

13. Concept par analogies progressives. « Explique-moi [concept technique] avec 3 analogies progressivement plus précises. Première : analogie pour un enfant. Deuxième : analogie pour un adulte non-spécialiste. Troisième : analogie pour quelqu’un de mon domaine ([ton domaine]). Conclus avec la définition rigoureuse en 2 phrases. »

14. 10 questions test compréhension. « Voici ce que je viens d’apprendre : [résumé ou texte]. Génère 10 questions qui testent ma compréhension. Mélange : 3 factuelles, 4 d’application, 3 de transfert (appliquer le concept à un cas nouveau). Réponses séparément en bas, format collapsible. »

Écriture et Créa

15. Adapter un texte à 3 tons. « Voici un texte : [texte]. Réécris-le en 3 versions de longueur similaire : formel/institutionnel, conversationnel/blog perso, punchy/punchline. Garde le sens identique, change seulement le ton. Précise pour chaque version 1 indice stylistique utilisé (ex: « phrase nominale, rythme ternaire »). »

16. Draft article depuis outline. « Voici mon outline d’article : [outline structuré]. Rédige le draft complet en suivant exactement la structure. Ton : [ton défini]. Longueur cible : [mots]. Pour chaque section, 1 anecdote concrète ou 1 chiffre. Pas de conclusion en « En somme ». Pas plus de 2 emdashes dans tout le texte. »

17. Révision en gardant ma voix. « Voici un de mes textes représentatif de ma voix : [exemple]. Voici un nouveau texte à réviser : [texte]. Améliore la clarté, la fluidité, et corrige les erreurs, mais conserve mon ton, mes tics de langage, mes structures de phrase. Ne réécris pas, ajuste. Liste à la fin les modifications majeures. »

Productivité et Ops

18. Prioriser to-do Eisenhower. « Voici ma to-do du jour : [liste de tâches avec contexte]. Classe-les selon la matrice Eisenhower (urgent/important). Pour chaque tâche, 1 phrase de justification du quadrant. Termine par 3 recommandations : laquelle faire en premier, laquelle déléguer si possible, laquelle reporter sans culpabilité. »

19. Préparer un 1-to-1 manager. « Je prépare un 1-to-1 avec [prénom du membre de l’équipe], poste [poste]. Contexte récent : [3-5 éléments factuels]. Génère : 3 sujets prioritaires à aborder, 4 questions ouvertes à lui poser, 1 sujet sensible à amener avec tact et comment l’amener. Format markdown structuré. »

20. Synthèse meeting depuis transcription. « Voici la transcription d’une réunion : [texte]. Produis une synthèse structurée : 3-5 décisions prises (avec qui décide quoi), 5-10 actions concrètes (avec owner et deadline si mentionné), 2-3 risques ou points ouverts. Pas de blabla, pas d’introduction, va droit au but. »

Les 10 erreurs de prompting qu’on voit chaque semaine

Ces erreurs, je les vois en formation, en agence, en réunion. Elles ne sont pas hiérarchisées par gravité. Elles sont juste fréquentes, et elles coûtent du temps.

1. Prompt trop court sans format ni contrainte. « Résume ça. » Le modèle te sortira parfois 50 mots, parfois 500, parfois un tableau, parfois un poème. Si tu ne précises rien, tu obtiens la moyenne du monde.

2. Tout en un seul paragraphe. Quand ton prompt fait 400 mots en un bloc continu, le modèle a du mal à hiérarchiser. Sépare visuellement (paragraphes, listes, sections nommées).

3. Dix instructions contradictoires. « Sois concis mais détaillé, professionnel mais drôle, technique mais accessible. » Tu vas obtenir du mou. Choisis. Si tu hésites, lance deux prompts et compare.

4. Oublier le format de sortie. Tableau, JSON, paragraphes, markdown, bullet list. Le défaut du modèle n’est jamais ce que tu voulais.

5. Ne jamais itérer. Le premier draft est rarement parfait. Trois passes ciblées (« réduis à 200 mots », « rends la troisième section plus concrète », « change le ton du paragraphe 2 ») battent une refonte complète le plus souvent.

6. Recopier un prompt « magique » trouvé sur Twitter. Les prompts magiques recopiés sont une perte de temps. Un prompt bien construit adapté à ton contexte bat un prompt magique générique 9 fois sur 10. Tu vas les voir circuler dans des threads, ne tombe pas dedans.

7. Surcharger le contexte. Mille mots de contexte pour une tâche simple. Tu noies le signal. La règle : autant de contexte que nécessaire, pas plus.

8. Ne pas tester sur plusieurs variations d’input. Un prompt qui marche sur ton premier exemple peut foirer sur trois autres. Avant d’industrialiser, tu testes sur 3 à 5 inputs différents au minimum.

9. Confondre role prompting et prompt système. Le role prompting (« tu es un expert en X »), c’est une ligne. Le prompt système, c’est l’architecture complète qui définit comportement, format, guardrails. Ce n’est pas la même couche.

10. Pas de critère de qualité explicite. « C’est bon » selon qui ? Définis avant de prompter : « le résultat est bon si X, Y, Z ». Sinon tu valides ce qui ressemble à ce que tu attendais, pas ce qui fonctionne.

Ta checklist avant d’envoyer un prompt important

Pour les prompts à enjeu (production, livrable client, contenu publié), je passe cette checklist mentale. Elle prend 30 secondes. Elle évite des heures de réécriture.

• ☐ L’action attendue est claire (verbe au début, sortie concrète décrite)
• ☐ Le modèle a assez de contexte (sans surcharge inutile)
• ☐ Au moins 1 exemple de sortie attendue si le format est non trivial
• ☐ Le format de rendu est explicite (markdown, JSON, tableau, paragraphes)
• ☐ Les contraintes critiques sont posées (longueur, ton, mots à éviter, niveau lecteur)
• ☐ J’ai choisi le bon modèle (Claude pour nuance et structure, GPT-5.4 pour raisonnement structuré et structured output, Gemini 2.5 Pro pour long context et multimodal)
• ☐ Thinking mode activé si la tâche demande de raisonner
• ☐ J’ai prévu au moins 2 itérations dans mon planning
• ☐ J’ai un critère de qualité défini avant d’envoyer le prompt
• ☐ Si la tâche est récurrente, je sauvegarde le prompt dans ma bibliothèque (Notion, fichier, Cursor rules, ce que tu veux)

Si tu coches ces 10 cases, tu as un workflow de prompting solide et reproductible. Le prompt engineering tient surtout d’une discipline méthodique. Et comme toute discipline, ça se travaille en répétant les bons gestes jusqu’à ce qu’ils deviennent automatiques.

Tableau comparatif des 3 grands modèles en mai 2026

Prix officiels mai 2026. Vérifier sur anthropic.com/pricing, openai.com/api/pricing, ai.google.dev/pricing.

Questions fréquentes sur le prompt engineering

C’est quoi le prompt engineering en 2026 ?

Le prompt engineering, c’est l’art et la discipline de formuler des instructions claires, structurées et adaptées au modèle IA pour obtenir la sortie attendue de façon reproductible. En 2026, ce n’est plus une astuce magique, c’est un savoir-faire pro qui repose sur 5 fondamentaux (clarté, contexte, format, exemples, contraintes), des frameworks comme CLEAR, et des techniques avancées (few-shot, chain-of-thought, meta-prompting, tool use). Les modèles modernes (Claude Opus 4.7, GPT-5.4, Gemini 2.5 Pro) récompensent une structure rigoureuse plutôt que des hacks de 2023.

Quelle est la meilleure technique de prompting pour ChatGPT ?

Il n’y a pas une technique, il y a une combinaison. Le socle : verbe d’action en début, contexte précis sur qui tu es et pour qui tu écris, format de sortie explicite (markdown, JSON, tableau), au moins un exemple si le format est spécifique, et contraintes négatives (« évite ceci »). Pour les tâches complexes, ajoute du few-shot (2-5 exemples) et active le mode reasoning de GPT-5.4 si le raisonnement compte. Si tu veux un seul template à retenir, prends le framework CLEAR décrit dans l’article : Contexte, Limites, Exemples, Action, Rendu.

Claude, GPT ou Gemini : lequel prompter ?

Ça dépend du cas. Claude (Opus 4.7 ou Sonnet 4.6) excelle sur les prompts structurés avec XML tags, les tâches longues nuancées, l’écriture qui demande du goût. GPT-5.4 brille sur le raisonnement explicite avec ses reasoning modes (low/medium/high), le structured output JSON natif, le tool use mature. Gemini 2.5 Pro est imbattable sur le long context (1M tokens), la multimodalité (image, vidéo, audio dans un même prompt), et un pricing souvent agressif sur le volume. En pratique, beaucoup de pros utilisent les trois selon la tâche. Le comparatif des meilleurs modèles IA détaille les choix par cas d’usage.

Qu’est-ce que le chain-of-thought prompting ?

Le chain-of-thought (CoT) est une technique de prompting popularisée par le papier de Wei et al. (Google Research, 2022) qui consiste à demander au modèle de détailler son raisonnement étape par étape avant de donner la réponse finale. Ça améliore significativement la qualité sur les tâches de calcul, de logique multi-étapes, ou d’analyse multi-critères. En 2026, les modèles récents (Claude 4.6/4.7, GPT-5.4, Gemini 2.5) intègrent un thinking mode natif qui rend le CoT explicite souvent redondant, voire contre-productif sur les tâches créatives courtes.

Comment écrire un prompt système efficace ?

Un prompt système efficace, c’est l’architecture des règles persistantes du modèle pour toute une session. Pattern qui marche : définir le rôle précis (pas générique), lister les guardrails (ce que le modèle ne doit jamais faire), spécifier le format de sortie par défaut, donner 1-2 exemples du ton attendu, fixer la longueur typique des réponses. Sur Claude, utilise des XML tags pour séparer les sections. Sur GPT, du markdown structuré marche très bien. Sur Gemini, place le contexte volumineux en début et la requête à la fin. Le guide technique des system prompts détaille les patterns avancés.

Combien de temps faut-il pour apprendre le prompt engineering ?

Pour le socle utilisable au quotidien (5 fondamentaux + framework CLEAR + savoir formuler un format de sortie clair), compte 3 à 5 heures de pratique active avec retour sur les sorties. Pour la maîtrise (few-shot, chain-of-thought, choix éclairé entre les modèles, tool use, meta-prompting), compte 20 à 40 heures de pratique répartie sur 2 à 3 mois. Le plus efficace : choisir un cas concret de ton travail, prompter dessus chaque jour pendant deux semaines, mesurer la qualité, itérer. Pratiquer sans cas d’usage concret donne peu de résultats.

Faut-il une formation payante pour maîtriser le prompting ?

Honnêtement, non. La doc officielle d’Anthropic (platform.claude.com/docs), la doc OpenAI (platform.openai.com/docs/guides/prompt-engineering) et la doc Google AI (ai.google.dev/gemini-api/docs/prompting-strategies) sont gratuites, à jour et excellentes. Si tu y consacres 5 à 10 heures de lecture active avec des essais en parallèle, tu es au-dessus de la moyenne des formations LinkedIn. Les formations payantes ont un intérêt si tu veux un cadre, du mentorat, ou un atelier en équipe où on construit ensemble une bibliothèque de prompts. Sinon, pratique + doc officielle + un guide comme celui-ci = largement suffisant.