Changer le thème

Bibliothèque de modèles Prompt Engineering : 12 schémas de conception réutilisables

Easton editorial illustration: one enlarged reusable four-field template card

J’ai passé quarante minutes à rédiger un Prompt presque parfait : Claude a transformé un tas de retours utilisateurs épars en recommandations d’amélioration structurées. Le résultat était bluffant. Trois jours plus tard, pour la même tâche — face à une zone de saisie vide, l’esprit reste muet.

Où est passé ce « Prompt parfait » ?

J’ai fouillé Notion, les notes, l’historique de chat : introuvable. J’ai dû le réécrire de mémoire ; la qualité de sortie a nettement baissé.

Ça m’est arrivé au moins dix fois : éclair de génie → Prompt oublié dès la fin de session → repartir de zéro → qualité en dents de scie.

Jusqu’à ce qu’une idée simple tombe : la qualité d’un Prompt dépend autant de la technique que de sa réutilisabilité.

80%
Couverture des scénarios quotidiens

Selon une étude aiengineerlab.in de 2026, ce qui sépare un Prompt « parfois bon » d’un Prompt « fiable en continu », ce sont quatre champs. Bien combinés, ils couvrent environ 80 % des tâches du quotidien.

Dans cet article, je partage une méthode éprouvée pour constituer une bibliothèque de modèles Prompt, notamment :

  • Structure en quatre champs : Role + Task + Constraints + Output Format
  • 12 Prompt Patterns : classés Beginner / Intermediate / Advanced
  • Tableau d’adaptation multi-modèles : stratégies différenciées pour Claude, GPT-4, DeepSeek
  • Méthode d’itération : passer d’un modèle « pas mal » à un niveau production
  • 5 modèles prêts à l’emploi : copier-coller et exécuter

Chapitre 1 : la structure en quatre champs d’un modèle Prompt

Avant les modèles concrets, un fait de base souvent négligé : l’écart entre un bon et un mauvais modèle tient surtout à ces quatre champs.

La recherche aiengineerlab.in indique qu’un Prompt « fiable et efficace » doit inclure Role (rôle), Task (tâche), Constraints (contraintes) et Output Format (format de sortie).

Un contre-exemple

Aide-moi à rédiger une réponse de revue de code

Je l’ai écrit des dizaines de fois. Résultat ? Des réponses très variables — parfois trop polies, parfois trop techniques, parfois un simple « le code est bien ».

La version avec les quatre champs

## Role
Vous êtes un ingénieur backend avec 10 ans d'expérience, expert en Python et systèmes distribués.

## Task
Examiner le changement de code ci-dessous, signaler les problèmes potentiels et proposer des améliorations.

## Constraints
- Focus : performance, sécurité, maintenabilité
- Ton : professionnel mais cordial, sans être trop sévère
- Longueur : limiter à 200 mots
- Mentionner au moins un point d'amélioration

## Output Format
Utiliser le format suivant :
### Liste des problèmes
- [type] description précise

### Suggestions d'amélioration
1. ...
2. ...

### Évaluation globale
(résumé en une phrase)

La différence est nette.

Détail des quatre champs

Role (rôle) — qui est l’IA. Pas un titre vague : un profil avec contexte. « Ingénieur backend, 10 ans d’expérience » vaut mieux que « vous êtes un expert ». Plus le rôle est précis, plus le style de sortie est stable.

Task (tâche) — ce que l’IA doit faire. Astuce : commencer par un verbe. « Examiner le changement de code » bat « revue de code ». « Signaler les problèmes et proposer des améliorations » bat « regarder le code ».

Constraints (contraintes) — le champ le plus ignoré et le plus important. Sans contraintes, l’IA part dans tous les sens. Domaine (performance ? sécurité ?), ton, longueur, éléments obligatoires : ce sont les limites du jeu.

Output Format (format de sortie) — à quoi doit ressembler le résultat. JSON ? Markdown ? Sections fixes ? Le préciser tôt évite beaucoup de reformatage.

Tableau comparatif

ChampContre-exempleBon exempleEffet
Role« Vous êtes un expert »« Ingénieur backend 10 ans, Python »Style stable
Task« Regarder le code »« Examiner le changement, problèmes + conseils »Périmètre clair
ConstraintsAucune« Perf + sécurité, 200 mots, ≥1 amélioration »Sortie maîtrisée
Output FormatAucun« Liste problèmes + suggestions + synthèse »Peu de retouche

Une fois ces quatre champs en place, le Prompt passe du hasard à la réutilisation. C’est la base de la bibliothèque de modèles.

Chapitre 2 : les 12 Prompt Patterns réutilisables

best-ai.org propose une liste utile de Prompt Patterns, classés par niveau. Je les ai réorganisés par scénario pour faciliter le choix.

Niveau Beginner (5)

1. Zero-Shot

Tâche directe, sans exemple. Pour les demandes simples et explicites.

## Task
{{description de la tâche}}

## Output Format
{{format de sortie}}

Cas d’usage : résumé d’e-mail, traduction courte, questions factuelles.

2. Few-Shot

2 à 3 exemples à imiter. aiengineerlab.in indique que 2-3 exemples suffisent en général ; la classification peut en prendre 5-7.

## Task
{{description de la tâche}}

## Examples
Exemple 1 :
Entrée : {{exemple entrée 1}}
Sortie : {{exemple sortie 1}}

Exemple 2 :
Entrée : {{exemple entrée 2}}
Sortie : {{exemple sortie 2}}

## Now Process
Entrée : {{entrée réelle}}
Sortie :

Cas d’usage : imitation de style, classification, conversion de format.

3. Persona (jeu de rôle)

Identité et contexte de l’IA. Pattern très courant, lié au champ Role du chapitre 1.

## Role
Vous êtes {{identité précise}}, avec {{contexte précis}}.

## Style
Votre style : {{description du style}}

## Task
{{description de la tâche}}

Cas d’usage : revue de code, conseil technique, écriture créative.

4. Output Format (formatage de sortie)

Forcer un format précis. Se combine avec presque tous les autres patterns.

## Task
{{description de la tâche}}

## Output Format
Sortie strictement au format suivant :
{{modèle de format}}

## Note
Ne produire que le contenu formaté, sans explication supplémentaire.

Cas d’usage : JSON, formulaires, documents structurés.

5. Negative Prompting (contraintes négatives)

Dire à l’IA ce qu’il ne faut pas faire. Parfois plus efficace que les contraintes positives.

## Task
{{description de la tâche}}

## Do NOT
- Ne pas {{interdit 1}}
- Ne pas {{interdit 2}}
- Éviter {{interdit 3}}

Cas d’usage : éviter certains termes, exclure du contenu sensible, contrôler le ton.

Niveau Intermediate (4)

6. Chain of Thought (chaîne de raisonnement)

Afficher le raisonnement. Pour la logique et les décisions complexes.

## Task
{{description de la tâche}}

## Instructions
Raisonner étape par étape : analyser d'abord, puis répondre.
Montrer le raisonnement avant la réponse finale.

Cas d’usage : maths, logique, décisions complexes.

7. System Prompt (invite système)

Instructions de rôle dans le System Prompt pour garder la cohérence. Très utilisé avec Claude et GPT-4.

## System
Vous êtes {{description du rôle}}.
Votre responsabilité principale : {{description des responsabilités}}.
Règles obligatoires :
1. {{règle 1}}
2. {{règle 2}}

## User
{{entrée utilisateur}}

Cas d’usage : agents IA, chatbots, dialogues prolongés.

8. Iterative Refinement (affinage itératif)

Brouillon puis auto-révision. Pour une haute qualité de sortie.

## Round 1
{{description de la tâche}}
Produire un brouillon.

## Round 2
Relire le brouillon et repérer :
- failles logiques
- formulations floues
- erreurs factuelles

## Round 3
Optimiser selon la relecture et livrer la version finale.

Cas d’usage : rédaction, génération de code, conception de solutions.

9. Constraint Stacking (empilement de contraintes)

Plusieurs contraintes cumulées. Combinaison fréquente en production.

## Task
{{description de la tâche}}

## Constraints
- Contrainte 1 : {{contrainte précise}}
- Contrainte 2 : {{contrainte précise}}
- Contrainte 3 : {{contrainte précise}}
- Contrainte 4 : {{contrainte précise}}

## Output Format
{{exigences de format}}

Cas d’usage : tâches de production à sortie strictement contrôlée.

Niveau Advanced (3)

10. Self-Critique (auto-évaluation)

L’IA évalue sa propre sortie. Utile quand la fiabilité compte.

## Task
{{description de la tâche}}

## Self-Critique
Après la réponse, évaluer :
1. La réponse est-elle complète ?
2. Y a-t-il des failles logiques ?
3. Toutes les contraintes sont-elles respectées ?

En cas de problème, régénérer.

## Output Format
Réponse :
{{réponse}}

Auto-évaluation :
{{évaluation}}

Cas d’usage : sorties à risque, besoin de fiabilité.

11. Task Decomposition (décomposition de tâche)

Découper une tâche complexe. Pour les workflows multi-étapes.

## Complex Task
{{description de la tâche complexe}}

## Decomposition
Découper en sous-tâches :
1. {{sous-tâche 1}}
2. {{sous-tâche 2}}
3. {{sous-tâche 3}}

## Execution
Exécuter chaque sous-tâche et documenter le résultat de chaque étape.

Cas d’usage : gestion de projet, analyse complexe, conception système.

12. Meta-Prompting (méta-invite)

Demander à l’IA d’écrire le Prompt. Pratique quand la formulation bloque.

## Task
Je dois accomplir : {{description de la tâche}}

## Request
Rédiger un Prompt de haute qualité pour qu'une autre IA réussisse cette tâche.
Le Prompt doit inclure : Role, Task, Constraints, Output Format.

Cas d’usage : débutants en ingénierie des prompts, clarification de tâches complexes.

Conseils de combinaison

"Combiner 2 à 4 patterns donne les meilleurs résultats. Exemples : rédaction professionnelle — Persona + Output Format + Constraint Stacking ; génération de code — Persona + Few-Shot + Negative Prompting ; recherche et analyse — Chain of Thought + Self-Critique + Task Decomposition."

Chapitre 3 : tableau d’adaptation multi-modèles

Chaque modèle « lit » les Prompts différemment. Un Prompt excellent sur Claude peut être moyen sur GPT-4.

Ce chapitre résume un guide d’adaptation pour limiter les mauvaises surprises.

Claude : balises XML et consignes contractuelles

Claude aime la structure. La doc officielle recommande les balises XML plutôt que le texte brut.

<instructions>
Examiner le changement de code ci-dessous et signaler les problèmes potentiels.
</instructions>

<context>
Vous êtes un ingénieur backend avec 10 ans d'expérience.
Le projet est un microservice Python avec FastAPI.
</context>

<constraints>
- Focus performance et sécurité
- Ton professionnel mais cordial
- Limiter à 200 mots
</constraints>

<output_format>
### Liste des problèmes
- [type] description

### Suggestions
1. ...
</output_format>

Autres atouts Claude :

  • Extended Thinking : réflexion avant sortie, utile pour l’inférence complexe
  • Consignes contractuelles : préciser en tête que le respect des contraintes vaut validation

GPT-4 : longues listes de contraintes et JSON

GPT-4 gère moins bien le XML pur ; il préfère les listes. Sorties JSON souvent un peu plus stables qu’avec Claude.

## Task
Examiner le changement de code ci-dessous.

## Constraints
1. Focus performance et sécurité
2. Ton professionnel mais cordial
3. Limiter à 200 mots
4. Au moins un point d'amélioration
5. Sortie en français

## Output Format
JSON uniquement :
{
  "issues": [...],
  "suggestions": [...],
  "summary": "..."
}

Traits GPT-4 :

  • Listes de 10+ contraintes encore bien suivies
  • Few-shot parfois légèrement meilleur qu’avec Claude
  • Code et explication plutôt équilibrés

DeepSeek et Qwen : modèles chinois

Progrès rapides, avec des particularités :

DeepSeek :

  • Fort en chinois, respect des structures un peu plus faible
  • Contraintes plus courtes et explicites
  • Few-shot : 1 à 2 exemples suffisent souvent

Qwen :

  • Sensible au Persona
  • Bon sur les longs documents
  • Préférer les interdictions explicites (« ne pas ») aux « éviter »

Llama (petits paramètres) : consignes très directes

Pour Llama 7B/13B, simplifier au maximum.

## Task
Examiner le changement de code.

## Output Format
Return ONLY valid JSON. No explanation. No markdown.
{
  "issues": [],
  "suggestions": []
}

Point clé : exiger « ONLY JSON », sinon le modèle commente trop.

Tableau récapitulatif

ModèleStructure recommandéeFew-shotFormat des contraintesAstuce
ClaudeBalises XML2-3Par bloc dans les balisesExtended Thinking
GPT-4Listes3-5Liste numérotéeFunction Calling
DeepSeekStructure concise1-2Phrases courtesChinois prioritaire
QwenPersona + listes2-3Consignes positivesLongs documents
Llama < 13BStructure minimale1Interdictions explicites« Sortie X uniquement »

En pratique : tester sur le modèle cible, ajuster selon la qualité observée.

Chapitre 4 : méthodologie d’itération des modèles

Un Prompt « correct » est facile ; un modèle « fiable à chaque fois » est autre chose.

"Les meilleurs modèles ne naissent pas d’un coup : ils mûrissent à l’usage. Comptez au moins cinq à six cycles."

Cinq étapes d’itération

Étape 1 : écrire le Prompt et valider le résultat

Ne pas templatiser trop tôt. Tester plusieurs fois jusqu’à une sortie stable.

Étape 2 : repérer fixe et variables

Analyser ce qui ne change pas (rôle, format) — le squelette du modèle — et ce qui change (contenu, données), marqué {{nom_variable}}.

Étape 3 : ajouter des garde-fous qualité

Étendre le squelette avec contraintes et critères de validation :

  • sortie trop longue → « limiter à X mots »
  • trop de bavardage → « pas d’explication, résultat seul »
  • format instable → modèle de format explicite

Étape 4 : utiliser et journaliser les problèmes

En production, noter :

  • variations de qualité ?
  • contraintes violées ?
  • scénarios forts / faibles ?

Étape 5 : itérer

Ajuster selon le journal :

  • contraintes floues → formulations plus précises
  • format instable → exemples ou gabarit
  • scénario faible → branche conditionnelle

Exemple : modèle « rapport hebdomadaire »

Environ 8 itérations avant stabilisation.

V1 : Prompt simple pour formater la semaine. Problème : sortie très inégale.

V2-V3 : gabarit + limite de mots. Problème : oublis sur certaines tâches.

V4-V5 : contrainte « progression / problème / prochaine étape » par tâche. Problème : micro-tâches inutiles incluses.

V6-V7 : « tâches cœur de la semaine » + exemple. Problème : écarts de format occasionnels.

V8 : module Self-Critique avant sortie finale.

Questions de contrôle

  1. Beaucoup d’édition manuelle ? → contraintes insuffisantes
  2. Quelles contraintes violées ? → les préciser
  3. Informations manquantes ? → ajouter « doit inclure X »
  4. Bruit inutile ? → Negative Prompting
  5. Format incohérent ? → exemple ou gabarit

Trois clés pour une bibliothèque d’équipe

mintedbrain.com suggère :

1. Document partagé — Notion, Lark/Feishu, regroupement par catégorie (rédaction, analyse, dev, communication).

2. Notice d’usage — scénario, variables, pièges ; sinon le modèle est mal employé.

3. Propositions d’amélioration — pas de modification directe anarchique ; tracer la raison de chaque changement.

Chapitre 5 : 5 modèles prêts pour la production

Cinq modèles copiables, testés en conditions réelles.

Modèle 1 : rapport hebdomadaire

<instructions>
À partir des notes de travail de la semaine, produire un rapport hebdomadaire concis.
</instructions>

<role>
Vous êtes un collaborateur efficace, capable de résumer l'avancement en langage clair.
</role>

<input>
{{notes de la semaine}}
</input>

<constraints>
- Uniquement les tâches cœur terminées cette semaine
- Par tâche : avancement, problème, prochaine étape
- Limiter à 300 mots
- Ton professionnel et concis
- Pas de jugement valorisant (ex. « excellent travail »)
</constraints>

<output_format>
## Avancement de la semaine
- {{tâche1}} : {{avancement}} | {{problème}} | {{prochaine étape}}
- {{tâche2}} : {{avancement}} | {{problème}} | {{prochaine étape}}

## Besoin d'aide
- {{points nécessitant de l'aide}}

## Plan de la semaine prochaine
- {{plan}}
</output_format>

<self_check>
Après génération, vérifier :
1. Seules les tâches cœur ?
2. Chaque tâche a avancement, problème, prochaine étape ?
3. Total ≤ 300 mots ?
</self_check>

Modèle 2 : revue de code

<instructions>
Examiner le changement de code ci-dessous, signaler les problèmes et proposer des améliorations.
</instructions>

<role>
Ingénieur backend, 10 ans d'expérience, expert {{langage}} et {{stack}}.
Style : professionnel sans sévérité excessive ; chaque problème avec une suggestion concrète.
</role>

<input>
{{contenu du changement}}
</input>

<constraints>
- Focus : performance, sécurité, maintenabilité, conventions
- Au moins un point d'amélioration
- Par problème : type, emplacement, cause, suggestion
- Limiter à 200 mots
- Pas de « le code est bien » sans contenu concret
</constraints>

<output_format>
### Liste des problèmes
- [{{type}}] {{fichier}}#{{ligne}} : {{description}}

### Suggestions
1. {{suggestion}}

### Évaluation globale
{{une phrase}}
</output_format>

Modèle 3 : compte rendu de réunion

<instructions>
Structurer les notes de réunion ci-dessous en compte rendu formel.
</instructions>

<role>
Rédacteur de réunion professionnel, capable d'extraire l'essentiel.
</role>

<input>
{{notes de réunion}}
</input>

<constraints>
- Garder l'essentiel, supprimer le bavardage
- Marquer : sujets, conclusions, actions, responsable, échéance
- Langage concis
- Limiter à 500 mots
</constraints>

<output_format>
## Informations générales
- Date/heure : {{datetime}}
- Participants : {{liste}}
- Sujets : {{liste sujets}}

## Points de discussion
### {{sujet1}}
- {{point1}}
- {{point2}}
- Conclusion : {{conclusion}}

### {{sujet2}}
- ...

## Actions
| Action | Responsable | Échéance |
|--------|-------------|----------|
| {{action1}} | {{responsable}} | {{date}} |
| {{action2}} | {{responsable}} | {{date}} |

## Remarques
{{remarques}}
</output_format>

Modèle 4 : extraction JSON

<instructions>
Extraire des données structurées du texte ci-dessous en JSON.
</instructions>

<role>
Expert en extraction de données précise.
</role>

<input>
{{texte d'entrée}}
</input>

<constraints>
- JSON uniquement, sans explication
- JSON valide obligatoire
- Champ manquant → null
- Ne pas inventer d'informations absentes du texte
</constraints>

<output_format>
Return ONLY valid JSON. No explanation. No markdown.

{
  {{définition des champs}}
}

Example:
Input: "张三,电话 13800138000,邮箱 zhang@example.com"
Output:
{
  "name": "张三",
  "phone": "13800138000",
  "email": "zhang@example.com"
}
</output_format>

Modèle 5 : invite système d’agent IA

<system_prompt>
Vous êtes {{agent_name}}, chargé de {{agent_description}}.

## Responsabilités principales
1. {{responsabilité1}}
2. {{responsabilité2}}
3. {{responsabilité3}}

## Flux de travail
À chaque requête utilisateur :
1. Analyser l'intention
2. Vérifier si les informations suffisent
3. Demander les précisions manquantes
4. Exécuter la tâche
5. Valider le résultat

## Comportement
- Ton cordial et professionnel
- En cas d'incertitude, le signaler et proposer des pistes
- Pas d'engagement hors périmètre
- Sorties claires et actionnables

## Interdictions
- Ne pas inventer d'informations
- Pas de décision non autorisée
- Pas de contenu sensible ou nuisible

## Format de sortie
Selon le type de tâche :
- Recherche d'information : réponse concise + sources
- Exécution : étapes + confirmation du résultat
- Question : analyse + plan + recommandation
</system_prompt>

Ces modèles couvrent la plupart des scénarios quotidiens. Adaptez variables et contraintes à votre contexte.

Conclusion

Trois niveaux à retenir :

Structure — Role + Task + Constraints + Output Format : le Prompt passe du hasard au contrôle.

Patterns — Les 12 modes se combinent ; 2 à 4 patterns battent un seul. En production : Persona + Output Format + Constraint Stacking est le trio le plus courant.

Ingénierie — Un modèle vit par l’itération : 5 à 6 cycles minimum, journal des problèmes, garde-fous, ajustements.

Pour agir tout de suite :

  1. Tester un pattern cette semaine — par exemple Persona ou Output Format sur une vraie tâche.
  2. Créer votre Personal Prompt Library — démarrer avec ces 5 modèles, copier-coller en remplaçant les variables.
  3. Itérer chaque mois — repérer ce qui tient et ce qui dérape ; affiner contraintes, exemples et format.

L’ingénierie des prompts peut sembler lourde ou légère : une fois la bibliothèque en place, fini la page blanche à chaque nouvelle tâche.

FAQ

Comment rédiger des Constraints efficaces dans la structure à quatre champs ?
Les Constraints doivent être concrètes, quantifiables et vérifiables. Évitez les formulations floues comme « haute qualité » ou « professionnel » ; préférez « limiter à 200 mots » ou « inclure au moins un point d'amélioration ». Chaque contrainte devrait correspondre à un critère vérifiable.
Parmi les 12 Prompt Patterns, lequel est le plus utile ?
Il n'existe pas de pattern unique « le plus utile », car chaque scénario convient à un mode différent. D'après les données terrain, Persona (jeu de rôle) et Output Format (formatage de sortie) sont les plus utilisés et couvrent environ 80 % des tâches quotidiennes. Commencez par maîtriser ces deux-là.
Quelle différence entre les Prompts pour Claude et GPT-4 ?
Claude préfère une structure en balises XML, avec les contraintes à l'intérieur des balises ; GPT-4 s'adapte bien aux listes numérotées, même au-delà de 10 points. Claude prend en charge Extended Thinking (chaîne de raisonnement) pour l'inférence complexe ; le Function Calling de GPT-4 est plus stable pour les sorties structurées.
Combien d'itérations pour stabiliser un modèle ?
En pratique, un bon modèle demande au moins 5 à 6 itérations. Le cœur du processus : utiliser → noter les problèmes → améliorer de façon ciblée. Questions clés : la sortie nécessite-t-elle beaucoup d'édition ? Quelles contraintes l'IA a-t-elle violées ? Le format est-il cohérent ?
Comment mettre en place une Prompt Library partagée en équipe ?
Trois points clés : 1) document partagé (Notion, Lark/Feishu), regroupé par catégorie ; 2) notice d'usage par modèle (scénario, variables, précautions) ; 3) mécanisme de propositions d'amélioration pour tracer chaque modification et éviter les changements anarchiques.
Combien d'exemples pour le Few-shot ?
Selon aiengineerlab.in, 2 à 3 exemples donnent en général les meilleurs résultats ; les tâches de classification peuvent en utiliser 5 à 7. Trop d'exemples allongent le Prompt sans gain garanti. L'essentiel est de couvrir les cas typiques : la qualité prime sur la quantité.

13 min de lecture · Publié le: 29 avr. 2026 · Mis à jour le: 30 juil. 2026

Commentaires

Connectez-vous avec GitHub pour laisser un commentaire

Easton BlogEaston Blog