La nouvelle économie de la gestion des coûts de l'IA

Ces deux dernières années, la question de l'adoption de l'IA en entreprise tournait principalement autour du fait d'inciter les gens à l'utiliser. Ces derniers mois, cette réalité a rapidement évolué dans de nombreuses organisations. L'observabilité de l'IA, qui mesurait autrefois le succès au volume de tokens, commence à mesurer la réussite par le retour sur investissement, et les entreprises qui maîtriseront la gestion des coûts en premier seront celles capables d'adapter l'IA à l'échelle sans que leurs dépenses ne dépassent leurs revenus.

Dans son essence, la gestion des coûts de l'IA consiste à mesurer, attribuer, contrôler et optimiser les dépenses d'IA à travers les modèles, les agents, les applications et les équipes. L'objectif n'est pas simplement d'utiliser moins de tokens, mais de maximiser la valeur métier générée pour chaque dollar dépensé. À mesure que les agents IA prennent en charge un travail plus autonome, cette discipline s'étend de plus en plus à la gestion du coût du raisonnement des agents, des appels d'outils et des modèles qui les alimentent.

Nous avons rencontré Kevin Stumpf, Senior Staff Engineer chez Databricks et responsable technique pour Unity Gateway, pour discuter de la manière dont les équipes devraient concrètement mettre cette discipline en pratique : ne pas traiter le coût de l'IA comme une simple ligne budgétaire à réduire, mais comme un système à gérer.

Du « tokenmaxxing » au « valuemaxxing »

Les réseaux sociaux regorgent de leaders affirmant que le « tokenmaxxing », c'est-à-dire faire tourner l'IA au maximum et aussi souvent que possible, est la bonne façon d'accélérer l'innovation. En dehors des implications financières évidentes, pourquoi est-ce une mauvaise façon d'envisager l'adoption de l'IA ?

Kevin Stumpf : L'industrie évolue du « tokenmaxxing » vers le « valuemaxxing ». Au début, il y avait des classements publics montrant le nombre de tokens consommés par chacun, et cela avait du sens comme stratégie à l'époque. Beaucoup hésitaient à se lancer dans l'IA, donc montrer que les leaders admirés par tous étaient de grands utilisateurs d'IA donnait aux autres une raison de suivre l'exemple. Si je vois quelqu'un que je respecte utiliser énormément l'IA, j'ai envie de faire comme lui.

Mais le système a été détourné. Une fois qu'être en haut du classement est devenu un symbole de statut, les gens ont compris que le moyen le plus rapide d'y arriver n'était pas un travail de qualité, mais le volume. Lancer un agent basique qui tourne en boucle, lui demander le temps qu'il fait en boucle et consommer des tokens à ne pratiquement rien faire. C'était le résultat prévisible d'un système d'incitation qui récompensait l'utilisation brute plutôt que les résultats.

Maintenant que les organisations ont largement adhéré à l'IA, la discussion s'est orientée vers une utilisation responsable et efficace. Ce vers quoi nous devrions vraiment tendre, c'est un autre type de classement, qui classerait les gens selon l'impact généré avec l'IA divisé par ce qu'il a coûté à produire. C'est le retour sur investissement, et c'est une donnée beaucoup plus difficile à quantifier que le simple nombre de tokens, mais c'est le seul chiffre qui compte réellement. Sur le même sujet : Qu'est-ce qui stimule l'adoption de l'IA en entreprise ?

Ce que signifie réellement l'attribution des coûts en pratique

Pouvez-vous nous expliquer ce que signifie réellement « l'attribution des coûts » dans le domaine de l'IA ?

Kevin Stumpf : L'attribution des coûts de l'IA consiste en fin de compte à répondre à deux questions : d'où viennent mes dépenses, et qu'ai-je obtenu en échange ? Au niveau le plus simple, cela signifie attribuer un coût à un utilisateur individuel ou à une équipe, comme une équipe de data science ou d'ingénierie logicielle. Cela peut également être rattaché à un projet spécifique, ou à un nœud dans un organigramme, par exemple comprendre quelles dépenses relèvent d'un vice-président IA par rapport à un vice-président senior ingénierie.

L'objectif est d'avoir une visibilité suffisamment fine pour pouvoir analyser les données sous tous les angles et comprendre d'où viennent réellement les coûts, car on ne peut pas gérer ce qu'on ne peut pas mesurer. Databricks propose l'attribution des coûts nativement par utilisateur, groupe, agent, point de terminaison AI Gateway, modèle, fournisseur et période. Mais les organisations peuvent également la personnaliser à l'extrême en utilisant des balises au niveau de la requête. Une balise peut représenter tout ce qui importe pour votre organisation, comme une pull request spécifique, une fonctionnalité ou un client externe, et une fois que chaque requête porte cette balise, vous pouvez agréger les dépenses selon vos besoins.

Ce changement d'attitude chez les clients a été bien réel. Il y a six mois, la principale crainte était d'accumuler du retard dans l'adoption de l'IA. Aujourd'hui, c'est l'inverse : l'IA est souvent utilisée pour des futilités, les coûts augmentent plus vite que les revenus, et les dirigeants cherchent comment fléchir cette courbe des coûts avant qu'elle ne nuise à la rentabilité. Ce n'est pas une hypothèse. C'est une discussion de haut niveau qui a lieu dans presque toutes les entreprises avec lesquelles nous échangeons, y compris en interne chez Databricks.

Maîtriser le surdimensionnement du contexte

L'utilisation des tokens et la taille de la fenêtre de contexte sont souvent incriminées, mais rarement bien expliquées. À quoi ressemble concrètement le gonflement du contexte dans un système en production, et quelle est la solution pratique ?

Kevin Stumpf : Le gonflement du contexte consiste à fournir à un agent beaucoup plus d'informations qu'il n'en a besoin pour prendre une bonne décision. C'est un problème pour deux raisons. Premièrement, cela consomme inutilement des tokens. Deuxièmement, cela le distrait : l'agent doit traiter ces informations supplémentaires et déterminer si elles sont pertinentes, ce qui génère un surcoût en soi. Cela ressemble un peu au fait de donner à une personne une pile de documents non pertinents et de lui demander de trouver ce qui compte avant même de pouvoir commencer sa tâche.

La meilleure solution ne consiste pas à élaguer ou mettre en cache après coup, mais à ne pas générer ce gonflement au départ. Une méthode courante et efficace consiste à laisser l'agent récupérer le contexte pertinent à la demande, via des outils, des serveurs MCP ou des compétences, plutôt que de lui fournir de manière proactive tout ce dont il pourrait avoir besoin dès le départ. Vous ne devriez fournir du contexte à un agent par défaut que si vous êtes sûr à au moins 90 % qu'il est réellement important pour la tâche à accomplir. Sinon, informez l'agent de ce qui est disponible et laissez-le récupérer ce dont il a besoin quand il en a besoin.

Routage dynamique des modèles et des harnesses

Le choix du modèle est souvent une décision prise une fois pour toutes. Pourquoi devrait-il plutôt être dynamique, et comment le routage intelligent décide-t-il, en temps réel, si une tâche nécessite un modèle de pointe (frontier model) ou quelque chose de plus rapide et moins cher ? Cette même idée s'applique-t-elle au choix entre différents harnesses d'agents ?

Kevin Stumpf : L'optimisation des coûts de l'IA ne consiste pas à toujours choisir le modèle le moins cher ; les équipes devraient plutôt opter pour le modèle ou le harness au coût le plus bas capable de fournir la qualité requise par une tâche. La réalité actuelle est que les modèles de pointe sont extrêmement performants et coûteux, tandis que les autres modèles restent très performants tout en étant moins chers. Environ 5 à 10 % des tâches nécessitent véritablement un modèle de pointe, soit parce que les enjeux sont suffisamment élevés pour exiger le meilleur résultat possible, soit parce que le problème est trop complexe pour tout autre modèle. Les 90 % restants peuvent être résolus par des modèles moins élaborés, qu'il s'agisse de modèles open source hébergés par vos soins ou de familles de modèles moins coûteuses proposées par les grands laboratoires.

Livrés à eux-mêmes, la plupart des employés utiliseront par défaut le modèle le plus cher disponible, car leur objectif est simplement de résoudre le problème et personne ne surveille ce que cela leur coûte individuellement. Smart Routing résout cela en insérant une couche qui évalue la complexité de la tâche en temps réel et décide si une requête doit être dirigée vers un modèle de pointe ou vers un modèle plus économique, avec pour objectif de maintenir la même qualité de résultat pour un coût inférieur.

Le routage par harness représente l'étape suivante après le routage de modèle. Des recherches récentes montrent qu'un même modèle, exécuté via un harness différent, peut générer des coûts nettement différents. Cela s'explique par le fait que le harness détermine la façon dont le modèle interagit avec son environnement : les règles qu'il suit, le moment où il réduit la fenêtre de contexte, la logique métier qui régit son comportement. Tout cela influe directement sur le nombre de tokens consommés. Le routage par harness constitue la prochaine étape dans cette évolution progressive de l'optimisation des coûts, que nous rendons possible grâce à Unity Gateway et à Omnigent, notre meta-harness.

Concevoir des garde-fous sur les dépenses

Parlons des garde-fous sur les dépenses elles-mêmes, comme les plafonds stricts, les budgets et les limites de débit. Quelle est la meilleure approche pour les concevoir afin d'éviter les dérives de coûts sans nuire à la productivité des développeurs ni interrompre les flux de travail en production ?

Kevin Stumpf : Certaines règles s'appliquent à toutes les organisations, tandis que d'autres dépendent du cas d'usage ou de l'entreprise. Tout le monde devrait mettre en place des plafonds de dépenses stricts pour stopper les utilisations incontrôlées. Si votre utilisateur le plus actif dépense au maximum environ 300 $ par jour en IA, fixez le plafond strict un peu au-dessus, par exemple à 500 $. Cet écart vous laisse une marge pour détecter les véritables erreurs, comme un agent resté tourner en boucle par accident, sans bloquer les journées d'utilisation intensive légitimes.

Au-delà de cette base, il est très judicieux d'établir des budgets différenciés par équipe ou par projet. Une équipe travaillant sur un projet critique pour le PDG peut justifier un budget bien supérieur à celui d'une équipe travaillant sur des tâches moins prioritaires, et cette décision doit comparer la valeur produite par cette équipe au coût nécessaire pour lui accorder plus de marge de manœuvre.

Les budgets doivent également pouvoir déclencher différents types de réponses, et pas seulement un arrêt strict. Ils peuvent envoyer des alertes, appliquer des plafonds stricts ou réduire la capacité de modèle disponible, par exemple en coupant l'accès par défaut aux modèles de pointe lorsqu'une équipe a consommé 70 % de son budget et en réacheminant le reste de ses requêtes vers des modèles open source. Les principes fondamentaux s'appliquant partout : éviter les dépenses incontrôlées, définir des limites différenciées par groupe ou projet, alerter avant de plafonner et intégrer une réduction intelligente de capacité plutôt qu'une coupure brutale.

Mesurer ce que l'IA apporte réellement

Quelles plateformes proposent à la fois le suivi des agents et le suivi des coûts, et jusqu'où cette visibilité peut-elle vous mener dans la mesure du ROI réel, et pas seulement des dépenses ?

Kevin Stumpf : Mesurer le coût est beaucoup plus simple que de relier ce coût au retour sur investissement, et c'est la question à laquelle tout le monde souhaite répondre mais que presque personne n'a encore totalement résolue. Le marquage au niveau de la session ou de la requête est ce qui rend cela possible. Si un agent travaille sur une pull request spécifique, il peut taguer sa session ou des requêtes spécifiques qu'il génère avec l'identifiant de cette pull request. Cette attribution remonte dans un tableau de bord des coûts, ce qui vous permet de voir, par exemple, qu'une pull request donnée a coûté 300 $ à accomplir. C'est quelque chose que nous faisons déjà en interne chez Databricks.

Dans un monde idéal, et c'est une fonctionnalité que nous intégrons au produit Unity Gateway, vous pouvez aller encore plus loin et connecter cette pull request à une fonctionnalité spécifique, puis cette fonctionnalité à un résultat mesurable, comme les revenus ou le pipeline générés sur une période donnée. C'est le Graal : ne pas seulement savoir ce que l'IA a coûté, mais savoir ce qu'elle a rapporté. Avec Unity Gateway, nous disposons déjà d'une plateforme hautement personnalisable sur laquelle nous appuyer, et nous investissons pour rendre cette vue du rapport coût/rendement disponible nativement, plutôt que sous la forme d'un outil que les équipes doivent construire elles-mêmes.

La visibilité sur les dépenses exige un système centralisé

Pour une entreprise qui exploite plusieurs modèles, agents et outils au sein de nombreuses équipes, qu'exige réellement une bonne visibilité sur les dépenses ? S'agit-il d'un problème de tableau de bord, de gouvernance ou de FinOps ?

Kevin Stumpf : Une bonne visibilité sur les dépenses exige que chaque interaction IA passe par un système centralisé. C'est ce qui vous permet de verrouiller la bonne information de manière cohérente, afin de pouvoir construire des tableaux de bord et des alertes fiables sur cette base. Une passerelle IA offre un point de contrôle centralisé pour la gestion des coûts de l'IA à travers les modèles, les agents, les outils et les équipes. Databricks Unity Gateway est conçu pour fournir ce point de contrôle centralisé à travers les modèles, les agents, les outils et les agents de codage. Lorsque les interactions IA passent par un point de contrôle commun, les organisations peuvent observer l'utilisation, attribuer les coûts, appliquer les budgets et optimiser les dépenses au même endroit.

Mais disposer du système centralisé ne suffit pas en soi. Il faut aussi un moyen d'obliger chacun à véritablement acheminer son trafic IA à travers celui-ci. La visibilité ne fonctionne que si l'adoption est universelle, et non optionnelle.

Équilibrer l'optimisation des coûts et la qualité des résultats

Le contrôle des coûts ne doit pas se faire au détriment de la qualité ou de la fiabilité. Comment savoir si une optimisation est allée trop loin et commence à nuire aux résultats ?

Kevin Stumpf : Cela dépend vraiment du cas d'usage. Vous avez besoin d'un mécanisme de retour d'information, qu'il soit subjectif ou objectif. Le retour subjectif est anecdotique : c'est un membre de l'équipe qui vous dit qu'il ne peut pas accomplir son travail avec le budget actuel. C'est rapide à obtenir, mais facile à écarter en y voyant la simple plainte d'une personne. Le retour objectif provient d'évaluations automatisées, plus difficiles à mettre en place mais beaucoup plus fiables.

Pour un cas d'usage courant comme les agents de codage, cela pourrait signifier définir une métrique d'évaluation de la qualité, comme les pull requests fusionnées qui ne sont pas annulées dans les deux semaines. À partir de là, vous pouvez expérimenter : réduire le budget de moitié et voir si cette métrique clé évolue, reste stable ou même s'améliore, car les contraintes stimulent parfois la créativité. L'exécution d'expérimentations parallèles au sein de plusieurs équipes avec des budgets, modèles et bancs d'essai différents, ou des comparaisons limitées dans le temps sur quelques semaines, vous permet de déduire si un budget donné crée de la valeur ou en détruit, au lieu de deviner.

La valeur du traçage de bout en bout

Quel rôle jouent le traçage et le suivi de bout en bout ici ? Une fois que vous pouvez voir les prompts, les appels d'outils et l'utilisation de jetons dans l'ensemble du flux de travail d'un agent, qu'est-ce que cela débloque que vous ne pouviez pas faire auparavant ?

Kevin Stumpf : Le traçage consiste à collecter l'ensemble des résidus d'activité des agents : ce à quoi ils pensent, les outils qu'ils appellent, les données qu'ils extraient, et si les prompts sont bons ou mauvais. Ce sont ces données brutes que vous pouvez analyser pour en tirer des enseignements, qu'il s'agisse d'identifier des abus, du gaspillage, des fuites de sécurité ou simplement des modèles que vous n'auriez jamais pensé à chercher.

Cela reflète ce qui s'est produit dans l'industrie plus large des données. Au début, nous n'avions que des données propres et structurées dans des bases de données. Puis sont arrivés les data lakes, qui sont devenus pendant un temps des marécages de données, car les utilisateurs y versaient des données non structurées sans moyen d'en extraire de la valeur. Finalement, ces marécages sont redevenus des data lakes exploitables, et nous sommes aujourd'hui mieux placés que jamais pour tirer des enseignements de données non structurées et semi-structurées, principalement parce que les LLM sont suffisamment flexibles pour les traiter. Les traces d'agents entrent dans cette même catégorie. Plus vous en collectez, plus vous obtenez d'enseignements, et il est plus facile que jamais d'y accéder.

Passer à l'échelle avec des flottes d'agents

De nombreuses entreprises passent d'applications IA isolées à des flottes d'agents. Ce changement modifie-t-il l'équation des coûts (nouveaux facteurs de coûts ? nouveaux points aveugles ?) par rapport à l'exécution d'un seul modèle derrière une seule application ?

Kevin Stumpf : Cela ne modifie pas tant l'équation qu'elle ne la multiplie. Les essaims d'agents vont être la nouvelle réalité, et chacun de ces agents consommera des tokens qu'il faudra attribuer, surveiller et gérer. C'est maintenant qu'il faut poser les bonnes bases de visibilité et de gestion des coûts, avant que le nombre d'agents en production n'augmente comme prévu.

Les agents de codage constituent aujourd'hui la catégorie dominante consommant des tokens, mais cela va s'étendre à de nombreuses autres classes d'agents effectuant un travail autonome 24h/24, des agents appelant d'autres agents qui en appellent d'autres. Les organisations qui attendent que cette complexité survienne pour créer une infrastructure centralisée d'observabilité de l'IA et de gestion des coûts la construiront sous pression, au lieu de le faire selon leurs propres conditions.

Si vous deviez transmettre un seul changement d'état d'esprit concernant la gestion des coûts aux responsables de l'IA en entreprise à l'approche de l'année prochaine, quel serait-il ?

Kevin Stumpf : Je n'attendrais pas l'année prochaine. C'est urgent, et cela doit être traité comme tel dès maintenant. Si je devais résumer cela à une seule idée, la voici : on ne peut pas gérer ce qu'on ne mesure pas. Cela s'applique aux matières premières, aux personnes, et tout autant à l'IA. L'IA devient rapidement l'un des postes les plus importants du tableau des flux de trésorerie d'une entreprise, et elle doit être entièrement instrumentée afin de pouvoir être mesurée et, à son tour, gérée. C'est simplement un autre ingrédient de base dans le système qui produit les biens ou services de votre organisation, et il mérite d'être traité avec la même rigueur.

Le compte à rebours est lancé Contrôler les coûts de l'IA au sein d'équipes utilisant plusieurs modèles et outils n'est pas un problème qui se résout avec un seul tableau de bord ou un choix ponctuel de modèle. Il s'agit d'une discipline opérationnelle : une attribution suffisamment fine pour relier les dépenses à une personne ou un projet, un acheminement qui s'adapte en temps réel aux exigences d'une tâche, des garde-fous qui stoppent les dépenses incontrôlées avant qu'elles ne fassent les gros titres et un traçage suffisamment détaillé pour transformer les données d'utilisation brutes en véritable enseignement. Les organisations qui prennent de l'avance sur ce sujet ne sont pas celles qui dépensent le moins pour l'IA. Ce sont celles qui peuvent dire, avec certitude, exactement ce qu'elles ont obtenu en échange de ce qu'elles ont dépensé.

En savoir plus sur la façon dont Unity Gateway centralise l'attribution des coûts, le routage intelligent et les garde-fous budgétaires sur l'ensemble de votre environnement IA.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original