ADR-0190 : Navin Enterprise Agent Planification de production, couche produit industrielle au-dessus du Control Plane

• Statut : proposé (2026-11-04)
• Décideurs : lead Navin Enterprise, session UC-08
• Références : agent_uses_cases/08_Industrie_Planification_Production.md, décisions du 2026-11-04 (.navin/continuity/DECISIONS.md : identités UC-06 à UC-10, un seul frontend, backend dérivé par copie, gabarits limités à 40 caractères), ADR-0176 (Banking Back-Office, motif des modules génériques copiés), ADR-0180 (socle frontend commun), ADR-0181 et ADR-0183 (agents assurance frères servant de référence de copie), contrat contracts/v1/agent-product-manifest.schema.json, paquet OPA eai.industrie_planification (deploy/policies/opa/industrie_planification.rego), contrats contracts/v1/industrie-planification-production-copilot-event.schema.json et contracts/v1/industrie-planification-production-action-request.schema.json, gabarit Manager navin-industrie-planification-agent (published: false).

Contexte

Un site industriel veut consolider sa demande (commandes fermes, prévisions, ordres de fabrication lancés), connaître sa capacité réelle (machines, équipes, habilitations, maintenances), vérifier la disponibilité des matières, produire des propositions d'ordonnancement à capacité finie, comparer des scénarios (commande urgente, panne, retard matière), faire approuver un plan puis le publier vers l'ERP et le MES, et suivre l'exécution pour replanifier le reste. Le cahier des charges impose huit modules (production-inputs, resource-calendars, material-feasibility, scheduling-models, schedule-runs, production-scenarios, plan-publications, production-replanning), une machine à états explicite côté serveur (input_snapshot_ready, validated, simulation_running, feasible ou infeasible, review_pending, approved, published, acknowledged, superseded) avec 409 sur toute transition interdite, des quantités et montants en Decimal portant unité ou devise, et des interdictions absolues : jamais une contrainte sécurité, habilitation ou maintenance obligatoire relâchée pour un objectif économique ; jamais un plan simplement faisable présenté comme optimal ; jamais un timeout sans solution converti en planning fictif ; jamais un OF déjà démarré écrasé ; jamais un statut published local sans accusé du système source.

La plateforme fournit déjà l'identité, OpenFGA, OPA, l'Action Gateway avec maker-checker, les travaux durables, le pipeline documentaire (ClamAV, YARA-X, Docling derrière le Control Plane), le RAG, la mémoire et l'observabilité (ADR-0176). Aucun ERP, MES, GMAO ou WMS réel n'est raccordé dans le dépôt : les connecteurs sont exercés en bac à sable déterministe et déclarent leurs capacités.

Décision

1. Le solveur propose, l'humain approuve, l'ERP/MES confirme

Une exécution d'ordonnancement (schedule_runs) est un moteur déterministe à capacité finie versionné (engine_version, ruleset_version, input_snapshot_id, as_of, parameters, time_limit, solver_status, objective, gap). Son résultat est une PROPOSITION : feasible, feasible_time_limit (solution réalisable sous limite, jamais annoncée optimale), infeasible (conflits expliqués, options de résolution proposées) ou unknown (timeout sans solution, aucun planning produit). Un validateur indépendant du solveur revérifie ressources, précédences, calendriers et matières sur la solution produite. L'approbation d'un scénario exige un humain autre que son préparateur (maker-checker dans l'Action Gateway, règle OPA, relation OpenFGA). La publication vers l'ERP/MES passe par un plan d'action à version attendue (If-Match), clé d'idempotence et confirmation du connecteur : un envoi sans accusé reste unknown_pending_confirmation puis est relu ; les accusés sont suivis par OF et les rejets partiels réconciliés sans redoubler les OF déjà confirmés.

2. Modules génériques copiés, modules métier écrits

Comme ADR-0181 et ADR-0183 : les modules génériques du backend de référence (config, errors, i18n, authz, audit, jobs, worker, controlplane, db/session, Action Gateway, connecteurs, observabilité, pipeline documentaire, copilote, ops, api/common, app) sont copiés dans navin_planification sans autre changement que le nom du paquet, du schéma (planification), du préfixe (/api/v1/industrie-planification-production) et du paquet OPA. Les huit tables métier de la section 18.1 (production_orders, routing_operations, resource_calendars, material_requirements, planning_snapshots, schedule_scenarios, schedule_operations, plan_publications) et les tables transversales de la section 18.2 sont écrites dans la migration 0001_foundation avec RLS locataire puis projet, clés étrangères composites (tenant_id, parent_id) et contraintes CHECK sur les statuts, les unités et les quantités accompagnées de leur unité.

3. Contraintes dures non relaxables et matières non consommées

Les contraintes de sécurité, d'habilitation et de maintenance obligatoire sont marquées hard et non_relaxable en données ; aucun poids d'objectif ne peut les annuler et une relaxation d'une autre contrainte dure exige un scénario explicite et une approbation. Une machine arrêtée ou un opérateur non habilité n'est jamais rendu disponible par une pénalité. La faisabilité matières (material_feasibility) réserve logiquement les quantités par scénario sans toucher au stock réel ; une réception prévue porte son statut et sa confiance et n'est jamais comptée comme stock physique ; deux OF qui consomment une matière disponible pour un seul produisent un conflit explicite, jamais une double réservation.

4. Matrice de délégation et séparation des tâches dans OPA

Le paquet eai.industrie_planification reprend le motif fail-closed des produits frères : types d'opération en données (eai.config.industrie_planification), rôles de préparation et d'approbation, second humain obligatoire pour scenario_approve, plan_publish, frozen_horizon_change, exceptional_priority, overtime_assumption, subcontracting_assumption, maintenance_move, constraint_relaxation et rule_change, safety_constraint_relax toujours refusé, délégations datées révocables, rail toujours none, applies vrai pour les seules actions planification.* et document.*. Les obligations annoncent proposal_not_decision et unknown_pending_confirmation.

5. Le réel prévaut

Le statut d'un OF est celui repris du MES/ERP (execution_status), jamais déduit d'un scénario ; les quantités déjà produites ne sont pas reprogrammées ; si une source structurante change après approbation, la publication est bloquée et le scénario revalidé. Le copilote ne reçoit que des faits sourcés et cite le snapshot et la sortie du solveur ; la mémoire ne retient ni secret ni donnée personnelle.

Conséquences

• Positives : un produit complet hors frontend (manifeste produit, backend, migrations, politiques, contrats, acceptation par l'API réelle, gabarit préparé) partageant le socle des agents frères ; une extraction ultérieure des modules génériques en bibliothèque reste mécanique.
• Négatives et limites : aucun solveur externe (OR-Tools ou autre) n'est embarqué, l'algorithme livré est une heuristique déterministe à capacité finie documentée comme telle ; ERP, MES, GMAO et WMS ne sont exercés qu'en bac à sable déterministe ; les rapports sont en csv et json seulement ; aucun frontend n'est livré par cette mission (ADR-0180) ; le gabarit n'est pas publié au catalogue.