ADR-0177 : Navin Enterprise Compliance & Audit Agent, noyau transverse et pack bancaire au-dessus du Control Plane

• Statut : proposé le 2026-11-04, options recommandées à confirmer par l'utilisateur (voir « Points à valider par l'utilisateur »)
• Date : 2026-11-04
• Portée : nouveau projet navin-enterprise-compliance/ (backend FastAPI, workers, frontend Next.js 16, intégration Navin), extensions additives du Control Plane (services/control-plane, nouveau domaine compliance modelé sur rag_agent), modèle OpenFGA (deploy/policies/openfga/model.fga, types additifs), portail Enterprise (parcours d'activation), descripteur de service et gabarit d'agent du Navin Manager préparés mais non publiés
• Documents liés : ADR-0101 (politique de licences), ADR-0103 (vLLM et LiteLLM), ADR-0108 (Opik), ADR-0166 (analyse ClamAV et YARA-X), ADR-0171 (installation durcie), ADR-0173 (séparation du Manager et d'Enterprise), ADR-0174 (mémoire Mem0 et Cognee), ADR-0175 (Navin Enterprise RAG Agent, modèle de couche produit), audit navin-enterprise-compliance/docs/NAVIN_INTEGRATION_AUDIT.md, diagramme docs/architecture/diagrams/compliance-audit-agent.html

Contexte

Deux cahiers des charges décrivent un même produit : le Navin Enterprise Compliance & Audit Agent (transverse : banque, assurance, industrie) et sa spécialisation Navin Enterprise Banking Internal Audit & Continuous Control Agent, qui doit réutiliser le modèle générique (référentiels, risques et contrôles, audits, preuves, constats, CAPA, workflow, reporting) et y ajouter les modules bancaires (univers d'audit, matrice risques et contrôles, contrôle permanent, contrôle continu, missions et papiers de travail, échantillonnage, connecteurs bancaires, reporting au comité d'audit).

L'audit du 2026-11-04 montre que :

• la plateforme fournit déjà l'identité, les rôles, la hiérarchie, OpenFGA et OPA, le runtime d'agents (exécutions, approbations, SSE), les outils gouvernés et MCP, le RAG (knowledge, V206 et V207), la mémoire (ADR-0174), l'analyse obligatoire des fichiers (file_security), le stockage objet avec verrou objet pour l'usage evidence (storage, PURPOSE_NEEDS), Presidio, SPIFFE, Docling, l'audit chaîné, les quotas et budgets, et un modèle complet de cycle de vie d'un produit (rag_agent, V208 et V209) ;
• aucun noyau transverse de conformité n'existe : ni registre de référentiels et d'obligations, ni registre de risques et de contrôles métier, ni gestion d'audits, de preuves probatoires, de constats ou de CAPA, ni moteur de rapports PDF, DOCX ou XLSX, ni connecteur GRC ou bancaire ;
• le RAG Agent (ADR-0175) a résolu les problèmes transverses d'une application produit sur le Control Plane (BFF Keycloak, autorisation, RLS, travaux durables, SSE, citations, cycle de vie, branding, observabilité) ;
• un embryon non testé d'une tentative annulée contient des moteurs déterministes (règles, échantillonnage, gravité, séparation des tâches, machines à états) et des politiques dont la conception est bonne mais le schéma trop bancaire.

Décision

1. Deux plans, une seule gouvernance

Qui	Fait quoi
Navin Manager	installe et exploite le runtime du produit (service navin-compliance-agent : API, workers, web), ses dépendances, TLS, santé, sauvegardes, mises à jour et rollback
Control Plane	tenants, projets, rôles, modèles, bases de connaissances, mémoire, analyse des fichiers, stockage et verrou objet, quotas, audit, politiques, traces, cycle de vie des instances par le domaine compliance
Backend du produit	couche métier : référentiels, obligations, risques, contrôles, campagnes, tests, échantillons, preuves, constats, CAPA, rapports, alertes, copilote ; il appelle le Control Plane uniquement par le SDK Python enterprise_ai

Le backend n'appelle jamais directement Qdrant, Cognee, LiteLLM, Docling, ClamAV ou YARA-X. Il ne possède que son schéma PostgreSQL et son espace de noms Redis.

2. Un noyau générique et des packs métier, une seule base de code

• Paquet navin_compliance : noyau transverse (référentiels, obligations, cartographie, risques, contrôles, audits, tests, échantillonnage, preuves, constats, CAPA, contrôle continu, rapports, copilote, workflows).
• Paquet navin_compliance_banking : pack bancaire (univers d'audit, matrice risques et contrôles versionnée, contrôle permanent de premier et deuxième niveau, missions et papiers de travail, connecteurs bancaires en lecture seule, catalogue de contrôles bancaires paramétrables, rôles et politiques KYC et déclaration de soupçon, rapports au comité d'audit). Les packs assurance et industrie suivent le même contrat.
• Un pack n'ajoute que des bibliothèques (référentiels, risques, contrôles, gabarits, listes de contrôle, règles de classification, rapports, indicateurs), des migrations additives dans un schéma d'extension (compliance_banking) et des politiques ; il ne modifie jamais le noyau. Les packs sont personnalisables sans changer le code.
• Ordre de réalisation : noyau d'abord, pack bancaire ensuite ; le pack reste déployable indépendamment en embarquant le noyau.

3. Moteurs déterministes indépendants du LLM

• Règles de contrôle continu (natures row_condition, field_equality, conflict_pairs, reconciliation, aging, limit_check, recency), évaluées sur des instantanés figés avec contrat de données, fraîcheur et population minimale ; source indisponible ou périmée : not_evaluated, jamais passed.
• Échantillonnage reproductible (ordre par SHA-256 de la graine et de la clé, aucune fonction aléatoire de bibliothèque), méthodes random, systematic, stratified, risk_based, exhaustive, judgmental ; aucune garantie statistique annoncée ; seule la méthode exhaustive peut affirmer que toute la population est testée.
• Gravité d'un constat depuis la matrice approuvée de l'organisation (vraisemblance x impact, version et approbateur), sinon not_rated ; jamais depuis un modèle.
• Machines à états déclaratives : audit_plan, engagement, workpaper, finding, capa, report, evidence_request, rule_activation, framework_version, rcm_version ; un état n'est jamais écrit directement, seulement par une transition déclarée avec ses rôles, ses gardes de séparation des tâches et sa justification.
• Le LLM propose (brouillons, hypothèses de cause, priorités, explications) ; il ne confirme jamais l'effectivité d'un contrôle, ne clôture pas une CAPA, ne signe pas un rapport et n'émet aucune conclusion réglementaire.

4. Maker-checker et séparation des fonctions

• Toute action sensible (approbation d'un plan, d'un papier de travail, d'un constat, d'un rapport, clôture d'une CAPA, activation d'une règle, publication d'une version de référentiel, export de preuves) exige un auteur et un valideur distincts ; gardes not_author, not_reviewer, not_submitter et délai de carence, refus nommés par OPA (self_approval_forbidden, human_decision_required, capa_not_verified, capa_owner_cannot_close, control_result_immutable, rule_not_active).
• Contrôle permanent (première et deuxième ligne) et audit interne (troisième ligne) ont des espaces, des rôles, des workflows et des droits distincts : un auditeur ne modifie jamais le résultat initial d'un contrôle, un contrôleur ne s'auto-audite pas.
• Les approbations du runtime d'agents (approvals) couvrent les exécutions IA ; les approbations métier vivent dans le schéma du produit ; les deux sont corrélées dans l'audit par trace_id.

5. Chaîne de possession des preuves

• Chaque preuve déposée passe par file_security (ClamAV, YARA-X, quarantaine, fail-closed) puis par le domaine storage avec l'usage evidence (verrou objet SeaweedFS en mode conformité, empreinte, intégrité) ; extraction par Docling via le Control Plane ; pseudonymisation par Presidio quand la politique l'exige.
• Une preuve n'est jamais modifiée : nouvelle version ou annotation séparée ; événements d'intégrité et d'accès journalisés en ajout seul ; gel légal ; bundle d'export avec inventaire et empreintes ; aucune exportation de données tierces hors droits.
• Une preuve manquante donne incomplete ou unverifiable, jamais une non-conformité prouvée.

6. Moteur de référentiels et applicabilité

• Catalogue versionné de référentiels, politiques, procédures, exigences et obligations, avec juridiction, secteur, activité, entité, période d'entrée en vigueur et statut de validation ; import de versions, comparaison, analyse d'impact sur les contrôles, revue humaine avant publication.
• L'applicabilité est décidée par juridiction et par entité par une fonction conformité habilitée ; aucune réglementation étrangère n'est chargée comme obligatoire par défaut ; sans validation : Applicability not verified.
• Aucune déclaration réglementaire automatique vers un superviseur ; aucune norme privée non licenciée redistribuée en texte intégral.

7. Données du produit

• Schéma compliance dans le PostgreSQL du catalogue (base dédiée, rôle à privilèges minimaux), SQLAlchemy 2 asynchrone, asyncpg et Alembic ; le Control Plane garde ses migrations V*.sql.
• Familles de tables : instances et réglages ; référentiels, versions, obligations et liens ; entités auditables, processus, risques, évaluations ; contrôles, versions, propriétaires, calendriers, exécutions, exceptions ; plans d'audit, missions, programmes, papiers de travail et revues ; populations, plans et sélections d'échantillonnage ; demandes et éléments de preuve, versions, liens, événements d'intégrité et d'accès ; constats, versions, réponses du management ; actions CAPA, preuves et tests d'efficacité ; workflows et décisions d'approbation ; rapports, versions et approbations ; règles, exécutions et alertes de contrôle continu ; sources et rafraîchissements ; conversations et références d'exécution ; références d'audit, rétention et gels légaux ; travaux et boîte de sortie.
• RLS sur chaque table portée par un tenant, contexte posé par transaction, journaux en ajout seul protégés par déclencheur ; travaux durables FOR UPDATE SKIP LOCKED ; Redis seulement pour l'éphémère.

8. Cycle de vie par un domaine compliance du Control Plane

• Nouveau domaine services/control-plane/src/eai/domains/compliance, copie adaptée de rag_agent : instances, états draft, validating, provisioning, starting, ready, degraded, failed, stopping, stopped, updating, deleting, deleted, étapes idempotentes tracées, branding (logo analysé par file_security), délégation d'infrastructure au Manager par platform_manager, routeur /v1/compliance, migrations additives.
• Chaque instance est une application gouvernée et un agent du registre ; le parcours d'activation vit dans le portail Enterprise.
• Ressource compliance ajoutée au SDK enterprise_ai.

9. Frontend, streaming et observabilité

• Mêmes choix que l'ADR-0175 : Next.js 16, React 19, MUI, BFF OIDC avec cookie httpOnly et aucun jeton dans le navigateur, Markdown sanitisé, i18n français, anglais et arabe ; SSE reprenable par Last-Event-ID ; une trace par requête du BFF à LiteLLM ; spans IA vers Opik après retrait des données personnelles ; métriques Prometheus compliance_* avec définition documentée ; un taux de conformité n'est affiché que si population et formule sont définies.
• Grafana, Loki et Tempo (AGPL-3.0, ADR-0101) sont remplacés par Prometheus, Alertmanager, Alloy, OpenSearch et OpenSearch Dashboards, Jaeger et Opik.

10. Gabarit de service et publication

Descripteur navin-compliance-agent.yaml conforme à navin-manager/catalog/schema/service.schema.json et gabarit d'agent conforme à navin-manager/agent-templates/schema.json, validés sur une copie temporaire ; rien n'est publié dans navin-manager/ avant la validation explicite de l'utilisateur.

11. Vérité des capacités

Aucune fonction déclarée terminée sans test réel ; aucune capacité, aucun SLA, aucune HA annoncés sans mesure ; limites écrites dans navin-enterprise-compliance/docs/KNOWN_LIMITATIONS.md.

Alternatives écartées

• Reprendre l'embryon tel quel : schéma bancaire d'emblée, aucun test, sécurité réécrite au lieu des briques testées du RAG.
• Deux produits séparés (transverse et bancaire) : second moteur d'audit, divergence des workflows.
• Moteur de conformité dans le Control Plane lui-même : le Control Plane reste une plateforme, le métier reste dans le produit ; seul le cycle de vie des instances y entre.
• Laisser le LLM coter la gravité ou conclure l'effectivité : refusé.
• Appels directs à LiteLLM, Qdrant ou Cognee ; jetons dans le navigateur ; Redis comme file persistante ; publication immédiate dans le catalogue.

Conséquences

• Le noyau sert trois secteurs ; le pack bancaire est le premier livré et valide le contrat des packs.
• Un domaine compliance additif dans le Control Plane et deux outils de migration dans le dépôt (Alembic pour compliance, V*.sql pour le Control Plane).
• Briques du RAG copiées puis, à la troisième application, extraites dans un paquet commun.
• Dépendance au verrou objet du stockage : sans capacité déclarée, l'usage evidence est refusé.

Points à valider par l'utilisateur

1. Remplacement de Grafana, Loki et Tempo (AGPL-3.0) par les composants autorisés du catalogue.
2. Noms et identifiants : dossier navin-enterprise-compliance, paquet navin_compliance, préfixe d'API /api/v1/compliance, pack bancaire navin_compliance_banking, service navin-compliance-agent, domaine compliance du Control Plane.
3. Reprise de l'embryon : moteurs déterministes, machines à états, politiques OPA et rôles OpenFGA repris comme spécifications et réécrits avec tests ; schéma et couche sécurité non repris.
4. Ordre : noyau transverse d'abord, pack bancaire ensuite.
5. Publication du descripteur et du gabarit seulement après validation explicite.

Plan de réalisation

Lots suivis sur le tableau du projet : audit et architecture ; fondations du backend et domaine compliance ; référentiels et obligations ; risques et contrôles ; audits et papiers de travail ; preuves et échantillonnage ; constats et CAPA ; contrôle continu ; rapports ; copilote et sous-agents ; frontend ; gouvernance et observabilité ; pack bancaire ; provisionnement Navin ; validation.