Erreurs de l'IA en production (et comment les stopper)
Les 10 erreurs de l'IA en production : ce que Claude a mal fait, le bon schéma et l'instruction exacte qui empêche chacune de se reproduire dans votre code.
Les erreurs de l'IA en production sont prévisibles et documentées : elle écrit du code qui marche en démo et échoue en conditions réelles. En construisant ma propre plateforme avec Claude, j'ai tenu un journal de chaque erreur qu'il a faite et qu'il a fallu corriger : 28 leçons récurrentes, chacune avec l'instruction exacte qui l'empêche de se reproduire. Voici les dix qui coûtent le plus cher quand elles passent à travers.
Cette liste n'a pas pour but de vous détourner du développement avec l'IA. C'est l'inverse : parce que les erreurs sont prévisibles, elles sont évitables, avec une phrase dans votre prompt ou une règle permanente dans les instructions de votre projet. Vous n'avez pas besoin d'écrire le bon code. Vous devez reconnaître le mauvais schéma et savoir quoi dire.
Pourquoi l'IA refait toujours les mêmes erreurs
L'IA optimise pour le « happy path » : la version de votre fonctionnalité où les données existent, où l'utilisateur est connecté, où rien n'échoue et où un seul client utilise l'application. Cette version fait une démo magnifique. La production, c'est tout le reste : les sessions expirent, deux utilisateurs cliquent en même temps, des données manquent, et le client A ne doit jamais voir les enregistrements du client B.
L'IA ne saute pas ces points par négligence. Elle les saute parce que vous ne les avez pas demandés, et contrairement à un développeur senior, elle ne complète pas les exigences implicites avec son expérience. Ces quatre comportements de sabotage forment une liste voisine mais différente, que j'ai traitée séparément ; les dix d'aujourd'hui portent sur ce qu'un code de niveau production exige et que l'IA omet par défaut.
Les 10 erreurs de l'IA en production, le bon schéma et l'instruction
| Ce que Claude a fait | Le bon schéma | Comment l'instruire |
|---|---|---|
| A créé un service en double pour une fonctionnalité qui existait déjà | Une seule source de vérité par domaine : étendre le service existant | « Avant de créer un nouveau fichier, vérifie s'il existe un service similaire et étends-le » |
| A laissé les composants d'interface parler directement à la base de données | Trois couches : les composants utilisent des hooks, les hooks utilisent des services, seuls les services touchent à la base | « N'importe jamais le client de base de données dans les composants : respecte l'architecture en 3 couches » |
| A utilisé des types ENUM rigides pour les statuts et les catégories | Des tables de référence qu'on peut étendre sans changer le code | « Pas d'enums : crée une table de référence avec code, nom affiché, ordre de tri et indicateur d'activité » |
| A créé des clés étrangères sans index | Chaque clé étrangère reçoit un index ; les combinaisons de requêtes courantes reçoivent des index composites | « Chaque colonne de clé étrangère doit avoir un index » |
| A construit des tables sans colonne d'organisation | Multi-tenancy dès le jour 1 : chaque table métier est rattachée au client propriétaire des données | « Chaque table métier reçoit organization_id, non nul, en deuxième colonne » |
| A complètement ignoré la sécurité au niveau des lignes | RLS activée sur chaque table, avec des politiques de lecture, d'insertion, de mise à jour et de suppression | « Après la création de toute table, active la RLS et ajoute les quatre politiques limitées à l'organisation » |
| N'a géré que le happy path dans les composants | Quatre états partout : chargement, erreur, vide et succès | « Chaque composant qui récupère des données doit gérer les états chargement, erreur, vide et succès » |
| A laissé les erreurs échouer en silence | Attraper, journaliser avec le contexte et proposer un nouvel essai à l'utilisateur | « Chaque fonction asynchrone gère les erreurs : journalise, lève une erreur lisible, affiche un bouton de nouvel essai » |
| A supprimé définitivement des données sur demande | Suppressions logiques : marquer les enregistrements comme supprimés, conserver les données, permettre l'annulation | « Ne supprime jamais définitivement les données métier : renseigne deleted_at et deleted_by, et filtre-les dans les requêtes » |
| A exécuté des écritures en plusieurs étapes sans transaction | Les écritures liées réussissent ou échouent ensemble, jamais à moitié | « Ces écritures doivent être atomiques : toutes réussissent ou tout est annulé » |
L'ensemble des 28 leçons, y compris la sécurité des types, la journalisation, l'accessibilité, les identifiants codés en dur et la couverture de tests, se trouve dans le cours AI Product Builder, chacune avec du code avant/après et le prompt à copier-coller.
Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →Les deux erreurs qui peuvent tuer votre entreprise
Huit des dix vous coûtent du temps. Deux peuvent vous coûter l'entreprise.
L'absence de multi-tenancy et l'absence de sécurité au niveau des lignes sont des machines à fuites de données. Sans colonne d'organisation sur chaque table, les données de tous vos clients vivent dans un seul tas indivis, et seule la chance dans le code applicatif empêche le client A de voir les enregistrements du client B. La sécurité au niveau des lignes est le mur au niveau de la base de données qui tient même quand votre code a des bugs, et votre code en aura. L'IA saute les deux si on ne le lui dit pas, car rien dans « construis-moi un outil de suivi de projets » ne dit que les entreprises d'autres personnes vivront aussi dans cette base de données.
Rattraper après coup est brutal : ajouter la colonne d'organisation plus tard signifie migrer chaque table, remplir chaque ligne, mettre à jour chaque requête et tout retester. Une phrase dans le prompt initial, ou une semaine de chirurgie de migration plus tard. Choisissez la phrase.
Transformer les corrections en règles permanentes
Corriger l'IA erreur par erreur, c'est lutter contre la marée. Le geste qui s'accumule consiste à écrire chaque correction dans le fichier d'instructions de votre projet, pour que chaque future session démarre avec les règles déjà chargées. J'en ai expliqué le fonctionnement dans le fichier unique qui évite 90 % des erreurs de l'IA. Un bloc de règles aussi court que celui-ci change tout en aval :
Respecte l'architecture en 3 couches. Chaque table reçoit organization_id, des colonnes d'audit et des politiques RLS. Pas d'enums : des tables de référence. Indexe chaque clé étrangère. Suppressions logiques uniquement. Chaque composant gère chargement, erreur, vide et succès. Chaque fonction asynchrone gère les erreurs.
Dix lignes. Écrites une fois. Appliquées à chaque prompt que vous lancerez. C'est la différence entre corriger l'IA et la diriger, qui est le vrai travail, comme je l'ai soutenu dans vous êtes l'architecte.
12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →Questions fréquentes
Si l'IA fait toutes ces erreurs, peut-on construire avec en sécurité ?
Oui, parce que les erreurs sont constantes, pas aléatoires. Un développeur junior fait des erreurs différentes chaque semaine ; l'IA fait les mêmes dix jusqu'à ce que vous écriviez la règle qui arrête chacune. Un mode de défaillance documenté avec une prévention connue en une ligne est un risque d'ingénierie gérable, pas une raison d'embaucher une équipe.
Comment repérer ces erreurs si je ne lis pas couramment le code ?
Relisez avec des questions, pas ligne par ligne. Demandez directement à l'IA après chaque génération : chaque table a-t-elle une colonne d'organisation et des politiques RLS ? Les suppressions sont-elles logiques ? Ce composant gère-t-il les états chargement, erreur et vide ? L'IA est honnête sur ses propres omissions quand on lui pose une question précise : le tableau ci-dessus est en pratique votre liste de contrôle de relecture.
Faut-il corriger ces problèmes dans le code déjà écrit par l'IA ?
Priorisez selon le risque. Corrigez d'abord le duo de sécurité, le cloisonnement par organisation et la sécurité au niveau des lignes, avant d'accueillir de vrais clients, car les rattraper ne fait que se compliquer à mesure que les données grossissent. Les états manquants, la journalisation et les suppressions logiques peuvent être corrigés fonctionnalité par fonctionnalité, au fil de vos passages sur chaque écran.
Où vont concrètement les règles permanentes ?
Dans un fichier d'instructions du projet que votre outil d'IA lit au début de chaque session : pour Claude, un fichier CLAUDE.md dans votre projet. Chaque correction que vous faites est promue dans ce fichier, donc elle n'est faite qu'une seule fois. La mise en place prend quelques minutes et est détaillée dans le guide CLAUDE.md.
À quel point êtes-vous piégé ?
Faites l'Indice d'Asphyxie Corporate, l'évaluation gratuite pour savoir si vous êtes prêt à devenir solopreneur.