Votre produit dans leur assistant : l'entonnoir SaaS perd ses trois premières marches

Une indépendante veut savoir ce que Marc lui doit ce mois-ci.

Premier parcours. Elle cherche un logiciel de facturation, tombe sur une page d'accueil, lit trois arguments, clique sur « Essai gratuit », remplit un formulaire, valide son adresse, atterrit sur un tableau de bord vide qui lui propose d'importer ses clients. Elle referme l'onglet. Trois jours plus tard elle reçoit un courriel de relance qu'elle n'ouvre pas.

Second parcours. Elle colle une URL dans les connecteurs de son assistant, valide un écran, pose sa question, obtient le montant. Quarante secondes. Elle n'a jamais vu votre page d'accueil, elle ne connaît pas votre nom et elle utilise votre produit tous les jours depuis.

Depuis vingt ans, l'acquisition SaaS consiste à faire venir quelqu'un chez vous. Un assistant renverse le trajet : votre produit va chez lui, dans l'outil qu'il a déjà ouvert. Votre entonnoir perd ses trois premières marches. Ce qui reste est plus court, plus difficile à mesurer et plus dur à défendre.

Cet article est destiné aux fondateurs qui se demandent s'il faut y aller, quoi en attendre et par où commencer. Il tient volontairement le niveau de la décision plutôt que celui du protocole. C'est la conversation que j'ai le plus souvent en ce moment au démarrage d'un produit web où l'IA est une fonctionnalité, avant qu'une ligne soit écrite.

Ce qui a changé, en deux chiffres

Le premier chiffre dit que le rayon est gratuit. J'ai paginé l'API du registre officiel MCP le 18 septembre 2026 : 33 350 serveurs uniques, dont 9 812 publiés sur les dix-huit premiers jours du mois. Trois comptes en publient à eux seuls 15 %. Il n'y a ni validation préalable, ni quota, ni coût. La barrière d'entrée est nulle, ce qui déplace toute la difficulté sur le fait d'être choisi.

Le second chiffre dit que l'installation a disparu. Voici, mois par mois, la part des serveurs publiés qui ne demandent rien à télécharger, juste une URL à coller :

En six mois, l'écosystème est passé de « clonez ce dépôt » à « collez cette adresse ». C'est la condition matérielle de tout le reste. Il n'y a plus rien à configurer, donc plus rien pour justifier un parcours d'installation de trente minutes, ni de votre côté ni du leur.

Votre entonnoir perd ses trois premières marches

Mettez les deux parcours côte à côte, étape par étape.

Trois lignes de ce tableau méritent qu'on s'y arrête.

L'état vide disparaît. C'est le premier tueur d'activation en SaaS et il cesse d'exister. Un tableau de bord vide demande à l'utilisateur de fournir un effort avant d'avoir reçu quoi que ce soit. Dans une conversation, l'ordre s'inverse : la personne arrive avec une question déjà formulée, votre produit y répond, la valeur précède l'effort. Tout ce que votre équipe produit a construit pour combler cet écart, les données de démonstration, les visites guidées, les listes de tâches d'accueil, les séquences de relance, devient sans objet.

La découverte ne vous appartient plus. Votre utilisatrice n'a pas comparé trois solutions sur une page de tableau comparatif. Son assistant a choisi pour elle parmi les outils dont il dispose, en lisant leurs noms et une ligne de description. Le travail de positionnement ne disparaît pas, il se comprime dans une phrase lue par une machine. J'ai détaillé ce mécanisme de sélection dans l'article sur le chargement des outils à la demande : au-delà de quelques dizaines d'outils disponibles, les clients ne les montrent plus tous au modèle, ils lui donnent un index et une recherche.

L'habitude est offerte. La rétention en SaaS consiste à faire revenir quelqu'un dans une application qu'il a tendance à oublier. Ici, la surface est déjà ouverte tous les matins pour d'autres raisons. Vous n'avez pas à créer l'habitude, vous avez à vous rendre utile dans une habitude qui existe.

Trois questions à trancher avant d'écrire une ligne

Aucune de ces trois questions n'est technique. Les trois décident du résultat.

Question 1 : votre produit est-il un verbe ?

Relancer un client, chercher un document, créer un devis, vérifier un stock : ces gestes se traduisent en outils qu'un assistant peut appeler. Un tableau de bord, un espace de travail, une vue Kanban : non. Ce sont des surfaces. Une surface ne s'appelle pas, elle se regarde.

Le test tient en un exercice. Nommez trois choses que fait votre produit, en trois mots chacune, avec un verbe à l'infinitif en premier. Si vous y arrivez sans effort, vous avez vos trois premiers outils. Si vous butez, votre valeur réside dans l'interface elle-même et vous livrerez un serveur que personne n'appellera.

Cette question en cache une plus profonde, qui vaut d'être posée même si vous ne faites jamais de serveur MCP. Un produit dont la valeur tient entièrement dans son interface est un produit dont la valeur tient entièrement dans une chose que l'IA sait désormais reproduire en quelques heures.

Question 2 : que mettez-vous avant le mur ?

L'écran de consentement est le nouveau formulaire d'inscription. Il convertit moins bien, parce qu'il demande plus, plus tôt, avec une formulation plus inquiétante : au lieu d'une adresse et d'un mot de passe, il annonce qu'un logiciel va accéder à vos données. C'est l'endroit exact où votre activation meurt.

La seule parade consiste à mettre de la valeur avant lui. Qu'est-ce qui, dans votre produit, peut fonctionner sans compte ? Un calcul, une simulation, une recherche dans vos données publiques, une réponse à une question de référence. Vous laissez les premiers appels passer, la personne constate que ça marche puis l'authentification arrive quand elle veut agir sur ses propres données. C'est un arbitrage de produit plutôt que d'ingénierie. Il se tranche avant la première ligne de code.

Une précision qui vous évitera une erreur coûteuse : laisser passer les premiers appels ne veut pas dire se passer d'authentification. Un audit publié en 2026 relève que 25 % des serveurs MCP publics n'en ont aucune et que 53 % reposent sur des clés statiques à longue durée de vie. Vous héritez de la réputation de sécurité de cette catégorie. C'est aujourd'hui un vrai coût d'acquisition auprès des équipes qui décident.

Question 3 : qui paie quand c'est une machine qui appelle ?

Le prix par siège repose sur une hypothèse simple : un humain, un identifiant, un abonnement. Un assistant qui appelle vos outils cent fois dans la journée pour une seule personne fait sauter le rapport entre l'usage et le nombre de sièges. Dans l'autre sens, une seule licence peut désormais servir une équipe entière si la configuration voyage dans l'organisation.

Il ne s'agit pas de tout basculer à l'usage demain matin. Il s'agit de savoir, avant d'ouvrir ce canal, ce que vous facturez : un accès, un volume d'appels, ou un résultat. Ouvrir le canal d'abord et se poser la question ensuite, c'est découvrir en même temps ses premiers utilisateurs sérieux et le fait qu'ils ne rentrent dans aucune de vos grilles.

Cinq leviers qui coûtent une semaine

Ces cinq leviers ont un point commun : ils sont simples, prévus par le protocole et presque personne ne les utilise. Ce sont ceux sur lesquels j'insiste en cadrage, parce que le rapport entre l'effort et l'effet sur l'activation y est le meilleur.

Levier 1 : livrez le menu avec la cuisine

Le protocole permet à un serveur de fournir des points de départ tout faits, que l'hôte affiche à l'utilisateur sous forme de commandes à choisir. C'est votre guide de démarrage, livré par le canal lui-même, affiché au moment exact où la personne se demande quoi faire de ce qu'elle vient de brancher.

C'est la primitive la plus délaissée de MCP. Le tutoriel officiel la cite parmi les trois concepts de base, puis construit un serveur qui n'en contient aucune. Pendant que tout le monde soigne ses outils, la case « voici ce que vous pouvez me demander » reste vide chez la quasi totalité des serveurs publiés.

Levier 2 : posez la question au moment de la question

Le protocole permet aussi à votre serveur de réclamer une information pendant l'exécution, au lieu de l'exiger avant. La différence en taux de complétion est la même qu'entre un formulaire de douze champs affiché à l'entrée et une question posée quand elle devient nécessaire.

Concrètement, chaque champ que vous demandiez à l'inscription devient une question que vous ne poserez qu'aux personnes qui vont assez loin pour en avoir besoin. Le reste de votre formulaire, vous pouvez le supprimer.

Levier 3 : faites porter l'étape suivante par chaque réponse

Tout ce que renvoie votre produit est relu par l'assistant puis reformulé à l'utilisateur. Une réponse d'outil qui se termine par une suggestion d'étape suivante sera relayée, en langage naturel, au moment où la personne vient d'obtenir un résultat.

C'est le courriel d'onboarding le moins cher que vous écrirez jamais, avec un taux d'ouverture de cent pour cent et un délai de zéro seconde. Le garde-fou : cette place se respecte. Une réponse d'outil qui fait de la promotion au lieu de rendre service apprend au modèle à préférer un concurrent.

Levier 4 : un utilisateur installe, l'équipe hérite

La configuration d'un serveur se range dans un fichier que l'on peut versionner avec un projet, ou dans les connecteurs d'une organisation. Un développeur l'ajoute au dépôt, chaque personne de l'équipe qui récupère le code se voit proposer de l'activer. Un administrateur l'active pour son organisation, tout le monde l'a le lendemain matin.

C'est la boucle de diffusion la plus efficace du canal et elle ne demande aucun travail supplémentaire : il suffit que votre documentation montre la version partageable de la configuration plutôt que la version individuelle. Un acheteur, N utilisateurs.

Levier 5 : votre interface dans leur conversation

Depuis janvier 2026, une extension officielle du protocole, coécrite par des mainteneurs d'Anthropic et d'OpenAI, permet à un serveur d'afficher sa propre interface directement dans la conversation. Vos composants, vos couleurs, vos boutons, dans un cadre isolé que l'hôte affiche à la suite de la réponse. L'utilisateur clique dans votre produit sans quitter ChatGPT ou Claude. Le modèle reste au courant de ce qu'il vient de faire.

C'est l'extension la plus largement adoptée du protocole, rendue par Claude sur le web et en application, par ChatGPT, par VS Code et par Cursor. Elle récupère ce que les quatre leviers précédents vous font abandonner : votre marque, votre ergonomie, la reconnaissance visuelle. Un utilisateur qui voit votre interface se souvient de votre nom.

Ce que vous perdez

Ce canal se paie, et il vaut mieux connaître le prix avant d'ouvrir.

La marque. Sans le levier 5, votre produit devient une voix dans l'application de quelqu'un d'autre. L'utilisatrice du début obtient son montant, elle est satisfaite et elle serait incapable de citer votre nom. Le jour où un concurrent propose le même outil, il n'y a aucune préférence à surmonter.

La mesure. Il n'y a pas de référent, pas de balise, pas de parcours à reconstituer. Vos outils d'analyse ne verront rien. Si vous voulez savoir ce que ce canal vous apporte, personne ne le fera à votre place : il faut compter les appels par outil, identifier les clients qui vous interrogent et construire vous-même l'entonnoir, dès le premier jour. Faute de quoi vous piloterez à l'aveugle un canal dont vous ne saurez pas dire s'il fonctionne.

Le prix au siège. Voir la question 3. Ce canal vous vaudra une refonte de grille tarifaire, plus tôt que vous ne l'imaginez.

Le contrôle de votre visibilité. Votre outil n'est montré au modèle que s'il sort d'une recherche que vous ne possédez pas, dans un index que vous n'administrez pas, face à 33 349 autres serveurs. Vous pouvez travailler vos noms et vos descriptions, vous ne pouvez pas acheter la première place.

La relation. Pas d'adresse récupérée, pas de séquence de bienvenue, pas de canal direct. Vous êtes un outil dans un catalogue et la personne qui vous a branché ne vous doit rien.

Aucun de ces points n'est rédhibitoire. Chacun invalide une partie de ce que votre équipe sait faire, ce qui est une raison suffisante pour en parler avant de livrer, plutôt qu'après.

Ce que je ferais cette semaine

1. Écrire les trois verbes. Trois gestes de votre produit, trois mots chacun, verbe en premier. Si l'exercice résiste, arrêtez là et gardez la question pour votre prochaine revue de stratégie.
2. Écrire la ligne. Une phrase par outil, dans les mots de vos utilisateurs plutôt que dans votre vocabulaire interne. C'est la version la plus courte de votre positionnement. C'est celle que lira la machine qui vous choisit.
3. Tracer le mur. Décider ce qui fonctionne sans compte et ce qui l'exige. Écrire la règle noir sur blanc avant que quiconque code.
4. Livrer trois points de départ. Les trois questions que vos meilleurs clients posent dans leur première semaine, fournies comme des commandes prêtes à choisir.
5. Relire vos réponses d'outil. Chacune doit pouvoir se terminer par une étape suivante utile. Écrivez-les comme vous écririez une réponse de support, pas comme une sortie d'API.
6. Publier la configuration partageable. Dans votre documentation, montrez d'abord la version qui se versionne avec un projet.
7. Poser le compteur. Appels par outil, par client, par jour, depuis le premier appel. Sans lui, la question « est-ce que ça marche ? » restera sans réponse dans six mois.
8. Trancher la grille. Ce que vous facturez sur ce canal, décidé avant d'avoir des utilisateurs dessus.

Sept de ces huit points sont du travail de produit et de marketing. Un seul demande un développeur.

Conclusion

Le canal est ouvert, il est gratuit et il est déjà encombré. Ce qui s'y gagne ne se gagne pas avec un budget publicitaire mais avec trois verbes justes, une ligne de description écrite pour être trouvée et une première réponse qui tombe avant que la personne ait eu à fournir quoi que ce soit.

C'est une bonne nouvelle pour les équipes qui savent formuler ce que fait leur produit. C'en est une mauvaise pour celles dont la valeur tenait surtout à l'écran d'accueil.

Votre utilisatrice n'ouvrira peut-être jamais votre application. Elle peut quand même devenir votre meilleure cliente.