Les agents IA destinés au commerce électronique sont des systèmes logiciels qui disposent d’identifiants authentifiés et qui interrogent directement votre système de gestion des commandes, votre ERP et vos API de gestion des stocks, puis enregistrent les modifications dans ces systèmes, qu’il s’agisse de créer un devis, de mettre à jour une ligne de commande ou de lancer un retour. Un chatbot analyse votre contenu et génère une réponse. Un agent marchand dispose des autorisations nécessaires et modifie le fonctionnement réel de vos systèmes.
La plupart des responsables de sites de commerce en ligne se sont déjà laissé convaincre d'adopter un chatbot. Celui-ci trône dans un coin de la vitrine, répond aux questions sur les délais de livraison et, de temps à autre, redirige un client vers la page consacrée à la politique de retour. On lui attribue rarement le mérite d'une vente, et on ne lui impute jamais la responsabilité d'une vente qui a mal tourné, car il ne peut intervenir d'aucune manière sur une commande.
Ce n'est pas une limite inhérente au modèle sur lequel il repose. C'est une limite liée à ce qu'il a été autorisé à faire. La distinction entre un chatbot et un véritable agent n'a rien à voir avec le caractère convaincant de la conversation, mais tout à voir avec le pouvoir d'agir : le système se contente-t-il de lire et de répondre, ou est-il capable de s'authentifier, d'appeler un système en temps réel et d'y enregistrer une modification ?
Nous développons des solutions sur Adobe Commerce, Magento Open Source, Shopify et BigCommerce pour les fabricants, les distributeurs et les grossistes, et on nous demande plus souvent de créer « un agent IA » que de définir d’abord ce qu’est un agent IA. Cet article présente la définition, l’architecture et les limites réelles de cette technologie, à l’intention des responsables opérationnels qui ont entendu l’argumentaire et souhaitent savoir ce que cela impliquerait concrètement.
Les agents IA destinés au commerce électronique se distinguent des chatbots par une caractéristique structurelle : ils disposent d’un accès en écriture aux systèmes backend, et non pas seulement d’un accès en lecture à une base de connaissances. Un chatbot est formé ou alimenté à partir du contenu de vos produits, de vos politiques et de vos FAQ, et il génère une réponse à partir de ce contexte. Il ne dispose d’aucune session liée à un compte client réel, d’aucun identifiant d’accès à votre système de gestion des commandes, ni d’aucun moyen de modifier un prix, une quantité ou un statut.
Un agent marchand est conçu différemment dès le départ. Il s'authentifie en tant que client spécifique ou compte de service spécifique, interroge en temps réel l'API de votre produit, le point de terminaison de tarification de votre ERP et votre système de commande, puis valide une modification. Cette modification correspond à une opération d'écriture sur une base de données en production, et non à une simple phrase générée.
C'est pourquoi ces deux catégories ne peuvent pas être évaluées selon les mêmes critères. La qualité d'un chatbot se mesure à sa capacité à répondre correctement à une question. La qualité d'un agent commercial se mesure quant à elle à la conformité du prix qu'il a proposé avec le prix contractuel, à la disponibilité effective en rayon du produit qu'il a confirmé, et à l'adéquation entre la commande qu'il a passée et ce que le client souhaitait réellement.
Une façon de mettre en évidence cet écart consiste à comparer six demandes courantes des acheteurs et à se demander ce que chaque système est réellement capable de faire pour y répondre.
| Capacité | Le rôle d'un chatbot | Le métier d'agent commercial |
| Recherche de prix | Indique le prix catalogue à partir du contenu utilisé pour l'entraînement | Appelle l'API de tarification et renvoie le prix contractuel du client |
| État des stocks | Estimations basées sur des données produit statiques ou mises en cache | Interroge les stocks en direct dans le système ERP et renvoie un décompte en temps réel |
| Création d'un devis | Impossible d'en générer un ; orienter le client vers le service commercial | Génère un devis via les API de commerce et d'ERP |
| Modification de la commande | Impossible de modifier une commande ; indique les coordonnées du service d'assistance | Enregistre la modification directement dans le système de gestion des commandes |
| Lancement de la procédure de retour | Explique la politique de retour sous forme de texte | Vérifie les conditions d'éligibilité et crée l'autorisation de retour (RMA) |
| Réorganiser | Invite le client à consulter à nouveau le catalogue | Récupère l'historique des commandes, recalcule les prix et reconstitue le panier |
Un agent commercial mène la transaction à bien car il est autorisé à accéder aux systèmes sur lesquels celle-ci s'effectue. Il s'agit là d'une question d'autorisations et d'intégration, et non d'une question de conception des interactions ; c'est pourquoi qualifier une version améliorée d'un chatbot d'« agent IA » sans rien changer à son fonctionnement sous-jacent ne tient pas la route.
Chacune de ces actions concerne un système différent, et chacune nécessite ses propres mesures de sécurité, car une erreur dans ce domaine n'est pas une mauvaise réponse, mais une commande erronée.
Chacune de ces six actions repose sur la même exigence fondamentale : les agents IA dédiés au commerce électronique ont besoin d’un accès en écriture, et non d’un accès en lecture, aux systèmes qui gèrent les prix, les stocks et l’état des commandes. C’est la partie du projet qui est souvent sous-estimée, car l’« accès en écriture » donne l’impression d’être une simple case à cocher, alors qu’il s’agit en réalité d’une architecture d’autorisations.
Concrètement, l’accès en écriture implique l’utilisation d’un identifiant OAuth 2.0 à portée limitée, lié à un compte de service, et non d’un identifiant administrateur partagé entre les différentes intégrations. Cela signifie qu’il faut définir précisément les points de terminaison auxquels cet identifiant peut accéder : la création d’une commande, oui ; la suppression d’une fiche client, non. Cela signifie également que chaque opération d’écriture est consignée avec un horodatage, l’identifiant du client et l’identifiant de session de l’agent ; ainsi, en cas de problème, il est possible de remonter jusqu’à l’appel exact à l’origine de l’incident.
L’intégration elle-même s’effectue généralement via une couche middleware telle qu’Alumio, qui se situe entre l’API GraphQL ou REST de la boutique en ligne et l’interface API propre à l’ERP, traduisant et acheminant les appels afin que les agents IA du commerce électronique n’aient pas besoin d’une connexion directe et fragile à Epicor Prophet 21 ou Microsoft Dynamics 365 Business Central. Pour les commerçants utilisant Magento Open Source ou Adobe Commerce en association avec l’un de ces ERP, il s’agit de la même couche d’intégration qui gère déjà aujourd’hui la synchronisation des commandes, étendue pour accepter les opérations d’écriture initiées par un agent plutôt que par une personne uniquement. Nous abordons plus en détail ce modèle d’intégration spécifique dans notre article consacré à l’intégration des ERP avec Magento et Adobe Commerce.
Si nous devions choisir un domaine par lequel commencer, ce serait celui de l'après-vente. Les agents IA chargés des actions d'après-vente présentent moins de risques que ceux impliqués dans la négociation avant l'achat, car la commande existe déjà, le prix est déjà fixé et l'agent met à jour un dossier connu plutôt que de créer un nouvel engagement à partir de zéro.
Le statut « Commande » correspond à la version de base : l’agent authentifie le client, appelle l’API de gestion des commandes et renvoie des données d’expédition réelles au lieu d’une réponse générique du type « consultez votre e-mail ». Le statut « Réapprovisionnement » constitue le niveau suivant : il permet de récupérer une commande antérieure, de recalculer son prix en fonction des conditions contractuelles en vigueur et de reconstituer le panier pour confirmation. Le statut « Lancement du retour » boucle la boucle : il valide l’éligibilité au retour selon une politique déterministe et génère l’autorisation de retour (RMA) sans passer par un ticket d’assistance.
C'est précisément cette séquence d'étapes qui explique pourquoi les agents d'IA chargés des actions post-achat conviennent particulièrement bien aux comptes B2B, où un même client passe des commandes répétées à un prix contractuel fixe.
Le client d'un distributeur envoie la demande suivante : « Commandez à nouveau les kits de roulements du mois dernier, dans la même quantité. » Voici comment un agent bien formé traite cette demande, en 6 étapes.
Chaque point de défaillance dans cette séquence correspond à une lacune d'intégration, et non à une limite du modèle. C'est cette partie du développement d'agents IA pour le commerce électronique qui prend réellement du temps.
Pour que tout ce qui précède soit envisageable, sept conditions doivent être réunies dans l'architecture. Lorsque ces conditions ne sont pas remplies, les agents d'IA destinés au commerce électronique échouent discrètement et sans faire de vagues, ce qui est pire que de ne pas en disposer du tout.
Nous commençons chaque projet par l’interface post-achat, car celle-ci répond aux conditions préalables mentionnées ci-dessus sans la complexité supplémentaire liée à la négociation des prix en temps réel. Sur Adobe Commerce, cela implique l’utilisation de l’API GraphQL Storefront pour les opérations de lecture, de l’API REST pour les opérations d’écriture des commandes, et d’Alumio comme connecteur vers l’ERP qui gère les stocks et les prix. Sur Shopify, cela implique l’utilisation de l’API Admin et de l’API Order Editing, Shopify Flow prenant en charge une partie de la logique de contrôle relative aux étapes de confirmation.
Pour la couche d’appel d’outils propre à l’agent, nous nous appuyons sur le Model Context Protocol, qui normalise la manière dont l’agent interroge ces API, évitant ainsi de devoir mettre en place une intégration personnalisée pour chaque outil. Nous suivons également de près l’Agentic Commerce Protocol ainsi que les initiatives au niveau des plateformes telles qu’OpenAI Instant Checkout, qui laissent toutes deux entrevoir un avenir où les agents développés en dehors de votre boutique en ligne pourraient devoir s’y connecter directement. Un projet pilote reposant dès aujourd’hui sur des protocoles standard est bien plus facile à étendre à cet écosystème qu’un projet basé sur une logique personnalisée et ponctuelle.
Un projet pilote type d'agents IA pour le commerce électronique, portant sur le suivi des commandes, les réapprovisionnements et le lancement des retours sur une seule plateforme et via une seule connexion ERP, dure entre huit et douze semaines. La majeure partie de ce temps est consacrée à l'intégration et à la logique de contrôle, et non à la couche conversationnelle de l'agent.
Nous préférons le dire clairement plutôt que de vendre un projet qui ne tiendra pas ses promesses. Un agent commercial n'est pas un bon investissement cette année si l'une de ces trois conditions est remplie.
Les tarifs sont encore négociés commande par commande par un commercial, plutôt que d'être extraits d'un niveau tarifaire défini dans votre ERP. S'il n'existe pas d'API permettant d'obtenir le montant exact, l'agent fera une estimation, et il le fera avec assurance.
La précision des stocks est inférieure à environ 95 %. Un agent qui confirme les stocks en se basant sur des données peu fiables vendra plus que ce dont il dispose, et ce quel que soit le volume sur lequel il opère, et non pas au rythme des erreurs humaines ponctuelles auxquelles vous avez l'habitude de faire face.
Les modifications de commande nécessitent toujours qu'une personne saisisse manuellement les changements directement dans le progiciel de gestion intégré (ERP). S'il n'existe pas de point de terminaison API que l'agent puisse appeler, il n'y a pas d'intégration à mettre en place, et un chatbot qui transfère la demande à un humain est véritablement l'outil le plus fiable pour l'instant.
Si l'une de ces situations correspond à votre activité, ce n'est pas une raison pour abandonner le projet. C'est plutôt une raison de commencer par corriger les données et les processus sous-jacents, car un agent commercial s'appuyant sur des données de prix ou de stock peu fiables échouera plus rapidement et de manière plus flagrante que le processus manuel qu'il est censé remplacer.
Si vous évaluez des agents IA destinés au commerce en ligne pour votre propre entreprise, la première discussion ne devrait pas porter sur l’agent lui-même. Elle devrait plutôt porter sur l’API de vos produits, votre structure tarifaire et la manière dont votre ERP synchronise actuellement les stocks et les commandes avec votre boutique en ligne.
Les éléments dont nous avons besoin avant de pouvoir définir le périmètre d’un projet sont simples : la plateforme que vous utilisez (Adobe Commerce, Magento Open Source, Shopify ou BigCommerce), l’ERP qui gère vos tarifs et vos stocks (Epicor Prophet 21, NetSuite OneWorld, Microsoft Dynamics 365 Business Central ou SAP Business One), et si cet ERP dispose déjà d’une API pour les tarifs et les stocks ou si cela fait partie du développement.
À partir de là, nous pourrons vous dire en toute franchise lesquelles des sept conditions préalables sont déjà remplies et celles que le pilote doit remplir en priorité.
Le coût dépend presque entièrement du degré d'intégration préalable déjà en place. Un commerçant disposant d'une API ERP moderne et d'une synchronisation des stocks en temps réel dépensera bien moins qu'un autre qui doit mettre en place cette connectivité à partir de zéro. La définition du périmètre commence par un audit des éléments déjà en place.
Un projet pilote ciblé portant sur les actions post-achat, le suivi des commandes, les réapprovisionnements et le lancement des retours dure généralement entre huit et douze semaines sur une seule plateforme et avec une seule connexion ERP. Les projets de plus grande envergure, comme l'établissement de devis avant l'achat, prennent plus de temps car ils nécessitent une logique de négociation des prix en temps réel.
L'agent agira en toute confiance sur la base de données erronées. Il confirmera un stock inexistant, proposera un prix ne correspondant pas au tarif contractuel du client ou approuvera un retour non conforme à la politique de l'entreprise, le tout à la vitesse et au volume propres aux appels automatisés, et non au rythme des erreurs manuelles.
Oui, dans certains cas précis. Si vos tarifs font encore l'objet d'une négociation manuelle ou si la précision de votre inventaire n'est pas encore au rendez-vous, un chatbot capable de répondre aux questions et de rediriger vers un interlocuteur humain constitue pour l'instant la solution la plus fiable.
Les agents IA destinés au commerce électronique sont conçus pour les fabricants, les distributeurs et les grossistes utilisant Adobe Commerce, Magento Open Source, Shopify ou BigCommerce, en association avec un progiciel de gestion d'entreprise (ERP) tel qu'Epicor Prophet 21, NetSuite OneWorld, Microsoft Dynamics 365 Business Central ou SAP Business One, où la tarification personnalisée et les stocks en temps réel confèrent tout son intérêt à cette intégration.
