LES POINTS ESSENTIELS
À retenir
- Décrire un comportement attendu avec un cas concret.
- Fournir l’environnement réel et les contraintes du projet.
- Vérifier le code et les résultats des tests avant de déployer.
À ADAPTER À VOTRE BESOIN
Problème : [comportement actuel et cas concret]. Résultat attendu : [comportement observable]. Environnement : [projet, versions et fichiers connus]. Contraintes : respecte les conventions du dépôt et les modifications existantes. Examine la documentation pertinente avant de changer le code. Vérifie [cas nominal, erreur et limite]. À la fin, explique les changements, les résultats des vérifications et les limites restantes. Ne déploie que dans le périmètre autorisé.
Remplacez les éléments entre crochets, puis vérifiez la réponse obtenue.
Décrire le comportement avant la solution
Présentez le problème avec un exemple. « Un utilisateur perd son formulaire lorsque le serveur refuse l’envoi » donne une situation observable. Ajoutez le résultat attendu : conserver les champs, montrer un message et ne pas afficher de succès.
Évitez d’imposer une technique si elle n’est pas nécessaire. La bonne modification peut être plus petite que la solution imaginée. Si vous avez une contrainte d’architecture, expliquez sa raison : bibliothèque déjà utilisée, compatibilité ou règle du dépôt. Cela permet de distinguer une préférence d’une exigence réelle.
Donner un contexte technique limité et exact
Indiquez le projet, les versions utiles et les fichiers concernés lorsque vous les connaissez. Fournissez une erreur complète sans y inclure de secrets. Un extrait isolé peut masquer un contrat défini ailleurs ; demandez que les dépendances pertinentes soient examinées avant la modification.
Dans un dépôt, les instructions locales et la documentation de la version installée comptent. Une solution valable pour une autre version peut échouer. Le prompt doit donc encourager la vérification de l’environnement réel plutôt que la production immédiate d’un exemple générique.
Écrire des critères de validation
Exemple : « Corrige l’envoi du formulaire. En cas de refus de l’API, les valeurs restent présentes et un message explicite apparaît. La confirmation n’est montrée qu’après une réponse positive attendue. Vérifie aussi une erreur réseau. Respecte les composants et conventions existants. »
Ces critères décrivent des comportements, pas une implémentation à recopier. Ils permettent de relire la modification et de choisir des tests utiles. Pour une action sensible, précisez aussi les droits et les données qui doivent être protégés.
Limiter la portée de la modification
Demandez que les changements sans rapport avec le problème soient évités. Une correction locale n’a pas forcément besoin d’une nouvelle architecture. Dans un projet partagé, les modifications existantes doivent être préservées et les conflits compris avant toute réécriture.
Le résultat doit expliquer les fichiers modifiés, la raison et les vérifications effectuées. Ne considérez pas une commande lancée comme un test réussi : il faut connaître son résultat. Une capture peut montrer un écran ; elle ne remplace pas le contrôle du traitement serveur lorsque celui-ci est concerné.
Faire relire et tester selon le risque
Un développeur doit examiner la logique, les accès, la gestion des erreurs et les dépendances ajoutées. Les essais doivent correspondre au changement. Évitez les tests qui ne font que recopier l’implémentation sans vérifier le comportement demandé.
Si vous ne savez pas évaluer le code, faites accompagner l’intégration et le déploiement. Un prompt clair améliore la collaboration, mais ne transforme pas un brouillon technique en système prêt pour la production. Le bon objectif est une modification compréhensible, vérifiable et proportionnée au besoin.