IA agentique dans le retail : quand les agents passent à l'action

Le commerce a progressivement organisé son fonctionnement autour du magasin, de l'omnicanal puis de plateformes mutualisant les applications, les données et les services. La transformation agentique prolonge cette évolution : les capacités métier deviennent utilisables par des agents capables de coordonner plusieurs opérations pour atteindre un objectif.

Ce changement dépasse l'automatisation des collaborateurs. Un client pourrait prochainement confier sa recherche, sa comparaison de produits et la préparation d'un achat à son propre agent personnel. Dans ce scénario, il ne commence plus nécessairement son parcours sur le site de l'enseigne : il dialogue avec un intermédiaire qui peut comparer plusieurs fournisseurs avant de solliciter leurs services.

La stratégie étudiée identifie un risque économique précis : être réduit à un fournisseur de produits, de stocks et de logistique, tandis qu'un agent externe contrôle la recommandation et la relation avec le consommateur. La réponse envisagée est double : proposer des expériences agentiques directement aux clients et exposer des capacités métier que les agents externes puissent utiliser.

L'entreprise ne cherche pas pour autant à tout développer elle-même. Elle entend conserver les éléments qui fondent sa valeur : les règles métier, la connaissance des clients, les contrats d'accès aux services et les informations permettant de comprendre les résultats des interactions. La maîtrise de ces éléments devient aussi importante que celle de l'interface commerciale.

La stratégie distingue le chatbot, qui répond à une demande, du système agentique, qui poursuit un objectif à travers une succession d'actions. Le cadre d'exécution décrit sept étapes : définir l'intention, sélectionner le contexte autorisé, agir, récupérer le résultat, le vérifier, corriger l'exécution si nécessaire et conserver les informations utiles en mémoire.

Chaque boucle doit être rattachée à un responsable métier, à des permissions explicites et à un mécanisme d'escalade. Elle doit également disposer d'une référence permettant de vérifier le résultat, d'une compréhension de son coût complet et d'une trace des décisions prises. Le modèle peut participer à l'exécution, mais la responsabilité, les arbitrages et les validations sensibles restent humains.

Cette organisation soulève une difficulté que la stratégie identifie directement : les entreprises peuvent construire des agents plus rapidement qu'elles ne parviennent à formaliser leurs processus. Les règles tacites, les exceptions locales et les arbitrages informels deviennent problématiques lorsqu'un système doit décider d'agir plutôt que demander conseil.

La transformation nécessite donc de rendre explicites trois éléments : ce qui fait autorité, ce qui est permis et qui est responsable. Sans cette clarification, un agent risque soit de prendre une décision inadaptée, soit d'escalader systématiquement vers un humain et de neutraliser la valeur de l'automatisation.

La stratégie étudiée organise sa transformation autour de fondations communes : gestion de la connaissance, environnement d'exécution des agents, accès aux modèles et sécurité. Elle prévoit parallèlement des travaux sur l'architecture, l'organisation et les compétences. Les choix techniques doivent ainsi évoluer avec les processus et les responsabilités, plutôt qu'être traités comme des projets indépendants.

Le cadre envisagé associe plusieurs fonctions complémentaires : un point d'entrée pour les demandes et le suivi des projets, un environnement commun de contexte, une bibliothèque de compétences agentiques réutilisables, un accès aux outils via MCP et une passerelle permettant de mobiliser plusieurs modèles. Les prototypes déjà développés par les équipes doivent pouvoir être intégrés à cet environnement au lieu d'être systématiquement remplacés.

La mutualisation permet de réutiliser des compétences et d'éviter la multiplication des connexions spécifiques. Elle impose aussi de décider quels outils sont publiés, quels agents peuvent les appeler, quelles données leur sont exposées et quelles opérations sont effectivement permises. Un catalogue centralisé d'outils ne constitue pas, à lui seul, un mécanisme d'autorisation.

La stratégie différencie également les modèles d'IA, qui peuvent provenir de fournisseurs multiples, des connaissances et des règles qui doivent rester sous maîtrise de l'entreprise. Le modèle devient un composant remplaçable, tandis que le contexte métier et les mécanismes de décision constituent des actifs durables.

Les principes suivants constituent une analyse et des recommandations Ariovis. Ils ne décrivent pas une infrastructure dont le déploiement serait établi dans le groupe étudié.

La première exigence consiste à identifier l'agent, son propriétaire et le mandat sous lequel il agit. Lorsqu'un agent intervient pour un utilisateur, il faut établir la relation entre l'utilisateur, l'agent, la tâche et la durée de la délégation. Les secrets et les capacités techniques nécessaires doivent être limités à ce qui est réellement justifié par cette mission.

La seconde exigence consiste à décider de la légitimité des actions au moment où elles sont demandées. Un jeton OAuth valide peut permettre d'accéder à une API sans décrire suffisamment finement les opérations métier autorisées. Une architecture d'autorisation fine peut faire évaluer chaque demande par un moteur de politiques, à partir de l'identité, de l'action, de la ressource et du contexte, puis faire appliquer la décision par un composant placé sur le chemin de l'exécution.

Ce contrôle doit rester indépendant de la volonté du modèle. Un agent ne doit pas pouvoir contourner un refus en choisissant une autre interface donnant accès à la même opération. Les politiques doivent aussi tenir compte des relations métier, des paramètres, des destinations, des volumes, des durées et des validations nécessaires.

Le contrôle des actions doit s'articuler avec une protection plus large de l'environnement agentique. Les documents récupérés, les instructions injectées, les outils, les serveurs MCP, les mémoires et les workloads peuvent influencer le comportement de l'agent ou exposer des capacités qui dépassent sa mission.

Les dispositifs de sécurité doivent permettre de découvrir les agents et leurs dépendances, d'inspecter les interactions, de limiter les actions dangereuses, d'observer l'exécution et de réagir à une dérive. La surveillance de la séquence complète, depuis l'intention jusqu'à l'effet produit, facilite autant le traitement des incidents que la production de preuves.

Cette articulation mobilise plusieurs expertises distinctes : l'IAM pour les identités et les mandats, le PAM pour les privilèges et les secrets, l'autorisation fine pour les décisions métier et la protection des agents pour les risques liés aux outils, aux données et au runtime. Aucune de ces composantes ne doit être présentée comme une solution universelle à l'ensemble des risques.