Erreurs de code IA :4 façons dont Claude sabote votre code

Les erreurs de code IA ne sabotent pas votre base de code avec du code qui plante. Elles la sabotent avec du code qui marche — pendant environ six mois. Claude se trompe avec assurance en permanence, et la version dangereuse n'est pas quand il a manifestement tort. C'est quand il a plausiblement tort : du code qui compile, s'exécute et semble correct, bâti sur une hypothèse erronée à propos de vos données ou de votre logique métier.

Pendant les onze mois de construction de FIKR Space, les mêmes quatre mauvais schémas sont sortis de l'IA encore et encore. Chacun aurait créé un type de douleur différent et précis six mois plus tard si je l'avais accepté. Les voici en langage simple — ce que Claude propose, pourquoi cela paraît raisonnable, et ce que cela vous coûte exactement plus tard.

Pourquoi l'IA tombe par défaut sur du code médiocre

Claude a été entraîné sur des millions de bases de code, dont la plupart étaient médiocres. Quand vous ne précisez pas ce que vous voulez, vous obtenez la production médiane — pleine de raccourcis et de compromis que des ingénieurs expérimentés n'accepteraient jamais. Aucun de ces raccourcis n'échoue aujourd'hui. Tous échouent plus tard, ce qui est exactement la raison pour laquelle ils passent la relecture d'un fondateur qui vérifie seulement si la fonctionnalité marche à l'instant.

Votre travail n'est pas d'écrire le code. Votre travail est d'être la voix senior du partenariat — de résister quand quelque chose ne sent pas bon, même quand vous ne pouvez pas expliquer tout de suite pourquoi.

Erreur 1 : le blob JSON — un fourre-tout au lieu d'un classeur

Claude vous suggérera de stocker des données structurées dans un blob JSON — un champ flexible qui contient tout — au lieu d'une vraie table avec de vraies colonnes. Voyez cela comme jeter vos documents dans un tiroir fourre-tout au lieu d'un classeur. Le tiroir fonctionne très bien tant qu'il contient dix documents.

Cela m'est arrivé en semaine trois. Claude a proposé de stocker les données d'objectifs stratégiques des utilisateurs — objectifs trimestriels, statut des OKR, indicateurs d'alignement — dans une colonne JSON de la table des utilisateurs. Cela aurait marché. Pendant environ trois mois. Puis j'ai eu besoin de répondre à une question business élémentaire : montre-moi tous les utilisateurs dont l'atteinte des objectifs du T3 est inférieure à soixante pour cent. Avec un blob JSON, répondre revient à ouvrir le tiroir fourre-tout de chaque utilisateur et à lire tout ce qu'il contient avant de pouvoir filtrer — une approche qui tenait à cinquante utilisateurs et serait morte à cinq cents. La corriger plus tard aurait signifié migrer six mois de données clients et réécrire douze services. Résister en semaine trois a coûté une heure de discussion de conception en plus. Reconstruire au sixième mois aurait coûté trois semaines.

Erreur 2 : les enums — graver dans la pierre les options d'aujourd'hui

Un enum est un champ dont les valeurs autorisées sont fixées à l'avance — comme imprimer le menu de votre restaurant au lieu de l'écrire sur un tableau blanc. Claude a un fort penchant par défaut pour les enums dès qu'un champ a un petit ensemble connu de valeurs : niveau d'abonnement, rôle d'utilisateur, type de notification. Chacun paraît évidemment figé sur le moment.

Chacun des miens a fini par nécessiter de nouvelles valeurs dans l'année — un nouveau niveau d'abonnement, un nouveau rôle, une nouvelle catégorie de notification. Et modifier un enum dans la base de données exige un rituel en plusieurs étapes : supprimer des contraintes, recréer le type, mettre à jour chaque ligne. Une table de référence — la version tableau blanc — est une table normale qui grandit en ajoutant une ligne. L'enum enferme la colonne dans la réalité d'aujourd'hui ; la table de référence s'adapte à celle de demain. Même schéma, autre réglage par défaut. Résistez. Exigez la table de référence.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Erreur 3 : les types any — débrancher le détecteur de fumée

Tout le rôle de TypeScript est d'attraper toute une catégorie de bugs avant que vos utilisateurs ne les voient, en vérifiant que chaque donnée a la forme attendue par le code. Quand cette vérification échoue sur quelque chose de complexe, Claude propose parfois de marquer la donnée comme any — ce qui signifie « arrête de vérifier ceci ». L'erreur disparaît. Le build réussit. La fonctionnalité est livrée. Vous venez de débrancher un détecteur de fumée, et il ne se passe rien tant qu'il n'y a pas de fumée.

C'est le schéma le plus insidieux, car le symptôme est invisible. Six mois plus tard, vous modifiez autre chose dans le produit, et l'erreur de type qui aurait dû repérer la casse ne le fait pas — parce que quelque part en amont, un any avale silencieusement le signal. Le bug part en production. Vous l'apprenez par un signalement client. Chaque any que vous acceptez maintenant est un futur mardi après-midi passé à déboguer un problème que le système de types était censé empêcher.

Erreur 4 : l'avalement silencieux des erreurs — des défaillances que personne n'entend

La pire des quatre. Claude écrit parfois l'équivalent de try { ... } catch (e) { return null } — « si quoi que ce soit se passe mal, ne dis rien et renvoie un résultat vide » — et appelle cela une gestion d'erreurs élégante. Ce code passe tous les tests que vous écrivez, parce que vos tests ne déclenchent pas délibérément le mode de défaillance.

En production, quand la vraie défaillance survient, la fonction ne renvoie rien. Silencieusement. Le reste du système ignore que quelque chose s'est mal passé. L'utilisateur voit un écran blanc. L'erreur n'est journalisée nulle part. Vous ne l'apprenez que quand un client se plaint — et même alors vous ne pouvez pas retracer ce qui s'est passé, car aucune erreur n'a jamais été levée. Combattez cela à chaque fois : des défaillances précises, traitées précisément, journalisées bruyamment. Les cinq lignes de code en plus vous évitent la prochaine panne.

Le schéma derrière les quatre erreurs de code IA

La bonne nouvelle : Claude réagit bien quand on le challenge. Quand vous dites « non, je veux ça dans une table séparée, pas dans un blob JSON — et voici pourquoi », il restructure le code avec élégance et améliore souvent ce qu'il avait proposé à l'origine. Le modèle est collaboratif. Il vous suffit d'être la voix senior.

Deux habitudes rendent la résistance systématique plutôt que chanceuse. Briefer correctement l'IA avant qu'elle ne construise quoi que ce soit — c'est la méthode PRP. Et ne jamais laisser la vitesse remplacer la structure — c'est toute la leçon du piège du vibe coding. Précisez. Résistez. Exigez la bonne structure. Cela coûte un peu plus de temps par fonctionnalité, et cela vous achète une base de code que vous pouvez encore faire évoluer au douzième mois, au lieu d'une que vous devez reconstruire.

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 →

Questions fréquentes

Pourquoi le code généré par l'IA cause-t-il des problèmes des mois plus tard ?

Parce que l'IA optimise pour faire fonctionner la demande d'aujourd'hui, pas pour l'évolution du code. Entraînée sur des millions de bases de code pour la plupart médiocres, elle choisit par défaut des raccourcis — blobs flexibles, listes de valeurs figées, vérifications désactivées, erreurs avalées — qui passent tous les tests maintenant et ne révèlent leur coût que lorsque le produit grandit ou change.

Comment repérer du mauvais code d'IA si je ne sais pas lire le code ?

Interrogez le changement et la défaillance, pas la syntaxe. Demandez à l'IA : que se passe-t-il quand on devra ajouter une nouvelle valeur ici ? Comment chercherait-on dans ces données quand il y en aura dix fois plus ? Que se passe-t-il quand cette opération échoue — où va l'erreur ? Si les réponses évoquent des migrations, des réécritures ou « ça ne renvoie rien », résistez.

Dois-je laisser Claude prendre mes décisions d'architecture ?

Non. Claude est un brillant exécutant et un architecte médiocre. Demandez-lui si une donnée doit aller dans une table séparée ou dans une colonne JSON : la réponse est généralement correcte, parfois mauvaise, occasionnellement excellente — et vous ne pouvez pas savoir laquelle si vous n'avez pas développé votre propre goût architectural. Les décisions d'architecture sont les vôtres ; les décisions d'implémentation sont celles de Claude.

Résister à l'IA ne ralentit-il pas la construction ?

Un peu, par fonctionnalité — et c'est le meilleur échange que vous ferez jamais. Résister au blob JSON m'a coûté une heure de discussion de conception en plus en semaine trois. L'accepter m'aurait coûté trois semaines de reconstruction au sixième mois, plus la migration de six mois de données clients.