Agent IA multicanal Sylius : un agent, plusieurs boutiques
Oui, un agent IA peut gérer plusieurs canaux Sylius, et même plusieurs boutiques séparées. La condition est qu'il sache, à chaque message, à quel canal il a affaire : c'est ce qui détermine la langue, la devise, les prix, les moyens de livraison et de paiement, les promotions et les règles commerciales à appliquer. Le canal doit être établi par le code, à partir de la commande ou de l'adresse de contact, jamais deviné par le modèle.
Je suis développeur Sylius et Symfony indépendant, et le multicanal est l'une des raisons pour lesquelles beaucoup de marchands choisissent Sylius. C'est aussi ce qui rend un agent plus délicat à construire : une bonne réponse sur un canal peut être fausse sur un autre. Voici comment je l'aborde dans un agent IA pour Sylius.
Qu'est-ce qui change d'un canal Sylius à l'autre ?
Dans Sylius, un canal est une vitrine : il a son nom d'hôte, sa devise de base, ses langues, et on lui rattache des prix, des moyens de livraison, des moyens de paiement et des promotions. Deux canaux d'une même installation peuvent donc vendre le même produit à un prix différent, avec des transporteurs différents et des conditions différentes.
| Élément | Propre au canal ? | Conséquence pour l'agent |
|---|---|---|
| Langue et devise | Oui | Répondre dans la bonne langue, citer la bonne devise |
| Prix des variantes | Oui, prix par canal | Ne jamais citer le prix d'un autre canal |
| Livraison et paiement | Oui | Proposer seulement ce que le canal permet |
| Promotions | Oui | Ne pas promettre un code valable ailleurs |
| Conditions de retour | Selon vos règles | Charger les règles écrites du bon canal |
| Clients | Partagés entre canaux | Lire l'historique, mais sur le bon périmètre |
La dernière ligne surprend souvent : dans une même installation Sylius, un client peut avoir commandé sur plusieurs canaux. L'agent doit alors savoir de quelle commande on parle avant de répondre.
Comment l'agent sait-il quel canal s'applique ?
Par le code, jamais par le modèle. Quand un message arrive, l'agent retrouve le client sur son adresse e-mail exacte, puis la commande concernée, et la commande porte son canal. Si le message arrive par une adresse de contact propre à un canal, c'est une deuxième indication. Si plusieurs commandes sur plusieurs canaux sont possibles, l'agent ne choisit pas au hasard : il le signale dans son brouillon.
Une fois le canal établi, les outils de l'agent ne lisent que dans ce périmètre, et ses documents sont ceux du canal : conditions de vente, politique de retour, FAQ. C'est le même principe que sur l'agent de service client que je construis en ce moment pour une boutique sous Sylius 2 : l'agent ne reçoit que les données du client concerné, et applique les règles écrites du commerçant en citant la règle.
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.
Plusieurs canaux ou plusieurs boutiques : quelle différence ?
Plusieurs canaux d'une même installation partagent une base, un catalogue et des clients. Un agent unique est alors naturel : il charge les règles du canal à chaque message.
Plusieurs installations Sylius séparées, parfois pour des marques ou des pays différents, ont chacune leur base et leurs accès. L'agent peut être commun, mais chaque connexion doit être étanche. Je donne à l'agent un accès distinct par boutique, et c'est le code qui choisit lequel utiliser selon la boîte de réception ou le domaine. Un message reçu pour une boutique ne doit jamais pouvoir faire lire les données d'une autre. C'est une question d'accès par rôle, développée dans l'article sur les données que l'agent ne doit pas montrer.
Ce que l'agent ne fait jamais seul : appliquer à un canal la règle, le prix ou la promotion d'un autre, ni passer d'une boutique à l'autre parce qu'un client le lui demande.
Comment tenir des règles différentes par canal ?
Les règles écrites du commerçant sont rangées par canal, dans des documents distincts et versionnés. Quand une règle est commune à tous les canaux, elle est écrite une seule fois et partagée ; quand elle diffère, chaque canal a sa version. L'agent cite, dans chaque proposition, la règle et le canal auxquels il se réfère, ce qui permet à la personne qui valide de repérer en un coup d'œil une confusion. Et les cas de test rejoués avant chaque changement couvrent chaque canal, pour qu'une modification pensée pour l'un ne casse pas l'autre.
Les promotions méritent une attention particulière : un code valable sur un canal ne l'est pas forcément sur un autre. Si l'agent doit en parler, il les lit dans Sylius au lieu de s'en souvenir ; voyez l'article sur les promotions.
Que proposent les briques officielles de Sylius ?
Le serveur MCP boutique de Sylius expose quinze outils, dont un pour lire les informations d'un canal. Il fonctionne en mode invité uniquement : il ne consulte pas le compte ni les commandes d'un client connecté. Le serveur MCP d'administration expose l'API d'administration, avec une authentification OAuth et des groupes d'outils que l'on peut désactiver. Les deux exigent Sylius 2.1 ou plus et sont en version 0.x. Ce sont des briques prometteuses, mais pas une solution multicanal clé en main ; la comparaison avec le sur mesure est dans l'article API, MCP ou code.
Et les clients étrangers ?
Le multicanal va souvent de pair avec plusieurs langues. L'agent s'appuie sur la langue de la commande et du canal pour rédiger son brouillon, et sur des documents traduits pour ne pas improviser une règle dans une langue où elle n'a pas été écrite. Le sujet est développé dans l'article sur le service client multilingue.
Pour savoir comment un agent suivrait vos canaux et leurs règles, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je regarde votre configuration Sylius et je vous propose une solution qui rentre dans votre budget.