Claude Code a permis de bâtir en quatre mois une application Elixir de production sans écrire une ligne de code à la main

L'auteur raconte une expérience de quatre mois : une application de production en Elixir/Phoenix, construite via Claude Code sans écrire de code à la main. Sur cette période, le projet a atteint 1 702 commits, 3 880 tests et 94,83% de couverture, non sans essuyer deux incidents sérieux en production.

L'ampleur du projet

Il ne s'agit ni d'une démo ni d'un projet personnel, mais d'EasyStocksAI, un service qui évalue plus de 1 000 actions selon 15 métriques. L'application calcule un scoring réparti en quatre blocs, gère des portefeuilles avec historique des transactions, compare les résultats à des stratégies benchmark et affiche des graphiques interactifs. L'auteur a aussi développé un blog doté d'un parseur Markdown sur mesure, capable de transformer tickers et commandes en liens et en graphiques intégrés. La stack n'a rien d'expérimental : Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind et Lightweight Charts.

En chiffres, le projet ressemble davantage à un produit complet qu'à une expérience. La base de code compte 422 mille lignes de code Elixir, plus de 73 mille lignes de tests, plus de 300 modules, 34 workers Oban et 80 migrations de base de données. Les données proviennent de cinq API avec un fallback en cascade : si une source ne répond pas, le système bascule automatiquement sur la suivante. Le tout tourne sur une infrastructure modeste : un VPS chez Vultr et PostgreSQL sur AWS RDS, avec un CI/CD monté sur GitHub Actions.

Comment la qualité a été tenue

Le principal mécanisme de contrôle est le fichier CLAUDE.md, que Claude Code lit à chaque session. L'auteur le décrit comme la constitution du projet : il fixe les commandes obligatoires, les interdits et les règles d'architecture. Sans ces garde-fous, l'IA produit du code qui fonctionne mais reste difficile à maîtriser ; avec eux, elle garde un style cohérent et n'oublie pas le processus. Chaque nouvelle erreur devenait une nouvelle règle, si bien que le document a grandi avec le produit.

• Après toute modification, mix format et mix credo --strict sont obligatoires
• Pas une ligne de code de production sans test qui échoue
• Les float sont interdits pour les données financières, uniquement Decimal
• Dans les workers Oban, interdiction de requêter la base à l'intérieur des boucles
• La base de données fait foi comme source de vérité principale, pas l'état des processus

Par-dessus, l'auteur a séparé les rôles au sein même du développement par l'IA. En mode Director, le modèle s'occupe de l'architecture, des ADR et du plan de modifications ; en mode Implementor, il écrit le code en suivant strictement ce plan, et uniquement en TDD. Le cycle de travail se découpe en trois phases distinctes : brainstorming, plan détaillé, puis exécution par petites étapes de 2–5 minutes. Cette approche élimine la dérive architecturale : une nouvelle session de l'IA lit les ADR, les plans et les fichiers memory, et reprend le projet non pas de zéro, mais à partir d'un contexte déjà consigné.

Quand l'IA a cassé la prod

La partie la plus utile de l'histoire n'est pas dans les chiffres, mais dans l'analyse de deux incidents de production. Dans le premier cas, les workers Oban et les requêtes web partageaient un même pool de 15 connexions PostgreSQL. Au lancement d'un backfill de 923 tâches, l'interface s'est de fait effondrée. Le problème a été résolu par un ObanRepo dédié, doté de son propre pool pour les opérations internes de la file. Les règles ont ensuite intégré un query budget obligatoire pour chaque worker et des limites de concurrence sur les files.

La seconde panne s'est révélée encore plus parlante. L'IA avait ajouté un ConnectionWatchdog pour surveiller la santé du pool et éviter une répétition du premier incident. Mais la supervision est elle-même devenue la cause de la chute suivante : sous charge, des requêtes au timeout agressif ont commencé à tuer les connexions, et le watchdog a mis à terre tout le pool Oban en quelques secondes. Le composant a finalement été supprimé, et la leçon consignée dans la mémoire du projet.

« N'utilise jamais de pooled connections avec des timeouts agressifs

pour la supervision »

L'auteur a par ailleurs intégré à l'application un MCP Debug Server, afin que Claude Code puisse se connecter à la production comme à un outil : lire les logs, inspecter les files Oban, exécuter des requêtes SQL, vérifier les métriques et redémarrer des workers, sans SSH ni débogage manuel. Même là, des limites existent : l'accès est restreint à une liste blanche d'actions, pour que le débogage ne devienne pas une faille de sécurité. La conclusion de l'auteur est simple : l'IA peut tout à fait maintenir une vraie prod, à condition de disposer de règles, de mémoire, de post-mortems et de limites d'accès claires.

Ce que cela signifie

Cette histoire montre que le développement par l'IA peut déjà atteindre le niveau production, mais pas tout seul. Le rôle clé ne revient pas au modèle, mais à la discipline qui l'entoure : TDD, décisions d'architecture, fichiers memory, post-mortems et garde-fous stricts. Si l'humain reste l'architecte et l'éditeur du processus, l'IA accélère réellement la livraison sans que la qualité en pâtisse nécessairement.