Anti-patterns et erreurs fréquentes avec l'IA
Erreurs fréquentes et anti-patterns quand on utilise une IA pour le développement, la documentation, la QA, les scripts, la sécurité ou l'exploitation.
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.
Anti-patterns par contexte
- Développement : demander un patch avant de demander la compréhension du module.
- Architecture : demander une architecture cible sans fournir les contraintes réelles.
- QA : lister des tests sans lier les cas aux flux et aux effets de bord.
- Scripts : oublier chemins, droits, messages d'erreur et procédure de retour arrière.
- Exploitation : documenter l'action sans points de contrôle ni escalade.
- Sécurité : se limiter à des généralités sans regarder entrées, sorties et droits.
Corrections rapides des erreurs fréquentes
- Au lieu de : "corrige ce bug". Demander : symptôme, fichier, contrainte principale et validations à rejouer.
- Au lieu de : "fais une doc". Demander : public cible, format, prérequis, exemples et points de vigilance.
- Au lieu de : "fais les tests". Demander : flux, cas nominaux, erreurs, cas limites et résultat attendu.
- Au lieu de : "vérifie la sécurité". Demander : surface d'attaque, risques classés, corrections prioritaires et vérifications restantes.
Anti-patterns avancés
- Laisser l'outil choisir sans garde-fou : utiliser Auto ou un agent multi-fichiers sans périmètre ni validations explicites.
- Donner trop de droits : autoriser écriture et terminal pour un simple diagnostic ou une revue documentaire.
- Instructions globales illisibles : empiler trop de règles permanentes dans un fichier de projet jusqu'à le rendre inutilisable.
- Few-shot mal choisi : fournir un exemple qui biaise trop fort la réponse au lieu d'illustrer une logique réutilisable.
- Température ou style mal adaptés : chercher une réponse stable avec une consigne trop ouverte, ou demander de l'idéation sur un format trop verrouillé.
Si l'erreur se répète, que faire
- Sur un même type de sujet : créer un prompt file ou un squelette plutôt que réexpliquer le besoin à chaque fois.
- Sur un même projet : poser quelques instructions de projet stables pour réduire les oublis récurrents.
- Sur une tâche sensible : revenir à un workflow en plusieurs étapes avec plan puis vérification.
- Sur une zone multi-fichiers : limiter le périmètre avant de passer à un agent ou à une exécution plus large.
Point d'entrée débutant
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é.
Cas du site
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.