Pourquoi le coût par exécution
remplacera la licence par siège

Le siège est une unité de mesure héritée du logiciel de bureautique. On comptait les utilisateurs parce qu'on ne savait compter que cela. Avec l'IA, cette unité devient absurde : elle facture une présence, pas une production. Le coût par exécution corrige cette erreur. Il mesure ce qui a réellement été fait — et ce que cela a réellement coûté.

01 — Le constatLa licence par siège mesure la mauvaise chose

Une licence par siège repose sur une hypothèse : la valeur est proportionnelle au nombre d'utilisateurs. C'était défendable pour un traitement de texte. Cela ne l'est plus pour un moteur d'IA, dont la valeur tient au volume et à la qualité des décisions produites, pas au nombre de badges actifs.

Le résultat est connu de toute direction financière. On paie pour des sièges sous-utilisés. On paie une capacité indépendamment de l'usage. Et l'on découvre, à la facture, que la dépense ne dit rien de ce qui a été produit. Combien a coûté la note d'arbitrage de mardi ? Quel rituel consomme le plus ? La licence par siège est incapable de répondre. Elle agrège tout dans un forfait opaque.

Cette opacité a un nom dans nos modèles : l'écart entre la capacité payée et la capacité exécutée. C'est le capital immobilisé qui ne produit rien. Plus la facture grossit, plus cet écart devient un angle mort budgétaire.

Ce que le siège rend impossible

Illustrons par un raisonnement simple. Une direction acquiert deux cents sièges d'un moteur d'IA. Le forfait est confortable, négocié au volume. Mais à l'usage, trente personnes seulement produisent l'essentiel des décisions, et l'une d'elles, sur un rituel critique, en produit à elle seule davantage que cent collègues réunis. Que dit la facture par siège de cette réalité ? Rien. Elle répartit un coût uniforme sur deux cents badges, alors que la valeur — et la consommation — sont radicalement concentrées.

Cette incapacité à relier le coût à l'usage a des conséquences au-delà du budget. Impossible de comparer deux rituels au mérite. Impossible de savoir si un rituel coûte plus qu'il ne rapporte. Impossible d'arbitrer finement, puisque tout est noyé dans un forfait. Le siège ne mesure pas seulement la mauvaise chose : il interdit les bonnes questions.

02 — Le mécanismeLe Cost per Run, ou la dépense au réel

Posons la taxonomie. Une inférence est l'unité atomique : une soumission à un moteur. Un run est un ensemble cohérent d'inférences — l'exécution complète d'un rituel, attachée à un Run Receipt unique. Le Cost per Run est le coût exact de chacune de ces exécutions, mesurable en temps réel.

La conséquence est immédiate. La dépense devient une fonction de l'usage, pas un palier fixe. Un rituel peu sollicité coûte peu. Un rituel critique, lancé mille fois, coûte mille fois son run — un coût connu à l'avance, ligne par ligne. La DSI ne pilote plus un abonnement global : elle pilote une structure de coût qu'elle peut décomposer par rituel, par domaine, par direction.

Une taxonomie qui rend le coût lisible

Pour piloter un coût, il faut d'abord savoir à quel niveau on le lit. Quatre échelons s'emboîtent. L'inférence est l'unité atomique — une sollicitation du moteur. Le run regroupe les inférences d'une exécution complète de rituel, attachée à un Run Receipt unique. Le projet rassemble les runs d'un même objectif métier sur une période. Le job, enfin, désigne l'ensemble des projets d'un domaine gouverné.

Cet emboîtement n'est pas une coquetterie de vocabulaire. Il permet de lire le coût à l'échelle où la décision se prend. Un ingénieur optimise au niveau de l'inférence ; un responsable de rituel raisonne au niveau du run ; un directeur métier arbitre au niveau du projet ; le comité exécutif pilote au niveau du job. La licence par siège, elle, n'offre qu'un seul niveau de lecture — le forfait global — qui ne correspond à aucune de ces décisions. Le Cost per Run, parce qu'il s'enracine dans l'inférence, se recompose à tous les étages supérieurs.

Ce déplacement répond à une objection fréquente : un coût variable serait moins prévisible qu'un forfait. C'est l'inverse. Un forfait masque la variabilité ; il ne la supprime pas. Le Cost per Run la rend visible et donc gouvernable. On peut plafonner, arbitrer, optimiser — précisément parce que l'on mesure.

03 — La preuveChaque coût est attaché à son run

Mesurer un coût ne suffit pas : il faut pouvoir le rattacher à ce qui l'a engendré. C'est là que la preuve native fait la différence. Le même Run Receipt qui certifie la décision en porte le coût. Le coût n'est pas une estimation a posteriori : c'est une donnée native du run.

Cette traçabilité du coût rend possible un raisonnement FinOps que la licence par siège interdit. On ne demande plus « combien coûte l'IA ? » mais « quel rituel produit le plus de valeur par euro dépensé ? ». La question devient enfin une question d'allocation de capital, pas de réduction de facture.

Cette bascule a un effet organisationnel discret mais profond. Tant que l'IA est un forfait, son coût est l'affaire d'une seule fonction — celle qui signe le contrat. Dès que le coût est attribué au run, il devient l'affaire de chaque direction, qui voit ce que ses propres rituels consomment et produisent. La responsabilité financière se distribue là où se prennent les décisions d'usage. Le coût n'est plus subi en central : il est arbitré au plus près du métier qui le génère.

04 — Le bénéficeUn coût qui devient un levier

Le passage au Cost per Run n'est pas qu'une économie. C'est un changement de nature du coût : d'une charge subie, il devient un levier piloté. Chaque fonction du comité exécutif y trouve sa prise.

• Pour la Finance. La dépense IA devient prévisible au geste près et imputable au centre de coût qui la génère. Le budget cesse d'être un forfait négocié pour devenir une structure pilotable, rituel par rituel.
• Pour la DSI. Le Cost per Run alimente le Cockpit : coûts, accès et algorithmes gouvernés depuis une interface unique. La fragmentation des abonnements laisse place à une structure de coût lisible.
• Pour le Métier. Le coût d'un rituel devient un argument d'arbitrage. On sait ce que coûte une décision certifiée — et on peut décider si elle vaut son prix, ce que le siège forfaitaire interdisait.
• Pour la Compliance. Le coût attribué est aussi une trace. Savoir qui a exécuté quoi, à quel prix, fait partie du même dossier de preuve que la décision elle-même.

05 — L'objection« Un coût variable n'est-il pas ingérable ? »

La direction financière soulève une objection légitime : un forfait, au moins, est connu d'avance. Un coût qui suit l'usage ne risque-t-il pas de déraper, de surprendre, d'échapper au contrôle budgétaire ? L'objection mérite mieux qu'une réassurance : elle mérite une démonstration.

D'abord, un forfait n'est prévisible qu'en apparence. Il fixe la dépense, pas la valeur. On sait ce que l'on paie ; on ignore ce que l'on obtient. Cette « prévisibilité » n'est que l'ignorance organisée de la variabilité réelle, qui existe pourtant — elle est simplement invisible. Le Cost per Run ne crée pas la variabilité : il la révèle, et c'est précisément ce qui la rend gouvernable.

Ensuite, un coût mesuré au run se pilote avec des instruments qu'un forfait interdit. On peut fixer des plafonds par rituel, déclencher une alerte au-delà d'un seuil, comparer le coût d'un run à la valeur qu'il produit. Le Taux d'Utilité Validée — la part de runs approuvés sans reprise — devient un levier direct : un rituel dont les runs sont souvent repris coûte cher pour rien, et on le sait immédiatement. La variabilité cesse d'être un risque subi pour devenir un paramètre réglé.

Enfin, l'expérience du Cercle Vertueux répond à la crainte d'emballement. Le coût unitaire d'un rituel gouverné ne croît pas avec l'usage : il décroît, à mesure que le Vault se densifie. La trajectoire naturelle d'un Cost per Run bien piloté n'est pas la dérive — c'est la baisse.

06 — La trajectoireDu siège au geste

Le marché du logiciel a déjà connu cette bascule. On a quitté la licence perpétuelle pour l'abonnement, parce que l'abonnement collait mieux à l'usage. L'IA pousse la logique un cran plus loin : du siège vers le run, de la présence vers la production. Ce n'est pas une mode tarifaire. C'est l'alignement, enfin, du prix sur la valeur.

Chaque étape de cette histoire a suivi la même logique : rapprocher l'unité facturée de l'unité de valeur. La licence perpétuelle facturait une possession ; l'abonnement, un accès ; le siège, une présence. Aucune de ces unités ne mesurait la production. Le Cost per Run franchit ce dernier pas. Il ne facture ni la possession, ni l'accès, ni la présence : il facture le geste qui crée la valeur. C'est l'aboutissement d'une trajectoire, pas une rupture isolée.

La bascule ne se décrète pas : elle se mesure. Le point de départ est un rituel existant, dont on commence à mesurer le Cost per Run réel. La comparaison avec la fraction de licence qu'il consomme suffit, le plus souvent, à rendre la conversation évidente. Le geste est moins cher que le siège — et infiniment plus pilotable.

La licence par siège a mesuré qui pouvait travailler. Le Cost per Run mesure ce qui a été produit. Entre les deux, il n'y a pas une remise. Il y a un changement d'époque comptable.