Les dépenses des agents IA deviennent un enjeu d’architecture

Les entreprises aiment leurs plateformes d’agents, et refusent pourtant de miser sur une seule

Les équipes en entreprise attribuent à leurs plateformes d’orchestration une note globale de satisfaction de 4,17 sur 5, alors même que l’entreprise médiane en exploite trois simultanément. Cette tension compte pour la planification de l’architecture, car la satisfaction à l’égard d’un produit ne détermine pas si une entreprise en fera l’unique endroit où les agents sont contrôlés. L’analyse continue de 107 entreprises par VB Pulse/VB Intelligence montre que l’usage de plusieurs outils d’orchestration est déjà la norme.

Les personnes qui prennent ces décisions comprennent des ingénieurs logiciels et machine learning, des responsables produit et programme, ainsi que des vice-présidents et directeurs data/IA/analytics. Leurs évaluations montrent où l’expérience est plus faible, même si l’orchestration commerciale reste largement utilisée.

Ces évaluations comptent, car une perception favorable des plateformes actuelles coexiste avec des projets de continuer à faire évoluer le stack. VB Pulse/VB Intelligence a constaté que plus des deux tiers des répondants s’attendent à changer de plateforme dans l’année, avec des échéances réparties sur les 12 prochains mois.

Ces projets à court terme transforment la pluralité des plateformes en enjeu d’architecture. Les entreprises combinent couramment des produits d’orchestration commerciaux, et doivent donc décider comment le contrôle fonctionnera à l’échelle du stack ainsi constitué. À mesure que les produits changent, la question devient de savoir où ce contrôle doit résider.

La pluralité devient un choix d’architecture

Les stacks actuels montrent à quel point le chevauchement existe déjà. VB Pulse/VB Intelligence a constaté que Microsoft AI Foundry/Copilot Studio et l’Agents SDK d’OpenAI étaient chacun présents dans plus des deux tiers des entreprises étudiées, tandis que Claude Platform d’Anthropic bénéficie aussi d’un déploiement important. L’orchestration personnalisée développée en interne ajoute des composants détenus par l’entreprise aux côtés de systèmes fournisseurs qui restent en usage.

Ces stacks incluent aussi Enterprise Agent Platform de Google, LangChain/LangGraph, Salesforce Agentforce, Amazon Bedrock et LlamaIndex. Leur coexistence compte, car l’orchestration détermine comment les modèles, les outils et les agents se connectent, ainsi que la manière dont l’exécution est gérée. Dès lors que plusieurs systèmes d’orchestration interviennent, l’entreprise doit décider quels contrôles relèvent de chaque plateforme et lesquels doivent fonctionner à travers l’ensemble.

Cette décision crée un rôle pour un control plane, la couche qui gouverne l’exécution à travers les systèmes concernés. Un control plane hybride peut couvrir plusieurs plateformes, modèles et agents tout en ajoutant des contrôles personnalisés là où l’entreprise en a besoin. Séparer certaines responsabilités d’une plateforme de workflow donnée permet à l’organisation de maintenir ces responsabilités stables à mesure que son stack évolue.

Les prévisions de VB Pulse/VB Intelligence pour la fin 2026 rendent cette orientation plus explicite. Une majorité, soit 53%, s’attend à ce que son control plane principal soit hybride, tandis que des groupes plus restreints anticipent des dispositifs gérés par le fournisseur, personnalisés ou abstraits à l’extérieur.

L’éventail des dispositifs attendus montre que les entreprises choisissent activement où doit se situer l’autorité d’orchestration. Un control plane géré par le fournisseur séduit certaines organisations, tandis que d’autres prévoient de posséder le leur ou d’utiliser une couche externe séparée des fournisseurs de modèles. L’hybride est le dispositif attendu le plus important, mais plusieurs modèles de contrôle restent activement utilisés.

Les évaluations en cours élargissent encore ce choix, car les entreprises examinent de nouvelles options alors que plusieurs produits se chevauchent déjà dans les stacks déployés. Cette réflexion peut conduire à un ajout, au remplacement d’un composant ou à un changement d’architecture plus large.

Le composant personnalisé rend la question des frontières particulièrement concrète. Les entreprises qui ajoutent une orchestration interne à des plateformes fournisseurs prennent en charge certaines responsabilités tout en continuant à s’appuyer sur des produits commerciaux. Pour une équipe d’ingénierie ou de plateforme, la question pratique est de savoir quelles fonctions doivent rester stables lorsque le modèle sous-jacent, le service d’orchestration ou le fournisseur change.

La raison la plus forte de garder un contrôle portable tient à ce que les entreprises cherchent à optimiser

Cette question de frontière mène directement aux critères d’achat, car VB Pulse/VB Intelligence a constaté que les acheteurs accordent le plus grand poids à la flexibilité. La sécurité et les permissions, la fiabilité en production et le contrôle de l’exécution des agents viennent ensuite, tandis que la gravité du modèle renvoie à l’alignement natif avec un modèle de base de premier plan.

Ces priorités deviennent plus précises lorsque les équipes identifient des problèmes pendant la sélection de la plateforme. Les limites en matière de sécurité et de gestion des permissions arrivent en tête des préoccupations, suivies par l’enfermement propriétaire, la visibilité et l’observabilité limitées, ainsi que le manque de flexibilité des modèles ou des outils.

L’observabilité signifie la capacité à inspecter ce que font les agents pendant leur exécution, afin que les équipes puissent diagnostiquer leur comportement ou intervenir. Cette capacité relie les préoccupations de sélection à la question d’architecture, car les politiques d’entreprise en matière de sécurité, de permissions et de visibilité sur l’exécution peuvent devoir survivre lorsque les charges de travail passent d’une plateforme à une autre. Des contrôles portables donnent aux équipes un moyen de préserver ces politiques à travers un stack en évolution.

VB Pulse/VB Intelligence a constaté que les dépenses se déplacent vers ces mêmes exigences. Le monitoring et le debugging représentent désormais 31% des dépenses d’orchestration, l’application de la sécurité et des permissions 30%, et les outils de workflow 19%. Lors de la précédente vague de VentureBeat, un mois plus tôt, les outils de workflow dominaient encore clairement les dépenses d’orchestration. Ce déplacement montre que l’investissement passe de la connexion des étapes de workflow à la capacité de voir et de contraindre ce qui se produit pendant l’exécution de ces étapes.

Les priorités d’optimisation montrent où les équipes appliquent cet investissement. VB Pulse/VB Intelligence a constaté que la fiabilité de l’achèvement des tâches arrive en tête à 30%, suivie par la gestion des workflows en plusieurs étapes à 27%, la productivité des développeurs à 23%, la stabilité opérationnelle à 13% et l’expérience utilisateur final à 7%. Un workflow d’agent réussi dépend aujourd’hui fortement de la capacité à mener de façon fiable une tâche en plusieurs étapes jusqu’à son terme. La simplicité du développement et l’expérience utilisateur pourraient gagner en importance à mesure que ces systèmes se stabilisent, mais l’effort d’ingénierie se concentre aujourd’hui plus profondément dans l’exécution.

Ces choix transforment la pluralité des plateformes en problème d’exécution autant qu’en choix d’achat. Les équipes doivent appliquer les permissions, inspecter l’exécution et maintenir la fiabilité des workflows lorsque plusieurs plateformes interviennent. Une plateforme bien notée peut rester dans le stack tandis que l’entreprise conserve certains contrôles portables à l’échelle du système plus large.

Les dépenses incontrôlées des agents font du contrôle architectural une exigence opérationnelle

Le contrôle de l’exécution devient immédiat lorsqu’un agent peut dépenser de l’argent pendant qu’il s’exécute. VB Pulse/VB Intelligence a constaté qu’une entreprise sur cinq ne peut pas arrêter en temps réel les dépenses d’un agent incontrôlé. Comme un agent peut continuer à consommer des tokens et à invoquer des modèles avant qu’un humain n’examine le coût qui en résulte, les garde-fous financiers doivent opérer dans le chemin d’exécution et interrompre ce comportement.

Les entreprises utilisent plusieurs mécanismes pour rendre cette intervention possible. Des plafonds budgétaires intégrés ou des mécanismes de throttling permettent à une plateforme d’imposer un plafond ou de ralentir l’activité, tandis qu’un middleware gateway ou proxy personnalisé peut intercepter un agent au passage des requêtes. Le routage dynamique peut orienter les tâches lourdes ou coûteuses vers des modèles moins chers à mesure que les conditions évoluent, faisant du choix du modèle un élément du contrôle financier en temps réel.

Le monitoring réactif définit la faille de contrôle restante. Les équipes qui s’appuient uniquement sur des logs a posteriori peuvent examiner les dépenses après l’exécution, mais elles ne disposent d’aucun kill switch en temps réel pour arrêter les coûts pendant qu’ils s’accumulent. Cette limite fait du contrôle financier une exigence d’architecture, car l’observation après exécution ne peut pas remplir la même fonction qu’une intervention pendant l’exécution.

Les méthodes de contrôle dissocient aussi l’économie de l’achat de l’économie du runtime. Le coût total de possession ne représente que 4% des critères d’achat, alors même que les entreprises consacrent encore des efforts d’ingénierie aux plafonds, au throttling, aux gateways, au routage et au monitoring. Les dépenses en runtime peuvent évoluer dynamiquement pendant l’exécution d’un agent, ce qui exige des contrôles capables de réagir sur la même échelle de temps.

Les garde-fous natifs restent importants dans cette conception plus large. Les limites budgétaires intégrées arrivent en tête des méthodes individuelles de contrôle des dépenses à 30%, ce qui montre que les entreprises utilisent les fonctionnalités des fournisseurs en complément de couches personnalisées. Une limite native peut protéger l’exécution au sein de sa plateforme, tandis que les gateways, le routage et d’autres contrôles peuvent couvrir les frontières que l’entreprise a choisi de gérer elle-même.

La taille de l’entreprise ne suffit guère à éliminer le problème d’intervention. VB Pulse/VB Intelligence a constaté que parmi les entreprises comptant au moins 10 000 employés, 18% n’ont encore qu’un contrôle financier réactif, contre 23% des organisations plus petites. Davantage de personnel et de ressources organisationnelles ne fournissent pas à eux seuls la capacité d’interrompre en temps réel les dépenses des agents, de sorte que les grandes entreprises doivent elles aussi concevoir et instrumenter explicitement cette capacité.

Les mécanismes de dépense montrent que ces contrôles sont déjà attachés aux charges de travail en cours d’exécution. Les équipes construisent des middlewares proxy spécifiquement pour intercepter les agents incontrôlés, orientent les tâches coûteuses vers des modèles moins chers et examinent les logs a posteriori là où les contrôles en direct n’ont pas encore été mis en œuvre. La gouvernance financière relève donc de l’architecture d’exécution, où elle peut agir pendant qu’un agent consomme des ressources.

Les entreprises construisent le control plane avant l’autonomie des agents

Ces contrôles d’exécution arrivent alors que l’autonomie avancée des agents reste peu courante. Les répondants décrivent des déploiements à plusieurs niveaux, allant des chatbots et assistants de base jusqu’à la véritable orchestration, aux pipelines multi-agents complexes et aux systèmes avancés et largement autonomes.

Cette répartition donne au terme « agent » une valeur limitée comme mesure de la maturité opérationnelle, car des systèmes portant cette étiquette peuvent accomplir des volumes très différents de travail indépendant en plusieurs étapes. La progression va des chatbots et assistants de base aux systèmes qui orchestrent réellement le travail, puis aux pipelines multi-agents complexes et aux systèmes largement autonomes. Les exigences du control plane doivent donc refléter ce que font réellement les systèmes déployés.

L’enquête Pulse de juin de VB a mis en évidence le même écart de maturité sous un autre angle. Quelque 71% ont déclaré qu’un quart ou moins de leurs « agents » déployés pouvaient accomplir de manière autonome un travail en plusieurs étapes, et seul un dixième a indiqué avoir déployé des agents à grande échelle. Ces résultats montrent que l’investissement actuel dans le control plane précède une autonomie élevée généralisée, les équipes préparant l’infrastructure à une plus grande complexité d’exécution et à un déploiement plus large.

Ce calendrier change la manière dont les équipes doivent juger les choix d’infrastructure à court terme. La visibilité cross-platform, les permissions et l’intervention financière peuvent dépasser ce qu’exigent aujourd’hui des déploiements encore dominés par les assistants, mais ces fondations deviennent plus difficiles à modifier une fois que des workflows autonomes se répartissent sur plusieurs produits. Les 53% qui s’attendent à des control planes principaux hybrides d’ici fin 2026 montrent que les entreprises mettent en place ces frontières alors que la maturité des agents est encore en développement.

Ces frontières déterminent quelles responsabilités évoluent avec une plateforme d’orchestration et lesquelles restent applicables malgré les changements de plateforme. Certaines responsabilités peuvent vivre chez un fournisseur, d’autres peuvent être appliquées via une infrastructure personnalisée, et d’autres encore peuvent couvrir plusieurs fournisseurs via un control plane hybride. Une forte satisfaction à l’égard des produits commerciaux peut coexister avec une visibilité indépendante, des permissions, la portabilité, des contrôles d’exécution et des garde-fous de dépense en temps réel, tandis que l’usage généralisé de contrôles financiers natifs maintient les fonctions gérées par les fournisseurs comme une couche importante.

Pour les équipes qui planifient le prochain changement de plateforme, cette répartition des responsabilités constitue la décision d’architecture durable. Les contrôles requis doivent rester applicables lorsque le produit ou le modèle sous-jacent change, ce qui fait de leur emplacement une partie intégrante de la conception de la plateforme elle-même.

Points clés à retenir pour les dirigeants

• Concevoir pour la pluralité des plateformes : L’entreprise médiane exploite déjà trois plateformes d’orchestration, et plus des deux tiers s’attendent à un changement de plateforme dans l’année. Les équipes d’architecture peuvent maintenir la portabilité des contrôles critiques afin que les changements de fournisseur ou de modèle n’imposent pas une refonte de la gouvernance.
• Définir la frontière du control plane : Les control planes hybrides constituent le modèle attendu dominant pour la fin 2026, à 53%. Les équipes plateforme peuvent décider quelles permissions, quelle visibilité et quels contrôles d’exécution relèvent des plateformes fournisseurs et lesquels doivent couvrir l’ensemble du stack.
• Donner la priorité à des contrôles d’exécution portables : La flexibilité arrive en tête des critères d’achat à 29%, tandis que la sécurité, l’enfermement propriétaire et l’observabilité figurent en bonne place parmi les préoccupations liées aux plateformes. Les entreprises peuvent préserver ces capacités à travers des plateformes changeantes grâce à des politiques partagées de sécurité, de monitoring et d’exécution.
• Placer les garde-fous financiers dans le chemin d’exécution : Une entreprise sur cinq ne peut pas arrêter en temps réel les dépenses incontrôlées d’un agent. Les équipes d’ingénierie et FinOps peuvent utiliser des plafonds budgétaires, le throttling, des contrôles de gateway et le routage dynamique des modèles pour intervenir pendant que les coûts s’accumulent.
• Construire les contrôles avant une autonomie accrue : Seuls 2% déclarent que 76% à 100% de leurs systèmes sont avancés et largement autonomes, tandis que la plupart des déploiements restent à des stades de maturité plus précoces. Les entreprises peuvent mettre en place dès maintenant une gouvernance cross-platform avant que les workflows autonomes ne deviennent plus complexes et plus répandus.