Novembre 2024 : le Model Context Protocol est publié par Anthropic. Une extension WordPress construite en 2023, bien avant que ce standard n’existe, exposait déjà à un agent onze fonctions de facturation Stripe via du function calling classique — création de client, génération de facture, application d’un avoir, entre autres. La question, dix-huit mois plus tard, n’était pas de savoir s’il fallait migrer vers MCP, mais comment le faire sans réécrire ni interrompre un système qui tournait en production depuis plus d’un an.
Réécrire les onze fonctions d’un coup, avec le risque de régression que cela implique sur un système qui gère de la facturation réelle, n’était pas envisageable. L’architecture retenue introduit une couche intermédiaire qui permet aux deux mondes de coexister le temps de la transition.
L’état de départ
extension-facturation-ia/
├── includes/
│ ├── class-fonctions-llm.php # 11 fonctions exposées en function calling
│ ├── class-appel-openai.php # appel direct à l'API Chat Completions
│ └── class-stripe-client.php # wrapper autour du SDK Stripe PHP
└── extension-facturation-ia.php
Chaque fonction était décrite dans un tableau PHP passé directement à l’appel API, avec son propre schéma de paramètres, sans aucune couche d’abstraction entre la définition de la fonction et son exécution réelle contre l’API Stripe.
L’architecture cible : une façade commune
Plutôt que de dupliquer la logique métier dans un nouveau serveur MCP, l’ensemble des fonctions de facturation a été extrait dans une couche de services PHP indépendante de tout protocole, appelée à la fois par l’ancien mécanisme de function calling et par le nouveau serveur MCP construit avec le plugin MCP Adapter :
extension-facturation-ia/
├── includes/
│ ├── services/
│ │ └── class-service-facturation.php # logique métier, protocole-agnostique
│ ├── class-fonctions-llm.php # appelle le service (function calling)
│ ├── class-mcp-outils-facturation.php # appelle le même service (MCP)
│ └── class-stripe-client.php
└── extension-facturation-ia.php
Cette extraction a représenté l’essentiel du travail de migration : chaque fonction existante a été « vidée » de sa logique, qui a migré vers le service, ne laissant dans class-fonctions-llm.php qu’un appel de façade vers ce service commun.
La bascule outil par outil
Les onze fonctions ont été migrées une par une sur six semaines, en commençant par les moins critiques (consultation d’une facture existante) avant de s’attaquer aux plus sensibles (émission d’un avoir). Chaque outil MCP nouvellement exposé a coexisté plusieurs jours avec son équivalent en function calling avant que ce dernier ne soit désactivé, le temps de vérifier que le comportement restait identique sur des cas réels.
- Extraction de la logique métier dans un service protocole-agnostique
- Exposition de l’outil équivalent via le serveur MCP
- Période de coexistence avec surveillance des deux chemins
- Désactivation de l’ancienne fonction en function calling
Ce qui a été gardé volontairement
Le client Stripe PHP existant (class-stripe-client.php) n’a pas été touché : il fonctionnait correctement et gérer une nouvelle couche d’accès (MCP) ne justifiait aucune remise en cause de la couche d’accès à l’API Stripe elle-même. Seule l’interface entre le modèle de langage et cette logique métier a changé de protocole.
Migrer vers MCP ne veut pas dire réécrire ce qui fonctionne ; cela veut dire changer la porte d’entrée, pas la maison derrière.
En résumé
Cette migration progressive a permis de conserver un système de facturation stable pendant toute la transition, en isolant le vrai changement (le protocole d’exposition à l’agent) de ce qui n’avait pas besoin de changer (la logique métier et le client Stripe). La sécurité de cette migration, notamment le contrôle des accès pendant la période de coexistence des deux mécanismes, mériterait cependant un traitement à part entière.
