Comment construire une piste d’audit conforme pour un moteur de scoring immobilier avec un profil médical sensible ?

Construire une piste d’audit conforme pour un moteur de scoring immobilier traitant des données médicales sensibles impose de combiner les exigences RGPD (article 9), les orientations ACPR sur les algorithmes d’octroi de crédit et le cadre DSP2 d’accès aux données bancaires. Chaque décision algorithmique doit être horodatée, versionnée et explicable, depuis la collecte du consentement jusqu’à la décision finale de crédit. Sans cette architecture de traçabilité, l’établissement prêteur s’expose à des sanctions prudentielles et à l’invalidation de ses décisions d’octroi.

Cadre réglementaire : RGPD, ACPR et DSP2 face aux données médicales

Trois référentiels qui se superposent sans s’annuler

Les données médicales constituent une catégorie particulière au sens de l’article 9 du RGPD : leur traitement est en principe interdit, sauf consentement explicite, libre et éclairé de la personne concernée, ou nécessité d’exécution d’un contrat d’assurance emprunteur. Dans le contexte du crédit immobilier, ces données apparaissent typiquement via la questionnaire de santé de l’assurance emprunteur ou via des déclarations volontaires de l’emprunteur souhaitant bénéficier de la convention AERAS. Le moteur de scoring ne peut les ingérer qu’à condition que la base légale soit documentée, horodatée et archivée de façon immuable.

L’ACPR, dans ses orientations sur l’utilisation des algorithmes d’octroi de crédit, impose aux établissements de crédit de démontrer la gouvernance de leurs modèles : documentation des variables d’entrée, justification de leur pertinence, traçabilité des versions du modèle et des seuils de décision (source : ACPR — Règles applicables aux établissements de crédit). Parallèlement, la DSP2 (Directive sur les services de paiement, transposée en droit français et encadrée par la Banque de France) autorise l’accès aux données de compte bancaire via des API agréées, sous réserve d’un consentement fort du client. Ce consentement DSP2 doit lui aussi figurer dans la piste d’audit, car il conditionne la légitimité des flux de données alimentant le score.

La superposition de ces trois référentiels crée une obligation de traçabilité à trois niveaux : légal (consentement), technique (version du modèle, paramètres) et décisionnel (score produit, seuil appliqué, décision finale). Omettre l’un de ces niveaux expose l’établissement à un risque de non-conformité cumulatif.

Architecture concrète d’une piste d’audit : composants et données à journaliser

Les sept couches d’un journal d’audit robuste

Une piste d’audit conforme n’est pas un simple fichier de logs : c’est une chaîne d’événements immuables, signés cryptographiquement, couvrant l’intégralité du cycle de vie de la décision. Pour un profil médical sensible, chaque couche doit être isolée afin de permettre une purge sélective en cas d’exercice du droit à l’effacement (article 17 RGPD), sans altérer l’intégrité du reste du journal.

Le tableau ci-dessous détaille les sept couches minimales recommandées, les données à capturer et les durées de conservation applicables au crédit immobilier français :

{
  "audit_event": "model_inference",
  "timestamp_utc": "2026-07-15T09:42:11Z",
  "dossier_id": "HASH_PSEUDONYME_XYZ",
  "model_version": "scoring-immo-v3.2.1",
  "features_count": 47,
  "medical_features_present": true,
  "medical_consent_ref": "CONSENT-2026-07-14-0091",
  "dsp2_token_ref": "DSP2-TOKEN-REF-4421",
  "score_raw": 712,
  "decision_threshold": 650,
  "decision": "ACCORD_CONDITIONNEL",
  "explainability_method": "SHAP",
  "top_features": ["taux_endettement", "stabilite_revenus", "historique_bancaire_24m"],
  "immutable_hash": "sha256:a3f9...c12e"
}

Implications pratiques : middleware IA, API et automatisation de la conformité

Intégrer la traçabilité dès la conception du pipeline (Privacy by Design)

Un middleware IA dédié au crédit immobilier doit implémenter la piste d’audit comme un composant de première classe, non comme un ajout a posteriori. Concrètement, cela signifie que chaque microservice du pipeline — collecte DSP2, feature store, moteur de scoring, moteur de décision — publie ses événements dans un bus de messages immuable (type Apache Kafka avec rétention chiffrée ou équivalent souverain). Le middleware orchestre ensuite la corrélation de ces événements en un journal cohérent, indexé par un identifiant de dossier pseudonymisé. Cette architecture garantit qu’aucune donnée médicale brute ne transite en clair entre les couches, conformément aux exigences de l’ACPR sur la gouvernance des modèles.

La DSP2 introduit une contrainte supplémentaire : le token d’accès aux données bancaires a une durée de vie limitée et doit être renouvelé avec re-consentement explicite au-delà de 90 jours (Banque de France, cadre DSP2). Le middleware doit donc journaliser chaque renouvellement de token et vérifier automatiquement la cohérence temporelle entre la date du consentement médical et la date d’appel au modèle. Un écart supérieur à la fenêtre de validité du consentement doit déclencher une alerte de conformité et bloquer l’inférence.

Enfin, l’explicabilité algorithmique n’est pas optionnelle : l’ACPR attend des établissements qu’ils soient en mesure de restituer, à tout moment et à tout contrôleur, les raisons d’une décision de crédit. L’intégration de méthodes d’explicabilité post-hoc (SHAP, LIME) dans le pipeline d’inférence, avec archivage des valeurs de contribution par feature dans le journal d’audit, constitue la réponse technique à cette exigence réglementaire. Pour les profils médicaux, il est impératif que les features issues du questionnaire de santé soient clairement étiquetées comme « données sensibles » dans le journal, afin de faciliter leur purge sélective sans altérer les autres entrées du modèle.

Conclusion & Perspective 2027

D’ici 2027, l’automatisation complète de la piste d’audit via des agents LLM spécialisés permettra de générer en temps réel des rapports de conformité lisibles par les contrôleurs ACPR, directement depuis les événements bruts du pipeline. Des connecteurs Open Banking standardisés (PSD3 en cours de transposition) renforceront la portabilité des consentements DSP2, tandis que des modules de détection d’anomalies entraînés sur les journaux d’audit identifieront proactivement les dérives de modèle ou les violations de consentement avant toute décision d’octroi. Pour les profils médicaux sensibles, l’enjeu sera de coupler ces capacités à des enclaves d’exécution sécurisées (TEE) garantissant que même l’opérateur du middleware ne peut accéder aux données brutes — une exigence qui pourrait devenir normative sous l’impulsion conjointe de la CNIL et de l’ACPR.

Sources utilisées

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