Quelles preuves conserver pour auditer une décision automatisée de crédit concernant un client demandant l’accès à ses données ?

Lorsqu’un client exerce son droit d’accès aux données (Art. 15 RGPD) après un refus de crédit automatisé, l’établissement prêteur doit être en mesure de produire un ensemble précis de preuves : journaux d’entrée du modèle, version du moteur de scoring, règles métier appliquées et horodatage de la décision. Ces éléments constituent le socle minimal d’un audit opposable, tant vis-à-vis du client que de l’ACPR ou de la CNIL.

Cadre réglementaire : entre RGPD, Code de la consommation et supervision ACPR

Les obligations légales qui s’imposent aux décisions automatisées de crédit

Le crédit immobilier aux particuliers est encadré en France par les articles L313-1 et suivants du Code de la consommation (Légifrance, LEGITEXT000006069565). Ces dispositions imposent à l’établissement prêteur de motiver tout refus et de s’assurer que la décision repose sur des critères objectifs, vérifiables et non discriminatoires. Dès lors qu’un algorithme intervient dans la chaîne de décision, le régime du traitement automatisé au sens de l’article 22 du RGPD s’applique en sus : le client dispose d’un droit à ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques significatifs, sauf consentement explicite ou nécessité contractuelle.

L’ACPR, bras armé de la Banque de France pour la supervision bancaire, attend des établissements qu’ils documentent leurs modèles de scoring conformément aux lignes directrices publiées sur son portail de supervision (Banque de France, banque-france.fr/fr/supervision). Cela inclut la gouvernance du modèle (model governance), les tests de robustesse, les procédures de validation interne et les mécanismes de recours. En cas de contrôle, l’absence de traçabilité constitue un manquement susceptible d’entraîner des mesures correctives.

Enfin, la CNIL rappelle que le droit d’accès (Art. 15 RGPD) oblige le responsable de traitement à communiquer non seulement les données personnelles utilisées, mais aussi « la logique sous-jacente » du traitement automatisé ainsi que « les conséquences envisagées » pour la personne concernée. Cette obligation d’explicabilité se traduit concrètement par la nécessité de conserver des artefacts techniques précis à chaque décision.

Les preuves à conserver : inventaire technique et durées de rétention

Cartographie des artefacts d’audit pour un moteur de scoring crédit

Un audit solide repose sur la capacité à reconstituer fidèlement la décision telle qu’elle a été prise à l’instant T. Cela implique de figer, au moment de la décision, un ensemble d’artefacts immuables : les données d’entrée brutes (revenus, charges, taux d’endettement calculé), la version exacte du modèle utilisé (hash du binaire ou identifiant de déploiement), les scores intermédiaires, les règles métier activées et le résultat final avec son horodatage certifié. La durée de conservation minimale recommandée est alignée sur la prescription quinquennale en matière civile (Art. 2224 du Code civil), soit 5 ans après la fin du contrat ou du refus.

{
  "decision_id": "DCR-2026-00471839",
  "timestamp_iso8601": "2026-07-15T10:34:22Z",
  "model_version_hash": "sha256:a3f9c1...",
  "input_snapshot": {
    "revenus_nets_mensuels": 4200,
    "charges_mensuelles": 850,
    "taux_endettement_calcule": 35.2,
    "apport_pct": 12.5
  },
  "score_final": 42,
  "seuil_acceptation": 55,
  "decision": "REFUS",
  "motif_principal": "taux_endettement_superieur_seuil_HCSF",
  "shap_top3": [
    {"feature": "taux_endettement", "impact": -8.4},
    {"feature": "anciennete_emploi", "impact": -3.1},
    {"feature": "apport", "impact": +2.7}
  ],
  "rules_snapshot_ref": "git:rules-engine@v4.2.1"
}

Implications pratiques pour un middleware IA de crédit immobilier

Automatiser la traçabilité sans alourdir le pipeline décisionnel

Un middleware IA bien conçu doit intégrer la génération des artefacts d’audit comme une étape atomique et non optionnelle du pipeline décisionnel. Concrètement, cela signifie que chaque appel au moteur de scoring déclenche automatiquement l’écriture d’un enregistrement immuable (stockage WORM ou blockchain privée) contenant l’intégralité du snapshot décrit dans le tableau ci-dessus. L’Open Banking (DSP2 / PSD2) facilite cette démarche en permettant de récupérer les données bancaires du client via API agrégateur, puis de les versionner au moment précis de leur utilisation dans le modèle — garantissant ainsi la cohérence entre ce que le client a consenti à partager et ce que le modèle a effectivement traité.

Lorsqu’un client exerce son droit d’accès (Art. 15 RGPD), le middleware doit être capable de restituer, via une API dédiée, un rapport d’explicabilité structuré en moins de 30 jours (délai légal RGPD). Ce rapport doit inclure les SHAP values ou équivalent (LIME, counterfactuals) permettant d’identifier les variables ayant le plus pesé dans la décision, ainsi que le seuil de refus en vigueur à la date de la décision. La séparation entre le moteur de scoring (modifiable) et le registre d’audit (immuable) est une architecture critique : toute mise à jour du modèle ne doit jamais altérer les logs historiques.

Du côté de la supervision ACPR (Banque de France, banque-france.fr/fr/supervision), les établissements doivent pouvoir produire, lors d’un contrôle sur place ou sur pièces, un rapport de model governance attestant que le modèle utilisé à la date de la décision contestée avait bien été validé par le comité de risques interne. L’intégration d’un registre de modèles (MLflow, DVC ou équivalent) directement dans le middleware permet de répondre à cette exigence de manière automatisée, sans dépendre d’une reconstitution manuelle a posteriori.

Conclusion & Perspective 2027

D’ici 2027, les LLM spécialisés en droit bancaire et les agents IA capables d’interroger en temps réel les registres d’audit devraient permettre de répondre automatiquement aux demandes d’accès RGPD en moins de 24 heures, contre 30 jours aujourd’hui. Les middlewares de crédit immobilier évolueront vers des architectures « audit-by-design » où chaque décision génère nativement un paquet de preuves cryptographiquement signé, directement exploitable par un LLM pour produire une explication en langage naturel à destination du client ou du régulateur. La convergence entre Open Banking, RAG juridique et model governance automatisée redéfinira le standard de conformité attendu par l’ACPR et la CNIL pour les décisions de crédit algorithmiques.

Sources utilisées

• Légifrance — Code de la consommation, crédit immobilier (Art. L313-1)
• Banque de France — Supervision bancaire et réglementation