Serveurs MCP vs Function Calling : Choisissez Votre Camp

C'est tentant. Vraiment tentant.

Chaque fournisseur de LLM propose du function calling maintenant. OpenAI l'a. Anthropic l'a. Google l'a. Vous choisissez votre préféré, lisez la doc pendant vingt minutes, définissez vos fonctions en JSON Schema, et vous livrez. Ça marche. Votre démo est impressionnante. Vos investisseurs sont conquis.

Le problème, c'est que « ça marche » et « ça marche à grande échelle avec plusieurs fournisseurs » sont deux affirmations complètement différentes. La première, c'est un mardi après-midi. La seconde, c'est un emploi à plein temps.

Quand vous câblez le function calling à un seul fournisseur, vous ne choisissez pas juste un vendeur. Vous choisissez son format de schéma, ses conventions de paramètres, sa sémantique de gestion d'erreurs et son calendrier de releases. Vous écrivez du code colle qui, par définition, n'est pas portable. Et vous le faites à la couche où la portabilité importe le plus — la frontière entre votre application et l'intelligence dont elle dépend.

La plupart des gens ne réalisent pas ça avant d'avoir besoin d'un deuxième LLM. À ce moment-là, le code colle a déjà métastasé.

Faites cet exercice. Allez dans votre codebase et comptez les lignes de code qui existent uniquement pour traduire entre vos définitions d'outils internes et le format function calling d'un fournisseur spécifique.

Une intégration ? Peut-être cent lignes. Gérable. Deux intégrations ? Vous commencez à remarquer qu'OpenAI et Anthropic ont des opinions subtilement différentes sur l'expression des paramètres optionnels. Trois ? Vous maintenez une matrice de compatibilité. Cinq ? Vous avez accidentellement construit un framework.

Et les frameworks ne cessent jamais de grossir. Chaque fournisseur met à jour son API chaque trimestre. Parfois ils ajoutent des fonctionnalités. Parfois ils déprécient des choses. Parfois ils « améliorent » le format de schéma de manières qui cassent vos définitions existantes en production à 2h du matin un samedi.

L'impôt de maintenance sur le function calling multi-fournisseur n'est pas linéaire. Il est combinatoire. Chaque nouveau fournisseur multiplie la surface. Chaque changement d'API se propage à travers toutes les intégrations. Votre couche « simple » de function calling devient la partie la plus fragile de votre stack — le fichier que tout le monde a peur de toucher.

Personne ne met ce coût dans le document d'architecture. Personne ne l'estime en planning de sprint. Ça s'accumule, en silence, jusqu'au jour où vous réalisez que la moitié de votre temps d'ingénierie part à maintenir des intégrations en vie plutôt qu'à construire des fonctionnalités.

MCP n'est pas un produit. Ce n'est pas l'API d'une startup. C'est un protocole. Cette distinction compte plus que les gens ne le pensent.

Quand vous écrivez un serveur MCP, vous décrivez vos outils une fois. Un schéma. Un jeu de descriptions. Un format d'erreur. Point. Chaque LLM qui parle MCP peut découvrir et utiliser vos outils sans que vous écriviez une seule ligne de code spécifique à un fournisseur.

Pas d'adaptateurs. Pas de matrices de versions. Pas de « if openai then format A, elif anthropic then format B ». Le protocole est le contrat, et tout client qui implémente le protocole obtient vos outils gratuitement.

C'est exactement le pattern qui a rendu HTTP gagnant. Personne n'écrit une API différente pour Chrome, Firefox et Safari. Vous implémentez le protocole et chaque client conforme fonctionne. MCP fait pour l'intégration d'outils IA ce que HTTP a fait pour la livraison de contenu web — il rend la couche transport ennuyeuse pour que vous puissiez vous concentrer sur la couche application.

Le résultat pratique : vos définitions d'outils deviennent des actifs au lieu de dettes. Vous les écrivez une fois, les testez une fois, les documentez une fois. Quand un nouveau fournisseur LLM arrive, vous ne réécrivez rien. Vous pointez vers votre serveur MCP et ça marche.

Je serais malhonnête si je ne le reconnaissais pas : parfois le function calling est le bon choix.

Si vous construisez une application qui n'utilisera qu'un seul LLM, que vous savez lequel, et que vous ne vous racontez pas d'histoires — le function calling direct est plus simple. Moins d'abstraction. Moins de pièces mobiles. Vous échangez la portabilité contre la simplicité, et parfois cet échange vaut le coup.

Si vous avez besoin de fonctionnalités spécifiques au fournisseur sans équivalent MCP — modes de sortie structurée, APIs d'utilisation d'ordinateur, ou comportements de streaming propres au fournisseur — l'intégration directe a du sens. On ne peut pas accéder à ce que le protocole n'expose pas.

Et si vous prototypez, si vous êtes dans la phase « fais que ça marche », le function calling vous y amène plus vite. MCP a un coût d'installation initial. Pour un hackathon de week-end, ce coût est réel.

Mais voici la question à laquelle il faut répondre honnêtement : est-ce que « un seul fournisseur pour toujours » décrit réellement votre avenir ? Parce que d'expérience, les entreprises qui disent « on n'utilisera jamais qu'OpenAI » sont les mêmes qui ajoutent frénétiquement le support Claude six mois plus tard quand leurs utilisateurs commencent à le demander. Celles qui disent « on prototype juste » sont les mêmes qui font tourner ce prototype en production deux ans après.

Le coût de passer du function calling à MCP augmente chaque jour que vous attendez. Le coût de commencer avec MCP reste à peu près constant.

Voici ce que la plupart des gens ne voient pas : MCP et function calling ne sont pas des ennemis. Ce sont des couches dans la même pile.

Les outils MCP peuvent être exposés comme fonctions à tout LLM qui supporte le function calling. Le protocole est la source de vérité — la description canonique de ce que font vos outils, ce qu'ils acceptent et ce qu'ils renvoient. Les adaptateurs function calling sont générés, pas écrits à la main. Votre serveur MCP est la source unique ; les formats spécifiques aux fournisseurs sont des projections.

Cela signifie que vous n'avez pas à choisir. Vous pouvez avoir MCP comme couche de définition d'outils et continuer à utiliser le function calling comme mécanisme de livraison vers chaque LLM. La différence, c'est qu'avec MCP, ces définitions de fonctions dérivent d'une source unique au lieu d'être maintenues indépendamment par fournisseur.

C'est la direction que prend l'industrie, qu'elle le sache ou non. Le pattern « une description canonique, de nombreux formats dérivés » a gagné dans tous les autres domaines — schémas de bases de données, spécifications d'API, systèmes de types. L'intégration d'outils IA convergera vers le même pattern parce que l'alternative est une charge de maintenance qui croît plus vite que l'équipe d'ingénierie de qui que ce soit.

Les entreprises qui comprennent ça maintenant consacreront leur temps à construire de meilleurs outils. Celles qui le comprendront plus tard consacreront leur temps à réécrire du code colle. Les deux groupes finiront au même endroit. La seule question est combien de temps ils gaspillent pour y arriver.