MCP en production : exposer ses APIs à un agent sans ouvrir la porte

Ce que MCP fait, et ce qu’il ne fait pas

MCP (Model Context Protocol) normalise le dialogue entre un modèle et des outils : comment un outil se décrit, quels paramètres il attend, comment il renvoie un résultat. C’est un gain réel : sans standard, chaque intégration réinvente son format et rien n’est réutilisable.

Mais un protocole ne décide pas de ce qui est autorisé. MCP ne vous dira jamais que vous venez d’exposer la suppression d’un client à un modèle qui interprète des phrases. Ces questions sont les vôtres, et elles ne changent pas depuis que les APIs existent.

La bonne façon de voir un serveur MCP : c’est une API publique de plus, dont l’appelant est un système non déterministe qui peut se tromper d’intention. Tout ce que vous exigez d’une API publique s’applique, avec une marge supplémentaire.

1. Décider ce qui n’est pas exposé

Le premier réflexe est d’exposer l’API existante en bloc. C’est le plus rapide et le plus risqué : une API interne a été conçue pour un appelant de confiance qui sait ce qu’il fait.

Faites l’inventaire dans l’autre sens. Partez des tâches que l’agent doit accomplir, listez les actions strictement nécessaires, et n’exposez que celles-là.

• Lecture d’abord : un agent qui ne fait que lire couvre déjà la majorité des cas d’usage utiles.
• Écriture ensuite, action par action, avec une justification pour chacune.
• Jamais de suppression définitive, de modification de droits, de changement de configuration ou d’opération financière sans validation humaine.
• Jamais d’outil générique du type « exécuter une requête » : c’est une porte ouverte déguisée en fonctionnalité.

2. Faire porter l’identité de l’utilisateur

C’est le point le plus souvent raté. Un serveur MCP qui s’exécute avec un compte de service voit tout, donc l’agent voit tout, donc l’utilisateur voit tout, y compris ce qu’il n’a pas le droit de lire.

L’appel doit être effectué avec l’identité de l’utilisateur à l’origine de la demande, et traverser la même couche d’autorisation que le reste de votre application. Deux conséquences pratiques :

1. Le serveur MCP appelle vos services applicatifs, jamais la base de données directement. C’est dans ces services que vivent vos règles métier.
2. Un refus d’autorisation doit remonter comme un refus explicite, que le modèle peut expliquer à l’utilisateur, pas comme un résultat vide qui l’incitera à inventer.

3. Écrire des contrats d’outils lisibles

La description d’un outil est ce que le modèle lit pour décider de l’appeler. Une description vague produit des appels hasardeux ; une description précise produit un comportement stable. C’est le levier de qualité le moins cher et le plus négligé.

• Un nom qui dit l’action et son objet, sans abréviation interne.
• Une description qui précise quand l’outil s’applique, et surtout quand il ne s’applique pas.
• Des paramètres typés, avec les valeurs autorisées énumérées plutôt que décrites en prose.
• Un format de retour stable, avec les erreurs comme cas normaux : « aucun résultat » et « accès refusé » sont des réponses, pas des exceptions.
• Des outils versionnés et testés comme n’importe quel contrat d’API.

Règle pratique : moins d’outils, mieux décrits. Un agent avec six outils clairs se comporte mieux qu’un agent avec quarante outils approximatifs, où il passe son temps à choisir mal.

4. Traiter les opérations irréversibles à part

Certaines actions ne se rattrapent pas : envoyer un message à un client, supprimer une donnée, déclencher un paiement, modifier une configuration de production. Elles demandent un traitement particulier.

• Validation humaine explicite avant exécution, avec un récapitulatif lisible de ce qui va se passer.
• Idempotence : un même appel rejoué ne doit pas produire deux effets. Les agents réessaient.
• Plafonds : nombre d’appels par période, montants maximaux, volumes maximaux.
• Réversibilité quand elle est possible : suppression logique plutôt que définitive, brouillon plutôt qu’envoi direct.

5. Journaliser pour pouvoir expliquer

Le jour où quelqu’un demande « pourquoi le système a-t-il fait ça ? », il faut pouvoir répondre. Sans trace, un service agentique est inexploitable et inauditable.

• Quelle demande initiale, quel utilisateur, quels outils appelés dans quel ordre, avec quels paramètres.
• Quels résultats renvoyés, et quelle réponse finale produite.
• Le coût et la latence par appel, pour détecter les dérives avant la facture.
• Les refus d’autorisation, qui signalent souvent un périmètre d’outils mal conçu.

Où faire tourner tout cela

Un serveur MCP exposé à un assistant est une surface exposée. Il se traite comme telle : isolation réseau, secrets gérés hors du code, limitation de débit, environnement de test distinct de la production, et une revue avant chaque ajout d’outil.

C’est aussi pour cette raison que la question « faut-il exposer cette action ? » doit rester une décision d’architecture, prise une fois, écrite, et pas une décision prise au cas par cas pendant un développement.

Une mise en place progressive

1. Commencer par deux ou trois outils en lecture seule, sur un périmètre métier limité.
2. Mesurer : les bons outils sont-ils choisis ? Les descriptions sont-elles comprises ?
3. Ajouter l’écriture sur une action simple et réversible.
4. Introduire la validation humaine, et n’aborder les opérations sensibles qu’après.
5. Ne généraliser qu’une fois la journalisation et les plafonds en place.