Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la façon dont un agent IA découvre et appelle des outils extérieurs. Son intérêt n'est pas technique mais économique : un outil exposé une fois devient utilisable par n'importe quel agent compatible, au lieu d'être réécrit pour chaque plateforme.

Nous exposons 643 outils MCP en production au 18 août 2026. Voici ce que ça change, et les six leçons que ça nous a coûtées.

Le problème que ça résout

Avant, chaque plateforme d'agent définissait sa propre façon de déclarer un outil. Exposer votre CRM à trois agents différents signifiait écrire trois adaptateurs, et les maintenir tous les trois.

Le MCP pose un contrat commun : le serveur déclare ses outils, nom, description, schéma d'entrée, et le client les découvre à l'exécution. Un outil, tous les agents compatibles.

Ce que ça change concrètement : l'intégration cesse d'être un projet par plateforme et devient un actif réutilisable. C'est un gain de maintenance, pas une capacité nouvelle : tout ce que fait un serveur MCP était faisable avant, en plus cher.

Les trois briques du protocole

Les outils, des fonctions appelables par l'agent, avec un schéma d'entrée déclaré. C'est la brique principale, et souvent la seule utilisée.

Les ressources, des contenus que l'agent peut lire : documentation, référentiels, contexte. Utile pour tout ce qui n'a pas à passer par un appel de fonction.

Les invites, des modèles de conversation réutilisables, préparés côté serveur.

En pratique, l'essentiel de la valeur est dans les outils. Nos ressources servent surtout à documenter les outils eux-mêmes, ce qui nous amène à la première leçon.

Leçon 1, La description de l'outil est l'interface

Un agent choisit un outil sur la foi de sa description. C'est donc de la documentation exécutable, et c'est la partie la plus rentable du travail.

Ce qui marche : dire ce que l'outil fait, ce qu'il ne fait pas, et quand ne pas l'utiliser. Cette dernière partie est celle qu'on oublie, et celle qui évite le plus d'erreurs.

Ce qui échoue : les descriptions génériques du type « gère les contacts ». L'agent choisira mal, et vous conclurez à tort que le modèle est mauvais.

Leçon 2, Trop d'outils tue l'agent

Chaque outil déclaré consomme du contexte et augmente le risque de mauvais choix. Au-delà de quelques dizaines d'outils visibles simultanément, la qualité des décisions se dégrade nettement.

Notre réponse : les 643 outils ne sont jamais tous exposés à la fois. Ils sont regroupés par domaine, 139 pour le SEO, 82 pour les réseaux sociaux, 21 pour la prospection, et un agent ne voit que le périmètre dont il a besoin.

La règle : concevez le catalogue comme un menu de restaurant, pas comme un inventaire de cuisine.

Leçon 3, Les arguments doivent être stricts

Un schéma permissif laisse passer des clés inconnues, que la bibliothèque de validation supprime silencieusement. L'agent reçoit une réponse en succès, et la valeur qu'il avait envoyée a disparu.

C'est le pire type d'erreur, parce qu'il est invisible : rien ne remonte, et le modèle en conclut que l'action a réussi.

La règle : refusez bruyamment les clés inconnues, à tous les niveaux, y compris à l'intérieur des tableaux d'objets. Nous avons appris celle-ci en production, sur un champ silencieusement perdu dans un tableau imbriqué.

Leçon 4, L'idempotence n'est pas optionnelle

Un agent réessaie. C'est même son comportement normal en cas d'erreur transitoire. Sans clé d'idempotence, un rejeu envoie deux messages, crée deux contacts, déclenche deux paiements.

La règle : toute action ayant un effet extérieur accepte une clé d'idempotence, et la respecte. C'est la différence entre un agent utilisable en production et une démonstration.

Leçon 5, Le message d'erreur est une instruction

Un agent lit vos erreurs et agit dessus. Un message d'erreur bien écrit corrige le comportement en un tour ; un message vague fait boucler l'agent jusqu'au plafond.

Ce qui marche : dire quel argument est invalide, quelles valeurs sont attendues, et quelle action alternative existe. Nos erreurs listent explicitement les clés reconnues quand une clé inconnue est passée, c'est ce qui transforme une erreur en autocorrection.

Leçon 6, Le protocole ne dit rien de l'autorisation

Le MCP standardise l'appel, pas le droit d'appeler. C'est à vous de décider ce qu'un agent a le droit de faire, et de le faire respecter côté serveur, jamais côté agent.

Chez nous : des plafonds par défaut de 20 invitations, 30 messages et 80 actions d'engagement par jour et par compte ; un plafond non relevable par l'agent, l'augmentation exigeant un humain administrateur avec effet le lendemain ; et une validation humaine avant les actions externes irréversibles.

Un agent qui peut relever son propre plafond finit toujours par le faire. Ce n'est pas une méfiance envers les modèles : c'est la même règle qu'on applique à n'importe quel programme automatique.

Ce que le MCP ne résout pas

Il ne rend pas l'agent intelligent. Un mauvais découpage d'outils produit un mauvais agent, quel que soit le modèle.

Il ne gère pas l'état de longue durée. Un agent qui suit un dossier sur trois semaines a besoin d'une mémoire d'exploitation que le protocole ne fournit pas.

Il ne remplace pas les tests. Un serveur MCP est un service : il se teste comme un service.

Il ne garantit pas la sécurité. Un outil MCP mal conçu est une porte ouverte comme n'importe quelle interface mal conçue. Les mêmes règles s'appliquent : authentification, cloisonnement par organisation, journal d'audit, moindre privilège.

Questions fréquentes

Le MCP est-il un standard ? C'est un protocole ouvert, publié et implémenté par plusieurs éditeurs. Son adoption a été rapide, ce qui est son principal argument : un outil exposé une fois sert à plusieurs clients.

Faut-il exposer tout son système en MCP ? Non, et c'est une erreur fréquente. Exposez les actions que vous voulez qu'un agent puisse déclencher, avec les mêmes précautions que pour une interface publique.

Combien d'outils par serveur ? Autant que vous voulez côté serveur ; quelques dizaines au maximum visibles simultanément par un agent. Le regroupement par domaine est ce qui rend un grand catalogue exploitable.

Le MCP fonctionne-t-il avec n'importe quel modèle ? Il fonctionne avec les clients qui l'implémentent. La qualité du choix d'outil dépend ensuite du modèle, et surtout de la qualité de vos descriptions.

---

Nos 643 outils tournent en production avec plafonds non contournables, idempotence et validation humaine. Pour en discuter, écrivez-nous.