Les Crédits IA Gaspillés Sont l'Impôt Idiot de Tout Développeur. Voici Ce Que Je Fais À La Place.

8 min read

Certains matins, j'ouvre mon tableau de bord Claude avant toute autre chose et je vois 15-20% de mes crédits hebdomadaires qui traînent là, quelques heures avant la remise à zéro. Des crédits que j'ai déjà payés. Des crédits sur le point d'expirer pour rien.

La plupart des développeurs regardent ce compteur tomber à zéro. (De toute façon, vous n'alliez rien en faire d'utile, pas vrai ?)

Moi, j'utilise ces heures différemment. Je lâche un agent de refactoring autonome sur un vrai projet, je lui donne une condition de fin vérifiable, et je vais faire autre chose. Du code de production en live, pas un projet de tutoriel. La semaine dernière : un backend de catalogue WooCommerce de 118 000 lignes de TypeScript avec un uptime surveillé toutes les 30 minutes, et un second projet avec 6 fichiers d'intégration fournisseurs qui exécutent tous la même boucle de sync, environ 500 lignes de code copiées-collées sur les 6. Configuration : Opus 4.8, /effort ultracode, /goal. J'ai tout configuré et je suis parti.

TLDR : un agent n'« améliore » pas les choses. Il optimise pour la condition de fin que vous lui donnez. Une condition vague donne des résultats vagues. Un prompt foireux trouve le chemin le plus court vers « terminé », ce qui est parfois le mauvais chemin. 🤓 C'est dans ces sessions que cette différence s'est révélée.

Employé de bureau paniqué devant son ordinateur avec des crédits IA presque épuisés tandis qu'une figure de super-héros se tient confiante en surveillant les progrès d'un agent autonome
Vos crédits IA ne se brûlent pas tout seuls. C'est vous qui les brûlez.

Opus 4.8, /effort ultracode, /goal

Ce trio mérite quelques explications avant que les sessions prennent sens.

Opus 4.8 est le seul modèle Claude compatible avec le raisonnement xhigh, et il embarque une fenêtre de contexte de 1M tokens. Cette seconde partie compte quand vous lui balancez 118 000 lignes de TypeScript en lui disant de se débrouiller tout seul.

/effort ultracode est un paramètre de session dans Claude Code, sorti le 28 mai avec la v2.1.154. L'activer déclenche le raisonnement xhigh et active automatiquement les Dynamic Workflows. Claude décide tout seul quand une sous-tâche mérite d'être répartie sur des sous-agents parallèles : jusqu'à 16 en simultané sur une machine standard, jusqu'à 1 000 par exécution. Certains sous-agents attaquent le problème sous des angles indépendants. D'autres tentent de réfuter les conclusions du premier passage, itérant jusqu'à convergence des résultats. Vérification adversariale, en gros (une équipe de raid où la moitié du groupe est là spécifiquement pour faire foirer l'autre moitié). Les sorties intermédiaires vivent dans des variables de script, pas dans la fenêtre de contexte principale, donc le contexte primaire reste léger pendant que le travail se répartit. J'ai expliqué pourquoi l'architecture native CLI change ce qui est possible pour les agents autonomes dans pourquoi les CLI surpassent MCP pour les agents IA.

/goal est disponible depuis la v2.1.139+. Vous définissez une condition de fin vérifiable en langage naturel. Une instance Haiku séparée lit la transcription de session après chaque tour et répond par oui ou non plus une raison en une ligne. Si non, cette raison devient la prochaine instruction de Claude. Si oui, l'objectif se vide et la session se termine. Sans /goal : environ 40 messages manuels « continue ». Avec : vous définissez l'état final et vous vous barrez.

Combinez les 3 et vous avez une session qui peut tourner toute seule pendant des heures. Ce que vous lui donnez comme objectif, c'est la partie qui compte vraiment.

Avant la Première Ligne Modifiée

La première chose que l'agent a faite dans les deux sessions n'était pas d'écrire du code. C'était de compter.

Backend de catalogue : il a trouvé la suite de tests du projet, lancé typecheck, et verrouillé la baseline. 303 tests qui passent, typecheck au vert. Ces chiffres sont allés dans le fichier de suivi avant que quoi que ce soit d'autre bouge.

Session d'intégration fournisseurs : 404 tests au vert. 701 erreurs de lint déjà présentes dans la codebase, comptées et enregistrées avant le premier changement.

Ce n'est pas du cérémonial optionnel. Le mécanisme qui fait fonctionner le refactoring autonome est le même que celui qui le rend sûr : l'agent optimise pour la condition de fin que vous définissez, pas pour une notion abstraite de meilleur code. Sans baseline connue établie avant le premier commit, il n'y a pas de condition à optimiser et pas d'état de référence vers lequel revenir si quelque chose casse en cours de route. La baseline définit ce que vert signifie. C'est ce vers quoi pointe chaque vérification de la session. L'ignorer et l'agent fait des changements qu'il ne peut pas vérifier, continue parce que rien ne dit de ne pas le faire, et quand vous vérifiez enfin le diff il est à des heures de profondeur sans chemin de retour propre. Ça prend quelques minutes à établir avant de toucher quoi que ce soit. L'ignorer peut coûter toute la session.

On ne pull pas le boss sans poser son point de spawn. La baseline, c'est le point de spawn.

Premier comportement notable dans le backend de catalogue : l'agent a spawné des sous-agents parallèles pour mapper la codebase avant d'écrire une seule ligne. Chaque découverte repassait par grep pour contre-vérification. Il ne parcourait pas le code. Il montait un dossier.

Deux Moments sur la Vérification

Erreur fantôme, backend de catalogue

En pleine extraction d'un composant, la console a jeté une erreur : CategoryEditor défini deux fois. Le genre de truc qui donne envie de rollback immédiatement.

L'agent a lancé typecheck. Propre. Greppé pour toute définition de classe dupliquée dans la codebase. Rien trouvé. Chargé la vraie page dans un navigateur : elle s'affichait correctement.

C'était un artefact du serveur de dev, un fantôme de la transition entre anciens et nouveaux chemins de modules pendant l'extraction. Un restart au checkpoint suivant : zéro erreur.

La procédure : typecheck, grep, rendu navigateur. Chaque vérification indépendante. Une erreur console est du bruit jusqu'à ce que 2 signaux indépendants l'confirment. « Ça compile » n'est pas un test live. « Le terminal a craché quelque chose une fois » non plus.

Une petite digression : pendant que je lisais les logs de la session d'intégration fournisseurs, j'ai reçu un Slack d'un client qui demandait une facture d'il y a 3 mois. J'ai passé 20 minutes à fouiller dans les fils d'emails pour trouver l'original. Pendant ce temps, l'agent avait traité 40 fichiers et faisait tourner 3 sous-agents parallèles. Différent type de débit.

Refus de déploiement, intégration fournisseurs

À un moment, la session a touché un garde-fou qui bloquait l'accès production. L'agent n'a pas essayé de le contourner. Il a vérifié ce qu'il pouvait via la suite de tests, confirmé que les changements principaux tenaient, et a continué à travailler sur le scope restant sans le chemin production. C'est la différence entre un outil et un passif, et ce n'est pas une distinction mineure.

Ce que l'Agent a Décidé de Ne Pas Toucher

Le backend de catalogue avait 2 fonctions slugify qui semblaient presque identiques. Tout audit automatisé les signale comme candidats évidents à la fusion. En lisant le vrai code : l'une gère les apostrophes différemment, l'autre tronque à 80 caractères. La différence entre elles n'est pas cosmétique. C'est une question de quels produits obtiennent quelles URLs, et ces URLs sont déjà indexées dans tout le catalogue. Les fusionner aurait réécrit les liens produits live sans prévenir.

La même logique s'appliquait à 5 variantes d'un parseur de métadonnées qui réécrivaient toutes les enregistrements produits live. L'audit a trouvé la duplication. Lire le code a montré pourquoi chaque variante existait. Les 10% qui divergent entre elles sont exactement les 10% qui comptent pour les données live. L'agent les a toutes signalées, n'a rien fusionné, et est passé à autre chose.

Le backend Convex était un choix plus difficile. Il tourne dans un environnement unique, ce qui signifie que dev c'est prod. Un test live nécessite un déploiement en production. Le gain potentiel était du nettoyage cosmétique. Le risque était invérifiable sans déploiement. L'agent l'a reporté, documenté dans le fichier de suivi, et l'a dit. Honnêtement, je ne suis pas sûr que le refactoring en aurait valu la peine même avec un vrai environnement de test, mais c'est un jugement qui appartient à un humain avec le contexte complet, pas à un agent qui tourne sans supervision.

La session d'intégration fournisseurs s'est terminée avec 334 erreurs de lint encore en place. Ces 334 étaient déjà là avant le début de la session, réparties sur des centaines de fichiers. Les nettoyer en lot aurait signifié toucher à tout pour zéro gain architectural. Les vieux scripts de migration semblaient morts mais se sont révélés être des trappes d'urgence manuelles, le genre dont on se souvient de l'existence seulement quand la prod est en feu et que le failover automatisé est down (demandez-moi comment je le sais). L'agent a laissé une note et les a ignorés plutôt que de décider à ma place.

« Satisfait » ne signifie pas que tout a été touché. Ça signifie que les vrais coupables ont été traités et vérifiés, et que tout le reste est soit risqué à changer soit peu intéressant à corriger. Inventer du travail supplémentaire, c'est de l'échec, pas de la diligence.

Le Prompt Avec des Cicatrices

Le prompt original que j'ai envoyé pour la session backend de catalogue avait des trous.

Aucune mention de production nulle part. « Until satisfied » sans endpoint vérifiable. « Live-test » sans définition de ce qui compte. Une instruction « autoreview » qui ne correspond à aucune vraie commande Claude Code.

Chaque trou correspond à un moment qui aurait pu se passer différemment. Les fonctions slugify auraient été fusionnées. Le backend Convex aurait pu être touché. L'erreur fantôme aurait déclenché un rollback sur un seul signal non confirmé.

Ces 2 sessions ont produit quelque chose qui vaut le coup d'être gardé :

/goal Improve this project's architecture through safe, incremental refactoring.
First: discover the project's own check/test/build/run commands (package.json
scripts, Makefile, justfile, CI config, README) and establish a green baseline
with them — record it. Then audit the codebase for concrete debt (dead code,
duplication, oversized files/modules) with grep-level evidence BEFORE touching
anything. If the project isn't green at the start, stop and report instead of
refactoring blind.
Work in priority order of (value × safety × verifiability). For each step:
  1. one coherent change,
  2. live-test through the REAL path — exercise the change end-to-end for THIS
     project type (browser for a web app, run the CLI/binary, the test suite for
     a library, a real request for an API, a dry-run for a cron). "It compiles"
     is NOT a live-test,
  3. run /code-review on the diff and address its findings,
  4. commit (conventional message, stage by path).
Hard constraints:
  - Production code: prefer surgical, reversible changes over rewrites.
  - Never change a public contract (API paths, published URLs, output formats)
    or any externally observable behavior.
  - Never refactor anything you cannot verify green. If you can't safely
    live-test it, DEFER it and say so explicitly.
  - If reading the real code shows a duplication or variation exists for a
    reason, skip the "cleanup."
Done when the remaining debt is either risky or low-value — don't manufacture work.
Track progress in ~/tmp/refactor-<project>.md (derive <project> from the repo):
log every step, every decision, AND every item you deliberately rejected with why.
Don't push or deploy without asking.

Chaque clause est une cicatrice d'une session qui ne l'avait pas.

C'est de ça qu'il s'agit vraiment avec le framework complet des contrats de prompts : pas de la structure pour elle-même, mais des contraintes qui viennent de quelque chose qui a mal tourné.

Vos Crédits Expirent Ce Soir

Ce que les 2 sessions ont réellement produit :

Backend de catalogue : 4 commits propres, 2 fichiers gonflés réduits, tests de 303 à 313, net -57 lignes. Zéro cassé en production.

Intégration fournisseurs : +288/-711 lignes, tests de 404 à 407, un composant mort de 504 lignes purgé, lint de 701 à 334 erreurs.

Si vous voulez creuser la méthode, Vibe Coding, For Real couvre l'approche étape par étape pour shipper de vrais projets avec l'IA. Gratuit sur Kindle Unlimited.

Votre reset arrive. Les crédits qui traînent dans votre tableau de bord sont déjà payés.

Améliorer l'architecture de vos projets est le meilleur usage des crédits qui expirent.

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais toucher une petite commission (ça ne vous coûte rien, et ça m'aide à continuer à pondre des articles de qualité tous les jours pour votre plaisir de lecture).