Ce chapitre est celui que les CTO ouvrent en premier, et c'est normal : personne n'aime signer une facture qu'il ne comprend pas. Le chapitre 2 vous a montré ce qu'est un token et pourquoi un contexte sale se paie deux fois, en euros et en qualité.
Ici, on passe du diagnostic aux réflexes : quel modèle pour quelle tâche, quand pousser ou brider le raisonnement, comment lire sa consommation. Une bonne nouvelle traverse tout le chapitre : les gestes qui font baisser la facture sont exactement ceux qui améliorent les réponses. Payer juste et travailler mieux sont le même geste.
La gamme, pensée comme une équipe
La fiche technique des modèles ne vous dira jamais lequel choisir. La bonne question n'est pas « lequel est le plus puissant », c'est « qui ferait ça dans une équipe ». Dans toutes celles où j'ai travaillé, de Mappy au Programme alimentaire mondial, on ne confiait pas la refonte de l'architecture au stagiaire, ni un renommage de variable au directeur technique. La gamme Claude se lit exactement comme un organigramme.
- Haiku, l'exécutant rapide et économeDans sa version 4.5, c'est le collègue véloce à qui l'on confie les tâches mécaniques : renommages, conversions de format, scripts jetables. C'est aussi le modèle naturel des subagents d'exploration du chapitre 9, ceux qui lisent quarante fichiers pour ne vous rapporter que la conclusion. Rapide, peu coûteux, et largement suffisant quand la tâche ne demande aucun jugement.
- Sonnet, le rapide bien cadréQuand le périmètre est clair et la solution sans surprise — une fonctionnalité balisée, une correction accompagnée de son test — Sonnet répond vite et coûte moins cher. C'est le bon choix quand la vitesse compte davantage que la profondeur de raisonnement.
- Opus, le modèle par défautC'est celui qu'on utilise le plus, et c'est volontaire : sur du code, c'est le plus fiable. Il tient un raisonnement au lieu de se contenter de la première piste plausible, ce qui fait la différence sur la conception, la refonte et le bug retors qui a déjà résisté à une session. Dans l'organigramme, ce n'est pas l'architecte qu'on dérange une fois par trimestre : c'est le développeur senior avec qui on passe la journée. Si vous hésitez, c'est lui.
- Fable, la nouvelle classeAu-dessus d'Opus, une nouvelle classe de modèle : raisonnement long, autonomie, les tâches les plus dures. C'est la personne la plus expérimentée de l'équipe, celle à qui l'on confie le problème que personne n'a réussi à résoudre, ou la mission longue qu'on veut pouvoir laisser avancer seule.
La règle des 80/20
Une journée de développement réelle est faite de petites choses : renommer, déplacer, mettre à jour une dépendance, ajuster un libellé, écrire un script qu'on jettera ce soir. Aucune ne demande le modèle le plus cher.
Reste à savoir ce que « cher » veut dire pour vous, et la réponse dépend d'abord de votre mode de facturation. Sur un abonnement forfaitaire — celui à 200 € par mois, par exemple — rester sur Opus toute la journée passe très largement : c'est le réglage par défaut, et c'est le meilleur usage de ce que vous avez déjà payé. L'arbitrage redevient sérieux dans deux cas : la facturation au token, où chaque tâche mécanique se paie au prix fort, et les journées très chargées qui commencent à tutoyer les quotas. C'est là que descendre en gamme sur le mécanique rapporte vraiment, et que le réflexe inverse — le plus gros modèle pour renommer une variable — mérite le nom que lui donnera le chapitre 13 : le luxe permanent.
L'antidote tient en une commande. /model change de modèle en cours de session, sans perdre le fil : vous redescendez pour dérouler une série de tâches mécaniques, vous remontez dès que le raisonnement redevient le sujet.
❯ /model Modèle actuel : Opus (par défaut). Haiku et Sonnet disponibles. ❯ /model haiku Modèle : Haiku. La session continue, même contexte. ❯ Cabinet de Talia : renomme userId en patientId dans src/. · Claude balaie les fichiers... 23 occurrences modifiées, build vert. Tâche mécanique, modèle économe : l'architecte n'aurait pas fait mieux, il aurait juste coûté plus cher.
Doser l'effort de raisonnement
Deuxième molette, plus fine : à modèle égal, l'effort de raisonnement se règle. Vous pouvez demander à Claude de réfléchir longuement avant de répondre, ou au contraire de trancher vite.
Poussez l'effort sur les problèmes durs : le bug que deux sessions n'ont pas coincé, le choix structurant qui engagera six mois de code. Bridez-le sur le mécanique : un renommage n'a pas besoin d'une méditation.
Le temps de réflexion est une ressource qu'on alloue à la difficulté du problème, pas un luxe qu'on s'offre par défaut.
Les réflexes qui divisent la facture
Le choix du modèle est le levier visible. Les quatre réflexes suivants sont moins spectaculaires et pèsent au moins autant.
- 01 · Gardez le contexte courtChaque échange embarque le fil entier de la session : plus il est long, plus chaque message coûte. L'hygiène du chapitre 7, interrompre tôt, repartir propre au bon moment, n'est pas qu'une question de qualité. C'est aussi la plus simple des économies.
- 02 · Confiez l'exploration à des subagentsLire quarante fichiers pour comprendre un module est un travail d'exécutant : un subagent sur Haiku s'en charge et ne vous renvoie que la synthèse, sans encombrer votre contexte principal (chapitre 9).
- 03 · Restez dans le même filCe que Claude a déjà reçu dans une session est mis en cache : le revoir coûte bien moins cher que de le renvoyer à neuf. Abandonner un fil sain pour en rouvrir un autre sur le même sujet, c'est repayer plein tarif ce qui était en cache. Attention, ce réflexe ne contredit pas le /clear du chapitre 7 : quand une session s'enlise, un contexte pourri coûte toujours plus cher que le cache ne fait gagner.
- 04 · Donnez un chemin, pas un collageColler 2 000 lignes de code « pour aider » part d'une bonne intention et produit l'inverse : vous payez ces lignes à chaque échange, y compris celles qui ne servent à rien. Donnez le chemin du fichier et laissez Claude lire ce dont il a besoin : il n'ouvrira que l'utile.
La même tâche, facturée trois fois
Pour sentir l'écart, rejouons une même correction de trois façons, et choisissons le patient idéal : le fameux app.js de 1 240 lignes du cabinet de Talia, celui que Claude réécrivait en entier à chaque retouche depuis le chapitre 1. Le diff final est identique dans les trois cas ; seule la manière de travailler change.
❯ # Essai 1, naïf : app.js collé en entier, plus gros modèle Résultat correct. Contexte saturé dès le premier message. ❯ # Essai 2, propre : un chemin de fichier, Claude lit seul · Claude ouvre trois fichiers sur soixante... Même résultat, pour une fraction du contexte. ❯ # Essai 3, optimisé : même fil, exploration sur Haiku Même résultat. Plusieurs fois moins cher que l'essai 1. Trois fois le même diff. Seule la façon de payer change.
L'ordre de grandeur à retenir est qualitatif : entre la version naïve et la version optimisée, la facture est divisée plusieurs fois, pour un résultat strictement identique. À l'échelle d'une personne, c'est agréable.
Multiplié par une équipe et par un trimestre, cet écart n'est plus un détail de note de frais, c'est une ligne de budget.
Lire sa consommation
On ne pilote pas ce qu'on ne mesure pas. Dans une session, /usage vous montre votre consommation : c'est le compteur à consulter quand vous testez un nouveau réflexe, pour vérifier qu'il produit l'effet attendu. Côté équipe, l'administrateur dispose de rapports d'usage : de quoi repérer les habitudes coûteuses avant qu'elles ne deviennent la norme.
Quand j'audite une équipe, c'est souvent par là que je commence : quelques sessions suffisent en général à montrer les deux ou trois habitudes qui expliquent l'essentiel de la facture, et elles se corrigent en une réunion.
Et puisque vous êtes le lecteur qui compte les euros, vous êtes probablement aussi celui à qui l'on demandera où part le code. Cette question a sa propre page, hors du parcours : confidentialité, RGPD et déploiement en entreprise. Ce qui s'y joue rejoint d'ailleurs ce chapitre, puisque le mode de déploiement que vous choisirez décide aussi de la façon dont vous serez facturé.
Questions fréquentes sur les modèles et les coûts
Quel modèle Claude choisir pour développer ?
Pensez usage, pas fiche technique : qui ferait ça dans une équipe ? Opus est le modèle par défaut et le plus fiable sur du code : conception, refonte, bugs retors, et l'essentiel des sessions de développement. Sonnet va plus vite et coûte moins cher quand la tâche est bien cadrée. Haiku est l'exécutant des tâches mécaniques, renommages, scripts jetables et subagents d'exploration. Fable, nouvelle classe de modèle au-dessus d'Opus, prend les tâches les plus dures, qui exigent raisonnement long et autonomie. La commande /model permet de changer en cours de session, et sur un abonnement forfaitaire rester sur Opus toute la journée est parfaitement tenable.
Combien coûte Claude Code ?
Cela dépend d'abord de votre mode de facturation : sur un abonnement forfaitaire, travailler sur Opus toute la journée tient très bien dans le forfait ; à la consommation, chaque token compte. Dans les deux cas, le coût réel dépend moins de la grille tarifaire que de votre façon de travailler. Une même tâche peut coûter plusieurs fois plus cher menée naïvement, gros modèle même sur le mécanique, fichiers entiers collés dans le prompt, sessions interminables, que menée proprement : bon modèle pour chaque tâche, contexte court, chemins de fichiers plutôt que collages, exploration déléguée à un modèle léger. La commande /usage permet de lire sa consommation, et l'administrateur d'une équipe dispose de rapports d'usage.
Comment réduire sa consommation de tokens ?
Quatre réflexes divisent la facture. Garder le contexte court : chaque échange embarque tout le fil de la session. Confier l'exploration à des subagents sur un modèle léger, qui lisent beaucoup et ne rapportent que la conclusion. Rester dans le même fil quand le sujet est le même, pour profiter du cache de prompt. Enfin, donner un chemin de fichier plutôt que coller des milliers de lignes, et laisser Claude lire ce dont il a besoin. Aucun de ces gestes ne dégrade la qualité : ils l'améliorent.
La suiteAu chapitre 11, Claude sort du bureau : lancer une correction depuis son smartphone, faire avancer plusieurs sessions en parallèle, brancher une revue automatique sur chaque PR, et poser les garde-fous qui permettent de ne pas regarder.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe