Avec 35 millions de dollars, SAPIOM veut devenir le contrôleur de gestion des agents IA
📩 Pour nous contacter: redaction@fw.media
Les agents IA peuvent enchaîner des dizaines d’appels de modèles, utiliser des outils externes, acheter des services et recommencer plusieurs fois une opération sans que l’entreprise sache précisément ce que chaque mission lui a coûté. Alors que les budgets consacrés à l’intelligence artificielle subissent leurs premiers audits, une nouvelle couche d’infrastructure, à l’instar de SAPIOM, cherche à attribuer, encadrer et optimiser ces dépenses.
- Le coût réel d’un agent IA ne se limite pas au prix des tokens : il comprend les modèles, les outils, les reprises, les contrôles humains et les erreurs. L’indicateur pertinent devient donc le coût d’une tâche correctement accomplie.
- SAPIOM veut attribuer chaque dépense à une exécution précise, appliquer des budgets et des permissions avant l’action, puis orienter chaque appel vers le modèle offrant le meilleur compromis entre coût, qualité et fiabilité.
- Cette discipline d’« AgentOps » devient nécessaire : selon KPMG, seuls 7 % des dirigeants déclarent un ROI établi pour leur IA, tandis que 42 % ne disposent que d’une visibilité partielle sur leurs dépenses.
- Après avoir levé 35 millions de dollars, pour un total annoncé de 50 millions, SAPIOM doit encore démontrer que cette couche de contrôle peut rester indépendante face à OPENROUTER et aux fonctions progressivement intégrées par AWS, MICROSOFT, GOOGLE, ALIBABA et TENCENT.
Ainsi à la question « combien d’agents ont travaillé hier et combien ont-ils coûté ? » les réponses tiennent souvent en un seul chiffre, correspondant à un nombre de tokens, sans que personne ne sache exactement quels agents ont généré cette dépense, quelles tâches ont abouti, où les exécutions se sont interrompues ni combien de fois certaines étapes ont été relancées.
C’est ce à quoi est réduit la dimension économique de nombreux projets d’IA agentique : l’entreprise connaît le montant débité, parfois avec une précision admirable jusqu’au dernier token, mais elle peine encore à établir ce qu’elle a réellement acheté.
Cette difficulté pourrait paraître secondaire tant que les agents restent confinés à des démonstrations ou des expérimentations, mais elle devient autrement plus sérieuse lorsqu’ils fonctionnent en continu, mobilisent plusieurs modèles, appellent des moteurs de recherche, exécutent du code, accèdent à des bases de données ou achètent des services sans la moindre intervention humaine. Le logiciel se transforme alors en consommateur autonome de ressources facturées à l’usage, où chaque décision a un prix, et chaque erreur aussi.
Le token ne suffit plus à raconter la dépense
Si le prix du million de tokens reste l’indicateur étalon de l’économie de l’IA générative, il décrit mal le coût réel d’un agent. Ainsi une mission apparemment simple peut commencer par un appel destiné à interpréter la demande, se poursuivre par une recherche documentaire, mobiliser un second modèle pour analyser les résultats, solliciter un outil spécialisé, pour revenir au modèle initial afin de produire la réponse finale. Si l’une de ces étapes échoue, l’agent peut modifier son plan et recommencer, vous voyez vite où je veux en venir.
D’autant qu’à cette consommation s’ajoutent les tokens de raisonnement, la conservation du contexte, les bases vectorielles, le stockage, les environnements d’exécution, les API tierces et, dans certains cas, les paiements réalisés pour accéder à une donnée ou à un contenu. Et chacun sait, les coûts les moins visibles sont souvent les plus difficiles à maîtriser.
Quand une application traditionnelle renvoie généralement une erreur, un agent, lui, peut tenter de la résoudre, ce qui constitue précisément l’une de ses qualités, mais cette persévérance logicielle a un coût et chaque nouvelle tentative ouvre une ligne supplémentaire sur la facture.
Le coût qu’il convient de prendre en compte, n’est donc plus celui d’un appel isolé et de sa suite logique, mais celui d’une tâche correctement accomplie. Un modèle facturé dix fois moins cher n’apporte aucune économie s’il doit être interrogé quinze fois, à l’inverse, un modèle frontière peut rester économiquement justifié lorsqu’une réponse exacte dès la première tentative évite une succession d’échecs coûteux.
La bonne équation doit ainsi rapprocher le coût total des modèles, outils, reprises et contrôles du nombre de missions effectivement menées à leur terme. Le résultat est moins élégant qu’un tarif par million de tokens, mais infiniment plus utile pour calculer une marge.
Donner une identité économique à chaque exécution
Fondée il y a onze mois par Ilan Zerbib, SAPIOM se présente comme une infrastructure de production pour agents IA. La startup affirme avoir traité plus de 270 millions de transactions et exécuter désormais plus de 100 000 agents par jour.
Petite précision, le terme « transaction » peut désigner un appel de modèle, une utilisation d’outil, une étape d’exécution ou une opération de paiement, et ne doit pas être confondu avec une mission complète. La proposition de valeur tient d’ailleurs moins au volume annoncé qu’à la manière dont SAPIOM souhaite le rendre intelligible.
Ainsi chaque exécution reçoit un identifiant auquel sont rattachés les différentes étapes, les modèles sollicités, les outils appelés, leur coût, leur durée, leur résultat et le nombre de tentatives nécessaires. Lorsqu’une mission échoue, l’entreprise peut localiser l’étape concernée, comprendre ce que l’agent a tenté et observer la manière dont il a réagi.
Cette traçabilité permet de passer d’une facture, où seul le nombre de ressources consommées par la plateforme (qu’il s’agisse d’Anthropic, OpenAI ou encore Google) est indiqué, à une analyse plus détaillée permettant de déterminer quel produit, quel client, quel processus ou quel centre de coûts en est à l’origine et de le rapprocher du chiffre d’affaires, des économies ou du temps humain épargné. Le nombre de tokens doit être lu comme une donnée technique parmi d’autres, et non un indicateur de performance économique.
Contrôler la dépense avant qu’elle ne se produise
Cela étant l’observabilité ne résout cependant qu’une partie du problème, car si le tableau de bord peut expliquer qu’un agent vient de dépasser son budget, l’argent, lui, a déjà été dépensé. SAPIOM veut donc intervenir au moment où l’agent tente d’agir, avant l’appel d’un modèle, l’utilisation d’un outil ou l’achat d’un service.
L’entreprise peut ainsi définir au préalable le mandat de l’agent : les modèles qu’il est autorisé à utiliser, les fournisseurs auxquels il peut transmettre des données, le montant maximal d’une mission, les outils accessibles et les opérations nécessitant une validation humaine.
La distinction avec un outil de monitoring classique est fondamentale. « L’observabilité indique ce qui s’est produit après l’action de l’agent ; SAPIOM détermine ce qu’il est autorisé à faire avant qu’il n’agisse », explique son fondateur Ilan Zerbib. La startup cherche à transformer chaque dépense potentielle en décision controlée.
Cette logique peut être déclinée selon plusieurs degrés d’autonomie. Une action peu coûteuse et réversible peut être exécutée librement ; une dépense supérieure à un certain montant peut exiger une approbation ; l’accès à des données sensibles peut rester limité à certains modèles ou régions ; une succession anormale d’échecs peut déclencher un arrêt automatique. L’agent gagne en autonomie, mais celle-ci reste bornée par un budget, des permissions et des règles d’escalade.
Réserver les modèles frontière aux tâches qui les justifient
La seconde source d’économie réside dans le choix du modèle. De nombreux agents sont développés autour du modèle le plus performant disponible au moment de leur conception, puis continuent de l’utiliser pour l’ensemble de leurs opérations. Une classification élémentaire, une extraction de données et un raisonnement complexe se retrouvent ainsi facturés au même tarif, comme si une entreprise mobilisait systématiquement son cadre le plus expérimenté pour ouvrir le courrier.
SAPIOM Router cherche à sélectionner, pour chaque appel, le chemin d’exécution offrant le meilleur compromis entre coût, qualité, latence, disponibilité et politique interne. Une tâche simple peut être envoyée vers un modèle ouvert moins cher, tandis qu’une opération complexe ou sensible reste confiée à un modèle frontière.
Le principe paraît évident, toutefois son exécution l’est beaucoup moins. Le routeur doit déterminer avant la réponse si un modèle sera capable de produire le niveau de qualité attendu. Une mauvaise décision peut réduire le prix de l’appel tout en augmentant le nombre de reprises, ou les contrôles humains. L’optimisation ne consiste donc pas à choisir mécaniquement l’option la moins chère, mais à estimer le coût complet d’un résultat qui soit satisfaisant.
Cette capacité dépend par ailleurs des évaluations réalisées sur les charges de travail réelles. Un modèle excellent sur un benchmark généraliste peut se révéler médiocre dans un processus métier particulier, tandis qu’un modèle plus modeste peut accomplir avec régularité une tâche fortement structurée. Plus une plateforme observe d’exécutions, d’erreurs et de corrections, plus elle peut, en théorie, améliorer ses décisions de routage.
C’est également là que SAPIOM espère construire une défense face à la banalisation rapide de cette fonction. OPENROUTER revendiquait en mai 2026 quelque 25 000 milliards de tokens traités chaque semaine et propose déjà un accès unifié à plus de 400 modèles. AMAZON a intégré le routage intelligent à Bedrock, MICROSOFT le développe dans Foundry, tandis que les routeurs open source permettent aux entreprises de construire leurs propres arbitrages. Le simple aiguillage des requêtes risque donc de devenir une fonctionnalité plutôt qu’un marché autonome.
Pour échapper à ce piège, SAPIOM associe son Router à Agent Studio, destiné à la construction, et surtout à Runtime, chargé de l’exécution, de la conservation de l’état, des reprises et de la traçabilité.
Empêcher les agents de recommencer indéfiniment
Un agent peut également faire exploser sa consommation parce qu’il ne sait pas s’arrêter. Lorsqu’un service externe ne répond pas, qu’une requête est mal formulée ou qu’une étape produit un résultat ambigu, le système peut modifier son approche, relancer l’outil, reconstituer son contexte et reprendre une partie du raisonnement.
Cette faculté d’adaptation distingue l’agent d’un workflow rigide, mais elle ouvre aussi la voie à des séquences coûteuses dont chaque étape paraît localement raisonnable, tandis que l’ensemble ne produit rien d’exploitable.
Le runtime doit donc appliquer des limites : nombre maximal d’étapes, plafond de reprises, durée maximale, budget par mission, modèle de secours et escalade vers un humain après plusieurs échecs. Il doit également préserver l’état de l’exécution afin que l’agent reprenne au point de rupture au lieu de recommencer toute sa mission.
Le pilotage des coûts rejoint ici l’ingénierie de la fiabilité. Une reprise intelligente peut apporter davantage d’économies qu’une baisse du tarif des tokens, de même qu’un arrêt anticipé peut valoir mieux qu’une dixième tentative obstinée.
Du FinOps à l’AgentOps
De nombreuses entreprises commencent à mesurer l’ampleur du problème. Dans son Global AI Pulse publié en juin 2026, KPMG indique que seulement 7 % des 2 145 dirigeants interrogés déclarent avoir établi un retour sur investissement de leur IA. Quarante-deux pour cent ne disposent que d’une visibilité partielle sur leurs dépenses, 23 % rencontrent des difficultés avec les coûts fondés sur l’usage et un tiers peine à comprendre les structures tarifaires liées aux tokens.
L’étude relève également que les organisations disposant d’une forte visibilité sur leurs coûts sont cinq fois plus nombreuses à déclarer un ROI établi. La corrélation ne démontre pas à elle seule que le tableau de bord crée la rentabilité, mais elle rappelle une règle assez robuste du contrôle de gestion : ce que l’entreprise ne parvient pas à attribuer finit rarement par être optimisé.
Une discipline d’AgentOps commence ainsi à se dessiner à la rencontre du FinOps, de la sécurité et des opérations logicielles. Le CTO ne peut plus piloter seul une dépense qui affecte directement la marge ; le directeur financier ne peut pas l’analyser sans comprendre la mécanique des exécutions ; le CISO doit contrôler les accès et les données ; les métiers doivent définir le résultat attendu.
Chaque agent doit alors recevoir un propriétaire, un budget, un objectif et des conditions d’arrêt. Les indicateurs doivent suivre le coût moyen par tâche réussie, le taux de réussite au premier essai, le nombre de reprises, la part des appels envoyés vers des modèles frontière, la proportion de missions nécessitant une intervention humaine et, surtout, la marge conservée après consommation d’IA.
Une nouvelle infrastructure, ou une fonction promise au cloud ?
SAPIOM a levé 35 millions de dollars lors d’une Série A menée par DRAGONFLY, six mois après un tour d’amorçage annoncé à 15 millions, portant son financement total communiqué à 50 millions. ACCEL, ANTHROPIC, OKTA VENTURES, MENLO VENTURES et ARRAY VENTURES figurent notamment parmi ses investisseurs.
Parmi ses challenges, SAPIOM doit démontrer que sa couche de contrôle peut demeurer indépendante. AWS AgentCore rassemble déjà runtime, identité, permissions et observabilité ; MICROSOFT Foundry associe hébergement, modèles, contrôle d’accès et suivi des agents ; GOOGLE intègre à sa plateforme des protocoles de paiement agentique. En Chine, ALIBABA CLOUD et TENCENT intègrent directement ces fonctions à leurs plateformes.
Notre politique éditoriale concernant l'intelligence artificielle
Les analyses et articles sont rédigées par des journalistes.
L'IA peut être utilisée comme outil d'assistance (traduction, synthèse, recherche documentaire ou amélioration stylistique).
Les faits, chiffres et analyses sont systématiquement vérifiés et validés par la rédaction.
Les illustrations générées ou modifiées par IA sont explicitement signalées.
