ADR-0202 : Navin Enterprise Agent Optimisation des Prix et Promotions, couche produit retail au-dessus du Control Plane

• Statut : proposé (2026-11-05)
• Décideurs : équipe plateforme Navin Enterprise AI, mission UC-13 (agent_uses_cases/13_Retail_Optimisation_Prix_Promotions.md)
• Références : ADR-0176 (motif des modules génériques), ADR-0180 (shell frontend partagé), ADR-0174 (fournisseur de mémoire), ADR-0191 (produit modèle supply chain), paquet OPA eai.retail_prix (deploy/policies/opa/retail_prix.rego), fragment OpenFGA deploy/policies/openfga/products/retail-prix-promotions.fga, gabarit Manager navin-retail-prix-promotions-agent (published: false).

Contexte

Une enseigne veut consolider prix, coûts, ventes, stocks et observations concurrentielles autorisées pour préparer des prix et promotions explicables, conformes à des règles validées et publiables après approbation. Le cahier des charges impose huit modules (§7 : price-foundations, competitive-observations, pricing-analytics, promotion-designs, pricing-scenarios, price-reviews, price-publications, promotion-evaluations), une machine à états côté serveur (data_ready à evaluated) et six scénarios de recette numériques (marge 20 et taux de marque 22,222 % après remise de 10 %, plancher 15 bloquant un scénario à 10, promotion non cumulable avec coupon, conditionnement différent, publication partielle sur trois canaux, coût modifié après approbation).

La plateforme fournit l'identité, OpenFGA, OPA, les approbations, les travaux durables, le pipeline documentaire, le RAG, la mémoire et l'observabilité. Aucun PIM, ERP, POS, moteur de prix ni source concurrentielle réelle n'est raccordé dans le dépôt : les connecteurs sont exercés sur un bac à sable déterministe déclaré sandbox.

Décision

1. Produit autonome navin-enterprise-retail-prix-promotions/, paquet Python navin_prix, schéma PostgreSQL prix avec RLS sur chaque table tenant, outbox et audit immuable ; API /api/v1/retail-prix-promotions sur le port 8485, Redis 6406, interface 3486 servie par le shell partagé (aucun code frontend propre).
2. Le moteur calcule, le LLM explique : marges, taux de marque, cumul de remises et contrôles de règles sont déterministes, en Decimal par devise, avec engine_version, ruleset_version et entrée figée. Les règles de prix (planchers, plafonds, marge minimale, terminaisons, familles, contraintes légales citées par la source) sont des données versionnées avec leur référence ; aucune réglementation n'est inventée.
3. Élasticité et uplift sont des estimations statistiques avec intervalle et fenêtre de données, jamais des certitudes ni des causalités ; cannibalisation et halo sont marqués comme estimations.
4. Aucun changement effectif de prix ou de promotion sans approbation humaine (maker-checker : le demandeur n'approuve jamais sa propre demande, ni le copilote ni un robot n'approuvent) et confirmation du système de prix ou de l'ERP/POS. La publication est une action side_effect de l'Action Gateway avec Idempotency-Key, If-Match sur la version du prix, dates d'effet et proposition de retour arrière ; une réponse incertaine devient unknown_pending_confirmation et la source est relue avant toute nouvelle tentative.
5. Prix concurrents : seulement des sources autorisées, avec provenance et date d'observation ; aucune collecte hors de ces sources, aucune coordination avec des concurrents.
6. Gabarit Manager préparé et non publié ; publication après validation explicite.

Conséquences

• Un canal qui échoue laisse la campagne published_partial avec réconciliation ciblée.
• Un coût modifié après approbation invalide l'approbation selon la règle configurée.
• Les connecteurs réels restent à raccorder ; le bac à sable ne vaut pas intégration validée.