Coût des agents IA : comparer prix par action et runtime auto-hébergé

En bref : La facturation à l’action signifie que vous payez davantage à mesure que votre agent fonctionne mieux. Le vrai coût se résume à savoir si l’usage explose avec le succès, aux factures hors grille liées à l’extraction des données et à l’enfermement, et à l’endroit où se situe le seuil de rentabilité de l’auto-hébergement.

En fin de trimestre, le directeur financier ouvre la facture de la plateforme d’agents et reste interdit : c’est quatre fois le budget.

Personne n’a dépensé n’importe comment — au contraire : l’agent du service client a trop bien réussi. Faisons le calcul : avant la mise en service, l’équipe traitait environ 5 000 tickets par jour ; après, l’efficacité par personne a grimpé et le volume pris en charge a doublé pour atteindre environ 10 000. Et la plateforme facture à l’action : traiter un ticket, c’est en coulisse consulter le client, consulter la commande, consulter l’historique, consulter la base de connaissances, lancer un remboursement, envoyer une notification — sept ou huit actions au bas mot. Un calcul grossier : 10 000 tickets × 7 actions × 0,10 $ ≈ 7 000 $ par jour, soit environ 2,5 millions de dollars par an. Or le budget avait été estimé au doigt mouillé sur « 5 000 tickets, un peu moins d’actions chacun ».

Le plus ironique est ici : plus ce projet réussit, plus cette facture fait peur. Si bien que le premier réflexe du conseil d’administration n’est pas de célébrer une efficacité doublée, mais de demander « peut-on réduire un peu la consommation ? » — une réussite qui aurait dû s’étendre se voit freinée par le modèle de facturation. Le ROI n’est pas encore réellement concrétisé que la mise à l’échelle est déjà bloquée par l’angoisse du coût.

Dix centimes, multipliés par un nombre qui enfle

L’Agentforce de Salesforce a lancé la facturation Flex : 0,10 $ par action. Pris isolément, ce chiffre est si dérisoire qu’il endort la vigilance.

Mais c’est précisément là que la facturation d’un agent doit éveiller le plus de méfiance — elle arrime le coût au volume, alors que tout l’intérêt d’un agent est d’agir de façon autonome, à haute fréquence, sans relâche. Et plus un agent est autonome, plus il déclenche d’actions intermédiaires pour mener à bien une seule tâche : une requête du type « fais-moi le point sur la situation de ce client » peut, en coulisse, représenter une dizaine d’appels d’outils, que vous ne pouvez ni dénombrer à l’avance ni vraiment plafonner. D’autres plateformes facturent au token, encore plus difficile à prévoir que l’action — pour une même tâche, le modèle réfléchit quelques étapes de plus, et la facture s’allonge d’autant. La comparaison rapportée publiquement n’a rien d’exagéré : à consommation équivalente, le coût annuel en mode SaaS peut dépasser 2 millions de dollars, tandis qu’un déploiement auto-hébergé fonctionnellement équivalent, licence plus infrastructure, se situe autour de 250 000 dollars — un ordre de grandeur d’écart.

Le paiement à l’usage n’est-il pas plus économique et plus souple ?

Il faut ici prendre au sérieux une objection, car dans bien des cas elle est juste : le paiement à l’usage n’a aucun investissement initial, vous payez moins si vous consommez moins, le fournisseur exploite à votre place, vous ne payez que pour la valeur produite — cette logique a été maintes fois validée à l’ère du cloud, alors pourquoi cesserait-elle de tenir avec les agents ?

Elle tient, mais à une condition : que le « volume » dont le coût dépend soit découplé de votre valeur, ou faiblement corrélé. Le stockage cloud facturé au Go ne pose pas problème, car stocker plus signifie généralement une activité plus grosse, capable de payer ; les deux progressent à peu près de concert.

L’agent brise cette condition. Il facture au « nombre d’actions », et ce nombre explose précisément avec le degré d’autonomie et le degré de réussite — plus vous voulez qu’il travaille pour vous, et mieux, plus il déclenche d’actions, plus la facture grimpe. Cela devient une « taxe sur le succès » : plus vous optimisez agressivement (le faire vérifier une étape de plus, recouper une fois de plus pour gagner en qualité), plus le taux d’imposition monte. Le logiciel traditionnel facture au siège : utilisez-le aussi intensément que vous voulez, le coût est plafonné ; la facturation à l’action, elle, vous fait payer d’autant plus que vous faites mieux. L’intuition de l’ère cloud, « à l’usage donc équitable », tombe en panne sur un corps d’exécution qui déclenche de lui-même d’innombrables actions intermédiaires et que vous encouragez à en faire plus.

À partir de quel volume faut-il tourner soi-même ? Calculons le point de croisement

Ne vous arrêtez pas à « ça dépend ». Avec les deux chiffres du directeur financier, on peut estimer ce point de croisement.

Du côté auto-hébergé, supposons un coût annuel fixé à environ 250 000 $ (licence + infrastructure + une part d’exploitation répartie) ; il ne varie quasiment pas avec le nombre d’appels. Du côté facturation à l’action, c’est 0,10 $ × nombre d’actions. En égalant les deux :

250 000 $ = 0,10 $ × nombre d'actions annuel
nombre d'actions annuel ≈ 2,5 millions  →  environ 6 800 actions par jour

Autrement dit, dès que vos actions d’agent quotidiennes dépassent l’ordre de 7 000, la facturation à l’action commence à coûter plus cher que l’auto-hébergement, et l’écart ne fait ensuite que se creuser. Revenons à ce directeur financier : ses 70 000 actions par jour (10 000 tickets × 7) sont très au-dessus du point de croisement — voilà pourquoi la facture s’est envolée à 2,5 millions. Sa souffrance n’est pas un accident : à ce volume, le modèle de facturation l’avait placé du mauvais côté de la courbe.

Vous pouvez appliquer ce calcul directement à vos chiffres : multipliez le volume d’interactions quotidien de l’équipe par « combien d’actions environ par interaction », comparez à l’ordre de grandeur de 7 000, et vous saurez de quel côté du point de croisement vous vous situez.

Trois modèles de coût, étalés côte à côte

Modèle	Représentant	De quoi le coût dépend	Prévisibilité	Où sont les données
À l’action / au token	Agentforce Flex (0,10 $/action)	Enfle linéairement, voire supra-linéairement, avec le nombre d’actions	Mauvaise, plus c’est bon plus c’est cher	Cloud du fournisseur
Au siège	La plupart des solutions type Copilot	Croît avec le nombre de personnes, plafonné mais pas bon marché par tête	Moyenne, mais déconnectée de l’autonomie de l’agent	Cloud du fournisseur
Runtime auto-hébergé	ObjectStack / ObjectOS	Suit l’infrastructure, largement découplé de l’usage	Bonne, la courbe ne bouge presque pas quand l’usage double	Votre propre infrastructure

Le modèle au siège paraît stable, mais il porte une contradiction intrinsèque : la valeur de l’agent est de remplacer une masse de tâches répétitives sans occuper de siège, et pourtant vous payez toujours « à la tête » — la dimension de facturation et la dimension de valeur ne coïncident pas. L’auto-hébergement, lui, change toute la structure de coût : vous payez pour le moteur d’exécution et votre propre puissance de calcul ; l’usage passe de dix mille à cent mille, la facture ne décuple pas pour autant.

D’abord une douche froide : l’auto-hébergement n’est pas moins cher partout

Ne prenez pas l’économie apparente de l’auto-hébergement pour une vérité universelle. Elle a une plage de validité bien définie ; hors de cette plage, elle ne tient plus.

Ce chiffre de tête à 250 000 $ n’inclut pas l’humain. L’auto-hébergement signifie qu’il vous faut des gens pour exploiter, appliquer les correctifs, garantir la disponibilité — si vous n’avez pas d’équipe plateforme, ce coût humain caché peut grignoter une bonne partie de l’avantage comptable, et repousser le point de croisement ci-dessus vers la droite. De plus, il a des coûts fixes : infrastructure et exploitation se paient d’avance, sans grand lien avec l’usage.

Donc, au stade d’un usage très faible, très peu fréquent, purement expérimental, le paiement à l’usage est au contraire plus souple et moins cher — vous n’avez pas à entretenir une équipe pour un runtime quasi inactif. L’avantage de l’auto-hébergement ne se concrétise qu’une fois que vous êtes sûr de monter à l’échelle.

La facture vraiment chère ne figure pas sur la grille tarifaire

Même une fois passé du côté où l’auto-hébergement est plus avantageux, ne comparer que la facture mensuelle sous-estime encore le problème. Avant de choisir un mode de facturation, ce qu’il faut vraiment calculer, ce sont trois factures, dont deux ne figurent pas sur la grille tarifaire :

La facture d’usage : le coût va-t-il exploser avec le succès ? C’est la facture x4 du directeur financier — votre usage est-il corrélé positivement au succès de l’agent. Si oui, la facturation à l’action est un piège.
La facture de conformité : le coût de la sortie de territoire des données. Le SaaS à l’action ou au siège signifie que les données métier affluent en continu vers le cloud du fournisseur. Dans le contexte de l’EU AI Act et des exigences de souveraineté, une seule violation de résidence des données peut coûter plus cher que de nombreuses années de licence.
La facture de verrouillage : le coût de ne plus pouvoir partir. Quand la définition métier, les processus, les permissions poussent tous dans une plateforme, le coût de migration croît à intérêts composés avec la durée d’utilisation. Vous croyiez payer pour un logiciel, vous payez en réalité une caution pour « ne plus pouvoir partir ».

En calculant ces trois factures ensemble, le maigre avantage apparent du « dix centimes par action » est vite englouti.

Pourquoi l’auto-hébergement maîtrise ces trois factures à la fois

Le cœur tient en une phrase : vous payez pour le moteur qui fait tourner cette définition métier, et non pour le nombre de fois où elle a été appelée. D’où :

Coût découplé de l’usage. ObjectOS exécute la définition métier sur vos propres serveurs ; peu importe combien de fois l’agent appelle des outils gouvernés, ce n’est pas facturé à l’appel — le coût est déterminé par l’infrastructure, prévisible, planifiable. Le volume de tickets de ce directeur financier double, la facture ne bouge presque pas.
Les données ne sortent pas du territoire. Objets, permissions, preuves d’audit restent sur votre propre infrastructure ; le risque de conformité et le coût de sortie des données baissent de concert.
Pas de verrouillage. La définition métier est une métadonnée dans votre dépôt sous protocole ouvert (Apache 2.0), diffable et migrable. Vous achetez le service du runtime, pas une caution pour « ne plus pouvoir partir ».

Conclusion

« 0,10 $ par action » est une étiquette de prix soigneusement conçue : quand vous démarrez et que votre usage est faible, elle paraît inoffensive ; quand vous réussissez vraiment et que l’usage décolle, elle montre les crocs. Revenons à ce directeur financier en fin de trimestre — sa facture n’a pas dérapé, elle est la conséquence inévitable de ce modèle de facturation : il vous tend la plus grosse des factures au moment où vous devriez le plus célébrer.

Pour calculer le coût d’un agent, ne regardez pas que le prix unitaire. Calculez ces trois factures — usage, conformité, verrouillage — puis comparez votre usage avec la formule du point de croisement. Une fois cela posé, l’intérêt de l’auto-hébergement n’est plus un slogan, mais une conclusion qui s’écrit dans le budget — et dont on sait aussi quand elle ne tient pas.

npm i -g @objectstack/cli && os start

Faites tourner un objet métier sur votre propre machine, faites-le appeler par un agent des milliers de fois de suite, puis regardez la facture — elle ne bougera pas, car il n’y a pas de ligne « 0,10 $ à chaque fois ».