Due diligence sur le pricing des logiciels IA : par siège, à l'usage, au résultat

La due diligence sur le modèle de pricing est la discipline qui consiste à tester si le modèle de monétisation d'une cible — par siège, à l'usage ou à la consommation, au résultat ou à la valeur, ou un hybride de ceux-ci — correspond réellement à l'économie produit sous-jacente et au contexte d'achat dans lequel elle vend. Il ne s'agit pas d'un examen de la page de tarifs. On se demande quelle unité l'entreprise facture, qui déclenche cette unité, si l'entreprise peut la prédire, et si le modèle survivra au contact des achats en entreprise, de l'automatisation pilotée par l'IA et de la structure de coûts de la cible elle-même. Se tromper sur ce point conduit à mal valoriser la qualité de la croissance, la rétention et la marge.

Si cette question est devenue centrale en diligence, c'est que l'IA remet en cause l'hypothèse sur laquelle le pricing SaaS traditionnel était construit. Le SaaS classique supposait un coût marginal nul : une fois le logiciel développé, chaque client supplémentaire coûtait à peu près le même montant à servir que le précédent, si bien que les abonnements forfaitaires par siège fonctionnaient. Les produits IA supportent un coût d'inférence variable et significatif : chaque requête, chaque action d'agent ou chaque artefact généré déclenche des dépenses de calcul que le fournisseur paie. Lorsque le modèle de pricing ne suit pas ce coût variable, la marge se réduit avec l'adoption au lieu de s'accroître.[1]

Les équipes de due diligence devraient se calibrer sur la réalité du marché plutôt que sur le battage médiatique. AlixPartners a analysé 65 grandes entreprises SaaS et des concurrents natifs de l'IA et a constaté que seules 4 ont pleinement adopté une tarification basée sur les résultats, tandis que 72 % appliquent une approche hybride intégrant la consommation via des crédits IA ou une facturation à l'usage, et que plus de la moitié des entreprises restantes s'appuient encore principalement sur des modèles par siège.[2] La migration est réelle, mais plus lente et plus inégale que ne le suggèrent les commentaires, c'est pourquoi le bon modèle relève de l'économie du produit, pas de l'idéologie.

Par siège : un tarif fixe par utilisateur avec accès à l'IA, familier pour les acheteurs mais fragile lorsque le coût d'inférence variable augmente avec l'usage.

Par token : facturation mesurée des entrées et sorties du modèle, le modèle canonique de la couche d'infrastructure, transparent pour les ingénieurs mais difficile à budgéter pour les acheteurs métier.

Par activité : un coût par action discrète telle qu'une conversation, un appel API ou une exécution de workflow.

Par production : un coût par artefact généré tel qu'une image, un document ou un rapport rédigé.

Par résultat : un coût uniquement lorsque l'IA délivre un résultat métier défini, comme la résolution d'un ticket.

Hybride : une base d'abonnement combinée à un dépassement de consommation, des crédits prépayés ou des composantes basées sur les résultats, le schéma suivi par la plupart des entreprises IA en production.

Chacun de ces modèles présente un profil de due diligence distinct. Pour un traitement approfondi de la manière dont la compression des sièges, le COGS d'inférence et les structures hybrides se répercutent sur l'analyse de transactions, consultez notre article complémentaire sur la due diligence de la tarification IA. Les sections ci-dessous offrent aux acheteurs un cadre d'analyse correspondant, des tests modèle par modèle, une liste de vérification des preuves et les signaux d'alerte qui relient les constats tarifaires à la valorisation.

Avant de juger si le modèle de tarification d'une cible est bon ou mauvais, les acheteurs devraient appliquer un diagnostic qui distingue l'adéquation de la mode. Un modèle qui paraît agressif dans un contexte peut être exactement le bon dans un autre. Six questions structurent ce jugement :

Qu'est-ce qui est monétisé : l'accès au logiciel, une activité dénombrable, une production générée ou un résultat métier délivré ?

Qui déclenche la consommation : un utilisateur humain, un workflow automatisé ou l'agent IA lui-même ? Un modèle facturé par utilisateur se comporte très différemment lorsque des agents font le travail.

Quelle est la prévisibilité de l'usage : la consommation est-elle stable et prévisible, ou fluctue-t-elle selon la saisonnalité, le comportement des clients et la complexité des requêtes ?

La valeur ou le résultat peut-il être mesuré et attribué : le succès est-il discret et vérifiable, ou diffus entre de nombreux facteurs contributifs ?

La tarification est-elle alignée sur les processus d'achat des entreprises : un DSI peut-il la budgéter, la faire valider par les achats et la défendre en interne ?

Quel pouvoir de tarification l'entreprise possède-t-elle réellement : le modèle de tarification est-il défendable parce que le produit est intégré aux workflows et difficile à remplacer, ou est-il exposé à un repositionnement tarifaire concurrentiel ?

Deux cadres publiés aident à répondre à ces questions. Le cadre COMPASS de Zuora classe les six modèles de tarification IA courants — par siège, par token, par activité, par production, par résultat et hybride — selon l'unité de valeur que l'IA délivre et la clarté avec laquelle cette valeur peut être mesurée, et note que la plupart des entreprises IA en production finissent par adopter des modèles hybrides combinant une base d'abonnement à un dépassement de consommation ou des crédits prépayés.[1] Ce cadre ne dit pas à une entreprise ce qu'elle doit facturer, mais il montre quand une revendication de résultat est crédible et quand il s'agit d'un habillage marketing : là où le succès ne peut être mesuré d'une manière acceptable pour le client, un compteur de résultats est une position de négociation plutôt qu'un modèle de tarification.

AlixPartners ajoute trois conditions structurelles d'exposition qui indiquent aux acheteurs à quel point un modèle de tarification est sous pression: une forte concentration de sièges dans des workflows automatisables tels que le service client ou le support informatique, la vente à des fonctions où le ROI de l'IA est facilement mesurable, et une dépendance aux sièges avec de faibles couches de tarification secondaires. Les entreprises à l'intersection de ces trois conditions sont les plus urgentes à agir.[2] Le pouvoir de tarification lui-même doit être testé séparément: lorsqu'un produit est profondément intégré et que le changement de solution est coûteux, un fournisseur dispose de plus de marge pour défendre la valeur du siège, une dynamique que nous examinons dans notre analyse des coûts de changement de workflow.

Chaque modèle de tarification échoue à sa manière, et chacun exige donc ses propres questions de due diligence. Le tableau ci-dessous résume les tests essentiels ; les paragraphes qui suivent approfondissent les deux domaines où les transactions échouent le plus souvent.

Modèles au siège : la compression, un churn silencieux

Pour les cibles facturées au siège, le test central est le risque de compression des sièges : lorsque des agents IA peuvent traiter la charge de travail d'utilisateurs qui détiendraient sinon des licences, l'argument de la valeur par siège s'affaiblit à chaque cycle de déploiement. La due diligence doit quantifier la part du chiffre d'affaires qui repose sur des flux de travail répétitifs et fondés sur des règles, et examiner séparément le shelfware, c'est-à-dire l'écart entre les sièges sous licence et les sièges actifs, car il flatte l'adoption déclarée et sous-estime le risque de renouvellement. La profondeur des remises et la réalisation des prix complètent le tableau : une entreprise qui accroît son nombre de sièges en baissant les prix ne démontre aucun pouvoir de fixation des prix.

Modèles au résultat : la définition, c'est le produit

Pour les cibles facturées au résultat, la définition tarifaire fait effectivement partie du produit. Il n'existe aucune norme sectorielle convenue pour noter les résultats, de sorte que les prix publiés par résolution ne sont pas comparables d'un fournisseur à l'autre.[3] Les acheteurs doivent établir comment le succès est vérifié, comment le silence du client est traité, ce qui se passe lorsque l'IA transfère la tâche à un humain en cours de route, et qui supporte le coût lorsque les taux de résolution déçoivent. AlixPartners a constaté que les quatre entreprises de son échantillon pratiquant un tarif confirmé au résultat opèrent toutes dans des flux de travail de service client où les résultats sont discrets et vérifiables, ce qui constitue un repère utile de l'étroitesse actuelle de l'espace viable.[2]

Les conclusions tarifaires ne valent que par les documents qui les étayent. La data room doit être passée au peigne fin pour les éléments suivants, et les lacunes de cette liste constituent en elles-mêmes une conclusion :

Relier les preuves tarifaires, des contrats et données d'usage aux conclusions de due diligence. · Généré par IA

Contrats clients et bons de commande avec grilles tarifaires, y compris les conditions de renouvellement et tout engagement d'utilisation ou de résultat.

Tarifaires et registres d'approbation des remises, pour confronter le prix réalisé au prix catalogue.

Données d'utilisation et de consommation par client, y compris les mécanismes de consommation de crédits et de régularisation pour les modèles prépayés ou à base d'allocation.

Mémos de reconnaissance de revenus couvrant le traitement de l'utilisation, des crédits et des frais de résultat au titre d'ASC 606.

Éléments probants de churn, de rétrogradation et d'expansion autour des changements de tarification ou de packaging passés, au niveau des cohortes lorsque disponible.

Les conditions contractuelles déterminent le traitement comptable, lequel façonne à son tour la qualité du revenu déclaré. Les recommandations DART de Deloitte mettent en évidence le jugement clé pour les dispositifs d'IA agentique : la promesse du fournisseur est-elle une obligation de disponibilité permanente (stand-ready) consistant à fournir un accès continu à l'agent, généralement reconnue dans le temps, ou une obligation de livrer une quantité déterminée de résultats probants, généralement reconnue au fur et à mesure de leur réalisation ? Les critères de succès et les droits de report comptent ici, et les crédits de résultat prépayés peuvent être non remboursables sur une base d'utilisation ou perte ou remboursables, ce qui modifie le comportement du revenu différé et de la contrepartie variable.[4]

Les éléments probants d'utilisation doivent également être rattachés au compteur réellement en vigueur, car les compteurs eux-mêmes évoluent. GitHub Copilot, par exemple, mesure les interactions par jetons d'entrée, de sortie et mis en cache à des tarifs qui varient selon le modèle, les convertit en crédits IA où un crédit équivaut à un centime américain, inclut une allocation par plan et facture l'utilisation au-delà de cette allocation par jeton, tandis que la complétion de code reste hors du compteur de crédits.[5] Un jeu de données d'utilisation construit sur un ancien compteur peut être inutilisable pour prévoir le compteur actuel. Les outils d' analyse de documents financiers aident les équipes de transaction à extraire ces conditions de contrats denses et à les recouper avec les fichiers d'utilisation.

Les schémas suivants devraient déclencher des tests approfondis avant d'atteindre le comité d'investissement.

Le schéma derrière plusieurs de ces signaux est l'allocation du risque. Sur les 65 entreprises analysées par AlixPartners, 53 font porter le risque de performance au client, 8 le partagent, et seulement 4 l'assument en tant que fournisseur, ce qui signifie que pour 82 % des entreprises, c'est le client qui subit les conséquences si le logiciel ne tient pas ses promesses.[2] Et dans la tarification au résultat spécifiquement, la partie qui choisit le substitut du succès est celle qui envoie la facture, raison pour laquelle les définitions des résultats méritent le même examen que le prix lui-même.[3]

Pour les professionnels de l'investissement en capital-investissement et capital-risque, les conclusions sur la tarification doivent alimenter directement l'évaluation de la qualité du revenu. S'agissant de la contrepartie variable, Deloitte note que lorsqu'un dispositif se qualifie comme une série de services distincts, les frais basés sur les résultats peuvent être reconnus au fur et à mesure de la réalisation des résultats plutôt que dans le temps, ce qui modifie le calendrier des revenus et rend la croissance déclarée plus sensible aux volumes de résolution.[4] Prévoir l'activité d'une entreprise dont les revenus dépendent de résultats que le client doit atteindre est un exercice différent de la prévision par sièges, et l'analyse de la qualité de l'ARR devrait en tenir compte.

La marge brute constitue la deuxième exposition. Lorsque la tarification ne suit pas le coût variable, l'adoption fait croître les dépenses d'inférence plus vite que les revenus — c'est le piège de la marge que décrit Zuora.[1] La due diligence devrait modéliser le coût de service par unité de facturation, et pas seulement la marge brute globale, et le soumettre à des tests de résistance face à la croissance de l'utilisation. Cela se rattache directement au chantier de due diligence du modèle financier, où les hypothèses d'économie unitaire cachent souvent le risque lié au modèle de tarification.

Troisièmement, la mécanique du NRR et le risque de multiple se concentrent partout où un modèle est en pleine migration. AlixPartners avertit que passer trop tôt à une tarification basée sur les résultats risque de cannibaliser les revenus par siège, tandis que migrer trop tard risque de céder la position sur le marché.[2] Une cible prise entre deux modèles peut afficher un NRR comprimé sur l'ancienne base et une rétention non prouvée sur la nouvelle — ce qui est une question de multiple, pas une note de bas de page.

Repositionnement des prix : corriger le prix réalisé vers le prix catalogue lorsque les remises ont érodé la réalisation.

Repackaging : restructurer les forfaits, les dépassements et les droits d'accès aux modules pour correspondre à la manière dont les clients consomment réellement.

Séquencement de la migration : déplacer les cohortes de clients vers les nouveaux modèles dans un ordre qui protège les revenus par siège tant que la rétention du nouveau modèle n'est pas prouvée.

Ces leviers sont là où la valeur post-acquisition se crée ou se détruit, et les équipes qui conseillent des mandats de conseil en fusions-acquisitions devraient traiter la question du séquencement comme un élément du plan de création de valeur plutôt que comme une arrière-pensée commerciale.

Le cadre ci-dessus n'a d'importance que s'il parvient aux chantiers de l'équipe deal sous une forme structurée et étayée par des preuves. La plateforme soutient ce workflow de bout en bout :

Utilisez Data Room Ingestion pour analyser les contrats clients, bons de commande et grilles tarifaires dans les minutes qui suivent l'ouverture de la data room, afin que les conditions tarifaires entrent dans l'analyse dès le premier jour.

Utilisez l'AI-Analysis Engine pour extraire les conditions tarifaires, les définitions de compteurs et les critères de succès des contrats denses, et pour recouper les données d'usage avec les revenus déclarés.

Utilisez Risk Radar pour faire émerger les risques tarifaires, les évaluer selon leur matérialité et leur pertinence pour la transaction, et les classer aux côtés du reste du registre des risques.

Utilisez le Collaboration Hub pour aligner les chantiers de due diligence commerciale, financière et technologique sur un ensemble unique de questions et de preuves tarifaires.

Utilisez Report Builder pour rédiger des constats étayés par des preuves avec une traçabilité complète des sources, afin que chaque affirmation tarifaire du rapport renvoie à un document de la data room.

Une limite doit être énoncée clairement: Plausity aide les équipes deal à structurer les preuves et à organiser les questions de due diligence, il ne détermine pas automatiquement le bon modèle tarifaire. Ce jugement reste celui de l'équipe, et il est préférable de le faire comme les experts de TechTarget conseillent aux acheteurs de le faire, en faisant passer des cas réels par la tarification avant de signer plutôt qu'en débattant des tarifs affichés.[3] Les équipes deal qui souhaitent voir comment cela s'intègre dans une configuration plus large d'équipe deal étayée par des preuves, ou comment l'IA soutient l'automatisation du workflow de due diligence du tri de la data room à l'enregistrement des risques, constateront que les questions tarifaires ci-dessus s'insèrent directement dans ces workflows.

En pratique, menez le chantier tarifaire en quatre étapes. Premièrement, classez l'unité de facturation et le packaging de la cible à partir des bons de commande plutôt que de la page tarifaire, et notez où sièges, compteurs et frais liés aux résultats se chevauchent. Deuxièmement, appliquez les six questions diagnostiques ci-dessus pour tester l'adéquation avec l'économie du produit et la réalité des achats. Troisièmement, reliez chaque affirmation à un document: contrats, grilles tarifaires, extraits d'usage et mémos de reconnaissance de revenus, en signalant les lacunes comme des constats à part entière. Quatrièmement, traduisez les constats dans le dossier d'évaluation, en montrant ce qu'ils signifient pour la qualité de la croissance, la marge brute, la prévisibilité des revenus et le plan post-acquisition de repositionnement des prix, de repackaging et de séquencement de la migration. Les équipes de due diligence commerciale peuvent intégrer cette structure directement dans le dossier du comité d'investissement.

1. [1] zuora.com — https://www.zuora.com/guides/ai-pricing-models
2. [2] alixpartners.com — https://www.alixpartners.com/insights/102nf2s/outcome-based-software-pricing-hype-or-reality/
3. [3] techtarget.com — https://www.techtarget.com/enterprise-software/feature/Outcome-based-AI-pricing-hits-a-measurement-problem
4. [4] dart.deloitte.com — https://dart.deloitte.com/USDART/home/publications/deloitte/industry/technology/accounting-outcome-based-pricing-agentic-ai
5. [5] docs.github.com — https://docs.github.com/copilot/reference/copilot-billing/models-and-pricing