Agent IA sur Sylius 1 : faut-il migrer vers Sylius 2 ?
Non, migrer n'est pas obligatoire : un agent IA peut fonctionner sur Sylius 1.x, en passant par l'API existante ou par du code intégré à l'application. En revanche, les trois plugins IA officiels de Sylius exigent la version 2.1 ou plus, et 2.2 pour Ask AI. La migration devient donc un préalable si vous voulez vous appuyer sur l'écosystème officiel, ou si elle était de toute façon prévue.
Je suis développeur Sylius et Symfony indépendant. Je fais des migrations Sylius 2 et j'intègre des agents IA, ce qui me place au milieu de cette question. Beaucoup de boutiques tournent encore sous Sylius 1.x, et leurs propriétaires se demandent s'ils doivent financer deux chantiers ou un seul. Voici comment je raisonne. La démarche générale est sur la page agents IA pour Sylius.
Qu'est-ce qui est impossible sur Sylius 1.x ?
Installer les plugins IA officiels. Le Shop MCP, l'Admin MCP et Ask AI déclarent tous une dépendance à Sylius 2.1 ou plus dans leur fichier de dépendances, et Ask AI exige 2.2. Composer refusera de les installer sur une boutique 1.x, et je n'ai trouvé aucun plugin IA officiel pour cette branche. Les écarts techniques sont réels : Sylius 1.14 s'appuie sur API Platform 2.7 et PHP 8.1, alors que Sylius 2.0 est passé à API Platform 4 et PHP 8.2.
Ce n'est donc pas une question de réglage. Les plugins IA reposent aussi sur symfony/mcp-bundle et, pour Ask AI, sur Symfony AI et Symfony 7.4. Ils ne sont pas pensés pour une pile plus ancienne.
Qu'est-ce qui reste possible sans migrer ?
L'essentiel d'un agent métier. Un agent de service client, par exemple, n'a pas besoin de MCP : il a besoin de lire les commandes, les expéditions, les paiements et le client concerné, puis de préparer une réponse. Ces données sont dans votre base, accessibles par l'API de Sylius 1.14 ou, plus simplement, par les services de l'application. Je peux écrire ces outils moi-même, en lecture seule, avec les accès par rôle qui conviennent.
Le modèle de langage, lui, est appelé par son API, indépendamment de la version de Sylius. Un agent peut aussi tourner dans un service à côté de la boutique, qui ne lit que ce qu'on lui expose. Ce découplage a un avantage : le jour de la migration, seule la couche d'accès aux données change.
| Situation | Ce que je conseille | Pourquoi |
|---|---|---|
| Sylius 1.x, migration non prévue, besoin urgent sur le service client | Agent sur mesure, accès aux données isolé | Le besoin n'attend pas, l'agent survivra à la migration |
| Sylius 1.x, migration déjà budgétée | Migrer d'abord, puis l'agent | Éviter d'écrire deux fois l'accès aux données |
| Sylius 1.x, envie d'Ask AI dans l'admin | Migrer vers 2.2 ou plus | Le plugin ne s'installe pas autrement |
| Sylius 2.0 ou 2.1 | Mise à niveau mineure si un plugin l'exige | Écart plus faible qu'une migration majeure |
| Sylius 2.2 ou plus | Évaluer les plugins officiels comme briques | Ils s'installent, mais restent en 0.x |
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 décider sans se tromper de chantier ?
Je pars du problème du commerçant, pas de la technique. Si votre boîte de contact déborde avant les soldes, si les demandes de retour s'empilent, ce problème a une date. Une migration bien faite demande du temps, des tests et une bascule soignée. Il serait dommage de faire attendre le premier pour la seconde, sauf si la migration était déjà nécessaire pour d'autres raisons.
Ces autres raisons existent souvent. Sylius 1.14 reçoit encore des correctifs de sécurité, la v1.14.21 est sortie le 22 octobre, mais l'écosystème avance sur la branche 2 : nouveaux plugins, Symfony 7.4, API Platform 4. Pour mesurer l'effort, j'utilise Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Il repère dans votre code ce qui bloque le passage à Sylius 2, ce qui donne une base concrète pour estimer l'effort avant toute décision. La démarche est détaillée sur la page migration Sylius 2.
Un agent construit sur Sylius 1 sera-t-il perdu à la migration ?
Non, s'il est construit pour durer. Trois choix le garantissent. Les accès aux données passent par quelques classes clairement isolées, et pas par des requêtes éparpillées. Les règles du commerçant vivent dans un prompt système versionné, indépendant de Sylius. Et un jeu de cas réels anonymisés est rejoué après la migration pour vérifier que l'agent répond toujours juste : c'est la couche tests et traces.
Après la migration, on peut garder l'accès sur mesure ou basculer une partie vers l'Admin MCP officiel, si son niveau de maturité convient à ce moment-là. Ce que l'agent ne fait jamais seul, avant comme après la migration : envoyer un mail, rembourser ou valider une action. Ces interdits sont dans le code, pas dans la version de Sylius.
Et si je suis déjà sous Sylius 2 ?
Vous avez le choix entre les plugins officiels et le sur mesure, ou un mélange des deux. Pensez simplement à tenir la boutique à jour : la version 2.3.2 a corrigé six failles, dont une qui donnait accès aux données d'autres clients par l'API boutique. Je compare les approches dans l'article plugin ou sur mesure, et je fais l'inventaire de l'existant dans l'état des lieux de l'IA dans Sylius.
Pour savoir dans quel ordre mener les travaux chez vous, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je regarde votre version de Sylius et votre code, et je vous propose la solution qui rentre dans votre budget.