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

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é.
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
| Champ | Contre-exemple | Bon exemple | Effet |
|---|---|---|---|
| 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 |
| Constraints | Aucune | « Perf + sécurité, 200 mots, ≥1 amélioration » | Sortie maîtrisée |
| Output Format | Aucun | « 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èle | Structure recommandée | Few-shot | Format des contraintes | Astuce |
|---|---|---|---|---|
| Claude | Balises XML | 2-3 | Par bloc dans les balises | Extended Thinking |
| GPT-4 | Listes | 3-5 | Liste numérotée | Function Calling |
| DeepSeek | Structure concise | 1-2 | Phrases courtes | Chinois prioritaire |
| Qwen | Persona + listes | 2-3 | Consignes positives | Longs documents |
| Llama < 13B | Structure minimale | 1 | Interdictions 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
- Beaucoup d’édition manuelle ? → contraintes insuffisantes
- Quelles contraintes violées ? → les préciser
- Informations manquantes ? → ajouter « doit inclure X »
- Bruit inutile ? → Negative Prompting
- 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 :
- Tester un pattern cette semaine — par exemple Persona ou Output Format sur une vraie tâche.
- Créer votre Personal Prompt Library — démarrer avec ces 5 modèles, copier-coller en remplaçant les variables.
- 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 ?
Parmi les 12 Prompt Patterns, lequel est le plus utile ?
Quelle différence entre les Prompts pour Claude et GPT-4 ?
Combien d'itérations pour stabiliser un modèle ?
Comment mettre en place une Prompt Library partagée en équipe ?
Combien d'exemples pour le Few-shot ?
13 min de lecture · Publié le: 29 avr. 2026 · Mis à jour le: 30 juil. 2026
Guide Prompt Engineering
Si vous arrivez depuis la recherche, le plus rapide est de passer à l’article précédent ou suivant de cette série.
Précédent
Ingénierie des prompts en entreprise : guide support, ventes et opérations
Guide pratique de l'ingénierie des prompts dans trois scénarios métier — support client, ventes et opérations — avec données réelles, modèles de prompts réutilisables et un processus de déploiement en sept étapes pour éviter l'échec des projets IA.
Partie 3 sur 5
Suivant
Pourquoi le Prompt Cache ne réduit pas la facture : diagnostiquer vos agents avec prompt-cache-skills
Repérez préfixes variables, cache keys incorrectes, options désactivées et TTL trop courts, puis validez prompt-cache-skills avec deux requêtes identiques.
Partie 5 sur 5



Commentaires
Connectez-vous avec GitHub pour laisser un commentaire