
🌐 Aussi en: English · Deutsch · Español
Depuis quelques mois, une grande partie de ce blog et du code Ansible qui le fait tourner s’écrit avec un assistant IA : Claude, dans sa version en ligne de commande Claude Code. Il écrit du code, lance des commandes sur les serveurs, lit des journaux et rédige des brouillons d’articles ; moi, je décide, je vérifie et je dis assez souvent « non, pas comme ça ». À un moment, j’ai voulu savoir ce que tout cela représente vraiment. Pas au feeling, en chiffres.
Il existe pour cela un petit outil communautaire, ccusage. Il lit les journaux que Claude Code garde sur mon propre ordinateur et les additionne. Une ligne dans le terminal :
npx ccusage@latest daily --since 20260923npx télécharge l’outil, l’exécute une fois et l’oublie. Il ne lit que les journaux locaux et n’envoie rien de leur contenu nulle part ; la seule chose qu’il récupère sur Internet, c’est la liste de prix actuelle. Voici le résultat pour les quatre semaines du 23 septembre au 21 octobre 2026.
🔢 Les chiffres bruts
| Valeur | |
|---|---|
| Jours d’utilisation | 25 sur 29 |
| Tokens au total | 3 973 410 229 – près de quatre milliards |
| … dont relus depuis la « mémoire » (cache) | 3,90 milliards (98 %) |
| … nouvellement mis en mémoire | 60,5 millions |
| … écrits par l’assistant | 8,7 millions |
| … tapés par moi comme nouvelle saisie | 18 342 |
| Jour le plus chargé | 19 octobre : 377 millions de tokens |
| Prix calculé au tarif public | 1 407 dollars US |
🧩 Au fait, c’est quoi un token ?
Un modèle de langage ne lit ni lettres ni mots entiers, il lit des tokens : des morceaux de mots. « Firewall » fait peut-être deux tokens, « le » en fait un, un long mot allemand comme « Datenbankverbindung » peut en faire quatre ou cinq. En règle générale, 100 tokens correspondent à environ 75 mots anglais. Tout se compte en tokens : ce qui entre, ce qui sort et – c’est la partie intéressante – ce que le modèle doit relire.
📚 98 % de relecture
La ligne la plus surprenante du tableau, c’est le cache. Sur près de quatre milliards de tokens, 3,9 milliards n’avaient rien de nouveau. C’était la même conversation, relue.
Voilà comment fonctionne un tel assistant : entre deux étapes, il n’a aucune mémoire. Avant chaque réponse – chaque commande qu’il lance, chaque fichier qu’il lit – on lui remet toute la conversation jusqu’ici : mes questions, ses réponses, chaque extrait de journal, chaque fichier. Une longue session de travail sur un serveur atteint vite la taille d’un petit livre, et ce livre est relu pour l’étape suivante. Puis la suivante. Puis encore la suivante.
Imaginez un employé de bureau qui, avant d’écrire chaque phrase d’une lettre, relit tout le dossier depuis la première page. C’est mon assistant. Pour chaque token qu’il écrit, il en relit environ 450. La bonne nouvelle : relire coûte peu. Le fournisseur garde la conversation prête dans un cache, si bien qu’un token relu ne coûte qu’environ un dixième d’un nouveau. Ce qui explique aussi pourquoi quatre milliards de tokens paraissent bien plus dramatiques qu’ils ne le sont.
✍️ Ce que cela donne au quotidien
- 80 romans. Les 8,7 millions de tokens écrits par l’assistant font environ 6,5 millions de mots – à peu près 80 romans de longueur moyenne. Imprimés, une pile de papier d’environ 2,60 mètres. Avouons-le, ce n’est pas de la littérature pour l’essentiel, mais des fichiers de configuration, des commandes shell et des explications sur les raisons pour lesquelles le pare-feu a fait quelque chose d’inattendu.
- 23 ans de lecture. Si une personne voulait lire les quatre milliards de tokens à un rythme normal, sans dormir, sans café, sans week-end, il lui faudrait environ 23 ans. À raison de huit heures par jour, ce serait toute une carrière.
- 475 fois plus de réponse que de question. Ma propre saisie nouvelle, c’était 18 342 tokens – quelques pages de texte en quatre semaines. Des consignes courtes comme « regarde les journaux », « oui, fais comme ça » ou « pourquoi c’est rouge ? ». Le reste vient de l’assistant : tout ce qu’il a lu sur les serveurs, écrit et expliqué.
- Quatre jours de repos. 25 jours sur 29 ont servi. Même un assistant IA a apparemment droit à un week-end de temps en temps – ou plutôt son humain.
💸 La facture qui n’est jamais venue
L’outil calcule aussi un prix : 1 407 dollars US pour quatre semaines, environ 56 dollars par jour actif, 118 le jour le plus chargé. Ça paraît beaucoup – et ce n’est pas ce que j’ai payé.
Ce chiffre correspond à ce que coûterait cette utilisation au tarif public de l’API, l’interface par laquelle les entreprises intègrent le modèle à leurs propres produits. Là, chaque token est facturé : nouvelle saisie, sortie, écriture dans le cache, lecture du cache, chacun à son propre tarif. ccusage multiplie simplement mes nombres de tokens par ces tarifs.
J’utilise plutôt un abonnement, la formule Pro, affichée à environ 20 dollars US par mois. Un abonnement, c’est un forfait avec des limites d’utilisation : on peut travailler jusqu’à épuiser le quota d’une fenêtre de temps, puis on attend qu’il se renouvelle. Les 1 407 dollars sont donc un « et si » – ce que coûterait le même travail si chaque token était facturé un par un. Pour un projet personnel, le forfait est le choix évident ; pour une entreprise qui intègre le modèle à son produit, le prix au token est la norme.
Ces limites ne sont d’ailleurs pas théoriques. La tâche la plus coûteuse du mois a été la traduction après coup du blog : les 111 articles existants en allemand, en français et en espagnol. Cela s’est étalé sur plusieurs jours et de nombreuses sessions, parce que je me heurtais sans cesse à la limite des cinq heures – le travail s’arrêtait en plein article, et une nouvelle session reprenait dès que la fenêtre s’était renouvelée. Traduire, c’est lire et écrire en même temps, et en grande quantité ; on le voit dans les statistiques, où les 9 et 11 octobre comptent parmi les journées les plus chargées. Un traducteur humain aurait eu besoin de plusieurs mois. L’assistant a eu besoin de quelques jours et de ma patience face au minuteur.
⚡ Et combien d’ordinateurs ont dû tourner pour ça ?
C’est la question à laquelle j’aimerais le plus répondre, et celle à laquelle je ne peux pas répondre honnêtement par un chiffre. Le modèle ne tourne pas sur mon ordinateur, mais dans des centres de données, sur des puces spécialisées conçues exactement pour ce type de calcul. La taille du modèle, le nombre de puces qui répondent à une requête et l’énergie que coûte un token – le fournisseur ne les publie pas, et tout chiffre précis ici serait inventé.
Ce qu’on peut dire : un modèle de cette catégorie ne tourne pas du tout sur un PC domestique. Il lui faut nettement plus de mémoire qu’un ordinateur ordinaire n’en possède. Et relire depuis le cache demande bien moins de calcul que de calculer quelque chose de nouveau – c’est précisément pour cela que c’est tellement moins cher. Les 98 % de relecture représentent donc beaucoup moins de travail dans le centre de données que ne le laisse penser le simple nombre de tokens.
🏗️ Ce qui en est sorti
Compter les tokens, c’est amusant, mais la vraie question est : à quoi ont-ils servi ? En environ cinq mois, voici ce qui a été créé :
| Volume | |
|---|---|
| Rôles Ansible | 39 |
| Code (tâches, templates, scripts) | environ 36 000 lignes, dont un cinquième de commentaires et d’explications |
| Documentation d’exploitation | en trois langues, environ 16 000 lignes |
| Articles de blog | une trentaine, chacun en quatre langues |
| Serveurs | ce blog et deux instances Nextcloud, durcis et surveillés |
Combien de temps cela aurait-il pris à l’ancienne, tapé à la main ? Pour du code d’infrastructure, on compte grosso modo 30 à 80 lignes terminées et testées par jour – recherche, essais sur de vrais serveurs et dépannage compris, ce dernier prenant souvent plus de temps que l’écriture. Ajoutez la documentation et les traductions, et l’estimation arrive à deux à trois ans de travail à temps plein pour une personne expérimentée. Cette personne devrait en plus maîtriser en profondeur, en même temps, SELinux, Kubernetes, les pare-feu, les bases de données, Nextcloud, WordPress et la supervision – ce qui est rare.
Cette personne, ce n’est pas moi non plus. Mais j’ai beaucoup appris en chemin, et bien plus vite que je ne l’aurais fait autrement. Chaque fois que quelque chose ne marchait pas, j’obtenais l’explication sur le moment : pourquoi SELinux refuse une transition, ce qu’est un en-tête hop-by-hop, pourquoi une base de données tourne sans protection alors que tout affiche « enforcing ». C’est apprendre exactement au moment où la question se pose – un professeur particulier qui a toujours le temps et ne dit jamais « lis d’abord le chapitre 7 ». Un manuel explique beaucoup de choses dont je n’ai pas besoin à ce moment-là, et la seule page qui me manque se trouve quelque part au milieu. Ici, je me suis documenté de façon ciblée, j’ai posé des questions, et les deep dives de ce blog sont ce qui en reste.
Les lignes de code sont une mesure grossière, et l’estimation donne un ordre de grandeur, pas une facture. Plus important est ce que les chiffres ne montrent pas : l’assistant n’a rien décidé seul. Chaque modification sur un serveur en production a été discutée avant, chaque résultat vérifié, et certaines des meilleures découvertes sont venues d’un simple « ça a l’air bizarre, tu peux revérifier ? ». Le deep dive SELinux en décrit deux. Vers le vingtième jour, j’ai d’ailleurs compris d’où vient cette vieille blague d’informaticien : certains d’entre nous parleraient plus à leur IA qu’à de vraies personnes – y compris leur propre conjoint. Pour ma défense : l’IA ne s’est encore jamais plainte que j’explique des règles de pare-feu pendant le dîner. L’IA prend en charge le travail de fourmi ; la responsabilité reste à l’humain. Et il s’agit d’un projet personnel – il est donc en concurrence avec tout le reste de la vie pour le temps disponible. C’est justement là que tout se joue : c’est parce que ce temps est limité que la vitesse du travail avec une IA a fait la différence. Quelques heures libres ne suffisent pas pour taper un pare-feu à la main. Elles suffisent pour en discuter un, le vérifier et le déployer.
🔍 Ce que révèlent les statistiques
- Les grands sujets font les grandes journées. Le jour le plus chargé, le 19 octobre, est celui où les dernières parties de la tournée Ansible et l’article sur SELinux ont été écrits et testés – beaucoup de lecture sur les serveurs, beaucoup de texte.
- Le contexte est le vrai moteur des coûts. Pas ce que je tape, ni même ce que l’assistant écrit, mais tout ce qu’il doit garder en tête. Les longues sessions avec beaucoup d’extraits de journaux coûtent cher ; les tâches courtes et ciblées, peu.
- Ce n’est pas le modèle qui écrit le plus. Il lit. 450 tokens lus pour chaque token écrit – c’est moins « machine à écrire créative » que « collègue très rapide qui relit tout le dossier à chaque fois ».
🧔 Mon avis personnel – un peu tranché, et seulement le mien
Pour moi, la vraie valeur de tout cela, ce ne sont pas les réponses brillantes. C’est le temps. Deux à trois ans de travail en environ cinq mois – c’est la différence entre un projet dont j’aurais rêvé et un projet qui tourne. Durcissement, supervision, documentation en trois langues, un blog en quatre : rien de tout cela n’existerait sous cette forme sans l’assistant, simplement parce qu’une vie humaine compte un nombre limité de soirées.
Voici donc mon avis tout personnel, en tant que quelqu’un qui a 20 ans d’expérience professionnelle et a tapé à la main bien assez de fichiers de configuration : pour mes propres projets personnels, écrire du code d’infrastructure ligne par ligne, à la main, n’est plus dans l’air du temps. Pour moi, cela ressemble à la carte perforée de notre époque – honnête, admirable, et pour moi personnellement une façon de passer trois ans sur quelque chose que je fais aujourd’hui en quelques mois. Ce n’est pas un jugement sur les autres : certains des administrateurs les plus soigneux que je connaisse écrivent eux-mêmes chaque règle, et ils ont de bonnes raisons. J’ai simplement déplacé mon propre soin ailleurs – vers les questions, la relecture, les tests et les décisions. C’est là que je trouve l’humain irremplaçable, et c’est là que va mon temps gagné.
L’Ansible écrit à la main survivra, bien sûr, et à juste titre – à côté des vinyles, des claviers mécaniques et de la personne qui compile son noyau elle-même par principe. Peut-être les rejoindrai-je un jour par nostalgie. Pour mes propres projets, dans le peu de temps libre qui me reste à côté de la famille et du travail, ce n’est toutefois plus la méthode que je choisis.
Et pourtant, il y a un revers moins joyeux, et il serait malhonnête de le passer sous silence. Deux à trois ans de travail pour une personne en cinq mois – à l’inverse, cela veut aussi dire qu’un projet qui aurait autrefois occupé longtemps une petite équipe n’a plus besoin que d’une personne et d’un assistant. Pour moi, avec un projet personnel et un temps limité, c’est un pur gain. Pour les équipes et les métiers qui vivaient justement de ce travail manuel soigneux, c’est une vraie question, et personne n’y a encore de bonne réponse. Le chemin de droite est plus rapide. Il est aussi plus vide.
Je crois que beaucoup d’entre nous se trouvent en ce moment à cette bifurcation, qu’ils le veuillent ou non – administrateurs, développeurs, rédacteurs techniques, traducteurs. J’ai pris le chemin de droite, parce que pour ma situation il est clairement le meilleur – pour d’autres situations, la réponse peut être tout autre. Mais je jette de temps en temps un regard par-dessus mon épaule. Ceux qui se tiennent encore devant le panneau ne sont pas dépassés. Ils pèsent quelque chose qui mérite d’être pesé.
🎬 Conclusion
Quatre milliards de tokens, ça sonne comme de la science-fiction. Traduits dans la vie courante, c’est un collègue qui ne se lasse jamais de relire tout le dossier, qui écrit 80 romans de configuration en quatre semaines et qui aurait envoyé une facture de 1 400 dollars s’il n’y avait pas eu de forfait. Ce qui reste, c’est du code qui tourne, des serveurs mieux protégés qu’avant et un blog qui parle désormais quatre langues. Et le constat que la phrase la plus courte de tous ces milliards – « oui, fais comme ça » – était toujours la plus importante.
Et une dernière remarque personnelle. Officiellement, je présente ce blog et le code sur GitHub comme mon engagement bénévole en 2026 – ça fait tout simplement meilleur effet en soirée 😉 Honnêtement, c’est surtout la meilleure formation continue que j’aie jamais eue : j’apprends énormément sur le plan technique, plus en quelques mois que dans bien des formations, parce que chaque question reçoit sa réponse au moment même où elle se pose, et que mon temps libre limité sert à comprendre plutôt qu’à chercher. Efficace, efficient, pas une minute de perdue. Écrit par un Xennial, né en 1979 et donc exactement un an trop tôt pour compter officiellement parmi les digital natives, mais juste assez tard pour avoir grandi entre le magnétophone à cassettes et le premier modem – la courbe d’apprentissage est raide, mais le plaisir aussi. Le bénévolat vient en bonus : au bout du compte, il en sort quelque chose que n’importe qui, n’importe où dans le monde, peut utiliser gratuitement s’il fait face aux mêmes tâches : faire tourner WordPress ou Nextcloud en toute sécurité sur ses propres serveurs. Si cela épargne quelques soirées à quelqu’un dans un autre pays, les quatre milliards de tokens auront été bien employés.
Pour voir vos propres chiffres : npx ccusage@latest daily dans un terminal sur l’ordinateur où tourne Claude Code. Il ne lit que des fichiers locaux et ne récupère rien d’autre que la liste de prix.




