500€ de tokens en cinq jours : retour d'expérience sur le pilotage des coûts d'une app IA

Grâce à l'IA, un Product Builder peut passer de l'idée à la production en autonomie. Mais quand le code s'écrit en arrière-plan, personne ne voit ce qui se passe : ni celui qui construit, ni sa direction. Matthias, Product Builder chez Thiga, s'en est rendu compte avec 500$ de tokens consommés en cinq jours de dev. Il a alors construit ce qui lui manquait : une vue précise sur ce que son app consomme, ce qu'elle appelle, et ce qui vaut ou ne vaut pas la peine d'être optimisé. Il revient ici sur les tâtonnements, les arbitrages et les angles morts qu'il a rencontrés en chemin.

Un abonnement Claude Max coûte 100€ par mois. En quatre jours de développement sur mon app, j'avais consommé l'équivalent de cinq mois d'abonnement : entre 400 et 500 dollars de tokens.

Chez Thiga, je suis devenu Product Builder, mais ces compétences en IA sont venues se superposer à celles que j'avais développées en tant que PM ces dix dernières années : IA ou pas, mon métier c'est le produit. L'app que je construis, je l'ai construite seul avec Claude Code, parce que le besoin métier et la valeur / ROI pour l'entreprise étaient là et parce que grâce aux LLM (et un peu de formation technique..) on peut maintenant se lancer seul dans ce genre de projet. Beaucoup de Product Builders font la même chose en ce moment : ils ont un besoin de produit interne, ils ont accès à un outil de génération de code, et ils se lancent.

Là où ça coince, c'est la visibilité. Quand on travaille avec Claude Code, chaque feature et chaque refactoring consomme des tokens... Mais on n'a aucun moyen de savoir combien à l'avance. Rien ne vous dit "attention, la feature que tu t'apprêtes à lancer va demander 10 000 tokens d'échanges avec le modèle". On avance sur le code pendant que la consommation s'accumule en arrière-plan. Et une fois l'app en fonctionnement, c'est la même question à un autre niveau : combien coûte chaque appel au modèle, et où va l'essentiel du poids dans le prompt.

L'app que j'ai construite génère des documents pour les consultants Thiga. Un consultant remplit un brief dans un formulaire, l'app charge des exemples de documents existants depuis Google Drive comme référence stylistique, envoie le tout à Claude, et récupère un document HTML structuré à la charte de Thiga qu'on peut éditer dans le navigateur puis exporter en PDF ou en Google Doc - ou qu'on peut partager directement via le lien de la page créée. C'est un livrable que tout le monde produit régulièrement et sur lequel on perdait un temps fou.

Le jour où la direction m'a demandé "combien ça coûte, ton truc ?", je n'avais rien à montrer. Je pouvais demander à Claude un audit ponctuel, mais pas de vue consolidée sur l'ensemble de ma consommation. C'est un angle mort que partagent beaucoup de Product Builders qui construisent seuls : tant que l'app tourne sur sa machine et que rien n'est hébergé, la question des coûts reste abstraite.

C'est de là qu'est parti le travail que je vais décrire ici : construire la visibilité qui me manquait sur ce que mon app consomme, et décider en connaissance de cause où l'effort d'optimisation valait le coup.

Avant de réduire les coûts, il faut les comprendre

Pour comprendre d'où venaient les 500 dollars, il faut savoir comment je travaillais à l'époque. Au tout début du projet, je codais via l'API Anthropic. La facturation est au token, en flux continu : chaque échange avec Claude pendant le développement a un prix, et il n'y a pas de plafond. En quatre ou cinq jours de dev intensif, le compteur s'emballe et on ne s'en rend compte qu'en ouvrant la facture.

Le premier pivot a été de basculer sur un abonnement Claude Max à 100€ par mois. Au lieu de payer chaque token sans plafond, on a un quota hebdomadaire qui se réinitialise. En volume de tokens, le développement qui m'avait coûté 500 dollars via l'API aurait tenu dans un seul mois d'abonnement.

Même avec l'abonnement Max en place, ça ne répondait toujours pas à la question de la direction : "combien ça coûte, ton truc ?" Ce qu'on me demandait, c'était le coût de l'app en fonctionnement. Et sur ça, je n'avais rien à montrer. Je pouvais demander à Claude un audit ponctuel, mais pas de vue consolidée sur l'ensemble de ma consommation.

J'ai donc fait ce que font les Product Builders quand il leur manque un outil : j'en ai construit un (autre). Avec Claude Code, j'ai généré un site de monitoring dédié à mon app, avec la décomposition des coûts par route, l'anatomie de chaque prompt et des projections de consommation.

Première chose que j'ai découverte : mon app n'appelle Claude que sur deux routes. Deux, sur dix-neuf au total. La première génère un document complet à partir du brief et des deux exemples de référence. La seconde reformule des notes brutes section par section. Tout le reste (l'édition dans le navigateur, le rendu HTML, l'export PDF, la création de Google Docs) fonctionne sans aucun appel au modèle. Zéro token.

En disséquant le prompt de la première route, j'ai compris où allait le gros du poids. Le prompt pèse 9 483 tokens. Les deux exemples chargés depuis le Drive en mangent 74% : environ 4 150 tokens pour l'un, 2 850 pour l'autre. Le skill qui donne les instructions de format et de ton pèse 2 000 tokens. Et le brief client, la seule partie qui change d'une génération à l'autre, représente 5% du total. À chaque appel, 95% du prompt est constitué de contenus fixes.

Le coût réel d'une génération complète sur Sonnet 4.6 : 9 centimes. Projeté sur un mois d'utilisation normale (vingt-cinq générations et cent soixante-quinze enrichissements de section), ça donne 3,70€ par mois. Mon app utilise 2,1% du quota de l'abonnement Claude Max à 20€.

Une fois qu'on a cette visibilité, la question change. On sait ce que ça coûte, on sait où vont les tokens. Reste à savoir si on les dépense sur le bon modèle.

Choisir son modèle : le match à 1 centime

Mon app a d'abord tourné sur Haiku 4.5, le modèle le moins cher de la gamme Anthropic. Pendant les premières semaines, je m'en servais pour vérifier que la mécanique tenait : est-ce que le document se génère et est-ce qu'on peut l'éditer correctement. Je ne lisais pas vraiment ce que le modèle écrivait.

Le jour où j'ai commencé à lire ce que le modèle écrivait, ça ne tenait pas. Les documents avaient la bonne structure mais l'argumentation restait en surface, avec des sections qui se paraphrasaient les unes les autres. On était loin du ton Thiga.

Avant de switcher, j'ai voulu mesurer l'écart proprement. J'ai généré des documents avec le même brief sur les deux modèles et je les ai comparés moi-même. En parallèle, j'ai demandé à un agent Claude de faire le même exercice à plus grande échelle : générer des documents avec chaque modèle, puis les évaluer en les comparant à des documents de référence validés qu'on avait dans le Drive.

Les deux approches convergeaient. Sonnet 4.6 produisait un contenu plus cohérent d'une section à l'autre, avec un ton qui se rapprochait de ce qu'on attend d'un document Thiga. Sur Haiku, la structure était là mais le fond manquait de substance.

Le comparatif Haiku vs Sonnet dans le dashboard de coûts : radar de performance sur cinq dimensions et coût par génération.

Le surcoût : une génération sur Sonnet coûte 9 centimes, contre environ 3 centimes sur Haiku. À vingt-cinq générations par mois, la différence représente 1,75€. Quand un document coûte 1 centime à produire en comptant l'enrichissement de sections, sacrifier la qualité du livrable pour gratter un demi-centime n'a pas de sens. C'est un réflexe qu'on connaît bien en produit : l'effort d'optimisation doit être proportionné au gain réel.

À un million de documents par mois, dans un scénario de marque blanche, chaque centime pèserait et il faudrait des benchmarks systématiques. Pour un outil interne entre 25 et 60 documents par mois, c'est sur la valeur du livrable qu'il faut mettre le curseur (et oui, on fait toujours du produit..!).

Les optimisations qu'on garde dans la poche

Une fois qu'on a la visibilité sur ses coûts et qu'on a choisi son modèle, la tentation naturelle c'est d'aller optimiser. J'ai identifié quatre leviers, je les ai documentés et chiffrés dans le dashboard.

Le plus immédiat : passer de deux exemples de référence à un seul. Les deux documents chargés depuis le Drive pèsent 74% du prompt. En supprimer un, c'est 3 000 tokens en moins, soit une réduction de 32% du coût input. La modification tient en une ligne de code et cinq minutes de travail. Je ne l'ai pas fait, parce que les deux exemples couvrent des typologies de clients différentes. Avec un seul document de référence, le modèle se formate sur un seul style et perd en capacité d'adaptation. Tant que la génération coûte 1 centime, je préfère garder la diversité des exemples.

Le deuxième levier, c'est la compression du skill. Le fichier d'instructions qui dit à Claude comment formater et structurer le document pèse 2 000 tokens. Certaines sections sont verbeuses, des checklists redondantes, des exemples qu'on pourrait raccourcir. Gain estimé : 10 à 15% pour une demi-heure de travail, ce que je n'ai pas priorisé non plus.

Le troisième est celui qui m'a le plus surpris, parce que je ne le connaissais pas avant que mon propre Claude me le montre en construisant le dashboard. Le prompt caching, c'est une fonctionnalité native d'Anthropic qui permet de mettre en cache les parties fixes du prompt. Vu que 95% de mon prompt ne change pas d'un appel à l'autre, le gain théorique est massif : on ne paie que 10% du coût sur les appels suivants dans les cinq minutes. Sauf que pour y accéder, il faut passer par le SDK Python, et mon app utilise la CLI Claude en subprocess. C'est une dette technique que je connais, mais qui suppose une migration de plusieurs heures pour un gain qui ne se justifie qu'à volume élevé.

Le quatrième, c'est du RAG. Au lieu d'envoyer les documents de référence en entier dans le prompt, on les découpe en sections, on les indexe via des embeddings, et on ne récupère que les passages pertinents pour chaque brief. Le gain estimé est de 70%, mais on parle de trois à cinq jours de développement – un tout autre investissement.

À 2,1% du quota Max, l'app a une marge de multiplication par quarante-huit avant de toucher le plafond. L'énergie que je mettrais à gratter des tokens, je la mets sur des fonctionnalités qui apportent de la valeur aux utilisateurs : du travail collaboratif, de la facilité de partage quand plusieurs consultants veulent intervenir sur le même document.

Sortir de la boîte noire

Le problème le plus difficile sur ce projet a été de rendre visible ce que je construis.

Quand on est Product Builder et qu'on développe une app en solo sur sa machine, personne autour ne voit ce qui se passe. L'app fonctionne et les coûts sont maîtrisés, mais c'est opaque pour tout le monde. La direction veut savoir si c'est compatible avec la stack et combien ça coûte en fonctionnement. Et quand on vous demande "montre-moi comment c'est construit", ouvrir un terminal et faire défiler du code ne suffit pas.

D'où le site de monitoring dont je parle depuis le début de cet article. Le dashboard de coûts en était une partie, mais le site va plus loin : l'architecture technique complète avec les choix et leurs arbitrages, les release notes mises à jour à chaque nouvelle fonctionnalité, la structure du code. Tout est accessible depuis un navigateur, lisible par quelqu'un qui ne code pas.

Le petit effet "wahou" en plus ? Aujourd'hui, le processus est devenu entièrement automatisé. Dès que je développe mon app et que je merge une nouvelle feature, un sub-agent prend instantanément le relais. Il me génère automatiquement une release note propre, claire et parfaitement designée directement sur le site.

L'impact est immédiat : l'information est accessible en temps réel à toutes les parties prenantes et de mon côté... plus besoin de rédiger ma doc à la main !

Quand j'ai pu montrer en une page que l'app coûte 3,70€ par mois en fonctionnement, qu'elle n'appelle Claude que sur deux routes et que le reste est zéro-LLM, la direction a eu de quoi évaluer le projet sur des faits plutôt que sur une intuition.

Ce problème de visibilité dépasse mon projet. J'ai des échos de consultants chez des grands groupes où les Product Managers commencent à coder des outils internes avec Claude ou Cursor, et où la direction met les freins parce qu'elle ne sait pas ce qui se passe. Les deux côtés sont compréhensibles : il faut un espace pour expérimenter, mais aussi un moyen de rendre compte de ce qu'on construit.

Chez Thiga, on appelle ça l'OS du Product Builder. Un Product Builder qui intègre une nouvelle équipe ou qui commence sur un nouveau périmètre a besoin d'un socle déjà en place : skills, connecteurs MCP, guardrails techniques, règles sur la stack. C'est une des conditions pour que les produits soient scalables dès le départ et que les exigences de qualité soient partagées à l'échelle de l'organisation. L'essentiel du parcours que j'ai dû faire seul sur mon projet (comprendre mes coûts, documenter mon architecture, rendre le tout lisible) pourrait être intégré au cadre de travail dès le départ. Faute de quoi, chaque Product Builder réinvente tout dans son coin et crée de la dette technique que l'entreprise ne peut pas reprendre au moment du passage en production.

Pour finir, sachez que grâce à ce travail sur la visibilité, mon app a pu passer la review d'architecture et a été validée par l'équipe technique. Maintenant, reste plus qu'à déployer en interne !