Comment maîtriser les coûts de l’IA avec plusieurs modèles

Des tokens d’IA moins chers envoient un signal trompeur aux budgets des entreprises. Sachin Chitturu, associé et responsable de l’Asie du Sud-Est chez QuantumBlack, AI by McKinsey, a déclaré à Tech Week Singapore que les données de Silicon Data montrent que les prix par token ont baissé d’environ 90% depuis 2023. Pourtant, des estimations de Gartner citées par Chitturu situent la consommation de tokens des modèles agentiques, capables d’exécuter des tâches en plusieurs étapes avec une plus grande autonomie, entre cinq et 30 fois plus par tâche. La baisse des prix unitaires peut donc coexister avec une hausse de la facture totale.

« Le coût des tokens ne diminue pas autant que l’usage des tokens augmente », a déclaré Chitturu. Cette relation change la question de l’architecture pour les responsables technologiques, car l’économie des modèles dépend à la fois du prix de chaque token et du nombre de tokens consommés par une charge de travail. À mesure que les agents prennent en charge des tâches plus longues, les entreprises doivent continuer à décider quels travaux justifient un raisonnement coûteux, lesquels peuvent s’exécuter sur des modèles moins chers, et où l’intervention humaine doit rester présente. QuantumBlack et McKinsey conseillent des entreprises clientes sur l’IA, ils ont donc un intérêt commercial dans la demande pour les travaux d’architecture et de transformation évoqués par Chitturu.

Des tokens moins chers peuvent malgré tout entraîner des coûts d’IA plus élevés pour les entreprises

La hausse de la consommation affaiblit une hypothèse courante dans la planification de l’IA en entreprise : l’amélioration de l’économie des modèles rendra progressivement moins coûteuses les charges de travail déployées. Les systèmes agentiques peuvent absorber les économies réalisées sur le prix unitaire en effectuant davantage de travail dans chaque tâche, de sorte que le coût pertinent est celui de la charge de travail complète. Pour un CTO ou une équipe FinOps, le contrôle financier dépend donc conjointement de la conception de la charge de travail, du choix du modèle et du mode de déploiement.

Ces variables modifient aussi le sens de la standardisation. Choisir un seul fournisseur de modèles de premier plan peut simplifier un déploiement initial, mais chaque charge de travail qui s’étend reste alors exposée à l’économie de ce fournisseur et à la consommation de tokens du modèle. Comme les tâches simples et les raisonnements difficiles ont des exigences très différentes, la vraie question d’architecture devient de savoir où chaque requête doit s’exécuter et comment son routage doit évoluer à mesure que les modèles et les prix changent.

La pression sur les coûts freine déjà l’adoption et met en évidence l’écart de ROI

Le besoin de contrôle au niveau de la charge de travail est déjà visible dans les budgets des entreprises. Chitturu a cité une enquête sur les opérations financières de l’IA en entreprise, ou FinOps, selon laquelle 93% des entreprises auraient dépassé leur budget IA au cours des six mois précédents. Le FinOps applique des pratiques de gestion financière à la consommation technologique, et l’IA rend cette discipline plus difficile parce que les applications, les agents et les modèles peuvent faire évoluer rapidement la consommation de calcul. Le contrôle budgétaire doit donc tenir compte de l’évolution de l’usage après le déploiement.

Cette pression restreint déjà la demande. Dans la dernière enquête mondiale de McKinsey sur l’état de l’IA, un répondant sur cinq a déclaré que les coûts d’exploitation, y compris les coûts des tokens, avaient conduit son organisation à limiter l’usage de l’IA. Les organisations technologiques ont signalé le taux de réduction le plus élevé, à 25%, suivies des institutions financières à 24%. Même parmi les organisations les plus performantes, Chitturu a indiqué que moins de 30% des employés déclarent avoir accès à toutes les capacités d’IA qu’ils souhaitent.

Ces restrictions comptent davantage lorsque la productivité individuelle est comparée aux retours financiers au niveau de l’entreprise. McKinsey a constaté que 80% des répondants utilisant l’IA au travail ont déclaré qu’elle améliorait leur productivité individuelle, tandis que 37% ont signalé une contribution positive au résultat opérationnel avant intérêts et impôts de l’organisation, ou Ebit. Seuls 6% ont été qualifiés de leaders de l’IA : des organisations attribuant au moins 5% de leur Ebit à l’IA et décrivant cet effet comme significatif. Ces chiffres mesurent des niveaux d’impact différents, ce qui aide à expliquer comment un bénéfice largement répandu pour les employés peut coexister avec un effet déclaré plus limité sur les résultats.

Cet écart change la conversation avec les conseils d’administration, car une hausse de l’usage à elle seule ne suffit pas à établir un retour suffisant. « Les organisations disent : “Je ne sais pas comment attribuer de la valeur à l’IA”, et elles disent aussi : “J’ai déjà largement dépassé mon budget IA” », a déclaré Chitturu. « C’est une pente très glissante pour n’importe quelle technologie. » Les entreprises peuvent donc avoir des utilisateurs individuels productifs tout en peinant à relier les dépenses globales aux résultats.

La difficulté à relier les dépenses aux résultats est antérieure à la dernière génération d’IA générative. Chitturu a indiqué que, dans les échanges avec les clients de McKinsey, des PDG avaient dépensé des centaines de millions de dollars dans des plateformes de données et d’IA depuis 2015 sans pouvoir pas suivre ce que ces dépenses avaient réellement produit. Ces discussions se sont donc déplacées du choix de la prochaine plateforme vers l’extraction de valeur à partir des investissements déjà en place. La contrainte porte de plus en plus sur la relation entre coût, adoption et résultats métier mesurables.

La réponse économique consiste à faire correspondre le modèle et le mode de déploiement à la charge de travail

Une fois le coût, l’adoption et les résultats considérés ensemble, une dépendance concentrée envers les fournisseurs de modèles de pointe devient un choix d’architecture parmi d’autres. Chitturu a déclaré que les organisations se demandent si elles doivent être « à 100% sur ces entreprises d’IA de pointe comme OpenAI et Anthropic » et explorent des alternatives. « Nous conseillons, et en fait leurs propres PDG conseillent aussi, que nous devons diversifier », a-t-il déclaré. Ici, la diversification signifie décider de quel niveau de capacité de modèle chaque charge de travail a réellement besoin.

Cette décision commence par les exigences de raisonnement de la tâche. Les adopteurs les plus sophistiqués classent le travail selon ces exigences, a déclaré Chitturu, en envoyant le raisonnement de haut niveau vers des modèles de pointe et les tâches plus simples, plus déterministes, vers des modèles open-weight. Les modèles open-weight rendent leurs poids disponibles pour qu’une organisation puisse les télécharger, les ajuster et les exécuter elle-même. L’automatisation de routine peut tirer peu de valeur supplémentaire d’un raisonnement de pointe, de sorte qu’une entreprise peut évaluer si cette prime est justifiée pour chaque catégorie de requête.

Chitturu estime très élevée la part potentielle du travail de routine. « Nous devons créer une solution adaptée à l’usage parce que, honnêtement, 95% des activités d’entreprise ne nécessitent pas un degré de calcul plus élevé qu’une simple opération arithmétique. Ce n’est qu’un travail d’automatisation. » Le chiffre de 95% est l’évaluation de Chitturu plutôt qu’une part établie de manière indépendante, mais il illustre l’architecture qu’il anticipe : une puissance de calcul plus importante est réservée aux charges de travail dont les exigences de raisonnement la justifient.

Cette répartition des charges de travail conduit à une prévision ambitieuse de Chitturu et McKinsey. « Selon nous, l’avenir de l’architecture IA d’entreprise sera au maximum de 10-15% sur la frontière, et 80-85% se fera sur des open weights », a-t-il déclaré. Ces pourcentages décrivent une segmentation proposée des charges de travail d’entreprise, en traitant la capacité de pointe comme une ressource premium au sein d’un portefeuille de modèles plus large. En tant que recommandation émanant d’un cabinet de conseil en IA, cette prévision reflète aussi la position commerciale de McKinsey dans l’accompagnement des entreprises pour concevoir et faire évoluer de telles architectures.

Les facteurs économiques qui sous-tendent cette prévision deviennent plus convaincants à mesure que l’écart de capacité se réduit. Chitturu a déclaré que le délai avant que les modèles open-weight atteignent la qualité des modèles de pointe sur la plupart des charges de travail d’entreprise est passé de plusieurs années à quelques mois. Il estime aussi leur prix par token à environ un tiers à un dixième du prix des API de pointe. Ces tarifs décrivent les prix des tokens ; les coûts par tâche achevée peuvent néanmoins différer, car les modèles peuvent consommer des quantités de tokens différentes.

Des prix d’API plus bas ne représentent qu’une partie du calcul de déploiement, car l’auto-hébergement ajoute des dépenses fixes d’infrastructure et des coûts d’opérations de machine learning, ou MLOps, pour déployer, exploiter et maintenir les modèles. Chitturu a déclaré que ces coûts fixes ne deviennent rentables qu’une fois qu’un volume suffisant de charges de travail est atteint. Beaucoup d’entreprises commencent seulement à développer les capacités d’ingénierie nécessaires pour exploiter efficacement cet environnement. Le choix économique dépend donc du mode de déploiement autant que de la catégorie de modèle.

Ce choix de déploiement donne à une architecture mature plus de deux options. Un trafic de routine à fort volume peut favoriser des open weights auto-hébergés lorsque l’économie unitaire domine, tandis que des charges de travail spécifiques à un domaine peuvent privilégier la même approche de déploiement lorsqu’une entreprise doit ajuster un modèle sur des données propriétaires. Les charges de travail à demande irrégulière, à faible sensibilité et sans exigence stricte de résidence des données peuvent au contraire utiliser une API open-weight hébergée. L’accès hébergé évite de supporter une infrastructure fixe pour une capacité nécessaire seulement de manière intermittente.

Les charges de travail difficiles ou à fortes conséquences constituent le cas restant en faveur des API de pointe, car la qualité du modèle peut justifier la prime lorsque les exigences de raisonnement ou les coûts d’échec sont élevés. Cette même segmentation répond à une objection économique majeure aux open weights : l’accès à des catégories de modèles moins chères n’exige pas qu’une entreprise exploite elle-même chaque modèle. Une organisation peut combiner l’auto-hébergement à une échelle suffisante, des services open-weight hébergés pour des charges de travail variables adaptées, et des services de pointe là où leurs capacités ont la plus forte valeur.

Le harness devient un plan de contrôle économique

Un portefeuille mixte de modèles ne crée de valeur que si le logiciel peut choisir entre ces options pendant l’exécution du travail. Le mécanisme pertinent est le harness, le logiciel qui entoure un grand modèle de langage, ou LLM, ou un agent, et qui détermine quel contexte le modèle reçoit, combien de tokens il peut dépenser et comment il aborde la tâche. L’ingénierie du harness s’est souvent concentrée sur les garde-fous et le risque, mais Chitturu voit cette même couche devenir un moyen de gouverner les dépenses. La décision de portefeuille devient alors une politique exécutable.

Cette politique transforme le choix du modèle en décision d’architecture à l’exécution. « Le harness vous donne la flexibilité de choisir si nous allons vers ce LLM coûteux et gourmand en tokens ou si nous passons par un [modèle] open-weight, et comment nous ajustons cela dynamiquement à la volée », a déclaré Chitturu. Une requête peut être routée selon ses besoins tandis que le harness contrôle la quantité de contexte et de capacité en tokens qu’elle reçoit. Les achats définissent les choix disponibles ; le harness décide comment ces choix sont utilisés pour les tâches individuelles.

Le choix à l’exécution crée un problème d’ingénierie, car le routage doit préserver un niveau de capacité suffisant pour la tâche tout en maîtrisant la consommation. Un harness peut envoyer les requêtes de routine vers un modèle moins cher lorsque le raisonnement premium apporte peu de valeur, puis faire remonter les cas difficiles ou à fortes conséquences vers un modèle de pointe. Les plafonds de tokens fournissent un second levier de coût en gouvernant la quantité de calcul qu’une tâche peut consommer. Ensemble, le routage des modèles et les limites de tokens déterminent une partie du coût de la charge de travail avant même que la tâche soit terminée.

Ces contrôles font de l’ingénierie du harness un élément de l’architecture financière de l’IA autant que de la sécurité de l’IA. L’organisation doit construire le logiciel environnant et la compétence opérationnelle nécessaires pour prendre de manière fiable des décisions de routage et de tokens, ce que Chitturu dit que beaucoup d’entreprises commencent seulement à faire. Sans cette capacité, un portefeuille de modèles avec des options moins chères peut malgré tout rester difficile à exploiter de manière économique.

Le ROI dépend de la refonte des workflows

Une fois que le routage contrôle le coût des modèles, la question du ROI se déplace vers la manière dont l’IA transforme le travail lui-même. Les données de McKinsey sur les leaders de l’IA indiquent que la refonte des workflows constitue une différence majeure entre les leaders et les autres organisations. La même comparaison montre des différences d’ambition et de pratiques de mesure, reliant le changement de processus à la manière dont les organisations fixent leurs objectifs et suivent leurs résultats.

L’écart sur les workflows est important, car insérer l’IA dans un processus existant laisse inchangées de nombreuses décisions concernant les rôles, les transferts et la supervision. Les leaders repensent plus souvent le processus lui-même, ce qui permet aux améliorations des capacités des modèles de modifier qui ou quoi exécute chaque étape. Leur taux plus élevé de suivi de l’impact relie ensuite ces changements de processus aux résultats. Les déclarations de productivité individuelle peuvent compléter cette mesure, mais elles opèrent à un niveau différent de l’impact organisationnel.

Chitturu décrit ce changement comme organisationnel autant que technique. « Ils ont tous dit qu’il ne s’agit pas seulement d’une transformation technologique », a déclaré Chitturu. « C’est une transformation de notre manière de travailler. C’est une transformation de la manière dont nous nous organisons. » Pour les dirigeants, la conséquence est que les programmes d’architecture et les programmes de modèle opérationnel doivent de plus en plus avancer ensemble.

Ce modèle opérationnel doit lui aussi évoluer à mesure que les modèles s’améliorent. Chitturu a déclaré que huit LLM différents ont établi des records sur des benchmarks de raisonnement avancé au cours de l’année écoulée, obligeant les organisations à reconsidérer à plusieurs reprises quelle part de chaque workflow un modèle peut exécuter et dans quelle mesure la supervision humaine reste utile. « Cette discussion ne se déroule pas comme un exercice ponctuel de blueprinting. Elle a lieu tous les trois mois », a-t-il déclaré. La rapidité des progrès des modèles transforme la conception des workflows en décision opérationnelle récurrente.

La revue humaine montre à quoi ressemblent concrètement ces décisions récurrentes dans la pratique. Les clients de McKinsey avaient auparavant discuté d’architectures dans lesquelles l’IA vérifie l’IA tandis qu’une personne reste dans la boucle. Chitturu a déclaré que les discussions plus récentes avec les clients demandent si cette personne est toujours nécessaire ou si l’implication humaine peut être réduite. Les améliorations des capacités des modèles peuvent donc modifier la répartition du travail elle-même, chaque revue reconsidérant la frontière entre travail automatisé et supervision humaine.

Pour gérer cette frontière mouvante, Chitturu propose une équipe dédiée de type « think tank ». Cette équipe suivrait les évolutions de l’architecture des solutions, ferait intervenir des experts métier pour décider au cas par cas quel travail relève de l’IA et lequel relève des personnes, et suivrait l’évolution de l’économie. Ce périmètre réunit capacité, workflow et coût, car une tâche peut passer des personnes aux modèles open-weight puis aux modèles de pointe selon l’évolution des performances relatives et de l’économie.

Les équipes dirigeantes ont besoin d’un engagement calibré

La réévaluation continue donne aussi aux équipes dirigeantes un moyen de contrôler avec quel niveau d’agressivité elles déploient l’IA. Chitturu a mis en garde contre les entreprises qui déploient largement l’IA dans plusieurs domaines d’activité sans offrir aux employés un chemin d’adoption. « Ces organisations vont échouer », a-t-il déclaré. « Elles vont brûler de l’argent, et elles ne vont pas réaliser le retour sur investissement et perdront leur conviction. » Selon lui, une large portée de déploiement sans adoption crée des dépenses avant que l’organisation n’ait établi une voie vers la valeur.

Attendre expose à un autre risque, car les concurrents peuvent continuer à avancer pendant qu’une organisation prudente retient ses investissements. Les organisations qui attendent parce qu’elles doutent de la durabilité des avancées de l’IA peuvent se retrouver face à ce que Chitturu a appelé des « perturbateurs à forte croissance et à évolution rapide qui viendront et décimeront complètement votre secteur ». Il identifie le défi central pour les équipes dirigeantes et les conseils d’administration comme étant de décider avec quel niveau d’agressivité avancer et à quel niveau s’engager. La décision porte donc sur le rythme et l’ampleur de l’engagement dans des conditions techniques et économiques changeantes.

Cet engagement doit rester ajustable, car les API de pointe, les API open-weight hébergées, les modèles auto-hébergés et le travail humain impliquent des coûts et des exigences opérationnelles différents. Leur valeur relative évolue selon le volume de la charge de travail, sa sensibilité, la difficulté du raisonnement et les conséquences d’un échec. Les équipes dirigeantes ont donc besoin de la capacité à réallouer en permanence le travail et l’investissement à mesure que les modèles, l’économie et les workflows évoluent.

Principaux enseignements pour les dirigeants

• Gérez les coûts de l’IA au niveau de la charge de travail : La baisse des prix des tokens peut malgré tout produire des factures plus élevées lorsque les systèmes agentiques consomment de cinq à 30 fois plus de tokens par tâche. Les équipes FinOps doivent suivre les coûts des charges de travail complètes en parallèle des prix des tokens et de leur usage.
• Reliez les dépenses d’IA à des retours mesurables : Les dépassements de budget IA et la faiblesse de l’attribution freinent déjà l’adoption, même si les employés déclarent des gains de productivité. Les équipes dirigeantes ont besoin de métriques reliant la consommation d’IA aux résultats des workflows et à l’impact financier.
• Faites correspondre les modèles aux exigences des charges de travail : Les tâches de routine peuvent souvent s’exécuter sur des modèles open-weight moins coûteux, tandis que les raisonnements complexes ou à fortes conséquences peuvent justifier des API de pointe. Les équipes d’architecture peuvent aussi choisir entre auto-hébergement et API hébergées selon le volume, la sensibilité et la capacité opérationnelle.
• Faites du harness IA une couche de contrôle des coûts : Le routage à l’exécution et les limites de tokens permettent aux entreprises d’orienter chaque requête vers un modèle approprié et de contrôler son budget de calcul. Les équipes plateforme ont besoin des capacités d’ingénierie nécessaires pour appliquer ces politiques de manière fiable à mesure que les prix et les performances des modèles évoluent.
• Repensez les workflows à mesure que les capacités des modèles progressent : Les leaders de l’IA selon McKinsey déclarent des taux nettement plus élevés de refonte des workflows et de suivi de l’impact. Les équipes métier et technologiques ont besoin de revues récurrentes de l’allocation des tâches, de l’automatisation et de la supervision humaine à mesure que les modèles gagnent en capacité.
• Calibrez l’investissement IA en fonction de l’adoption et de l’économie : Un déploiement large sans trajectoire d’adoption peut consommer les budgets avant que la valeur ne se matérialise, tandis qu’une prudence excessive peut laisser les organisations derrière des concurrents plus rapides. Les équipes dirigeantes ont besoin d’un modèle d’investissement ajustable qui réalloue les charges de travail et les dépenses à mesure que l’adoption, les capacités et l’économie évoluent.