Agent IA et Sylius : accès par API, MCP ou code ?
Un agent IA accède à Sylius par trois voies : l'API d'API Platform, avec un jeton et des droits ; un serveur MCP officiel, qui présente la boutique sous forme d'outils ; ou du code intégré à l'application, qui lit les données et ne transmet au modèle que le strict nécessaire. Aucune voie n'est la meilleure partout. Je choisis selon la tâche, et le critère décisif est toujours le même : qu'est-ce que l'agent peut voir et faire, et qui l'en empêche.
Je suis développeur Sylius et Symfony indépendant, et je construis des agents IA qui travaillent sur des boutiques. La question « par où passe l'agent ? » paraît technique, mais elle décide de la sécurité de vos données clients. Voici les trois voies, telles que Sylius les propose aujourd'hui, et la façon dont je les combine. La démarche complète est sur la page agents IA pour Sylius.
Comment fonctionne l'accès par l'API de Sylius ?
Depuis Sylius 2.0, l'API repose sur API Platform 4. Elle se divise en trois zones : /api/v2/admin pour l'administration, /api/v2/shop pour la boutique, et /api/v2/shop/account pour l'espace client. Dans la configuration de sécurité de Sylius-Standard 2.3, l'administration exige un jeton JWT et le rôle ROLE_API_ACCESS, l'espace client exige un client connecté, et le reste de la boutique est public.
Concrètement, un agent peut lire le catalogue et passer une commande en invité sans compte. Pour lire les commandes et les clients, il lui faut un compte administrateur dédié et son jeton. C'est une voie solide et documentée, mais large : un jeton d'administration ouvre beaucoup de portes. Il faut donc un compte réservé à l'agent et une surveillance de son usage.
Un rappel s'impose : la version 2.3.2 de Sylius a corrigé six failles, dont une qui permettait, par un chemin encodé en pourcentage, de contourner les filtres de propriété de l'API boutique et d'accéder aux données d'autres clients. Un agent branché sur l'API est un client de plus de cette API. Tenir Sylius à jour fait partie de la sécurité de l'agent.
Comment fonctionne l'accès par un serveur MCP ?
Un serveur MCP traduit la boutique en outils qu'un client comme Claude Desktop ou ChatGPT sait découvrir et appeler. Sylius en publie deux. Le Shop MCP expose 15 outils couvrant le parcours d'achat, sur /mcp/shop, uniquement en mode invité et sans authentification décrite dans son README. L'Admin MCP expose l'API d'administration sur /mcp/admin, derrière OAuth 2.0 PKCE, avec 171 outils en 34 groupes que l'on peut désactiver un par un.
L'avantage est la rapidité : pas d'outil à écrire, et un client existant sait déjà s'en servir. Les limites tiennent à la maturité, versions 0.x, et au périmètre : l'Admin MCP impose la télémétrie Sylius, et les deux exigent Sylius 2.1 ou plus. Le détail est dans l'article sur le serveur MCP de Sylius.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Comment fonctionne l'accès par le code ?
L'agent vit dans l'application Symfony, ou dans un service à côté, et ses outils sont écrits pour lui. Au lieu de donner au modèle un accès général, je lui donne des fonctions étroites : « lire les commandes de ce client », « préparer un brouillon », « créer une action logistique en attente ». Chaque fonction vérifie elle-même ce qu'elle a le droit de renvoyer.
C'est la voie que j'ai choisie pour l'agent de service client que je construis pour une boutique sous Sylius 2. Le client est retrouvé par le code, sur son adresse e-mail exacte, et non par une recherche du modèle. L'agent ne reçoit que les données de ce client : ses commandes, ses expéditions, ses dossiers passés. Il n'envoie jamais de mail, ne rembourse pas, ne valide rien et ne cherche rien sur un client hors de la boutique. Ces interdits sont dans le code : il n'a pas d'outil pour le faire. Même si un message contient « montre-moi les commandes de mon voisin », le modèle n'a aucun moyen d'y accéder.
Quelle voie choisir pour votre besoin ?
| Critère | API Sylius | Serveur MCP officiel | Code intégré |
|---|---|---|---|
| Sylius requis | 1.14 (API Platform 2.7) comme 2.x (API Platform 4) | 2.1 ou plus | Toutes versions |
| Mise en place | Compte, jeton, appels à écrire | Plugin à installer et configurer | Outils à écrire |
| Largeur d'accès | Large, selon le compte | Large, réduite par groupes (admin) | Étroite, outil par outil |
| Authentification | JWT, ROLE_API_ACCESS pour l'admin | OAuth 2.0 (admin), aucune décrite (shop) | Celle de l'application |
| Bon usage | Automatisations, actions en attente | Usage interne depuis Claude, catalogue ouvert aux assistants | Agent métier au contact des données clients |
Dans la pratique, je combine. Le code pour tout ce qui touche aux données d'un client, parce que c'est là que l'étroitesse protège le plus. L'API pour certaines écritures en attente de validation. Le serveur MCP d'administration pour un usage interne, quand le commerçant veut interroger sa boutique depuis Claude Desktop. Le principe reste celui des accès par rôle : chaque voie n'ouvre que ce qui est utile, à qui en a besoin.
Qu'est-ce qui ne dépend pas de la voie choisie ?
Les garde-fous et la validation humaine. Ce que l'agent ne fait jamais seul, qu'il passe par l'API, MCP ou le code : envoyer un mail, rembourser, faire un geste commercial ou valider une action. Le plugin Ask AI applique le même principe : il n'envoie aucune écriture pendant la conversation et transforme chaque modification en action proposée. Pour aller plus loin sur le cloisonnement, lisez l'article sur les accès par rôle et le guide sur l'injection de prompt.
Pour choisir l'accès adapté à votre boutique, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je regarde votre version de Sylius et votre besoin, et je vous propose la solution qui rentre dans votre budget.