Votre IA de commerce a oublié ce qu'elle a fait il y a 5 secondes. Une nouvelle architecture peut y remédier.

TL;DR : Votre agent est amnésique

• La plupart des agents IA sont aujourd'hui sans état (stateless). Ils n'ont pas de mémoire fiable des actions passées, ce qui les rend inaptes aux opérations commerciales critiques comme la gestion des stocks ou les parcours clients en plusieurs étapes. Ce n'est pas un bug ; c'est un défaut fondamental dans leur conception qui conduit à des échecs imprévisibles et inauditables.
• Un nouvel article d'arXiv cette semaine, "ESAA : Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1), propose une solution en adaptant un modèle d'entreprise éprouvé — l'event sourcing (approvisionnement par événements) — pour les systèmes agentiques [5]. Il sépare les intentions d'un agent (ce qu'il veut faire) de ses effets (ce qui se passe réellement).
• Ce changement architectural permet de créer des flux de travail agentiques auditables, rejouables et résilients. Il permet aux marques d'utiliser des LLM hétérogènes (comme GPT-5 et Claude Sonnet 4.6), d'éviter le vendor lock-in (dépendance vis-à-vis d'un fournisseur) et de construire des agents à long terme qui peuvent enfin être dignes de confiance pour des tâches critiques sans halluciner leur propre état [6].

Voici un scénario de plus en plus plausible. Le CTO d'une marque DTC (Direct-to-Consumer) à croissance rapide — appelons-la "Melrose Active" — était en pleine panique. Leur nouvel agent autonome de gestion des stocks, un système qu'on leur avait vendu comme le summum du "commerce agentique" (agentic commerce), venait d'essayer de commander 50 000 unités d'une référence à faible rotation (slow-moving SKU). Le déclencheur ? Un pépin réseau lors d'un contrôle de stock de routine. L'agent, ayant perdu son contexte en cours d'opération, a relancé sa logique initiale, a mal interprété les données partielles de la première tentative échouée et a conclu que l'entrepôt était vide. Ce fut une erreur d'un million de dollars, détectée uniquement par une alerte humaine (human-in-the-loop) qui, franchement, a annulé tout l'intérêt du système autonome.

Ce scénario est illustratif, mais il n'a rien d'invraisemblable. C'est la conséquence directe du sale petit secret du boom de l'IA agentique : la plupart de ces systèmes sont construits sur du sable. Ce sont des amnésiques sans état (stateless) opérant dans un présent perpétuel. Ils ne peuvent pas se souvenir de manière fiable de ce qu'ils ont fait il y a une minute, et encore moins hier. Pour les chatbots simples de questions-réponses, c'est une gêne. Pour les processus complexes, avec état (stateful) et de longue durée qui définissent le commerce réel — inventaire, logistique, personnalisation, service client — c'est une responsabilité catastrophique.

Pendant que le reste du monde est hypnotisé par des démos d'agents IA réservant des vols ou "recherchant l'ambiance" d'itinéraires de voyage [1], nous, dans les tranchées de la construction de systèmes de commerce réels, menons une bataille beaucoup plus fondamentale : la bataille pour l'état. Et un article discrètement publié sur arXiv cette semaine pourrait être l'un des développements les plus importants à ce jour dans cette lutte.

Trois agents IA entrent dans un bar... et le réduisent en cendres ?

Le problème avec l'agent de Melrose Active n'était pas seulement un point de défaillance unique. C'était le symptôme d'un problème systémique beaucoup plus profond avec les systèmes multi-agents. Lorsque vous déployez plusieurs agents autonomes qui partagent des ressources — comme des bases de données d'inventaire, des moteurs de tarification ou des passerelles API — ils ne tombent pas seulement en panne individuellement. Ils échouent souvent de manière synchronisée et corrélée, ce qui amplifie les dégâts.

Un fascinant article d'arXiv publié cette semaine même, "Three AI-agents walk into a bar … ‘Lord of the Flies’ tribalism", illustre parfaitement ce scénario cauchemardesque [2]. Des chercheurs ont placé des agents LLM autonomes dans un scénario classique de contention de ressources (le problème du bar El Farol) et ont observé ce qui s'est passé. Au lieu d'agir comme des acteurs indépendants et rationnels, les agents ont rapidement formé des "tribus" basées sur leurs schémas de raisonnement sous-jacents. Certains sont devenus "agressifs" (27,3 % de la population), essayant toujours d'accéder à la ressource. D'autres étaient "conservateurs" (24,7 %), et une grande pluralité est devenue "opportuniste" (48,1 %).

Le résultat terrifiant ? Ce tribalisme émergent a conduit à un comportement synchronisé, provoquant des surcharges et des défaillances systémiques bien pires qu'une simple distribution aléatoire n'aurait pu produire. Lorsqu'un agent décide d'inonder votre API d'inventaire, il est probable que des dizaines d'autres, construits sur le même modèle et la même logique fondamentaux, s'apprêtent à faire la même chose. C'est le danger de déployer des systèmes apparemment autonomes qui manquent d'une véritable indépendance dans leurs modes de défaillance. Sans une solide architecture, votre force de travail agentique n'est pas une équipe d'individus ; c'est une foule, sujette aux flash crashes (chutes rapides du marché) et à la stupidité collective (herd-like stupidity).

Voilà pourquoi l'obsession des capacités des agents — ce qu'ils peuvent faire — est tellement déplacée. Le véritable défi est de construire une architecture IA de commerce (commerce AI architecture) qui puisse gérer non seulement la défaillance d'un agent, mais aussi la défaillance de dizaines d'entre eux à l'unisson. Nous avons besoin de systèmes déterministes, auditables et résilients au chaos inhérent à la logique basée sur les LLM. Nous devons planifier la défaillance, pas seulement nous émerveiller du succès.

La machine amnésique : pourquoi votre agent IA actuel échoue dans le commerce

La cause profonde de cette fragilité est ce que les ingénieurs appellent la "gestion d'état" (state management). Ou, dans ce cas, une absence totale de celle-ci. La plupart des frameworks agentiques actuels, comme les boucles ReAct (Reason+Act) populaires, traitent chaque interaction comme un événement largement indépendant. La "mémoire" de l'agent n'est souvent que l'historique de la conversation fourré dans la fenêtre contextuelle d'un appel LLM. Ce n'est pas de la mémoire ; c'est un post-it, et un très petit de surcroît.

Un article publié plus tôt cette semaine sur l'évaluation de la mémoire à long terme (long-horizon memory) pour les applications agentiques a confirmé ce que beaucoup d'entre nous ont constaté en pratique : cette approche se dégrade de manière catastrophique avec le temps [7]. À mesure que la tâche devient plus complexe et que le nombre de tours augmente, la fenêtre contextuelle se remplit, des informations critiques sont perdues et l'agent commence à dériver. Il oublie ses instructions initiales, ses actions précédentes et l'état du monde qu'il est censé manipuler.

Cela a des conséquences profondes et tangibles pour toute utilisation sérieuse dans le commerce :

1. Manque d'auditabilité : Si les actions d'un agent ne sont que des appels API transitoires pilotés par un LLM probabiliste, quelle est la source de vérité ? Lorsque votre service financier demande pourquoi votre agent de tarification dynamique a baissé le prix d'un produit phare de 90 % au milieu de la nuit, votre seule réponse est "le LLM en a décidé ainsi". Il n'y a pas de journal immuable des décisions, des données qui les ont informées ou de la séquence d'événements. C'est un non-départ pour tout processus réglementé ou critique.

2. Pas d'idempotence : Dans les systèmes distribués, l'idempotence est reine. C'est la garantie que faire la même requête plusieurs fois produit le même résultat que de la faire une seule fois. Lorsque l'agent de Melrose Active a réessayé son contrôle de stock après une erreur réseau, cela aurait dû être une opération inoffensive et idempotente. Au lieu de cela, parce que son état était perdu, la nouvelle tentative est devenue une nouvelle action indépendante avec un résultat désastreux. La plupart des frameworks d'agents n'appliquent ni même ne considèrent l'idempotence, ce qui les rend fragiles face aux inévitables pannes réseau du monde réel.

3. Incapacité de rejouer et de déboguer : Lorsque le système tombe en panne, comment le déboguez-vous ? Avec un agent sans état, vous ne pouvez pas. Vous ne pouvez pas rejouer la séquence exacte d'événements et d'états qui ont conduit à la panne. Vous êtes réduit à contempler des journaux opaques du fournisseur LLM, essayant de rétrofiter une boîte noire probabiliste. C'est comme essayer de déboguer un modèle financier complexe en regardant un débat télévisé.

Ce ne sont pas des cas extrêmes. C'est le comportement par défaut de la majorité des systèmes de commerce agentiques vendus aujourd'hui. Ils sont fondamentalement peu fiables, inauditables et inaptes aux environnements de production où de l'argent réel et des stocks réels sont en jeu. Ils sont une responsabilité architecturale en attente de se produire.

L'event sourcing est-il la solution ennuyeuse et attendue pour le commerce agentique ?

Cela m'amène à l'article publié cette semaine avec le titre résolument peu sexy : "ESAA : Event Sourcing for Autonomous Agents in LLM" (arXiv:2602.23193v1) [5]. Il propose une solution qui n'est pas un prompt plus intelligent ou un modèle plus grand. C'est un modèle architectural emprunté au monde des systèmes d'entreprise à enjeux élevés et à grande échelle : l'event sourcing (approvisionnement par événements).

L'event sourcing n'est pas nouveau. C'est un modèle essentiel dans des architectures comme le CQRS (Command Query Responsibility Segregation) qui sont utilisées depuis des années dans la fintech, la banque et la logistique — partout où l'auditabilité et la fiabilité sont non négociables. L'idée centrale est simple : au lieu de stocker l'état actuel d'un système, vous stockez un journal (append-only log) de tous les événements qui se sont produits. L'état actuel est ensuite dérivé en rejouant ces événements.

L'article de l'ESAA propose d'appliquer ce modèle exact aux agents IA. Au lieu de laisser un LLM appeler directement des outils et modifier l'état du monde, le seul travail de l'agent est d'émettre un objet JSON décrivant son intention. C'est tout. Cette intention est traitée comme un événement. Un système séparé et déterministe — l'orchestrateur — est ensuite responsable de la validation de cet événement, de sa persistance dans un journal immuable, et seulement ensuite d'appliquer ses effets (comme appeler une API Shopify ou mettre à jour une base de données).

Cette séparation est la clé. La partie probabiliste, imprévisible et créative du système (le LLM) est isolée de la partie déterministe, fiable et modifiant l'état du système (l'orchestrateur).

Comment fonctionne l'ESAA : Des intentions, pas des actions

Le flux de données dans un système basé sur l'ESAA fournit les garde-fous dont les agents actuels ont désespérément besoin. Il impose un niveau de discipline qui empêche les types de défaillances que nous avons observés avec Melrose Active.

Le processus ressemble à ceci :

• agentic commerce
• commerce ai architecture
• event sourcing
• llm
• ai