Prompts pour développeurs : du bug à la revue de code

Tu colles une stack trace, tu écris « corrige », et l'assistant te rend une fonction réécrite qui fait taire l'erreur. Le test passe, parfois parce que le try/except ajouté avale l'exception. Le symptôme a disparu, pas le bug.

Un développeur n'a pas besoin qu'on lui explique ce qu'est un prompt. Il a surtout besoin de réflexes pour empêcher l'IA de foncer vers la première solution plausible. Les modèles ci-dessous forcent ce ralentissement, et ils marchent dans un chat comme dans un assistant de code.

Déboguer : séparer le diagnostic du correctif

La consigne la plus rentable tient en une ligne : pas de code avant le diagnostic. Elle évite de valider une correction fondée sur une cause supposée.

Bug dans [LANGAGE/FRAMEWORK, VERSION SI ELLE COMPTE].

Comportement attendu : [CE QUI DEVRAIT SE PASSER]
Comportement observé : [CE QUI SE PASSE]
Reproduction : [ÉTAPES OU TEST]
Erreur complète :
[STACK TRACE]

Code concerné :
[EXTRAITS]

Ce que j'ai déjà essayé ou écarté : [LISTE]

Ne propose pas encore de correctif.
1. Liste 3 hypothèses classées par probabilité.
2. Pour chacune, donne l'observation du code ou de la trace qui la soutient.
3. Indique la vérification la plus rapide pour la confirmer ou l'exclure (log précis, requête, test minimal).

J'exécuterai ces vérifications et je te donnerai les résultats. Si un fichier te manque pour raisonner, demande-le au lieu de supposer son contenu.

Prends un développeur Rails face à une facture créée en double : ici, les hypothèses auront des chances de porter sur un double envoi du formulaire, un webhook rejoué ou un job relancé, et chacune se vérifie en quelques minutes dans les logs. Ce découpage en deux temps reprend le principe du raisonnement étape par étape, avec en plus un humain qui fournit les faits entre les deux.

Relire un diff, pas un fichier entier

Une revue demandée sans orientation renvoie surtout des remarques de style. Donne le diff, dis ce que le changement doit faire et précise ce qui t'intéresse.

git diff main...HEAD > diff.txt

Tu relis cette pull request.

Objectif du changement : [TICKET OU DESCRIPTION]
Contexte : [STACK, CONVENTIONS, CONTRAINTES DE PERFORMANCE]
Diff :
[COLLE LE DIFF]

Cherche dans cet ordre :
1. Les bugs : cas limites, erreurs non gérées, concurrence, valeurs nulles.
2. La sécurité : injection, contrôle d'accès, données sensibles dans les logs.
3. Les écarts avec l'objectif : ce qui manque et ce qui dépasse le périmètre.

Pour chaque problème, donne le fichier et la ligne du diff, le scénario concret qui le déclenche et la gravité (bloquant, à corriger, mineur). Ignore le formatage et le nommage, un linter s'en charge. Si le diff te paraît correct sur un axe, dis-le simplement plutôt que d'inventer un problème.

La dernière phrase compte. Sans elle, un modèle à qui l'on demande des problèmes a tendance à en trouver à tout prix, y compris dans du code sain.

Sécuriser du code legacy avant d'y toucher

Tu dois modifier une fonction de 300 lignes sans tests, écrite par quelqu'un qui est parti. Demander « refactorise » revient à perdre les comportements non documentés. La bonne séquence commence par des tests de caractérisation, qui figent ce que le code fait aujourd'hui, bugs compris.

Voici une fonction sans tests, en production :
[CODE]

Framework de test : [PYTEST, JEST, PHPUNIT...]

Avant tout refactoring :
1. Décris le comportement réel de ce code, cas par cas, y compris les comportements qui te semblent être des bugs.
2. Écris des tests de caractérisation qui documentent ce comportement actuel, sans le corriger. Marque d'un commentaire les cas qui ressemblent à des bugs.
3. Liste les dépendances à simuler (base, horloge, API) et les zones que tu ne peux pas couvrir sans changer le code.

Ne modifie pas la fonction. Le refactoring viendra dans un second temps, par petites étapes, tests au vert entre chacune.

Lance ces tests sur le code actuel avant d'aller plus loin. S'ils échouent sur le code actuel, c'est le modèle qui s'est trompé sur le comportement, et ces écarts sont précisément ce que tu voulais découvrir. Découpe ensuite le refactoring en une chaîne de prompts : une extraction par message, un commit par étape.

Écrire des tests qui attaquent le code

Quand on lui demande des tests après avoir montré une implémentation, l'IA écrit souvent des tests qui décrivent cette implémentation. Ils passent et ne prouvent pas grand-chose. Oriente-la vers la spécification et les ruptures.

Spécification de la fonction : [RÈGLES MÉTIER]
Signature : [SIGNATURE]
Exemple réel d'entrée et de sortie : [EXEMPLE]

Écris les tests à partir de la spécification, sans chercher à refléter une implémentation.
Couvre les bornes, les entrées invalides, les doublons, les fuseaux horaires et les arrondis si cela s'applique.
Pour chaque test, indique en une ligne quel bug réaliste il attraperait.
Écarte les tests qui ne pourraient échouer que si le langage lui-même était cassé.

Pour une application de réservation de restaurant, ce prompt a de bonnes chances de faire remonter le créneau à cheval sur le changement d'heure, le genre de cas qu'on oublie souvent.

Migration SQL : faire chercher ce qui peut mal tourner

Une migration fonctionne en local et bloque la table en production. L'IA est un bon relecteur pessimiste à condition de connaître le volume et le moteur.

Moteur et version : [POSTGRESQL, MYSQL...]
Taille des tables concernées : [LIGNES]
Trafic : [LECTURES/ÉCRITURES, FENÊTRE DE MAINTENANCE]
Migration :
[SQL]
Code applicatif qui lit ces colonnes : [EXTRAITS]

Analyse :
1. Les verrous pris par chaque instruction et leur effet probable sur ce volume.
2. La compatibilité pendant le déploiement, quand ancien et nouveau code tournent ensemble.
3. Le plan de retour arrière, et ce qui ne peut pas être annulé.
4. Une version en plusieurs étapes si nécessaire.

Si un comportement dépend de la version du moteur, dis-le et indique ce que je dois vérifier dans la documentation.

Trois précautions avant de faire confiance au code généré

Vérifie que ce qui est cité existe. Un modèle peut inventer une méthode, une option ou un paquet. Le risque est réel côté sécurité : un nom de paquet inventé peut être enregistré par un tiers malveillant. Avant d'installer, regarde le registre, l'auteur et l'activité du projet :

npm view [paquet]
pip index versions [paquet]

Ne colle pas ce que tu ne peux pas partager. Clés d'API, chaînes de connexion, données clients et code sous accord de confidentialité n'ont rien à faire dans un outil non validé par ton entreprise. Regarde les conditions de ton offre, car elles varient d'un produit à l'autre, et passe un scanner de secrets sur ce que tu envoies.

Garde la responsabilité de la relecture. Le code généré se relit comme celui d'un collègue, avec en plus la question des licences s'il s'agit d'un produit commercial. Si tu travailles avec un agent qui exécute lui-même des commandes, ses consignes méritent autant de soin que ton code : tout est dans notre guide des instructions pour agents.

Ouvre ton dernier ticket de bug résolu, redonne-le à ton assistant avec le premier prompt et compare ses hypothèses à la vraie cause. Tu sauras vite ce que ton outil vaut sur ta base de code.