Un même cas d’usage, deux façons de le construire : donner à un agent la capacité de consulter le statut d’un paiement Stripe et de proposer un remboursement partiel sous validation humaine. L’équipe technique de la plateforme de paiement fictive Paymento a implémenté ce cas des deux façons, à quelques mois d’intervalle, pour comparer concrètement l’effort de mise en place et la maintenance de chaque approche.
La première version reposait sur du function calling classique, intégré directement dans le code de l’assistant conversationnel maison de l’équipe support. La seconde version, développée ensuite, exposait les mêmes capacités via un serveur MCP, pensé pour être potentiellement réutilisé par d’autres clients que ce seul assistant.
Le function calling classique : rapide à mettre en place
Définir les fonctions directement dans le code de l’assistant a demandé peu d’efforts : un fichier de schémas, quelques fonctions d’exécution appelant l’API Stripe, et une boucle de traitement qui relie le tout. Sur un projet avec un seul consommateur identifié, cette approche reste la plus rapide à livrer, sans couche d’abstraction supplémentaire à concevoir ni à maintenir.
const tools = [{
name: 'get_payment_status',
parameters: { type: 'object', properties: { payment_id: { type: 'string' } } }
}];
async function getPaymentStatus(paymentId) {
return stripe.paymentIntents.retrieve(paymentId);
}La limite est apparue quelques mois plus tard, quand une deuxième équipe, chargée d’un tableau de bord interne assisté par un autre agent, a voulu réutiliser la même capacité de consultation de paiement. Sans standard commun, il a fallu dupliquer les schémas de fonctions et leur logique d’exécution dans le nouveau projet, avec le risque que les deux implémentations divergent progressivement au fil des évolutions.
MCP : un effort initial plus élevé, un partage facilité
La version MCP a demandé davantage de travail de départ : mettre en place un serveur dédié, gérer son cycle de vie, documenter ses outils selon la spécification du protocole. Cet investissement supplémentaire ne se justifiait pas pour un seul consommateur, mais il a immédiatement profité à la deuxième équipe, qui a pu brancher son propre agent sur le même serveur MCP sans dupliquer la moindre ligne de logique métier liée à Stripe.
Ce qui a changé concrètement pour la deuxième équipe
- Aucune réécriture de la logique d’appel à Stripe, entièrement centralisée dans le serveur MCP existant.
- Une seule source de vérité pour la définition des outils, ce qui a évité une divergence progressive entre deux implémentations parallèles.
- Une mise à jour de la logique de remboursement, effectuée une seule fois, immédiatement disponible pour les deux agents consommateurs.
Tableau comparatif
| Critère | Function calling classique | MCP |
|---|---|---|
| Effort de mise en place initial | Faible | Modéré |
| Réutilisation par un second agent | Duplication nécessaire | Immédiate |
| Maintenance à long terme, un seul client | Simple | Surdimensionnée |
| Maintenance à long terme, plusieurs clients | Risque de divergence | Centralisée |
Le choix entre function calling classique et MCP ne se tranche pas sur la sophistication technique de l’un ou de l’autre, mais sur une question concrète : combien de consommateurs distincts appelleront cet outil dans les douze prochains mois ?
Où se situe le seuil de rentabilité
Sur ce projet, le seuil s’est révélé bas : dès qu’un deuxième client a eu besoin de la même capacité, l’effort supplémentaire consenti pour MCP dès le départ aurait été rentabilisé. En dessous de ce seuil, pour un outil destiné à un unique agent sans perspective de réutilisation, le function calling classique reste le choix le plus pragmatique, sans qu’il faille y voir un renoncement à une meilleure pratique.
Ce que ce comparatif ne traite pas
La sécurité de ces deux intégrations, leur gestion des accès et leur journalisation ne sont pas abordées ici : ce comparatif se concentre exclusivement sur l’effort de mise en place et de maintenance, pas sur les garanties de sécurité de chaque approche, qui mériteraient un traitement séparé et approfondi.
En résumé
Aucune des deux approches n’est universellement supérieure à l’autre : le function calling classique reste imbattable en simplicité pour un cas d’usage isolé, tandis que MCP prend l’avantage dès que plusieurs agents doivent partager le même outil sans dupliquer sa logique. La question à se poser avant de choisir n’est pas technique mais organisationnelle : qui d’autre, demain, voudra appeler ce même outil ?
