Le Model Context Protocol (MCP) est une norme ouverte, introduite par Anthropic fin 2024, qui permet aux applications d’IA de se connecter à des outils et des données externes via une interface commune. Un serveur MCP expose des outils, des ressources et des invites ; un client MCP, tel que Claude, ChatGPT, Cursor ou VS Code, les utilise. Faire passer le MCP du stade pilote à la production signifie limiter la portée, sécuriser l’authentification, contrôler les autorisations, journaliser chaque appel et attribuer un propriétaire.
Quel problème le MCP résout-il ?
Avant le MCP, chaque assistant IA avait besoin de sa propre intégration personnalisée pour chaque outil : un connecteur pour le CRM, un autre pour la plateforme d’analyse, un autre pour le stockage de fichiers. Le MCP standardise la connexion. Créez un serveur pour votre CRM et tout client compatible MCP pourra l’utiliser.
L’adoption s’est propagée rapidement. OpenAI, Google, Microsoft et de nombreux outils de développement ont ajouté la prise en charge du MCP, et des entreprises telles que GitHub, Stripe, Atlassian et HubSpot ont publié des serveurs MCP pour leurs produits. Pour les équipes marketing, cela signifie des assistants capables de lire les données de campagne, d’interroger une base de données ou de mettre à jour directement un tableau de projet.
Comment une configuration MCP s’articule-t-elle ?
Il y a trois parties. L’hôte est l’application dans laquelle l’utilisateur travaille. Le client qu’elle contient maintient une connexion avec chaque serveur. Le serveur enveloppe un système et décrit ce qu’il propose : des outils que le modèle peut appeler, des ressources qu’il peut lire et des modèles d’invites.
Les serveurs peuvent s’exécuter localement sur la machine d’un utilisateur, en communiquant via une entrée et une sortie standard, ou à distance via HTTP. Les serveurs distants sont ceux utilisés par la plupart des déploiements en production, car ils peuvent être sécurisés et surveillés de manière centralisée.
Étape 1 : liste de contrôle pilote
Commencez petit pour apprendre sans trop vous exposer.
- Choisissez un cas d’utilisation, comme permettre à un assistant de lire les données de Google Analytics 4 ou de la Search Console pour établir des rapports.
- Préférez un serveur officiel du fournisseur lorsqu’il en existe un, plutôt qu’un serveur communautaire.
- Donnez-lui d’abord un accès en lecture seule.
- Testez avec un petit groupe d’utilisateurs nommés.
- Notez à quoi ressemble le succès : questions répondues correctement, temps gagné sur un rapport.
La qualité et la maintenance des serveurs communautaires varient. Lisez le code ou au moins les autorisations qu’il demande avant d’en installer un.
Étape 2 : sécurité et authentification
La spécification du MCP comprend un cadre d’autorisation basé sur OAuth pour les serveurs distants. Utilisez-le plutôt que de coller des clés API à longue durée de vie dans des fichiers de configuration. Chaque utilisateur doit s’authentifier en tant que lui-même, afin que le serveur applique les autorisations existantes de cette personne.
Pensez également à l’injection d’invites. Si un serveur renvoie du contenu provenant d’e-mails, de pages Web ou de documents, ce contenu peut contenir des instructions destinées au modèle. Traitez les sorties des outils comme des données non fiables et concevez l’hôte de manière à demander confirmation avant toute action d’écriture déclenchée par celles-ci.
Étape 3 : définir les autorisations outil par outil
Chaque outil exposé par un serveur est une autorisation. Examinez-les un par un :
- Listez chaque outil et marquez-le comme lecture ou écriture.
- Supprimez les outils dont personne n’a besoin ; moins d’outils aident également le modèle à faire le bon choix.
- Exigez une confirmation humaine pour les outils d’écriture, tels que l’envoi d’e-mails, la modification de budgets ou la suppression d’enregistrements.
- Restreignez les données sensibles avec des filtres côté serveur, pas seulement avec des instructions au modèle.
- Documentez la décision pour chaque outil, avec la date et le propriétaire.
Étape 4 : journalisation et surveillance
En production, vous devez être capable de répondre : qui a appelé quel outil, avec quels arguments, et qu’est-ce qui est revenu ? Journalisez les appels sur le serveur, masquez les données personnelles et conservez les journaux assez longtemps pour les audits. Surveillez les erreurs et la latence, car les outils lents donnent l’impression que les assistants sont en panne.
Les alertes sont utiles pour les modèles inhabituels, comme une augmentation soudaine des appels d’écriture ou des appels en dehors des heures de travail.
Étape 5 : tests et contrôle des changements
Traitez les serveurs comme n’importe quel autre logiciel. Versionnez-les, testez automatiquement le comportement des outils et examinez les changements avant de les déployer. Lorsque vous modifiez la description d’un outil, testez à nouveau avec les clients que votre équipe utilise ; les modèles choisissent les outils en fonction de ces descriptions, donc les changements de formulation peuvent modifier le comportement.
Évaluer avec des tâches réelles
Créez un ensemble de 30 à 50 requêtes réalistes, telles que “comparez les sessions organiques du mois dernier avec le mois précédent par page de destination”. Vérifiez que l’assistant appelle les bons outils, avec des arguments sensés, et produit une réponse correcte. Répétez après chaque changement de serveur ou de modèle.
Comment Alien Road applique le MCP dans le travail d’optimisation de l’IA
Dans une mission typique, la découverte répertorie les systèmes que l’équipe marketing du client lit le plus souvent pour les rapports et les décisions : analyses, plateformes publicitaires, CRM, gestion de contenu. L’équipe vérifie lesquels disposent de serveurs MCP officiels et lesquels nécessiteraient un serveur personnalisé.
La configuration commence par des serveurs en lecture seule pour les tâches de reporting et les utilisateurs nommés. Les serveurs personnalisés, si nécessaire, sont écrits avec une liste minimale d’outils, une authentification OAuth et une journalisation côté serveur, et stockés dans le référentiel du client. Les outils d’écriture ne sont ajoutés qu’une fois que la phase de lecture seule s’est déroulée correctement.
La mesure couvre les résultats de l’ensemble d’évaluation, le temps passé sur les rapports récurrents avant et après, les taux d’erreur des appels d’outils et tout événement de sécurité. Les rapports mensuels incluent un échantillon des sessions journalisées, afin que le client puisse voir exactement ce à quoi l’assistant a accédé.
Étape 6 : liste de contrôle de préparation à la production
Avant de passer en production à grande échelle, confirmez :
- Chaque serveur a un propriétaire désigné et un plan de maintenance.
- L’authentification est par utilisateur, sans clés partagées dans les fichiers de configuration.
- Les outils d’écriture nécessitent une confirmation.
- Les journaux capturent les appels avec les données personnelles masquées.
- L’ensemble d’évaluation réussit sur les versions actuelles du client.
- Les utilisateurs savent quels serveurs sont approuvés et comment en demander de nouveaux.
La dernière ligne est importante car les utilisateurs peuvent souvent ajouter eux-mêmes des serveurs. Une liste approuvée empêche les serveurs communautaires inconnus d’accéder aux environnements sensibles.
Comment choisir entre des serveurs officiels et personnalisés ?
Les serveurs officiels sont maintenus par le fournisseur, suivent ses changements d’API et prennent généralement en charge une authentification appropriée. Utilisez-les chaque fois qu’ils couvrent vos besoins. Leur inconvénient est la portée : ils peuvent exposer plus d’outils que vous ne le souhaitez, alors vérifiez si le client vous permet de désactiver des outils individuels.
Les serveurs personnalisés sont utiles lorsqu’aucun serveur officiel n’existe, lorsque vous devez combiner plusieurs systèmes en un seul outil simple, ou lorsque vous devez appliquer des filtres qui manquent au serveur du fournisseur. Ils deviennent également votre charge de maintenance. Gardez-les petits, documentés et versionnés, et prévoyez que quelqu’un les mette à jour lorsque l’API sous-jacente change.
Par où commencer cette semaine
Choisissez un rapport récurrent que votre équipe construit manuellement à partir d’un seul système. Trouvez le serveur MCP officiel de ce système, connectez-le en lecture seule à l’assistant que votre équipe utilise déjà et demandez-lui de produire la version du rapport du mois dernier. Comparez avec le manuel. Notez les erreurs et le temps gagné, et utilisez ces notes pour décider de la deuxième étape.
Continuer la lecture : Optimisation par IA · Optimisation par IA