Agents IA & MCP
Un agent IA est un programme qui s’appuie sur un modèle de langage pour exécuter des tâches en enchaînant des appels d’outils, et non seulement pour produire du texte. Le Model Context Protocol (MCP) est le protocole ouvert qui standardise la façon dont ces agents accèdent à des outils, à des données et à des applications métier.
Les fondamentaux
Agents IA et MCP : deux briques complémentaires
On confond souvent les deux termes parce qu’ils apparaissent ensemble. Ils désignent pourtant deux choses distinctes, et c’est cette distinction qui permet de comprendre ce qu’on achète ou ce qu’on construit. L’agent décide de ce qu’il faut faire. Le protocole détermine ce qu’il a le droit de faire. Un projet réussi traite les deux questions séparément.
L’agent : la partie qui décide
Un agent reçoit un objectif, pas une procédure. « Publie un résumé des trois derniers articles » suppose de lister les articles, de les lire, de rédiger, puis de publier : enchaînement que personne ne lui a décrit. Il compose lui-même cette suite d’actions, observe le résultat de chacune et ajuste. C’est ce qui le rend utile, et c’est aussi ce qui le rend non déterministe : deux exécutions du même objectif ne suivront pas forcément le même chemin. Voir Agents IA.
MCP : la partie qui donne accès
Un modèle seul ne peut rien atteindre. Pour lire un article ou créer une facture, il lui faut des outils, et quelqu’un doit les lui décrire. C’est le rôle du serveur MCP : il expose un ensemble fermé d’actions et de données, dans un format standard qu’un assistant sait interpréter. Le point décisif tient en une phrase : ce qui n’est pas exposé n’existe pas pour l’agent. Voir Serveurs MCP.
Ce qui change par rapport à une intégration API classique
Une API est écrite pour un développeur qui lit la documentation et code l’appel. MCP s’adresse à un modèle : la description des outils fait partie du protocole, l’assistant découvre ce qui est disponible au moment de la connexion et choisit lui-même quoi appeler. L’intégration n’est plus à refaire pour chaque assistant. C’est le bénéfice principal, et il ne se manifeste qu’à partir du deuxième client connecté. Voir MCP & API.
Mise en œuvre
Connecter une IA à vos systèmes
Tous les systèmes ne se prêtent pas au même degré d’ouverture. Le critère de tri n’est pas la faisabilité technique (presque tout est connectable) mais le coût d’une erreur. Une publication ratée se corrige aussitôt ; un avoir émis à tort engage la comptabilité.
| Système cible | Mode de connexion courant | Ce que l’agent y fait bien | Niveau de risque |
|---|---|---|---|
| Site vitrine ou blog | Serveur MCP sur le CMS | Rédiger, publier, corriger, auditer les contenus | Faible (tout est réversible) |
| Boutique en ligne | Serveur MCP ou API de la plateforme | Enrichir le catalogue, contrôler les fiches | Modéré (prix et stocks à exclure de l’écriture) |
| CRM | Serveur MCP devant l’API existante | Interroger, qualifier, enrichir des fiches | Modéré (données personnelles) |
| Facturation, comptabilité | API exposée en lecture seule | Répondre à des questions, produire des états | Élevé (écriture à proscrire au départ) |
| Base de données interne | Serveur MCP avec requêtes prédéfinies | Extraire, croiser, restituer en clair | Élevé (jamais de SQL libre) |
La progression naturelle va du haut vers le bas de ce tableau : on ouvre d’abord ce qui se corrige, on étend ensuite. L’inverse (commencer par le système le plus critique parce qu’il est le plus coûteux en temps humain) est la décision qui fait échouer les projets.
- Connecter une IA à un site internet : lecture et écriture du contenu, pilotage du CMS.
- Connecter ChatGPT et Claude à vos outils métier : CRM, ERP, facturation, base de données.
- MCP pour WordPress : exposer les capacités de WordPress à un assistant.
- MCP pour CMS : Joomla, Drupal, PrestaShop, Shopify et approches headless.
Cadre et garde-fous
Sécurité, permissions et supervision
La sécurité d’un agent ne se joue pas dans le modèle mais dans ce qu’on lui donne à sa portée. Un modèle peut se tromper, mal interpréter une consigne, ou être influencé par un contenu qu’il a lu. On ne corrige pas cela par une instruction : on le borne en amont, en limitant ce qui est atteignable.
Limiter le périmètre d’action de l’agent
Trois principes suffisent à couvrir l’essentiel. Le premier : la lecture s’ouvre largement, l’écriture se découpe en actions précises. « Créer un brouillon d’article » est une action maîtrisable, « modifier n’importe quel contenu » ne l’est pas.
Le deuxième : l’agent travaille sous une identité dédiée, dotée du rôle minimal nécessaire. Jamais un compte administrateur existant, jamais un compte partagé. Le troisième : les opérations irréversibles (suppression, envoi vers un tiers, mouvement financier) restent hors du périmètre exposé, quel que soit le niveau de confiance accordé.
Garder un humain dans la boucle
La supervision ne consiste pas à tout valider. Ce serait perdre le bénéfice de l’automatisation. Elle consiste à placer la validation aux endroits où l’erreur devient visible par un tiers ou coûteuse à défaire : publication, envoi, engagement.
Elle suppose aussi de pouvoir reconstituer ce qui s’est passé. Journalisez chaque appel d’outil, ses paramètres et son résultat. Sans cette trace, un comportement anormal reste indiagnosticable, et vous n’avez que deux options : tout rouvrir ou tout couper. Prévoyez enfin un moyen de désactiver l’accès immédiatement, sans redéploiement.
Sur le terrain
Cas d’usage
- Publier, mettre à jour et contrôler des contenus depuis une conversation avec un assistant.
- Interroger en langage naturel un CRM ou un outil de facturation sans passer par son interface.
- Faire exécuter un audit technique récurrent par un agent, avec compte rendu automatique.
- Exposer un outil métier interne à une IA sans développer d’interface dédiée.
Objections courantes
Questions fréquentes
Quelle différence entre un agent IA et un chatbot ?
Un chatbot répond, un agent agit. Le premier compose un texte à partir de ce qu’il sait ou de ce qu’on lui a fourni ; le second enchaîne des actions dans vos systèmes et vérifie leur résultat avant de poursuivre. La différence ne tient pas à l’interface (les deux peuvent se présenter comme une conversation) mais à la présence ou non d’outils exécutables.
Cette différence change entièrement la nature du risque. Un chatbot qui se trompe donne une mauvaise information, qu’un lecteur attentif peut repérer. Un agent qui se trompe modifie quelque chose. Les garde-fous ne se pensent donc pas de la même manière.
Faut-il développer son propre serveur MCP ?
Pas si un serveur existant couvre déjà votre besoin. Pour les outils très répandus, des implémentations sont disponibles et il serait absurde de les réécrire. Le développement se justifie lorsque le système à exposer est spécifique (outil interne, métier particulier) ou lorsque vous voulez maîtriser exactement le périmètre ouvert.
Ce dernier point pèse plus qu’il n’y paraît. Un serveur générique expose ce que son auteur a jugé utile, ce qui dépasse souvent ce dont vous avez besoin. Écrire son propre serveur, c’est d’abord décider de ce qu’on n’expose pas. Et cette décision, personne ne peut la prendre à votre place.
Un agent peut-il modifier un site en production sans validation ?
Techniquement oui, si vous lui en donnez le droit. La vraie question est de savoir quelles modifications méritent une validation humaine. Et la réponse dépend de la réversibilité, pas de l’importance apparente. Créer un brouillon ne coûte rien à défaire. Modifier une page tarifaire publiée, si.
Le montage courant expose la production en lecture, l’écriture en brouillon, et réserve la publication à une action humaine. C’est le meilleur rapport entre le temps gagné et le risque pris, et il se relâche ensuite, cas par cas, quand la confiance est établie sur des éléments observés.
MCP remplace-t-il les API existantes ?
Non, il se pose dessus. Un serveur MCP s’appuie le plus souvent sur l’API que vous avez déjà : il n’en refait pas la logique, il la décrit dans un format qu’un modèle sait exploiter et il restreint ce qui est atteignable. Vos intégrations existantes continuent de fonctionner sans changement.
La question utile n’est donc pas « MCP ou API » mais « pour qui ». Une API sert un développeur qui code un appel précis ; MCP sert un modèle qui découvre les outils disponibles et choisit. Les deux coexistent sur le même système sans se gêner.
Les autres piliers
Aller plus loin
- IA pour le Web : les fonctionnalités IA visibles par le visiteur.
- Workflows IA : orchestrer plusieurs étapes autour d’un agent.
- Intégration LLM : la couche applicative au-dessus du modèle.
- Formation MCP : monter en compétence sur le protocole.
Ce qu’il faut retenir
Conclusion
Un projet d’agent se juge à une question, posée avant d’écrire la moindre ligne : quelle tâche répétitive fait aujourd’hui perdre du temps à quelqu’un, et que coûterait une erreur sur cette tâche ? Si la réponse à la seconde partie est « pas grand-chose », vous tenez votre premier cas d’usage.
Le reste s’assemble dans cet ordre : écrire la liste des actions à exposer, créer l’identité dédiée qui les portera, ouvrir en lecture seule, observer pendant quelques semaines, puis élargir. Chacune de ces étapes est réversible, ce qui est exactement la propriété qu’on recherche quand on confie des actions à une machine.
Parlons de votre projet
Décrivez votre besoin en quelques lignes : vous recevrez une première analyse et une orientation claire.
Réponse sous 48 h. Sans engagement.