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 (Large Language Models) et les récentes percées en deep learning, l’intelligence artificielle a changé de nature. Elle ne se contente plus de comprendre ou de générer du texte. Elle agit. Elle planifie, elle exécute, elle orchestre. En clair, elle devient un véritable agent opérationnel.
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 toute autonomie. On passe de l’assistant conversationnel à une intelligence agissante. Ces agents peuvent coder, se connecter à des bases de données, piloter des workflows, automatiser des suites d’actions. Et surtout : ils peuvent apprendre à interagir avec un environnement logiciel inconnu — à condition que cet environnement leur soit lisible.
Mais pour que ces agents soient vraiment utiles, il faut qu’ils puissent interagir avec les logiciels qu’on utilise au quotidien. En clair : il faut leur donner les moyens d’agir dans nos apps métiers, comme un utilisateur le ferait — mais sans interface graphique.
Aujourd’hui, c’est justement ce que permet le Model Context Protocol (MCP). Et pour les éditeurs SaaS, l’enjeu est stratégique : rendre leurs produits intelligents et actionnables par l’IA, ou risquer de passer à côté de la prochaine grande 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 entre elles. Ce sont ces APIs qui ont permis à des services comme Stripe, Zapier ou Twilio de s’imposer comme des standards dans leur catégorie.
Le MCP, c’est exactement ce genre de moment. Une bascule. Un nouveau paradigme. Mais cette fois-ci, ce ne sont plus des développeurs humains qui consomment l’interface : ce sont des agents IA.
Ce nouveau standard permet à une application d’exposer ses fonctionnalités sous forme de "tools" — des capacités décrites en langage naturel, compréhensibles et utilisables par des modèles comme GPT-4o, Claude ou Devin. Plus besoin de documentation complexe : les outils sont auto-décrits, lisibles à la volée.
REST vs MCP : une comparaison plus fine
Une API REST expose des endpoints structurés. Le MCP expose des capacités en langage naturel.
REST est fait pour des humains qui codent. MCP est fait pour des IA qui comprennent.
REST nécessite d’explorer une documentation, de construire manuellement des appels. MCP permet la découverte dynamique : l’agent interroge l’application, comprend ce qu’elle sait faire, et agit en conséquence.
REST exige des efforts de parsing, d’adaptation, de gestion d’erreurs. MCP embarque ses métadonnées (noms, descriptions, paramètres, types, formats), ce qui permet aux modèles de généraliser leur compréhension d’un outil à un autre.
On passe d’un monde d’API conçues pour les développeurs à un monde d’actions conçues pour les intelligences.
Retrouvez la documentation officielle ici : modelcontextprotocol.io/introduction
MCP : comment ça marche
Techniquement, le MCP repose sur un modèle simple : 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, Devin, les agents Zapier ou Windsurf 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 claire,
les paramètres attendus (nom, type, obligatoire ou non),
et le format de la sortie.
L’agent envoie une requête (via un protocole comme StreamableHttp ou Stdio), et le serveur exécute l’action. En retour, il fournit une réponse lisible par l’agent.
En résumé : MCP permet à un agent de piloter n’importe quelle app, sans interface graphique, en comprenant simplement ce qu’elle sait faire.
Pourquoi c’est stratégique pour les éditeurs SaaS
Aujourd’hui, très peu d’applications exposent un serveur MCP. Et c’est précisément là que réside l’opportunité. Les éditeurs qui s’y mettent tôt bénéficieront d’un avantage compétitif net :
Compatibilité native avec les agents IA.
Intégration fluide dans des workflows autonomes.
Meilleure découvrabilité dans les marketplaces de tools pour IA.
Pas besoin de tout refaire. Implémenter un MCP ne nécessite pas un refactoring complet du 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 d’agents.
Des quotas gratuits puis payants pour l’usage de tools via MCP.
Des intégrations natives proposées comme upsell.
Et surtout : cela ouvre la porte à des cas d’usage concrets, qui parlent immédiatement aux équipes produit.
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.
Imaginez une IA qui :
cherche une information dans Notion,
crée une tâche dans Trello,
envoie un mail de relance dans Gmail,
notifie une équipe dans Slack…
Le tout sans que personne n’ouvre aucun outil. Juste à partir d’un objectif formulé.
Une interopérabilité fluide, pensée pour l’IA
Le standard MCP a été conçu pour créer une surface d’usage universelle, lisible par les modèles. Une fois qu’un agent comprend le fonctionnement d’un serveur MCP, il peut s’adapter à n’importe quel outil qui le respecte.
On mutualise l’intelligence : une fois la grammaire MCP acquise, un agent peut comprendre toutes les apps MCP-compatibles, sans apprentissage spécifique.
Plusieurs projets misent déjà sur cette logique :
Mastra : plateforme d’exposition de tools métiers.
Composio MCP : pont entre apps SaaS et IA.
MetaMCP, Zapier MCP, MCP.run : hubs de connections prêts à l’usage.
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 toute API, exposer un serveur MCP demande rigueur et précautions.
Sécurité
Un serveur MCP doit intégrer une authentification sérieuse (clé API, OAuth, token), des restrictions d’accès, et un contrôle fin des droits. On ne veut pas qu’un agent IA déclenche une suppression de compte sans validation, même par erreur.
Permissioning
Tous les tools ne doivent pas être accessibles à tous les utilisateurs. Pensez rôles, scopes, quotas, et environnements sandbox pour tester sans impacter les données réelles.
Documentation
Un tool mal décrit est inutilisable. Soignez les descriptions, précisez les paramètres, les erreurs possibles et les formats de sortie. Proposer une démo (Docker, playground, README clair) fait toute la différence pour encourager les intégrations.
Ce que ça change côté utilisateur final
Le plus grand bénéfice, il est pour l’utilisateur.
Fini le temps où il fallait jongler entre dix onglets, copier-coller des infos d’un outil à l’autre ou suivre des procédures fastidieuses. Avec le MCP, l’utilisateur s’adresse simplement à son agent — dans Slack, sur son bureau, dans son éditeur de code — et celui-ci exécute les actions à sa place, en temps réel.
Le workflow devient conversationnel. L’expérience est plus fluide, plus intuitive, presque invisible. L’utilisateur ne pilote plus les apps, il exprime une intention — et l’agent la réalise, en coulisses.
Résultat : plus de confort, plus de productivité, moins de frictions. Et une vraie montée en puissance dans la manière d’interagir avec son environnement logiciel.
Le bon moment, c’est maintenant
Les standards comme le MCP créent un effet de réseau puissant. Plus il y a d’applications qui exposent des tools, plus les agents IA deviennent compétents. Et plus les agents deviennent performants, plus les éditeurs ont intérêt à rendre leurs logiciels compatibles. C’est un engrenage vertueux — mais aussi une course.
On a déjà vu ce film : c’était en 2010, avec les APIs REST. Ceux qui ont ouvert leurs services en premier ont capté l’attention des développeurs, sont devenus des briques incontournables, et ont bâti leur croissance sur cette interopérabilité.
Aujourd’hui, le MCP joue ce rôle pour l’ère des intelligences artificielles. Et les signaux sont clairs : la bascule est en train de se faire. Attendre que l’écosystème soit mature, c’est prendre le risque d’être invisible aux yeux des agents, et donc de leurs utilisateurs. C’est offrir à vos concurrents une avance qu’il sera difficile de rattraper.
Ce qu’il faut bien comprendre, c’est que le MCP ne demande pas une refonte. C’est une surcouche. Un pas stratégique pour ouvrir son logiciel à un nouveau monde d’interactions, de cas d’usage, de valeur perçue.
Agir maintenant, c’est s’assurer que son produit sera compatible avec l’intelligence qui vient. C’est se connecter — dès aujourd’hui — à ce que sera le SaaS dans 2, 3 ou 5 ans. Et éviter d’être relégué dans un monde où les apps non pilotables deviennent… secondaires.
Et demain : à quoi ressemblera un SaaS “MCP-first” ?
Probablement à un logiciel sans interface principale. L'agent sera l’interface. L’utilisateur final ne manipulera plus des menus, mais des intentions.
Les équipes produit penseront “actionabilité par les modèles” dès la conception :
Quelle action exposer ?
Comment la nommer ?
Comment la documenter pour une IA ?
Les UX designers travailleront en tandem avec les ingénieurs IA, pour concevoir une grammaire d’usage fluide. Et le design deviendra une affaire de lisibilité… non plus pour des humains, mais pour des intelligences.
Ce sera une autre manière de penser le logiciel. Plus modulaire. Plus composable. Plus intelligent.
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 ?