L'économie du développement assisté par IA pour une équipe de plugin WordPress
Comptabilité honnête des coûts d'une petite équipe livrant un plugin d'analytique WordPress. À quoi ressemblait la facture Anthropic avant l'optimisation, à quoi elle ressemble aujourd'hui, et d'où viennent réellement les économies qui se cumulent.
Une question à laquelle nous ne pouvions pas répondre honnêtement le premier mois
Combien coûte la livraison d’un plugin WordPress avec Claude Code comme collaborateur quotidien ?
Pendant le premier mois où nous avons construit Statnive, nous ne pouvions pas répondre. Nous connaissions la facture. Nous ne savions pas ce qui la pilotait réellement. Certains jours étaient à $3, d’autres à $11, et la variance n’avait aucune corrélation évidente avec la quantité de code livrée.
Quatre mois plus tard, nous avons une image bien plus claire. Cet article est la comptabilité des coûts : où va l’argent, les quatre leviers qui se cumulent à environ 2–3× notre dépense, et le seul chiffre qui a compté plus que toute optimisation individuelle.
Annonce : la dépense quotidienne est passée de ~$6/jour à ~$2–3/jour pour le même débit d’ingénierie. Les économies ne sont pas additives. Elles se multiplient.
Où va réellement la dépense IA
Tarifs Anthropic pour les modèles pertinents pour Claude Code, à début 2026 :
| Modèle | Input / MTok | Output / MTok | Idéal pour |
|---|---|---|---|
| Haiku 4.5 | $1 | $5 | Exploration en lecture seule, validation, corrections de routine |
| Sonnet 4.6 | $3 | $15 | Travail de développement standard |
| Opus 4.7 | $5 | $25 | Architecture complexe, raisonnement profond |
Naïvement, vous choisissez un modèle et payez ce tarif × votre consommation de tokens. La réalité est plus fine, et trois des quatre leviers ci-dessous l’exploitent.
Pour référence, voici les budgets de tokens typiques par opération :
| Type d’opération | Tokens typiques | Temps réaliste |
|---|---|---|
| Correction simple (Haiku) | 2K–5K | 1–2 min |
| Fonctionnalité standard (Sonnet) | 10K–20K | 5–10 min |
| Refactoring complexe (Sonnet + extended thinking) | 30K–50K | 15–25 min |
| Revue d’architecture (Opus) | 50K–100K | 20–40 min |
Multiplié sur une journée de travail, voilà d’où viennent les ~$6/jour pour un seul ingénieur. Multipliez sur l’année et la conversation sur l’optimisation devient sérieuse.
Levier 1 — Mise en cache des prompts (~90 % sur le préfixe stable)
Claude Code met automatiquement en cache le préfixe stable de chaque conversation : le prompt système, les définitions des outils intégrés, les métadonnées des skills et le CLAUDE.md racine. Les lectures de cache coûtent 0,1× le prix de base — une réduction de 90 % sur la portion mise en cache.
Le préfixe stable fait 50 K+ tokens pour la plupart des configurations. Sans mise en cache, chaque tour facture à nouveau ces 50 K tokens. Avec la mise en cache, chaque tour après le premier les lit à 10 % du coût.
Deux règles pratiques :
- Ordonnez le contenu : statique d’abord, dynamique en dernier. Les hits de cache exigent une correspondance exacte du préfixe. Tout élément dynamique au début d’une conversation casse le cache et force une relecture complète. Nous gardons le
CLAUDE.mdracine et les métadonnées des skills en premier, et le contexte dynamique (fichiers modifiés, état de la branche actuelle) en dernier. - Ne polluez pas le préfixe avec quoi que ce soit qui change à chaque session. C’est le vrai argument pour garder
CLAUDE.mdépuré — chaque octet retiré est un octet qui n’a pas besoin d’être remis en cache quand le fichier change, et les préfixes mis en cache plus courts coûtent moins cher à rafraîchir lorsqu’ils expirent.
La mise en cache est le plus gros levier de coût et elle est en grande partie automatique. Le travail consiste à ne pas la casser.
Levier 2 — Routing des modèles (3× sur la portion routée)
Haiku 4.5 coûte 3× moins que Sonnet par token. La différence de capacité pour les tâches en lecture seule et de validation est minime. Anthropic suggère de défaut sur Haiku pour ~80 % des tâches de routine.
En pratique, nous routons ainsi :
| Tâche | Modèle | Pourquoi |
|---|---|---|
| Exploration de code (« trouver tous les endroits où X est appelé ») | Haiku (sous-agent) | Lecture seule, déterministe |
| Tri des échecs de tests | Haiku (sous-agent) | Pattern matching, peu de jugement |
| Implémentation de fonctionnalité standard | Sonnet (principal) | Défaut pour le travail productif |
| Décisions d’architecture, conception de schéma | Opus (principal, occasionnel) | Vaut le supplément pour le raisonnement difficile |
| Passe de revue de code | Haiku (sous-agent fork) | Lecture intensive, retour résumé |
Le routing prend toute sa puissance quand il est associé à des sous-agents, parce que les sous-agents ont leur propre paramétrage de modèle indépendant de la session principale. Nous pouvons faire tourner la conversation principale sur Sonnet pendant qu’un sous-agent fork fait le travail intensif en lecture sur Haiku. Le routing du modèle se passe à la frontière du skill, pas à la frontière de la conversation.
Levier 3 — Isolation par sous-agent (~37 % de réduction du contexte principal)
Les sous-agents (aussi appelés fork agents) reçoivent leur propre fenêtre de contexte de 200 K tokens. Le travail effectué dans un sous-agent ne pollue pas la conversation principale. Seul un résumé revient.
Anthropic documente que les sous-agents renvoient ~500–1 000 tokens à partir de 10 000+ de travail interne — environ une réduction de 37 % du contexte principal sur les tâches complexes.
Deux effets sur les coûts :
- Économies directes de tokens. Une revue de code qui lit 30 fichiers et renvoie un verdict consomme ses tokens en isolation. Sans isolation, ces 30 lectures de fichiers s’installent dans le contexte principal, refacturées à chaque tour suivant (modulo la mise en cache).
- Économies de tokens liées à la qualité. Les contextes longs dégradent la qualité de récupération — la recherche documente des chutes de performance de 15–47 % à mesure que le contexte se remplit, le problème « lost in the middle ». Une qualité moindre implique plus de retries, plus de relectures, plus de tokens. Garder le contexte principal propre prévient toute cette catégorie de gaspillage.
Le compromis est réel : les équipes d’agents utilisent environ 7× plus de tokens totaux que les sessions standards parce que chaque agent fait apparaître une instance fraîche avec son propre overhead de mise en place. Nous l’acceptons parce que nous n’optimisons pas pour les tokens totaux — nous optimisons pour la propreté du contexte principal et le débit global. Et les sous-agents sur Haiku sont bon marché de toute façon.
Levier 4 — Différer les outils MCP (~85 %)
Nous avons couvert cela en détail dans le post sur MCP Tool Search. La version courte :
24 connecteurs MCP sans différement consommaient environ 135 000 tokens d’overhead de base par session. Tool Search a fait tomber cela à ~3 000 tokens pour l’index, les schémas complets se chargeant à la demande. Réduction de 85 %, la précision a monté, les sessions ont cessé d’être à l’étroit.
Effet sur les coûts : chaque token d’overhead de base est un token qui fait partie du préfixe mis en cache à chaque session. Couper 130 K tokens d’overhead, c’est couper environ 130 K × 0,1× le tarif par token × le nombre de lectures de cache par session. Même à 10 % de coût, cela représente plusieurs centaines de dollars par mois pour un ingénieur en activité.
Le multiplicateur cumulatif
Voici la partie que les chiffres d’annonce ne capturent pas. Les quatre leviers sont multiplicatifs, pas additifs.
Imaginez une session de référence qui brûle, disons, $0,30 sur une tâche de 5 minutes. Appliquez chaque levier l’un après l’autre :
| Levier | Effet | Coût cumulé |
|---|---|---|
| Référence | — | $0,30 |
| Mise en cache des prompts (90 % sur préfixe stable) | Le préfixe stable est ~70 % des tokens de session | ~$0,12 |
| Routing des modèles (3× sur le travail éligible Haiku) | ~50 % du travail est éligible Haiku | ~$0,07 |
| Isolation par sous-agent (37 % de réduction du contexte) | Le contexte principal rétrécit → moins refacturé | ~$0,05 |
| Différement des outils MCP (85 % sur l’overhead des schémas) | Les schémas ne sont plus en base | ~$0,04 |
Chaque étape est modeste. La composition est dramatique. Les pourcentages exacts ne sont pas l’essentiel — l’intuition structurelle est que les optimisations de coût des tokens se cumulent multiplicativement parce qu’elles s’appliquent à des portions chevauchantes de la facture. En corriger quatre, c’est changer d’ordre de grandeur.
C’est pourquoi notre dépense quotidienne est passée de ~$6 à ~$2–3 sans changer ce que nous livrons. Même code, mêmes tests, même cadence de release. Des défauts différents.
Sur quoi nous dépensons aujourd’hui
Une journée d’ingénierie Statnive type, après optimisation :
| Activité | Coût approximatif |
|---|---|
| Revue de code matinale sur une PR ouverte (forkée, Haiku) | ~$0,20 |
| 2 fonctionnalités standards dans le tableau de bord React (Sonnet, avec mise en cache) | ~$0,80 |
1 exécution du release-gate (skill statnive-release) | ~$0,30 |
| Brouillons de documentation/articles de blog | ~$0,40 |
| Exploration et Q&A divers | ~$0,50 |
| Total | ~$2,20 |
Sur l’ensemble de l’équipe, notre facture mensuelle Anthropic est bien en-dessous de ce que coûterait un seul abonnement SaaS hérité. Pour le contexte : cette facture finance un collaborateur IA qui aide à livrer un plugin WordPress utilisé par de vraies entreprises, avec 248 tests et 22 portes de publication barrant chaque release.
Extended thinking : assortir le mot-clé à la tâche
Une subtilité tarifaire à connaître : les modes extended thinking de Claude ont des budgets déclenchés par mot-clé :
| Mot-clé | Budget de réflexion |
|---|---|
think | 5K–10K tokens |
think hard | 20K–50K tokens |
think harder | 50K–100K tokens |
ultrathink | 100K–128K tokens (maximum) |
Ces tokens comptent comme input. Utilisez le moins cher qui suffit à la tâche. Nous sommes en mode sans modifieur de réflexion par défaut pour le travail de routine, think hard pour les décisions de conception non triviales, et ultrathink uniquement pour les vraies questions d’architecture où le raisonnement profond gagne sa place. Tendre la main vers ultrathink pour corriger une faute de frappe, c’est l’équivalent en développement IA d’ouvrir une fenêtre Chrome avec 50 onglets pour lire une seule page web.
L’hygiène des sessions nous a fait économiser autant que les leviers
Une découverte contre-intuitive : la plus grande variance dans notre coût quotidien venait de la longueur des sessions, pas de la configuration des skills ou des outils.
Les longues sessions autonomes sans réinitialisation de contexte dégradent progressivement la qualité. L’effet « lost in the middle » — chutes de performance de 15–47 % à mesure que le contexte se remplit — se traduit directement par plus de retries, plus de relectures et plus de tokens gaspillés. Les sessions qui dépassaient 80 % de contexte coûtaient régulièrement 2–3× ce que coûtaient les sessions plus courtes pour le même travail.
Deux règles d’hygiène désormais intégrées à notre façon de travailler :
/clearentre tâches non liées. Passer d’un bug frontend à un changement de release-gate, ce sont deux conversations différentes. Réinitialiser le contexte ne coûte rien et évite la pollution./compactproactivement à 60–70 % de contexte, pas au seuil auto-compact de 95 %. L’auto-compact à la limite est une opération de panique qui perd de l’information. Le compact proactif préserve l’état important et réinitialise le bruit.
Persister l’état dans des fichiers plutôt que dans l’historique de la conversation rend ces deux règles sûres — tout ce qui compte est sur le disque, donc un clear ne le perd pas.
Ce que nous n’avons pas optimisé
- Nous ne mesurons pas encore le coût par skill. Nous voyons les totaux quotidiens via la facturation Anthropic et utilisons les commandes locales
/costet/statspour des contrôles ponctuels, mais nous n’avons pas d’attribution par skill. Des outils commeccusage(lit les fichiers de session JSONL locaux de Claude) et Claude-Code-Usage-Monitor existent ; nous ne les avons pas intégrés. - Notre ratio de sous-agents est sans doute trop bas. Nous utilisons agressivement le mode fork pour les revues et les audits, mais une fraction significative de notre travail standard pourrait plausiblement être forkée pour garder le contexte principal plus propre. Pas mesuré rigoureusement.
- Nous ne menons pas de comparaisons A/B formelles. Le chiffre $6 → $2–3 vient de la comparaison de notre dépense avant et après stabilisation des optimisations. Il n’y a pas d’expérience contrôlée derrière. La vôtre sera différente.
Ce qu’il faudrait pour la diviser à nouveau par deux
Réponse honnête : sans doute rien qui en vaille la peine.
Nous pourrions pousser plus fort sur Haiku. Nous pourrions regrouper plus de travail dans des sous-agents. Nous pourrions écrire des contrats plus agressifs de budget de sortie dans nos skills. Chacun raserait peut-être 10–20 % de plus.
Le coût d’un ingénieur supplémentaire est plusieurs fois le total de notre dépense Anthropic. Passer des heures d’ingénierie à optimiser les coûts IA au-delà d’un certain point, ce sont des heures d’ingénierie qui ne sont pas passées à livrer le vrai produit. Nous optimisons quand les sessions semblent à l’étroit ou que les factures surprennent. Sinon, nous livrons.
Essayer Statnive
Analytique WordPress respectueuse de la vie privée, construite par une équipe qui prend la comptabilité des coûts aussi au sérieux que la couverture de tests. Installer Statnive gratuitement depuis WordPress.org — vos données restent sur votre serveur, notre dépense reste sur une seule ligne budgétaire, et toute la pratique d’ingénierie est open source.