Aller au contenu principal

ADR-0189 : Navin Enterprise Agent Contrôle Qualité Industriel, couche produit industrie au-dessus du Control Plane

  • Statut : proposé le 2026-11-04, en attente de validation de l'utilisateur (voir « Points à valider »)
  • Date : 2026-11-04
  • Portée : nouveau projet navin-enterprise-industrie-controle-qualite/ (backend FastAPI navin_qualite, workers, intégration Navin, pas de frontend propre : le socle frontend partagé de l'ADR-0180 porte l'interface), types additifs du modèle OpenFGA (deploy/policies/openfga/model.fga, type quality_instance et objets inspection_control, nonconformity, quality_disposition, capa_record, quality_document), paquet OPA eai.industrie_qualite (deploy/policies/opa/industrie_qualite.rego, clé eai.config.industrie_qualite de data.json), contrats contracts/v1/industrie-controle-qualite-action-request.schema.json et contracts/v1/industrie-controle-qualite-copilot-event.schema.json, gabarit d'agent du Navin Manager préparé mais non publié (navin-industrie-qualite-agent)
  • Documents liés : ADR-0101 (politique de licences), ADR-0103 (vLLM et LiteLLM), ADR-0108 (Opik), ADR-0166 (ClamAV et YARA-X), ADR-0173 (séparation du Manager et d'Enterprise), ADR-0174 (mémoire Mem0 et Cognee), ADR-0176 (Banking Back-Office), ADR-0180 (socle frontend des agents sectoriels), ADR-0183 (Agent Gestion des Sinistres, implémentation de référence dont les modules génériques sont copiés), décisions du 2026-11-04 (.navin/continuity/DECISIONS.md : identités des agents Industrie UC-06 à UC-10, identifiants de gabarit limités à 40 caractères), cahier des charges agent_uses_cases/07_Industrie_Controle_Qualite.md

Contexte​

Le client demande un agent de contrôle qualité industriel : plans de contrôle et échantillonnage, acquisition et métrologie, inspection visuelle assistée, tolérances et contrôle statistique, non-conformités et confinement, dispositions et dérogations, causes et actions correctives (CAPA), traçabilité des lots et vérification d'efficacité, copilote IA pour le contrôleur et le responsable qualité. Le cahier des charges impose que le LLM ne libère, ne rebute, ne bloque jamais un lot, ne déclare jamais une conformité et ne clôture jamais une non-conformité : chaque effet passe par la passerelle d'actions avec un humain dans la boucle, la séparation préparateur / approbateur et la confirmation du système source (MES, QMS, ERP ou WMS).

La plateforme fournit déjà sous gouvernance l'identité et le contexte tenant et projet, la passerelle d'outils avec décision OPA, les approbations avec séparation des tâches et clé d'idempotence, les délégations datées, l'analyse obligatoire des fichiers (quarantaine, ClamAV, YARA-X), la mémoire Mem0 et Cognee, les bases de connaissance et l'audit chaîné. UC-01 (ADR-0183) a montré comment une couche produit s'appuie sur ces briques.

Décision​

  1. Backend dérivé par copie : le paquet navin_qualite reprend sans modification (hors nom de paquet et identifiants produit) les modules génériques de navin_sinistres ; seuls les modules métier (spécifications et plans, sessions de mesure, constats visuels, contrôle statistique, non-conformités, dispositions, CAPA, traçabilité, certificats fournisseurs) et leurs machines à états sont écrits pour ce produit. Aucun frontend : product.manifest.json décrit menus, entités, colonnes, actions d'écriture et invites du copilote au socle partagé.
  2. Identité fixe : product_id industrie-controle-qualite, préfixe /api/v1/industrie-controle-qualite, ports de développement web 3480, API 8478, Redis 6400, schéma PostgreSQL qualite, rôles navin_qualite_app et navin_qualite_worker sans BYPASSRLS.
  3. Spécification figée par contrôle : chaque contrôle enregistre la version de spécification et de plan en vigueur au moment de l'échantillonnage ; une nouvelle version de spécification ne réévalue jamais un contrôle historique, la comparaison est une lecture explicite (/inspection-controls/{id}/compare-spec).
  4. Mesures : valeur brute, valeur corrigée et méthode conservées en numeric(20, 6) depuis des chaînes décimales (un flottant est refusé à la liaison), unité obligatoire, aucune somme ni comparaison entre unités, aucun arrondi avant le verdict ; limites inclusives sans garde additionnelle sauf règle de décision versionnée. Un instrument hors calibration, une tolérance absente ou une acquisition invalide donnent le verdict unknown, jamais pass.
  5. Indicateurs, jamais décisions : les cartes de contrôle et Cp/Cpk sont calculés seulement si les hypothèses (taille, sigma non nul, stabilité déclarée) sont réunies, avec engine_version, input_snapshot_id et avertissements ; sinon le résultat est insufficient_data ou not_computed avec les raisons. Un constat visuel sans échelle ne porte aucune dimension physique (contrainte dimension_requires_scale).
  6. Libération, confinement et disposition par la source : le statut bloqué d'un lot (containment_status) et l'exécution d'une disposition ne sont source_confirmed qu'après la réponse du connecteur MES, WMS ou ERP relue ; une réponse absente donne unknown_pending_confirmation et un travail de confirmation ; aucun statut « libéré » local.
  7. Maker-checker en données : OPA eai.industrie_qualite lit la matrice de délégation de la section 15 depuis data.json (opérations, rôles préparateurs et approbateurs, paliers de quantité par unité, quorum, urgence) ; OpenFGA porte can_approve ... but not maker et can_review ... but not uploader. Le paquet expose decision.applies vrai pour ses seules actions (qualite.*, document.*).
  8. CAPA : une action marquée réalisée passe à effectiveness_pending ; la clôture exige un résultat d'efficacité enregistré avec preuves et une approbation par un autre humain ; une récidive détectée par la traçabilité bloque la clôture.
  9. Documents et images : même pipeline que UC-01 (quarantaine, ClamAV et YARA-X obligatoires, Docling, revue manuelle) ; les images sont des preuves liées aux constats, jamais une mesure.
  10. Copilote : runtime copié (SSE, Last-Event-ID, gouvernance injection, DLP, budget, chiffres) ; outils de lecture sous RLS, outils de préparation via la passerelle, outils à effet de bord après approbation par un autre humain que le propriétaire du run ; contrat d'événement dérivé de assurance-sinistres-copilot-event.
  11. Connecteurs : contrats de capacités déclarés (QMS, MES, ERP/WMS, passerelle d'instruments, vision, GED), bac à sable déterministe refusé en mode production, jamais une confirmation simulée présentée comme celle de la source.

Conséquences​

  • Positives : réutilisation intégrale des briques gouvernées, isolation tenant par RLS sur toutes les tables, matrice de délégation modifiable sans redéploiement, traçabilité complète des mesures, versions et décisions.
  • Négatives : la copie des modules génériques crée une dette de synchronisation avec UC-01 (consignée dans KNOWN_LIMITATIONS.md) ; les connecteurs réels (QMS, MES, ERP, instruments, vision) restent à configurer par le client ; le gabarit n'est pas publié tant que le pipeline d'artefacts n'a pas tourné.

Points à valider​

  • Paliers de quantités et quorums par unité de eai.config.industrie_qualite (valeurs de départ, à ajuster par le client).
  • Règles de décision par caractéristique (garde d'incertitude) : par défaut limites inclusives sans garde.
  • Délai de réconciliation des confinements unknown_pending_confirmation avant alerte.

Alternatives écartées​

  • Un frontend par produit : refusé par la décision du 2026-11-04.
  • Un statut released posé localement à la décision : refusé, seule la source confirme l'exécution.
  • Un verdict de conformité issu d'un modèle visuel ou d'un LLM : refusé, le moteur est déterministe et versionné, le LLM explique.

Plan de réalisation​

Sous-plan de la tâche t-c15fbf1a (S1 audit et ADR, S2 contrats et politiques, S3 fondation, S4 et S5 modules métier, S6 machine à états, S7 documents, S8 copilote, S9 sécurité, S10 recette, S11 manifeste et gabarit, S12 docs).