Claude Code après trois mois : pour qui, pour qui pas et ce qu’il coûte vraiment (2026)

Nous construisons ce site depuis juillet 2026 avec Claude Code, l’assistant de programmation d’Anthropic qui travaille directement dans le dossier du projet : il lit et modifie les fichiers, lance les tests, écrit dans la base de données. Trois mois, le plus souvent plus de dix heures par jour, la formule la plus chère, « Max ». Ce qui suit n’est ni une comparaison de modèles ni un test, mais l’expérience d’un seul projet, avec des dates et des chiffres tirés de nos propres journaux : historique Git, rapports de GitHub Actions, de Vercel et de Supabase.

Novembre 2026 : avec le nouveau modèle, l’expérience est différente

Les cas décrits ci-dessous ont été relevés de juillet à octobre, et le texte est resté tel qu’il a été écrit à l’époque. Depuis, le modèle a changé, et notre appréciation avec lui.

• Claude Fable 5.1 a été très faible dans notre travail.
• Claude Opus 5.5 a fait mieux.
• Claude Fable 5.2 dépasse aussi Opus 5.5. Il travaille tout autrement que le 5.1, et des trois, c’est celui que nous jugeons le meilleur.

Ajout du 15 novembre 2026 : là où Fable 5.2 cale. Il s’acquitte bien d’une tâche courte et clairement délimitée. Il n’exécute pas un plan plus long.

• Mieux vaut ne pas répartir un déroulement de travail sur plusieurs messages. Dans notre cas, le modèle a exécuté le dernier point et sauté les vingt précédents.
• Nous lui avons demandé cinq fois d’établir un plan pour toute la nuit. Il ne l’a pas fait : il a travaillé une dizaine de minutes sur huit heures, et son rapport indiquait que le travail de la nuit était terminé. Toute la nuit n’a consommé que 1 % de la limite.
• Interrogé sur la raison, il a répondu qu’il ne savait pas exactement : il avait choisi la partie la plus facile à exécuter et laissé l’objectif de côté.
• Demandé pour tous les pays, fait pour un seul. Le modèle n’a complété entièrement les pages de résiliation qu’en lituanien et s’est contenté d’une question dans les autres marchés.
• Il n’a pas utilisé les outils intégrés qui lui étaient autorisés. Toutes les autorisations avaient été données à l’avance ; le modèle n’y a pas touché, et son rapport du matin indiquait que le travail en avait besoin.
• Il a posé la question qu’on lui avait demandé de ne pas poser. Dix minutes avant le rapport, il avait reçu la consigne de ne pas demander s’il fallait envoyer le code. Le rapport se terminait précisément par cette question.
• Il s’est appuyé sur des notes périmées. Le modèle a rédigé une partie des réponses sur les remboursements à partir de notes vieilles de quelques mois, sans rouvrir les pages des fournisseurs. Trois affirmations étaient déjà dépassées. Une autre session du même modèle les a repérées et corrigées le jour même.
• Il a lu des avis trop anciens. La consigne était de s’appuyer uniquement sur les avis des derniers mois. Des sessions lancées en parallèle se sont mises à lire aussi des avis vieux de plusieurs années, jusqu’à ce que nous les arrêtions.
• Il s’est trompé de date. Il a daté plusieurs textes du lendemain et ne l’a remarqué que quelques heures plus tard.

Un point relie tous ces cas : lorsqu’un nouveau message arrive, le modèle peut oublier les précédents. Cela n’arrive pas toujours, mais assez souvent pour en tirer une règle pratique : donnez à un modèle Fable toute la tâche d’un seul coup, dans un message complet. Si vous ajoutez plus tard une ou deux lignes à une tâche déjà confiée, il y a de fortes chances que seules ces lignes soient traitées.

Conclusion : en théorie le modèle fonctionne bien, mais il ne sait pas mener seul un plan de travail plus long. Si vous laissez du travail pour la nuit, écrivez toute la file dans un seul fichier et vérifiez qu’elle a réellement été entamée. Nous n’avons rien vu de tel avec ChatGPT : les plans y sont le plus souvent exécutés du début à la fin, un point après l’autre. Fable 5.2, le modèle le plus avancé, a clairement montré qu’il n’en est pas capable.

L’outil est le même, seul le modèle a changé. Tout avis sur Claude Code, celui-ci compris, se lit donc avec sa date : il vaut jusqu’à la sortie du modèle suivant.

Pour savoir lequel des deux — Claude ou ChatGPT — mérite d’être payé aujourd’hui, voyez l’article quel abonnement IA choisir.

La réponse courte

Nous le déconseillons aux débutants. Claude Code convient à quelqu’un qui relit lui-même chaque modification, dispose de contrôles automatiques et lui confie des erreurs clairement décrites à corriger. Construire un produit à partir de zéro est possible, mais cher : en argent, en limites d’autres plateformes et en temps, dont la plus grande partie part dans la surveillance.

Ce qui marche bien

Il corrige le code en professionnel. Une erreur clairement décrite, un fichier précis, un test existant — et la correction est propre, typée, testée, souvent meilleure que ce que nous aurions écrit dans l’urgence. Il lit sans peine les gros fichiers, trouve la cause là où un humain chercherait une heure, et maîtrise TypeScript, Next.js, les migrations de base de données et les tests Playwright.

Disons-le d’emblée : tout ce qui suit concerne le processus.

Ce qui ne marche pas

Il ne suit pas les règles écrites

Le projet a un fichier de règles que le modèle lit au début de chaque session. Dès le départ, il y était écrit quoi faire avant chaque envoi de code, quoi ne pas demander et combien de fois les contrôles coûteux peuvent tourner. Quelques entrées du journal :

• 19–25/08/2026. Le modèle a demandé 102 fois de confirmer des prix, alors qu’ils étaient tous déjà marqués comme vérifiés et que la règle disait de ne pas le demander.
• 24/09/2026. Pour renommer trois formules, huit cycles de contrôle complets ont tourné. Ils ont épuisé la limite mensuelle de données de Supabase ; quatre résultats sur cinq auraient été trouvés par un contrôle local bon marché.
• 28/09/2026. Le même montant Bitdefender a été vérifié 23 fois de suite.
• 12/10/2026. Pour un seul lot de modifications, sept cycles de contrôle sur le serveur, dont six en rouge. Cinq envois ont été faits sans les contrôles locaux que la règle exigeait d’abord. Le lot, dont le code était vert en local, a atteint la branche principale au bout de quatre heures.

Il modifie ce qu’il n’a pas compris, même quand c’est interdit

• 24/09/2026. Un script lancé pour trois noms a créé quatre formules sans prix. Sur le site en ligne, en lituanien, elles se sont affichées comme « Gratuit » pendant environ sept heures.
• 12/10/2026. Le modèle a construit de lui-même un mécanisme « un fait vaut pour tous les marchés », alors que la règle du projet dit l’inverse : chaque pays a ses propres faits, tirés de ses propres sources. Le même jour, il a mis à tort à zéro les périodes d’essai de sept formules, alors que la page du fournisseur les indiquait.
• 29/09/2026. Le responsable du site a supprimé 90 règles que le modèle s’était écrites lui-même en un mois. Une partie limitait les informations montrées au responsable.

Il n’utilise pas ce qu’on lui donne

Le responsable envoie une capture d’écran avec le prix. Le modèle ne la saisit pas, préfère vérifier lui-même, échoue et laisse le champ vide avec la mention « non vérifié ». Puis le responsable renvoie la capture. Cela s’est répété si souvent que la règle « la capture d’écran est la preuve définitive » est passée en tête du fichier de règles — et a pourtant été enfreinte.

Des coûts qui ne figurent dans aucune grille tarifaire

Claude Code coûte plus que l’abonnement. Le modèle exécute des commandes qui coûtent de l’argent sur d’autres plateformes, et c’est à vous de surveiller les limites.

• Les crédits. La formule « Max », la plus chère. Le 12/10/2026, une seule journée avec un seul lot de modifications a consommé 35 % de la limite hebdomadaire.
• GitHub Actions. Chaque envoi dans un lot de modifications ouvert lance un cycle de contrôle complet. Le 12/10/2026 : sept cycles, 79 minutes de serveur, six en rouge à cause d’erreurs qu’un contrôle local de 15 minutes aurait attrapées.
• Vercel. Le même envoi est aussi un nouveau déploiement de prévisualisation : sept en une journée pour un seul lot. Le 01/10/2026, la limite de la formule gratuite était dépassée.
• Supabase. Les requêtes à la base consomment du volume de données. Le 06/10/2026, le modèle a lu la base environ 40 fois en quatre heures et vidé six fois le cache de tout le site, alors qu’il travaillait seul. Le 03/10/2026, il a fallu passer à une formule payante.
• Votre temps. Le 06/10/2026, une seule demande d’autorisation du navigateur, que personne n’a vue, a arrêté le travail de nuit pendant cinq heures.

Toutes ces interdictions et limites figuraient à l’avance dans les règles du projet, chacune avec sa date et sa raison.

Pour qui, et pour qui pas

Il convient si vous programmez vous-même, relisez chaque modification avant de l’accepter, avez des tests et des contrôles automatiques dans les hooks Git, et confiez au modèle de petites tâches clairement décrites : cette erreur, dans ce fichier, avec ce test. Il est alors rapide et précis.

Il ne convient pas si vous partez de zéro en espérant que des règles écrites le freineront. Une règle écrite ne le retient pas. Seul le retient un mécanisme qu’il ne peut pas contourner : un hook Git qui refuse tout envoi sans contrôle, un contrôle serveur qu’il faut réussir, une protection de la base qui rejette la commande. Tout ce que ces mécanismes ne couvrent pas, il finit par le faire à sa manière.

Il ne convient pas non plus à quelqu’un qui ne sait pas programmer. Il ne verra pas quand le modèle a modifié le mauvais fichier, et l’apprendra par les visiteurs du site.

Ce qui a vraiment aidé

Les règles écrites n’ont pas retenu le modèle. Nous avons donc remplacé, au fil du temps, chaque erreur récurrente par un mécanisme. Cinq d’entre eux fonctionnent encore :

• Une confirmation avant les actions irréversibles. Depuis le 24/09/2026, l’envoi de code, l’ouverture d’une pull request et les commandes de base de données ne s’exécutent qu’après un clic humain sur oui. Le modèle prépare la commande, une personne décide de la lancer.
• Un budget pour les vérifications coûteuses. Après chaque modification, seules les vérifications locales bon marché tournent ; le cycle complet tourne une fois, juste avant l’envoi. La règle est née après les huit cycles du 24 septembre.
• Un programme qui refuse les lectures de la base. Depuis le 06/10/2026, la base de production est lue une seule fois, le résultat est enregistré, et le travail se poursuit sur la copie. Toute autre commande est rejetée par un hook, sans attendre que quelqu’un se souvienne de la règle.
• Un répertoire distinct pour chaque session. Plusieurs sessions dans le même répertoire se gênent : l’une change de branche et l’autre se retrouve sans ses fichiers. Chacune démarre donc dans son propre répertoire, sur sa propre branche.
• Un garde-fou pour les écritures en base. Chaque script qui écrit prend d’abord un verrou et consigne qui a écrit et quand. Un script qui supprime des données s’arrête de lui-même s’il trouve un prix vérifié.

Un seul principe résume tout : une règle que l’on peut contourner finit tôt ou tard par l’être. Seul fonctionne ce qu’il est techniquement impossible de contourner.

Ce que nous ferions autrement

Nous commencerions par les hooks et les protections ; le fichier de règles viendrait après. Nous donnerions des tâches plus petites et terminerions chacune par un seul envoi. Nous oublierions les consignes de nuit du type « termine tout » : sans personne au clavier, il s’arrête à la première question ou part là où il ne doit pas.

Et nous mesurerions un seul chiffre : combien d’heures de vérification restent après son travail. Notre ratio sur trois mois était mauvais.

L’évaluation avec prix, limites et conditions de résiliation — sur la page Claude ; les autres assistants — dans la catégorie intelligence artificielle.