Ton MCP, c'est ta nouvelle homepage. On vient de lancer le nôtre.

On a appris à notre produit à se laisser piloter par une IA en deux semaines. Un nouvel utilisateur qui met en place sa première ligne peut maintenant configurer des cellules d'inspection, enregistrer des caméras, fixer des tolérances et embarquer un opérateur sans jamais ouvrir notre app. Il pointe son agent vers notre MCP, et le travail se fait dans le chat.

Ce n'est pas une fonctionnalité secondaire. C'est le début d'un basculement complet de la façon dont les logiciels sont utilisés. D'ici dix-huit mois, l'interface classique sera l'exception plutôt que la voie par défaut.

Voici ce qu'on a fait, pourquoi ça nous a pris deux semaines au lieu de deux mois, et où ça nous a surpris.

Pourquoi les menus de navigation sont un genre en voie d'extinction

Depuis trente ans, la forme grossière de tout produit B2B SaaS est la même : une sidebar, une top bar, un workspace, et une roue de réglages. L'onboarding pour un nouvel utilisateur signifie lire la doc, cliquer partout, regarder une vidéo, et construire lentement un modèle mental de l'endroit où chaque chose se trouve. Le produit est un endroit qu'on visite et qu'on apprend à parcourir.

Cette hypothèse est en train de céder. La raison est simple : quand un agent peut lire ta doc et appeler tes API, l'utilisateur n'a plus besoin de la navigation. Il dit ce qu'il veut, et l'agent trouve où ça se trouve dans ton produit. La navigation devient de la plomberie que l'utilisateur ne voit jamais, comme le routage des paquets en TCP.

On l'a vu très clairement sur notre propre onboarding. Les nouveaux clients atterrissaient sur un dashboard, se sentaient submergés, et nous pinguaient sur Slack avec les cinq mêmes questions. Mettre en place une inspection signifiait connecter une caméra, choisir une pièce, définir une région d'intérêt, entraîner un modèle, et fixer des tolérances, avec au moins quatre écrans différents au passage. Le produit fonctionnait, et les gens restaient, mais la première heure était un mur d'effort.

Notre équipe customer success portait ce mur sur ses épaules. On s'est donc posé une autre question : et si un nouvel utilisateur n'avait jamais à trouver d'écran en premier lieu ?

Ce qu'est vraiment MCP, en un paragraphe

Model Context Protocol est un standard ouvert d'Anthropic qui permet à n'importe quel agent de parler à n'importe quelle application via un contrat uniforme. Tu exposes un ensemble de tools, chacun étant une fonction typée avec une description claire et un schéma clair, et l'agent décide quel tool appeler quand. Imagine un contrat d'API conçu pour un consommateur LLM plutôt que pour un développeur humain. L'agent lit tes descriptions de tools comme un junior engineer lirait ta doc, et ces descriptions deviennent la nouvelle surface produit.

La raison pour laquelle ça compte : chaque agent, dans chaque client de chat, sait instantanément utiliser ton produit. Tu n'as pas besoin d'intégration Zapier, de GPT custom, de programme partenaire ni de SDK par fournisseur. Tu livres le MCP, et tu es connecté à tout l'écosystème agent d'un coup.

Salesforce vient de produitiser la même idée

Salesforce a annoncé sa plateforme Headless 360 le 17 avril, exposant tout le stack via APIs et MCP. Marc Benioff résume la thèse en cinq mots : « The API is the UI. » La réaction de Jason Lemkin chez SaaStr a été que ce n'est pas un lancement produit mais une description de la façon dont son entreprise tourne depuis six mois. SaaStr opère aujourd'hui sur un Salesforce headless, avec trois humains, une vingtaine d'agents en production et deux agents de niveau exécutif (un AI VP of Marketing et un AI VP of Customer Success) qui lisent et écrivent dans le CRM en continu, alors que personne dans l'équipe n'ouvre l'UI Salesforce un jour donné. SaaStr dépense maintenant environ quinze fois plus en agents qu'en licences Salesforce, et c'est le chiffre le plus utile, parce qu'il dit où la valeur se déplace dans le stack.

C'est la même forme de basculement qu'on décrit ici, juste un étage plus haut. Salesforce-comme-couche-de-données pour SaaStr est ce qu'Enao-Vision-comme-couche-de-données est en train de devenir pour nos clients. Le système d'enregistrement reste où il est, les agents lisent et écrivent via le protocole, et les humains voient les réponses dans le client de chat qu'ils préfèrent. L'UI classique est un chemin que les utilisateurs peuvent prendre quand ils veulent, pas le chemin qu'ils doivent prendre.

Comment on a livré le nôtre en deux semaines

On n'a pas restructuré le produit. On n'a pas monté de nouvelle « équipe MCP ». Un engineer, deux semaines, par-dessus la base de code existante.

Grossièrement, voici comment les jours se sont répartis :

Jour 1 : définir les tools. On s'est assis avec l'équipe customer success et on a listé les opérations qu'un nouvel utilisateur fait vraiment dans sa première heure : enregistrer un appareil, créer une inspection, définir une région, uploader des images de référence, labelliser des bons et mauvais échantillons, lancer l'entraînement, fixer les tolérances, et regarder les résultats. Ça nous a donné environ quinze tools. On a écrit chacun comme une signature typée avec une description en une ligne, et on a traité ces descriptions comme du copy produit, pas comme des commentaires de dev. Une mauvaise description, c'est de la mauvaise UX à l'ère des agents.

Jours 2 à 7 : construire la couche /mcp. On a ajouté un adaptateur fin par-dessus nos services métier existants, en mappant chaque tool MCP à un ou plusieurs appels internes. L'adaptateur est la seule chose que l'agent voit. Il s'occupe de l'authentification, de la validation des paramètres, de la normalisation des erreurs et du rate limiting, puis il forwarde. On n'a délibérément pas laissé l'agent toucher directement à la couche métier, parce qu'on voulait un blast radius propre si une description de tool changeait.

Jours 8 et 9 : frontend. On a ajouté un seul panneau dans l'app montrant le statut de connexion MCP, les tools disponibles, et un bloc de config copy-paste pour Claude Desktop, Cursor, ChatGPT Desktop, et un client stdio générique. Rien de spectaculaire, mais ça enlève le dernier bout de friction « où est-ce que je branche ça ».

Jours 10 à 12 : polish et edge cases. Uploads longs, échecs partiels, idempotence sur les tool calls retentés, chaînes d'erreur parlantes sur lesquelles l'agent peut agir, et un vrai story de rate limit. On a aussi ajouté des messages de progression structurés pour que l'agent puisse raconter au user ce qui se passe pendant des opérations lentes, comme un run d'entraînement.

C'était tout. Pas de nouvelle infra, pas de nouvelle base de données, pas de nouveau modèle d'auth, et environ quatre cents lignes de glue plus les descriptions des tools et un fichier de tests.

Ce qui nous a surpris

On pensait que la partie difficile serait le protocole ou l'intégration agent. Elle ne l'était pas. La partie difficile était la dérive de schéma.

Notre logique métier a grandi sur deux ans. Elle a les petites incohérences que toute vraie base de code accumule : un objet « device » qui veut dire des choses légèrement différentes dans deux contextes, une « inspection » avec cinq champs qui se chevauchent presque, un objet de réglages dont la structure est aux deux tiers un accident historique.

Un utilisateur humain navigue autour de cette dérive sans s'en rendre compte, parce qu'il ne voit qu'un écran à la fois et que l'UI lisse les coutures. Un agent voit tout d'un coup, dans les descriptions de tools, et se mélange. On a dû faire un petit passage sobre dans nos types métier pour qu'ils soient assez cohérents pour être décrits proprement.

Ce passage s'est révélé précieux pour d'autres raisons. Il a fait remonter deux vrais bugs dans l'UI existante, simplifié un flow d'onboarding qu'on voulait nettoyer depuis des mois, et raccourci nos docs API internes d'environ trente pour cent. Construire un MCP est une forcing function pour nettoyer ton modèle métier, dans le même esprit que l'ajout d'une API publique l'était autrefois.

Si tu en démarres un et que ta base de code te résiste, c'est le signe que le MCP n'est pas le vrai problème ; c'est la dérive en dessous.

Ce que ça change pour le business

Trois chiffres qui nous intéressent, trois semaines après le lancement :

Time to first inspection running est passé d'une première session typique de deux heures à moins de vingt minutes pour les utilisateurs équipés d'un agent. Ils décrivent la ligne, la pièce, et le défaut qui les intéresse, l'agent appelle les bons tools, on fait le gros du travail dans le backend, et ils finissent la conversation avec une inspection configurée.

Tickets de support sur la mise en place de la première semaine ont sensiblement baissé. Pas à zéro, mais les faciles (où je trouve ça, comment je fais ceci) sont maintenant répondues par l'agent qui lit nos descriptions de tools. Customer success peut remettre son temps sur les problèmes difficiles, ce qui est exactement ce qu'ils préfèrent.

Sales motion a changé sans qu'on ait à la redesign. Un évaluateur technique chez un prospect ne veut plus de démo, il veut nous brancher dans Claude ou Cursor et faire tourner un vrai workflow lui-même pendant une heure. On envoie la config MCP, il répond oui ou non d'ici vendredi. La boucle d'achat est passée de deux semaines à environ trois jours sur cette persona.

Aucun de ces chiffres n'est énorme isolément. Ensemble, ils signifient qu'on embauche moins de customer success par euro de chiffre d'affaires, qu'on closure plus vite, et qu'on peut consacrer plus d'équipe au produit.

Qui ne devrait probablement pas encore livrer de MCP

Trois exceptions honnêtes, parce que sans elles ce post serait malhonnête.

Si tu n'as aucune sorte d'API ou de couche de service sous ton UI, un MCP n'est pas ton prochain mouvement. Construis l'API d'abord, idéalement comme une API interne fine, puis pose le MCP par-dessus. On a pu faire ça en deux semaines parce que notre produit était déjà API-first sous le capot, même si la plupart des utilisateurs ne voyaient que l'UI.

Si ton produit est un workflow régulé où chaque action doit être attestée par un humain (pense aux dossiers qualité aérospatiaux, aux processus pharmaceutiques GxP, ou aux transactions financières au-dessus d'un seuil), le chemin agent ne t'aide pas, et le MCP créerait surtout des problèmes d'attestation. Attends, observe comment les régulateurs se positionnent sur les actions d'agent, et reste sur la touche.

Si tu es un monolithe legacy sans séparation propre entre logique métier et logique UI, un projet MCP virera au refactor métier à mi-parcours. Ce refactor est peut-être la bonne chose à faire, mais c'est un projet de six mois, pas un projet de deux semaines, et tu devrais le pricer en interne en conséquence.

Pour tous les autres : l'argument pour livrer est plus fort que l'argument pour attendre.

Ce qu'on construit ensuite

La première version de notre MCP est strictement request-response : l'agent appelle un tool, on fait le travail, on renvoie un résultat. Ça mappe proprement sur les tâches d'onboarding et de configuration, et c'est exactement là qu'on a commencé.

La couche suivante, ce sont les tâches agentiques longues, celles qui ne tiennent pas dans un seul aller-retour. Entraîner un nouveau modèle de défaut prend des minutes, auditer une tendance qualité sur une semaine de production prend plus longtemps, et observer une ligne pour un signal inhabituel est ouvert par définition. Ces workflows veulent une autre forme : l'agent lance un job, le job tourne contre notre backend, l'agent est notifié quand quelque chose d'intéressant se passe, et l'utilisateur voit la conversation continuer sans avoir à rafraîchir quoi que ce soit.

On teste ce pattern ce trimestre. Si ça tient, le rythme quotidien d'usage d'Enao Vision passe de « l'utilisateur se logue et regarde le dashboard » à « l'agent fait remonter ce qui compte, l'utilisateur réagit dans le chat, le système se corrige tout seul. » C'est un produit différent de celui qu'on a livré il y a deux ans, et c'est celui sur lequel on parie pour les deux prochaines.

Pourquoi c'est important pour la série

C'est le troisième article de Building Enao Vision, où on partage les décisions d'engineering et de produit derrière l'entreprise. Le fil rouge de la série est le même que celui qui traverse le logiciel en général : la couche qui prenait des humains prend maintenant des agents, et les produits qui s'adaptent le plus vite gagnent.

Dans le post deux, on a migré notre CMS en trois heures en passant le travail à un agent via le MCP de Sanity. Dans ce post, on a fait de notre propre produit quelque chose qu'un agent peut piloter end-to-end. L'arc n'est pas un hasard. C'est le même basculement, vu des deux côtés du contrat.

Si tu construis du logiciel en 2026 et que ton produit est encore une UI à laquelle tu dois apprendre à des humains à naviguer, les dix-huit prochains mois vont être inconfortables. Si tu le construis comme quelque chose qu'un agent peut comprendre, configurer et opérer pour le compte d'un utilisateur, les mêmes dix-huit mois vont être très amusants.

On sait de quel côté du pari on est.