[{"data":1,"prerenderedAt":697},["ShallowReactive",2],{"article-en-\u002Fai\u002Fai-spend-nobody-tracks":3,"article-sibling-en-\u002Fai\u002Fai-spend-nobody-tracks":340,"surround-en-\u002Fai\u002Fai-spend-nobody-tracks":653,"related-en-\u002Fai\u002Fai-spend-nobody-tracks":660},{"id":4,"title":5,"body":6,"date":318,"description":319,"draft":320,"extension":321,"img":322,"meta":323,"navigation":324,"path":325,"seo":326,"slug":327,"stem":328,"tags":329,"topics":335,"__hash__":339},"content\u002Fai\u002F1.ai-spend-nobody-tracks.md","Nobody Knows What Your Company Spends on AI",{"type":7,"value":8,"toc":301},"minimark",[9,13,16,19,24,27,30,33,36,40,43,51,58,65,68,71,75,78,81,84,87,91,94,97,100,103,107,110,116,122,128,132,135,138,141,144,147,150,154,157,160,163,166,170,173,176,179,182,186,189,192,195,198,202,205,208,211,214,217,220,224,227,230,233,236,239,243,246,249,252,256],[10,11,12],"p",{},"It is six in the evening and the working day is over. Somewhere in the company, a support agent pasted three customer emails into a chat window to get help drafting a reply. A lawyer uploaded a draft contract to summarize its risk clauses. A developer ran an agent across a private repository for four hours. A marketing manager generated forty product descriptions. An intern, told to be resourceful, put an export of the CRM into a prompt to find patterns in it. Some of those people used a company account. Most used a personal one, because it was faster and nobody said not to.",[10,14,15],{},"Now ask the questions any board would eventually ask. How much did the company spend on artificial intelligence today? Which departments spent it? Did any regulated data leave the building, and under which provider's terms? Did any of it produce something worth the money? In the overwhelming majority of organizations, the honest answer to all four is the same: we do not know, and we have no mechanism that could tell us.",[10,17,18],{},"This is not a failure of discipline, and the people in the story are not doing anything unreasonable. It is a structural gap. The tools arrived faster than the controls, they are consumed through a channel nobody instrumented, and they are billed in a unit that no finance process was designed to handle. The instinct in most companies is to close the gap with a policy: publish an AI charter, list the approved tools, forbid the rest. That instinct is wrong, and this article is about why, and about what actually works instead.",[20,21,23],"h2",{"id":22},"shadow-it-at-least-left-a-receipt","Shadow IT at least left a receipt",[10,25,26],{},"We have seen this shape before. In the SaaS era, teams bought tools their IT department had never heard of, and the industry called it shadow IT. The comparison is useful but it flatters the current situation, because shadow AI is worse in three specific ways.",[10,28,29],{},"Shadow IT left artifacts. Someone had a subscription, on a corporate card, renewing monthly, with an invoice arriving in an inbox. Finance could find it. There was an account with an admin, a domain, a login page, a contract with terms someone could eventually read. The trail was thin but it existed, and enough companies eventually built SaaS discovery tooling on exactly that trail. A prompt leaves nothing. It is a request, a response, and a token count on a bill that belongs to the employee's personal credit card. When the employee leaves, the trail leaves with them.",[10,31,32],{},"Shadow IT moved data on purpose. Uploading a customer list to an unapproved CRM was an act with intent behind it, and it was rare enough to be an incident. In the AI case, moving data is the interaction. There is no way to ask a model for help with a contract without sending it the contract. Exfiltration is not the abuse of the tool, it is the normal, correct, everyday use of the tool. Any control model built on the assumption that data movement is exceptional will be wrong on the first day.",[10,34,35],{},"Shadow IT had a fixed price. That is the difference that breaks the finance side. A SaaS seat is a known number per user per month, forecastable a year ahead, and the worst case equals the best case. Inference is metered by the token, which means consumption is unbounded by construction and the same headcount can produce a bill that varies by an order of magnitude between two consecutive months. There is no seat count to multiply. This is the observation that leads most executives to the question that opens the next section, and it is worth taking seriously rather than dismissing.",[20,37,39],{"id":38},"the-three-unknowns","The three unknowns",[10,41,42],{},"Strip the problem down and there are exactly three things a company cannot currently answer about its own AI usage.",[10,44,45,46,50],{},"The first is ",[47,48,49],"strong",{},"attribution",": who spent what, on which model, for which team, on which project. This is an accounting question. It has a well understood shape, it maps onto structures the company already has, and it is entirely tractable with the right plumbing.",[10,52,53,54,57],{},"The second is ",[47,55,56],{},"exposure",": what data left the organization, to which processor, under which retention and training terms, and whether any of it falls under a regime that requires a declaration. This is a legal and security question. It is harder, because answering it fully requires inspecting content, and inspecting content creates its own problems.",[10,59,60,61,64],{},"The third is ",[47,62,63],{},"value",": what came back. Did the four hours of agent time save a day of work or produce a branch nobody merged. Did the forty product descriptions convert. This is the question everyone actually cares about and the one nobody in the industry can currently answer with rigor, including the vendors selling the answer.",[10,66,67],{},"These three are not independent, and their relationship is the argument of this article. Attribution is the only one that is cheap to measure. It is also the one that, once you have it, materially advances the other two. A system that knows which key made which call, to which model, with which volume, is one configuration change away from also knowing which calls carried a redacted payload and which team is producing them. You do not get exposure control and value measurement by demanding them directly. You get them as a byproduct of building the accounting layer, because the accounting layer is the point of passage that all three questions need.",[10,69,70],{},"That is the whole strategy in a sentence. Chase the money, because the money is the only thread you can pull that drags the rest along with it.",[20,72,74],{"id":73},"why-the-ai-charter-does-not-work","Why the AI charter does not work",[10,76,77],{},"The standard first response to shadow AI is a document. It names the approved tools, forbids the others, tells employees not to paste confidential information into public models, and asks them to acknowledge that they have read it. Some version of this document now exists in most large organizations. Almost none of them are enforced, because none of them can be.",[10,79,80],{},"A rule is only as real as the mechanism that observes it. A policy that says \"do not send customer data to unapproved models\" has no observer. Nothing in the network stack, the endpoint, or the identity provider is watching for it by default. There is no gate the employee passes through where the rule could be applied. The rule is therefore not a control, it is a statement of preference with a signature attached, and its main function is to move liability from the company to the employee. That may be worth something to a legal team. It is worth nothing to the person who has to answer the board's four questions.",[10,82,83],{},"Security learned this lesson twenty years ago with web filtering, and again with data loss prevention. Nobody writes a policy saying \"do not visit malicious sites\" and considers the problem solved. They put a proxy in the path, because the proxy is what turns the sentence into an outcome. The same logic applies here and it is not a new insight, but it has a consequence for AI that is easy to miss, and the rest of this article turns on it.",[10,85,86],{},"There is a second, sharper reason the charter fails. The prohibited behavior is also the productive behavior. Web filtering works partly because the employee gains nothing from the blocked site. Here, the employee who ignores the policy does better work, faster, than the one who follows it. A control that makes compliant employees less effective than non compliant ones will lose, every time, regardless of how senior the person who signed it. Any workable model has to be one where using the sanctioned path is the easier path, not the more virtuous one.",[20,88,90],{"id":89},"the-fixed-budget-is-the-wrong-question","The fixed budget is the wrong question",[10,92,93],{},"When the charter fails, the next move is usually financial: give the AI spend a line in the budget. Allocate a fixed amount per employee per year, approve it once, and treat it like any other cost center. And then the objection arrives immediately, and it is a real one: these services are billed per token, so the amount consumed cannot be known in advance, so a fixed budget cannot be committed in advance. The finance director is right about the mechanics and stops there.",[10,95,96],{},"But look at what the objection actually says. It says: this cost is variable, consumption driven, unbounded in principle, attributable only after the fact, and generated by decentralized decisions made by people who do not see the price of what they are doing. That is not a new category of problem. That is a description of public cloud, circa 2010, almost word for word.",[10,98,99],{},"No company has a fixed AWS bill either. What they have, if they are mature about it, is something better than a fixed bill: they have per team attribution, a unit cost they track, a forecast with a known error range, budgets with alerts, and a set of guardrails that make the pathological cases impossible rather than merely discouraged. Nobody asks the cloud provider for a flat rate. They build the practice that makes a variable cost governable. That practice has a name, a body of work behind it, and a foundation that maintains its framework. Turning it on AI workloads is not an analogy stretched for the sake of an article. It is the same problem with a different meter.",[10,101,102],{},"So the question to bring to the finance director is not \"how much will we spend on AI next year\". It is \"what is our unit of consumption, who owns it, and what is the maximum we can lose in a day\". Those three have answers.",[20,104,106],{"id":105},"what-finops-actually-offers-here","What FinOps actually offers here",[10,108,109],{},"The FinOps lifecycle is usually described in three phases, and each one maps onto the AI problem cleanly enough to be worth walking through. The Foundation has since expanded the framework into domains and extended its scope beyond public cloud to cover SaaS and AI workloads, but the original three phase framing remains the clearest way to sequence the work.",[10,111,112,115],{},[47,113,114],{},"Inform"," comes first and it is the phase most companies skip. Before any budget, any limit, any policy, you need visibility: a showback that tells each team what it consumed last month, broken down by model and by use case. Showback is not chargeback. Nothing is billed internally yet, nothing is blocked, the only output is a number sent to a team lead who has never seen one before. The effect of that number is consistently underestimated. A large share of wasteful AI spend is not malicious or even deliberate, it is a default that nobody revisited: a frontier model used for a classification task a small one would do, a system prompt carrying twelve thousand tokens of context on every call, a nightly job that reprocesses the same documents. None of that survives contact with a team lead who can see it.",[10,117,118,121],{},[47,119,120],{},"Optimize"," comes second, and it has more levers than the discourse suggests. Model selection is the obvious one, and the largest: the price spread between the cheapest usable model and the most capable one is not a few percent, it is a multiple, and a great deal of production traffic is running on a model chosen once during a prototype and never reconsidered. Context size is the second, and it is where the real waste hides, because prompt tokens are billed on every single call and a bloated system prompt multiplies its own cost by the request count. Caching is the third, and it is close to free money for repeated prefixes. Batching is the fourth where latency permits. None of these are visible without the first phase, which is why the order matters.",[10,123,124,127],{},[47,125,126],{},"Operate"," comes last: budgets that reset on a schedule, alerts that fire before the limit rather than after it, rate limits that contain a runaway process, and an allowlist of models per population. This is the phase people want to start with, because it feels like control. Starting here produces a system that blocks work nobody understood the shape of, generates escalations, and gets switched off within a quarter.",[20,129,131],{"id":130},"the-token-is-not-a-business-unit","The token is not a business unit",[10,133,134],{},"The most important thing FinOps brings to this problem is not the tooling, it is the insistence on a unit. Cloud FinOps matured the day teams stopped reporting a monthly total and started reporting cost per transaction, per customer, per gigabyte served. The total tells you nothing: it goes up when the business grows, which is good, and it goes up when the system degrades, which is bad, and the number looks identical in both cases. Only a unit cost separates the two.",[10,136,137],{},"AI spend needs the same treatment, and the token is emphatically not that unit. The token is the vendor's meter, not the company's measure of anything. It has no relationship to any outcome the business recognizes. A million tokens spent resolving support tickets and a million tokens spent generating unread drafts appear identically on the invoice.",[10,139,140],{},"Useful units are the ones the business already counts. Cost per employee per month is the crudest one and still worth having, because it makes the population visible. Cost per resolved ticket is better, and it is available to any support organization that already tracks resolutions. Cost per merged pull request is the developer equivalent and it is more honest than counting agent hours. Cost per generated document, per processed invoice, per onboarded customer: the pattern is to divide the spend by whatever the department already puts in its own reporting. The moment a team can say \"this workflow costs eleven cents per resolved ticket\", every subsequent conversation becomes an ordinary business conversation. Is that too much, compared to what. Would a cheaper model raise it or lower it, once you count the reopened tickets. That is a discussion an operations manager can have. \"We spent four hundred thousand tokens\" is not.",[10,142,143],{},"A note on that currency, because it is a deliberate choice rather than an oversight. The model vendors are American, their price tables are denominated in dollars, and the invoice arrives in dollars regardless of where the company is incorporated. The dollar is therefore the native unit of this cost, and every unit figure in this series stays in it. Converting to a local currency for internal reporting looks like a courtesy to the finance team and is in fact a measurement error, because it folds a second variable into a number whose entire purpose is to isolate the first. A cost per resolved ticket expressed locally moves when consumption moves, which is the signal, and it also moves when the exchange rate moves, which is noise from the perspective of the team being asked to explain it. Two months with identical usage produce two different numbers, and nobody in the review meeting can tell which part of the variation they are supposed to act on.",[10,145,146],{},"This does not make the exchange rate irrelevant, it puts it in a different line of the analysis. For a company in the CFA zone the exposure is real and slightly counterintuitive: the franc is pegged to the euro at a fixed parity, so the local cost of a dollar denominated AI bill does not track any West African variable at all, it tracks the euro against the dollar. Consumption is governed by the gateway, currency exposure is governed by treasury, and collapsing the two into a single reported figure means neither one gets managed. Keep the unit cost in dollars where the meter is, convert once at the top for the consolidated accounts, and let the treasury conversation happen on its own terms. The third article in this series returns to the payment side of this, which in the UEMOA context is not only a question of rates but of card ceilings and settlement friction.",[10,148,149],{},"This is also where the third unknown, value, stops being unanswerable. Nobody is going to produce a defensible company wide ROI figure for artificial intelligence, and the attempts are mostly marketing. But a single workflow with a known unit cost and a known outcome count is measurable, and enough of those add up to something real.",[20,151,153],{"id":152},"agents-break-the-per-seat-budget","Agents break the per seat budget",[10,155,156],{},"There is one more reason the fixed per employee allocation fails, and it is recent enough that many finance teams have not encountered it yet.",[10,158,159],{},"Conversational use is roughly predictable. A person reads, thinks, types, waits for an answer, reads it. Human reading speed puts a natural ceiling on consumption, and across a population it averages out into something you can plan around. The per seat model works acceptably for this population, which is why the vendors' seat based enterprise plans exist and are reasonable value.",[10,161,162],{},"Agentic use has no such ceiling. When a developer runs a coding agent over a repository, a single instruction expands into a long chain of calls: the agent reads files, reasons, calls a tool, receives output, reasons again, and each step resends an accumulating context. One human sentence can produce hundreds of model calls and replay the same context dozens of times. The consumption is bounded by the task and the loop, not by human attention. The same is true of any autonomous pipeline: document processing chains, evaluation harnesses, anything with retries.",[10,164,165],{},"The practical consequence is that a uniform allocation is not conservative, it is broken in both directions at once. Set it at a level that suits the sales team and the engineering team hits it on day three, so they route around it and you have lost the visibility you built the system for. Set it at a level that suits engineering and you have handed the entire company a budget it will never use, which is not a control at all. Budgets have to be per role, sized from observed consumption, which is another reason the Inform phase is not optional. You cannot size a limit for a population you have never measured.",[20,167,169],{"id":168},"governing-by-giving","Governing by giving",[10,171,172],{},"Here is the turn. Every control discussed so far fails for the same reason: there is no point of passage. The charter has no observer, the budget has no meter, the security team has no gate. Everything becomes possible the moment all AI traffic goes through one place the company operates, and nothing is possible until then.",[10,174,175],{},"That place is a gateway: a service that speaks the same API the providers speak, sits between the company's people and tools and the model vendors, holds the real provider credentials, and issues its own keys to internal consumers. Every call passes through it, which means every call can be attributed, limited, logged, filtered and priced. It is the proxy of the web filtering era, applied to inference.",[10,177,178],{},"The strategic point is not the architecture, it is the deal it lets you offer. A gateway can be deployed as an instrument of restriction, and if it is, it will be treated as one and worked around. It should be deployed as an instrument of access. The employee currently paying for a personal subscription out of their own pocket, or worse, using a free tier whose terms permit training on their input, gets something concrete in exchange for coming inside: a single key that reaches every model from every vendor, no personal card, no expense report, access to the expensive models the company has decided to pay for, and no ambiguity about whether they are allowed to use this for work. That is a better deal than the one they have. They take it, and they take it voluntarily.",[10,180,181],{},"The company gets, as a byproduct of that adoption, the attribution layer it could not obtain by writing a document. This is what \"govern by giving\" means concretely: the control is not paid for by the employee in friction, it is paid for by the company in provisioning, and the compliance falls out of the incentive rather than out of the rule. The second article in this series builds this gateway with LiteLLM, and shows what the budget, tagging and limit primitives actually look like in configuration.",[20,183,185],{"id":184},"what-a-gateway-will-never-see","What a gateway will never see",[10,187,188],{},"An honest account has to state the boundary, because a gateway solves less of this problem than its proponents imply.",[10,190,191],{},"A gateway sees API traffic. It does not see an employee opening a vendor's consumer web application in a browser tab and pasting a contract into it on a personal account. That is a large fraction of real world usage, quite possibly the majority in a non technical department, and no amount of gateway configuration reaches it. Closing that path is a different project: enterprise agreements with the vendors so there is a sanctioned web interface tied to corporate identity, single sign on so accounts are company accounts, network policy or endpoint controls for the consumer endpoints, and an offer good enough that the sanctioned path is the convenient one. The gateway is necessary and it is not sufficient.",[10,193,194],{},"It also does not see AI embedded inside other software. The assistant inside the document suite, the summarizer in the ticketing tool, the copilot in the CRM, the meeting notetaker: these send company data to models through their vendor's own infrastructure, on terms set in a SaaS contract nobody read with this in mind. That spend is invisible to the gateway by construction, and it is governed, if at all, through procurement and vendor review rather than through infrastructure. Browser extensions are the same category with worse terms.",[10,196,197],{},"None of this argues against the gateway. It argues against declaring victory when it is deployed. The realistic claim is that a gateway gives you full control of the traffic your engineering and your automated systems generate, a strong sanctioned path for everyone else, and an inventory that is far better than nothing. The claim it cannot support is total coverage.",[20,199,201],{"id":200},"an-operating-model-that-survives-contact","An operating model that survives contact",[10,203,204],{},"Assume the gateway exists. The design decisions that determine whether the system is still running in six months are organizational, not technical, and they are worth stating in advance.",[10,206,207],{},"Make the team the accounting unit and the person the identity unit. Budgets belong to teams, because teams have a manager who owns a cost center and can arbitrate. Keys belong to individuals, because attribution to a shared key is not attribution. This mirrors how cloud accounts and IAM identities already work, and it means the escalation path for \"we need more\" is the one the company already uses for every other resource.",[10,209,210],{},"Separate the soft limit from the hard limit, and put real distance between them. The soft limit exists to start a conversation before anything breaks, so it fires to the team lead, not to the user. The hard limit exists to make the catastrophic case impossible: the misconfigured loop, the agent that retries forever, the credential that leaked. Do not set the hard limit at a level where ordinary good work reaches it, because a limit that regularly blocks legitimate work teaches people to route around the system, and once they route around it you have lost the data, which was the point.",[10,212,213],{},"Bound the day as well as the month. A monthly ceiling alone permits the entire month to be consumed on a Tuesday morning by one runaway process, which is the exact failure the ceiling was supposed to prevent. A daily bound stacked underneath the monthly one contains the blast radius without constraining normal usage, and this is a primitive the gateway can provide directly.",[10,215,216],{},"Tier the models. Route the default traffic to a cheap, fast model that handles the large majority of requests acceptably, and make the expensive frontier models available to the roles and workflows that demonstrably need them. Do not make this a request form. Make it a group membership that a manager can grant, otherwise the friction reappears exactly where you removed it.",[10,218,219],{},"Publish an exception path and honor it quickly. Every control system in a company is judged by what happens when someone legitimately needs to exceed it. If the answer is a ticket that takes a week, the control has taught the organization to bypass it. If the answer is a manager approval that takes an hour, the control survives.",[20,221,223],{"id":222},"where-to-start","Where to start",[10,225,226],{},"The sequencing matters more than any individual decision, and it is the inverse of the intuition.",[10,228,229],{},"For the first month, measure and block nothing. Stand up the gateway, provision keys generously, set limits high enough that nobody encounters them, and let the traffic arrive. Resist every request to enforce something during this period. The output of the month is a picture of actual consumption by team, by model and by use case, which is the thing the company has never had, and which every subsequent decision depends on.",[10,231,232],{},"For the second month, publish showback and do not attach consequences to it. Each team lead receives their number and their breakdown. Expect the first round of optimization to happen without any instruction, because a visible number changes behavior on its own, and expect to find at least one workflow whose cost is absurd relative to what it produces.",[10,234,235],{},"For the third month, set the budgets, and set them from what you measured rather than from what you guessed. Now the per role sizing has evidence behind it, the soft limits sit above real usage, and the hard limits are set where a genuine anomaly lives. This is also when chargeback becomes possible, if the company wants it, and when the first unit costs can be published for the workflows that have a countable outcome.",[10,237,238],{},"The whole sequence is inform, then optimize, then operate, and the reason to insist on it is that the failure mode of starting at the end is not merely inefficiency. It is that the system gets bypassed in week two and never recovers the trust it needs to be useful.",[20,240,242],{"id":241},"limits-and-open-questions","Limits and open questions",[10,244,245],{},"Everything above rests on one assumption worth making explicit: that measured cost is a reasonable proxy for the thing the company actually cares about. It is a proxy, not the thing. A gateway's cost figures are computed from a price table maintained in software, and they will drift from the provider's invoice for ordinary reasons: cached prefixes billed at a discount, batch tiers, negotiated enterprise rates, changes the vendor makes on a Tuesday. Reconciliation against the real invoice is an operational task that has to be owned by someone, and any organization treating gateway numbers as accounting truth without that reconciliation is going to be surprised.",[10,247,248],{},"The value question remains genuinely open. Unit costs per workflow are a real advance over token totals, but a unit cost is only half of a return, and the other half requires measuring what the output was worth, which for most knowledge work is not measurable at the resolution anyone would like. Claims of company wide AI ROI should be read with that in mind, including the ones that are flattering.",[10,250,251],{},"And there is a question this article has deliberately not resolved: whether routing every prompt through a single company operated chokepoint, which by construction sees every question every employee asks, is a governance improvement or a new concentration of risk. It is both. The gateway becomes an extremely attractive target, its logs are a surveillance capability whether or not anyone intends to use them that way, and the decision about whether to log prompt content or only metadata is a genuine one with no default safe answer. The third article in this series takes that question up under a specific legal regime, where the answer stops being a matter of preference.",[20,253,255],{"id":254},"sources","Sources",[257,258,259,275,286,298],"ul",{},[260,261,262,263,267,268],"li",{},"FinOps Foundation, ",[264,265,266],"em",{},"FinOps Framework",": domains, capabilities and the inform, optimize and operate lifecycle. ",[269,270,274],"a",{"href":271,"rel":272},"https:\u002F\u002Fwww.finops.org\u002Fframework\u002F",[273],"nofollow","finops.org\u002Fframework",[260,276,262,277,280,281],{},[264,278,279],{},"FinOps for AI"," and the extension of framework scopes beyond public cloud to SaaS and AI workloads. ",[269,282,285],{"href":283,"rel":284},"https:\u002F\u002Fwww.finops.org\u002Fintroduction\u002Fwhat-is-finops\u002F",[273],"finops.org\u002Fintroduction\u002Fwhat-is-finops",[260,287,288,289,292,293],{},"LiteLLM documentation, ",[264,290,291],{},"Proxy: cost tracking, budgets and rate limits",", for the gateway primitives referenced here and detailed in the next article. ",[269,294,297],{"href":295,"rel":296},"https:\u002F\u002Fdocs.litellm.ai\u002Fdocs\u002Fproxy\u002Fcost_tracking",[273],"docs.litellm.ai",[260,299,300],{},"Provider pricing documentation from OpenAI, Anthropic and Google for the per token billing model and the price spread between model tiers.",{"title":302,"searchDepth":303,"depth":303,"links":304},"",2,[305,306,307,308,309,310,311,312,313,314,315,316,317],{"id":22,"depth":303,"text":23},{"id":38,"depth":303,"text":39},{"id":73,"depth":303,"text":74},{"id":89,"depth":303,"text":90},{"id":105,"depth":303,"text":106},{"id":130,"depth":303,"text":131},{"id":152,"depth":303,"text":153},{"id":168,"depth":303,"text":169},{"id":184,"depth":303,"text":185},{"id":200,"depth":303,"text":201},{"id":222,"depth":303,"text":223},{"id":241,"depth":303,"text":242},{"id":254,"depth":303,"text":255},"2026-08-29","Every company now has employees using OpenAI, Anthropic and Gemini every day, and almost none of them can say who asked what, what data left the building, or what any of it returned. This article argues that AI governance by policy fails for the same reason shadow IT policies failed, that the request for a fixed AI budget is the wrong question, and that FinOps is the practical way in: the only one of the three unknowns you can measure today is cost, and measuring it is what buys you the other two.",false,"md","https:\u002F\u002Fres.cloudinary.com\u002Fdpdwhd6ka\u002Fimage\u002Fupload\u002Ff_auto,q_auto\u002Fv1\u002FBlog\u002Fimages\u002Fhbcudyxllyjvbkjxvs7g",{},true,"\u002Fai\u002Fai-spend-nobody-tracks",{"title":5,"description":319},"ai-governance-finops-shadow-ai","ai\u002F1.ai-spend-nobody-tracks",[330,331,332,333,334],"FinOps","AI-Governance","Shadow-AI","LLM","Cost-Attribution",[336,337,338],"ai","finops","security","wKw66JKsBve_tgmng2djhCldTdFL3bEuntbF5hZPMho",{"id":341,"title":342,"body":343,"date":318,"description":645,"draft":320,"extension":321,"img":322,"meta":646,"navigation":324,"path":647,"seo":648,"slug":327,"stem":649,"tags":650,"topics":651,"__hash__":652},"content\u002Fai\u002F1.ai-spend-nobody-tracks.fr.md","Personne ne sait ce que votre entreprise dépense en IA",{"type":7,"value":344,"toc":630},[345,348,351,354,358,361,364,371,374,378,381,388,395,402,405,408,412,419,422,425,432,436,439,442,445,448,452,455,461,467,473,477,480,483,486,489,492,495,499,502,505,508,511,515,518,521,524,527,531,534,537,540,543,547,550,553,556,559,562,565,569,572,575,578,581,584,588,591,594,597,599],[10,346,347],{},"Il est dix-huit heures et la journée de travail est finie. Quelque part dans l'entreprise, un agent du support a collé trois emails clients dans une fenêtre de chat pour se faire aider à rédiger une réponse. Un juriste a téléversé un projet de contrat pour en résumer les clauses à risque. Un développeur a fait tourner un agent pendant quatre heures sur un dépôt privé. Une responsable marketing a généré quarante descriptions produit. Un stagiaire, à qui on avait demandé d'être débrouillard, a mis un export du CRM dans un prompt pour y chercher des tendances. Certains ont utilisé un compte d'entreprise. La plupart ont utilisé un compte personnel, parce que c'était plus rapide et que personne n'avait dit le contraire.",[10,349,350],{},"Posez maintenant les questions que tout conseil d'administration finira par poser. Combien l'entreprise a-t-elle dépensé en intelligence artificielle aujourd'hui ? Quels départements l'ont dépensé ? Des données réglementées sont-elles sorties, et sous les conditions contractuelles de quel fournisseur ? Est-ce que tout cela a produit quelque chose qui valait son prix ? Dans l'immense majorité des organisations, la réponse honnête aux quatre questions est la même : on ne sait pas, et aucun mécanisme en place ne permettrait de le savoir.",[10,352,353],{},"Ce n'est pas un manque de discipline, et les personnes de cette histoire ne font rien de déraisonnable. C'est un trou structurel. Les outils sont arrivés plus vite que les contrôles, ils sont consommés par un canal que personne n'a instrumenté, et ils sont facturés dans une unité pour laquelle aucun processus financier n'a été conçu. Le réflexe, dans la plupart des entreprises, est de combler ce trou avec une politique : publier une charte IA, lister les outils autorisés, interdire le reste. Ce réflexe est mauvais, et cet article explique pourquoi, puis ce qui fonctionne à la place.",[20,355,357],{"id":356},"le-shadow-it-laissait-au-moins-une-facture","Le shadow IT laissait au moins une facture",[10,359,360],{},"Nous avons déjà vu cette forme. À l'époque du SaaS, des équipes achetaient des outils dont la DSI n'avait jamais entendu parler, et le secteur a appelé ça le shadow IT. La comparaison est utile mais elle flatte la situation actuelle, car le shadow AI est pire sur trois points précis.",[10,362,363],{},"Le shadow IT laissait des traces. Quelqu'un avait un abonnement, sur une carte d'entreprise, renouvelé chaque mois, avec une facture qui arrivait dans une boîte mail. La finance pouvait le retrouver. Il y avait un compte avec un administrateur, un domaine, une page de connexion, un contrat dont quelqu'un pouvait finir par lire les conditions. La piste était mince mais elle existait, et suffisamment d'entreprises ont fini par construire des outils de découverte SaaS sur cette piste exacte. Un prompt ne laisse rien. C'est une requête, une réponse, et un compteur de tokens sur une facture qui appartient à la carte bancaire personnelle du collaborateur. Quand il quitte l'entreprise, la piste part avec lui.",[10,365,366,367,370],{},"Le shadow IT déplaçait des données de manière délibérée. Téléverser un fichier clients dans un CRM non validé était un acte intentionnel, et assez rare pour constituer un incident. Dans le cas de l'IA, déplacer les données ",[264,368,369],{},"est"," l'interaction. Il n'existe aucun moyen de demander à un modèle de l'aide sur un contrat sans lui envoyer le contrat. L'exfiltration n'est pas le détournement de l'outil, c'est son usage normal, correct et quotidien. Tout modèle de contrôle bâti sur l'hypothèse que le mouvement de données est exceptionnel sera faux dès le premier jour.",[10,372,373],{},"Le shadow IT avait un prix fixe. C'est la différence qui casse le côté financier. Une licence SaaS, c'est un montant connu par utilisateur et par mois, prévisible un an à l'avance, dont le pire cas égale le meilleur cas. L'inférence est facturée au token, ce qui signifie que la consommation est non bornée par construction et que le même effectif peut produire une facture qui varie d'un ordre de grandeur entre deux mois consécutifs. Il n'y a pas de nombre de sièges à multiplier. C'est cette observation qui mène la plupart des dirigeants à la question de la section suivante, et elle mérite d'être prise au sérieux plutôt que balayée.",[20,375,377],{"id":376},"les-trois-inconnues","Les trois inconnues",[10,379,380],{},"Réduisez le problème à l'os : il y a exactement trois choses qu'une entreprise ne sait pas répondre aujourd'hui sur son propre usage de l'IA.",[10,382,383,384,387],{},"La première est ",[47,385,386],{},"l'attribution"," : qui a dépensé quoi, sur quel modèle, pour quelle équipe, sur quel projet. C'est une question comptable. Sa forme est bien comprise, elle se projette sur des structures que l'entreprise possède déjà, et elle est entièrement traitable avec la bonne plomberie.",[10,389,390,391,394],{},"La deuxième est ",[47,392,393],{},"l'exposition"," : quelles données sont sorties de l'organisation, vers quel sous-traitant, sous quelles conditions de rétention et d'entraînement, et si une partie relève d'un régime qui impose une déclaration. C'est une question juridique et sécurité. Elle est plus difficile, parce qu'y répondre pleinement suppose d'inspecter le contenu, et qu'inspecter le contenu crée ses propres problèmes.",[10,396,397,398,401],{},"La troisième est ",[47,399,400],{},"la valeur"," : ce qui est revenu. Les quatre heures d'agent ont-elles économisé une journée de travail ou produit une branche que personne n'a fusionnée ? Les quarante descriptions produit ont-elles converti ? C'est la question qui intéresse réellement tout le monde et celle à laquelle personne dans le secteur ne sait répondre avec rigueur aujourd'hui, y compris les fournisseurs qui vendent la réponse.",[10,403,404],{},"Ces trois inconnues ne sont pas indépendantes, et leur relation constitue la thèse de cet article. L'attribution est la seule qui soit peu coûteuse à mesurer. C'est aussi celle qui, une fois obtenue, fait matériellement avancer les deux autres. Un système qui sait quelle clé a fait quel appel, vers quel modèle, avec quel volume, se trouve à un changement de configuration de savoir aussi quels appels transportaient une charge utile masquée et quelle équipe les produit. On n'obtient pas le contrôle de l'exposition et la mesure de la valeur en les exigeant directement. On les obtient comme sous-produit de la construction de la couche comptable, parce que cette couche est le point de passage dont les trois questions ont besoin.",[10,406,407],{},"Voilà toute la stratégie en une phrase. Suivre l'argent, parce que l'argent est le seul fil qu'on puisse tirer et qui ramène le reste avec lui.",[20,409,411],{"id":410},"pourquoi-la-charte-ia-ne-fonctionne-pas","Pourquoi la charte IA ne fonctionne pas",[10,413,414,415,418],{},"La réponse standard au shadow AI est un document. Il nomme les outils autorisés, interdit les autres, demande aux collaborateurs de ne pas coller d'informations confidentielles dans des modèles publics, et leur fait accuser réception. Une version de ce document existe désormais dans la plupart des grandes organisations. Presque aucune n'est appliquée, parce qu'aucune ne ",[264,416,417],{},"peut"," l'être.",[10,420,421],{},"Une règle n'est réelle que dans la mesure où un mécanisme l'observe. Une politique qui dit « n'envoyez pas de données clients à des modèles non autorisés » n'a pas d'observateur. Rien dans la pile réseau, sur le poste de travail ou dans le fournisseur d'identité ne surveille cela par défaut. Il n'existe aucun point de passage où la règle pourrait s'appliquer. La règle n'est donc pas un contrôle, c'est une préférence signée, et sa fonction principale est de déplacer la responsabilité de l'entreprise vers le collaborateur. Cela vaut peut-être quelque chose pour une direction juridique. Cela ne vaut rien pour la personne qui doit répondre aux quatre questions du conseil.",[10,423,424],{},"La sécurité a appris cette leçon il y a vingt ans avec le filtrage web, puis à nouveau avec la prévention des fuites de données. Personne n'écrit une politique disant « ne visitez pas de sites malveillants » en considérant le problème réglé. On met un proxy sur le chemin, parce que c'est le proxy qui transforme la phrase en résultat. La même logique s'applique ici, ce n'est pas une idée neuve, mais elle a pour l'IA une conséquence facile à manquer, et le reste de cet article repose dessus.",[10,426,427,428,431],{},"Il y a une seconde raison, plus tranchante, à l'échec de la charte. Le comportement interdit est aussi le comportement productif. Le filtrage web fonctionne en partie parce que le collaborateur ne gagne rien au site bloqué. Ici, celui qui ignore la politique travaille mieux et plus vite que celui qui la respecte. Un contrôle qui rend les employés conformes moins efficaces que les non conformes perdra, à chaque fois, quel que soit le niveau hiérarchique de celui qui l'a signé. Tout modèle viable doit être un modèle où le chemin autorisé est le chemin ",[264,429,430],{},"facile",", pas le chemin vertueux.",[20,433,435],{"id":434},"le-budget-fixe-est-la-mauvaise-question","Le budget fixe est la mauvaise question",[10,437,438],{},"Quand la charte échoue, le mouvement suivant est généralement financier : donner à la dépense IA une ligne dans le budget. Allouer un montant fixe par collaborateur et par an, le valider une fois, et le traiter comme n'importe quel centre de coût. Et l'objection arrive immédiatement, et elle est réelle : ces services sont facturés au token, donc le montant consommé ne peut pas être connu à l'avance, donc un budget fixe ne peut pas être engagé à l'avance. Le directeur financier a raison sur la mécanique, et s'arrête là.",[10,440,441],{},"Mais regardez ce que dit vraiment l'objection. Elle dit : ce coût est variable, piloté par la consommation, non borné en principe, attribuable seulement a posteriori, et généré par des décisions décentralisées prises par des gens qui ne voient pas le prix de ce qu'ils font. Ce n'est pas une nouvelle catégorie de problème. C'est la description du cloud public, version 2010, presque mot pour mot.",[10,443,444],{},"Aucune entreprise n'a de facture AWS fixe non plus. Ce qu'elle a, si elle est mature sur le sujet, vaut mieux qu'une facture fixe : une attribution par équipe, un coût unitaire suivi dans le temps, une prévision avec une marge d'erreur connue, des budgets avec des alertes, et des garde-fous qui rendent les cas pathologiques impossibles plutôt que simplement déconseillés. Personne ne demande un forfait à son fournisseur cloud. On construit la pratique qui rend un coût variable gouvernable. Cette pratique a un nom, un corpus derrière elle, et une fondation qui en maintient le référentiel. L'appliquer aux charges IA n'est pas une analogie forcée pour les besoins d'un article. C'est le même problème avec un autre compteur.",[10,446,447],{},"La question à porter au directeur financier n'est donc pas « combien allons-nous dépenser en IA l'an prochain ». C'est « quelle est notre unité de consommation, qui en est propriétaire, et quel est le maximum que nous puissions perdre en une journée ». Ces trois questions ont des réponses.",[20,449,451],{"id":450},"ce-que-le-finops-apporte-réellement-ici","Ce que le FinOps apporte réellement ici",[10,453,454],{},"Le cycle FinOps est habituellement décrit en trois phases, et chacune se projette assez proprement sur le problème IA pour mériter d'être parcourue. La Fondation a depuis élargi le référentiel en domaines et étendu son périmètre au-delà du cloud public pour couvrir le SaaS et les charges IA, mais le découpage en trois phases reste la manière la plus claire de séquencer le travail.",[10,456,457,460],{},[47,458,459],{},"Informer"," vient en premier et c'est la phase que la plupart des entreprises sautent. Avant tout budget, toute limite, toute politique, il faut de la visibilité : un showback qui dit à chaque équipe ce qu'elle a consommé le mois dernier, ventilé par modèle et par cas d'usage. Le showback n'est pas la refacturation. Rien n'est encore facturé en interne, rien n'est bloqué, la seule sortie est un chiffre envoyé à un responsable d'équipe qui n'en avait jamais vu. L'effet de ce chiffre est systématiquement sous-estimé. Une large part de la dépense IA inutile n'est ni malveillante ni même délibérée, c'est un réglage par défaut que personne n'a revisité : un modèle frontier utilisé pour une tâche de classification qu'un petit modèle traiterait, un prompt système qui transporte douze mille tokens de contexte à chaque appel, un batch nocturne qui retraite les mêmes documents. Rien de tout cela ne survit au contact d'un responsable qui le voit.",[10,462,463,466],{},[47,464,465],{},"Optimiser"," vient ensuite, et cette phase a plus de leviers que le discours ambiant ne le suggère. Le choix du modèle est le plus évident, et le plus lourd : l'écart de prix entre le modèle le moins cher qui fait le travail et le plus capable ne se compte pas en pourcents mais en multiples, et une grande partie du trafic de production tourne sur un modèle choisi une fois pendant un prototype et jamais réévalué. La taille du contexte est le deuxième levier, et c'est là que se cache le vrai gaspillage, car les tokens d'entrée sont facturés à chaque appel et un prompt système obèse multiplie son propre coût par le nombre de requêtes. Le cache est le troisième, et il s'apparente à de l'argent gratuit sur les préfixes répétés. Le batch est le quatrième là où la latence le permet. Aucun de ces leviers n'est visible sans la première phase, ce qui explique pourquoi l'ordre compte.",[10,468,469,472],{},[47,470,471],{},"Opérer"," vient en dernier : des budgets qui se réinitialisent selon un cycle, des alertes qui se déclenchent avant la limite plutôt qu'après, des limites de débit qui contiennent un processus fou, et une liste blanche de modèles par population. C'est la phase par laquelle les gens veulent commencer, parce qu'elle ressemble à du contrôle. Commencer par là produit un système qui bloque un travail dont personne n'avait compris la forme, génère des escalades, et se fait désactiver en un trimestre.",[20,474,476],{"id":475},"le-token-nest-pas-une-unité-métier","Le token n'est pas une unité métier",[10,478,479],{},"Ce que le FinOps apporte de plus important à ce problème n'est pas l'outillage, c'est l'exigence d'une unité. Le FinOps cloud a mûri le jour où les équipes ont cessé de reporter un total mensuel pour reporter un coût par transaction, par client, par gigaoctet servi. Le total ne dit rien : il monte quand l'activité croît, ce qui est bon, et il monte quand le système se dégrade, ce qui est mauvais, et le chiffre est identique dans les deux cas. Seul un coût unitaire sépare les deux situations.",[10,481,482],{},"La dépense IA appelle le même traitement, et le token n'est catégoriquement pas cette unité. Le token est le compteur du fournisseur, pas la mesure de quoi que ce soit du côté de l'entreprise. Il n'a aucune relation avec un résultat que le métier reconnaît. Un million de tokens dépensés à résoudre des tickets de support et un million de tokens dépensés à générer des brouillons que personne ne lit apparaissent à l'identique sur la facture.",[10,484,485],{},"Les unités utiles sont celles que le métier compte déjà. Le coût par collaborateur et par mois est la plus grossière et vaut quand même d'être suivie, parce qu'elle rend la population visible. Le coût par ticket résolu est meilleur, et il est accessible à toute organisation support qui compte déjà ses résolutions. Le coût par pull request fusionnée est l'équivalent côté développement et il est plus honnête que de compter des heures d'agent. Coût par document généré, par facture traitée, par client intégré : le principe est de diviser la dépense par ce que le département met déjà dans son propre reporting. Dès qu'une équipe peut dire « ce workflow coûte onze cents par ticket résolu », toute conversation ultérieure devient une conversation de gestion ordinaire. Est-ce trop, comparé à quoi ? Un modèle moins cher ferait-il monter ou descendre ce chiffre, une fois comptées les réouvertures ? C'est une discussion qu'un responsable d'exploitation sait tenir. « Nous avons consommé quatre cent mille tokens » ne l'est pas.",[10,487,488],{},"Un mot sur cette devise, car c'est un choix délibéré et non un oubli. Les éditeurs de modèles sont américains, leurs grilles tarifaires sont libellées en dollars, et la facture arrive en dollars quel que soit le pays d'immatriculation de l'entreprise. Le dollar est donc l'unité native de ce coût, et tous les coûts unitaires de cette série y restent. Convertir en monnaie locale pour le reporting interne ressemble à une politesse faite à la direction financière et constitue en réalité une erreur de mesure, parce que cela injecte une seconde variable dans un chiffre dont toute la raison d'être est d'isoler la première. Un coût par ticket résolu exprimé en monnaie locale bouge quand la consommation bouge, ce qui est le signal, et il bouge aussi quand le taux de change bouge, ce qui est du bruit du point de vue de l'équipe à qui l'on demande de s'expliquer. Deux mois d'usage identique produisent deux chiffres différents, et personne dans la réunion de revue ne sait sur quelle part de l'écart il est censé agir.",[10,490,491],{},"Cela ne rend pas le taux de change indifférent, cela le range dans une autre ligne de l'analyse. Pour une entreprise de la zone franc, l'exposition est réelle et légèrement contre-intuitive : le franc CFA est arrimé à l'euro à parité fixe, donc le coût local d'une facture IA libellée en dollars ne suit aucune variable ouest-africaine, il suit l'euro face au dollar. La consommation se gouverne par la passerelle, l'exposition de change se gouverne par la trésorerie, et fondre les deux dans un chiffre unique revient à ne piloter ni l'une ni l'autre. Gardez le coût unitaire en dollars, là où se trouve le compteur, convertissez une seule fois en haut pour les comptes consolidés, et laissez la discussion de trésorerie se tenir sur son propre terrain. Le troisième article de cette série revient sur le volet paiement, qui dans le contexte UEMOA n'est pas seulement une question de taux mais de plafonds de carte et de friction de règlement.",[10,493,494],{},"C'est aussi là que la troisième inconnue, la valeur, cesse d'être insoluble. Personne ne produira un chiffre de ROI défendable pour l'intelligence artificielle à l'échelle d'une entreprise, et les tentatives relèvent surtout du marketing. Mais un workflow unique, avec un coût unitaire connu et un nombre de résultats connu, est mesurable, et un nombre suffisant de ces workflows finit par constituer quelque chose de réel.",[20,496,498],{"id":497},"les-agents-cassent-le-budget-par-siège","Les agents cassent le budget par siège",[10,500,501],{},"Il y a une dernière raison pour laquelle l'allocation fixe par collaborateur échoue, et elle est assez récente pour que beaucoup d'équipes financières ne l'aient pas encore rencontrée.",[10,503,504],{},"L'usage conversationnel est à peu près prévisible. Une personne lit, réfléchit, tape, attend une réponse, la lit. La vitesse de lecture humaine impose un plafond naturel à la consommation, et sur une population cela se moyenne en quelque chose de planifiable. Le modèle par siège fonctionne correctement pour cette population, ce qui explique que les offres entreprise par siège des fournisseurs existent et soient d'un bon rapport.",[10,506,507],{},"L'usage agentique n'a pas ce plafond. Quand un développeur lance un agent de code sur un dépôt, une seule instruction se déploie en une longue chaîne d'appels : l'agent lit des fichiers, raisonne, appelle un outil, reçoit une sortie, raisonne encore, et chaque étape renvoie un contexte qui s'accumule. Une phrase humaine peut produire des centaines d'appels au modèle et rejouer le même contexte des dizaines de fois. La consommation est bornée par la tâche et par la boucle, pas par l'attention humaine. Il en va de même de tout pipeline autonome : chaînes de traitement documentaire, harnais d'évaluation, tout ce qui comporte des reprises sur erreur.",[10,509,510],{},"La conséquence pratique est qu'une allocation uniforme n'est pas prudente, elle est cassée dans les deux sens à la fois. Fixez-la au niveau qui convient à l'équipe commerciale et l'équipe technique l'atteint le troisième jour, la contourne, et vous avez perdu la visibilité pour laquelle vous aviez construit le système. Fixez-la au niveau qui convient à la technique et vous avez donné à toute l'entreprise un budget qu'elle n'utilisera jamais, ce qui n'est pas un contrôle du tout. Les budgets doivent être par rôle, dimensionnés à partir de la consommation observée, ce qui est une raison de plus pour laquelle la phase Informer n'est pas optionnelle. On ne dimensionne pas une limite pour une population qu'on n'a jamais mesurée.",[20,512,514],{"id":513},"gouverner-en-donnant","Gouverner en donnant",[10,516,517],{},"Voici le retournement. Tous les contrôles évoqués jusqu'ici échouent pour la même raison : il n'y a pas de point de passage. La charte n'a pas d'observateur, le budget n'a pas de compteur, l'équipe sécurité n'a pas de porte. Tout devient possible dès l'instant où l'ensemble du trafic IA transite par un endroit que l'entreprise opère, et rien n'est possible avant.",[10,519,520],{},"Cet endroit est une passerelle : un service qui parle la même API que les fournisseurs, se place entre les personnes et les outils de l'entreprise d'un côté et les éditeurs de modèles de l'autre, détient les véritables identifiants fournisseurs, et émet ses propres clés pour les consommateurs internes. Chaque appel y transite, ce qui signifie que chaque appel peut être attribué, plafonné, journalisé, filtré et valorisé. C'est le proxy de l'ère du filtrage web, appliqué à l'inférence.",[10,522,523],{},"Le point stratégique n'est pas l'architecture, c'est le marché qu'elle permet de proposer. Une passerelle peut être déployée comme un instrument de restriction, et si c'est le cas, elle sera perçue comme telle et contournée. Elle doit être déployée comme un instrument d'accès. Le collaborateur qui paie aujourd'hui un abonnement personnel de sa poche, ou pire, qui utilise une offre gratuite dont les conditions autorisent l'entraînement sur ses saisies, reçoit quelque chose de concret en échange de son passage à l'intérieur : une clé unique qui atteint tous les modèles de tous les fournisseurs, pas de carte personnelle, pas de note de frais, l'accès aux modèles chers que l'entreprise a décidé de payer, et aucune ambiguïté sur son droit à s'en servir pour son travail. C'est un meilleur marché que celui qu'il a. Il l'accepte, et il l'accepte volontairement.",[10,525,526],{},"L'entreprise obtient, comme sous-produit de cette adoption, la couche d'attribution qu'elle ne pouvait pas obtenir en rédigeant un document. Voilà ce que « gouverner en donnant » signifie concrètement : le contrôle n'est pas payé par le collaborateur en friction, il est payé par l'entreprise en fourniture de service, et la conformité découle de l'incitation plutôt que de la règle. Le deuxième article de cette série construit cette passerelle avec LiteLLM et montre à quoi ressemblent réellement, en configuration, les primitives de budget, de marquage et de plafonnement.",[20,528,530],{"id":529},"ce-quune-passerelle-ne-verra-jamais","Ce qu'une passerelle ne verra jamais",[10,532,533],{},"Un exposé honnête doit poser la limite, parce qu'une passerelle résout une part plus faible du problème que ne le laissent entendre ses promoteurs.",[10,535,536],{},"Une passerelle voit le trafic API. Elle ne voit pas un collaborateur qui ouvre l'application web grand public d'un fournisseur dans un onglet et y colle un contrat depuis un compte personnel. C'est une fraction importante de l'usage réel, très probablement majoritaire dans un département non technique, et aucune configuration de passerelle ne l'atteint. Fermer ce chemin est un autre chantier : accords entreprise avec les fournisseurs pour qu'il existe une interface web autorisée rattachée à l'identité d'entreprise, authentification unique pour que les comptes soient des comptes d'entreprise, politique réseau ou contrôle du poste pour les points d'accès grand public, et une offre suffisamment bonne pour que le chemin autorisé soit le chemin commode. La passerelle est nécessaire et elle n'est pas suffisante.",[10,538,539],{},"Elle ne voit pas non plus l'IA intégrée dans d'autres logiciels. L'assistant dans la suite bureautique, le résumeur dans l'outil de ticketing, le copilote dans le CRM, le preneur de notes de réunion : tous envoient des données d'entreprise vers des modèles via l'infrastructure de leur propre éditeur, sous des conditions fixées dans un contrat SaaS que personne n'a lu avec cette question en tête. Cette dépense est invisible à la passerelle par construction, et elle se gouverne, si tant est qu'elle se gouverne, par les achats et la revue fournisseur plutôt que par l'infrastructure. Les extensions de navigateur relèvent de la même catégorie, avec de moins bonnes conditions.",[10,541,542],{},"Rien de tout cela ne plaide contre la passerelle. Cela plaide contre le fait de crier victoire une fois qu'elle est déployée. L'affirmation réaliste est qu'une passerelle donne le contrôle complet du trafic généré par l'ingénierie et les systèmes automatisés, un chemin autorisé solide pour tous les autres, et un inventaire très supérieur à rien. Ce qu'elle ne peut pas soutenir, c'est une couverture totale.",[20,544,546],{"id":545},"un-modèle-opérationnel-qui-tient-au-contact","Un modèle opérationnel qui tient au contact",[10,548,549],{},"Supposons la passerelle en place. Les décisions de conception qui déterminent si le système tourne encore dans six mois sont organisationnelles, pas techniques, et elles méritent d'être posées à l'avance.",[10,551,552],{},"Faites de l'équipe l'unité comptable et de la personne l'unité d'identité. Les budgets appartiennent aux équipes, parce qu'une équipe a un responsable qui porte un centre de coût et sait arbitrer. Les clés appartiennent aux individus, parce qu'une attribution vers une clé partagée n'est pas une attribution. Cela reproduit le fonctionnement déjà en place pour les comptes cloud et les identités IAM, et cela signifie que le chemin d'escalade pour « il nous en faut plus » est celui que l'entreprise utilise déjà pour toute autre ressource.",[10,554,555],{},"Séparez la limite souple de la limite dure, et mettez une vraie distance entre les deux. La limite souple existe pour ouvrir une conversation avant que quoi que ce soit ne casse, elle se déclenche donc vers le responsable d'équipe, pas vers l'utilisateur. La limite dure existe pour rendre le cas catastrophique impossible : la boucle mal configurée, l'agent qui réessaie sans fin, l'identifiant qui a fuité. Ne placez pas la limite dure à un niveau que du bon travail ordinaire atteint, parce qu'une limite qui bloque régulièrement du travail légitime apprend aux gens à contourner le système, et une fois qu'ils le contournent vous avez perdu la donnée, qui était l'objectif.",[10,557,558],{},"Bornez la journée autant que le mois. Un plafond mensuel seul autorise la consommation du mois entier un mardi matin par un unique processus fou, ce qui est exactement la défaillance que le plafond devait empêcher. Une borne journalière empilée sous la borne mensuelle contient le rayon d'explosion sans contraindre l'usage normal, et c'est une primitive que la passerelle peut fournir directement.",[10,560,561],{},"Hiérarchisez les modèles. Routez le trafic par défaut vers un modèle rapide et économique qui traite correctement la grande majorité des demandes, et rendez les modèles frontier disponibles aux rôles et aux workflows qui en ont démontrablement besoin. N'en faites pas un formulaire de demande. Faites-en une appartenance à un groupe qu'un responsable peut accorder, sinon la friction réapparaît exactement là où vous l'aviez retirée.",[10,563,564],{},"Publiez une voie d'exception et honorez-la vite. Tout dispositif de contrôle dans une entreprise se juge à ce qui se passe quand quelqu'un a légitimement besoin de le dépasser. Si la réponse est un ticket qui prend une semaine, le contrôle a appris à l'organisation à le contourner. Si la réponse est une validation managériale qui prend une heure, le contrôle survit.",[20,566,568],{"id":567},"par-où-commencer","Par où commencer",[10,570,571],{},"Le séquencement compte plus que n'importe quelle décision prise isolément, et il est l'inverse de l'intuition.",[10,573,574],{},"Le premier mois, mesurez et ne bloquez rien. Déployez la passerelle, provisionnez les clés généreusement, réglez les limites assez haut pour que personne ne les rencontre, et laissez le trafic arriver. Résistez à toutes les demandes d'appliquer quoi que ce soit pendant cette période. La sortie du mois est une image de la consommation réelle par équipe, par modèle et par cas d'usage, c'est-à-dire la chose que l'entreprise n'a jamais eue, et dont toutes les décisions ultérieures dépendent.",[10,576,577],{},"Le deuxième mois, publiez le showback sans y attacher de conséquence. Chaque responsable d'équipe reçoit son chiffre et sa ventilation. Attendez-vous à ce que la première vague d'optimisation se produise sans aucune consigne, parce qu'un chiffre visible change le comportement à lui seul, et attendez-vous à découvrir au moins un workflow dont le coût est absurde au regard de ce qu'il produit.",[10,579,580],{},"Le troisième mois, posez les budgets, et posez-les à partir de ce que vous avez mesuré plutôt que de ce que vous aviez supposé. Le dimensionnement par rôle repose désormais sur des faits, les limites souples se situent au-dessus de l'usage réel, et les limites dures sont placées là où vit une véritable anomalie. C'est aussi le moment où la refacturation devient possible, si l'entreprise la souhaite, et où les premiers coûts unitaires peuvent être publiés pour les workflows dont le résultat est comptable.",[10,582,583],{},"L'ensemble de la séquence est informer, puis optimiser, puis opérer, et la raison d'y tenir est que la conséquence d'un démarrage par la fin n'est pas seulement une perte d'efficacité. C'est que le système est contourné dès la deuxième semaine et ne retrouve jamais la confiance dont il a besoin pour être utile.",[20,585,587],{"id":586},"limites-et-questions-ouvertes","Limites et questions ouvertes",[10,589,590],{},"Tout ce qui précède repose sur une hypothèse qu'il faut expliciter : que le coût mesuré est un indicateur raisonnable de ce qui intéresse vraiment l'entreprise. C'est un indicateur, pas la chose elle-même. Les chiffres de coût d'une passerelle sont calculés à partir d'une table de prix maintenue dans du logiciel, et ils divergeront de la facture du fournisseur pour des raisons ordinaires : préfixes en cache facturés avec remise, offres batch, tarifs entreprise négociés, changements que l'éditeur applique un mardi. La réconciliation avec la facture réelle est une tâche opérationnelle qui doit avoir un propriétaire, et toute organisation qui prend les chiffres de sa passerelle pour une vérité comptable sans cette réconciliation aura des surprises.",[10,592,593],{},"La question de la valeur reste réellement ouverte. Les coûts unitaires par workflow constituent un progrès net par rapport aux totaux de tokens, mais un coût unitaire n'est que la moitié d'un rendement, et l'autre moitié suppose de mesurer ce que la production valait, ce qui, pour la plupart des tâches de travail intellectuel, n'est pas mesurable à la résolution qu'on souhaiterait. Les affirmations de ROI IA à l'échelle d'une entreprise doivent être lues avec cela en tête, y compris les plus flatteuses.",[10,595,596],{},"Et il y a une question que cet article n'a délibérément pas tranchée : faire transiter chaque prompt par un point de passage unique opéré par l'entreprise, qui par construction voit chaque question posée par chaque collaborateur, est-ce un progrès de gouvernance ou une nouvelle concentration de risque ? C'est les deux. La passerelle devient une cible extrêmement attractive, ses journaux constituent une capacité de surveillance que quelqu'un ait ou non l'intention de s'en servir ainsi, et le choix de journaliser le contenu des prompts ou seulement les métadonnées est un vrai choix, sans réponse par défaut qui serait sûre. Le troisième article de cette série reprend cette question sous un régime juridique précis, où la réponse cesse d'être une affaire de préférence.",[20,598,255],{"id":254},[257,600,601,609,617,627],{},[260,602,262,603,605,606],{},[264,604,266],{}," : domaines, capacités et cycle informer, optimiser, opérer. ",[269,607,274],{"href":271,"rel":608},[273],[260,610,262,611,613,614],{},[264,612,279],{}," et l'extension du périmètre du référentiel au-delà du cloud public, vers le SaaS et les charges IA. ",[269,615,285],{"href":283,"rel":616},[273],[260,618,619,620,623,624],{},"Documentation LiteLLM, ",[264,621,622],{},"Proxy : suivi des coûts, budgets et limites de débit",", pour les primitives de passerelle évoquées ici et détaillées dans l'article suivant. ",[269,625,297],{"href":295,"rel":626},[273],[260,628,629],{},"Documentations tarifaires d'OpenAI, Anthropic et Google pour le modèle de facturation au token et l'écart de prix entre gammes de modèles.",{"title":302,"searchDepth":303,"depth":303,"links":631},[632,633,634,635,636,637,638,639,640,641,642,643,644],{"id":356,"depth":303,"text":357},{"id":376,"depth":303,"text":377},{"id":410,"depth":303,"text":411},{"id":434,"depth":303,"text":435},{"id":450,"depth":303,"text":451},{"id":475,"depth":303,"text":476},{"id":497,"depth":303,"text":498},{"id":513,"depth":303,"text":514},{"id":529,"depth":303,"text":530},{"id":545,"depth":303,"text":546},{"id":567,"depth":303,"text":568},{"id":586,"depth":303,"text":587},{"id":254,"depth":303,"text":255},"Dans toutes les entreprises, les collaborateurs utilisent désormais OpenAI, Anthropic et Gemini au quotidien, et presque aucune n'est capable de dire qui a demandé quoi, quelles données sont sorties, ni ce que tout cela a rapporté. Cet article défend l'idée que la gouvernance IA par la charte échoue pour les mêmes raisons que les politiques anti shadow IT, que la demande d'un budget IA fixe est la mauvaise question, et que le FinOps est la porte d'entrée pratique : des trois inconnues, seul le coût est mesurable aujourd'hui, et c'est en le mesurant qu'on obtient les deux autres.",{},"\u002Fai\u002Fai-spend-nobody-tracks.fr",{"title":342,"description":645},"ai\u002F1.ai-spend-nobody-tracks.fr",[330,331,332,333,334],[336,337,338],"YsO5boGkG_DMCvj1yXWrDMz_d7HQ4Uodd4cMJnNyFPY",[654,657],{"title":655,"path":656},"My Journey to AWS Cloud Practitioner Certification","\u002Fcloud\u002Faws\u002Fhow-i-passed-clf-exam",{"title":658,"path":659},"Giving Your Teams a Real AI Budget with LiteLLM","\u002Fai\u002Fai-budget-with-litellm",[661,675,686],{"path":662,"title":663,"description":664,"date":665,"tags":666,"topics":673},"\u002Fai\u002Fai-prompts-cross-border-transfer","Every Prompt Is a Cross-Border Transfer: AI Governance Under Law 2019-014","A company in Lomé or Dakar wires two hundred employees to American inference APIs, and nobody files anything. This article argues that a prompt containing customer data is a transfer of personal data to a third country in the sense of Togo's law 2019-014, that an LLM gateway does not change the legal nature of that transfer but is what makes it declarable, and that the residency options available to a West African company rank very differently on paper than they do once GPU prices, currency exposure and payment friction are counted.","2026-08-31",[667,668,669,670,333,671,672],"Sovereignty","Togo","Law-2019-014","ANCY","Data-Residency","Compliance",[336,338,674],"cloud",{"path":659,"title":658,"description":676,"date":677,"tags":678,"topics":684},"A hands-on guide to putting a gateway between your people and the model vendors, so that every call is attributed to a named person and a team, every team has a ceiling that resets on a schedule, a daily bound contains the runaway agent, and the finance team finally gets a per team breakdown. Covers deployment with Docker and Postgres, teams and keys, stacked budget windows, rate limits, model tiering, request tags for chargeback, PII guardrails, and the day two work nobody warns you about.","2026-08-30",[679,330,680,681,682,683],"LiteLLM","LLM-Gateway","Budgets","Observability","Platform-Engineering",[336,337,685],"platform-engineering",{"path":687,"title":688,"description":689,"date":690,"tags":691,"topics":694},"\u002Fkubernetes\u002Fsovereign-govcloud-reference-architecture","A Reference Architecture for a Sovereign Government Cloud","The two previous articles showed where Togolese law and Kubernetes fail to meet, then why multi-cloud does not answer a jurisdictional question. This one proposes what to build: a reference architecture for a sovereign government cloud in the WAEMU context. Requirements derived from the legal texts, layer-by-layer design choices with their justifications, an operating model, stated limits, and an honest comparison with the alternatives. An architecture document, not a tutorial.","2026-08-15",[667,692,693,668,683],"Kubernetes","Reference-Architecture",[695,674,685,338,696],"kubernetes","authz",1788067432002]