Le même modèle de langage peut produire un chef-d’œuvre ou un fiasco selon la manière dont vous lui parlez. C’est tout l’enjeu du prompt engineering pour développeur : transformer une intention floue en instructions assez nettes pour que l’IA livre du code utilisable du premier coup. Pas de mantra, pas de formule magique : des patterns reproductibles.

Cet article retient quatre patterns éprouvés en 2025-2026 sur Claude, ChatGPT et les modèles locaux. Pour chacun, vous verrez un avant/après concret sur une tâche de dev, et un template à recopier dans votre toolkit personnel.

Pourquoi le « bon prompt » n’existe pas, mais les patterns oui

Un LLM (Large Language Model, modèle de langage de grande taille) ne lit pas votre intention. Il prédit la suite la plus probable d’une séquence de tokens, à partir du contexte que vous lui donnez. Si ce contexte est ambigu, il choisit une interprétation parmi mille, parfois la mauvaise. Si ce contexte est cadré, il converge.

Cesser de chercher la formule parfaite et adopter quelques patterns réutilisables change tout. Vous gagnez en reproductibilité, vous économisez des allers-retours, et vous transmettez plus facilement la pratique à vos collègues. La doc d’Anthropic résume bien l’idée dans son guide officiel de prompt engineering, et le Prompt Engineering Guide communautaire reste une référence transverse, modèle-agnostique, qui couvre few-shot, chain-of-thought et patterns avancés avec des exemples reproductibles.

Pattern 1 — Rôle, contexte, contraintes, format

Anatomie d’un prompt qui tient

Quatre blocs suffisent pour la plupart des tâches : qui le modèle doit incarner, ce qu’il doit savoir du contexte, ce qu’il ne doit pas faire, et sous quel format livrer la réponse. Ce squelette s’adapte à toutes les situations sans devenir verbeux.

Rôle : Tu es un développeur senior Node.js spécialiste Fastify.
Contexte : Notre API expose /users avec une validation Zod existante.
Le schéma User contient id (uuid), email, createdAt (Date).
Tâche : Écris une fonction de validation qui vérifie qu'un email
est unique en base avant insertion. La connexion Postgres
se fait via Drizzle, instance importée depuis ./db.
Contraintes :
- TypeScript strict, pas de any
- Pas de gestion d'erreur try/catch : laisser bubbler
- 100% testable, pas d'effet de bord caché
Format : Une seule fonction exportée + 3 cas de test Vitest.

Avant/après sur une demande de fonction utilitaire

La différence entre un prompt naïf et un prompt structuré se mesure à l’œil nu. Voici le même besoin, formulé deux fois.

Prompt naïf	Prompt structuré
« Fais-moi une fonction qui valide un email avant d’insérer en base. »	Rôle développeur senior Node, contexte API Fastify et Drizzle, tâche fonction d’unicité, contraintes TypeScript strict, format fonction plus tests Vitest.
Sortie : code JavaScript générique, regex maison, pas de connexion DB, pas de tests.	Sortie : fonction TypeScript typée, requête Drizzle correcte, trois cas de test pertinents.
Trois itérations pour obtenir un résultat exploitable.	Code utilisable au premier essai, ajustements mineurs.

Pattern 2 — Few-shot pour code

Quand un exemple vaut cinq paragraphes

Le few-shot consiste à montrer à l’IA deux ou trois exemples de la transformation attendue, plutôt que la décrire en mots. Pour du code, c’est imbattable : les conventions de votre projet (nommage des hooks, structure d’un test, format d’un commit) se transmettent en montrant trois cas existants.

Voici comment on écrit nos custom hooks dans ce projet.

Exemple 1 :
// hooks/useDebouncedValue.ts
export function useDebouncedValue<T>(value: T, delayMs: number): T {
  const [debounced, setDebounced] = useState(value);
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delayMs);
    return () => clearTimeout(id);
  }, [value, delayMs]);
  return debounced;
}

Exemple 2 : (...)
Exemple 3 : (...)

Maintenant écris dans le même style un hook useOnlineStatus
qui renvoie true / false selon navigator.onLine et écoute
les événements online / offline.

Avec ce prompt, le modèle reproduit le style maison sans qu’on l’ait expliqué. Trois exemples bien choisis valent mieux qu’une page de directives. Si vos exemples sont contradictoires en revanche, le résultat l’est aussi.

Pattern 3 — Chain-of-thought guidé

Le chain-of-thought (raisonnement en chaîne) consiste à demander au modèle de raisonner explicitement avant de produire le résultat. Sur les tâches qui demandent de l’analyse, c’est ce qui fait la différence entre une réponse plausible et une réponse correcte.

• Demandez d’abord un plan ou une analyse, pas la solution.
• Validez ce plan, corrigez si besoin.
• Seulement ensuite, demandez la mise en œuvre.
• Cette discipline coûte un tour d’échange et économise plusieurs itérations.

Sur Claude, vous pouvez aussi exploiter le mode extended thinking qui rend visible le raisonnement avant la réponse. Cela vous donne un point de contrôle naturel : si le raisonnement part en biais, vous interrompez avant d’avoir consommé les tokens de la solution finale.

Pattern 4 — Le prompt-comme-test

Donner le test avant le code

Inverser l’ordre habituel donne des résultats remarquables : écrivez vous-même le test, donnez-le au modèle, demandez-lui le code qui le fait passer. Cette méthode contraint la sortie de manière vérifiable. Le modèle ne peut pas inventer une signature de fonction qui ne respecterait pas le test, ni omettre un cas limite couvert.

// Voici les tests Vitest. Écris la fonction parseDuration
// qui les fait tous passer.

import { test, expect } from 'vitest';
import { parseDuration } from './parseDuration';

test('rejette une entrée vide', () => {
  expect(() => parseDuration('')).toThrow();
});

test('parse les minutes', () => {
  expect(parseDuration('5m')).toBe(300_000);
});

test('parse les heures', () => {
  expect(parseDuration('2h')).toBe(7_200_000);
});

test('combine heures et minutes', () => {
  expect(parseDuration('1h30m')).toBe(5_400_000);
});

Avec ce cadre, l’IA produit une fonction qui passe les tests dès la première sortie dans neuf cas sur dix. C’est aussi le meilleur moyen d’éviter les hallucinations : un test exécutable est un juge implacable.

Le toolkit de prompts à se constituer

Les prompts récurrents méritent d’être versionnés comme du code. Ouvrez un dossier dans votre ~/.claude/ ou dans votre dépôt d’équipe, et conservez les templates qui marchent. Vous gagnez du temps et vous lissez la qualité dans l’équipe.

• Un template « génération de fonction utilitaire avec tests ».
• Un template « refactor de fichier sans changer le comportement ».
• Un template « écriture de tests unitaires sur module legacy ».
• Un template « code review pré-PR ».
• Un template « génération de migration SQL à partir d’un changement de schéma ».

Ces templates s’utilisent particulièrement bien avec une CLI agentique. Le guide complet Claude Code et le comparatif des assistants IA détaillent comment les intégrer concrètement à votre quotidien.

Quand abandonner et reformuler de zéro

Un prompt qui ne donne pas le résultat attendu après deux ajustements est rarement sauvable par un troisième. Le réflexe utile : repartir d’une page blanche, reformuler la demande sous un angle différent, parfois changer l’ordre des blocs ou réécrire le rôle. Acharner l’agent sur une mauvaise piste consomme des tokens sans rapprocher de la solution.

Trois symptômes signalent qu’il faut tout reprendre : le modèle reformule sa réponse précédente avec des variations cosmétiques, il invente des dépendances ou des API qui n’existent pas, ou il ignore systématiquement une contrainte que vous avez répétée. Dans ces cas, la persévérance est l’ennemi. Cette discipline, appliquée en équipe, complète bien un workflow Git d’équipe avec Claude Code.

Questions fréquentes

Qu’est-ce que le prompt engineering pour un développeur ?

Le prompt engineering pour développeur consiste à formuler vos demandes à un modèle de langage de manière à obtenir du code utilisable du premier coup. Cela passe par des patterns reproductibles : rôle, contexte, contraintes, format, plus l’usage d’exemples ou de tests pour cadrer la sortie.

Quels sont les meilleurs patterns de prompt en 2026 ?

Quatre patterns ressortent du terrain : le squelette rôle-contexte-contraintes-format, le few-shot avec deux ou trois exemples du style attendu, le chain-of-thought qui demande un plan avant la solution, et le prompt-comme-test où vous fournissez les tests à faire passer. Aucun n’est exclusif, ils se combinent bien.

Pourquoi mes prompts donnent-ils des résultats incohérents ?

Trois causes dominent : un contexte trop maigre, des contraintes implicites jamais formulées, ou un format de sortie laissé au choix du modèle. Une demande qui produit cinq résultats différents en cinq essais souffre presque toujours de l’un de ces trois problèmes. Le cadrer suffit à stabiliser la sortie.

Faut-il donner un rôle à l’IA dans le prompt ?

Oui, dans la plupart des cas. Préciser un rôle (« développeur senior Node », « relecteur de sécurité ») oriente le ton et la profondeur attendue. L’effet est mesurable sur la qualité des réponses techniques. Évitez en revanche les rôles fantaisistes ou trop pittoresques, ils n’apportent rien de plus que du bruit.

Comment debugger un prompt qui ne fonctionne pas ?

Réduisez la demande à son minimum, vérifiez chaque bloc isolément. Demandez au modèle de paraphraser votre demande pour repérer les ambiguïtés. Si rien ne marche après deux tentatives, repartez d’une page blanche : la reformulation produit souvent de meilleurs résultats que l’acharnement.

À retenir : pas de mantra, des patterns. Cadrez le rôle et le contexte, montrez plutôt que décrire quand vous le pouvez, demandez un raisonnement avant la solution, et donnez les tests quand l’enjeu est précis. Vous voulez intégrer un toolkit de prompts dans votre équipe ? On peut le co-construire.