Comment les agents IA changent la monétisation des données

La tarification de l’accès des agents arrive en troisième

Un client peut cesser d’ouvrir votre application tout en continuant à dépendre de votre plateforme pour accomplir son travail. Pour un éditeur de logiciels, ce changement peut renforcer l’activité ou affaiblir sa position concurrentielle, selon l’actif qu’il conserve sous son contrôle. La première décision consiste donc à déterminer ce que l’entreprise doit conserver : des données propriétaires peuvent justifier un accès restreint, tandis que l’exécution des workflows peut gagner en valeur grâce à un accès plus large et gouverné.

Model Context Protocol (MCP) rend cette décision plus urgente en donnant aux agents IA un moyen standard de se connecter en toute sécurité aux logiciels et aux données d’entreprise. Les agents sont des logiciels capables de récupérer des informations et d’exécuter des actions ; les serveurs MCP fournissent leurs connexions. Depuis son lancement fin 2024, MCP évolue vers un statut de standard par défaut, atteignant plus de 20 000 serveurs moins de deux ans plus tard.

Figure 1. « La croissance des serveurs Model Context Protocol signale son essor comme nouveau standard par défaut pour l’accès agentique aux données. »
Sources : MCP.so (un registre de serveurs) ; Glama.ai ; PulseMCP.

Une adoption plus large rend l’accès des agents important sur le plan commercial, mais chaque éditeur définit encore sa propre politique d’accès. Avant de fixer un prix, une entreprise doit identifier quelles données et quels workflows elle doit rendre disponibles aux logiciels, puis décider si MCP est le bon mécanisme de connexion. La monétisation arrive en troisième. Les décisions prises en amont déterminent ce que l’éditeur conserve et la manière dont les clients dépendront de lui.

Protéger l’actif qui différencie l’entreprise

Pour définir cette frontière, partez de l’actif qui donne aux clients une raison de dépendre de l’entreprise. LinkedIn considère son graphe professionnel comme son principal actif concurrentiel et limite étroitement l’accès programmatique, c’est-à-dire l’accès par logiciel. ServiceNow adopte une approche différente : l’entreprise rend des workflows gouvernés largement disponibles via MCP, facture l’usage et conserve les données opérationnelles au sein de sa plateforme. Ces choix ont un enjeu commercial pour les deux entreprises, car l’accès influe sur les actifs et l’activité qu’elles peuvent monétiser.

Pour LinkedIn, les restrictions protègent les données propriétaires à l’origine de son avantage. Un accès plus simple pourrait permettre à des clients ou à des concurrents d’utiliser le graphe professionnel tout en dépendant moins de l’interface de LinkedIn. ServiceNow tire profit du fait que des agents externes utilisent ses workflows, car l’entreprise fournit toujours l’exécution et la gouvernance, génère des revenus d’usage et conserve les données opérationnelles. L’effet stratégique de l’accès dépend donc de ce qui reste essentiel une fois que le client passe à une autre interface.

Ces exemples offrent aux responsables logiciels un test simple : identifier l’actif à l’origine de l’avantage, puis évaluer comment son exposition modifie la dépendance des clients à son égard. Si les données propriétaires sont centrales, il faut examiner la valeur du maintien du contrôle ; si l’orchestration des workflows, c’est-à-dire la coordination du travail entre plusieurs étapes, et la gouvernance sont centrales, il faut examiner si un accès plus large renforce ces fonctions. L’accès aux workflows et l’autorisation de récupérer des données opérationnelles nécessitent des décisions distinctes. Chaque stratégie peut convenir à son entreprise sans pour autant établir un modèle financier universellement supérieur.

Commencer par la tarification peut masquer cette évaluation, car cela suppose qu’un accès plus simple profitera à l’entreprise. Pour un éditeur dont les revenus dépendent du contrôle de données propriétaires, une disponibilité plus large peut affaiblir l’actif qu’il vend. L’évaluation doit donc couvrir les différentes catégories de données : dossiers clients, analyses propriétaires, données de benchmark, schémas, identifiants et métadonnées de workflow. Un schéma décrit la manière dont les données sont organisées, tandis que les métadonnées de workflow décrivent la manière dont le travail progresse ; chaque catégorie a sa propre valeur stratégique et son propre risque.

L’examen de chaque catégorie peut aussi révéler où l’exposition renforcerait l’entreprise. Les clients attendent de plus en plus un accès aux données d’un fournisseur, et le fait de les fournir peut faire du fournisseur un élément plus profondément intégré à leurs workflows. Leur dépendance peut croître à mesure qu’ils construisent des processus autour des données et des actions disponibles. Là où les clients sont prêts à payer, l’accès crée une opportunité de revenus autour de quelque chose qu’ils valorisent déjà.

Une dépendance accrue s’accompagne toutefois de coûts d’exploitation et de risques. Les clients et les concurrents peuvent contourner l’interface du fournisseur, tandis que les autorisations de lecture et d’écriture augmentent la vulnérabilité en permettant aux agents de récupérer et de modifier des informations. Une activité plus automatisée peut accroître les coûts d’infrastructure et les coûts de télémétrie, c’est-à-dire les dépenses liées à la collecte et au traitement d’informations sur l’activité du système. Les dispositifs de partage de données entraînent également des considérations réglementaires qui doivent être évaluées en parallèle des bénéfices commerciaux.

Ces conséquences deviennent plus difficiles à modifier une fois que les clients et les partenaires construisent des systèmes autour des données disponibles. Retirer l’accès peut perturber leurs processus, de sorte qu’une intégration proposée aujourd’hui peut créer un engagement durable. Avant d’encourager de telles dépendances, l’éditeur doit décider lesquelles il souhaite prendre en charge. Cette décision fixe la frontière dans laquelle une connexion agent doit opérer.

MCP peut réduire l’usage de l’interface tout en gardant la plateforme essentielle

Une fois la frontière d’exposition clarifiée, la question suivante est de savoir comment les agents doivent se connecter. Les interfaces de programmation applicative traditionnelles, ou API, permettent aux logiciels de demander des données ou des actions, mais les développeurs doivent créer des intégrations pour chaque interface et ses points de requête spécifiques. MCP standardise la manière dont les agents trouvent et utilisent les données et les actions d’une application, réduisant le besoin d’une intégration sur mesure pour chaque éditeur. À mesure que l’adoption progresse, cette approche commune réduit le coût d’intégration des logiciels d’entreprise dans les workflows des agents.

Des coûts de connexion plus faibles peuvent encourager l’adoption, car les clients ont moins de travail d’intégration à effectuer avant que leurs agents puissent utiliser une plateforme. Ils peuvent aussi accomplir des tâches sans ouvrir l’application de l’éditeur. C’est le contournement de l’interface : la plateforme exécute toujours le travail pendant que le client interagit ailleurs. Pour une entreprise construite autour d’une exécution gouvernée, l’interface peut perdre du trafic tandis que la plateforme reste centrale dans les opérations.

Le risque commercial change lorsque des agents exécutent le travail via un autre fournisseur, un basculement appelé déplacement de plateforme. Refuser l’accès MCP peut limiter une voie de contournement de l’interface de l’application, mais cela peut aussi rendre la plateforme plus difficile à utiliser pour les agents. Les API traditionnelles restent disponibles, même si elles exigent toujours un travail d’intégration. Un éditeur doit donc arbitrer entre les bénéfices d’une participation plus simple et le risque que les clients choisissent une alternative plus accessible.

Un accès restreint peut ainsi amener les agents à contourner un éditeur, même lorsque la restriction protège un jeu de données de valeur. L’évaluation doit mettre en balance la désintermédiation, c’est-à-dire la perte d’interaction directe avec les clients, et l’exclusion des écosystèmes d’agents, à savoir les agents, les plateformes et les connexions par lesquels les clients organisent le travail. L’examen séparé des catégories de données rend ce compromis plus précis. Un éditeur peut alors envisager un accès gouverné aux workflows tout en conservant le contrôle sur des données de valeur.

L’accès externe laisse aussi à un éditeur la possibilité de proposer sa propre expérience agent. Une entreprise peut prendre en charge des connexions MCP pour des agents conçus ailleurs tout en développant des agents first-party, c’est-à-dire des agents construits sur sa propre plateforme. Les clients disposent alors à la fois d’une expérience conçue par l’éditeur et d’un accès via d’autres agents. L’entreprise peut rivaliser pour l’interaction en contact direct avec le client tout en accompagnant les clients qui choisissent un autre agent.

L’investissement d’Atlassian dans Rovo illustre le versant first-party de cette approche, parallèlement à sa participation à des écosystèmes d’agents externes. Atlassian a un intérêt commercial à retenir les utilisateurs grâce à sa propre expérience agent tout en gardant sa plateforme disponible pour des agents développés ailleurs. Ces investissements servent des objectifs différents : les connexions externes rendent la plateforme plus facile à utiliser, tandis que Rovo donne aux clients une raison de choisir l’agent d’Atlassian. La pertinence durable dépend donc aussi de la qualité et de la valeur de cette expérience first-party.

Tarifer l’accès des agents à l’échelle de l’ensemble du portefeuille de revenus

Une fois les décisions d’exposition et de connexion prises, la tarification devient une question de place de l’accès des agents dans l’activité. Les éditeurs expérimentent encore. Bain, un cabinet de conseil ayant un intérêt commercial à accompagner les entreprises sur la tarification et la stratégie, décrit plusieurs approches : une facturation fondée sur l’usage ou les résultats, des frais pour une capacité supplémentaire ou des limites de débit plus élevées, et des frais pour l’accès lui-même.

Les proportions approximatives de Bain décrivent des approches de facturation plutôt que des parts de marché mutuellement exclusives. La tarification à l’usage facture l’activité, tandis que la tarification au résultat facture le résultat livré. Les frais de capacité permettent aux clients d’utiliser davantage un service, et des limites de débit plus élevées augmentent le nombre de requêtes autorisées sur une période donnée. Avec des frais d’accès, la disponibilité de la connexion devient une partie de ce que le client achète.

Au-delà de ces approches, la plupart des éditeurs appliquent des principes de tarification similaires à MCP et aux API traditionnelles, même si beaucoup, en particulier les entreprises nativement IA dont l’activité est construite autour de l’IA, font varier les tarifs selon l’action effectuée. Ce qu’un agent fait compte donc dans le prix. Un éditeur peut facturer l’accès, l’activité, les résultats, la capacité supplémentaire, des limites de requêtes plus élevées ou différents types d’actions. Le choix doit refléter l’usage client et son effet sur l’activité existante.

Cet effet peut être défavorable même lorsque l’offre d’accès attire des clients. Prenons le cas d’un éditeur qui vend des licences pour utilisateurs individuels, communément appelées licences par siège, et introduit un accès MCP peu coûteux. Les clients pourraient transférer du travail des utilisateurs sous licence vers des agents, réduisant les revenus liés aux sièges tout en augmentant l’activité programmatique. Comme les connexions standardisées facilitent l’adoption des workflows d’agents, elles peuvent accélérer à la fois l’usage de la plateforme et ce transfert de travail.

Le déplacement de revenus qui en résulte doit être évalué à l’échelle du portefeuille de l’éditeur. Une hausse des revenus d’accès peut s’accompagner d’une baisse des dépenses sur d’autres produits, de sorte que l’adoption à elle seule n’établit pas le succès commercial. La tarification de l’accès des agents doit tenir compte de ce que les clients continuent d’acheter et de l’évolution de leur comportement d’achat. Ce qui compte, c’est l’effet sur l’ensemble de l’activité.

La personne qui paie influe aussi sur ce résultat, car le mode de paiement façonne la relation client. Faire payer les clients finaux maintient un lien commercial direct avec l’organisation qui utilise la plateforme. Faire payer les développeurs ou les partenaires de l’écosystème peut réduire les frictions pour ces clients, mais cela peut affaiblir avec le temps la maîtrise de la relation par l’éditeur. Choisir le payeur détermine donc à la fois l’endroit où se situe la facturation et qui gère la relation commerciale continue.

Une fois que les développeurs ont intégré une interface, modifier les tarifs ou les restrictions change aussi l’économie de systèmes dont les clients dépendent déjà. De tels changements ont à plusieurs reprises déclenché des réactions négatives de la part des clients et, dans certains cas, un examen réglementaire. Cette préoccupation est distincte des questions réglementaires associées au partage de catégories de données particulières. Elle apparaît lorsqu’un éditeur révise des modalités d’accès établies après que d’autres ont construit autour d’elles.

Les dépendances établies influent aussi sur la facilité avec laquelle les décisions d’accès et de tarification peuvent être inversées. Les données exposées, les intégrations construites et le rôle de l’éditeur dans les workflows d’agents peuvent être difficiles à retirer, tandis que la tarification peut évoluer à mesure que le marché mûrit. Les réactions des clients limitent néanmoins la rapidité avec laquelle les prix peuvent changer. Une modification nécessaire de l’accès ou de la tarification est donc généralement mieux introduite par une transition progressive qui laisse aux clients et aux développeurs le temps d’adapter leurs systèmes et leurs processus.

Points clés à retenir pour les décideurs

• Définir la politique d’accès avant la tarification : Les éditeurs de logiciels doivent décider quelles données et quels workflows exposer, puis choisir le mécanisme de connexion et le modèle commercial. Ces décisions façonnent la dépendance des clients et créent des engagements qui deviennent plus difficiles à inverser une fois que les clients ont construit des intégrations.
• Protéger l’actif à l’origine de la dépendance des clients : Des données propriétaires peuvent justifier des restrictions, tandis que l’exécution de workflows gouvernés peut gagner en valeur grâce à un accès plus large. Les équipes produit et sécurité ont besoin de politiques distinctes pour les actions de workflow et les différentes catégories de données, en tenant compte de la valeur concurrentielle, des coûts d’exploitation et du risque réglementaire.
• Garder la plateforme essentielle à mesure que les interfaces évoluent : MCP peut aider les agents à utiliser une plateforme même lorsque les clients cessent d’ouvrir son application. Les propriétaires de plateforme doivent mettre cette opportunité en balance avec le risque qu’un accès restreint oriente les clients vers des alternatives plus accessibles ; les agents first-party offrent une autre manière de conserver une interaction directe.
• Tarifer à l’échelle de l’ensemble du portefeuille de revenus : Les équipes finance et produit doivent évaluer si les revenus liés à l’accès des agents compensent les évolutions des licences par siège et des autres achats. Le choix du payeur façonne aussi la relation client, tandis que des changements tarifaires progressifs laissent aux clients et aux développeurs le temps d’adapter les intégrations existantes.