Un bon prompt ne remplace pas l'expertise. Il sert à donner un cadre de travail précis à l'IA pour obtenir une analyse utile, un plan clair, un patch proposé ou une documentation exploitable.
Les exemples ci-dessous sont généralistes. Ils peuvent être adaptés à plusieurs assistants IA. L'important est surtout la structure: rôle, objectif, contraintes, format de sortie et validations attendues.
Prompt utile quand on reprend un module inconnu, qu'on veut comprendre les flux de données, la structure ou les risques de maintenabilité.
Analyse ce module comme un ingénieur logiciel senior. Objectif : - expliquer le fonctionnement réel du code ; - résumer l'architecture locale ; - identifier les zones fragiles ; - proposer 3 améliorations concrètes. Contraintes : - ne pas inventer de comportement absent du code ; - distinguer les faits des hypothèses ; - signaler les cas limites visibles. Format de sortie : 1) Résumé du module 2) Flux principal 3) Risques techniques 4) Pistes d'amélioration
À utiliser pour éviter les corrections superficielles et obtenir un raisonnement par cause racine, avec prise en compte des cas limites.
Agis comme un ingénieur senior spécialisé en debug de production.
Problème observé :
{{ERREUR_OU_COMPORTEMENT}}
Contexte :
{{CODE_OU_EXTRAIT}}
Attendu :
- expliquer le fonctionnement du code ;
- identifier la cause racine probable ;
- expliquer pourquoi l'échec se produit ;
- proposer une correction robuste et durable ;
- lister les cas limites à vérifier.
Format :
1) Analyse
2) Cause racine
3) Correctif propose
4) Vérifications à faire
Ce prompt sert à améliorer la lisibilité, la testabilité et la structure sans changer le comportement fonctionnel ni l'API publique.
Tu es un expert en refactorisation.
Objectif :
- améliorer la lisibilité ;
- réduire la complexité ;
- clarifier les responsabilités.
Contraintes :
- pas de changement d'API publique ;
- pas de nouvelle dépendance ;
- meme comportement fonctionnel.
Format de sortie :
1) Plan de refactor
2) Patch proposé
3) Risques
4) Étapes de validation
Code :
{{CODE_SNIPPET}}
Bon point de départ pour obtenir un plan de tests axé sur les branches critiques, les erreurs et les cas limites plutot qu'une couverture artificielle.
Tu es un expert QA.
Génère un plan de tests exhaustif.
Concentre-toi sur :
- les branches critiques ;
- les cas d'erreur ;
- les cas limites ;
- les hypothèses implicites.
Format :
1) Stratégie
2) Cas de tests priorisés
3) Risques restants
Specification :
{{SPEC}}
Utile pour obtenir une première passe sur les validations d'entrée, injections, gestion des secrets, contrôle d'accès et erreurs d'exposition.
Tu es un expert sécurité.
Fais une revue rapide de ce code.
Attendu :
- risques critiques ;
- risques modérés ;
- recommandations concrètes.
Ne te limite pas au symptome. Signale aussi :
- injection ;
- validation insuffisante ;
- exposition d'informations sensibles ;
- contrôles d'accès fragiles.
Code :
{{CODE_SNIPPET}}
Structure utile pour demander une migration progressive et prudente, avec typage strict et preservation de l'API publique.
Migre ce code JavaScript vers TypeScript.
Contraintes :
- strict mode ;
- pas de changement d'API ;
- pas de dépendances supplémentaires.
Format :
1) Plan
2) Code TypeScript
3) Points d'attention
Code :
{{CODE_SNIPPET}}
Cette page peut servir pour revoir un module PHP, auditer un service Python, générer un plan de tests, préparer une migration JS vers TypeScript, vérifier une couche d'accès aux données ou cadrer une revue de sécurité.
Exemples métier fréquents : relire une procédure d'import CSV, vérifier un script BAT de sauvegarde, auditer un module Oracle d'accès aux données, contrôler un Dockerfile ou documenter un petit outil interne.
Les points d'entrée les plus utiles pour cette page sont l'application locale, get-fiches-list.php, save-fiche.php, get-sujets-list.php et save-sujet.php pour travailler analyse, debug, refactor et validations.
Cette page sert aussi à relire un flux plus transversal en croisant REST / JWT, Oracle SQL, Docker et les scripts locaux autour de start-admin.ps1.
Si vous traitez souvent les mêmes types de sujets backend, il devient utile de stabiliser ce cadre : quelques instructions de projet pour fixer les interdits, des prompt files pour les cas récurrents, et un agent plus spécialisé si les revues ou refactors multi-fichiers reviennent souvent.
Pour le cadrage de système, consultez les prompts architecture. Pour transformer du code ou des specs en pages lisibles, consultez les prompts documentation. Pour régler les usages avancés, consultez aussi Copilot / VS Code avancé et les agents, skills et instructions. Pour les sujets Oracle SQL, PL/SQL et accès aux données, consultez la page Oracle. Pour une revue orientée risques, API et contrôles d'accès, consultez la page sécurité applicative. Pour les flux, les jeux de données et la non-régression, consultez aussi la page tests de flux et données. Pour les flux de test, les données et la non-régression, consultez aussi la page QA / test. Pour débuter ou choisir un point d'entrée simple, consultez aussi les prompts pour débutants et le parcours débutant par besoin. Pour enchaîner les étapes ou contrôler votre travail, consultez les workflows et les checklists. Pour les techniques avancées de formulation, consultez aussi l'ingénierie de prompt avancée.
Cette page couvre le coeur du développement. La suite naturelle est d'ajouter encore des recettes ciblées par contexte : import/export, exploitation applicative, sécurité applicative et usages plus directement reliés aux différents métiers de l'informatique.