Anti-patterns du prompting
Les erreurs de prompting les plus courantes quand on travaille avec un agent de coding, et comment les eviter pour tirer le meilleur de chaque session.
Le principe fondamental
La majorite des mauvais resultats d’un agent de coding viennent d’un mauvais prompt, pas d’un mauvais modele. La regle diagnostique du Core Four (Prompt, Context, Tools, Model) place le prompt en premiere position pour une raison simple : c’est le levier le moins cher et le plus impactant.
Point cle : Avant de changer de modele ou d’ajouter des outils, verifier que le prompt est clair, specifique et complet. C’est presque toujours la que se trouve le probleme.
Connaitre les anti-patterns du prompting permet d’eviter les erreurs les plus frequentes et de produire des resultats corrects des le premier essai.
Le mega-prompt
Regrouper plusieurs taches heterogenes dans un seul prompt massif : creer un service, ecrire les tests, mettre a jour la doc, migrer la base de donnees. L’agent perd le fil entre les sous-taches. Certaines seront oubliees, d’autres mal executees.
Point cle : Un prompt = une tache verifiable. Decomposer en etapes sequentielles permet de valider chaque resultat avant de passer au suivant.
Le mega-prompt est tentant parce qu’il donne l’impression d’aller vite. En realite, le temps perdu a corriger les oublis depasse largement le temps gagne.
Le prompt vague
Des formulations comme “ameliore les performances”, “rends ce code plus propre”, “refactore le module de paiement”. Ces termes sont subjectifs — l’agent doit deviner ce que “propre” signifie pour vous.
Un prompt vague produit un resultat generique. Un prompt precis produit un resultat utile.
| Vague | Precis |
|---|---|
| Ameliore ce code | Extrais la logique de calcul de TVA dans un TaxCalculator injectable |
| Rends ca plus testable | Remplace l’appel direct a HttpClient par une interface IOrderApi |
| Corrige les performances | Ajoute un cache en memoire sur GetProductById, TTL 5 minutes |
La sur-specification
L’inverse du prompt vague : dicter chaque ligne, chaque nom de variable, chaque instruction. Le prompt devient aussi long que le code attendu. On transforme l’agent en editeur de texte vocal.
Le risque principal : le moindre oubli dans la specification produit un code incomplet. Et on perd la capacite de l’agent a proposer des solutions idiomatiques — il suit les instructions a la lettre sans completer les lacunes.
Point cle : Decrire l’intention, les contraintes et les patterns a suivre. Laisser l’agent proposer l’implementation. Verifier le resultat.
Ignorer les erreurs
Quand l’agent produit un mauvais resultat, la reaction correcte est de corriger le prompt. Pas de changer de modele, pas de relancer le meme prompt en esperant un resultat different.
La regle Core Four donne l’ordre de diagnostic :
- Prompt — la demande est-elle claire ?
- Context — l’agent a-t-il les informations necessaires ?
- Tools — a-t-il les bons outils pour verifier son travail ?
- Model — seulement en dernier recours
Changer de modele sans corriger le prompt reproduira probablement le meme probleme.
L’absence de contexte
Dire “ajoute la validation FluentValidation pour CreateOrderCommand” sans mentionner que les validateurs vivent dans Application/Validators/ et pas a cote des handlers. L’agent applique la convention la plus courante, qui n’est pas forcement celle du projet.
Ce probleme se resout de deux facons : mentionner les conventions dans le prompt, ou mieux, les documenter dans un fichier de configuration persistant (CLAUDE.md ou equivalent) pour ne pas avoir a les repeter.
Le prompt sans critere de succes
Ne pas indiquer comment verifier que le resultat est correct. “Ajoute un endpoint” — mais avec quels tests ? Quels status codes ? Quelle validation des inputs ?
Un bon prompt inclut un critere de verification : “les tests existants doivent passer”, “le endpoint retourne 201 avec le header Location”, “la validation rejette un email vide avec un 400”.
La conversation au lieu du prompt
Enchainer 15 micro-corrections dans la meme session : “non pas comme ca”, “ajoute aussi X”, “en fait change Y”. Le contexte se remplit d’instructions contradictoires et de versions obsoletes.
Attention : L’agent ne “supprime” pas les anciennes instructions. Elles restent dans le contexte et influencent les reponses suivantes. Apres 10-15 echanges, le rapport signal/bruit est tres defavorable.
La solution : apres 2-3 corrections, reformuler un prompt propre qui integre toutes les clarifications et relancer une session neuve.
Recapitulatif
| Anti-pattern | Symptome | Correction |
|---|---|---|
| Mega-prompt | Sous-taches oubliees ou mal executees | Un prompt = une tache verifiable |
| Prompt vague | Resultat generique, pas adapte au projet | Specifier le quoi, le ou, le comment verifier |
| Sur-specification | Code fragile, capacites de l’agent sous-utilisees | Decrire l’intention et les contraintes, pas chaque ligne |
| Ignorer les erreurs | Memes problemes malgre le changement de modele | Suivre la regle Core Four : Prompt d’abord |
| Absence de contexte | Placement incorrect, conventions non respectees | Mentionner l’architecture, ou utiliser un CLAUDE.md |
| Pas de critere de succes | Resultat invérifiable | Inclure la condition de validation dans le prompt |
| Conversation au lieu du prompt | Degradation progressive de la qualite | Reformuler un prompt propre apres 2-3 corrections |
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.