Prompts IA pour le développement informatique

Des prompts pour faire avancer un vrai travail technique

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.

Mode d'emploi rapide

Commencez par décrire le contexte technique: langage, version, architecture, objectif.
Fixez des contraintes claires: pas de changement d'API, pas de dépendance, ton attendu, niveau de détail.
Demandez un format de sortie stable: plan, analyse, patch, tests, risques.
Exigez une vérification finale ou une liste des points à valider à la main.

Checklist avant d'envoyer un prompt de dev

Le langage et la version sont-ils explicites ?
Le comportement à préserver est-il défini ?
Les interdits sont-ils nommés ?
Le format de sortie est-il imposé ?
La validation attendue est-elle demandée ?

1. Analyse et compréhension d'un code

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

2. Debug et recherche de cause racine

À 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

3. Refactor sans casser l'existant

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}}

4. Génération de tests

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}}

5. Revue sécurité rapide

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}}

6. Migration JavaScript vers TypeScript

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}}

Cas d'usage concrets

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.

Cas du site

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.

Cas ultra-concrets du site

Comprendre l'application locale : "Analyse index.php et explique le flux réel entre interface, lecture et sauvegarde."
Corriger une sauvegarde : "Relis save-fiche.php, propose une cause racine probable et liste les validations à rejouer."
Vérifier une liste : "Analyse get-sujets-list.php sous l'angle flux, erreurs possibles et non-régression."
Croiser plusieurs surfaces : "Relie REST / JWT, Oracle SQL et start-admin.ps1 pour faire ressortir dépendances, risques et validations."

Parcours de dev utiles

Comprendre puis corriger : commencer par l'analyse d'un module, enchaîner sur la recherche de cause racine, puis finir par les validations à rejouer.
Refactor prudent : demander une cartographie locale, proposer un plan de refactor, vérifier les impacts et documenter les risques restants.
Revue backend : croiser flux PHP, accès aux données, validations d'entrée et sécurité applicative avant toute modification.
Évolution d'API : partir d'un endpoint existant, qualifier les entrées et sorties, lister les effets de bord, puis basculer vers architecture ou QA si le sujet s'élargit.

Capitaliser les usages de développement

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.

Instructions de projet : imposer analyse d'abord, API préservée, validations obligatoires et signalement des hypothèses.
Prompt files : garder un cadre stable pour debug, refactor prudent, plan de tests ou revue de sécurité.
Agent dev : utile pour les sujets multi-fichiers quand le périmètre et les validations sont déjà clairs.

Prompts pour instructions et agent backend

Instructions backend : "Propose un fichier d'instructions pour ce workspace : analyse avant patch, API préservée, dépendances interdites sauf justification, validations finales obligatoires."
Prompt file debug : "Transforme ce cas de debug backend en prompt file réutilisable avec symptôme, périmètre, cause racine, correctif prudent et validations."
Agent refactor : "Définis un agent backend spécialisé pour refactor multi-fichiers avec rôle, limites, droits nécessaires et format de sortie imposé."

Version débutant vers intermédiaire

Débutant : demander compréhension, cause probable, correctif prudent et vérifications à rejouer.
Intermédiaire : ajouter interdits, périmètre exact, format de sortie, effets de bord et validations de non-régression.
Quand monter d'un cran : si le sujet touche flux, données ou sécurité, bifurquer vers tests de flux, sécurité ou architecture.

Performance et refactoring avancé

Diagnostic de performance

Analyse ce problème de performance : [SYMPTÔME ET MESURES].
Ne propose pas d'optimisation avant d'avoir classé les hypothèses.
Indique les profils, métriques et expériences nécessaires.
Pour chaque piste : preuve attendue, gain plausible,
risque, coût et test de non-régression.

Cache multi-niveaux

Propose une stratégie de cache pour [FLUX].
Compare navigateur, CDN, application et base de données.
Précise clés, TTL, invalidation, cohérence, stampede,
données sensibles, observabilité et mode dégradé.
Explique aussi quand ne pas mettre de cache.

Audit de dette technique

Audite ce périmètre : [CODE / ARBORESCENCE].
Classe les dettes par impact utilisateur, risque de panne,
frein à l'évolution et coût de correction.
Propose une trajectoire incrémentale avec petits lots,
tests de caractérisation et critères d'arrêt.

Refactor vers SOLID

Évalue ce code au regard de SOLID sans appliquer mécaniquement
chaque principe. Identifie couplages et responsabilités confuses.
Propose le plus petit refactor utile, API préservée,
avec avant/après, compromis et tests nécessaires.

Adapter le prompt au langage

Python	Version, typage, environnement, dépendances, async, formatage et tests.
TypeScript	Configuration stricte, runtime, framework, contrats, validation des entrées et build.
Rust	Ownership, lifetimes, traits, erreurs, concurrence, sécurité mémoire et benchmarks.
SQL	SGBD exact, schéma, volumétrie, index, plan d'exécution, transactions et concurrence.

Avant de proposer du code, confirme langage, version, runtime,
framework, conventions, dépendances autorisées et commandes de test.
Utilise les idiomes du langage et signale toute hypothèse.
Ne change pas l'API publique sans l'indiquer explicitement.

Utiliser l'IA comme une équipe, sans perdre le contrôle

Pour un sujet complexe, séparez les rôles au lieu de demander une réponse monolithique : analyse fonctionnelle, architecture, implémentation, QA, sécurité et exploitation.

Traite cette demande comme une revue en quatre rôles : [DEMANDE].
1) Architecte : frontières, flux et compromis.
2) Développeur : solution minimale et maintenable.
3) QA : cas nominaux, limites et non-régression.
4) Sécurité/exploitation : risques, observabilité et retour arrière.
Confronte les avis, puis propose une synthèse unique et priorisée.

Construire un composant d'interface prêt pour un usage réel

Agis comme un développeur front-end senior. Construis un composant
réutilisable pour [BESOIN] dans [STACK ET VERSION].
Avant le code, définis son API : propriétés, événements, slots ou enfants,
état contrôlé/non contrôlé et dépendances autorisées.

Couvre explicitement :
- affichage responsive et navigation au clavier ;
- libellés accessibles, focus et contraste ;
- chargement, absence de données, succès, erreur et état désactivé ;
- données longues, valeurs manquantes et actions répétées ;
- exemple d'intégration et tests de comportement essentiels.

Respecte les composants et styles déjà présents. N'ajoute pas de dépendance
sans justification et signale les points à vérifier dans un navigateur.

Pour une application complète, commencez par un MVP vertical : un parcours utilisateur utile, son contrat de données, son interface minimale, ses erreurs et ses tests. Ajoutez ensuite les capacités secondaires au lieu de générer toute l'application en un seul bloc impossible à vérifier.

Pages voisines utiles

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. Pour cadrer l'aspect graphique d'une interface, consultez aussi la création visuelle.

← Retour à la rubrique IA