Résumé
Quelques semaines avant d’écrire ces lignes, j’ai demandé à Claude Code d’attaquer une conception que j’avais déjà préparée: pas d’écrire du code, mais de trouver ce qui clochait dans mon raisonnement. La fonctionnalité concernée était une refonte de la gestion des périodes et des années dans mon application. Je la croyais prête. Elle ne l’était pas: la revue a trouvé une règle de validation qui entrait en collision avec une nouvelle règle de correspondance sur sept routes, une migration qui copiait une table sur deux et aurait laissé vides des niveaux entiers de l’organisation, et une faille de sécurité préexistante sur les routes d’actifs dont personne ne s’était soucié.
Le contexte est une vraie plateforme, pas une démo: une plateforme de gestion des actifs logiciels d’entreprise, construite seul en deux mois, avec un backend Spring Boot, un frontend Angular et un contrôle d’accès par rôle à des informations financières. Aucun des trois bugs n’était une erreur de syntaxe. Un compilateur ne les aurait pas vus, et une suite de tests écrite sur les mêmes hypothèses fausses serait passée. C’est le cœur de l’article: l’IA ne supprime pas le besoin de compétence d’ingénierie, elle le déplace de l’écriture du code vers la détection des problèmes de conception et de cohérence que seul le jugement trouve.
L’article montre aussi ma façon de travailler: pas de code d’abord, mais un CLAUDE.md concis et des fichiers de règles, une «équipe d’IA» d’agents spécialisés à responsabilité unique, une boucle de revue où une correction non vérifiée n’est qu’une affirmation. Et il liste les fois où l’IA s’est trompée avec assurance, d’une stratégie de migration inutile à un changement d’un caractère dans un appel de journalisation d’audit qui aurait enregistré des actions sous le nom de l’utilisateur précédent.
La conclusion que j’en tire est une question à se poser sans cesse: non pas si l’IA peut écrire votre code, mais si vous sauriez qu’il est faux. Un bon réglage par défaut n’est pas automatiquement une bonne décision pour votre système; cette connaissance-là reste la responsabilité de l’ingénieur.
Idées clés
- Demander à l’IA d’attaquer la conception avant de la construire: une revue contradictoire déplace les bugs de la production vers la phase de conception.
- Les bugs qui valent d’être trouvés ne sont pas des erreurs de syntaxe: une collision de règles sur sept routes, une migration à moitié faite qui a l’air finie, une règle de visibilité appliquée à un jeu de routes et pas à l’autre.
- Commencer par un CLAUDE.md concis et des fichiers de règles ciblés, puis une équipe d’IA de spécialistes: un agent, une responsabilité; un skill, un but; une tâche, un périmètre.
- Une correction non vérifiée n’est pas une correction, c’est une affirmation: auditer, prioriser, demander, corriger un fichier, ré-auditer.
- L’IA propose une architecture, elle n’en est pas l’architecte autonome: un bon réglage par défaut n’est pas automatiquement une bonne décision pour votre système.
Pourquoi j’ai écrit cet article
Quelques semaines plus tôt, j’avais demandé à Claude Code d’attaquer une conception déjà préparée, une refonte de la gestion des périodes et des années dans mon application. Je la croyais prête. Elle ne l’était pas, et c’est de là que part cet article.