Petit jeu. Vous êtes CTO. Vous avez donné à vos ingénieurs une carte bancaire sans relevé, et maintenant la société émettrice aimerait vous dire un mot. Le CTO d'Uber a mis un chiffre sur ce mot le mois dernier : le budget annuel complet de coding IA, parti en avril. Le plus intéressant n'était pas la taille de la facture. C'était la deuxième phrase — « je retourne à la planche à dessin parce que le budget dont je pensais avoir besoin est déjà pulvérisé ». Ce qui, traduit du langage exécutif poli, donne : nous avons payé la facture, nous savons exactement combien elle a coûté, nous ne pouvons pas vous dire ce qu'elle a acheté, et nous aimerions arrêter de faire ça.

Bon, la façon moderne d'acheter du logiciel consiste à donner aux ingénieurs un truc qui facture au token, à leur dire de l'utiliser avec discernement, et puis à attendre. The Information a rapporté le mois dernier que le CTO d'Uber, Praveen Neppalli Naga, avait attendu et découvert que son budget annuel 2026 de coding IA était déjà parti en avril, ce qui, comme calendrier, est ambitieux. L'usage de Claude Code dans l'entreprise a presque doublé en un trimestre ; en mars, 84 % des ingénieurs d'Uber étaient classés comme utilisateurs de coding agentique, et tant mieux pour eux. La dépense par ingénieur allait grosso modo de 500 à 2 000 $ par mois, le CTO lui-même brûlant 1 200 $ lors d'une démo personnelle de deux heures — soit à peu près le tarif horaire d'un collaborateur junior dans un cabinet d'avocats de Midtown, lequel produirait au minimum une feuille de temps. La ligne globale R&D d'Uber était de 3,4 milliards de dollars en 2025, donc ce n'est pas qu'ils n'avaient pas la place. C'est que le modèle est parti chercher plus de place qu'ils n'en avaient, en a trouvé, et l'a facturée.

Le billet qu'on attendrait d'une entreprise d'isolement et de sécurité à ce stade serait « utilisez un sandbox ». Ce n'est pas ce billet-là. On l'a déjà écrit, évidemment. Voici l'autre moitié du même problème, celle où la facture arrive, vous pouvez la lire, et vous ne pouvez pas répondre à la seule question que tout le monde veut poser, à savoir : d'accord, mais pour quoi.

La facture va bien. La facture est le problème.

La tarification au siège était très facile à se représenter, et vous devriez apprécier l'ère du siège maintenant qu'elle est révolue. Vous achetiez 200 sièges de GitHub Copilot à 19 $ chacun, vous obteniez une ligne à 3 800 $ par mois, et quand quelqu'un demandait « qu'est-ce qu'on a eu pour ça ? », la réponse était un haussement d'épaules en forme d'industrie — « des complétions de tab, probablement » — et tout le monde retournait en réunion. Ce qu'il y a de particulier avec un haussement d'épaules, c'est qu'il passe à l'échelle. Un haussement d'épaules à 3 800 $ va bien. Un haussement d'épaules à 1,8 million de dollars commence à attirer l'attention de la partie du bâtiment qui a un devoir fiduciaire.

L'outillage agentique facturé au token est d'une autre forme, et il faut y réfléchir avec la figure. Deux ingénieurs d'une même équipe, travaillant sur le même type de feature, peuvent différer en dépense d'un facteur quarante. (Quarante.) L'un ouvre une nouvelle session, demande une chose, l'obtient, ferme la session — 50 $, terminé, rentre chez lui faire des pâtes. L'autre laisse un pack parallèle d'agents s'acharner sur un refactor pendant six heures, relance quand le build casse, relance encore parce qu'un autre modèle a estimé que la première relance était fausse, relance une troisième fois parce qu'à ce stade c'est personnel. Les deux ingénieurs ont livré du code. L'un a livré pour 50 $ de temps modèle. L'autre a livré pour 2 000 $. La facture ne dit pas qui est qui. L'IDE ne dit pas qui est qui. La finance reçoit un unique chiffre agrégé, l'ingénierie reçoit un fil Slack qui dit « Claude was amazing today », et aucun des deux, avec tout le respect dû, n'est une mesure.

Ce qui rend la chose difficile, ce n'est pas le prix. C'est qu'aucune des dépenses n'est attachée à quoi que ce soit que vous puissiez auditer un trimestre plus tard. Et donc une PR a atterri. La PR a un diff. Le diff a des commits. Les commits ont des auteurs. L'auteur est un humain. L'humain a utilisé un agent à un moment donné — peut-être. Quel agent ? Quelle session ? Quel prompt ? Pendant combien de temps ? Pour faire quoi ? La piste se perd quelque part autour du scrollback du terminal, qui a été fermé, parce que personne ne scrolle vers le haut. Il y a un nom pour ça en finance, et c'est « la démarque inconnue », même si en logiciel on n'a pas encore pris la peine de le nommer.

La boîte du milieu, c'est tout ce que vous avez acheté. C'est aussi la seule chose que vous ne pouvez pas voir.

À quoi ressemble mai 2026 dans la plupart des organisations d'ingénierie : les dollars sortent de l'entreprise par un gros tuyau, le travail sort de l'autre côté par plein de petits tuyaux, et la partie au milieu — celle pour laquelle vous avez réellement payé — c'est du brouillard. Le CFO voit la facture. Le manager d'ingénierie voit les PRs. Ce qui relie les deux, c'est une fenêtre de terminal fermée et un ressenti.

Bref, la forme de ce problème est plus ancienne que le coding agentique, et si vous êtes dans le métier depuis assez longtemps pour être fatigué, vous la reconnaîtrez instantanément. La dépense cloud a eu le même arc. Cinq ans de « la facture AWS est énorme et personne ne sait pourquoi », puis une génération d'outillage FinOps a commencé à rattacher les dollars aux équipes, aux services et aux requêtes individuelles, et maintenant la facture AWS est énorme et les gens savent pourquoi, ce qui, aussi modeste que ça puisse paraître, est tout le jeu. La solution n'a pas été d'utiliser AWS moins. Elle a été de rendre la dépense lisible.

Le coding agentique est actuellement dans le cloud pré-FinOps. La dépense est réelle, les outils sont bons, la productivité est authentiquement là — rien de tout ça n'est en cause. Ce qui manque, c'est le tissu conjonctif entre « cet ingénieur, sur ce repo, dans cette session » et « ces tokens, ces commandes, ces fichiers, cette PR ». Tant que cette phrase n'existe pas, chaque dollar sur la facture est payé sur la foi, et la conversation avec votre CFO fait partie de ces conversations-là.

Ce que « visibilité » doit vouloir dire, au-delà du dashboard avec le gros chiffre.

Tout le monde dit « observabilité » et tout le monde hoche la tête, et presque personne n'entend la même chose. Les fournisseurs d'agents de coding seront ravis de vous montrer un dashboard. Le dashboard a des compteurs de tokens. Il a des pourcentages d'adoption. Il a un graphique prêt-à-projeter qui monte en haut à droite, ce qui est la forme-graphique de tout logiciel en 2026. Rien de tout ça n'est une réponse. « Vos développeurs ont consommé 2,3 milliards de tokens d'entrée cette semaine » n'est pas une réponse ; c'est une reformulation de la facture en police plus grosse.

Ce dont un CTO a réellement besoin, pour défendre un budget ou en obtenir un plus grand, vient en quatre parties.

Une adoption que vous pouvez montrer sur une slide

Combien de vos ingénieurs ont effectivement utilisé un agent de coding cette semaine. Pendant combien de temps. Sur quels projets, dans quels repos. Pas des licences de sièges émises, pas des détenteurs de clés API, pas des « personnes inscrites au programme » — des sessions initiées, par un humain, sur quelque chose que l'organisation peut nommer.

Chaque fichier que l'agent a touché

Par session, par repo, par ingénieur — l'ensemble exact des fichiers qu'un agent IA a créés, modifiés ou supprimés, avec diffs, rattachés à l'ingénieur qui a lancé la session et au modèle qu'il a utilisé. L'unité de travail, c'est « une mutation de fichier », pas « un token ». Les tokens, c'est comme ça que le fournisseur vous facture. Les fichiers, c'est ce que vous devez livrer.

Chaque commande, chaque source

Chaque commande shell que l'agent a exécutée dans la session, chaque fichier qu'il a lu, chaque outil qu'il a appelé, chaque API qu'il a touchée. Capturé en direct, conservé de manière centralisée, interrogeable par équipe, par repo, par modèle. « Qu'a installé l'agent hier » devient une requête, au lieu d'une fouille archéologique à la lampe-torche avec un SRE junior.

Le dialogue complet, archivé

Prompts, réponses du modèle, appels d'outils — la totalité du transcript. Quelque part de stable. Relisable par la sécurité, échantillonnable par la direction de l'ingénierie, exportable dans la même archive de rétention que vous alimentez déjà pour l'email et le chat. La session est désormais un enregistrement, pas le souvenir d'un truc que quelqu'un a tapé un jour.

Remarquez ce qui n'est pas sur cette liste. Le nombre de tokens n'est pas sur la liste. Il est sur la facture. Le but de la liste, c'est de mettre la facture à côté de ce qu'elle a acheté, pour qu'une équipe finance puisse faire la division, qu'une équipe d'ingénierie puisse arrêter d'argumenter au feeling, et que tout le monde puisse passer la réunion sur la vraie question.

Comment Bromure fait la plomberie.

La feature de coding agentique dans Bromure a, en toute honnêteté, été initialement construite pour la moitié sécurité de cette conversation. Chaque agent de coding tourne à l'intérieur d'une VM Linux jetable sur votre Mac. La VM n'a accès qu'aux dossiers de projet que vous avez montés ; elle n'a pas de clés SSH, pas de credentials AWS, pas de token GitHub posé sur le disque. Un broker de credentials sur l'hôte échange des tokens factices contre des vrais, mais seulement sur le fil, seulement pour des endpoints whitelistés. C'est l'histoire qu'on a déjà racontée, dans laquelle un paquet npm empoisonné essaie de partir avec vos secrets et se prend un mur à la place.

L'histoire d'observabilité, c'est la même plomberie, utilisée pour une autre raison. L'hyperviseur est assis entre l'agent et tout ce qu'il touche. L'agent n'ouvre pas un fichier ; la VM le fait. L'agent n'exécute pas une commande shell ; la VM le fait. L'agent ne fait pas d'appel API ; le proxy sur l'hôte le fait. Chacune de ces opérations est — doit être, parce que la moitié sécurité du job l'exige — un événement nommé, avec un timestamp, un ID de session, une identité d'ingénieur, et un payload. Bromure enregistre déjà tout ça en local. Ça s'appelle le Session Tracer et c'est livré avec Agentic Coding aujourd'hui.

La pièce qui ferme la boucle pour les CTOs (et les CFOs, et les CISOs, et la personne aux achats qui aimerait savoir ce qu'elle a acheté) est le côté cloud. Quand le client Bromure sur le Mac d'un développeur est enrôlé dans votre organisation, ces traces locales cessent d'être un outil de debug local et commencent à être un enregistrement structuré streamé vers votre serveur d'entreprise Bromure. Par ingénieur. Par session. Par projet. Par modèle. Filtrable, exportable, conservable. Le copy produit sur la page agentic coding appelle ça « AI usage monitoring » et le marque actuellement bientôt disponible, ce qui, pour éviter tout doute, est en partie la raison de ce billet.

La même image une fois qu'on a mis un hyperviseur au milieu. Chaque session d'agent tourne dans une VM par développeur. L'hyperviseur et le proxy de credentials voient déjà chaque commande shell, chaque fichier, chaque requête sortante — ils doivent les voir, pour faire la moitié sécurité de leur job — et le serveur d'entreprise est l'endroit où ces événements atterrissent dans une table par laquelle vous pouvez enfin diviser la facture. Claude Code reste Claude Code, Cursor reste Cursor, Codex reste Codex ; les agents sont inchangés. La boîte du milieu, celle qui était autrefois du brouillard, est maintenant une base de données.

La raison pour laquelle les événements sont fiables, ce n'est pas un sidecar à l'intérieur de l'agent, et ce n'est pas un wrapper autour de l'API du modèle, l'un comme l'autre étant en principe contournables par l'agent s'il en avait envie. Les événements sont fiables parce que l'agent tourne dans une VM dont l'hyperviseur doit connaître chaque commande et chaque fichier, qu'on le lui demande ou non. L'observabilité est, en un sens, gratuite. Vous avez déjà payé pour. La facture disait « isolement ». Ce que vous avez obtenu, c'est aussi un log. Et donc vous obtenez le même enregistrement que l'ingénieur ait utilisé Claude Code, Cursor en mode CLI, Codex, Aider ou un agent interne dont on n'a jamais entendu parler — parce que l'unité d'enregistrement, c'est « chose que la VM a faite », pas « chose que le fournisseur a décidé d'exposer ce trimestre ».

À quoi ressemble, à la place, la conversation un trimestre plus tard.

Le chiffre d'Uber est utile pour réfléchir, parce que rien là-dedans n'est un échec. 84 % d'adoption. Du code livré. Un CTO qui a effectivement retroussé ses manches et utilisé l'outil, ce qui, soit dit en passant, est ce que plus de CTOs devraient faire, même à 1 200 $ la démo. Ce qui s'est cassé, c'est la conversation un trimestre plus tard. « Faut-il doubler la mise ? Reculer ? Étager nos sièges ? Pousser les gens vers des modèles moins chers pour certaines classes de travail ? » Aucune de ces décisions n'est prenable depuis une facture de tokens agrégée. Elles sont toutes parfaitement prenables depuis une table par ingénieur, par session, par repo. Les décisions ne sont pas devenues plus dures. C'est la table qui a été retirée.

Une poignée de questions qui deviennent répondables, plus ou moins dans l'ordre où on les entend de la part des gens qui essaient de défendre une ligne budgétaire :

Quels ingénieurs obtiennent une valeur démesurée, et que font-ils différemment ? Regardez les ingénieurs dont le ratio dépense / fichiers modifiés se trouve dans le bon coin de la distribution. Lisez quelques-unes de leurs traces de session. Une partie de ce qu'ils font bien est du style, une partie est de la technique, une partie est juste le choix du modèle qu'ils attrapent. Rien de tout cela n'est visible sans l'enregistrement. (« Comment Alice arrive-t-elle à livrer autant de code pour si peu d'argent ? » est le genre de question qui produit un déjeuner-partage interne utile, mais seulement si les sessions d'Alice ne sont pas un terminal fermé quelque part.)
La dépense est-elle concentrée dans une équipe, un repo, un type de travail ? Si 60 % de votre facture IA vient d'un seul service legacy et que l'agent passe surtout son temps à patauger sur des tests flaky, c'est un constat. Ce n'est aussi pas un constat sur l'IA.
Quels projets sont productifs avec quel modèle ? « Claude est meilleur que Cursor » est un tweet. « Claude a livré 3x plus de modifications de fichiers par dollar que Cursor sur notre repo front-end le mois dernier, et l'inverse sur notre service Go » est une conversation d'achats.
Qu'a installé l'agent, et où ? C'est la question de l'équipe sécurité, et c'est la même requête contre la même table. Chaque npm install, chaque pip install, chaque apt-get que l'agent a exécuté, par session, par repo, filtrable par nom de paquet. Le jour où un paquet empoisonné apparaît sur un registry — ce qui, geste vague vers la plupart des semaines du calendrier — la question « est-ce qu'un de nos agents a touché à ça ? » est une clause WHERE au lieu d'un exercice d'incendie.

Ce sur quoi il faut être prudent : aucune de ces questions n'est répondable depuis le dashboard du fournisseur du modèle non plus, et elles ne peuvent pas l'être. Le fournisseur voit des tokens. Le fournisseur voit, parfois, prompts et complétions pour la durée d'une requête. Le fournisseur ne voit pas votre repo, vos mutations de fichiers, vos commandes shell, ni quel ingénieur de votre organisation a tapé quoi. Le fournisseur ne peut pas. Le fournisseur est du mauvais côté du fil. La couche de visibilité doit vivre de votre côté — sur la machine du développeur, dans la VM, dans votre serveur d'entreprise — parce que c'est là que le travail se passe réellement. Les compteurs de tokens, c'est une carte postale depuis le terrain.

Avertissements, parce qu'évidemment.

Quelques-uns honnêtes, parce que la pire version d'un billet comme celui-ci, c'est celui qui promet un rapport finance de fin de l'Histoire et qui livre ensuite un dashboard.

L'enregistrement de Bromure vous dit ce que l'agent a fait. Il ne vous dit pas si ce que l'agent a fait était bon. Une session qui a écrit 40 fichiers et livré une PR peut toujours avoir livré 40 mauvais fichiers. L'enregistrement les rend plus faciles à trouver, plus faciles à discuter, et plus faciles à révertir. Il ne les passe pas en revue, en soi. La revue de diff reste sur vos épaules, et sur celles de l'humain dans la boucle, et sur celles de l'ingénieur senior très fatigué à 17h.

L'enregistrement de Bromure couvre ce que l'agent fait à l'intérieur de la VM. Il ne couvre pas ce que l'ingénieur fait dans sa tête avant d'ouvrir l'agent. La conversation de cinq minutes qu'un ingénieur a avec Claude dans son IDE avant que la vraie session ne commence n'est pas sur cette bande. C'est un vrai manque. Ce n'est pas un manque qu'on prétend combler, parce qu'on ne peut pas le combler sans un produit beaucoup plus bizarre.

L'enregistrement de Bromure est de votre côté du fil, ce qui est tout l'intérêt — mais ça veut aussi dire que votre côté du fil, c'est là où la politique de rétention, les contrôles d'accès et les contrats de manipulation des données doivent vivre. Les prompts incluent du code. Le code inclut des secrets que vos développeurs n'auraient pas dû coller mais ont absolument collés. L'enregistrement est aussi sensible que le travail, et vous devriez le traiter comme tel. Le stockage est le vôtre ; la responsabilité est la vôtre. (« Il y a un nom pour ça en finance, et c'est « la démarque inconnue » », sauf que maintenant la démarque est une table SQL et vous pouvez l'auditer.)

Et enfin, ceci est une pièce d'une histoire plus large. L'autre pièce, c'est celle qu'on a déjà couverte — que faire tourner les agents de coding à l'intérieur d'une VM avec un broker de credentials est la façon d'empêcher le prochain paquet npm empoisonné de partir avec vos clés SSH. L'histoire sécurité et l'histoire observabilité, c'est la même plomberie. Elles déposent juste leurs notes de frais des jours différents.

Payez la facture. Mais payez-la en sachant ce qu'elle a acheté.

La phrase d'Uber — I'm back to the drawing board because the budget I thought I would need is blown away already — va être la phrase de beaucoup de CTOs cette année. Elle allait toujours l'être. La tarification au token sur des outils dont l'appétit n'est borné que par l'ambition que ressent le modèle à 14h va produire cette phrase dans chaque entreprise qui les adopte sans les instrumenter. Les agents ne sont pas le problème. C'est la plomberie.

Bromure Agentic Coding, à contrecœur, est ce à quoi ressemble la plomberie quand elle fait son boulot. Chaque agent tourne dans sa propre VM, chaque session est un enregistrement structuré, chaque enregistrement est streamé vers un endroit que votre équipe finance et votre CISO peuvent tous deux interroger, et les agents que vous aimez déjà restent exactement ce qu'ils étaient. Vous paierez toujours la facture. Vous saurez juste, enfin, ce qu'elle a acheté — ce qui, la dernière fois qu'on a vérifié, était le minimum syndical qu'une société de carte bancaire demande à ses clients.