« Où en est ma commande ? » : l'automatiser sur Sylius
Pour répondre automatiquement à « Où en est ma commande ? » sur Sylius, un agent IA retrouve le client par son adresse e-mail exacte, lit l'état de sa commande et de son expédition, ajoute le suivi du transporteur s'il y a accès, puis prépare une réponse précise. Le modèle ne devine rien : il reformule des données lues dans la boutique. Au départ, chaque réponse reste un brouillon qu'une personne relit avant envoi.
C'est souvent la question la plus fréquente d'une boîte de contact e-commerce, et la plus frustrante à traiter : la réponse existe déjà dans l'administration, mais il faut aller la chercher, message après message. Je suis développeur Sylius indépendant et j'intègre des agents IA dans des boutiques Sylius. Voici comment je traite ce cas précis.
Pourquoi cette question coûte-t-elle autant de temps ?
Chaque « où en est ma commande ? » suit le même rituel. Ouvrir le message, chercher le client dans l'administration, trouver la bonne commande parmi plusieurs, regarder l'état de paiement et d'expédition, copier le numéro de suivi, ouvrir le site du transporteur, puis rédiger une réponse polie. Cela prend quelques minutes, multipliées par des dizaines de messages en période chargée.
Le client, lui, attend. Et plus il attend, plus il relance, ce qui ajoute des messages à une file déjà longue. Un chatbot classique ne règle rien ici : il ne voit pas la commande et se contente de renvoyer vers la page de suivi. C'est la différence que j'explique dans l'article sur chatbot et agent IA.
Que lit l'agent dans Sylius pour répondre juste ?
Sylius stocke tout ce qu'il faut. Une commande porte un état général, un état de paiement et un état d'expédition. Chaque expédition a sa méthode de livraison, son état et, quand il a été saisi, son code de suivi. L'agent lit ces informations pour le seul client concerné, et rien d'autre.
| Situation lue dans Sylius | Ce que l'agent prépare |
|---|---|
| Paiement en attente | Un rappel que la commande attend son paiement, avec le moyen choisi |
| Payée, pas encore expédiée | La confirmation de prise en compte et le délai de préparation écrit dans vos règles |
| Expédiée avec un code de suivi | La date d'expédition, le transporteur, le numéro et le dernier événement de suivi |
| Plusieurs commandes récentes | Une réponse qui distingue chaque commande au lieu d'en choisir une au hasard |
| Aucune commande trouvée | Une demande polie du numéro de commande, signalée à un humain |
Le point clé est l'identification. Le client est retrouvé par le code, sur son adresse e-mail exacte, et non par une interprétation du modèle. C'est la couche des accès par rôle : l'agent ne reçoit que les données de ce client, ce qui l'empêche d'en révéler un autre, même si on le lui demande habilement.
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.
Par où l'agent passe-t-il : API, MCP ou code ?
Sylius 2 expose une API sous /api/v2. Dans la configuration standard de Sylius 2.3, la partie /api/v2/shop/account exige un client connecté et la partie /api/v2/admin exige le rôle ROLE_API_ACCESS, comme le montre le fichier de sécurité de Sylius-Standard. Un agent de service client qui lit les commandes de n'importe quel client passe donc par l'accès administrateur, ou par du code intégré à la boutique.
On me demande souvent si le serveur MCP officiel de Sylius suffit. Pour ce cas, non. Son README indique que ses outils fonctionnent en mode invité uniquement : la consultation de commande ne renvoie qu'une commande qui n'est rattachée à aucun compte client. C'est une brique intéressante pour un assistant d'achat, pas pour lire l'historique d'un client inscrit. Le plugin MCP d'administration, lui, passe par OAuth et le rôle ROLE_API_ACCESS, mais il est encore en version 0.x et demande Sylius 2.1 ou plus. Je le considère comme une piste prometteuse, pas comme une solution clé en main.
Exposer l'API à un agent impose aussi d'être à jour. La version 2.3.2 de Sylius a corrigé une faille qui permettait, par un chemin encodé, de contourner des filtres de l'API shop et d'accéder aux données d'autres clients. Une boutique en retard de correctifs doit d'abord être mise à niveau.
Comment ajouter le suivi Colissimo ou La Poste ?
Sylius connaît le numéro de suivi, pas la position du colis. Pour savoir que le colis est « en cours d'acheminement » ou « disponible en point de retrait », l'agent doit interroger le transporteur. La Poste propose sur son portail développeurs une API « Suivi » qui couvre courrier, colis et Chronopost, avec un compte ; les offres y sont gratuites ou payantes selon les besoins. C'est un outil de plus, en lecture seule, que l'agent appelle avec le numéro lu dans Sylius.
Pour les autres transporteurs, je vérifie au cas par cas ce que leur documentation officielle permet. À défaut d'API, l'agent donne au client le numéro et le lien de suivi public, ce qui règle déjà une bonne partie des demandes.
Ce que l'agent ne fait jamais seul
Sur une question de suivi, l'agent ne promet jamais une date de livraison que le transporteur n'a pas donnée, ne déclare pas un colis perdu, ne propose ni renvoi ni geste commercial. Si le suivi est bloqué depuis plusieurs jours, il le signale et prépare un brouillon prudent ; la décision revient à une personne. Le traitement des colis vraiment introuvables est un sujet à part, que je détaille dans l'article sur les colis non reçus.
Ces limites ne sont pas de simples consignes dans le prompt. Sur l'agent de service client que je construis en ce moment pour une boutique sous Sylius 2, l'agent n'a tout simplement pas d'outil pour envoyer un mail, rembourser ou valider quoi que ce soit : il prépare un brouillon dans Gmail et une action en attente dans l'administration. Les garde-fous sont dans le code, pas dans la bonne volonté du modèle.
Faut-il envoyer les réponses automatiquement ?
Le suivi de commande est le meilleur candidat à l'envoi automatique, parce que la réponse est factuelle et vérifiable. Mais je ne commence jamais par là. Les premières semaines, chaque réponse est un brouillon. On mesure combien sont envoyées sans retouche, on corrige les règles, puis on décide, type de message par type de message, de ce qui peut partir seul.
Cette prudence a une autre raison : en France, la CNIL rappelle dans ses conseils sur les chatbots qu'une conversation sans intervention humaine ne peut conduire à elle seule à des décisions importantes. Donner un statut de livraison n'en est pas une ; refuser un renvoi en est une. Pour savoir si vos messages relèvent d'abord d'un tri, voyez l'article sur le tri des messages clients.
Par où commencer ?
Relisez vos cinquante derniers messages. Si une bonne part demande où en est une commande, c'est un premier cas d'usage idéal : fréquent, factuel, peu risqué. Je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je passe votre boutique Sylius au crible des huit couches, et je vous propose la solution qui rentre dans votre budget, sans abonnement de plateforme imposé, avec un code qui vous appartient.