Aller au contenu principal

6 mois avec Claude Code : ce sur quoi je m'étais trompé

Un développeur relit le travail produit par un agent IA sur son projet web

En janvier, j'ai publié ici un retour d'expérience sur la refonte de ce site avec Stitch, ChatGPT et Gemini. Je le terminais par une promesse et par une conviction.

La promesse : « je n'ai utilisé les IA que via leurs interfaces web. Je n'ai pas utilisé d'agents autonomes ou intégrés à l'IDE pour la génération du code. Ce sujet, bien plus vaste, sera traité dans un prochain article. » Voici cet article.

La conviction, c'est plus embarrassant :

Je n'envisage pas que des agents Claude puissent générer l'intégralité de l'application à partir de User Stories. Je suis d'ailleurs sceptique quant à la faisabilité d'une telle approche.

Six mois plus tard, l'essentiel de ce que vous lisez sur ce site — le code comme les contenus — est passé par un agent. Je m'étais trompé.

Pas sur tout, et la partie qui tient est justement celle qui compte : j'y reviens plus bas. Mais sur ce paragraphe-là, oui. Je préfère l'écrire moi-même plutôt que de laisser un article vieillir en silence en espérant que personne ne remonte le fil.

Les chiffres, d'abord

Un aveu sans chiffres n'est qu'une opinion qui a changé. Voici la matière, extraite du dépôt Git de ce site. Depuis la publication de l'article de janvier :

Et la répartition dans le temps, qui est la partie intéressante :

Ce trou de janvier suivi d'un pic à 205 commits sur février-mars, ce n'est pas une soudaine disponibilité dans mon agenda. C'est une courbe d'apprentissage. Je vais la détailler, parce que c'est là que se trouve l'explication de mon erreur.

Janvier, février, mars : la chronologie d'un basculement

Janvier — la prise en main

Six commits. J'installe Claude Code, je l'essaie sur des tâches réelles, et je fais exactement ce que fait tout le monde : je lui parle comme à un chat, dans un terminal. Je décris ce que je veux, je regarde ce qui sort, je corrige. C'est mieux qu'un copier-coller depuis une interface web, mais ce n'est pas structurellement différent. Le gain est marginal.

C'est à ce moment-là que j'écrivais l'article de janvier. Et c'est précisément ce qui explique ma conclusion : je jugeais l'outil sur ma première semaine d'usage. J'avais raison sur ce que je constatais. J'avais tort d'en tirer un pronostic.

Février — la question de l'industrialisation

85 commits, et un changement de question. Je cesse de demander « est-ce que ça code bien ? » pour demander « comment est-ce que je cadre ça ? ». C'est le réflexe d'ingénieur qui aurait dû être le premier, et qui arrive avec un mois de retard.

Concrètement, j'écris le contexte. Pas dans une fenêtre de chat : dans le dépôt. Les conventions du projet, l'architecture des modules, la ligne éditoriale, les recettes pour ajouter un article ou un terme de glossaire, les garde-fous — ce qu'il ne faut jamais faire, les noms qui ne doivent jamais apparaître. Puis des règles transverses, des commandes, des agents spécialisés, des hooks de vérification.

Février n'est pas un mois de production. C'est un mois d'outillage. Les 85 commits sont surtout la conséquence d'avoir enfin un cadre qui tient.

Mars et après — tout passe par Claude

120 commits en mars. À partir de là, il n'y a plus de bascule à raconter : le glossaire, les guides, les pages villes, les modules entiers, tout se fait à travers Claude Code. Pas « avec l'aide de », à travers. Je décris l'intention et les contraintes, l'agent lit le cadre qu'on a écrit ensemble, produit, et je relis.

La courbe est explicite : le mois de cadrage n'a pas ralenti le projet, il l'a rendu possible. C'est exactement l'argument que je défendais en janvier sur l'industrialisation — je ne l'avais simplement pas appliqué à l'IA elle-même.

Ce qui a changé le verdict, et une seule des trois raisons est l'IA

1. Le modèle a franchement progressé

C'est la raison la plus simple et la moins intéressante, mais elle est réelle : entre janvier et juillet, l'écart de capacité est net. Sur des tâches identiques — reprendre un module existant, respecter une convention, tenir une cohérence sur plusieurs fichiers — ce qui échouait au premier trimestre passe aujourd'hui.

Si je n'avais que celle-là à avancer, cet article serait un billet de fanboy. Le point important, c'est que les deux autres raisons ne dépendent pas d'Anthropic.

2. Le contexte est devenu un artefact du dépôt, pas une conversation

C'est le vrai basculement, et c'est ce que je n'avais pas vu venir.

En janvier, ma description du contexte était juste mais datée : « l'IA ne connaît rien, ni de moi, ni de mon activité, ni de mes attentes ». Ma solution était un « projet » ChatGPT et une Gem Gemini — c'est-à-dire du contexte qui vit à côté du code, dans un compte, chez un éditeur, qu'il faut maintenir à la main et qui dérive dès que le projet bouge. Je décrivais moi-même le processus comme du copier-coller.

Aujourd'hui, ce contexte est un fichier versionné à la racine du dépôt. Il est relu en revue, il évolue avec le code, il est daté par l'historique Git. Quand une convention change, elle change à un endroit, dans le même commit que le code qui l'applique. Ce n'est plus de la configuration d'outil : c'est de la documentation exécutable.

La différence n'est pas cosmétique. Un contexte dans un chat, c'est un savoir tacite qui s'évapore. Un contexte dans le dépôt, c'est un actif — versionné, partagé, testable. J'ai passé quinze ans à défendre cette idée pour le code. Il m'a fallu un mois pour comprendre qu'elle s'appliquait telle quelle à l'IA.

3. J'ai appris à m'en servir

La troisième raison est la moins flatteuse. En janvier, je jugeais un outil que je ne savais pas utiliser.

C'est un biais que je connais pourtant bien : on l'observe à chaque arrivée d'un framework, d'un langage ou d'une méthode. Le premier contact produit un verdict, et le verdict survit à l'apprentissage. J'ai fait exactement ça, avec la conviction d'être lucide parce que je critiquais la hype plutôt que de la relayer.

Résister à la hype et juger trop vite sont deux erreurs différentes. Elles se ressemblent beaucoup de l'intérieur.

Ce qu'est devenu Stitch

L'article de janvier portait Stitch dans son titre. Je ne l'utilise plus.

Ce n'est pas un jugement sur l'outil — ce que j'en disais reste vrai : le rendu est professionnel, le responsive est excellent, l'effet est immédiat. Le problème n'a jamais été le design, c'était ce qu'il y avait dessous. J'y consacrais une section entière : chaque page exportée dupliquait tout, aucune factorisation, des largeurs différentes d'une section à l'autre, des boutons identiques codés de trois façons, des valeurs en dur partout, des dépendances en CDN. Je résumais ça d'une phrase : la dette technique est immédiate. Et plus de 50 % du code généré passait au refactoring manuel.

Claude Code ne supprime pas cette dette : il l'empêche d'exister. La différence tient à un mot — il écrit dans un projet, pas dans le vide. Il lit le thème en place, les composants existants, les conventions du dépôt, et produit du code qui s'y insère. Il n'y a plus de traduction à faire entre une maquette autonome et une base de code, donc plus de refactoring de traduction.

C'est la boucle bouclée de l'article de janvier : le problème que j'attribuais à Stitch n'était pas un problème de génération, c'était un problème de cadre. Un outil qui ne connaît pas votre projet produira toujours du code à retravailler, quelle que soit sa qualité.

Pour les sujets visuels plus ambitieux — explorer une direction, travailler une maquette avant de coder — j'utilise Claude Design, encore en bêta au moment où j'écris. L'intérêt n'est pas le canvas : c'est qu'il importe le design system existant — couleurs, typographies, composants — au lieu d'inventer le sien à chaque écran. Il est joignable depuis Claude Code via un serveur MCP, ce qui referme la boucle avec la base de code.

C'est le renversement exact de la prémisse. Stitch partait d'un prompt et produisait un artefact autonome dont j'héritais la dette. Un outil qui part du système existant n'a pas cette dette à produire. Sa limite documentée le dit d'ailleurs mieux que moi : l'import d'un design system ne vaut jamais mieux que le design system source. Autrement dit, l'outil ne fabrique pas la cohérence — il la propage si elle existe déjà. Et la fabriquer, c'est toujours le travail de quelqu'un.

Le ratio s'est inversé — et ça ne veut pas dire ce qu'on croit

En janvier, je chiffrais la répartition : l'industrialisation et l'optimisation représentaient plus de 75 % du temps total. L'IA produisait, je passais l'essentiel de mon temps à réparer, factoriser, cadrer.

Aujourd'hui, c'est environ 80 % Claude Code, 20 % relecture. Le rapport s'est inversé.

Mais attention à la lecture facile. « 20 % de relecture » ne veut pas dire que je travaille cinq fois moins : ces 20 % s'appliquent à un volume sans commune mesure avec celui de janvier. Rapporté aux +81 500 lignes et aux 280 commits plus haut, un cinquième du temps passé à relire, c'est beaucoup de relecture en valeur absolue. Le travail n'a pas disparu, il a changé de nature : moins de production, plus de jugement.

C'est très exactement ce que j'écrivais en janvier — « l'IA ne rend pas la création triviale, elle déplace le coût ». Cette phrase-là n'a pas bougé d'un millimètre. C'est l'ampleur du déplacement que j'avais sous-estimée, pas sa direction.

Le budget : ce que j'ai coupé, ce que j'ai gardé

L'article de janvier listait mes outils. Le tableau a changé.

Coupés — ChatGPT Plus et JetBrains AI. Le premier parce que son rôle (le contexte de l'entreprise, la génération de prompts, le SEO technique) a été absorbé par un cadre versionné plus fiable que n'importe quel « projet » chez un éditeur. Le second parce qu'un agent qui a accès au dépôt entier rend l'assistant d'IDE redondant.

Gardés, mais déplacés — Gemini, qui ne touche plus au code ni à la rédaction, et me sert pour tout le reste : les questions de fond, le droit, l'économie, la compta. J'y ai ajouté NotebookLM pour le suivi des dossiers complexes, là où il faut interroger un corpus de documents plutôt que produire quelque chose.

Ajouté — un abonnement Claude Max, à 180 € HT par mois. Une seule ligne : Claude Code et Claude Design y sont inclus et puisent dans le même budget de session.

Le budget outillage a donc été multiplié par trois environ. Et c'est là qu'il faut être honnête sur l'arbitrage, parce qu'il est trivial : 180 € HT, c'est moins de deux heures de travail facturable. La question n'est pas « est-ce que ça vaut le coup », elle est réglée avant même d'être posée. La vraie ressource contrainte n'est pas l'argent — c'est le budget de session : ces abonnements ouvrent une fenêtre d'usage glissante, pas un quota de jetons. On n'arbitre plus en euros, on arbitre en fenêtres.

Ce qui ne veut pas dire que le coût du projet a baissé. Il est ailleurs, dans le temps d'un profil senior — et c'est le sujet de la suite.

Ce que je maintiens, et pourquoi c'est le cœur du sujet

La responsabilité finale est toujours la mienne. Ce n'est pas une clause de style pour amortir le mea culpa, c'est le seul point de l'article de janvier qui soit sorti renforcé de ces six mois.

Mais la formulation exacte compte, et je l'affine :

Je gagne énormément de temps parce que je sais ce que je fais. Pas l'inverse.

L'agent produit vite et bien. Il ne sait pas que cette abstraction va coûter cher dans six mois, que ce contournement va se payer à la première montée en charge, que cette dépendance est un piège, que ce choix d'architecture est correct techniquement et absurde pour le métier. Il ne sait pas ce qu'il ne sait pas.

Relire 20 % du temps un volume dix fois supérieur, ça ne s'improvise pas. Ça suppose de repérer une incohérence subtile en diagonale, de savoir quand la solution proposée est bonne et quand elle est seulement plausible. C'est de l'expertise, elle ne s'obtient pas par abonnement, et c'est précisément ce qui fait la différence entre un gain de temps et une dette invisible.

Je n'avais pas de preuve de cette affirmation en janvier. J'en ai une maintenant, et elle m'est arrivée par surprise.

L'angle mort : quand le client s'y met aussi

C'est la chose que je n'avais pas anticipée du tout, et de loin la plus instructive de ces six mois.

Certains clients se sont mis à Claude Code. Ils m'envoient désormais des merge requests, ouvrent des issues GitHub, rédigent des spécifications — le tout généré par IA. L'intention est excellente : gagner du temps, arriver avec quelque chose de concret, participer.

Le résultat est contre-productif.

Sans compétence technique pour trier, ce qui arrive est massif, ultra-verbeux, et souvent faux. Une demande de trois lignes devient deux pages décrivant un problème mal identifié. Une spécification énumère des contraintes contradictoires, avec l'assurance tranquille du texte bien écrit. Une merge request touche quinze fichiers pour un correctif qui en demandait un, et fait passer les tests en corrigeant les tests.

Et je dois tout relire. La charge n'a pas disparu : elle s'est déplacée sur moi, en pire — parce que relire du volume plausible coûte plus cher que lire une demande courte et honnête. J'écrivais en janvier que valider une génération peut demander plus d'effort que produire soi-même. Je parlais du code. Ça vaut pour les demandes.

Le mécanisme est le même que celui de mon propre mois de janvier, à un détail près : moi, j'avais l'expertise pour voir que ça ne marchait pas et pour construire le cadre qui manquait. Sans ce socle, l'outil n'amplifie pas la compétence — il amplifie l'écart. Il rend un non-technicien très rapide à produire du texte technique qu'il ne peut pas évaluer.

Ce n'est pas un reproche à ces clients, et surtout pas un argument pour qu'ils s'en abstiennent. C'est un constat sur ce que l'outil fait réellement : il ne comble pas un manque d'expertise, il le déguise. Ce qui aide vraiment, c'est ce qui a toujours aidé — dire le besoin métier, le contexte, la contrainte, et laisser la traduction technique à qui en porte la responsabilité.

Le même outil, entre les mains de qui sait juger, multiplie le débit. Entre les mains de qui ne sait pas, il multiplie le volume à trier.

Ce que je réécrirais

En relisant l'article de janvier, ce qui frappe n'est pas qu'il soit faux. C'est qu'il soit juste presque partout, et qu'il se trompe pile à l'endroit du pronostic.

Ce qui tient, six mois après :

Ce que je corrige :

La conclusion de janvier disait : « l'IA est un junior très rapide et les seniors n'ont jamais été aussi nécessaires pour cadrer, vérifier et industrialiser ». Je la garde mot pour mot. J'avais simplement sous-estimé à quel point ce junior irait vite une fois qu'on aurait pris la peine de l'encadrer sérieusement — et à quel point l'absence de senior deviendrait visible partout ailleurs.

Message clé

Je m'étais trompé sur les agents, pas sur l'ingénierie. Un agent tient un projet entier — à condition qu'un senior ait construit le cadre. Sans ce cadre, il ne produit pas de la vitesse, il produit du volume à trier.

Une équipe qui veut industrialiser l'IA sans y laisser sa maintenabilité ? Parlons de votre contexte — le cadrage initial est offert.

Photo d'Emmanuel BALLERY, fondateur de x10

À propos de l'auteur

Emmanuel BALLERY est le fondateur de x10 solutions. Expert en architecture logicielle et passionné par la qualité du code (Software Craftsmanship), il aide les entreprises à transformer leur dette technique en actifs durables.

Voir plus arrow_forward

Questions fréquentes

Sur quoi vous étiez-vous trompé exactement ? expand_more
Sur le pronostic, pas sur le diagnostic. J'écrivais en janvier ne pas envisager qu'un agent puisse porter l'intégralité d'une application, en invoquant un contexte trop riche et des temps de génération trop longs. Je décrivais des contraintes d'outil et je les ai prises pour une impossibilité de principe. Six mois plus tard, l'essentiel du code et des contenus de ce site est passé par un agent. En revanche, tout ce que je disais du cadrage, de la validation et de la responsabilité finale s'est vérifié.
Pourquoi un mois de cadrage avant de produire quoi que ce soit ? expand_more
Parce qu'un agent ne se juge pas sur une semaine d'usage. En janvier, je lui parlais comme à un chat dans un terminal : le gain était marginal, et c'est ce que j'ai pris pour une limite de l'outil. Février a servi à écrire le contexte dans le dépôt — conventions, architecture, recettes, garde-fous — au lieu de le maintenir à la main dans un compte chez un éditeur. Les 85 commits de février puis les 120 de mars sont la conséquence directe d'avoir enfin un cadre qui tient. Le mois de cadrage n'a pas ralenti le projet, il l'a rendu possible.
Le ratio 80 % IA / 20 % relecture signifie-t-il qu'on travaille cinq fois moins ? expand_more
Non, et c'est la lecture piège. Ces 20 % s'appliquent à un volume sans commune mesure avec celui de janvier : rapporté à plus de 81 500 lignes et 280 commits, un cinquième du temps passé à relire reste beaucoup de relecture en valeur absolue. Le travail n'a pas disparu, il a changé de nature : moins de production, plus de jugement. C'est le même constat qu'en janvier — l'IA déplace le coût, elle ne le supprime pas. Seule l'ampleur du déplacement avait été sous-estimée.
Pourquoi ne plus utiliser Stitch pour le design ? expand_more
Parce que le problème n'a jamais été le design, mais ce qu'il y avait dessous : chaque page exportée dupliquait tout, sans factorisation, avec des valeurs en dur et des dépendances en CDN. Plus de 50 % du code généré passait au refactoring manuel. Un agent qui écrit dans un projet existant lit le thème, les composants et les conventions en place : il n'y a plus de traduction entre une maquette autonome et une base de code, donc plus de dette de traduction. Le problème que j'attribuais à l'outil était un problème de cadre.
Un client peut-il utiliser ces outils pour aider son prestataire ? expand_more
L'intention est bonne, le résultat rarement. Des clients passés à Claude Code envoient désormais des merge requests, des issues et des spécifications générées par IA. Sans compétence technique pour trier, ce qui arrive est massif, verbeux et souvent faux — et la charge de relecture se déplace sur le prestataire, en pire, car relire du volume plausible coûte plus cher que lire une demande courte. L'outil ne comble pas un manque d'expertise, il le déguise. Ce qui aide vraiment reste ce qui a toujours aidé : exprimer le besoin métier, le contexte et les contraintes, et laisser la traduction technique à qui en porte la responsabilité.