Migrer une extension IA codée avant MCP sans tout réécrire

Une extension maison développée en 2023 permettait déjà à un assistant interne de récupérer des informations produit et de proposer des descriptions via l’API d’un fournisseur de LLM, avec un système de function calling codé en dur dans le plugin. Le client souhaitait désormais ouvrir ces mêmes fonctions à un agent externe capable de se connecter via MCP, sans immobiliser l’équipe sur une réécriture complète pendant plusieurs semaines.

Voici la recette suivie, fonction par fonction, qui a permis de livrer un serveur MCP fonctionnel en gardant l’extension existante opérationnelle à chaque étape.

Étape 1 : cartographier l’existant avant de toucher au code

Avant d’écrire une seule ligne, nous avons listé les six fonctions PHP que l’extension exposait déjà au mécanisme de function calling du fournisseur : récupération de fiche produit, mise à jour de description, recherche par catégorie, vérification de stock, génération de variante de texte, et export d’un lot de fiches. Chacune avait déjà sa propre signature et son propre traitement des erreurs, hérités de trois années d’évolutions successives.

Étape 2 : écrire une couche d’adaptation, pas une réécriture

Plutôt que de réécrire ces six fonctions pour un nouveau format, nous avons ajouté une fine couche qui les enregistre comme outils MCP, en réutilisant leur signature existante telle quelle. Le schéma d’entrée déclaré côté MCP correspond exactement aux paramètres déjà attendus par la fonction PHP d’origine.

// Fonction existante, inchangée depuis 2023
function agence_get_product_sheet( $product_id ) {
    $produit = wc_get_product( $product_id );
    if ( ! $produit ) {
        return new WP_Error( 'not_found', 'Produit introuvable' );
    }
    return array(
        'id'          => $produit->get_id(),
        'nom'         => $produit->get_name(),
        'description' => $produit->get_description(),
        'stock'       => $produit->get_stock_quantity(),
    );
}

// Couche d'adaptation ajoutée, aucune réécriture de la fonction ci-dessus
function agence_register_mcp_tools( $serveur_mcp ) {
    $serveur_mcp->register_tool( array(
        'name'        => 'get_product_sheet',
        'description' => 'Récupère la fiche complète d\'un produit par son identifiant.',
        'inputSchema' => array(
            'type'       => 'object',
            'properties' => array( 'product_id' => array( 'type' => 'integer' ) ),
            'required'   => array( 'product_id' ),
        ),
        'callback'    => 'agence_get_product_sheet',
    ) );
}

Étape 3 : migrer une fonction à la fois, jamais tout le lot

Chaque fonction a été enveloppée, testée isolément avec un client MCP de démonstration, puis validée avant de passer à la suivante. Cette approche a permis de repérer, dès la deuxième fonction migrée, un cas où le format de retour d’erreur (WP_Error) devait être converti explicitement en réponse d’erreur MCP structurée, faute de quoi le client recevait un objet PHP sérialisé illisible pour l’agent.

1. Choisir la fonction la plus simple et la moins risquée pour commencer (recherche par catégorie, en lecture seule).
2. Écrire la déclaration d’outil MCP correspondante sans modifier la fonction PHP.
3. Tester avec un client MCP minimal, avec des paramètres valides puis invalides.
4. Corriger uniquement la couche d’adaptation si le format de sortie ne convient pas.
5. Passer à la fonction suivante seulement après validation complète de la précédente.

Étape 4 : garder les deux chemins actifs en parallèle

L’ancien mécanisme de function calling directement intégré à l’extension est resté actif tout au long de la migration, sans interruption de service pour les usages existants. Le nouveau serveur MCP a été ouvert à un agent de test en parallèle, sur un sous-domaine dédié, avant toute bascule du trafic réel.

Faire cohabiter l’ancien et le nouveau pendant la migration coûte un peu de complexité temporaire, mais évite le scénario où une régression sur une fonction migrée bloque tout le système en même temps.

Ce que cette recette n’aborde pas

Cette recette ne couvre pas l’écriture d’un serveur MCP entièrement nouveau depuis zéro, déjà traitée dans un autre article : elle part du principe qu’une logique métier existe déjà et fonctionne, et se concentre uniquement sur la façon de l’exposer sans la reconstruire.

En résumé

Migrer une intégration IA existante vers MCP ne demande pas de réécrire la logique métier qui fonctionne déjà : une couche d’adaptation fine, ajoutée fonction par fonction et testée isolément, suffit dans la grande majorité des cas. La discipline la plus importante n’est pas technique mais méthodologique : ne jamais migrer plus d’une fonction à la fois, et garder l’ancien chemin actif jusqu’à validation complète du nouveau.