Connecter vos agents IA à des outils externes avec MCP : vers des agents plus propres, plus ouverts, plus maintenables (+VIDEO)

Dans beaucoup de démonstrations autour des agents IA, on commence naturellement par écrire quelques fonctions directement dans l’application : une fonction pour interroger une base, une autre pour récupérer un client, une autre encore pour consulter l’état d’un incident ou déclencher une action métier. Cela pose un problème malgré tout...

Pour apprendre, c’est parfait.

Pour produire une architecture durable, c’est déjà beaucoup plus discutable.

C’est précisément le sujet de ma nouvelle vidéo : « Connecter vos agents à des outils externes avec MCP ». L’objectif n’est pas de montrer un énième agent capable d’appeler une fonction. Cela, on sait déjà le faire. L’objectif est de poser une question plus intéressante : où doivent vivre les outils consommés par vos agents ?

Et derrière cette question apparemment simple se cache un vrai sujet d’architecture.

Le problème : des agents qui embarquent trop de choses

Lorsqu’un agent est développé dans un projet isolé, il est tentant de lui adjoindre directement ses propres tools : accès aux données, appels API, règles métier, fonctions utilitaires, connecteurs internes, etc.

Au début, cela paraît efficace. Le code est proche de l’agent, facile à tester, facile à montrer en démo.

Mais cette approche se dégrade rapidement dès que plusieurs agents, plusieurs applications ou plusieurs équipes doivent exploiter les mêmes capacités.

On se retrouve alors avec :

• des outils recodés plusieurs fois ;
• des conventions différentes selon les projets ;
• des règles métier dupliquées ;
• des accès techniques dispersés ;
• des évolutions plus coûteuses ;
• une gouvernance difficile à maintenir.

Le problème n’est donc pas que l’agent ne fonctionne pas. Le problème est qu’il fonctionne en embarquant localement une partie du système d’information.

Et cela, à long terme, est une mauvaise pente.

Un agent sérieux ne devrait pas devenir un fourre-tout applicatif. Il ne devrait pas contenir à lui seul toutes les règles, tous les connecteurs et toutes les connaissances techniques nécessaires à son exécution. Il devrait pouvoir consommer proprement des capacités exposées ailleurs.

C’est là que MCP devient intéressant.

MCP : pas un gadget, un mécanisme de découplage

MCP signifie Model Context Protocol. Son rôle est de standardiser la manière dont une application IA peut découvrir et utiliser des outils, des ressources ou des contextes exposés par un serveur externe. La norme est Open Source, ce qui est important à savoir.

Autrement dit, MCP ne rend pas l’agent “plus intelligent” par magie. Ce n’est pas son rôle.

Sa valeur est ailleurs : MCP permet de séparer l’agent de l’implémentation concrète des outils qu’il consomme.

On peut voir cela comme un déplacement de responsabilité :

Ce changement peut sembler modeste sur une petite démo. En réalité, il devient structurant dès que l’on parle d’agents utilisés dans un environnement professionnel.

Le vrai bénéfice : appliquer DRY aux agents IA

Le principe DRY — Don’t Repeat Yourself — est bien connu des développeurs. On l’applique aux méthodes, aux classes, aux composants, aux services, aux librairies.

Mais dans beaucoup de projets agentiques, on l’oublie très vite.

Chaque agent finit avec ses propres fonctions d’accès aux données, ses propres descriptions d’outils, ses propres connecteurs, parfois même ses propres copies de règles métier.

MCP permet de réintroduire ce principe à un niveau supérieur : celui de l’architecture agentique.

L’idée n’est pas seulement d’éviter de dupliquer du code. L’idée est d’éviter de dupliquer des capacités métier.

Un outil exposé via MCP peut devenir une capacité partagée :

Serveur MCP
 ├── getImportantCustomers
 ├── getIncidentStatus
 ├── searchInternalDocs
 ├── createSupportTicket
 └── queryBusinessMetrics

En face, un ou plusieurs agents peuvent découvrir ces outils, les comprendre à partir de leurs descriptions, puis les utiliser selon le contexte.

L’agent n’a plus besoin de tout embarquer. Il devient consommateur d’un environnement outillé.

C’est une différence importante.

Ce que cela change dans une architecture réelle

Dans une architecture sérieuse, MCP n’est pas seulement une commodité technique. C’est une façon de clarifier les frontières.

Un serveur MCP peut être vu comme un point d’exposition de capacités métiers ou techniques. Il peut encapsuler des accès à :

• des bases de données relationnelles ;
• des bases vectorielles ;
• des API internes ;
• des systèmes de ticketing ;
• des référentiels clients ;
• des métriques applicatives ;
• des équipements IoT ;
• des moteurs de recherche internes ;
• des services métiers déjà existants.

L’intérêt est évident : l’agent ne se connecte pas directement à tout. Il passe par une couche explicitement conçue pour exposer des outils utilisables par des clients IA.

Cela permet de mieux raisonner sur plusieurs aspects essentiels.

1. Les responsabilités

L’agent raisonne, orchestre, sélectionne les outils pertinents.

Le serveur MCP expose, décrit et exécute les outils.

Le système métier reste responsable de ses propres données et de ses propres règles.

Cette séparation évite de transformer l’agent en application monolithique déguisée.

2. La réutilisation

Un même serveur MCP peut être consommé par plusieurs agents.

On peut ainsi imaginer :

• un agent support ;
• un agent commercial ;
• un agent d’analyse ;
• un assistant interne pour les équipes produit ;
• un agent de supervision technique.

Tous peuvent utiliser certaines capacités communes sans les recoder.

3. L’évolution

Ajouter un nouvel outil, modifier une règle, améliorer une description ou corriger un connecteur peut se faire côté serveur.

Cela ne signifie pas qu’il n’y a jamais d’impact côté client, bien entendu. Mais l’évolution devient mieux localisée, mieux contractualisée et plus facile à gouverner.

4. La gouvernance

Dès que les agents deviennent sérieux, la question n’est plus seulement : “Est-ce que l’agent peut appeler une fonction ?”

Les vraies questions deviennent :

• Qui expose cette fonction ?
• Avec quel contrat ?
• Avec quelles permissions ?
• Avec quel versionnement ?
• Avec quelle traçabilité ?
• Avec quelle politique d’erreur ?
• Avec quel niveau de confiance ?

MCP ne résout pas automatiquement tous ces sujets. Mais il fournit un point d’architecture beaucoup plus propre pour commencer à les traiter.

Attention : MCP ne dispense pas de concevoir correctement les tools

Il serait dangereux de présenter MCP comme une solution magique.

Un mauvais outil exposé via MCP reste un mauvais outil. Une règle métier mal localisée reste une règle métier mal localisée. Une description ambiguë reste une source d’erreurs pour l’agent.

La qualité d’une architecture MCP dépend fortement de la qualité des outils exposés.

Quelques règles pratiques s’imposent rapidement :

• donner aux tools des noms explicites ;
• rédiger des descriptions précises, non ambiguës ;
• limiter chaque outil à une responsabilité claire ;
• éviter les outils trop génériques du type executeQuery ou runCommand ;
• traiter correctement les erreurs ;
• journaliser les appels importants ;
• prévoir le versionnement des contrats ;
• ne jamais exposer plus de permissions que nécessaire ;
• distinguer les outils de lecture des outils d’écriture ;
• encadrer strictement les actions destructives ou sensibles.

C’est un point capital : MCP ouvre une architecture, mais cette ouverture doit être maîtrisée.

Un agent qui découvre dynamiquement des outils mal conçus ne devient pas plus fiable. Il devient simplement capable d’utiliser plus vite de mauvaises abstractions.

Ce que montre la vidéo

Dans la vidéo « Connecter vos agents à des outils externes avec MCP », je montre une démonstration volontairement simple autour de Microsoft Agent Framework.

L’idée n’est pas de construire un gros scénario métier. L’idée est de rendre visible la mécanique essentielle :

Agent Microsoft Agent Framework
        │
        ▼
Client MCP
        │
        ▼
Serveur MCP local
        │
        ├── outil : liste de clients importants
        └── outil : état d’un incident

Le serveur MCP expose deux outils simples.

L’agent, de son côté, ne recode pas ces outils. Il se connecte au serveur, découvre le catalogue disponible, puis consomme les outils utiles selon le prompt et le contexte.

Ce qu’il faut observer dans cette démonstration, ce n’est donc pas seulement la réponse finale de l’agent. Ce qui compte vraiment, c’est le découplage :

• les outils vivent hors de l’agent ;
• le catalogue peut être découvert ;
• les capacités peuvent être réutilisées ;
• le serveur peut évoluer indépendamment ;
• l’agent reste plus léger et plus propre.

C’est exactement le type de bascule qui distingue une démonstration agentique amusante d’une architecture agentique exploitable.

Pourquoi cette vidéo est importante dans une progression agentique

Lorsqu’on découvre les agents IA, on commence souvent par les fondamentaux :

• créer un agent ;
• lui donner des instructions ;
• lui fournir quelques tools ;
• observer comment il choisit les actions à exécuter ;
• gérer les réponses.

C’est indispensable.

Mais assez vite, une autre question apparaît : comment intégrer ces agents dans un système réel ?

C’est là que MCP devient un sujet naturel. Non pas parce qu’il serait obligatoire dans tous les cas, mais parce qu’il pose une vraie question d’urbanisation :

Mon agent doit-il contenir ses outils, ou doit-il consommer des capacités exposées par une couche spécialisée ?

Dans un petit prototype, les deux approches peuvent se défendre.

Dans un SI réel, avec plusieurs équipes, plusieurs agents et des capacités métier partagées, la seconde approche devient beaucoup plus crédible.

En résumé

MCP n’est pas intéressant parce qu’il ajoute une couche technique de plus.

Il est intéressant parce qu’il évite d’ajouter de la complexité partout ailleurs.

Son intérêt principal tient en trois idées :

• découpler l’agent de l’implémentation des outils ;
• réutiliser les mêmes capacités dans plusieurs contextes agentiques ;
• gouverner plus proprement les points d’accès aux systèmes externes.

La question n’est donc pas seulement de savoir si un agent peut appeler une fonction. La vraie question est de savoir comment cette fonction est exposée, maintenue, sécurisée, versionnée et partagée.

C’est ce que j’aborde dans cette vidéo, avec une démonstration concrète en C# autour de Microsoft Agent Framework et MCP.

Voir la vidéo : Connecter vos agents à des outils externes avec MCP https://youtu.be/7OpvF-pKN3Q 

Conclusion

DRY est un principe qui ne se discute plus depuis longtemps : il faut l’appliquer, aveuglément ou presque. Et partout.
Mais lorsqu’on passe au développement d’agents IA, on a tendance à être entraîné dans un univers de logique floue, de raisonnements synthétiques presque magiques, de réponses variables, de température à ajuster pour obtenir plus ou moins d’originalité. Bref, on se retrouve immergé dans un monde… un peu fantastique et déconnecté de la rigueur d'une application professionnelle. On oublie alors les bases, MVVM, SOLID, ou DRY.
Les serveurs MCP permettent de faire revenir la programmation agentique dans le giron de la programmation professionnelle.

La vidéo vous le prouvera encore plus facilement que ce billet. Alors à bientôt sur ma chaîne YoouTube !

Stay Tuned !