Comment construire une piste d’audit conforme pour un moteur de scoring immobilier avec un refus lié à l’assurance ?

Une piste d’audit conforme pour un moteur de scoring immobilier doit enregistrer, horodater et rendre explicable chaque décision algorithmique, y compris les refus motivés par l’assurance emprunteur. Les exigences de l’ACPR imposent une traçabilité complète des variables d’entrée, des pondérations et des motifs de refus, tandis que la DSP2 encadre la collecte des données bancaires sous-jacentes. Sans cette architecture de journalisation, l’établissement s’expose à des sanctions prudentielles et à l’impossibilité de justifier ses décisions auprès du client ou du régulateur.

Cadre réglementaire : ce que l’ACPR et la DSP2 imposent concrètement

Obligations de traçabilité algorithmique selon l’ACPR et la DSP2

L’ACPR, dans ses orientations applicables aux établissements de crédit, exige que tout algorithme d’octroi de crédit soit documenté, auditable et explicable. Cela signifie que chaque décision — accord, refus partiel ou refus total — doit être associée à un enregistrement immuable des variables utilisées, de leurs pondérations au moment du calcul, et du motif précis ayant conduit au résultat. Pour un refus lié à l’assurance emprunteur, le moteur doit distinguer explicitement si le refus provient d’un risque médical, d’une surprime inacceptable ou d’une absence de couverture compatible avec les critères de la banque.

La DSP2 (Directive sur les services de paiement, transposée en droit français et supervisée par la Banque de France) intervient en amont : elle autorise l’accès aux données bancaires du client via des API agréées (AISP/PISP), sous réserve de son consentement explicite et traçable. Ce consentement doit lui-même figurer dans la piste d’audit, avec l’horodatage, l’identifiant de session et la portée exacte des données collectées. Toute donnée bancaire alimentant le score sans consentement DSP2 documenté constitue une violation réglementaire directe.

La combinaison de ces deux cadres crée une obligation de double traçabilité : traçabilité de la collecte (DSP2) et traçabilité de l’usage algorithmique (ACPR). Un middleware de scoring conforme doit les articuler dans un même journal d’événements structuré.

Architecture concrète d’une piste d’audit pour un refus assurance

Les champs obligatoires d’un enregistrement d’audit trail

Un enregistrement d’audit trail pour un refus lié à l’assurance doit contenir au minimum les champs suivants, structurés en JSON immuable et signé cryptographiquement. Chaque événement doit être horodaté en UTC et lié à un identifiant de dossier unique. Le tableau ci-dessous détaille les champs requis, leur source réglementaire et leur rôle dans la justification du refus.

{
  "session_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "timestamp_utc": "2026-07-15T09:42:11Z",
  "dossier_id": "IMM-2026-089341",
  "score_global": 0.38,
  "seuil_acceptation": 0.55,
  "decision": "REFUS",
  "motif_refus_code": "INS_SURPRIME",
  "variables_assurance": {
    "quotite_couverte": 50,
    "surprime_pct": 180,
    "taux_assurance_effectif": 1.42,
    "seuil_max_banque_pct": 0.80
  },
  "consentement_dsp2_ref": "DSP2-AISP-20260715-00412",
  "version_modele": "3.7.2",
  "hash_payload": "a3f1c9e2b84d..."
}

Implications pratiques : intégration dans un middleware de scoring

Automatisation de la piste d’audit via API et pipeline de données

Dans une architecture middleware moderne, la piste d’audit ne doit pas être générée manuellement après la décision : elle doit être produite atomiquement avec le calcul du score. Cela implique que le moteur de scoring expose un endpoint dédié (ex. POST /v1/scoring/decision) qui retourne simultanément la décision, le score décomposé et le payload d’audit signé. Ce payload est immédiatement persisté dans un journal append-only (Kafka, immutable ledger ou base de données avec write-once policy), indépendant de la base opérationnelle.

Pour les refus liés à l’assurance, une attention particulière doit être portée à la pseudonymisation des données médicales avant leur inscription dans le journal. Les informations de santé ayant conduit à une surprime ou un refus d’assurance relèvent du RGPD (données sensibles, article 9), et leur présence dans un log d’audit doit être limitée à un identifiant de pathologie codifié, jamais à un libellé en clair. Le middleware doit implémenter une couche de tokenisation avant l’écriture dans le journal.

Enfin, la piste d’audit doit être interrogeable par le régulateur et par le client. L’ACPR peut demander la reconstitution complète d’une décision à partir de son identifiant. Le client, en vertu du droit à l’explication (RGPD, article 22), peut exiger une version lisible du motif de refus. Le middleware doit donc exposer deux vues du même enregistrement : une vue technique complète pour l’ACPR, et une vue synthétique traduite en langage naturel pour le client — idéalement générée par un LLM contrôlé et lui-même audité.

Conclusion & Perspective 2027

D’ici 2027, la convergence entre les API Open Banking DSP2/DSP3, les modèles de langage embarqués dans les middlewares de crédit et les exigences croissantes de l’ACPR en matière d’explicabilité algorithmique rendra la piste d’audit entièrement automatisée et auto-documentée. Les moteurs de scoring généreront en temps réel des explications structurées en langage naturel, horodatées et signées, couvrant chaque variable — y compris les paramètres d’assurance emprunteur — sans intervention humaine. Les établissements qui investissent dès aujourd’hui dans une architecture de journalisation atomique et pseudonymisée seront les seuls à pouvoir absorber ces évolutions réglementaires sans refonte majeure de leur infrastructure.

Sources utilisées

• DSP2 — Directive sur les services de paiement (Banque de France)
• ACPR — Règles applicables aux établissements de crédit