Comment choisir entre tarification à l’usage et forfaits IA

La tarification de l’IA évolue, mais l’économie de l’abonnement perdure

L’IA change la manière dont les éditeurs de logiciels facturent leurs clients. Pourtant, l’abandon progressif des licences par utilisateur a produit un résultat surprenant : environ 80 % des éditeurs qui introduisent une tarification de l’IA choisissent des dispositifs de capacité, dans lesquels les clients achètent un volume défini, quelle que soit leur consommation finale. Parallèlement, environ 20 % des éditeurs de logiciels nativement IA s’appuient encore principalement sur des licences traditionnelles par utilisateur.

Ces constats proviennent de l’analyse de Bain & Company de juin 2026 sur les tarifs publiquement disponibles d’environ 200 entreprises B2B SaaS. Ils remettent en cause l’idée selon laquelle la tarification des logiciels passerait progressivement des licences par utilisateur à la consommation, puis aux résultats métier. Les éditeurs mesurent de plus en plus les ressources consommées par l’IA, le travail qu’elle accomplit et les résultats métier qu’elle produit. Mais beaucoup commercialisent encore ces capacités dans le cadre d’engagements d’entreprise familiers.

Dans son Bain Brief, « AI Pricing: A Reality Check on Effort, Usage, and Outcomes », le cabinet examine deux décisions souvent traitées comme une seule : ce qui déclenche une facturation et la manière dont les clients s’engagent à la payer. La première détermine l’unité de tarification. Un éditeur peut facturer les ressources de calcul, le travail accompli ou des résultats métier mesurables. La seconde détermine la structure d’achat : les clients peuvent payer leur consommation réelle ou s’engager sur un volume prédéfini.

Ces choix sont indépendants. Un éditeur de logiciels peut introduire une unité de tarification à l’usage tout en conservant la prévisibilité des revenus associée aux abonnements. Pour les responsables technologiques qui décident comment monétiser l’IA, ces deux décisions comptent.

La tarification de l’IA va au-delà des licences par utilisateur

La tarification SaaS traditionnelle facture généralement les clients en fonction du nombre d’utilisateurs sous licence. L’IA complique cette approche, car deux utilisateurs peuvent générer des volumes de calcul très différents. La valeur qu’ils en retirent peut également avoir peu de rapport avec le nombre de personnes qui accèdent à l’application.

Ces différences poussent les éditeurs vers des unités de tarification fondées sur les tokens, les tâches réalisées et les résultats métier. Les éditeurs SaaS établis adoptent également des modèles hybrides qui combinent les licences existantes par utilisateur avec des droits supplémentaires liés à l’IA. Cela leur permet de facturer l’activité de l’IA tout en conservant les contrats d’abonnement que leurs clients utilisent déjà.

Bain avait identifié cette orientation dans un précédent Brief, « Per-Seat Software Pricing Isn’t Dead, but New Models Are Gaining Steam », publié l’automne dernier. Ses recherches ultérieures confirment que les licences par utilisateur restent commercialement pertinentes, même si l’IA modifie la relation entre les coûts logiciels et la valeur client.

Une grande partie de la confusion vient de la terminologie de tarification. Les éditeurs décrivent leurs produits comme fondés sur l’usage, la consommation ou les résultats, alors que ces termes peuvent renvoyer à des modalités de facturation différentes. Certains produits commercialisés autour des résultats facturent des activités réalisées, tandis que de nombreuses offres dites à l’usage exigent que les clients achètent de la capacité à l’avance et paient un supplément lorsqu’ils dépassent leur quota.

Pour les acheteurs, ces différences déterminent le degré de prévisibilité des dépenses et ce qui se passe lorsque la consommation est inférieure aux attentes. Pour les éditeurs, elles influent sur la stabilité des revenus, la couverture des coûts et l’exposition aux variations d’usage des clients. Évaluer la tarification de l’IA suppose donc de distinguer l’unité facturée de l’engagement qui encadre son achat.

Première décision : facturer l’effort, la production ou les résultats

La première décision de tarification consiste à déterminer quelle activité doit déclencher une facturation. Bain identifie trois grandes approches : la tarification fondée sur l’effort, sur la production et sur les résultats. Chacune mesure un aspect différent de ce que l’IA fournit et crée une relation différente entre la rémunération de l’éditeur et la valeur pour le client.

Parmi les entreprises nativement IA et les éditeurs SaaS établis fondés sur des licences par utilisateur qui introduisent des unités hybrides pour l’IA, la tarification fondée sur la production est la plus courante.

Ces pourcentages décrivent la population spécifiée d’entreprises nativement IA et à tarification hybride. Bain constate également peu de différences significatives entre les entreprises nativement IA et les éditeurs SaaS établis dans leur choix d’unités de tarification. La distinction la plus utile porte plutôt sur ce que les clients achètent et sur la place du logiciel dans leur workflow.

La tarification fondée sur l’effort mesure la consommation de ressources

La tarification fondée sur l’effort lie les frais aux ressources techniques consommées par un système d’IA. Les unités courantes incluent les tokens, c’est-à-dire des fragments de texte traités ou générés par un modèle ; le compute, c’est-à-dire les ressources de traitement requises ; et les heures d’agent, qui mesurent la durée de fonctionnement d’un agent IA.

Pour les fournisseurs d’infrastructure, ces unités sont directement liées au service fourni. Un client qui consomme davantage de ressources de traitement génère plus d’activité facturable, ce qui fait de l’usage technique une base pratique pour la tarification.

Cette approche fonctionne également pour les éditeurs qui proposent de larges portefeuilles de capacités IA. Des applications différentes peuvent produire des résultats totalement différents, ce qui rend difficile l’établissement d’une définition commune du travail accompli. La consommation de ressources fournit une mesure commune à l’ensemble de ces activités.

Les éditeurs peuvent simplifier la facturation en convertissant la consommation technique en crédits ou en unités monétaires, comme des dollars. Les clients gèrent alors leurs dépenses via une unité commune au lieu de suivre des mesures distinctes pour chaque capacité. Cela donne aux éditeurs un moyen cohérent de tarifer de nouvelles fonctions IA à mesure que leurs portefeuilles s’élargissent.

Cependant, la consommation de ressources et la valeur client peuvent diverger. Deux opérations utilisant des volumes de compute similaires peuvent produire des bénéfices métier très différents. La tarification à l’effort donne donc aux éditeurs un moyen mesurable de couvrir leurs coûts de fourniture, tout en laissant aux clients le soin de juger si le travail obtenu vaut la dépense.

La tarification fondée sur la production mesure le travail accompli

Au niveau applicatif, les clients comprennent souvent plus facilement le travail qu’ils veulent voir réalisé que les ressources de calcul qu’il exige. La tarification fondée sur la production répond à cela en facturant des unités de travail identifiables.

Une application marketing peut facturer des brouillons générés ou des leads recommandés. Un produit de traitement documentaire peut facturer des synthèses, tandis qu’un outil d’automatisation d’entreprise peut facturer selon le nombre d’enregistrements mis à jour.

Les acheteurs professionnels peuvent comprendre ces unités parce qu’elles décrivent quelque chose que le logiciel a effectivement fourni. Un client peut évaluer le coût de production d’une synthèse ou de mise à jour d’un enregistrement sans savoir combien de tokens l’opération a consommés.

La tarification à la production est particulièrement adaptée aux applications ciblées avec des livrables clairement définis. Elle permet aussi aux éditeurs de gérer leurs coûts internes liés à l’IA séparément des prix visibles par le client. Si un éditeur réduit les ressources nécessaires pour générer une production, ses coûts de fourniture baissent tandis que l’unité facturable reste la même.

Cela incite les éditeurs à améliorer leur efficacité. Mais accomplir le travail ne garantit pas que le client obtienne le résultat recherché.

Un système peut recommander un lead commercial qui ne répond jamais aux critères de qualification du client. La recommandation est une production ; un lead qualifié représente un résultat. De même, la mise à jour d’un enregistrement de base de données est une activité accomplie, tandis que l’achèvement du processus métier plus large qui dépend de cette mise à jour représente un autre niveau de réalisation.

Cette distinction détermine qui supporte les conséquences d’un travail inefficace. Dans une tarification à la production, l’éditeur est rémunéré lorsque l’activité convenue est réalisée. Le client supporte principalement le risque que la production soit inexacte, inutilisable ou commercialement improductive.

La tarification fondée sur les résultats mesure les résultats métier

La tarification fondée sur les résultats lie la rémunération de l’éditeur à un résultat métier convenu. Parmi les exemples figurent la résolution réussie d’un problème de support client, la récupération de valeur liée à la fraude ou l’encaissement de revenus en souffrance.

Avec cette approche, produire un travail intermédiaire ne suffit pas s’il ne conduit pas au résultat contractuel. Les revenus de l’éditeur dépendent donc plus directement de l’atteinte par le client de l’objectif spécifié.

Ce lien peut rapprocher la tarification de la valeur que les clients estiment recevoir. Il transfère aussi davantage de risque à l’éditeur, car le paiement peut dépendre de facteurs qui dépassent l’activité immédiate du système d’IA.

Ces trois unités conviennent donc à des produits différents. Les services d’infrastructure privilégient souvent l’effort, car les clients achètent des ressources techniques. Les applications ciblées peuvent privilégier la production, car les clients achètent un travail identifiable. La tarification fondée sur les résultats devient attractive lorsque l’éditeur et le client peuvent s’accorder sur un résultat métier mesurable.

Parvenir à cet accord est la difficulté centrale.

Pourquoi la tarification fondée sur les résultats fonctionne pour certains produits IA

La tarification fondée sur les résultats séduit les clients parce que le paiement dépend de l’obtention de quelque chose de précieux. Pour les éditeurs confiants dans l’efficacité de leur produit, elle offre un moyen de relier plus étroitement la rémunération à la performance métier.

Pourtant, son adoption reste limitée, car ce modèle se heurte à des contraintes pratiques. L’IA peut générer une activité mesurable sans produire des résultats que les deux parties peuvent utiliser de manière fiable pour calculer le paiement. Bain identifie trois conditions que la tarification fondée sur les résultats doit remplir.

Ces trois conditions comptent, car les résultats métier dépendent souvent de plusieurs systèmes, employés et facteurs externes. Un résultat peut être facile à mesurer alors que ses causes restent difficiles à isoler. Sans accord sur l’attribution, l’éditeur et le client peuvent contester quels résultats doivent donner lieu à facturation.

Le support client offre des résultats mesurables

Le support client est l’une des applications les plus claires, car les interactions individuelles ont souvent des résolutions identifiables. Lorsqu’un agent IA traite une demande, l’éditeur et le client peuvent fréquemment déterminer si le problème a été résolu. Cela crée un événement mesurable autour duquel établir la tarification.

Zendesk, Sierra et Fin utilisent une tarification orientée résolution pour les interactions de support client. Decagon propose également une tarification fondée sur les résultats en parallèle d’une alternative fondée sur la production.

Ces entreprises vendent des capacités de support client par IA, de sorte que leurs modèles tarifaires influent directement sur la manière dont elles génèrent des revenus à partir des interactions clients. Une facturation fondée sur la résolution peut relier leur rémunération à la réussite du service, tandis que les alternatives fondées sur la production permettent de faire dépendre le paiement de l’activité réalisée.

Les deux approches de Decagon illustrent comment une même catégorie d’application peut prendre en charge différentes définitions du travail facturable. Selon l’accord et les préférences du client, un éditeur peut facturer une interaction traitée ou un problème effectivement résolu.

La différence devient importante lorsqu’un système d’IA accomplit l’activité qui lui est assignée mais laisse le client avec un besoin d’assistance supplémentaire. Une unité de production peut générer une facturation pour l’interaction réalisée. Un accord fondé sur la résolution fait au contraire de la définition du succès l’élément central du paiement.

Le risque transactionnel et les workflows financiers offrent d’autres possibilités

La tarification fondée sur les résultats devient également possible lorsque le logiciel opère au plus près d’un événement financier mesurable. Riskified en fournit un exemple dans la gestion du risque transactionnel.

Riskified garantit les transactions approuvées contre les chargebacks et reçoit une rémunération calculée en pourcentage des commandes approuvées. Sa tarification relie les frais à une activité transactionnelle définie, tandis que la garantie place la protection contre le risque financier au cœur de la décision d’achat du client.

L’entreprise a un intérêt commercial dans ce modèle, car une rémunération liée aux transactions détermine ses revenus. La garantie signifie aussi que son économie dépend de la relation entre les frais perçus et l’exposition aux chargebacks qu’elle assume.

HighRadius expérimente une tarification liée aux résultats métier dans l’automatisation des comptes clients. Dans ce contexte, la rémunération peut être liée à des processus financiers plutôt qu’aux activités IA individuelles réalisées en cours de route.

HighRadius a également un intérêt commercial à démontrer que son logiciel crée une valeur métier mesurable. Une tarification liée aux résultats peut renforcer cette proposition lorsque les clients peuvent relier les améliorations de la performance des comptes clients à la contribution du produit.

Ces exemples montrent comment des accords orientés résultats peuvent fonctionner dans différentes applications. Une adoption plus large dépend de la capacité à maintenir des résultats mesurables et attribuables chez des clients aux processus différents.

Les workflows complexes rendent l’attribution difficile

L’attribution devient plus difficile lorsque l’IA contribue à un résultat aux côtés de plusieurs autres activités. Le marketing illustre bien ce problème.

Une application d’IA peut générer des contenus de campagne, recommander des segments d’audience ou optimiser des décisions de ciblage. Les revenus générés par la campagne peuvent aussi dépendre de la notoriété de la marque, de la tarification, de la distribution, des conditions de marché et du travail de l’équipe commerciale.

Même lorsque les revenus de campagne sont observables, l’acheteur et l’éditeur peuvent ne pas s’accorder sur la part de contribution du système d’IA. Il devient alors difficile de déterminer ce que l’éditeur doit percevoir.

Les workflows RH créent des problèmes similaires. Une décision de recrutement peut impliquer un logiciel de suivi des candidatures, un filtrage par IA, des entretiens, le jugement du management et plusieurs étapes d’approbation. La décision finale est observable, mais isoler la contribution d’une application d’IA peut être difficile.

L’ingénierie logicielle présente un autre défi de mesure. Les outils d’IA peuvent générer du code, suggérer des correctifs et assister les développeurs, mais mesurer de manière cohérente le gain de productivité qui en résulte reste difficile.

Dans l’ensemble de ces workflows, la collecte de données d’usage technique ne résout qu’une partie du problème. Les éditeurs ont aussi besoin d’une définition convenue du succès métier et d’un moyen défendable de relier ce succès à leur logiciel.

Les contrats fondés sur les résultats créent des coûts opérationnels

L’attribution devient un problème contractuel lorsque la rémunération dépend du résultat mesuré. Les éditeurs et les clients peuvent devoir négocier les événements qualifiants, les méthodes de mesure, les exceptions et la responsabilité des résultats.

Ces conditions doivent ensuite être intégrées dans les systèmes de facturation. Chaque accord a besoin de règles pour déterminer quels événements donnent lieu à paiement et comment les frais sont calculés.

L’administration devient plus exigeante à mesure que la base clients s’élargit. Des organisations ayant des processus différents peuvent exiger des définitions différentes du succès, créant des variations que l’éditeur doit gérer de manière cohérente.

La tarification fondée sur les résultats accroît également l’exposition de l’éditeur à l’environnement opérationnel du client. Si le paiement dépend de l’achèvement d’un processus métier, des faiblesses ailleurs dans ce processus peuvent réduire les revenus de l’éditeur même lorsque le système d’IA accomplit le travail qui lui est assigné.

Ces contraintes expliquent en partie pourquoi Bain s’attend à ce que la tarification fondée sur les résultats reste relativement limitée au cours des prochaines années. Le modèle peut fonctionner lorsque les résultats sont observables, attribuables et contractualisables. Une IA plus performante ne peut à elle seule supprimer le besoin de mesures fiables et d’accords exécutoires.

Deuxième décision : consommation directe ou capacité engagée

Une fois qu’un éditeur a choisi ce qu’il mesure, il doit décider comment les clients achètent l’activité mesurée. Une même unité fondée sur l’effort, la production ou les résultats peut s’appuyer sur deux structures d’achat différentes.

Dans le cadre d’une consommation directe, les clients paient en fonction de l’activité réelle. Dans le cadre d’une capacité engagée, ils achètent un volume couvrant une quantité convenue d’activité, qu’ils l’utilisent finalement ou non.

Bain constate qu’environ quatre éditeurs sur cinq qui introduisent une tarification de l’IA choisissent des dispositifs fondés sur la capacité. Ce constat concerne les engagements d’achat, tandis que les pourcentages précédents décrivent les unités de tarification.

Cette distinction explique pourquoi les mesures d’usage spécifiques à l’IA se sont diffusées plus vite que les changements dans l’économie des achats d’entreprise. Les éditeurs peuvent introduire de nouvelles unités facturables tout en continuant à percevoir des revenus via des contrats convenus à l’avance.

La consommation directe fait suivre les dépenses à l’activité

Dans une facturation en consommation directe, les clients paient la quantité qu’ils utilisent pendant la période de facturation. Si une application d’IA facture des synthèses générées, la facture reflète le nombre produit. Si un service d’infrastructure facture des tokens, la dépense varie avec la quantité traitée.

Cela lie étroitement l’utilisation au paiement. Les clients dont la demande est variable peuvent augmenter ou réduire leur consommation sans acheter un volume fixe qui pourrait dépasser leurs besoins.

Cette approche rend également visible le coût marginal d’une activité supplémentaire. Le coût marginal est la dépense additionnelle créée par l’exécution d’une unité de travail supplémentaire. Une équipe produit ou d’ingénierie peut voir comment une charge de travail supplémentaire affecte les dépenses et ajuster son usage en conséquence.

Mais cette flexibilité s’accompagne d’une incertitude financière. Lorsque la consommation augmente de manière inattendue, la dépense augmente avec elle. Les acheteurs d’entreprise peuvent avoir du mal à faire approuver des budgets avant de savoir quelle quantité d’IA leur organisation utilisera.

Le problème s’aggrave lorsqu’une application se diffuse dans de nombreuses équipes ou entre dans des workflows aux niveaux d’activité variables. Une organisation peut connaître le prix par tâche tout en restant incertaine quant à sa dépense annuelle.

Les équipes finance doivent alors planifier une dépense qui varie avec la demande opérationnelle. Cette incertitude peut ralentir les achats, en particulier lorsque les acheteurs ont besoin d’une approbation préalable des dépenses.

La consommation directe reste importante pour les logiciels d’infrastructure et les acheteurs à profil technique. Ces clients ont souvent de bonnes raisons de relier les dépenses à l’usage des ressources et disposent peut-être déjà des outils nécessaires pour suivre la consommation.

Pour les applications d’entreprise dont l’adoption est moins prévisible, la capacité engagée offre une autre manière de gérer l’incertitude.

La tarification à la capacité établit un volume

Dans une tarification à la capacité, les clients s’engagent à acheter une quantité définie d’activité ou de ressources IA. Le droit d’usage peut être exprimé en crédits, en unités d’usage ou en un autre volume lié à l’unité de tarification du produit.

Les clients consomment ce volume pendant la période convenue, l’activité supplémentaire pouvant être soumise à des frais de dépassement. La caractéristique déterminante est que le paiement engagé reste dû même lorsque la consommation réelle est inférieure à la quantité achetée.

La capacité inutilisée n’est pas automatiquement reportée ni remboursée. L’éditeur perçoit donc le paiement convenu même lorsque le client utilise moins d’unités que prévu.

Prenons une application qui facture selon le nombre de tâches IA réalisées. Avec une tarification en consommation directe, la dépense suit les tâches effectivement exécutées. Dans une tarification à la capacité, le client achète un volume couvrant un nombre convenu de tâches.

Si le client réalise moins de tâches que ce que couvre le volume, le paiement engagé reste le même. Si la demande dépasse le volume, le contrat peut autoriser une consommation supplémentaire payante.

Les deux accords utilisent la même unité de production. Leur économie diffère parce que l’un facture l’activité réelle tandis que l’autre établit un engagement d’achat.

C’est ainsi qu’un logiciel présenté comme fondé sur l’usage peut conserver des caractéristiques de revenus proches de celles de l’abonnement.

Les acheteurs d’entreprise valorisent les engagements prévisibles

La tarification à la capacité séduit les équipes achats et les DAF parce qu’elle établit une obligation financière définie. Les acheteurs peuvent comparer le coût d’un déploiement d’IA à un budget approuvé et voir combien l’organisation s’est engagée à dépenser.

Cette prévisibilité compte lorsque la consommation est difficile à anticiper. Les employés peuvent adopter les applications à des rythmes différents, les workflows peuvent s’étendre et les utilisateurs individuels peuvent générer des niveaux de demande très différents.

Un volume fixe donne à l’organisation acheteuse le contrôle de son engagement initial. Il s’intègre aussi aux processus d’achats d’entreprise établis, fondés sur des contrats négociés, des validations de dépenses et des budgets logiciels planifiés.

Pour les acheteurs, cet avantage s’accompagne d’un risque d’utilisation. Lorsqu’une organisation achète plus de capacité qu’elle n’en consomme, le coût effectif par unité d’usage réel augmente.

Un volume qui paraît économique au niveau d’activité attendu peut devenir coûteux si l’adoption est plus faible qu’anticipé. Les clients doivent donc prévoir soigneusement la demande et suivre l’utilisation après le déploiement.

Cela crée un arbitrage entre certitude budgétaire et paiement de droits inutilisés. Le contrat fixe l’obligation initiale, mais la valeur de cet achat dépend toujours du volume d’activité utile réellement produit.

Les éditeurs bénéficient de revenus engagés

La même structure d’achat offre un avantage différent aux fournisseurs de logiciels. Les revenus liés à l’usage direct varient avec l’activité du client ; une consommation plus faible réduit donc le paiement correspondant.

Les engagements de capacité établissent des obligations de revenus à l’avance. L’éditeur perçoit le montant engagé même lorsque le client consomme moins que prévu.

Cela préserve une caractéristique importante de l’économie traditionnelle du logiciel d’entreprise. Avec les licences par utilisateur, les clients achètent un accès pour un nombre déterminé d’utilisateurs. Certaines licences peuvent rester inutilisées, ou des employés peuvent utiliser le logiciel de manière occasionnelle, mais le paiement contractuel reste généralement en place.

La tarification IA fondée sur la capacité applique le même principe à un droit différent. Les clients achètent le droit de consommer une quantité spécifiée d’activité IA plutôt qu’un accès pour un nombre fixe de personnes.

L’unité facturable change, tandis que l’éditeur conserve la capacité de percevoir des revenus sur des volumes que les clients n’utilisent pas entièrement.

Le résultat est une asymétrie économique. Les clients supportent le coût de la capacité inutilisée, tandis que les éditeurs conservent le paiement associé.

Cela aide à expliquer la prévalence des dispositifs de capacité. Ils combinent une mesure spécifique à l’IA avec un modèle de revenus engagés que les éditeurs de logiciels d’entreprise comprennent déjà et qu’ils ont intérêt financièrement à préserver.

Les acheteurs ont eux aussi des raisons de préférer cette structure, car elle simplifie la budgétisation. Mais les intérêts des deux parties diffèrent : les éditeurs bénéficient de la certitude du paiement, tandis que les clients doivent mettre cette certitude en balance avec la possibilité de capacité inutilisée.

La popularité de ces accords reflète donc leur adéquation avec les pratiques établies d’achat d’entreprise et les modèles de revenus des éditeurs. Elle ne prouve pas qu’ils produisent nécessairement de meilleurs résultats pour les clients, une rétention plus élevée ou une rentabilité supérieure.

Les grands éditeurs de logiciels utilisent déjà des modèles de capacité

La tarification à la capacité apparaît dans plusieurs produits logiciels établis. Ces exemples montrent comment les éditeurs peuvent introduire des frais spécifiques à l’IA tout en conservant des engagements familiers pour les acheteurs d’entreprise.

Atlassian Rovo utilise des crédits IA, permettant aux clients d’acheter l’accès à une quantité définie d’activité IA. ServiceNow Now Assist utilise des droits IA prédéfinis, reliant les achats à des volumes pour ses capacités IA.

Adobe Firefly utilise de la même manière des crédits pour encadrer l’accès à la génération par IA. Les unités commerciales diffèrent, mais chacune permet de gérer la consommation d’IA via un droit défini.

Atlassian, ServiceNow et Adobe ont tous un intérêt commercial dans la manière dont ces volumes sont structurés, puisqu’ils vendent les produits sous-jacents. Un achat fondé sur la capacité peut leur donner des revenus plus prévisibles tout en permettant aux clients de planifier leurs dépenses.

Les crédits et droits offrent aussi un moyen d’introduire une tarification spécifique à l’IA en parallèle des contrats logiciels existants. Une entreprise peut conserver des abonnements par utilisateur pour l’accès principal à l’application tout en ajoutant un volume pour l’activité IA.

Cette approche hybride permet d’intégrer les évolutions des coûts et de la consommation de l’IA sans exiger une refonte complète de l’accord client. Elle permet aussi aux éditeurs de facturer séparément les opérations IA qui créent des coûts incrémentaux significatifs.

Pour les fournisseurs SaaS établis, cette séparation peut être particulièrement utile. Les fonctionnalités applicatives classiques peuvent continuer à délivrer de la valeur via l’accès utilisateur, tandis que les capacités IA introduisent une consommation supplémentaire de ressources ou du travail accompli.

Le contrat qui en résulte peut contenir plusieurs composantes tarifaires tout en maintenant un engagement financier défini. Les acheteurs disposent d’un moyen de budgéter l’IA, et les éditeurs peuvent couvrir les coûts liés à l’IA via un droit distinct.

La décision d’achat détermine l’exposition financière

Choisir entre consommation directe et capacité exige de comprendre quelle incertitude compte le plus pour le client.

La consommation directe lie étroitement les paiements à l’activité réelle. Elle peut bien fonctionner lorsque la demande varie, que l’usage des ressources est mesurable et que les acheteurs peuvent gérer des dépenses qui évoluent dans le temps.

La capacité établit un engagement prévisible. Elle peut convenir à des clients dont les processus d’achat privilégient des budgets définis et dont la consommation attendue est suffisamment stable pour justifier un volume.

Chaque structure laisse subsister un risque différent. La consommation directe expose les clients à des hausses inattendues d’activité, tandis que la capacité les expose à des prévisions inexactes et à des droits inutilisés.

Ces risques existent indépendamment de l’unité sous-jacente. Un produit fondé sur l’effort peut utiliser l’une ou l’autre structure d’achat, et il en va de même pour la tarification fondée sur la production et sur les résultats.

L’unité de tarification détermine ce qui déclenche une facturation. La structure d’achat détermine la quantité que les clients s’engagent à acheter et la manière dont l’utilisation réelle affecte leurs coûts.

Cette indépendance compte lorsqu’on compare des produits IA. Deux éditeurs qui annoncent une tarification fondée sur l’usage peuvent facturer des activités différentes, exiger des engagements différents et répartir le risque financier de façons très différentes.

Le bon modèle de tarification de l’IA dépend des deux décisions

Pour les dirigeants du logiciel, le point de départ pratique consiste à déterminer si l’IA a suffisamment modifié l’économie du produit pour justifier un ajustement tarifaire.

Bain identifie deux questions qui aident à établir la nécessité d’un changement :

1. L’IA modifie-t-elle de manière significative la façon dont les clients reçoivent de la valeur du produit ?
2. L’IA introduit-elle des coûts marginaux substantiels à mesure que le logiciel accomplit davantage de travail ?

L’une ou l’autre de ces conditions peut justifier de reconsidérer le modèle tarifaire existant.

Un produit qui continue à délivrer de la valeur principalement via l’accès utilisateur peut conserver une tarification par utilisateur. Une application dans laquelle l’IA crée un volume substantiel de travail supplémentaire ou de consommation de ressources peut nécessiter une unité distincte, potentiellement ajoutée à l’abonnement existant.

Une fois la nécessité du changement établie, la question suivante est de savoir quelle activité doit déclencher une facturation.

Faire correspondre l’unité à la valeur délivrée

Pour les produits d’infrastructure et les larges portefeuilles IA, la tarification fondée sur l’effort peut fournir une mesure cohérente entre différentes capacités. Les clients achètent des ressources de traitement, et les éditeurs peuvent relier les frais à la consommation sous-jacente.

Pour les applications ciblées, des productions identifiables peuvent correspondre plus étroitement à ce que les clients reconnaissent et achètent. Les brouillons générés, les synthèses, les leads recommandés et les enregistrements mis à jour sont des exemples de travail que les acheteurs peuvent compter et évaluer.

La tarification fondée sur les résultats mérite d’être envisagée lorsque le résultat métier peut être mesuré, attribué spécifiquement au système d’IA et intégré dans un accord exécutoire.

Cette évaluation doit inclure le coût d’exploitation du modèle tarifaire. Un résultat qui semble facile à mesurer dans une démonstration peut exiger des clauses contractuelles ou des procédures de facturation complexes chez des clients d’entreprise aux workflows différents.

Les éditeurs doivent aussi tenir compte du degré de contrôle qu’ils ont sur le résultat. Plus un résultat dépend des processus du client, de ses employés ou de conditions externes, plus l’éditeur est exposé à des facteurs extérieurs à son logiciel.

Une unité de tarification doit donc refléter le rôle du produit dans la création de valeur tout en restant pratique à mesurer, expliquer et administrer.

Faire correspondre l’engagement aux besoins d’achat du client

Une fois l’unité établie, les éditeurs doivent déterminer comment les clients achèteront ses unités.

L’usage direct aligne étroitement l’activité sur la dépense. La capacité engagée établit une obligation de dépense définie pour les acheteurs et un engagement de revenus plus prévisible pour les vendeurs.

Le choix doit refléter les préférences d’achat des clients, les schémas de consommation attendus, les exigences budgétaires et les conséquences de volumes inutilisés.

Un acheteur dont la demande est variable et qui dispose de contrôles d’usage solides peut préférer une facturation directe. Une entreprise soumise à des validations formelles de dépenses peut trouver plus simple d’acheter un volume convenu, même lorsque la consommation reste incertaine.

Ces décisions doivent aussi refléter la structure de coûts de l’éditeur. Les capacités IA avec des coûts marginaux substantiels exigent une attention particulière à la consommation, que les clients achètent les unités directement ou via une capacité engagée.

Par exemple, une application fondée sur la production peut facturer aux clients un montant fixe pour chaque tâche réalisée tout en supportant des coûts variables de traitement par modèle. Si l’usage augmente ou si le coût de production d’une unité change, l’éditeur doit s’assurer que sa tarification continue de couvrir les coûts de fourniture.

Les accords de capacité introduisent une autre considération. Un éditeur reçoit des revenus engagés à l’avance, mais les clients peuvent consommer leurs volumes à des rythmes différents. L’éditeur doit donc comprendre comment le coût de fourniture de la capacité achetée se compare aux revenus qui y sont attachés.

Évaluer l’économie derrière la tarification des concurrents

Les libellés tarifaires des concurrents offrent peu d’indications, car des descriptions similaires peuvent masquer des dispositifs financiers différents.

Deux produits décrits comme fondés sur l’usage peuvent employer des unités différentes, exiger des engagements différents et exposer les clients à des risques de dépense différents. Comparer uniquement le prix unitaire affiché peut donc faire passer à côté du coût effectif d’utilisation du logiciel.

Pour les acheteurs, ce coût effectif dépend en partie du taux d’utilisation. Un accord de capacité avec un prix unitaire attractif peut devenir moins économique lorsqu’une grande partie du volume reste inutilisée.

Pour les éditeurs, le calcul inclut aussi le coût de production de chaque unité facturable. Les unités fondées sur l’effort, la production et les résultats exposent les fournisseurs à des niveaux différents de coûts de fourniture et de risque de performance.

Les responsables logiciels qui évaluent un nouveau modèle tarifaire doivent donc examiner l’activité attendue, les coûts de fourniture, les engagements contractuels et la capacité à mesurer ce que les clients reçoivent. Ces facteurs déterminent si l’accord reste soutenable à mesure que l’adoption évolue.

Le test pratique intervient après le déploiement, lorsque les clients commencent à consommer l’IA à des rythmes qui peuvent différer de leurs prévisions. Les éditeurs doivent suivre la relation entre activité facturable et coûts de fourniture, tandis que les acheteurs doivent surveiller l’utilisation réelle par rapport aux droits achetés.

Ces mesures fournissent la base pour ajuster les volumes, les conditions de dépassement et les engagements futurs. Elles révèlent aussi si l’unité choisie continue de refléter le travail que les clients valorisent à mesure que l’IA prend une place plus importante dans le produit.

Recap

L’IA change ce que les éditeurs de logiciels facturent, mais pas nécessairement la manière dont les clients paient. À mesure que la tarification s’éloigne des licences traditionnelles par utilisateur pour aller vers la consommation de ressources, le travail accompli et les résultats métier, la capacité engagée reste le modèle d’achat dominant. Cela permet aux éditeurs de monétiser l’activité IA tout en préservant des revenus prévisibles, mais cela impose aussi aux acheteurs une responsabilité accrue dans la gestion de l’utilisation et l’évitement du paiement de volumes inutilisés.

Pour les PDG, CTO et autres responsables technologiques, la distinction entre unités de tarification et engagements d’achat devient de plus en plus importante. Un produit fondé sur l’usage ne signifie pas automatiquement que les clients paient uniquement ce qu’ils consomment. De même, une tarification fondée sur les résultats ne garantit pas un lien plus étroit avec la valeur métier, sauf si les résultats peuvent être mesurés, attribués et intégrés dans des clauses contractuelles.

La priorité pour les acheteurs d’entreprise est de comprendre comment chaque structure tarifaire affecte la dépense logicielle totale, la flexibilité opérationnelle et le risque financier. Pour les éditeurs de logiciels, l’enjeu est d’établir une tarification qui reflète la valeur client, couvre les coûts de fourniture de l’IA et soutienne des revenus durables à mesure que l’adoption progresse.

Le changement plus large ne consiste pas simplement à passer des licences par utilisateur à l’usage ou aux résultats. Il va vers des modèles tarifaires qui doivent tenir compte à la fois du travail accompli par l’IA et des engagements financiers que les clients sont prêts à prendre. Les organisations qui évaluent séparément ces décisions seront mieux placées pour négocier des accords logiciels, prévoir les dépenses d’IA et capter de la valeur à mesure que l’IA s’intègre aux opérations de l’entreprise.