Créer une plateforme IA de production avec Claude Code en 30 jours : le récit authentique

Il était 2 heures du matin un mardi quand j'ai réalisé que le système de facturation facturait le double aux utilisateurs. Le bug était en production depuis six heures. Claude Code avait généré la logique de rapprochement des paiements cet après-midi-là, et je l'avais revue, testée et déployée. Le code semblait parfait. Il passait tous les tests. 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, plus de 100 000 lignes de code — avec un assistant de codage IA. Pas l'histoire enjolivée du type « regardez à quel point l'IA vous rend productif ». La vraie histoire, avec les échecs, les sessions de débogage à 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 faire 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 tickets était enivrant.

Puis les fissures ont commencé à apparaître.

La même fonction apparaissait dans trois fichiers différents avec des implémentations légèrement distinctes. Des valeurs de configuration étaient codées en dur à 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 trop pourquoi ».

Et ce bug de facturation ? Claude avait généré une fonction de rapprochement à l'apparence tout à fait raisonnable. Mais elle ne tenait pas compte d'une race condition dans notre flux de confirmation de paiement asynchrone. L'IA n'avait aucun moyen de connaître ce cas limite (edge case) car 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 non plus couvert.

Les sept patterns qui n'ont cessé de poser problème

Après un mois de construction avec Claude Code, j'ai commencé à tenir une liste. Pas de bugs, exactement, mais de patterns. Les mêmes types d'échecs se répétaient, et ce n'était pas la faute de Claude — ou 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 fonctionnera 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 apparemment par simple variation aléatoire. Un endpoint API renvoyait { data: users }, un autre renvoyait { users }. Les deux fonctionnaient. Aucun ne correspondait à l'autre. Le débogage 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 la dérive des types (Type Drift)

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 incohérences sémantiques — les cas où les types étaient techniquement corrects mais logiquement incohérents.

4. Le problème de l'éparpillement de la configuration

URL de base de données, clés API, feature flags, rate limits — Claude les plaçait là où c'était pratique pour la tâche en cours. Parfois dans des variables d'environnement, parfois dans un fichier de config, parfois codés en dur. Trouver tous les endroits où une valeur était définie est devenu 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 chemin nominal (happy path) et à ignorer complètement les cas limites. Le bug de facturation 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 quand deux confirmations de paiement arrivent dans la même milliseconde.

6. Le problème de l'échec silencieux

Claude ajoutait des blocs catch (error) { console.log(error) } qui étouffaient les exceptions. En développement, cela semblait correct — les erreurs apparaissaient dans la console. En production, des échecs critiques étaient loggués silencieusement et oubliés.

7. Le fossé de documentation

Claude écrit d'excellents commentaires de code. Il écrit une documentation architecturale médiocre. 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 conception particulière.

La solution CLAUDE.md

Le tournant est survenu à la troisième semaine, quand j'ai créé CLAUDE.md — un fichier situé à la racine du projet qui contient 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 fut 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 barrières CI pour le code généré par IA

Nous avons construit un pipeline CI avec des barrières (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 :

• Vérification des types sur l'ensemble du monorepo (détecte la dérive des types)
• Audit SSOT qui vérifie qu'aucune implémentation en double n'existe
• Vérification de la synchronisation des enums qui garantit que les enums de la base de données correspondent aux enums TypeScript
• Validation du format de réponse API (règle le problème de cohérence)
• Barrières de sécurité pour le code de facturation, de permissions et d'authentification

L'idée clé : 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 fortes, 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 facturation ne pourrait plus se produire. Non pas parce que Claude est devenu plus intelligent, mais parce que le pipeline exige désormais une gestion explicite des race conditions asynchrones, vérifiée par une barrière qui contrôle le verrouillage approprié dans les flux de paiement.

Ce que signifie réellement « Développement AI Native »

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 a des barrières 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 construire pour le développement assisté par IA m'a forcé à 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 Qu'est-ce que l'AI Native ?

Conseils pour les développeurs construisant avec des assistants de codage IA

Si vous commencez un projet avec Claude Code, Cursor ou tout autre assistant de codage IA :

1. Créez votre CLAUDE.md dès le premier jour — pas à la troisième semaine comme moi
2. Automatisez l'application des conventions — ne comptez pas sur l'IA pour se souvenir des règles
3. Révisez le code de l'IA comme s'il avait été écrit par un développeur junior — il est rapide et capable, mais manque de contexte
4. Testez manuellement les cas limites — les tests générés par IA couvrent les chemins nominaux, pas les race conditions
5. Centralisez la configuration dès le début — le problème de l'éparpillement s'aggrave rapidement
6. Utilisez un TypeScript strict — c'est votre meilleure défense contre la dérive des types
7. Construisez des barrières CI tôt — elles sont rentabilisées dès la première semaine

Est-ce que je le referais ?

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é par 10 inclut un multiplicateur par 10 des conséquences des erreurs.

La plateforme que nous avons construite — plus de 300 modèles d'IA, une API unifiée, une facturation multi-devises, 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 forme 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 créer 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 solide jugement architectural, de barrières de qualité automatisées et de la discipline nécessaire pour tout réviser soigneusement. La vitesse x10 inclut des bugs x10 plus rapides si vous n'êtes pas prudent.

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'intégration pour votre coéquipier IA.

Comment prévenir les bugs générés par l'IA en production ?

Les barrières CI automatisées sont essentielles : vérification des types, audits SSOT, vérification de la synchronisation des enums et barrières 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 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 facturation et de paiement ?

Oui, mais avec une prudence accrue. Le code de paiement nécessite une gestion explicite des race conditions, un verrouillage (locking) approprié et des tests approfondis des cas limites. Les tests générés par l'IA ont tendance à couvrir les chemins nominaux — 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. Nous l'avons construit avec l'IA, pour servir l'IA. Commencez gratuitement — les nouveaux utilisateurs reçoivent 1 $ de crédits.