Lonestone est une agence qui conçoit et développe des produits web et mobile innovants intégrant de l'IA.
Nos experts partagent leurs expériences sur le blog. Contactez-nous pour discuter de vos projets !
Depuis l’arrivée des LLMs et des avancées en deep learning, l’intelligence artificielle ne se contente plus de comprendre ou de générer du texte. Elle agit. Elle planifie, elle exécute, elle orchestre. Une nouvelle ère s’ouvre : celle des agents IA capables de manipuler des outils, de prendre des décisions et d’accomplir des tâches complexes en autonomie.
Mais pour que ces agents soient vraiment utiles, il faut qu’ils puissent interagir avec les logiciels qu’on utilise au quotidien. Aujourd’hui, c’est justement ce que permet le Model Context Protocol (MCP). Et pour les éditeurs SaaS, l’enjeu est clair : rendre leurs produits intelligents et actionnables par l’IA, ou risquer de passer à côté de la prochaine vague d’interopérabilité.
De l’API au MCP : un nouveau paradigme
Souvenez-vous du tournant pris au début des années 2010 avec l’explosion des APIs REST. Les applications sont devenues programmables, interopérables, connectées. C’est ce qui a permis à des services comme Stripe, Zapier ou Twilio d’exister.
Le MCP, c’est exactement ce genre de moment. Mais au lieu d’être consommé par des développeurs, ce nouveau standard est pensé pour des agents IA. Il permet à une application d’exposer ses fonctionnalités sous forme de "tools", compréhensibles et utilisables par des modèles comme GPT ou Claude.
L’analogie est simple : une API REST expose des endpoints. Le MCP expose des capacités en langage naturel. Et à la place d’un humain qui code, on a un agent qui décide d’agir en fonction d’une instruction.
Retrouvez la documentation officielle ici : modelcontextprotocol.io/introduction
MCP : comment ça marche
Techniquement, le MCP repose sur un modèle client-serveur.
Côté client, on trouve l’agent IA. Il découvre les tools disponibles, comprend leurs paramètres, puis exécute les bonnes actions. Claude, Cursor, Windsurf ou encore les agents de Zapier sont déjà capables d’interagir via MCP.
Côté serveur, on trouve l’application qui expose ses capacités. Chaque "tool" est défini avec :
un nom et une description : pour aider l’agent à comprendre à quoi ça sert et comment bien l'utiliser,
les paramètres nécessaires : nom, type, obligatoire ou non,
le format de la sortie attendue.
L’agent envoie une requête (via un protocole comme SSE ou Stdio), et le serveur exécute le tool demandé.
En résumé : MCP permet à un agent de piloter n’importe quelle app, sans interface graphique, simplement en comprenant ce qu’elle sait faire.
Pourquoi c’est stratégique pour les éditeurs SaaS
Aujourd’hui, peu d’applications exposent un serveur MCP. C’est donc une opportunité évidente : les éditeurs qui s’y mettent tôt auront un temps d’avance net sur leurs concurrents. Ils seront directement compatibles avec les agents IA qui arrivent en force, et proposeront une expérience utilisateur plus fluide, plus intelligente, plus différenciante.
Implémenter un MCP ne demande pas de refaire son produit. Il suffit d’exposer proprement quelques fonctions clés — celles qui ont de la valeur dans des workflows automatisés : lire des données, créer un objet, déclencher une action.
C’est aussi un levier de monétisation. On peut imaginer des offres premium réservées aux utilisateurs qui veulent connecter leur agent à l’app, ou des modèles freemium avec quota d’usage MCP. Et surtout : ça ouvre la porte à des cas d’usage très concrets.
Des cas d’usage concrets qui parlent aux équipes produit
Prenons quelques exemples. Ils parlent d’eux-mêmes.
Un CRM expose un serveur MCP : un agent IA peut créer une opportunité, mettre à jour une fiche contact, générer un rapport hebdo… sans que l’utilisateur n’ouvre l’app.
Un ATS expose ses fonctions clés : l’agent peut chercher les derniers candidats, rédiger un mail d’approche, puis programmer l’envoi. En trois lignes de prompt.
Un ERP expose ses modules : l’agent peut générer un bon de commande, vérifier un stock, ou créer une facture à partir d’un brief.
Et ce n’est que le début. Le vrai pouvoir du MCP, c’est l’orchestration : enchaîner plusieurs actions, dans plusieurs apps, sans couture. L’IA devient un chef d’orchestre. Elle peut chercher des infos dans Notion, créer des tâches dans Trello, rédiger un email dans Gmail, notifier une équipe dans Slack… le tout dans un seul flux de pensée.
Une interopérabilité fluide, pensée pour l’IA
Le standard MCP a été conçu pour ça : créer une surface d’usage universelle, lisible par les modèles, sans qu’ils aient besoin d’apprendre à chaque fois une logique propriétaire différente. Une fois qu’un modèle comprend le fonctionnement d’un serveur MCP, il peut s’adapter à n’importe quel outil qui le respecte.
Des projets comme Mastra misent à fond sur cette logique. Et des plateformes comme MetaMCP, Zapier MCP, Composio MCP, ou MCP.run permettent déjà de connecter des dizaines, voire des milliers d’apps à des agents via MCP.
Comment s’y mettre : approche concrète
Pour un éditeur SaaS, lancer un serveur MCP peut se faire de manière très progressive.
Identifier les 5-10 fonctions clés de son app qui ont de la valeur quand elles sont pilotées par un agent : lecture de données, création simple, recherche ciblée.
Décrire ces fonctions proprement : quels paramètres ? quelles erreurs possibles ? quelles réponses ?
Choisir une implémentation : open-source (à auto-héberger) ou MCP-as-a-service (plus facile à adopter).
Quelques exemples :
OpenTools : registre de tools en CLI ou Docker
Attention aux pièges : sécurité, permission, documentation
Comme pour les APIs, il faut penser sécurité. Un serveur MCP doit filtrer l’accès, vérifier les permissions, limiter les scopes d’usage. Et il doit documenter ses tools de façon claire pour que les développeurs d’agents puissent les exploiter sans friction.
Bonne pratique : publier une documentation ou une image Docker de démo. Donner accès à quelques scénarios types. Et surtout, tracer les appels pour monitorer et améliorer l’expérience.
Ce que ça change côté utilisateur final
Le plus gros bénéfice, c’est pour l’utilisateur. Il ne jongle plus entre les apps. Il n’a plus besoin d’ouvrir dix onglets pour accomplir une tâche. Il parle à son agent (dans Slack, sur son bureau, dans son éditeur de code), et l’agent agit.
Le workflow devient conversationnel. L’expérience devient fluide. Et l’utilisateur gagne en confort, en productivité, en contrôle.
Le bon moment, c’est maintenant
Les standards comme MCP créent un effet de réseau. Plus il y a de serveurs, plus les agents deviennent puissants. Et plus ils sont puissants, plus les éditeurs ont intérêt à les rejoindre.
C’est le cercle vertueux de l’interopérabilité. Exactement comme avec les APIs REST.
Attendre que tout soit mature, c’est prendre le risque d’arriver après les autres. D’avoir un produit qui ne s’intègre pas bien avec les agents IA. De se faire distancer.
Ce qu’il faut retenir, c’est que le MCP ne demande pas un refactoring massif. C’est une surcouche, une opportunité d’élargir son champ d’usage, d’augmenter la valeur perçue, et de se connecter à ce que sera le SaaS dans 2, 3 ou 5 ans.
En conclusion : le chaînon manquant pour faire agir l’IA
Le MCP, ce n’est pas juste un protocole technique. C’est un standard d’action, un langage commun entre les logiciels et les intelligences artificielles. Et pour les éditeurs, c’est l’occasion de rejoindre dès maintenant la prochaine grande vague d’interopérabilité.
En 2010, ceux qui ont ouvert leur API ont gagné des parts de marché. En 2025, ceux qui exposent un MCP seront prêts pour l’ère des agents.
Si vous éditez un logiciel, posez-vous la question : que pourrait faire un agent IA avec mon produit ? Et surtout : qu’attendez-vous pour lui en donner les clés ?