Guide technique · Agents IA et e-commerce
Brancher un agent IA sur les flux marketplace d’une PME.
Une commande Amazon arrive avec un SKU inconnu. Le connecteur sait transporter le message, pas décider quelle référence ERP lui correspond. Un agent IA peut préparer ce rapprochement et expliquer le rejet. Les écritures de stock, de prix et de remboursement restent soumises à des règles vérifiables.
Demander un diagnostic
Ce que ce guide établit
- 01
Conserver les événements bruts
Chaque notification reçue garde son identifiant, son horodatage et sa charge utile avant toute transformation.
- 02
Séparer règles et interprétation
Le stock et les montants suivent des règles déterministes. L’agent travaille sur le texte libre et les correspondances ambiguës.
- 03
Rendre les rejets exploitables
Le code technique, la donnée fautive et l’action attendue arrivent dans une file attribuée à une personne.
- 04
Réconcilier chaque journée
Les commandes reçues, créées, expédiées et remboursées sont comparées entre le canal et l’ERP.
Le cas qui révèle les limites d’un simple connecteur
À 8 h 04, une marketplace transmet une commande pour le SKU vendeur TSHIRT-NOIR-L. L’ERP connaît NOIR-L-2025, tandis que la boutique conserve encore une ancienne référence. Le connecteur peut recevoir la commande et appeler l’API de l’ERP. Il ne possède aucun élément fiable pour choisir entre les deux fiches produit.
Créer la commande malgré l’ambiguïté réserve le mauvais stock. Rejeter la ligne sans explication oblige l’équipe à comparer plusieurs écrans. Le traitement correct met la commande en attente, rassemble les deux références candidates et montre les attributs qui les rapprochent : EAN, taille, couleur, conditionnement et historique de correspondance.
L’agent IA intervient à cet endroit. Il lit les libellés et propose une correspondance argumentée. Une personne confirme la première association. La table de correspondance devient ensuite une règle réutilisable. L’agent n’a plus à deviner lors de la commande suivante.
Une architecture qui distingue transport, état métier et agent IA
Le flux reçoit d’abord l’événement original dans une boîte d’entrée durable. Il enregistre l’identifiant de la marketplace, l’identifiant de commande, chaque ligne et l’heure de réception. Cette copie sert à rejouer le traitement sans redemander une donnée qui a pu changer entre-temps.
Une machine à états décrit ensuite le parcours réel : reçu, contrôlé, bloqué pour correspondance, créé dans l’ERP, confirmé au canal, expédié, puis rapproché. Le passage d’un état au suivant exige une condition observable. Une réponse HTTP 200 indique que l’API a reçu la requête. Elle ne prouve pas que toutes les lignes ont été acceptées ni que l’ERP a enregistré le résultat attendu.
L’agent IA est un composant de cette architecture. L’orchestrateur lui fournit un dossier borné, avec la commande, les références candidates et la consigne. Sa réponse revient sous une structure contrôlée : proposition, niveau de confiance, éléments utilisés et motif d’incertitude. Une règle décide ensuite si le traitement continue ou rejoint la file humaine.
Entrée durable
Événement original, identifiants du canal et horodatage conservés avant le premier appel métier.
Orchestrateur
États, délais, tentatives et conditions d’arrêt appliqués sans demander au modèle de piloter seul le flux.
Agent IA
Lecture des libellés, pièces et motifs de rejet, avec une sortie structurée et une confiance exploitable.
File d’exception
Commande bloquée, cause technique, documents utiles et action attendue réunis dans l’outil de l’équipe.
Les tâches qui justifient réellement un agent IA
Un agent apporte quelque chose lorsque l’entrée résiste aux règles exactes. Il peut rapprocher un libellé fournisseur d’une fiche produit, extraire une référence depuis une pièce jointe, classer le commentaire libre d’un retour ou reformuler un rapport de rejet pour l’équipe catalogue. Chaque résultat reste lié au texte ou au document qui l’a produit.
Les écritures financières et les quantités exigent une autre mécanique. Le stock vendable découle du stock physique, des réservations, des unités bloquées et du seuil de sécurité défini par l’entreprise. Le prix suit une grille. Le remboursement suit un statut de retour et une autorisation. Ces calculs appartiennent au code et aux règles métier, avec un point de décision lorsque le contrat l’exige.
Cette séparation facilite aussi les changements de modèle. Le prompt et le fournisseur peuvent évoluer sans toucher à la clé d’idempotence, au calcul de stock ou aux règles comptables. L’équipe sait alors quelle régression chercher : qualité d’interprétation d’un côté, intégrité des écritures de l’autre.
Bon usage
Proposer deux références candidates et citer les attributs communs qui soutiennent la proposition.
Bon usage
Transformer un rapport de rejet technique en consigne lisible sans supprimer le code d’erreur original.
Mauvais usage
Inventer une disponibilité, corriger un prix ou approuver un remboursement depuis une consigne en langage naturel.
Idempotence, reprises et rapprochement quotidien
Une notification peut arriver deux fois. Une API peut répondre trop tard alors que l’écriture a réussi. La clé d’idempotence combine l’identifiant du canal, celui de la commande et celui de la ligne. Avant toute création, le flux vérifie si l’opération possède déjà un résultat métier. Relancer une étape retrouve alors la commande existante au lieu d’en créer une seconde.
Les notifications accélèrent le traitement sans garantir son exhaustivité. Une tâche planifiée relit les commandes et compare les états entre la marketplace et l’ERP. Elle retrouve une expédition confirmée d’un côté seulement, un numéro de suivi absent ou un remboursement sans rapprochement financier. L’écart devient une tâche, avec un propriétaire et une date de reprise.
Le journal technique conserve les appels, les codes de retour et les tentatives. L’équipe opérationnelle reçoit une vue plus courte : commande concernée, dernière étape réussie, donnée à corriger et action de reprise. Les deux vues partagent le même identifiant de corrélation. Le support peut donc passer du dossier métier à la trace API sans recherche manuelle.
Limiter les données confiées au modèle
Le modèle n’a pas besoin de l’adresse complète du client pour rapprocher deux SKU. L’orchestrateur prépare un contexte réduit à la tâche : libellé, attributs produit, identifiants techniques et extrait du rejet. Les données personnelles restent dans les systèmes qui les utilisent pour la livraison et la facturation.
Les secrets d’API sont stockés dans un coffre et associés à des droits limités. L’agent ne reçoit jamais les clés dans sa consigne. Les appels sortants sont journalisés, les données de test sont séparées de la production et la durée de conservation des événements est définie. Les recommandations de la CNIL sur les API donnent un cadre utile pour les accès, les environnements et les traces.
Une validation doit porter sur l’action précise. Confirmer une correspondance produit n’autorise pas l’agent à modifier le prix ou à publier une nouvelle offre. Le jeton technique, le schéma de sortie et l’orchestrateur appliquent cette limite même si le texte généré demande autre chose.
Tester le flux sur un canal et des exceptions connues
Le premier pilote couvre un canal, une famille de produits et vingt commandes terminées. L’échantillon inclut une référence inconnue, une rupture, une annulation, une expédition partielle et un retour. Chaque dossier est rejoué avec les données disponibles au moment où l’événement est arrivé.
Le contrôle vérifie les doublons, le délai de création dans l’ERP, la qualité des correspondances proposées, les rejets sans propriétaire et les écarts trouvés par la réconciliation. Les propositions de l’agent sont relues contre les fiches produit. Une réponse plausible avec un mauvais EAN reste une erreur.
Le pilote livre une table de correspondance propre, une liste d’états, les règles d’arrêt et une file d’exception utilisable. L’intégration passe ensuite en production sur un périmètre limité. Les autres canaux rejoignent le flux après vérification de leurs API, de leurs statuts et de leurs contraintes contractuelles.
Questions fréquentes.
Les points à trancher avant de lancer un pilote.
Pourquoi ajouter un agent IA si un connecteur existe déjà ?
Le connecteur transporte les données prévues par son schéma. L’agent intervient sur les libellés, documents et motifs de rejet qui demandent une interprétation. Les deux composants répondent à des problèmes différents.
L’agent peut-il modifier directement le stock ?
Le stock vendable suit une formule et une source métier identifiées. L’agent peut signaler une incohérence ou préparer une explication. L’orchestrateur et les droits d’API empêchent une modification hors des règles validées.
Comment éviter les commandes créées deux fois ?
Le flux conserve les identifiants du canal et vérifie l’état métier avant chaque écriture. Une relance reprend l’opération existante au lieu de créer une nouvelle commande.
Apportez cinq commandes propres et cinq commandes bloquées
Nous suivrons les identifiants, les écritures ERP et les reprises manuelles. Le diagnostic séparera ce qui relève du connecteur, des règles métier et d’un agent IA.
Demander un diagnosticUn exemple réel vaut mieux qu’une liste d’outils.
Apportez un dossier, un e-mail ou un passage entre deux logiciels. Nous le transformons en périmètre testable, exceptions comprises.
Premier échange non facturé. Le devis précède toute connexion à vos systèmes.