Il était 2 heures du matin un mardi quand j'ai réalisé que le système de billing facturait les utilisateurs en double. Le bug était en production depuis six heures. Claude Code avait généré la logique de réconciliation des paiements cet après-midi-là, et je l'avais revue, testée et déployée. Le code semblait parfait. Il passait chaque test. Et il était fondamentalement défectueux.
Voici l'histoire de la création de LemonData : 274 routes API, 46 modèles de base de données et plus de 100 000 lignes de code avec un assistant de codage IA. Pas l'histoire polie du type « regardez à quel point l'IA vous rend productif ». La vraie histoire, avec les échecs, les sessions de debugging à 3 heures du matin et les moments où je me suis demandé si le développement assisté par IA était vraiment une bonne idée.
Le Pitch vs la réalité du développement assisté par IA
Le pitch des assistants de codage IA est séduisant : vous décrivez ce que vous voulez, l'IA l'écrit, vous révisez et vous déployez. En théorie, un seul développeur peut désormais accomplir le travail d'une équipe entière.
En pratique ? Les deux premières semaines ont été incroyables. Claude Code comprenait ma base de code, générait des fonctionnalités complètes, effectuait des refactorisations sur plusieurs fichiers. Je déployais plus vite que jamais dans ma carrière. Le pic de dopamine lié à la résolution si rapide des issues était enivrant.
Puis les premières fissures sont apparues.
La même fonction apparaissait dans trois fichiers différents avec des implémentations légèrement distinctes. Des valeurs de configuration étaient hardcoded à des endroits aléatoires. Les définitions de types se contredisaient d'un package à l'autre. La base de code grandissait vite, mais elle devenait aussi un labyrinthe de code qui « fonctionne, mais je ne sais pas pourquoi ».
Et ce bug de billing ? Claude avait généré une fonction de réconciliation à l'apparence tout à fait raisonnable. Mais elle ne tenait pas compte d'une race condition dans notre flux de confirmation de paiement async. L'IA n'avait aucun moyen de connaître cet edge case parce que je ne le lui avais pas explicitement dit, et la suite de tests, également en partie générée par l'IA, ne l'avait pas couvert non plus.
Les sept patterns qui n'ont cessé de casser
Après un mois de construction avec Claude Code, j'ai commencé à tenir une liste. Pas de bugs à proprement parler, mais de patterns. Les mêmes types d'échecs se répétaient, et ce n'était pas la faute de Claude, du moins pas entièrement. C'était le résultat prévisible d'une IA optimisant pour un « code qui fonctionne maintenant » plutôt que pour un « code qui fonctionne demain ».
1. Le problème de cohérence
Claude implémentait la même logique différemment selon le fichier sur lequel il travaillait, les exemples qu'il avait vus récemment ou, semble-t-il, par simple variation aléatoire. Un endpoint API renvoyait { data: users }, un autre renvoyait { users }. Les deux fonctionnaient. Aucun ne correspondait à l'autre. Le debugging est devenu de l'archéologie.
2. Le problème du copier-coller
Pourquoi une IA créerait-elle un utilitaire partagé alors que dupliquer le code est plus rapide et ne risque pas de casser les fonctionnalités existantes ? Chaque fois que je demandais une nouvelle fonctionnalité ressemblant à une existante, j'obtenais une nouvelle implémentation plutôt qu'une solution partagée refactorisée. Après trois semaines, j'avais cinq fonctions « format currency » différentes éparpillées dans la base de code.
3. Le problème de dérive des types
Une nouvelle valeur de statut était ajoutée à un fichier mais pas à la définition de l'enum. Un champ était optionnel dans la réponse API mais requis dans le type frontend. TypeScript en détectait certains, mais pas les décalages sémantiques, les cas où les types étaient techniquement corrects mais logiquement incohérents.
4. Le problème de dispersion de la configuration
Les URL de base de données, les clés API, les feature flags et les rate limits finissaient là où c'était pratique pour la tâche en cours. Parfois dans des variables d'environnement, parfois dans un fichier de config, parfois hardcoded. Trouver tous les endroits où une valeur était définie devenait une chasse au trésor.
5. L'illusion de la couverture de tests
Les tests générés par IA ont tendance à tester minutieusement le happy path et à ignorer totalement les edge cases. Le bug de billing en était le parfait exemple : la suite de tests couvrait magnifiquement les flux de paiement normaux. Elle n'a jamais testé ce qui se passe lorsque deux confirmations de paiement arrivent dans la même milliseconde.
6. Le problème des échecs silencieux
Claude ajoutait des blocs catch (error) { console.log(error) } qui étouffaient les exceptions. En développement, cela semblait correct car les erreurs apparaissaient dans la console. En production, des échecs critiques étaient loggués silencieusement et oubliés.
7. Le fossé de la documentation
Claude écrit d'excellents commentaires de code. Il écrit de terribles documentations architecturales. Il peut expliquer ce qu'une fonction fait, mais il ne peut pas expliquer pourquoi le système est structuré ainsi, ou quelles contraintes ont mené à une décision de design particulière.
La solution CLAUDE.md
Le tournant est survenu à la troisième semaine, lorsque j'ai créé CLAUDE.md, un fichier à la racine du projet contenant chaque convention, contrainte et décision architecturale que Claude doit connaître.
Pas une documentation pour les humains. Une documentation pour l'IA.
## API Response Format
Always use: { success: true, data: T } or { success: false, error: string }
Never return raw data without the wrapper.
## Currency
Internal storage: USD. Display: formatCurrency(amount, currency, rate).
Never hardcode exchange rates. Never store CNY directly.
## Error Handling
Never use catch(e) { console.log(e) }.
Always use the logger: logger.error('context', { error }).
L'effet a été immédiat. Claude a commencé à suivre les conventions de manière cohérente. Lorsqu'il générait du code violant une règle, je pouvais pointer la ligne spécifique dans CLAUDE.md et il se corrigeait de lui-même.
Mais CLAUDE.md seul ne suffisait pas. J'avais besoin d'une application automatisée.
Construire le filet de sécurité : des CI gates pour le code généré par IA
Nous avons construit un pipeline CI avec des gates qui sembleraient paranoïaques dans une base de code traditionnelle, car elles existent pour intercepter les bugs générés par l'IA avant les utilisateurs :
- Vérification des types sur l'ensemble du monorepo
- Audits SSOT qui vérifient qu'aucune implémentation en double n'existe
- Vérifications de synchronisation des enums entre la base de données et TypeScript
- Validation du format de réponse API
- Security gates pour le code de billing, de permissions et d'authentification
L'idée clé est simple : Claude est un amplificateur, pas un remplaçant. Il amplifie votre productivité, mais il amplifie aussi vos erreurs. Si vous n'avez pas de conventions solides, Claude inventera les siennes, et elles ne seront pas cohérentes. Si vous n'avez pas de vérifications automatisées, les bugs de Claude atteindront la production plus vite que les bugs humains ne le pourraient jamais.
Le bug de billing ne pourrait plus se produire. Pas parce que Claude est devenu plus intelligent, mais parce que le pipeline exige désormais une gestion explicite des race conditions async, vérifiée par une gate qui contrôle le verrouillage approprié dans les flux de paiement.
Ce que signifie réellement « AI Native Development »
Quand je dis que LemonData est une « Infrastructure AI Native », je ne veux pas dire que nous avons ajouté des fonctionnalités d'IA à un produit existant. Je veux dire que tout le processus de développement a été façonné par la réalité du travail avec un partenaire de codage IA.
Notre documentation est plus détaillée qu'elle ne le serait autrement parce que Claude a besoin d'un contexte explicite qu'un coéquipier humain pourrait déduire. Notre système de types est plus strict que nécessaire parce que Claude exploitera toute ambiguïté. Notre pipeline CI comporte des gates qui sembleraient paranoïaques dans une base de code traditionnelle parce qu'elles existent pour intercepter les bugs générés par l'IA avant les utilisateurs.
Le résultat est une base de code qui est en fait plus facile à maintenir que la plupart de celles sur lesquelles j'ai travaillé. Non pas parce que l'IA écrit un meilleur code que les humains, mais parce que la construction pour le développement assisté par IA m'a obligé à rendre explicites toutes les conventions et vérifications qui ne vivent habituellement que dans la tête des développeurs seniors.
Pour en savoir plus sur ce que signifie AI Native en tant que philosophie, consultez What Is AI Native?
Si vous voulez le côté plus pratique « comment commencer à appliquer cela ? », les deux meilleures lectures complémentaires sont le guide de design d'API agent-first et le guide de migration. L'un explique la forme de l'API. L'autre montre à quel point une équipe peut changer de direction rapidement une fois que le workflow est conçu pour le model switching.
Leçons pour les développeurs construisant avec des assistants de codage IA
Si vous commencez un projet avec Claude Code, Cursor ou n'importe quel assistant de codage IA :
- Créez votre
CLAUDE.mddès le premier jour, pas à la troisième semaine comme je l'ai fait. - Automatisez l'application des conventions. Ne comptez pas sur l'IA pour se souvenir des règles.
- Révisez le code de l'IA comme s'il avait été écrit par un développeur junior. Il est rapide et capable, mais il manque de contexte.
- Testez les edge cases manuellement. Les tests générés par IA couvrent les happy paths, pas les race conditions.
- Centralisez la configuration dès le début. Le problème de dispersion s'aggrave rapidement.
- Utilisez un TypeScript strict. C'est votre meilleure défense contre la dérive des types.
- Construisez des CI gates tôt. Elles sont rentabilisées dès la première semaine.
Le referais-je ?
Absolument. Mais je commencerais par CLAUDE.md dès le premier jour au lieu de la troisième semaine. Et je me rappellerais que le multiplicateur de productivité de 10x inclut un multiplicateur de 10x sur les conséquences des erreurs.
La plateforme que nous avons construite, plus de 300 modèles d'IA, une API unifiée, un billing multi-devises et une internationalisation en 13 langues, aurait pris des mois à une équipe traditionnelle. Nous l'avons lancée en 30 jours. Les bugs étaient réels, mais la vélocité l'était aussi.
Le développement assisté par IA n'est pas magique. C'est une nouvelle sorte de discipline d'ingénierie. Et comme toutes les disciplines, elle récompense ceux qui respectent ses contraintes.
FAQ
Un seul développeur peut-il vraiment construire une plateforme de production avec Claude Code ?
Oui, mais avec des réserves. L'IA gère la génération de code et la refactorisation à une vitesse incroyable, mais vous avez toujours besoin d'un jugement architectural solide, de gates de qualité automatisées et de la discipline nécessaire pour tout réviser soigneusement. La vitesse de 10x inclut des bugs 10x plus rapides si vous ne faites pas attention.
Qu'est-ce que CLAUDE.md ?
CLAUDE.md est un fichier d'instructions au niveau du projet que les assistants de codage IA lisent pour obtenir du contexte. Il contient les conventions de codage, les décisions architecturales et les contraintes que l'IA doit suivre. Considérez-le comme une documentation d'onboarding pour votre coéquipier IA.
Comment prévenir les bugs générés par l'IA en production ?
Les CI gates automatisées sont essentielles : vérification des types, audits SSOT, vérification de la synchronisation des enums et gates de sécurité spécifiques au domaine. L'idée clé est que l'IA amplifie à la fois la productivité et les erreurs, vous avez donc besoin de vérifications automatisées pour intercepter les erreurs amplifiées.
Le développement assisté par IA est-il adapté aux systèmes de billing et de paiement ?
Oui, mais avec une prudence accrue. Le code de paiement nécessite une gestion explicite des race conditions, un verrouillage approprié et des tests approfondis des edge cases. Les tests générés par IA ayant tendance à couvrir les happy paths, vous devez tester manuellement les scénarios d'échec et les opérations concurrentes.
LemonData vous donne accès à plus de 300 modèles d'IA via une seule API. Commencez gratuitement et testez la plateforme avec 1 $ de crédits.
