Journal
6 min de lecture

Non concluant

J'ai mesuré ce que Foundry me faisait gagner. Un compteur qui affichait 513 000 $ au lieu de 3 900, quatre modèles locaux à 0 sur 12, un seuil raté à 0,93 % près. Et aucune économie que je puisse annoncer.

Mon compteur de coûts affichait 513 192 dollars.

Le vrai chiffre était 3 916.

Je précise tout de suite : ce n'est pas une facture. Je suis au forfait. C'est ce que mes sessions auraient coûté au tarif de l'API, token par token. Mais 513 000, même en équivalent, ça réveille.

Le bug était bête. Les journaux de Codex donnent des compteurs cumulés : à chaque message, le total depuis le début de la session. Mon lecteur les additionnait comme si chaque ligne était un message à part. Une seule session passait de 1 330 dollars à 243 457.

Ce chiffre-là, je l'aurais cru s'il avait été dix fois plus petit. Et c'est bien le problème.

Pourquoi je mesure

Tous les outils d'agents promettent la même chose : moins de tokens, moins cher, plus vite. Foundry fait tourner chaque rôle sur le modèle qui lui suffit, donc sur le papier je devais économiser.

Sur le papier. J'ai voulu voir.

Règle du jeu, la même à chaque campagne : le seuil est écrit avant la mesure, et gelé. Après, on ne le bouge plus, et on ne réinterprète pas le résultat.

Le pilote : 7,42 %

Première campagne en août. Dix vrais tickets, avec le routage par rôle. L'objectif affiché : 40 % de moins que si tout tournait sur le plus gros modèle.

Résultat : 95,76 dollars contre 103,43. Soit 7,42 %.

Raté de loin. Et même ces 7,42 %, je ne peux pas les revendiquer : c'est le même travail, re-tarifé après coup au prix du gros modèle. Rien ne dit que le gros modèle aurait fait le même nombre d'allers-retours. Ce n'est pas une économie mesurée, c'est une règle de trois.

Décision : je garde le routage. Et je n'annonce rien.

Le rêve du modèle local

Ça, c'est celui qui me tient à cœur. J'ai un Mac avec 64 Go de mémoire. L'idée : un modèle local prémâche le travail — résumer un diff, trier des logs — et le modèle payant reçoit moins à lire.

Quatre candidats : Qwen, gpt-oss, Devstral, Gemma. Seuils gelés d'avance : 100 % de réponses au bon format, et au moins 40 % d'entrée en moins.

Résultat, pour chacun des quatre : 0 sur 12.

Réduction d'entrée mesurée : 0,32 %.

Et le pire, c'est que ça ne dit rien de leur intelligence. En creusant, l'échec venait du format : toutes les réponses contenaient un champ de métadonnées que mon lecteur, volontairement strict, refusait. La campagne n'a jamais mesuré la qualité de ce que les modèles écrivaient. Elle le dit elle-même dans sa conclusion.

Détail qui pique : sur ma première version du test, avec un prompt écrit pour l'occasion, deux candidats faisaient 12 sur 12. C'est en passant par le vrai chemin du produit qu'ils sont tombés à zéro.

Entre les deux, une version entière est morte avant de commencer, sur un disque externe qui ne répondait plus.

Les 48 faux positifs

Dans cette même campagne, mon classifieur a sorti 48 fois « citation falsifiée acceptée ». Quarante-huit alertes de sécurité.

Aucune n'était réelle. Il n'y avait rien à classifier, puisque aucun candidat n'avait produit de réponse valide. Le classifieur, gelé avant la mesure, renvoyait « vrai » sur du vide.

J'aurais pu corriger et relancer. J'ai gardé la sortie brute, intacte, et publié un rectificatif à côté. Si je m'autorise à retoucher un résultat qui me gêne, je m'autoriserai à en retoucher un qui m'arrange.

Octobre : raté de 0,93 %

J'ai retenté, autrement. Cinq versions en une semaine.

D'abord l'ambitieux : un modèle local qui traite un ticket tout seul. Cinq candidats, six tâches. 0 accepté sur 30.

Puis le modeste : le modèle local explore le dépôt, et le modèle payant implémente avec ce qu'il a trouvé. Dix tâches, faites deux fois, avec et sans l'éclaireur local. Cinq acceptées de chaque côté. Égalité sur la qualité.

Restait la question : est-ce que le payant a consommé moins ? Seuil gelé : il devait descendre à 85 % de la consommation de référence.

Il est descendu à 85,79 %.

Raté de 14 485 tokens par tâche. 0,93 %.

Je conserve le cloud. Le seuil était écrit avant, et un seuil qu'on arrondit quand il gêne n'est plus un seuil.

D'autant qu'en regardant de plus près, c'était encore moins flatteur. Tous les tokens ne valent pas le même prix. En pondérant par les tarifs, le ratio passe de 0,86 à 1,03. Avec l'éclaireur local, ça coûtait un peu plus. « Moins de tokens » dépend de ce que pèse un token.

Le test qui a refusé de répondre

Mon préféré. Pour valider un changement de modèle, un petit essai : l'agent doit lire un fichier et en recopier la valeur.

Non conforme. L'agent a refusé de recopier.

Le fichier s'appelait token.txt. Et mes propres consignes interdisent d'afficher des secrets. Le modèle a fait exactement ce que je lui demande d'habitude.

Le verdict est resté « non conforme ». Le second essai, avec un fichier au nom neutre, est passé. Les deux sont dans le dossier.

Ce qu'il me reste

Trois réflexes.

Inconnu n'est pas zéro. Quand une donnée manque, la case reste vide. Pas « 0 dollar ». Vide.

Le seuil d'abord. Écrit et gelé avant la mesure. Sinon tu trouves toujours une lecture qui t'arrange.

On garde le brut. Le résultat faux reste dans le dossier, avec son rectificatif à côté.

Est-ce que c'est frustrant ? Oui. Franchement oui. Je n'arrive pas encore à intégrer un modèle local qui soit pertinent, et au bon niveau. J'ai une machine qui pourrait, des modèles qui s'améliorent tous les mois, et un dossier plein de « non concluant ».

Mais je sais pourquoi. Je sais à 0,93 % près où est la ligne. Et le jour où un modèle la franchit, j'aurai le protocole pour le voir — et pour le croire.

En attendant, le seul gain que je peux affirmer ne figure dans aucun de mes tableaux : ce que je livre est meilleur. Celui-là, je ne l'ai pas mesuré. Je le constate à chaque merge.

— Pato