Votre produit a besoin d’un serveur MCP : exposer les données e-commerce aux agents IA en toute sécurité

Le Model Context Protocol est passé d’intéressant à structurant plus vite que la plupart des standards d’intégration. Shopify fournit des serveurs MCP à chaque boutique ; les principaux assistants peuvent utiliser des outils sur des systèmes externes ; et une part significative du trafic web provient désormais d’automates plutôt que de visiteurs humains.

Pour toute personne exploitant une plateforme e-commerce ou un produit SaaS, cela pose une question concrète à la réponse non évidente : vous disposez déjà d’une API — pourquoi un agent aurait-il besoin d’autre chose ?

Pourquoi votre API REST ne suffit pas

Une API REST est conçue pour un développeur qui lit la documentation, comprend votre domaine et écrit du code pour appeler les bons endpoints dans le bon ordre. Un agent n’a aucun de ces avantages. Il dispose d’une liste d’outils, d’une description pour chacun, et d’une seule tentative pour choisir le bon.

Les différences importantes :

• Découverte. Un agent doit découvrir à l’exécution ce que votre système sait faire, à partir de l’interface elle-même. Votre spécification OpenAPI décrit les endpoints, pas les intentions.
• Granularité. Les API REST sont structurées par ressource : récupérer la commande, le client, les lignes, puis tout assembler. Un agent attend un appel qui répond directement à quel est le statut de la dernière commande de ce client — une tâche, pas une ressource.
• Ambiguïté. Un développeur résout le bleu, taille M en consultant votre modèle de variantes. Un agent a besoin d’un outil qui accepte cette formulation et effectue la résolution.
• Gestion des erreurs. Un 422 avec un objet de validation aide un développeur. Un agent a besoin d’une erreur qui explique, en toutes lettres, ce qu’il faut corriger.
• Périmètre d’impact. L’erreur d’un développeur est détectée dans sa suite de tests. Celle d’un agent survient en production, pour le compte d’un client, en temps réel.

Un serveur MCP n’est pas un simple habillage de votre API. C’est une interface différente, pensée pour un autre utilisateur, mais qui s’appuie sur la même logique métier.

Concevez les outils autour des tâches, pas des ressources

Le facteur principal qui détermine la qualité d’utilisation de votre produit par un agent est la façon dont vous nommez et cadrez les outils. Privilégiez peu d’outils, bien décrits et orientés tâches, plutôt qu’un reflet fidèle de votre modèle de données.

Pour un produit e-commerce, le jeu d’outils de départ ressemble généralement à ceci :

• search_products — requête en langage naturel en entrée, résultats classés avec les attributs nécessaires pour comparer. Ce n’est pas un export brut du catalogue.
• get_product_details — toutes les informations nécessaires à la décision : variantes, disponibilité, délai de livraison, conditions de retour.
• check_availability — quantité et localisation, fournis directement plutôt qu’inférés à partir d’un objet stock.
• get_order_status — la question réellement posée par les clients, avec une seule requête.
• start_return — une écriture encadrée, soumise à vos vraies règles d’éligibilité.
• get_policy — conditions de retour, d’expédition et de garantie sous forme textuelle, pour que l’agent cite votre politique et non une approximation.

Rédigez les descriptions d’outils comme pour un nouveau collègue compétent à son premier jour : ce que fait l’outil, quand l’utiliser, quand ne pas l’utiliser, et ce qu’il refusera. Ces descriptions constituent tout le manuel utilisateur dont l’agent disposera, et leur clarté compte plus que la qualité du modèle.

Ce qui ne doit jamais devenir un outil

Les exclusions sont plus importantes que les inclusions, car tout outil exposé finira par être appelé d’une façon que vous n’aviez pas anticipée.

• Toute opération sur les moyens de paiement. Tokenisez, déléguez, et ne laissez jamais les données de carte transiter par la surface agent.
• Export de données en masse. Un outil qui retourne tout votre catalogue ou la liste des clients est un endpoint de scraping, en plus poli.
• Opérations administratives. Modifications de prix, ajustements de stock, gestion des utilisateurs. Si c’est dans votre interface d’administration, ce n’est pas dans votre serveur MCP.
• Toute action sans contrôle d’autorisation par locataire, appliqué côté serveur à chaque appel.
• Requêtes inter-clients. Un agent agissant pour un client doit être structurellement incapable d’accéder aux données d’un autre — il ne suffit pas qu’il soit peu probable qu’il le fasse.

Authentification, droits d’accès et limitations

C’est là que la plupart des implémentations sont les plus faibles, car la conception des outils est intéressante, mais tout le reste est fastidieux.

1. Authentifiez l’agent, puis identifiez distinctement la personne pour qui il agit. Ce sont deux informations différentes, et les confondre ouvre la porte à l’accès inter-clients.
2. Limitez strictement les droits d’accès. Un agent qui explore les produits n’a pas besoin d’accéder à l’historique des commandes. Délivrez des identifiants par usage et faites-les expirer.
3. Appliquez un rate limiting par locataire et par outil. Les agents réessaient sans relâche. Une limite généreuse pour un humain est facilement dépassée par une boucle.
4. Consignez chaque appel avec ses arguments et son résultat. En cas d’incident, vous devrez reconstituer précisément la demande et la réponse. Ce journal est aussi votre première ligne de détection des abus.
5. Versionnez vos outils. Modifier le comportement d’un outil sans avertir casse les agents qui s’y sont adaptés, et contrairement à une intégration pour développeurs, personne ne consultera votre journal des modifications.
6. Ajoutez des clés d'idempotence aux outils d’écriture. Un agent qui subit un dépassement de délai et réessaie ne doit pas générer deux retours.

Les données sous-jacentes déterminent tout

Un serveur MCP expose vos données produits. Si ces données sont incomplètes, incohérentes ou erronées, l’agent les restituera telles quelles — rapidement, avec assurance, face au client.

Avant de construire l’interface, vérifiez honnêtement si le catalogue peut la supporter. Exhaustivité des attributs, taxonomie cohérente, données de stock et de livraison fiables, politique de retours structurée (et non en PDF) sont indispensables. Nous avons détaillé notre méthode pour amener un catalogue à ce niveau ; c’est peu valorisé, mais c’est le vrai projet.

Est-ce pertinent de le développer maintenant ?

Une évaluation honnête, car le domaine évolue vite et il existe un vrai coût à être trop précoce.

Lancez-vous maintenant si : vous êtes sur une plateforme qui expose déjà MCP et que vous l’étendez ; votre produit cible les développeurs, où l’usage assisté par agent est déjà courant ; ou vous vendez un produit qu’un assistant pourrait raisonnablement rechercher pour un client.

Attendez si : vos données produits ne sont pas prêtes à être citées telles quelles par une machine ; vous n’avez pas la capacité de suivre et d’itérer sur une interface agent en production ; ou vos clients ne passent pas par ce canal — et vous l’avez vérifié, pas supposé.

Dans tous les cas, faites le travail préalable dès maintenant. Des données produits propres, des politiques structurées et une API métier adaptée sont utiles quel que soit le protocole retenu, et ce sont les étapes les plus longues. La couche MCP se construit ensuite rapidement.

Notre pratique Node.js construit ces interfaces, et la question plus large de la place des canaux agents dans une stratégie commerce est précisément ce à quoi répondent notre travail d’intégration IA et notre équipe d’ingénierie IA. Si votre priorité est d’être trouvé par les assistants plutôt que transigé avec, c’est un projet connexe mais distinct — voir comment faire recommander vos produits par ChatGPT et Perplexity.

Commencez par la liste des outils

Avant toute ligne de code, listez les six actions qu’un agent doit pouvoir réaliser avec votre produit, et les six qu’il ne doit jamais faire. Ce document constitue l’essentiel de la conception. Nous l’écrivons avec vous. Contactez notre équipe ; réponse sous un jour ouvré.