« On refait exactement la même intégration que le mois dernier, mais avec un format différent. » Cette phrase, prononcée en revue de sprint, résume assez bien ce qu’a été le développement d’outils externes pour un modèle de langage entre 2023 et fin 2024 : une succession de solutions maison, chacune valable pour un fournisseur donné, aucune réellement transposable au suivant.
Quatre tentatives distinctes se sont succédé sur nos projets avant que le Model Context Protocol ne devienne une option crédible fin 2024. Chacune a résolu un problème réel, mais à sa manière, sans laisser de socle commun à la tentative suivante.
La première tentative : des plugins liés à un seul écosystème
Les premiers plugins pour assistants conversationnels grand public, apparus courant 2023, permettaient à un modèle d’appeler un service externe via une description au format OpenAPI hébergée sur le site du service. L’idée était séduisante : décrire une API existante, et laisser le modèle décider quand l’appeler. En pratique, ce mécanisme restait propre à un seul écosystème fermé, et ne fonctionnait pas avec un autre fournisseur de modèle.
Sur un projet client, nous avions ainsi exposé un catalogue de produits via une description OpenAPI, fonctionnelle uniquement dans l’environnement pour lequel elle avait été pensée. Changer de fournisseur de modèle signifiait recommencer cette description depuis zéro, avec un format différent.
La deuxième tentative : le function calling propriétaire
Le function calling, généralisé chez les grands fournisseurs à partir de 2023, a permis de sortir de cette dépendance à un seul écosystème conversationnel : n’importe quel modèle compatible pouvait désormais appeler une fonction décrite dans le code de l’application. Mais chaque fournisseur imposait son propre schéma de description, ce qui obligeait à dupliquer les définitions de fonctions si le projet devait rester compatible avec plusieurs modèles.
// Format fournisseur A
$tools_a = array(
'name' => 'chercher_produit',
'parameters' => array( 'type' => 'object', 'properties' => array( 'nom' => array( 'type' => 'string' ) ) ),
);
// Format fournisseur B, même fonction, structure différente
$tools_b = array(
'function_name' => 'chercher_produit',
'input_schema' => array( 'nom' => 'string' ),
);La troisième tentative : des adaptateurs maison
Pour limiter la duplication, nous avons construit une couche d’adaptation en PHP, traduisant une définition d’outil unique vers le format attendu par chaque fournisseur. Cette solution a tenu deux ans, mais chaque nouveau fournisseur ou chaque évolution de format côté fournisseur imposait de mettre à jour l’adaptateur, avec le risque de régression sur les intégrations existantes.
- Un adaptateur central traduisant vers chaque format propriétaire
- Une maintenance proportionnelle au nombre de fournisseurs supportés
- Aucune découverte dynamique : chaque outil devait être déclaré à l’avance côté application
- Aucune authentification standardisée entre l’agent et le service appelé
La quatrième tentative : l’arrivée du Model Context Protocol
Le Model Context Protocol, publié en novembre 2024, a repris l’idée de description standardisée des outils, mais côté serveur plutôt que côté application appelante. Un serveur MCP expose ses outils une seule fois, dans un format commun à tous les clients compatibles, ce qui a permis de supprimer notre couche d’adaptation maison sur les projets où nous l’avons adoptée en 2025.
Ce que cette rétrospective enseigne
Aucune des trois premières tentatives n’était mauvaise en soi : chacune répondait à une contrainte réelle du moment. Mais leur absence de standardisation partagée entre fournisseurs a coûté un temps de maintenance considérable, réparti sur plusieurs années, pour un problème que le protocole actuel résout par construction.
Sur nos projets, le vrai gain de MCP n’a pas été fonctionnel — nos agents faisaient déjà ce qu’on attendait d’eux — mais organisationnel : une seule description d’outil à maintenir, quel que soit le modèle appelant.
Pour aller plus loin
Un développeur qui découvre aujourd’hui le Model Context Protocol sans avoir vécu les tentatives précédentes risque de sous-estimer ce qu’il apporte réellement. Ce n’est pas une nouvelle capacité d’appel de fonction, mais la fin d’une fragmentation qui a coûté cher à chaque projet multi-fournisseurs mené entre 2023 et 2024.
