Personne ne sait ce que votre entreprise dépense en IA

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.

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.

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.

Le shadow IT laissait au moins une facture

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.

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.

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 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.

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.

Les trois inconnues

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.

La première est 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.

La deuxième est 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.

La troisième est 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.

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.

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.

Pourquoi la charte IA ne fonctionne pas

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 peut l'être.

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.

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.

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 facile, pas le chemin vertueux.

Le budget fixe est la mauvaise question

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à.

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.

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.

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.

Ce que le FinOps apporte réellement ici

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.

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.

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.

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.

Le token n'est pas une unité métier

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.

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.

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.

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.

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.

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.

Les agents cassent le budget par siège

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.

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.

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.

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.

Gouverner en donnant

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.

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.

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.

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.

Ce qu'une passerelle ne verra jamais

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.

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.

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.

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.

Un modèle opérationnel qui tient au contact

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.

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.

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.

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.

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.

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.

Par où commencer

Le séquencement compte plus que n'importe quelle décision prise isolément, et il est l'inverse de l'intuition.

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.

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.

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.

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.

Limites et questions ouvertes

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.

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.

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.

Sources

• FinOps Foundation, FinOps Framework : domaines, capacités et cycle informer, optimiser, opérer. finops.org/framework
• FinOps Foundation, FinOps for AI et l'extension du périmètre du référentiel au-delà du cloud public, vers le SaaS et les charges IA. finops.org/introduction/what-is-finops
• Documentation LiteLLM, 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. docs.litellm.ai
• 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.