Bien structurer un prompt

Un bon prompt est d'abord un cadre de travail

La plupart des bons prompts reposent sur une structure simple et reusable : objectif, contexte, perimetre, contraintes, donnees, format de sortie et validation finale. Cette page sert a comprendre comment composer ce cadre sans faire un mega-prompt inutilement long.

1. Objectif

Dire ce que vous voulez vraiment obtenir : comprendre, corriger, refactorer, documenter, tester, cadrer, verifier.

2. Contexte

Donner juste ce qu'il faut : langage, environnement, module, symptome, fichier, dependances, stack ou type de flux.

3. Perimetre

Delimitez ce qui est dedans et ce qui reste hors sujet : un fichier, un module, un endpoint, un script, une procedure, une page.

4. Contraintes et requis

Précisez les interdits et les attentes : ne pas changer l'API, pas de dépendance, garder la logique métier, produire des tests ou une doc.

5. Format de sortie

Imposez une forme stable : analyse, plan, patch, cas de test, risques, synthèse, checklist, runbook ou fiche courte.

6. Validation finale

Terminez par ce qu'il faut vérifier : risques restants, tests à rejouer, hypothèses non couvertes, limites ou contrôles manuels.

Version un peu plus avancée

Quand le sujet devient plus sensible ou plus long, vous pouvez séparer le cadre permanent, la demande utilisateur et la vérification finale. Cette séparation aide à garder un prompt lisible sans tout mélanger dans un seul bloc compact.

Cadre / rôle : {{ROLE_ET_REGLES}}

Demande utilisateur : {{DEMANDE_REELLE}}

Format de sortie : {{FORMAT_IMPOSE}}

Vérification finale : {{CONTROLES_A_REJOUER}}

Squelette simple

Rôle : tu es un/une {{ROLE}}.

Objectif : {{OBJECTIF}}

Contexte :
- sujet : {{SUJET}}
- environnement : {{ENVIRONNEMENT}}
- données utiles : {{DONNEES}}

Périmètre :
- inclus : {{INCLUS}}
- exclus : {{EXCLUS}}

Contraintes / requis :
- {{CONTRAINTE_1}}
- {{CONTRAINTE_2}}

Format de sortie :
1) {{SECTION_1}}
2) {{SECTION_2}}
3) {{SECTION_3}}

Validation finale :
- {{VALIDATION_ATTENDUE}}

Quand imposer un format plus strict

Plan ou audit humain : un plan numéroté ou une checklist suffit souvent.
Sortie à comparer ou reprendre : imposer un tableau fixe, un JSON simple ou un balisage court.
Procédure rejouable : préférer un runbook avec pré-requis, étapes, contrôles et retour arrière.
Décision technique : imposer contexte, options, compromis, risques et recommandation finale.

Exemples rapides

Bug backend : objectif = corriger, contexte = symptôme + fichier, périmètre = un module, requis = ne pas casser l'API, sortie = analyse, cause, correctif, validations.
Flux JSON : objectif = vérifier, contexte = source/destination, périmètre = lecture et écriture, requis = signaler doublons et formats invalides, sortie = cas nominaux, erreurs, jeux de données, contrôles.
Documentation : objectif = rédiger, contexte = public + matière source, périmètre = fiche courte ou guide, requis = exemples et limites, sortie = plan, contenu, zones à compléter.
Script ou Docker : objectif = cadrer ou revoir, contexte = environnement local, périmètre = lancement ou exploitation, requis = prérequis, retour arrière, contrôles, sortie = procédure et vérifications.

Ce qu'il faut éviter

Mettre un objectif flou du type "aide-moi" sans dire sur quoi porter l'effort.
Oublier le périmètre et laisser l'IA inventer un sujet plus large que le besoin réel.
Ne pas imposer de format de sortie et recevoir une réponse difficile à exploiter.
Oublier la validation finale, surtout sur les flux, la sécurité, les scripts ou les effets de bord.
Mettre les règles permanentes, la demande du moment et les données brutes dans un seul bloc confus.

Cas du site

Cette structure se prête très bien à des sujets comme save-fiche.php, start-admin.ps1, fiches.json, REST / JWT ou DEPLOIEMENT.md : objectif, contexte, périmètre et validations y font une vraie différence.

Pages voisines utiles

Voir les bonnes pratiques, l'ingénierie de prompt avancée, les prompts pour débutants, les formulations de sorties attendues, les exemples avant / après, les squelettes de prompts, les recettes rapides et les anti-patterns.

← Retour à la rubrique IA