Beaucoup d'échecs ne viennent pas d'un mauvais outil, mais d'un mauvais cadrage : objectif flou, contexte absent, trop de demandes à la fois, aucune validation demandée, ou confiance excessive dans une réponse non vérifiée. Cette page sert à repérer vite les erreurs fréquentes avant qu'elles n'abîment le travail.
Exemple : "corrige ce bug" sans contexte, fichier, comportement attendu ni contrainte.
A faire : préciser symptôme, contexte, contraintes et validation attendue.
Exemple : analyser, refactorer, tester, documenter et sécuriser en une seule demande massive.
A faire : séparer analyse, plan, implémentation, tests et synthèse.
Exemple : appliquer un correctif ou reprendre une synthèse sans rejouer de contrôles.
A faire : demander explicitement validations, risques et zones non couvertes.
Exemple : oublier les valeurs limites, champs absents, doublons ou formats incohérents.
A faire : cadrer les flux, les jeux de données et la non-régression.
Exemple : demander "c'est sécurisé ?" sans angle sur entrées, droits, secrets ou sorties.
A faire : demander une revue classée par risques et validations restantes.
Exemple : une page longue sans public cible, sans plan clair, sans exemples ni fiche courte.
A faire : préciser public, structure, exemples et limites à documenter.
Si vous voyez que votre demande tombe dans un de ces anti-patterns, revenez d'abord à prompts débutants, avant / après ou checklists débutants avant de remonter en complexité.
Ces erreurs se voient vite sur des sujets comme save-fiche.php, start-admin.ps1, fiches.json, REST / JWT ou DEPLOIEMENT.md quand le contexte, les contraintes ou la vérification sont insuffisants.