Vos économies d'IA peuvent disparaître sans aucun message d'erreur

Le service fonctionne. Les réponses sont bonnes. Aucune alerte n'est apparue depuis des semaines. Pourtant, la facture du fournisseur d'intelligence artificielle n'a pas bougé, alors que votre équipe croyait avoir activé une remise importante.

Ce n'est pas une panne. C'est un défaut plus discret : l'économie est bien branchée, mais elle ne sert jamais. Une équipe de chercheurs a analysé 120 corrections de ce type, dans dix systèmes d'agents à code source ouvert. Dans 90 % des cas, aucun message d'erreur n'apparaît. La seule trace est une dépense plus élevée que prévu.

L'étude a été déposée le 26 octobre 2026 sur arXiv, l'archive publique des travaux scientifiques. Elle est acceptée à ICSE 2027, la principale conférence de génie logiciel. Ses auteurs viennent de l'université Griffith, de l'université technologique de Nanyang, de l'université de Nouvelle-Galles du Sud et de l'université des sciences et technologies du Sud.

Ce que la mise en cache fait réellement

Un agent est un programme à qui l'on confie un objectif et des outils. À chaque étape, il envoie à un modèle d'IA un long texte : les consignes, la liste des outils, le contexte, puis la conversation. Les premières pages sont presque identiques d'un appel à l'autre.

Le fournisseur peut donc conserver le début déjà traité. C'est la mise en cache : le service garde le calcul des premières pages et le réutilise au lieu de le refaire. Un token — un fragment de texte, l'unité que le modèle compte et facture — lu dans le cache coûte environ un dixième du prix normal. Le délai de réponse peut baisser jusqu'à 80 %.

L'image utile est celle du formulaire pré-rempli. Le guichet garde les trois premières pages déjà remplies et vous rend la suite à compléter. Si vous changez la date en haut de la première page, il vous rend un formulaire vierge. Le travail est refait, et personne ne proteste.

Les fournisseurs ne jouent pas la même partition. Anthropic et Amazon Bedrock exigent une activation explicite. OpenAI et Gemini appliquent la mise en cache automatiquement. Un réglage écrit pour l'un ne produit donc rien chez l'autre. Les règles bougent aussi : Anthropic a ramené la durée de vie par défaut du cache d'une heure à cinq minutes. Des déploiements inchangés ont vu leur taux de réussite chuter.

Une horloge suffit à tout annuler

L'exemple le plus parlant vient de PrivateGPT, un outil à code source ouvert qui répond à des questions sur des documents internes.

Un développeur voulait que l'assistant connaisse l'heure courante. Il a placé un horodatage à la seconde en tête des consignes. Or la comparaison se fait au caractère près, depuis le tout premier. Un horodatage qui change à chaque appel rend le début différent à chaque appel. Le cache ne peut jamais répondre.

La correction tient en un mot : l'horodatage est passé à la journée. Le début redevient stable pendant vingt-quatre heures, et l'heure reste juste.

Les chercheurs classent ces causes en quelques familles. Une valeur volatile glissée dans la partie mise en cache. Un début reconstruit dans un ordre différent à chaque tour. Une conversion en texte qui produit des octets différents pour un contenu identique. Un marqueur posé sur un message qui change, au lieu du début stable. Ou un état modifié entre deux tours, qui réécrit une partie déjà mise en cache.

Un cas cité dans l'étude, hermes-agent#754, a fait grimper la facture d'environ 75 %. Une passerelle reconstruisait les consignes à chaque tour.

Pourquoi personne ne le voit

Sur les 120 défauts étudiés, 108 ne produisent aucune erreur. Ni exception, ni test rouge, ni page d'erreur. La réponse du modèle reste correcte. Seul le compteur de dépense bouge.

Parmi eux, 86 cas sont du gaspillage pur : le cache ne répond plus, le service continue, la facture monte. Les 22 autres sont plus retors. La mise en cache fonctionne, mais les compteurs affichés sont faux. Le tableau de bord que l'équipe consulte pour vérifier l'économie est lui-même erroné.

Les 12 défauts restants plantent franchement. Huit viennent d'un marqueur incompatible avec le modèle appelé. Ceux-là se voient tout de suite, et un simple test les attrape.

C'est le cœur du problème. Les contrôles habituels cherchent une erreur. Ici, l'erreur est une absence : celle d'une remise. Un test qui vérifie la justesse d'une réponse ne verra jamais qu'elle a coûté dix fois trop cher.

Ce que les 120 correctifs révèlent

La répartition est instructive. 97 défauts sur 120 abîment la requête envoyée. Les 23 autres ne touchent pas à la requête, mais lisent mal les compteurs de cache.

Parmi les 97, 47 viennent de la diversité des mécanismes entre fournisseurs. Un marqueur ajouté pour Anthropic, envoyé à un modèle qui ne le reconnaît pas, provoque une erreur explicite. Le cas inverse est plus fréquent : le marqueur manque, et le cache reste simplement inactif.

Les corrections sont petites. 82 des 120, soit 68 %, sont locales, ou se contentent de réparer un compteur. Il ne s'agit presque jamais d'une refonte.

Les auteurs ont ensuite construit un outil qui lit le code sans l'exécuter. Sur les 120 défauts connus, il atteint 0,71 de précision, la part d'alertes justes, et 0,78 de rappel, la part de défauts trouvés. Sur 571 projets réels, il a signalé 32 défauts inconnus, avec 0,86 de précision. Vingt et un ont été confirmés par les mainteneurs et dix-huit corrigés, dont un dans le kit de développement officiel d'Anthropic.

Trois vérifications à demander à votre équipe

Suivez le taux de réussite du cache, pas la promesse. Chaque fournisseur renvoie des compteurs de tokens lus dans le cache. Si personne ne les suit, personne ne sait si l'économie existe. Un taux proche de zéro, sur un agent qui enchaîne les appels, est le signal d'alerte.

Cherchez ce qui change en tête de requête. Un horodatage, un identifiant tiré au hasard, une liste d'outils réordonnée, un nom de modèle codé en dur. Ces quatre éléments suffisent à annuler la mise en cache. La correction consiste souvent à déplacer la valeur volatile après la partie stable.

Testez après chaque changement de modèle ou de fournisseur. Un modèle renommé peut sortir du filtre qui activait le cache, sans erreur. L'étude cite un projet où ce seul changement a fait remonter la facture, sans autre signe.

Trois limites empêchent d'en faire une règle absolue. L'étude porte sur des projets à code source ouvert, pas sur des produits commerciaux. Elle compte des défauts déjà corrigés, donc visibles. Et elle ne mesure pas la facture réelle des projets, seulement les mécanismes en cause.

La conclusion utile reste simple. Une économie qui ne se mesure pas n'existe pas. Le seul chiffre qui compte est celui que le fournisseur facture, comparé à ce qu'il facturerait sans cache.

Ce qu'il faut retenir

• La mise en cache du début des requêtes peut ramener le coût des tokens concernés à environ un dixième du prix normal.
• Sur 120 défauts étudiés dans dix agents à code source ouvert, 108 n'ont produit aucune erreur : la facture montait, le service fonctionnait.
• Une valeur qui change en tête de requête, comme un horodatage, suffit à annuler l'économie à chaque appel.
• 82 des 120 corrections sont locales, souvent une ligne ou un compteur : le défaut est fréquent, pas forcément coûteux à réparer.
• Suivez le taux de tokens lus dans le cache, et testez-le après chaque changement de modèle ou de fournisseur.
• Sans mesure du taux de réussite, vous ne saurez jamais si la remise annoncée arrive sur votre facture.