Bien structurer un prompt
Comment bien structurer un prompt : objectif, contexte, perimetre, contraintes, requis, format de sortie et validation finale.
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.
Dire ce que vous voulez vraiment obtenir : comprendre, corriger, refactorer, documenter, tester, cadrer, verifier.
Donner juste ce qu'il faut : langage, environnement, module, symptome, fichier, dependances, stack ou type de flux.
Delimitez ce qui est dedans et ce qui reste hors sujet : un fichier, un module, un endpoint, un script, une procedure, une page.
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.
Imposez une forme stable : analyse, plan, patch, cas de test, risques, synthèse, checklist, runbook ou fiche courte.
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.