+150 XP

Ce que l'IA agentique casse dans le business model du SaaS

# Ce que l'IA agentique casse dans le business model du SaaS

Un agent IA vient de faire le travail d'un utilisateur CRM facturé 150 $ par siège sans jamais se connecter. Il a appelé l'API, mis à jour les enregistrements, déclenché le workflow, puis s'est arrêté. Pas de dashboard. Pas de clics. Pas d'« utilisateur ».

C'est la menace silencieuse qui pèse sur beaucoup de modèles de pricing SaaS. Si votre revenu dépend d'humains qui se connectent et cliquent, l'IA agentique change le calcul.

Définissons d'abord le terme, puis regardons précisément ce qui craque.

Ce que « IA agentique » veut dire ici

Un agent est un système d'IA qui agit vers un objectif sans qu'un humain pilote chaque étape. Il lit le contexte, décide quoi faire, et exécute : interroger des données, remplir des formulaires, appeler d'autres logiciels.

Comparez deux modes :

  • Mode copilot : un humain est dans l'UI (user interface, les écrans et les boutons), et l'IA suggère. L'humain clique toujours sur « envoyer ».
  • Mode agent : l'IA opère le logiciel elle-même, souvent via l'API (Application Programming Interface, la porte machine-à-machine d'un produit), sans humain au poste.

La plupart des modèles de pricing et de défensibilité SaaS supposent le mode copilot. Les agents supposent que vous avez construit pour des machines. Tout est là.

Rupture n°1 : la licence par siège

Le modèle de pricing SaaS dominant est le per-seat : vous payez par utilisateur humain nommé et par mois. Il fonctionne parce que le logiciel a historiquement exigé un humain pour l'opérer.

Les agents retirent l'humain de la boucle.

Prenez un outil de support facturé 80 $ par siège d'agent. Une entreprise avec 40 conseillers support humains paie 40 sièges. Elle déploie maintenant des agents IA qui résolvent les tickets de niveau 1 de façon autonome. Elle descend à 15 sièges humains. Le volume de travail a *augmenté*. Le revenu par siège a *baissé*.

C'est l'inversion de fond : les agents découplent la valeur délivrée des sièges occupés.

Les éditeurs qui bougent le plus vite repricent déjà autour de ça. Vous verrez :

  • Usage-based pricing : facturer à l'appel API, au ticket résolu, à l'exécution de workflow.
  • Outcome-based pricing : facturer à la résolution réussie ou au rendez-vous décroché.
  • Sièges d'agents : traiter un agent IA comme un « utilisateur » facturable avec son propre niveau de licence.

Aucun de ces modèles n'est magique. Le pricing à l'usage rend le revenu plus difficile à prévoir (pour vous comme pour la finance de votre client). L'outcome pricing vous oblige à définir et mesurer proprement le résultat, ce qui est souvent la partie dure. Mais le per-seat seul est exposé.

Si vous voulez une base solide sur les modèles de pricing avant d'y toucher, les ressources d'OpenView sur l'usage-based pricing sont un bon point de départ gratuit.

Rupture n°2 : le moat de l'UI

Beaucoup de produits SaaS sont défendables parce que leur interface est sticky. Les utilisateurs apprennent les écrans. Les admins acquièrent des automatismes. Changer implique de reformer tout le monde. Cette friction est un moat (un avantage concurrentiel durable).

Les agents se fichent de votre UI.

Un agent interagit via l'API. Pour un agent, un dashboard magnifiquement conçu et un simple endpoint de données sont la même chose : une interface qu'il appelle. Les années passées à polir le parcours de clics deviennent sans objet pour l'acheteur qui tourne avec des agents.

Pire : si un concurrent expose une API plus propre et mieux documentée, un agent peut basculer dessus avec un changement de configuration. Pas de reformation. Pas de conduite du changement. Le coût de switch sur lequel vous comptiez s'évapore discrètement.

La conséquence inconfortable

Si l'UI n'est plus le moat, qu'est-ce qui l'est ? Pour le SaaS de l'ère des agents, la défensibilité se déplace vers :

  • La donnée propriétaire dont l'agent a besoin et qu'il ne trouve pas ailleurs.
  • Les actions que vous seul pouvez exécuter (vous possédez l'intégration, la licence, la connexion régulée).
  • La fiabilité et les permissions auxquelles l'agent peut se fier pour agir en pilote automatique.

Ce dernier point compte plus qu'on ne le croit. Un agent qui agit de façon autonome a besoin de garde-fous : ce qu'il a le droit de faire, des plafonds de dépense, des logs d'audit. Les éditeurs qui rendent l'opération par agent *sûre* deviennent le choix par défaut de confiance.

Rupture n°3 : system of record contre system of action

Voici le recadrage qui relie tout.

Un system of record est l'endroit où vit la donnée : le CRM, la plateforme RH, le grand livre de facturation. Sa valeur, c'est d'être la source de vérité de confiance. Historiquement, cela suffisait, parce que les humains s'y connectaient pour lire et modifier.

Un system of action est l'endroit où le travail se *fait* : il reçoit une instruction et exécute un changement à travers les systèmes.

À l'ère humaine, un même produit pouvait être les deux. Vous vous connectiez au CRM pour consulter (record) et pour mettre à jour une affaire (action).

Les agents séparent les deux.

Les agents adorent les systems of action qu'ils peuvent appeler par programme. Ils sont indifférents aux systems of record qui n'offrent qu'un joli écran en lecture seule. Si votre produit est un system of record avec une belle UI mais une API faible, un client piloté par agents vous traite comme une base de données passive, et les bases de données se commoditisent.

À quoi ressemble un repositionnement « API-first »

API-first signifie concevoir le produit de sorte que chaque capacité soit disponible via l'API, l'UI n'étant qu'un client parmi d'autres de cette API (et non la seule porte d'entrée).

Concrètement, demandez-vous :

  • Un agent peut-il faire *tout* ce qu'un utilisateur humain fait, via votre API ? Ou certaines actions clés sont-elles réservées à l'UI ?
  • Votre API est-elle assez bien documentée pour qu'un agent (ou le développeur qui le branche) l'utilise sans appeler votre support ?
  • Proposez-vous des scopes et des permissions clairs pour qu'un client laisse un agent agir dans des limites définies ?

Un exemple retail : un SaaS de gestion des retours. En tant que system of record, il stocke les demandes de retour et les affiche à l'écran. En tant que system of action, il expose un endpoint du type « traite ce retour, rembourse le client, remets l'article en stock, informe le transporteur ». C'est la seconde version qu'un agent paiera pour continuer à appeler.

Voici la différence, en clair :

System of record (UI-first):
  Human logs in → reads dashboard → clicks "Refund" → done

System of action (API-first):
  Agent → POST /returns/{id}/process
        → {refund: true, restock: true, notify_carrier: true}
        → 200 OK, action executed + audit log entry

La version API est celle qui survit quand l'humain quitte le siège.

Vérification des acquis

1. Quelle est la distinction fondamentale entre le « mode agent » et le « mode copilot » telle que décrite dans la leçon ?

2. Pourquoi l'IA agentique menace-t-elle spécifiquement le modèle de pricing SaaS per-seat ?

3. Un outil de support constate que le volume total de tickets d'un client augmente alors que le nombre de sièges humains payés chute fortement après le déploiement d'agents. Qu'illustre le mieux ce scénario ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses sur les approches de pricing adoptées par les éditeurs en réponse à l'IA agentique.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses sur les raisons pour lesquelles les hypothèses SaaS traditionnelles sont remises en cause par les agents.

Sélectionnez toutes les réponses correctes.

Quoi faire concrètement

Vous ne reconstruisez pas votre entreprise du jour au lendemain. Vous vous repositionnez délibérément.

1. Auditez vos actions UI-only

Listez tout ce qu'un utilisateur peut faire de précieux dans votre produit. Marquez ce qui est disponible via API et ce qui est UI-only. Chaque action UI-only est un endroit inaccessible à un agent, donc un client qui tourne avec des agents ne peut pas vous utiliser pleinement. Comblez ces trous en premier.

2. Repensez le pricing avant que vos clients ne vous y forcent

Si les agents d'un client se mettent à faire le travail de dix sièges, il *va* remarquer qu'il surpaie des logins. Prenez les devants. Modélisez ce que donnerait un palier usage-based ou hybride. Beaucoup d'éditeurs atterrissent sur un hybride : un abonnement plateforme plus l'usage, ce qui garde un revenu prévisible tout en captant le volume généré par les agents.

Ne promettez pas de résultats de revenu précis à votre board sur la base de ces modèles. Le calendrier d'adoption des agents est réellement incertain en 2026 : traitez les projections comme des scénarios, pas comme des prévisions.

3. Devenez le system of action de confiance

Publiez une documentation d'API propre. Ajoutez des permissions fines pour que les clients laissent les agents agir sans risque. Fournissez des logs d'audit pour qu'une équipe conformité puisse faire confiance aux actions autonomes. Envisagez de supporter les standards émergents d'intégration d'agents (comme le Model Context Protocol, un standard ouvert pour connecter les systèmes d'IA aux outils et aux données) afin que les agents se branchent chez vous avec moins de travail sur mesure.

4. Protégez le moat que les agents ne peuvent pas contourner

Renforcez la donnée propriétaire, les intégrations exclusives et les actions que vous seul êtes autorisé ou connecté à exécuter. Ce sont elles qui survivent quand l'UI cesse de compter.

Quand l'UI gagne encore

Ne surcorrigez pas. Les humains tranchent encore les cas de jugement, gèrent les exceptions et approuvent les actions à fort enjeu. Une UI bien conçue pour la *supervision* (valider ce que les agents ont fait, repérer les erreurs, fixer la politique) devient plus précieuse, pas moins.

Le changement n'est pas « tuez l'UI ». C'est « arrêtez de supposer que l'UI est le seul canal par lequel la valeur sort de votre produit, et arrêtez de pricer comme si un humain était toujours au poste ».

Points clés

  • Le pricing per-seat est exposé. Les agents délivrent de la valeur sans occuper de sièges : un revenu adossé aux logins humains peut baisser pendant que la charge de travail monte. Modélisez dès maintenant l'usage-based, l'outcome-based ou l'hybride.
  • Le moat de l'UI s'affaiblit à mesure que les agents se déploient. Les agents opèrent via API et sont indifférents au soin apporté à l'interface : l'API plus propre d'un concurrent peut déclencher un switch à faible friction.
  • Devenez un system of action, pas seulement un system of record. Les bases de données passives se commoditisent ; les produits qui exécutent des actions via API sont payés pour continuer à tourner.
  • Chaque action UI-only est un angle mort. Auditez votre produit et assurez-vous qu'un agent peut faire via l'API tout ce qu'un humain fait dans les écrans.
  • Les nouveaux moats sont la donnée, les actions exclusives et la confiance. Donnée propriétaire, actions que vous seul pouvez exécuter, et opération par agent sûre, auditée et permissionnée : voilà ce que les agents ne peuvent pas contourner.

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.

Précédent

Pricing et packaging de l'IA dans un monde per-seat