Un agent repère un risque de rupture, consulte les commandes attendues et propose un réapprovisionnement. La démonstration fonctionne. Une question reste pourtant ouverte : a-t-il le droit de créer la commande, ou seulement de la préparer ?
Cette différence détermine les données à lui fournir, les contrôles à installer et la personne qui répondra d’une erreur. Une stratégie d’agents IA en entreprise commence par le périmètre d’autonomie d’un premier usage. Acheter une licence ou choisir un framework ne tranche pas cette question.
L’épisode 289 de DataGen, publié le 2 septembre 2026, fournit un point de départ concret. Matthieu Grymonprez, présenté comme Global Leader du Digital chez Adeo, et Romain Taillade, Global CTO chez Decathlon, y décrivent leur vision de cette transformation. L’entretien a été enregistré pendant leur Dev Summit commun. Nous analysons ici le podcast, dont le transcript complet a été lu, sans prétendre avoir assisté à l’événement. Épisode officiel et chapitres.
Leur discussion fait ressortir trois chantiers : réutiliser les capacités existantes de l’entreprise, expliciter les concepts métier et fournir un environnement de développement encadré. La méthode et les exemples fictifs ci-dessous sont notre proposition pour passer de ces enseignements à un pilote. Ils ne décrivent pas des déploiements réalisés chez les deux enseignes.
Un agent IA fait quoi de plus qu’un workflow ?
Un workflow suit des étapes prévues : lire un stock, appliquer une règle, préparer une alerte. Un agent peut choisir la prochaine étape et les outils à appeler selon ce qu’il observe. Il reçoit un objectif et du contexte, consulte des systèmes, puis produit une réponse ou demande une action.
Cette distinction entre chemins prédéfinis et choix pilotés par le modèle est celle du guide Building effective agents d’Anthropic, publié en décembre 2024. Elle reste utile pour décider du niveau d’autonomie ; ce guide ancien ne sert pas ici de comparatif des offres actuelles.
Pour détecter chaque matin un stock sous un seuil connu, une requête et une alerte peuvent suffire. Un agent devient un candidat quand il faut enquêter : rapprocher plusieurs causes possibles, demander une information manquante, choisir entre consulter un fournisseur ou examiner une commande. Ce choix doit être comparé à une procédure déterministe sur les mêmes dossiers.
Dans les deux cas, les règles de calcul et les droits d’accès restent des décisions explicites de l’entreprise. Une réponse convaincante ne prouve ni que le stock est frais, ni que l’action est autorisée.
Ce qu’Adeo et Decathlon apportent au débat
Les API existantes deviennent des outils à réutiliser
Romain Taillade explique que le travail de transformation en plateforme a apporté des domaines métier plus petits, exposables et standardisés. Cette préparation, initialement menée pour d’autres besoins, facilite les interactions avec de nouveaux systèmes agentiques.
La conséquence pratique pour une équipe data : avant de connecter un modèle, inventorier les capacités déjà disponibles. Existe-t-il un service de disponibilité produit ? Une API de commande ? Un catalogue de données ? Qui les maintient et quelles règles appliquent-ils ?
Dans l’entretien, le risque de fragmentation est très concret : si un agent ignore qu’une capacité existe, il peut contribuer à recréer une intégration supplémentaire. Notre lecture est qu’un catalogue d’outils doit rendre l’existant trouvable et compréhensible. Ajouter un nouvel accès direct à une base pour chaque prototype finit par multiplier les chemins à maintenir.
Le contexte métier doit devenir explicite
Matthieu Grymonprez insiste sur la sémantique des données. Une définition valable dans un pays peut ne pas l’être dans un autre ; une connaissance implicite, compensée par un collaborateur expérimenté, devient une dépendance fragile pour un agent.
Il évoque une progression par verticales métier. Pour un département data, cela peut signifier commencer par les définitions nécessaires à un usage en approvisionnement, plutôt que tenter de documenter tout le système d’information avant le premier essai.
Le mot « disponible » illustre le problème. Désigne-t-il le stock physique, le stock vendable après réservations ou une quantité attendue demain ? Un modèle sémantique partagé aide à stabiliser les règles. Il faut encore préciser la date, le pays, le canal et les cas où l’agent doit demander une clarification.
L’environnement de travail fait partie du produit
Le « harnais » évoqué dans le podcast désigne l’environnement qui entoure les capacités du modèle : outils disponibles, espace de développement, règles et contrôles. Les invités veulent permettre l’expérimentation tout en distinguant les parties du système où une erreur aurait des conséquences importantes.
La leçon ne se réduit pas à écrire un meilleur prompt. Dans notre proposition de pilote, les permissions sont appliquées par les services, les comptes et les contrôles d’exécution. Le prompt explique la règle ; il ne constitue pas à lui seul le mécanisme qui la fait respecter.
La spécification MCP des outils, version du 28 juillet 2026, décrit des outils invocables par un modèle et recommande qu’un humain puisse refuser les appels. Elle indique également de ne pas faire confiance aux annotations d’un outil provenant d’un serveur non fiable. Un connecteur ne remplace donc pas une politique d’accès réellement appliquée.
Le commerce agentique reste une hypothèse à tester
Romain Taillade s’interroge sur la place d’une marque lorsqu’un client exprime son besoin à un agent sans la nommer. Matthieu Grymonprez souligne, de son côté, le poids de l’expertise, de la confiance et de la capacité à tenir une promesse commerciale.
Ces points de vue éclairent une stratégie. Ils ne mesurent pas la part future des achats délégués à des agents. Une entreprise peut préparer ses informations produit et ses interfaces sans supposer que tous ses clients changeront de canal ni engager immédiatement une automatisation des achats.
Trois usages, trois niveaux d’autonomie
Les situations suivantes sont fictives. Elles servent à comparer des périmètres et à choisir un test.
Préparer une décision de réapprovisionnement. L’entrée réunit stock vendable, réservations, commandes ouvertes et délais. L’agent examine les cas ambigus puis prépare une proposition motivée, avec ses sources. Il ne crée pas de commande fournisseur pendant le pilote. Un approvisionneur valide la décision. Le gain recherché est une baisse du temps d’analyse, à mesurer après correction des propositions et sans dégrader leur justesse.
Préparer une modification de code data. L’entrée est un ticket, le schéma des données et les conventions du dépôt. L’agent produit une modification dans une branche isolée et propose les contrôles associés. La revue et le déploiement restent dans le circuit existant. Le critère utile est le délai jusqu’à une modification acceptée, en incluant les reprises et les régressions, pas le volume de code produit.
Répondre à une question de compatibilité produit. L’entrée combine caractéristiques et documentation validée. L’agent rapproche la demande des références disponibles et indique ce qui manque. Il n’invente pas une compatibilité lorsque la preuve est absente. Une équipe catalogue répond des règles ; un conseiller reprend les situations non couvertes. On mesure la proportion de réponses étayées et le taux de reprise, sans confondre fluidité de la réponse et exactitude.
Ces usages partagent des composants mais pas les mêmes autorisations. Une permission accordée au premier ne doit pas devenir automatiquement disponible pour les deux autres.
Tutoriel : cadrer un pilote sur la disponibilité d’un produit
L’atelier est réalisable avec un tableur et un éditeur de texte. Il ne demande ni abonnement supplémentaire, ni appel à un modèle. Il produit un périmètre testable ; il ne déploie pas les contrôles techniques.
Téléchargez les trois supports :
Prérequis : réunir une personne du métier concerné, une personne responsable des données et une personne capable de configurer les accès au système. Le même collaborateur peut cumuler des rôles, mais chaque décision doit avoir un responsable identifié.
1. Écrire le service rendu et sa limite
Remplacez « assistant supply chain » par une phrase vérifiable :
Sur le périmètre France du magasin pilote, préparer une proposition de réapprovisionnement pour les références examinées, à partir de données datées, sans créer de commande.
Inscrivez aussi ce qui termine une exécution : proposition prête, information indispensable manquante ou limite d’exécution atteinte. Une demande d’information est une sortie normale si les éléments ne permettent pas de décider.
La fiche distingue le commanditaire du service, le responsable des définitions, l’équipe qui applique les droits et la personne qui valide une action. Remplacez les rôles génériques par des responsables réels avant le pilote.
2. Rendre la définition calculable
Dans notre exemple pédagogique, le stock vendable est le stock physique diminué des réservations et du stock bloqué. Les trois quantités portent sur la même référence, le même magasin, la même unité et le même instant logique.
Avec 10 unités physiques, 3 réservées et 2 bloquées, le stock vendable attendu est 5. Ce chiffre est une donnée d’exercice, pas un résultat d’Adeo ou Decathlon. Les arrivages annoncés demain ne sont pas ajoutés au disponible immédiat.
Ajoutez à la fiche la source de chaque quantité, sa fraîcheur maximale admise et la règle en cas de valeur absente. Le seuil de fraîcheur doit être fixé par le métier selon le processus ; le support ne prétend pas imposer une durée universelle.
Si ces définitions sont déjà exposées dans un service fiable, réutilisez-le. Si elles diffèrent entre pays, conservez le pays dans la demande et bloquez la comparaison tant que les règles ne sont pas réconciliées.
3. Séparer lecture, préparation et engagement
La matrice distingue trois capacités :
- Consulter le stock et les commandes dans le périmètre accordé.
- Préparer une proposition identifiable, sans effet sur les achats.
- Créer une commande, qui reste hors du pilote initial.
Demandez à l’équipe technique comment cette séparation est appliquée. Un compte de lecture ne doit pas pouvoir écrire dans le système de commande. Une validation d’action doit porter sur les paramètres effectivement présentés, et une modification de ces paramètres doit provoquer une nouvelle validation.
Pour un futur passage à l’écriture, prévoir aussi le traitement d’une réponse réseau perdue : vérifier si la commande existe avant de la soumettre à nouveau. Le risque ne vient pas seulement d’un mauvais choix du modèle ; il peut venir d’une répétition de la même opération.
4. Jouer les cas difficiles avant la démonstration
Le fichier de recette contient huit situations : cas nominal, donnée trop ancienne, valeur absente, arrivage futur, pays non couvert, demande de commande, instruction parasite dans une note et absence de réponse d’un outil.
Pour chacune, renseignez d’abord la décision attendue, puis observez la sortie de la solution testée. Par exemple, le cas nominal produit 5 unités vendables ; une donnée périmée produit une demande de rafraîchissement ; une demande de création de commande reste refusée dans ce périmètre.
Une note fournisseur demandant d’ignorer les règles demeure une donnée externe, sans autorité pour changer les permissions. Le test doit vérifier l’effet réel : aucune écriture, y compris si le texte de réponse prétend avoir correctement refusé.
Cette recette est un support à exécuter sur votre implémentation. Sa cohérence documentaire a été vérifiée ; aucun agent ni système d’achat n’a été exécuté pour cet article. Une recette réussie sur huit exemples ne constitue pas non plus une garantie générale de fiabilité.
5. Comparer à la procédure actuelle
Prenez les mêmes dossiers pour l’approvisionneur seul, le workflow classique et le pilote agentique. Conservez les cas faciles, les cas incomplets et les cas qui imposent une reprise humaine.
Mesurez le temps total jusqu’à une proposition acceptée, les corrections nécessaires, les décisions sans preuve et les actions hors périmètre. Gardez un dénominateur commun : une abstention n’est pas une réussite automatique et un dossier abandonné ne doit pas disparaître du bilan.
Pour le coût, additionnez inférence, appels d’outils, infrastructure, revue humaine et reprises. Rapportez ce total aux dossiers acceptés. Les frais d’intégration et d’entretien restent visibles à part, puis sont répartis selon un horizon explicite si vous calculez un coût complet. Aucun tarif fournisseur n’est supposé dans les supports.
6. Décider de poursuivre, réduire ou arrêter
Fixez les critères avant de regarder les résultats. Dans le pilote proposé, toute écriture non autorisée suspend l’essai. Un gain de temps ne compense pas une action interdite. Si les reprises absorbent le gain, réduisez le périmètre ou conservez la procédure actuelle.
L’élargissement se fait sur une capacité précise : ajouter une source, un magasin ou une action, puis rejouer la recette. La fiche conserve la version des règles, les outils disponibles et la décision d’ouverture. Elle doit rester liée au fonctionnement réel, pas devenir un document validé une fois puis oublié.
Ce qui change pour l’équipe data
L’effort se déplace vers la définition du contexte exploitable et la maîtrise des actions. Les data engineers rendent les données accessibles avec leurs règles et leur fraîcheur. Les responsables métier arbitrent les définitions et les sorties acceptables. Les équipes applicatives appliquent les droits et maintiennent les outils. Les personnes qui construisent l’agent assemblent cet ensemble et vérifient ses comportements.
Cela prolonge les sujets de responsabilités autour des produits data et de contrats de données. La question supplémentaire est ici : que peut décider et déclencher le système une fois les données lues ?
L’entretien d’Adeo et Decathlon invite à préparer ce cadre pendant que les usages se développent. Pour une PME ou une ETI, la première étape peut rester modeste : un usage, des sources identifiées, un périmètre d’action limité et une recette qui accepte de conclure que l’agent n’est pas nécessaire.
Questions fréquentes
Faut-il documenter tout le SI avant de démarrer ?
Non. Le pilote peut couvrir un domaine limité. Il faut en revanche connaître les sources, les règles et les dépendances de ce domaine, ainsi que le comportement attendu lorsque l’information manque.
Un agent en lecture seule est-il sans conséquence ?
Non. Une lecture peut exposer une information ou alimenter une décision erronée. La restriction des écritures réduit une catégorie de risque ; elle ne dispense pas de limiter le périmètre consultable et de vérifier les réponses.
Faut-il choisir MCP pour mener cet atelier ?
Non. Le cadrage concerne les données, les droits et les responsabilités, quel que soit le protocole d’accès. MCP peut standardiser la description et l’appel des outils ; il ne choisit pas leur périmètre métier à votre place.
