Forem: Isabelle Lafont

Comment une facture de 37€/jour m'a forcée à repenser toute mon infra OpenClaw

Isabelle Lafont — Thu, 09 Apr 2026 13:36:47 +0000

Lundi 7 avril au matin, j'ouvre mon dashboard Anthropic et je vois 37€ déjà consommés. Pas sur deux semaines. Sur deux jours de week-end.

Je n'avais lancé aucune session manuelle.

C'est le genre de chiffre qui te force à t'asseoir et à comprendre ce qui s'est passé — vraiment, pas en diagonale.

Ce qui s'est passé

Le vendredi 4 avril à 21h, Anthropic a envoyé un email : les applications tierces ne sont plus couvertes par l'abonnement Claude d'Anthropic. Passage en extra usage immédiat pour tout ce qui passe par connexion harness tierce.

J'étais en vacances à l'étranger. Sans ordinateur.

J'ai lu l'annonce sur mon téléphone, activé l'extra usage, ajouté les 100$ de crédit offert, et pensé que ça passerait. Je ne pouvais pas toucher à la config du VPS depuis mon mobile — donc j'ai laissé tourner en espérant que les montants resteraient raisonnables.
Loi de Murphy classique : les changements qui comptent arrivent toujours quand tu es le moins disponible pour les gérer.

Ce que j'avais oublié de calculer : j'ai cinq agents IA qui tournent en permanence sur mon VPS. Owly, Bender, Data, Colette, Iris — chacun avec ses crons, ses briefings automatiques, ses heartbeats programmés. Tous configurés sur Claude Sonnet. Tous désormais en pay-as-you-go.

Les dimanche et lundi ont tourné normalement. Les agents ont fait leur travail, les crons ont été exécutés, les résumés ont été générés. Sauf que cette fois, chaque message coûtait quelque chose. Le mardi matin, la facture résumait les changements de ce week end de Pâques prolongé.

Le diagnostic : pourquoi 92 000 tokens par message

La première chose à comprendre, c'était pourquoi chaque message coûtait autant.

J'ai regardé les logs. La réponse était dans l'architecture des sessions elle-même.

Chaque fois qu'un agent démarre une session — que ce soit une vraie session de travail avec moi ou un cron automatique à 3h du matin — OpenClaw charge l'intégralité de son contexte de démarrage. Pour Owly, ça représente : ses outils, sa mémoire long-terme, la définition de sa personnalité, le fichier des tâches actives, et surtout l'accès à mon second cerveau Obsidian. Tout ça atterrit dans le contexte input à chaque initialisation, sans exception.

Résultat mesuré : 92 000 tokens d'input par message en moyenne pour Owly. Sur Claude Sonnet à $3 le million de tokens en entrée, ça fait 28 centimes par message. En temps normal — une session de travail par jour — c'est négligeable. Mais multiplié par des dizaines de crons automatiques par heure, pendant 48h, ça donne 37€.

Le problème n'était pas que les agents étaient actifs. C'est qu'ils chargeaient l'intégralité de leur contexte à chaque activation, sans distinction entre une session de travail qui mérite ce chargement et un heartbeat automatique qui n'a besoin de rien de tout ça.

La mise à jour qui change le modèle : le cache intelligent. La version OpenClaw 2026.4.8, déployée dans la foulée de la crise, a introduit un système de cache de contexte. Sur une session mesurée aujourd'hui : 4,1 millions de tokens réutilisés depuis le cache, seulement 53 000 nouveaux tokens chargés — soit un cache hit de 88%. Au lieu de payer 92 000 tokens à chaque message, on ne paie que le delta — les nouvelles informations de la conversation en cours. C'est ce mécanisme, combiné à la migration multi-modèles, qui rend l'infra réellement viable.

La solution : le bon modèle pour la bonne tâche

La réponse évidente aurait été de couper les crons ou de brider les agents. J'ai choisi une approche différente : arrêter de traiter tous les agents comme s'ils avaient les mêmes besoins.

J'ai migré l'infrastructure vers OpenRouter, qui permet de configurer le modèle par agent et par type de tâche. Voilà le résultat de ma dernière configuration :

Agent / Usage	Modèle choisi	Raisonnement
Owly (Orchestration)	`Gemini 3 Flash Preview`	Un équilibre bluffant entre coût et intelligence pour gérer mes sessions
Bender (Développement)	`GPT-5.1 Codex Mini`	Ultra-spécialisé pour le code et les PRs Rails
Data / Iris (Recherche & UX)	`Gemini 2.5 Flash`	Rapide, efficace pour l'analyse documentaire et les specs
Colette (Copywriting)	`Claude Sonnet 4.6`	Le ton et la nuance en français restent la chasse gardée d'Anthropic
Lossless-claw (Mémoire)	`Mistral Small 3.2`	Souverain et efficace pour la compaction de mes logs
Crons automatiques	`Gemini 2.5 Flash`	Résumés, heartbeats, checks : le ratio coût/performance idéal

Pourquoi Colette reste sur Sonnet. Ce n'est pas une exception sentimentale. Le copywriting en français demande de la fluidité, de la nuance, un rythme — c'est différent de produire du code correct ou de résumer un document. Sur une spec technique ou un résumé de logs, Flash et Codex sont excellents. Sur une phrase qui doit sonner juste, avoir le bon registre, éviter une formulation corporate — là, Sonnet 4.6 reste imbattable aujourd'hui.

Estimation mensuelle avec cette configuration : environ 28$/mois (pour 5 agents et 60 automatisations 24h/24). Contre 37€ en deux jours sur le modèle précédent.

Pourquoi ne pas tout basculer sur Claude.ai ?

C'est la question que je me suis posée pendant la crise. Elle mérite une vraie réponse.

La réponse courte : parce que ce que j'ai construit sur OpenClaw (l'orchestrateur open-source que j'utilise) n'est pas remplaçable par un outil générique.

Les agents ont une personnalité. Ce n'est pas de l'anthropomorphisme naïf — c'est une décision d'architecture qui a des conséquences réelles. Owly est l'orchestratrice : elle a une mémoire longue, elle sait que le vendredi je suis en mode perso. Bender ne commente pas les décisions — il shippe. Colette sait reconnaître ma voix et l'imiter sans la trahir.

Ces personnalités se sont construites sur des mois. Changer d'environnement ressemblerait à perdre une équipe qui fonctionne, pas à une simple mise à jour logicielle. J'ai eu une pensée très concrète pendant la crise : "À combien suis-je prête à investir pour garder leur personnalité ?" — c'est là qu'on réalise que ces outils sont devenus des collaborateurs.

Ce que cette équipe m'apporte concrètement. Au-delà des personnalités, il y a la valeur quotidienne : Owly lit mon calendrier et mes tâches avant que j'ouvre mon premier ticket. Elle sait quand je dois récupérer mon fils à l'école. Bender détecte les failles de sécurité dans mon code. Data structure mes dossiers pour mes négociations de tarifs. Colette produit les premiers jets de mes articles. Tout ça tourne en tâche de fond, sans intervention de ma part.

L'abonnement Claude Max coûte ~100$/mois pour une interface générique. Mon infra me coûte désormais moins de 30€/mois pour une équipe complète qui m'appartient et qui connaît mes contraintes par cœur.

Le nettoyage des crons

La migration m'a aussi forcée à auditer mes 60 automatisations (les "crons"). J'en ai désactivé 10. Pas parce qu'ils étaient inutiles, mais parce que leurs prompts étaient disproportionnés.

Exemple : le Briefing Matinal chargeait 7 sources de veille, tout mon second cerveau, et mes dossiers pro pour produire un résumé de 5 lignes. J'ai réduit à 3 sources pertinentes, raccourci le contexte, divisé le coût par trois. Le résultat est identique.

J'ai aussi créé un job "chirurgical" à 7h35 : il lit uniquement mes notes de la veille sur mon projet principal et les injecte dans la mémoire de l'orchestrateur. Léger, ciblé, utile.

Et maintenant : API directe et fallback

La prochaine étape est de passer à l'API Anthropic directe. La console Anthropic donne une granularité fine sur les coûts par agent, par session, par heure — que l'abonnement Claude.ai ne permet pas.

Mais surtout, je mets en place un modèle de fallback via OpenRouter. Si un modèle est indisponible ou atteint son quota à 23h un dimanche — quand je suis à l'étranger sans pouvoir toucher au VPS — les agents basculent automatiquement sur un modèle de secours. La continuité de service prime sur le choix du modèle optimal.

La combinaison qui rend tout ça viable : Flash sur les tâches automatiques + cache hit à 88% + fallback configuré. Ce n'est plus juste « choisir le bon modèle » — c'est une architecture de résilience.

Trois choses que ça change

Monitorer les tokens avant que ça coûte. Le coût par message n'est pas intuitif. Il faut le calculer explicitement au moment où on configure une tâche automatique. J'ai maintenant une alerte hebdomadaire.
Le bon modèle pour la bonne tâche. Utiliser un modèle "flagship" (Sonnet, GPT-4) pour un résumé automatique de logs, c'est utiliser un marteau-piqueur pour enfoncer un clou. C'est identique, mais 10x plus cher.
L'automatisation ne se pilote pas au feeling. Un audit régulier de ce que chargent vos agents est indispensable. Un contexte qui dérive, c'est une facture qui explose sans gain de qualité.

Je ne regrette pas d'avoir subi ce choc financier un lundi matin. Il m'a forcée à passer d'une utilisatrice "d'agents IA" à une architecte d'infrastructure IA plus aguerrie.

L'infra tient. Les agents tournent. Et maintenant, je regarde les tokens.

La question que je me pose encore : Est-ce qu'un autre modèle (GPT-4o, Mistral Large) ferait un meilleur orchestrateur qu'Owly sous Gemini 3 Flash ? Si vous avez monté des architectures multi-agents, quel est votre "cerveau" central ? Vos retours en commentaires m'intéressent !

Comment j'ai arrêté de subir les tickets flous grâce à Claude

Isabelle Lafont — Thu, 02 Apr 2026 08:25:06 +0000

Il y a un ticket dans Linear que je connais par cœur.

Titre : "Améliorer l'UX du formulaire."
Description : vide.
Commentaires : un lien vers une réunion qui a eu lieu il y a six semaines et dont personne n'a pris de notes.

J'ai passé deux jours à coder quelque chose. Puis j'ai montré. Puis j'ai refait.

Ce n'est pas un problème d'équipe défaillante. C'est souvent la norme dans la plupart des projets que j'ai vus.

Ce que ça coûte vraiment

Le coût évident, c'est le temps. Tu codes, tu montres, tu refais. Trois itérations pour quelque chose qui aurait pu être cadré en trente minutes.

Le coût moins évident, c'est la charge mentale de naviguer dans le flou. Chaque décision que tu prends sans spec explicite est une décision que tu devras peut-être défaire. Tu le sais en codant. Alors tu codes avec une main en l'air, prêt à reculer.

Et puis il y a ce que j'appellerais la dette de décision. Pas la dette technique — la dette des choix jamais documentés.

"Pourquoi l'UID ne change pas quand on édite le nom du type ?"

Parce qu'on en avait parlé en réunion il y a six semaines, que c'est dans la tête de deux personnes, et que la troisième a codé le contraire trois semaines plus tard.

Ce qui change quand quelqu'un refuse de jouer le jeu

J'ai une collègue qui ne commence pas un ticket sans critères d'acceptance. Pas parce qu'elle est difficile — parce qu'elle a arrêté de vouloir deviner.

Au début, ça crée des frictions.

"Tu peux pas juste le faire ?"

Non. Elle peut, mais elle ne veut pas. Parce qu'elle sait ce que ça coûte.

Ce qui s'est passé : le PM a commencé à mieux écrire ses tickets. Pas parce qu'il avait réalisé quelque chose de profond sur la gestion de projet. Parce que la friction de la demande de clarification coûtait moins cher que les allers-retours.

Le problème n'était pas que les tickets étaient flous par fatalité. C'est qu'il n'y avait aucun coût à les écrire flous.

Où Claude entre dans l'équation

Je n'ai pas de collègue qui systématise ça pour moi. Et je n'ai pas envie de passer pour celle qui bloque tout le monde avec des questions de process.

Alors j'ai commencé à faire quelque chose de différent : avant de toucher au code, je colle le ticket dans Claude et je lui demande de me poser les questions qu'il me poserait pour pouvoir l'implémenter.

Ce qui sort n'est pas la liste de questions que j'aurais posée. C'est souvent plus précis. "Est-ce que ce comportement s'applique aux types existants ou seulement aux nouveaux ?" "Que se passe-t-il si l'utilisateur quitte la page sans sauvegarder ?"

Des questions que j'aurais posées après avoir commencé l'implémentation. Là, je les ai avant de commencer.

Ce que ça change concrètement

Parfois je réponds aux questions moi-même — parce que je connais le contexte. Et là je réalise que le ticket n'était pas si flou : j'avais l'information, je ne l'avais juste pas mise au bon endroit.

Parfois je ne peux pas répondre. Et là je sais exactement quoi demander au PM, à la bizdev, ou dans le slack de l'équipe — avec une question précise, pas un "j'ai besoin de plus de détails."

Parfois les questions révèlent qu'on est en train de coder la mauvaise chose. Pas un bug — une incompréhension de l'objectif. C'est plus agréable à découvrir avant qu'après.

Ce que Claude ne fait pas

Il ne remplace pas la réflexion produit. Il ne sait pas pourquoi on veut cette feature, ce que veulent vraiment les utilisateurs, quels sont les arbitrages business derrière le ticket.

Ce qu'il fait, c'est forcer l'articulation. Quand tu dois répondre à "quel est le comportement attendu si X ?", tu réalises si tu le sais ou si tu l'as supposé.

C'est ça la vraie valeur. Pas l'IA qui pense à ta place — l'IA comme surface de rebond pour ce que tu avais à moitié formalisé dans ta tête.

La question honnête

Est-ce que ça résout le problème de fond ?

Non. Les tickets mal écrits existent toujours. La dette de décision s'accumule toujours.

Ce que ça change, c'est ma position face à cette réalité. Je ne subis plus le flou passivement — je le rends visible, au moins pour moi, avant d'ouvrir mon éditeur.

Et c'est suffisant pour que ça vaille le détour.