ADR-0203 : Navin Enterprise Agent Gestion des Achats et Fournisseurs, couche produit retail au-dessus du Control Plane
- Statut : proposé (2026-11-05)
- Décideurs : équipe plateforme Navin Enterprise AI, mission UC-14 (
agent_uses_cases/14_Retail_Achats_Fournisseurs.md) - Références : ADR-0176 (motif des modules génériques copiés), ADR-0180 (shell frontend générique piloté par manifeste),
ADR-0174 (contrat Navin Memory Provider), ADR-0191 (agent UC-09 dont les modules génériques, les scorecards fournisseurs
et les commandes sous maker-checker sont copiés puis adaptés, jamais importés), paquet OPA
eai.retail_achats(deploy/policies/opa/retail_achats.rego), fragment OpenFGAdeploy/policies/openfga/products/retail-achats-fournisseurs.fga, contratscontracts/v1/retail-achats-fournisseurs-action-request.schema.jsonetcontracts/v1/retail-achats-fournisseurs-copilot-event.schema.json, gabarit Managernavin-retail-achats-fournisseurs-agent(published: false).
Contexte
Une enseigne de distribution veut comparer les offres de ses fournisseurs sur un coût réellement comparable, suivre ses commandes et ses anomalies tarifaires, rapprocher commande, réception et facture, puis préparer ses négociations et ses décisions d'achat, sans jamais laisser un modèle de langage envoyer une consultation, attribuer un marché, promettre un volume, passer une commande, modifier les coordonnées bancaires d'un fournisseur ou payer une facture. Le cahier des charges impose huit modules (référentiel et homologation, besoins et consultations, extraction et normalisation des offres, comparaison et attribution préparée, négociation, commandes, rapprochement trois pièces, performance), une machine à états explicite côté serveur et six scénarios de recette numériques.
La plateforme fournit l'identité, OpenFGA, OPA, l'Action Gateway avec maker-checker, les travaux durables, le pipeline documentaire, le RAG, la mémoire et l'observabilité. Aucun ERP, PIM, WMS, système de factures ou portail fournisseur réel n'est raccordé dans le dépôt : les connecteurs sont exercés en bac à sable déterministe déclaré comme tel.
Décision
1. Coût rendu comparable, par devise
Le moteur de coût rendu (Decimal, règle d'arrondi versionnée) calcule pour une quantité demandée le coût de chaque offre
à partir du prix unitaire ou par colis, du conditionnement, du MOQ, du fret, des droits, des conditions de paiement et du
délai. Un prix par carton n'est comparé à un prix unitaire qu'après conversion de conditionnement validée ; une composante
inconnue (fret absent) rend le coût incomplete, jamais nul. Une remise conditionnelle non acquise reste un scénario
séparé du coût certain. Les offres de devises différentes ne sont classées ensemble qu'avec un taux approuvé dont la date
et la source sont affichées ; sinon elles sont présentées par devise sans classement commun.
2. Rapprochement trois pièces et anomalies tarifaires
Le rapprochement commande, réception acceptée et facture s'effectue par ligne, avec des tolérances par type d'écart versionnées comme données. Tout écart (quantité, prix hors contrat, frais non prévus, doublon) produit une exception pour revue humaine ; aucun paiement n'est déclenché. Une facture importée deux fois (même référence et même empreinte) est dédoublonnée et ne crée ni deux dettes ni deux litiges.
3. Le modèle prépare, l'humain décide, la source confirme
Consultations, attributions, engagements de volume, commandes, avenants, litiges et changements sensibles du référentiel
fournisseur sont des plans du Gateway approuvés par un humain autre que leur préparateur, dans les limites de délégation
d'OPA, avec Idempotency-Key et If-Match. Le lien de commande vaut unknown_pending_confirmation jusqu'à la confirmation de
l'ERP ou du portail ; une réponse incertaine conduit à relire la source avant toute nouvelle tentative. Un email de
changement bancaire ouvre une revue indépendante et ne modifie jamais le fournisseur. La préparation de négociation ne
montre que des faits sourcés et n'invente aucun engagement.
4. Modules génériques copiés, modules métier écrits
Les modules génériques du modèle UC-09 sont copiés dans navin_achats (schéma achats, préfixe
/api/v1/retail-achats-fournisseurs, ports 3487, 8486 et 6407). Les tables du §18.1 (supplier_projections,
purchase_requisitions, rfq_records, supplier_offer_lines, award_decisions, purchase_order_links,
invoice_match_results, supplier_disputes) et leurs compléments sont créées avec RLS locataire puis projet. Un
fournisseur ne voit que sa consultation et ses offres (relation supplier dans OpenFGA).
Conséquences
- Positives : aucun effet externe sans plan approuvé et confirmation de source ; coûts reproductibles et expliqués ; aucune somme entre devises ; isolation testée ; le shell générique affiche le produit grâce au manifeste.
- Négatives : les ERP, PIM, WMS et portails réels ne sont pas raccordés ; les scénarios de recette s'exécutent sur le bac à sable et ne valent pas intégration de production.
- Le gabarit
navin-retail-achats-fournisseurs-agentrestepublished: falsejusqu'à validation explicite.