Au cours du dernier mois, les agents de codage que je construis ont traité 13 milliards de tokens entre l'entrée et la sortie, avec un taux de cache hit de 97,24 % et un coût effectif d'environ 0,04 R$ par million de tokens.
Quand je mentionne ces chiffres, la première réaction est généralement de la méfiance — et c'est sain. Le coût est la raison numéro un pour laquelle les entreprises abandonnent les agents autonomes : le pilote fonctionne, la facture arrive, le projet meurt. Cet article explique donc comment ces chiffres sont obtenus. Il n'y a pas de truc unique ; il y a une architecture où chaque token qui entre et sort est compressé, routé et mesuré.
Voici Velua Code, l'agent que nous construisons dans une nouvelle startup que j'ai décidé de lancer, Velua AI (https://velua.ai). Avant l'architecture, la thèse.
La Thèse : Trois Problèmes, Résolus Ensemble
Les agents de codage cassent à trois endroits, et résoudre un seul problème ne suffit pas.
Coût. Un agent autonome consomme des tokens à une échelle qui effraie n'importe quel CFO. Si chaque itération est coûteuse, personne ne laisse l'agent itérer — et un agent qui n'itère pas ne résout rien de concret.
Contexte. La fenêtre de contexte est finie et coûteuse. L'implémentation typique remplit le prompt avec des fichiers entiers et des résultats de grep, en payant pour des milliers de tokens non pertinents à chaque appel.
Mémoire. Chaque session repart de zéro. L'agent redécouvre mardi ce qu'il avait déjà appris lundi — et paie (en tokens et en erreurs) pour le redécouvrir.
Les trois s'alimentent mutuellement : un contexte gonflé augmente le coût, l'absence de mémoire gonfle le contexte. C'est pourquoi Velua Code attaque les trois à la fois.
Coût : Compression Source + Routage Actif
La première décision architecturale : compresser le contexte à la source, pas à la fin. Chaque sortie d'outil — lecture de fichier, résultats de recherche, logs de build — passe par un pipeline de compression avant d'entrer dans l'historique de la session. Le cœur est un modèle de compression propriétaire tournant localement en ONNX, sur la machine du développeur ou dans le conteneur de l'agent. Il n'y a pas d'appel réseau pour compresser : les économies ne coûtent pas de tokens.
Autour de lui, des couches plus simples font le gros du travail : déduplication des lectures (l'agent a-t-il relu le même fichier ? l'ancienne version quitte le contexte), compression structurelle JSON, élision du corps du code tout en maintenant les signatures, et un seuil adaptatif qui resserre la compression à mesure que le contexte grandit. Tout est mesuré avec le tokenizer réel du modèle cible — les économies comptées en tokens réels, pas en estimations.
Et il y a une décision sur ce qu'il ne faut pas faire : nous ne touchons jamais au prompt système à l'exécution. Un prompt stable est ce qui maintient le taux de cache hit à 97,24 % — et le cache hit est le levier de coût le moins cher qui existe, car un token en cache coûte une fraction d'un token complet.
La deuxième décision : l'agent ne choisit pas le modèle. Un classifieur local pré-classifie chaque tâche par catégorie et complexité, et la Velua Gateway — qui voit 50+ modèles avec prix et performance en temps réel — route vers le modèle le plus capable dans la limite du nécessaire, en plus d'appliquer des garde-fous et d'enrichir avec du RAG. Renommer une variable n'a pas besoin d'un modèle frontalier ; concevoir une migration de schéma, oui. Avec le routage actif, la plupart des appels vont vers des modèles plus petits, et le modèle coûteux n'intervient que lorsque la complexité l'exige.
La gateway mesure également le coût réel de chaque requête. Cela permet quelque chose que je considère comme non négociable pour les agents en production : le budget comme condition d'arrêt. La boucle autonome tourne avec un plafond de coût en devise, pas avec de l'espoir.
C'est la combinaison — compression source, cache élevé, routage entre modèles plus petits — qui produit les 0,04 R$ par million. Aucun des trois éléments pris isolément ne s'en approche.
Contexte : Un Graphe au Lieu de Grep
La façon standard pour un agent de "comprendre" une base de code est le grep et la lecture de fichiers — coûteux et aveugle. Velua Code maintient un graphe de connaissance du code : fonctions, classes, routes, et les relations entre elles (qui appelle qui, qui implémente quoi).
Cela change les deux extrémités de la boucle. En entrée, l'agent assemble un package de contexte léger en consultant le graphe — la vue architecturale du projet et les nœuds pertinents pour la tâche — au lieu de déverser des fichiers dans le prompt. En sortie, cela change la vérification : quand l'agent modifie une fonction, le graphe liste exactement les points d'appel impactés, et un agent réviseur — avec un contexte propre, sans le biais de celui qui a écrit le code — vérifie chacun d'eux, en plus d'exécuter les tests, le lint et le build. "Tu as changé la signature de processOrder ; sept endroits l'appellent" est un type de vérification que grep ne fournit pas.
Mémoire : La Boucle Qui Apprend
La pièce qui ferme le système. À la fin de chaque itération vérifiée, l'agent enregistre les décisions d'ingénierie : ce qui a été décidé, pourquoi, quelles alternatives ont été considérées, ce qui a échoué. Et chaque décision est liée aux nœuds de code qu'elle explique, au sein même du graphe.
À l'itération suivante, la phase de collecte de contexte récupère ces décisions — y compris les approches qui ont déjà échoué, pour ne pas les répéter. La boucle cesse d'être un exécuteur qui répète des tâches et devient un système qui accumule des connaissances sur la base de code. C'est aussi le meilleur amortisseur de coût qui existe : une mémoire bon marché remplace une redécouverte coûteuse.
La boucle complète, donc : collecter le contexte (graphe + mémoire + RAG), planifier avec le bon modèle pour la taille du problème, agir avec des sous-agents, vérifier avec un réviseur à contexte propre et une conscience du graphe, apprendre en enregistrant les décisions — et répéter, avec un plafond de coût. C'est la boucle agent canonique, avec chaque phase générique remplacée par sa propre capacité.
Pourquoi le Premier Client, C'est Nous
La stratégie produit est délibérément contre-intuitive : avant de vendre à un client quelconque, Velua Code tourne en interne chez SIGE Cloud. Du vrai dogfooding — un ERP en production, avec des équipes réelles faisant opérer des agents sur du code réel, chaque jour.
C'est cette utilisation interne qui a généré les 13 milliards de tokens, et c'est ce qui façonne le produit. Les agents autonomes en production exposent des problèmes qu'aucun benchmark n'expose : permissions, coût accumulé, tâches qui calent, contexte qui pourrit. Je préfère que ça mûrisse là où la douleur est la nôtre.
La Suite : Une Mémoire Unifiée pour les Entreprises
Aujourd'hui, la mémoire des décisions vit par projet. La prochaine étape est ce qui m'excite le plus : l'élever à un niveau de couche mémoire d'ingénierie unifiée pour les entreprises.
Imaginez la décision enregistrée par l'agent de l'équipe A — "nous avons migré vers X à cause de Y ; nous avons évité Z parce que ça cassait W" — récupérable par l'agent de l'équipe B, et par les développeurs humains qui opèrent ces agents, avec contrôle d'accès, traçabilité et audit. La question "pourquoi ce code est-il comme ça ?" répondue avec la décision originale, liée au code, pour n'importe qui ou n'importe quel agent dans l'organisation. Un onboarding plus rapide, une cohérence entre les équipes, et la connaissance technique de l'entreprise qui ne réside plus seulement dans les têtes des gens.
Servie par la gateway, cette mémoire devient une infrastructure : tout agent dans l'entreprise, dans n'importe quel outil, hérite de l'apprentissage accumulé.
Les agents autonomes seront une commodité. La connaissance qu'ils accumulent sur
votre
système ne le sera pas.
C'est le pari.
Si vous construisez avec des agents en production — ou que vous vous heurtez aux coûts de contexte — ma boîte de réception est ouverte.
