Aller au contenu
Fondamentaux et prise en main

Exemples de prompts avant / après

Exemples pédagogiques de prompts avant / après pour apprendre à transformer une demande floue en demande utile avec contexte, périmètre, contraintes et format de sortie.

Le but n'est pas de faire plus long, mais plus exploitable

Cette page montre comment passer d'une demande trop floue à une demande qui donne une réponse plus stable. Les exemples restent courts, mais ils ajoutent les pièces qui changent vraiment le résultat : objectif, contexte, périmètre, contraintes, format de sortie et validation finale.

1. Bug backend
Avant :
Corrige save-fiche.php.

Après :
Analyse [FICHIER OU EXTRAIT À FOURNIR].

Objectif : corriger un bug de sauvegarde sans changer l'API.
Attendu :
1) Cause racine probable
2) Correctif minimal
3) Risques de régression
4) Vérifications à rejouer
2. Documentation
Avant :
Fais-moi une doc.

Après :
Transforme ../DEPLOIEMENT.md en guide interne pour un collègue.

Inclure : prérequis, étapes, contrôles, retour arrière.
Format :
1) Préparation
2) Exécution
3) Vérification
4) Erreurs fréquentes
3. Architecture
Avant :
Concois une architecture.

Après :
Prends [DESCRIPTION DU SYSTÈME], [CONTRAINTES]
et [FLUX OU FICHIERS À FOURNIR].

Attendu :
1) Cartographie du flux actuel
2) Faiblesses de couplage
3) Cible d'évolution simple
4) Questions ouvertes
4. Script ou exploitation
Avant :
Améliore ce script PowerShell.

Après :
Relis [SCRIPT POWERSHELL À FOURNIR].

Objectif : fiabiliser le lancement local.
Contraintes : garder le comportement actuel.
Attendu :
1) Prérequis
2) Risques opératoires
3) Améliorations prudentes
4) Procédure de vérification
5. QA / test
Avant :
Fais les tests.

Après :
Construis un plan de tests pour [COMPOSANT]
et [JEU DE DONNÉES OU CONTRAT].

Inclure : nominal, erreurs, valeurs limites,
données invalides, non-régression et résultat attendu.
6. Sécurité
Avant :
Vérifie la sécurité.

Après :
Analyse [CODE OU CONFIGURATION À FOURNIR] et ../tutoriels/rest-jwt-partie2.html.

Attendu :
1) Surface d'attaque visible
2) Risques par criticité
3) Corrections prioritaires
4) Vérifications manuelles restantes

Ce qui change entre avant et après

  • Le sujet est nommé : un fichier, une page, un flux ou une procédure précise.
  • L'objectif est borné : comprendre, corriger, documenter, cadrer ou vérifier.
  • Le format est imposé : plan, synthèse, patch, checklist ou note courte.
  • La validation existe : tests à rejouer, risques restants ou contrôles manuels.

Mini formule réutilisable

Analyse {{SUJET}}.

Objectif : {{OBJECTIF}}.
Contexte : {{CONTEXTE}}.
Contraintes : {{CONTRAINTES}}.

Attendu :
1) {{SECTION_1}}
2) {{SECTION_2}}
3) {{SECTION_3}}
4) {{SECTION_4}}

Erreurs fréquentes par métier

  • Backend : demander "corrige" sans dire ce qu'il ne faut pas casser ni quelles validations rejouer.
  • Exploitation : demander une procédure sans prérequis, sans contrôle final ni retour arrière.
  • QA : demander "fais les tests" sans flux, sans cas limites et sans résultat attendu.
  • Documentation : demander "fais une doc" sans public cible, sans format ni niveau de détail.
  • Sécurité : demander "vérifie la sécurité" sans périmètre ni priorisation des risques.

Version débutant

Si vous voulez une marche encore plus simple, ouvrez les prompts pour débutants puis revenez ici pour apprendre à reformuler une demande déjà existante.