Aller au contenu principal

ADR-0200 : Navin Enterprise Agent Commercial et Vente Omnicanale, couche produit retail au-dessus du Control Plane

  • Statut : proposed
  • Date : 2026-11-04
  • Cas d'usage : UC-11 (agent_uses_cases/11_Retail_Commercial_Vente_Omnicanale.md), secteur retail
  • Liens : ADR-0175 (produit RAG), ADR-0180 (shell partagé), ADR-0184 (Customer Operations Agent), ADR-0191 (modèle Supply Chain dont les modules génériques sont copiés), paquet OPA eai.retail_commercial (deploy/policies/opa/retail_commercial.rego), contrats contracts/v1/retail-commercial-omnicanal-action-request.schema.json et contracts/v1/retail-commercial-omnicanal-copilot-event.schema.json, gabarit navin-retail-commercial-omnicanal-agent (published: false).

Contexte​

Un marchand veut conseiller ses clients sur ses canaux autorisés (site, application, chat, messageries), rechercher dans son catalogue publié, comparer des produits, consulter prix, promotions et disponibilité, préparer un panier, obtenir la confirmation explicite du client puis lui remettre le checkout hébergé, transférer la conversation à un conseiller, suivre une commande et préparer un retour, sans jamais promettre un prix, un stock, un délai ou une promotion que la source n'a pas confirmé, sans laisser un modèle de langage conclure une vente ou un remboursement, et sans profiler les clients. Le PIM, le moteur prix, l'ATP, l'OMS, le POS et le CRM restent les seules sources de vérité.

Le tableau de bord demande de réutiliser le Customer Operations Agent (pack Retail) pour les conversations et les dossiers ; ce produit n'existe que sous forme de décision (ADR-0184) et d'audit, sans code.

Décision​

  1. Produit séparé, modules génériques copiés. Backend FastAPI navin_omnicanal (port 8483, Redis 6404, web 3484 servi par le shell partagé ADR-0180), schéma PostgreSQL omnicanal avec RLS tenant puis projet sur chaque table, outbox, audit en ajout seul, clés d'idempotence. Les modules génériques du modèle UC-09 sont copiés et adaptés, jamais importés.
  2. Conversations et dossiers derrière un port. Un port ConversationPort (retail/conversations.py) taillé sur l'ADR-0184 (session de canal, événements dédoublonnés, contexte client vérifié, transfert, dossier de service) avec une implémentation locale minimale dans le schéma omnicanal. Aucun second produit Customer Operations n'est construit ; quand CO sera livré, l'implémentation locale sera remplacée par un adaptateur CO sans changer l'API.
  3. Sources lues avec leur fraîcheur. Catalogue, prix, disponibilité, promotions, clients et commandes sont lus via des connecteurs déclarés (table de capacités, lecture seule par défaut, bac à sable navin-sandbox étiqueté comme tel). Chaque offre porte source, version, date d'observation et validité ; elle est relue avant panier et avant checkout. Un attribut absent reste inconnu.
  4. Recommandations explicables. Contraintes explicites puis score documenté, règles versionnées en données, attributs protégés refusés, placement sponsorisé signalé, produit indisponible jamais présenté comme achetable.
  5. Effets externes par l'Action Gateway seulement. Panier, checkout, demande de retour et note CRM passent par la passerelle (Idempotency-Key, If-Match, OPA, OpenFGA, maker-checker pour geste commercial, remboursement, annulation engageante, envoi marketing et changement de règle). Le checkout exige la confirmation explicite du client sur le hash exact des lignes ; la commande n'est order_confirmed que sur la réponse de l'OMS ; une réponse incertaine devient unknown_pending_confirmation et la source est relue avant tout nouvel essai.
  6. Contact marketing sur consentement enregistré seulement, opt-out révoquant les usages concernés.
  7. Copilote sur le contrat d'exécution du modèle : lectures sous RLS, préparations par la passerelle, aucune exécution par le LLM, SSE avec Last-Event-ID, contenu des fiches et réponses des connecteurs traité comme donnée non fiable ; suspension automatique quand un conseiller a pris la main.

Conséquences​

  • Positives : produit utilisable sans CO, frontière claire pour la migration vers CO, aucune promesse non confirmée.
  • Négatives : implémentation locale des conversations à migrer ; aucun connecteur réel (PIM, OMS, CRM, paiement) n'est livré ; Shopify, WooCommerce, PrestaShop et Magento restent déclarés non configurés.

Alternatives écartées​

  • Construire un second produit Customer Operations dans UC-11 : refusé (doublon de l'ADR-0184).
  • Importer le code du modèle UC-09 : refusé (couplage entre produits).
  • Mettre en cache les prix pour accélérer le checkout : refusé (promesse non confirmée par la source).