224 000 lignes de code générées avec l'IA : qu'est-ce qui reste du travail humain ?

Note sur la rédaction de cet article

Comme le précédent, cet article a été rédigé avec l'aide d'une IA, puis relu, corrigé et validé par mes soins.

Il s'appuie sur mon expérience de développement de LingRise, sur mes notes de travail et sur un audit technique extrait du code et de l'historique Git. Si les chiffres sont issus de ces traces matérielles, les intuitions, les doutes et les changements de cap relèvent, eux, de l'expérience vécue.

---

Je ne me considère pas comme un virtuose de la technique. Pourtant, depuis septembre 2025, j'ai développé seul un projet qui cumule aujourd'hui près de 224 000 lignes de code, en grande partie générées avec l'aide de l'intelligence artificielle.

Dès lors, une question s'impose : que reste-t-il concrètement de mon travail ?

L'explication simpliste voudrait que l'humain fournisse les idées pendant que la machine tape les lignes. La version inverse prétendrait que l'IA fait tout pendant que l'utilisateur regarde. Les deux visions sont fausses.

Pour mesurer ce qui relève encore d'un effort humain dans un tel volume de code, il faut observer comment la nature des obstacles a évolué au fil des mois : d'abord un défi de cadence, puis un problème de méthode, et enfin un travail d'arbitrage.

La réalité derrière le volume

Pris isolément, un compteur de lignes ne démontre rien. N'importe quel modèle de langage peut aligner des milliers de lignes redondantes ou inutilisables en quelques minutes.

Dans le cas de LingRise, ces 224 000 lignes recouvrent une infrastructure concrète développée sur environ un an :

• TypeScript (~124 000 lignes) : l'application web sous Next.js et l'application mobile en React Native.
• Python (~86 000 lignes) : le moteur de contenu (transcription audio, traduction, génération et validation qualité).
• SQL (~11 000 lignes) : près d'une centaine de fichiers de migration.
• Architecture : 96 routes API, 56 pages utilisateur, 179 composants React, plus d'une soixantaine de tables PostgreSQL et 332 commits.

Ce volume ne fait pas de moi un développeur d'exception. En revanche, il illustre ce qu'une seule personne peut aujourd'hui envisager de construire, mais aussi les pièges que cette abondance fait émerger.

De l'improvisation au besoin de cadre

À mes débuts sur le projet, mon approche n'avait rien de méthodique. J'exposais une idée à l'IA, discutais rapidement des pistes d'implémentation, validais une proposition et passais à la suite.

Tant que le projet tenait dans quelques dizaines de fichiers, ce fonctionnement « freestyle » suffisait largement. L'IA démultipliait ma vitesse d'exécution en me permettant de tester des intuitions que je n'aurais jamais eu le temps de coder manuellement.

La friction est apparue avec l'accumulation des fonctionnalités. Quand une base de code commence à dépendre de choix d'architecture pris des semaines auparavant, ouvrir un prompt vierge pour empiler une brique supplémentaire devient risqué. L'IA sait produire vite, mais elle n'assure pas spontanément la cohérence d'un ensemble grandissant.

Pour éviter l'enlisement, j'ai adopté la méthode BMAD, découverte lors de ma veille technique. Sans être magique, elle a imposé une rigueur indispensable : des étapes explicites, des agents spécialisés et un cheminement balisé allant du recueil de besoins jusqu'à la spécification technique avant la moindre génération de code.

Le bénéfice majeur n'a pas été technique, mais cognitif : j'ai commencé à passer plus de temps sur la clarification des problèmes que sur la demande de solutions. Brainstormer, formaliser des contraintes, faire relire une décision par un agent critique et accepter d'abandonner une idée avant même de la coder ont permis d'assainir le flux de développement.

Pourtant, un projet peut être parfaitement cadré et courir droit dans le mur.

Le piège de l'abondance fonctionnelle

Au départ, LingRise devait couvrir un spectre très large : grammaire, conjugaison, vocabulaire thématique, livres interactifs, analyse de chansons et dialogues guidés. L'IA donne l'impression de pouvoir tout créer très rapidement alors pourquoi ne pas tout créer ?

C'était une illusion. Même avec une méthode solide et des agents efficaces, empiler des sous-produits conduit à un système impossible à tester, à maintenir et à mettre sur le marché.

Le vrai défi a alors basculé : il ne s'agissait plus d'accélérer, mais de savoir s'arrêter.

Pour trancher, j'ai lancé une session avec l'agent bmad-brainstorming. L'objectif n'était pas de lui déléguer le choix? la volonté d'élaguer venait de moi, mais de confronter mes priorités à une contradiction systématique.

À force d'interroger chaque cas d'usage, une ligne directrice claire s'est dégagée : LingRise devait se concentrer sur une proposition forte et lisible. En l'occurrence, l'immersion via des podcasts réels, des transcriptions synchronisées, une traduction mot à mot contextuelle et un module de shadowing pour l'oral. Le reste a été écarté.

C'est là que réside une part essentielle du travail : concevoir un cadre d'évaluation strict pour résister à la tentation de tout construire sous prétexte que le coût de génération est invisible.

Poser la question à la bonne échelle

L'arbitrage technique dépend rarement d'un simple test unitaire. Le pipeline de traduction de LingRise en est un bon exemple.

Sur un échantillon restreint de textes, il est tentant de retenir le modèle le plus sophistiqué sans trop regarder à la dépense. Mais à l'échelle du catalogue complet de l'application, le volume atteignait 2,16 milliards de tokens. (Je n'ai pas vérifié depuis longtemps, mais on est problablement à un chiffre bien plus élevé puisque je génère de nouveaux podcasts tous les jours.)

Les projections financières ont vite recadré le débat :

• DeepSeek : ~1 900 €
• Claude Sonnet : ~30 000 €
• Claude Opus : ~165 000 €

Même l'achat d'une carte graphique dédiée pour tourner en local ne tenait pas la comparaison économique face aux tarifs de certaines API spécialisées.

L'IA peut parfaitement dresser ce tableau comparatif et calculer les ratios. En revanche, elle ne prend pas l'initiative d'évaluer l'impact d'un choix technique à l'échelle d'un modèle économique global : cette responsabilité reste entièrement humaine.

Quand la solution technique masque le vrai problème

Un code généré peut tourner sans la moindre erreur tout en passant complètement à côté de son objectif.

Pour protéger les fichiers audio payants, l'IA m'avait configuré un système d'URL signées temporaires. Tout fonctionnait en apparence. Je n'ai pas découvert la faille moi-même en jouant les experts en cybersécurité : c'est simplement en soumettant le code à /bmad-code-review que le problème a été levé. En raison de ma configuration de stockage et de sous-domaine, la signature pouvait être altérée sans bloquer l'accès au fichier.

La première IA avait appliqué la consigne technique à la lettre, sans sécuriser réellement le contenu. Il a fallu réitérer pour concevoir un système de jetons vérifiés à la volée. Mon travail n'a pas été d'auditer le code à la main, mais de maintenir cette exigence en organisant la contradiction entre plusieurs agents.

L'envers du décor : la dette assumée

Revendiquer 224 000 lignes de code sans évoquer la dette technique serait malhonnête. LingRise comporte des faiblesses évidentes :

• Aucun pipeline d'intégration continue (CI) : les vérifications restent en grande partie manuelles avant déploiement.
• Une migration monorepo inachevée : la structure globale conserve des artefacts historiques à la racine depuis le lancement de l'application mobile.

L'IA permet d'identifier ces chantiers et de rédiger les correctifs à la chaîne. Mais le temps de validation et l'attention restent des ressources finies. Assumer ces manques fait partie du compromis : choisir ses priorités, c'est aussi assumer ce qu'on ne traite pas immédiatement.

---

Au bout de ces onze mois, l'opposition binaire entre « l'humain qui conçoit » et « la machine qui exécute » ne tient plus. Les agents d'IA savent aujourd'hui rédiger des spécifications et proposer des architectures cohérentes.

Le rôle du développeur ne s'est pas pour autant effacé : il s'est déplacé.

Il consiste à repérer le moment où le problème change de nature. À comprendre quand une accélération devient toxique, à refuser de construire de nouvelles fonctionnalités même si elles ont l'air simple à faire générer, à détecter les failles logiques derrière un code propre et à garantir l'équilibre économique d'un système.

L'IA a permis de matérialiser LingRise à une vitesse impensable pour un développeur isolé. Mais la responsabilité de ce qui est construit, et surtout de ce qui ne doit pas l'être, continue de peser sur la même personne derrière l'écran.