ADR-0187 : Navin Enterprise Credit Analysis & Loan Origination Agent, application de crédit au-dessus du Control Plane

• Statut : accepté le 2026-11-04 ; les deux choix ouverts ont été tranchés par le client le même jour (voir « Décision sur les points à valider »)
• Date : 2026-11-04
• Portée : nouveau projet navin-credit/ (backend FastAPI, travaux durables, écrans dans le frontend commun des agents sectoriels (ADR-0180), intégration Navin), extensions additives du Control Plane (domaine services/control-plane/src/eai/domains/credit, migrations V250 à V259), contrats contracts/v1/credit-*.schema.json, modèle OpenFGA (deploy/policies/openfga/model.fga), paquet OPA eai.credit (deploy/policies/opa/credit.rego), écrans dédiés du portail Enterprise, descripteur de service du Navin Manager préparé mais non publié
• Documents liés : ADR-0101 (politique de licences), ADR-0106 (tenancy et RLS forcée), ADR-0114 (PostgreSQL source de vérité), ADR-0116 (audit chaîné), ADR-0123 (honnêteté des tests), ADR-0174 (mémoire Mem0 et Cognee), ADR-0175 (RAG Agent, modèle suivi), audit navin-credit/docs/NAVIN_INTEGRATION_AUDIT.md

Contexte

Le client demande une plateforme bancaire de bout en bout pour l'analyse de crédit et l'octroi : demandes, emprunteurs et groupes, pièces, analyse financière, capacité de remboursement, scoring, garanties, simulations, stress tests, aide à la décision, note de crédit, comités, contractualisation, décaissement contrôlé et suivi des engagements, avec un copilote IA. Ce n'est pas un chatbot sur des documents : un vrai moteur métier est exigé, et aucun chiffre, aucun score et aucune décision ne doit être produit par un modèle de langage.

L'audit du 2026-11-04 montre que le Control Plane fournit déjà la gouvernance (connaissances avec versions et pages, mémoire Cognee, analyse des fichiers fail-closed, stockage objet, approbations avec séparation des fonctions et quorum, délégations, exécutions d'agents et sous-agents, outils, connecteurs avec courtier, Presidio, preuves, lignage, évaluation, passerelle de modèles). Il manque toute la couche métier du crédit, le rendu PDF, DOCX et XLSX, la signature électronique et tout connecteur bancaire réel autre que des gabarits simulés. Les produits KYC/AML, Compliance & Audit, CO et FAI ne sont pas disponibles dans le dépôt au moment de la décision.

Décision

1. Cinq moteurs séparés

Moteur	Responsabilité	Ce qu'il ne fait jamais
Moteur financier	calculs vérifiables en decimal.Decimal : normalisation, ratios, flux, capacité, DSCR, amortissement, coût total, stress tests ; formules versionnées, restitution valeur, formule, entrées, sources et statut	aucun calcul en virgule flottante, aucun calcul confié au LLM
Moteur de risque	exécution de modèles approuvés et versionnés, variables autorisées, explicabilité	aucune PD, LGD, EAD ni perte attendue sans modèle approuvé : le module est alors affiché « non configuré »
Moteur de règles	éligibilité, limites, délégations et exceptions, évalués contre la version de politique en vigueur	aucune règle modifiable par le LLM, aucun seuil codé en dur
Agent IA	analyse, explication, préparation de recommandations et de documents à partir des résultats calculés et des pièces vérifiées	jamais source d'une décision, d'un taux, d'une condition ou d'un chiffre officiel
Décideur humain	décision selon la matrice de délégation et les procédures, par les approbations du Control Plane	aucune auto-approbation

2. Règles absolues

• Le LLM n'est jamais la source autoritative d'une décision financière ni d'un calcul officiel. Toute valeur affichée dans une note, un tableau ou une réponse du copilote vient d'un résultat enregistré du moteur financier, du moteur de risque ou d'une pièce vérifiée ; la réponse du copilote distingue faits, mesures vérifiées, interprétation de l'IA, limites et statut de validation humaine.
• Aucun décaissement n'est déclenché par l'IA. Une demande de décaissement est préparée, contrôlée (conditions préalables, juridique, conformité, opérations), autorisée par des humains distincts, puis transmise par un connecteur bancaire déclaré et testé avec une clé d'idempotence ; seul le statut relu dans le système source fait foi, une soumission n'est jamais présentée comme un transfert de fonds.
• Tout seuil (taux d'endettement, DSCR, LTV, montants de délégation, tolérances) vient des politiques validées de la banque, versionnées ; une décision reste liée à la version de politique appliquée. Aucune valeur universelle n'est imposée.
• Taux et frais sont lus dans des référentiels approuvés, jamais inventés.
• Une décision, une note finalisée ou un contrat validé n'est jamais écrasé : toute modification crée une nouvelle version historisée.
• Aucune valeur extraite d'un document n'entre dans un calcul officiel sans vérification humaine ; un contrôle d'incohérence n'est jamais présenté comme une fraude.

3. Deux plans, une seule gouvernance

Même séparation que l'ADR-0175 : le Navin Manager installe et exploite le runtime (service du catalogue navin-credit-agent : API, travaux, web) ; le Control Plane porte tenants, projets, rôles, modèles, connaissances, mémoire, analyse des fichiers, stockage, approbations, quotas, audit, politiques et traces ; le backend du crédit porte la couche métier et n'appelle le Control Plane que par le SDK Python enterprise_ai. Il n'appelle jamais directement Qdrant, Cognee, LiteLLM, Docling, ClamAV, YARA-X ni un système bancaire : connaissances, mémoire, fichiers et modèles passent par les domaines du Control Plane, les systèmes bancaires par le courtier de connecteurs.

4. Données du produit

• Schéma credit dans PostgreSQL (base dédiée, rôles à privilèges minimaux), SQLAlchemy 2 asynchrone, asyncpg et Alembic ; le Control Plane garde ses migrations V*.sql (plage V250 à V259 pour l'activation des instances).
• RLS forcée sur chaque table portée par un tenant, contexte tenant, projet et instance posé par SET LOCAL dans chaque transaction, jamais conservé par une connexion du pool ; isolation projet en plus de l'isolation tenant.
• Montants en numeric avec devise ISO 4217 explicite ; aucune colonne float pour une valeur financière.
• Versionnement par tables *_versions et historique des statuts ; verrouillage optimiste par numéro de version.
• Travaux durables dans PostgreSQL (FOR UPDATE SKIP LOCKED) avec une identité de travail signée par le serveur ; décisions et décaissements idempotents (clé d'idempotence unique par tenant) ; Redis seulement pour l'éphémère (cache, limites, verrous, idempotence courte), avec TTL.
• PostgreSQL conserve les données et décisions officielles ; Cognee enrichit les relations sémantiques et ne transforme jamais une hypothèse de l'IA en fait métier.

5. Frontend

Écrans dans le frontend commun des agents sectoriels (ADR-0180), paramétré par le manifeste produit du crédit : Next.js 16, React 19.3, MUI 9.5, fond blanc et texte noir, branding (nom, logo, couleur de la barre latérale, couleur de la barre de navigation), BFF OIDC avec PKCE sur un client confidentiel du realm Keycloak existant, sessions côté serveur dans Redis, CSRF, proxy SSE, français, anglais et arabe avec RTL. Ports de développement : 3476 (web) et 8476 (API). Aucun écran sans route réelle de l'API.

6. Rendu documentaire et signature

• Le Control Plane n'a aucun moteur de rendu : la note de crédit et les rapports sont rendus par le backend (JSON canonique, PDF par ReportLab, DOCX par python-docx, XLSX par openpyxl), uniquement depuis des résultats enregistrés ; chaque rendu porte l'empreinte de sa version.
• La signature passe par un connecteur vers la solution approuvée par la banque. Sans connecteur testé, aucun contrat n'est présenté comme signé ; une approbation applicative n'est jamais présentée comme une signature électronique qualifiée.

7. Tenants et instances

• Modèle partagé ou dédié au choix, comme le RAG : un runtime par cluster sert plusieurs instances isolées par la RLS, OpenFGA, les préfixes du stockage objet, les espaces de noms Redis et les correspondances contrôlées de Cognee ; une instance nommée du service par instance de crédit quand la banque l'exige. Le modèle partagé est soumis à la validation de la sécurité de chaque banque, notamment parce que la séparation de Cognee n'est que logique (ADR-0175).
• Le contexte tenant, projet et instance vient toujours de l'identité validée et des appartenances du Control Plane, jamais d'un paramètre du navigateur.
• Rôles logiques du produit (chargé de clientèle, analyste crédit, analyste risque, membre et président de comité, juriste, conformité, opérations, auditeur, administrateur) portés par des relations OpenFGA sur des types additifs (emprunteur, dossier, document, score, garantie, rapport, comité, condition, décaissement, outil).

8. Autorisations et politiques

OpenFGA et OPA en fail-closed : un refus, ou un moteur indisponible, bloque l'action avant son exécution. Le paquet OPA eai.credit couvre l'accès au dossier, la lecture des données financières par un agent, le scoring, l'override de note, l'approbation, la modification des conditions, la dérogation, la validation de garantie, la préparation et l'autorisation du décaissement et l'export. Un sous-agent agit avec son identité de service et le contexte vérifié de l'utilisateur, sans jamais augmenter ses privilèges ; aucun outil n'exécute de SQL libre sur un système bancaire.

9. Équité, protection des emprunteurs et réglementation

• Minimisation des données et finalité documentée ; variables de scoring inventoriées et justifiées, contrôle des variables proxy, évaluation des biais et de la dérive.
• Décision humaine qualifiée par défaut ; l'IA générative n'approuve ni ne refuse un crédit. Une décision automatisée n'est activable qu'avec une validation réglementaire documentée de la juridiction.
• Contestation, demande de révision, correction des données et revue humaine historisées.
• Usages de solvabilité des personnes physiques : la classification du système au titre de l'AI Act est à faire évaluer par la banque ; aucune conformité réglementaire n'est annoncée automatiquement. Le bureau de crédit n'est consulté qu'avec une finalité légale enregistrée.

10. Observabilité

Selon l'ADR-0101 : Grafana, Loki et Tempo (AGPL-3.0) sont refusés et remplacés par Prometheus, Alertmanager, Alloy, OpenSearch et OpenSearch Dashboards, Jaeger, ClickHouse et Opik. Une trace par requête (W3C traceparent), spans IA vers Opik par l'adaptateur du Control Plane sans états financiers complets ni données personnelles, métriques à faible cardinalité (jamais d'identifiant de dossier ou d'emprunteur en étiquette), OpenLineage pour les calculs.

11. Mémoire

Cognee selon l'essai technique de l'ADR-0175 (navin-enterprise-rag/docs/COGNEE_TRIAL.md) : profil standard de l'ADR-0174, vecteurs pgvector, graphe LadybugDB embarqué, accès par le contrat Navin Memory Provider du Control Plane uniquement.

12. Gabarit de service et vérité des capacités

Descripteur navin-credit-agent.yaml conforme au schéma réel du catalogue et manifeste de gabarit, validés sur une copie temporaire du catalogue ; rien n'est ajouté à navin-manager/catalog/services/ sans validation explicite du client. Aucune fonction n'est déclarée terminée sans test réel, aucun connecteur non testé n'est déclaré opérationnel, aucune capacité ni aucun SLA ne sont annoncés sans mesure ; les limites sont écrites dans navin-credit/backend/KNOWN_LIMITATIONS.md.

Conséquences

• La couche métier du crédit reste séparée de la gouvernance : les évolutions du Control Plane profitent au crédit sans duplication.
• Le moteur financier et le moteur de règles sont testables seuls, contre des jeux de référence vérifiés.
• Sans connecteurs bancaires réels ni modèles de risque approuvés, plusieurs modules s'affichent « non configuré » : c'est l'état attendu, pas un défaut.
• Deux outils de migration : Alembic pour le schéma credit, V*.sql pour le Control Plane.

Points à valider par le client

1. Modèle de déploiement des instances : dédié obligatoire, partagé ou dédié au choix, ou partagé par défaut.
2. Décaissement : envoi par un connecteur core banking déclaré et testé après autorisation humaine, ou jamais d'envoi par le produit.

Décision sur les points à valider

Le 2026-11-04, le client a choisi :

1. Partagé ou dédié au choix, comme le RAG, avec validation de la sécurité de chaque banque.
2. Envoi par un connecteur core banking déclaré et testé, après autorisation humaine par des personnes distinctes, avec clé d'idempotence et relecture du résultat dans le système source. Sans connecteur testé, la demande autorisée reste en attente d'exécution et aucun statut de fonds n'est affiché.

Alternatives écartées

• Calculs financiers par le LLM ou en virgule flottante : non vérifiables, arrondis non maîtrisés.
• Scores ou PD générés par un prompt, ou valeurs par défaut présentées comme réglementaires.
• Seuils universels codés en dur (DSCR, LTV, taux d'endettement).
• WeasyPrint pour le PDF : bibliothèques système (Pango) à installer, moins adapté au hors ligne que ReportLab.
• Appels directs aux systèmes bancaires sans le courtier de connecteurs, ou SQL libre sur le core banking.
• Simulation d'un connecteur bancaire ou d'un service de score externe présentée comme réelle.
• Publication immédiate dans le catalogue du Manager.

Plan de réalisation

Vingt-quatre tâches « CL » suivies sur le tableau du projet : audit, ADR, contrats et politiques ; backend et frontend ; politiques et produits ; demandes et expositions ; documents ; analyse financière, capacité et analyse entreprise ; scoring ; garanties et simulations ; aide à la décision et note ; comités, tarification et contrats ; décaissement ; suivi ; IA ; connecteurs et équité ; écrans ; sécurité, observabilité et cycle de vie ; scénarios, documentation, générateurs.