Toute discussion sur la tarification de l’IA se résume finalement à quatre variantes concrètes : au token, au résultat, par agent et par poste avec un pool de crédits. Les fournisseurs les présentent comme des philosophies fondamentalement différentes. Dans la pratique, elles répondent à différentes combinaisons de prévisibilité, de protection des marges et de compréhension par l’acheteur. Le bon choix n’est pas nécessairement le plus sophistiqué. C’est celui qui résiste à l’épreuve de votre rentabilité unitaire et des habitudes d’achat de vos clients.
Il s'agit d'une comparaison entre différents modèles de tarification de l'IA, et non d'un classement. Chaque modèle fonctionne dans certains cas de figure, mais présente des lacunes dans d'autres. Poursuivez votre lecture pour découvrir à quelles situations s'applique chaque modèle, ce que cela vous coûte lorsqu'il ne fonctionne pas, et comment envisager les combinaisons hybrides que la plupart des produits d'IA destinés aux entreprises finissent par utiliser.
Tarification par jeton
Avec la tarification au jeton, le client paie un tarif par jeton traité, les tarifs étant généralement distincts pour les jetons d’entrée et de sortie. Il s’agit du modèle le plus simple à expliquer à un acheteur technique. Lien direct avec le coût de l’infrastructure. Norme pour les API d’IA destinées aux développeurs. OpenAI, Anthropic, Cohere et tous les autres grands fournisseurs de modèles de langage à grande échelle (LLM) utilisent une variante de ce modèle.
Le revers de la médaille, c'est la compréhension de la part des acheteurs. Les acheteurs professionnels ne savent pas ce qu'est un token et ne peuvent pas estimer leurs dépenses pour un produit dont le prix est fixé en tokens. Cela ne pose pas de problème lorsque l'acheteur est un développeur qui utilise votre API. En revanche, cela devient problématique lorsque l'acheteur est une équipe financière qui tente d'établir son budget annuel.
La facturation au jeton fonctionne lorsque : votre acheteur est un expert technique, votre produit est une API ou un outil de développement, et vos outils de suivi client sont suffisamment performants pour lui permettre de mesurer sa propre consommation. La facturation au jeton ne fonctionne pas lorsque : vous vendez à des acheteurs métier non techniciens qui souhaitent un montant annuel prévisible, ou lorsque vos coûts d'inférence varient d'un mois à l'autre et que vous ne disposez pas d'un mécanisme permettant de réajuster les tarifs sans renégocier les contrats.
Tarification par résultat
Le client ne paie que lorsque l'IA mène à bien une tâche définie : ticket détourné, opportunité qualifiée, cas de fraude détecté. Il s'agit du modèle de tarification qui offre le meilleur alignement sur la valeur. La disposition à payer est maximale lorsque le résultat est mesurable et clairement attribuable.
La réalité opérationnelle est plus complexe que le discours commercial. La réussite doit être définie avec suffisamment de précision pour pouvoir être vérifiée. L’attribution doit résister à un litige avec un client. Le système de facturation doit évaluer les résultats variables et retenir les revenus jusqu’à ce que le résultat soit confirmé. Exemples publics où cela fonctionne : Intercom Fin (par résolution de ticket), Riskified (par transaction approuvée) et Decagon (par résolution de conversation). Leur point commun est un indicateur de réussite clair, généré par le système d’IA lui-même et que le client peut vérifier.
La facturation par résultat fonctionne lorsque : le résultat est discret, mesurable au niveau de l’événement, et généré par un système plutôt que par un jugement humain. La facturation par résultat ne fonctionne pas lorsque : la définition du résultat ne résiste pas à un débat sur l’attribution, lorsque les clients contestent ce qui constitue un succès, ou lorsque votre plateforme ne permet pas de retenir les revenus en attente de résultats. La comptabilisation des revenus dans le cadre d’une tarification basée sur les résultats s’appuie sur la notion de contrepartie variable de la norme ASC 606, avec un risque de reprise sur les résultats non confirmés, ce qui constitue l’un des traitements comptables les plus complexes prévus par les directives.
Tarification par agent
Le client paie soit par instance d'agent, soit par tâche d'agent, généralement avec un minimum mensuel. Ce modèle fonctionne lorsque l'agent constitue une unité de valeur distincte que le client peut attribuer à un processus spécifique. En termes de complexité opérationnelle, il se situe à mi-chemin entre la facturation au résultat (qui suppose la réussite) et la facturation par poste (qui ne tient pas compte de l'utilisation).
La variante pratique qui fait son chemin est celle de la tarification « par agent-tâche » : facturer chaque unité de travail réalisée par l'agent, en définissant clairement ce qui constitue une tâche. Les agents peuvent être rémunérés à des taux différents en fonction de leur rôle : agent de développement commercial, agent du service client, agent des achats. Chacun a son propre coût unitaire et son propre tarif.
La tarification « par agent » fonctionne lorsque : les agents effectuent des unités de travail distinctes qui correspondent à des processus client identifiables, et que le client peut attribuer l’utilisation à des résultats spécifiques sans avoir besoin d’une structure de facturation « par résultat ». La tarification « par agent » ne fonctionne plus lorsque : les agents travaillent selon des boucles ou des cycles asynchrones qui ne correspondent pas clairement à une unité quantifiable, ou lorsque la consommation du client connaît des pics impossibles à prévoir. Certains fournisseurs utilisent également la tarification « par agent » comme tarif d’entrée, complétée par une tarification « par résultat », ce qui combine la prévisibilité d’un abonnement avec l’alignement sur la valeur propre à la tarification basée sur les résultats.
Tarification par poste avec un pool de crédits
Chaque licence contribue à un pool commun de crédits d'utilisation de l'IA. Ce pool est débité chaque fois qu'un utilisateur lance une action d'IA. Des recharges automatiques ou des passages à un niveau supérieur sont déclenchés lorsque le pool est épuisé. GitHub Copilot Business, Notion AI, Miro AI et Figma AI utilisent tous des variantes de ce système.
La logique commerciale réside dans le fait que ce modèle préserve le mode d'achat par licence auquel l'entreprise est habituée, tout en introduisant une composante de consommation qui évolue en fonction de l'adoption réelle de l'IA. Il résout le problème suivant : « nous avons vendu des licences à une entreprise où la moitié des utilisateurs n'utilisent jamais l'IA », car le pool de crédits absorbe les écarts entre les utilisateurs.
Le modèle « par poste » avec un pool de crédits fonctionne lorsque vous disposez d’un accord commercial existant basé sur le nombre de postes que vous souhaitez conserver, et lorsque l’utilisation varie considérablement d’un utilisateur à l’autre, de sorte qu’un modèle de pool permet d’obtenir une moyenne équitable. Ce modèle ne fonctionne plus lorsque votre acheteur est une petite équipe où l’utilisation se concentre sur une poignée d’utilisateurs (le pool ne protège pas les marges car la plupart des postes ne consomment pas), ou lorsque la complexité de la comptabilité des crédits dépasse ce que votre plateforme de facturation peut gérer sans rapprochement manuel. La comptabilisation repose sur des produits différés pour l’émission des crédits et sur une comptabilisation basée sur la consommation pour leur utilisation, ce qui est bien établi par la norme ASC 606, mais nécessite que la mise en correspondance entre crédits et coûts soit documentée et cohérente.
Où les hybrides atterrissent-ils réellement ?
La plupart des produits d'IA destinés aux entreprises finissent par adopter une approche hybride. Les deux combinaisons les plus courantes sont les suivantes :
- Abonnement et surconsommation. Le client paie un abonnement mensuel comprenant un quota de base d'utilisation de l'IA. La surconsommation est facturée à un tarif unitaire. Chiffre d'affaires de base prévisible, potentiel de croissance lié à l'adoption. Il s'agit du modèle d'offre SaaS d'entreprise par défaut appliqué à l'IA.
- Nombre de postes + pool de crédits + composantes basées sur les résultats. Un abonnement par poste pour le produit de base, un pool de crédits partagé régissant l’utilisation des fonctionnalités d’IA, et une facturation basée sur les résultats pour un ensemble précis de tâches d’IA à forte valeur ajoutée. Complexe à configurer. Par ailleurs, ce modèle s’adapte à la plus large gamme de comportements d’achat des clients, ce qui explique pourquoi les produits d’IA destinés aux entreprises se retrouvent dans cette catégorie.
La décision relative à la plateforme sous-jacente constitue la contrainte qui détermine si le modèle hybride est envisageable. Un moteur de facturation incapable de prendre en charge plusieurs modèles sur une même facture oblige l’entreprise à opter pour un modèle plus simple que celui que le marché récompense. Cette limitation de la plateforme est l’une des raisons les plus courantes pour lesquelles les stratégies de monétisation de l’IA sont édulcorées entre la conception de la tarification et le contrat client.
Comment choisir un modèle de tarification pour l'IA
Le choix ne consiste pas à déterminer « laquelle de ces options est la meilleure », mais à déterminer « laquelle correspond à notre modèle économique unitaire et au comportement d'achat de nos clients ». Trois questions vous permettront d'y voir plus clair.
Tout d’abord, à quoi ressemble le coût unitaire ? L’économie unitaire par transaction détermine quel modèle permet de fixer un prix sans éroder la marge. Si votre coût unitaire est élevé et variable, les modèles « par résultat » ou « par tâche d’agent » vous offrent le lien le plus étroit entre le prix et le coût. Si votre coût unitaire est faible et prévisible, le modèle « par poste » avec un pool de crédits absorbe la variance sans vous obliger à fixer un prix pour chaque événement.
Deuxièmement, qui est votre acheteur ? Les acheteurs techniques sont en mesure d'estimer les dépenses par jeton. Ce n'est pas le cas des acheteurs métier. Si l'acheteur appartient au service financier ou aux achats, le modèle doit fournir un chiffre sur lequel il pourra établir son budget.
Troisièmement, qu’est-ce que votre plateforme prend réellement en charge ? Le modèle tarifaire le plus défendable que votre plateforme ne peut pas évaluer vaut moins que le deuxième meilleur modèle qu’elle peut évaluer sans problème. Insistez sur la question de la plateforme avant de vous prononcer sur celle de la tarification.
Pour découvrir le cadre complet couvrant les neuf modèles de monétisation de l'IA et savoir comment élaborer une stratégie en amont du choix du modèle, consultez billingplatform.com/ai-monetization.
BillingPlatform évalue chacun des modèles ci-dessus sur la base d'un moteur unique, sans code d'intégration entre la facturation par abonnement, à l'utilisation, au crédit et au résultat. Découvrez comment cela fonctionne sur billingplatform.com.
