Quels contrôles l'ACPR peut-elle attendre d'un algorithme d'octroi de crédit immobilier pour un refus lié à l'assurance ?

Quels contrôles l’ACPR peut-elle attendre d’un algorithme d’octroi de crédit immobilier pour un refus lié à l’assurance ?

L’ACPR peut exiger qu’un algorithme d’octroi de crédit immobilier soit explicable, traçable et non discriminatoire, y compris lorsque le refus est motivé par l’assurance emprunteur. Concrètement, l’établissement doit documenter chaque variable utilisée, démontrer la proportionnalité de la décision et garantir la possibilité d’un réexamen humain. Ces obligations découlent des orientations ACPR sur les algorithmes et du cadre DSP2 encadrant l’accès aux données.

 Testez notre pré-générateur de dossier propulsé par notre middleware IA.  Générer mon pré-accord IA →

Cadre réglementaire : ce que l’ACPR exige des algorithmes de décision

Des orientations précises sur la gouvernance algorithmique

L’Autorité de contrôle prudentiel et de résolution (ACPR) encadre l’utilisation des algorithmes d’octroi de crédit au titre de ses Règles applicables aux établissements de crédit. Ces orientations imposent aux banques de maintenir une gouvernance robuste sur tout système automatisé participant à une décision de financement. Un algorithme ne peut pas constituer à lui seul une décision finale sans dispositif de supervision humaine identifié et documenté.

Trois piliers structurent les attentes de l’ACPR : la traçabilité (chaque décision doit être reconstituable a posteriori), l’explicabilité (le motif de refus doit être communicable au client en termes intelligibles) et la non-discrimination (aucune variable protégée — état de santé, origine, situation familiale — ne peut constituer un critère déterminant, même de façon indirecte via un proxy). Ces exigences s’appliquent avec une acuité particulière lorsque le refus est lié à l’assurance emprunteur, domaine où les données de santé sont particulièrement sensibles.

Par ailleurs, 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 bancaires du client via des API agréées, sous réserve de son consentement explicite. Toute donnée de flux bancaire intégrée dans le scoring doit donc être collectée dans ce cadre légal, et l’algorithme doit être capable de prouver la licéité de chaque source de données utilisée lors d’un contrôle ACPR.

Mécanismes concrets : les contrôles attendus point par point

De la variable d’entrée à la décision de refus : ce que l’inspecteur vérifie

Lors d’une mission de contrôle sur place ou sur pièces, les inspecteurs de l’ACPR examinent le cycle de vie complet de la décision algorithmique. Pour un refus lié à l’assurance, l’attention se porte notamment sur la manière dont le risque assurantiel est modélisé : le motif médical est-il traité directement ou via un score de risque agrégé ? La pondération de ce facteur est-elle documentée et validée par le comité des risques ? Le client a-t-il été informé de son droit à un réexamen par un conseiller humain ?

Dimension de contrôle Exigence ACPR Risque en cas de manquement
Traçabilité des décisions Journal horodaté de chaque décision algorithmique, conservé ≥ 5 ans Sanction administrative, injonction de mise en conformité
Explicabilité du refus Motif intelligible communiqué au client sur demande (art. 22 RGPD + orientations ACPR) Contentieux client, amende CNIL
Non-discrimination assurantielle Absence de proxy discriminatoire (code postal, CSP) corrélé à l’état de santé Requalification en pratique discriminatoire, mise en cause pénale
Licéité des données DSP2 Consentement client documenté pour tout flux bancaire utilisé dans le scoring Nullité de la collecte, invalidation de la décision
Supervision humaine Procédure de réexamen humain activable à la demande du client Non-conformité aux orientations EBA sur le crédit responsable
Validation du modèle Back-testing annuel, rapport de performance soumis au comité des risques Modèle jugé non maîtrisé, suspension possible de l’usage
{
  "decision_id": "IMM-2026-00471",
  "type_credit": "immobilier",
  "motif_refus": "risque_assurance_eleve",
  "score_assurabilite": 42,
  "seuil_acceptation": 60,
  "variables_determinantes": ["imc_proxy", "historique_arrets_travail", "age_emprunteur"],
  "source_donnees": "DSP2_consentement_v2",
  "superviseur_humain_disponible": true,
  "horodatage": "2026-07-15T09:32:11Z",
  "version_modele": "scoring-assurance-v3.1"
}

Implications pratiques : automatisation, API et middleware de conformité

Intégrer les exigences ACPR dès la conception du pipeline d’octroi

Pour un établissement qui automatise ses décisions d’octroi via un middleware IA, les contrôles ACPR ne sont pas une couche ajoutée en fin de chaîne : ils doivent être by design dans l’architecture. Cela signifie concrètement que chaque appel au modèle de scoring doit générer un objet de décision structuré (voir exemple ci-dessus), stocké dans un entrepôt de données auditable, avec un champ explicite identifiant la version du modèle et les variables ayant le plus contribué au score final (approche SHAP ou LIME).

L’Open Banking, rendu possible par la DSP2, enrichit les pipelines d’octroi de données de flux en temps réel. Mais cette richesse crée une responsabilité accrue : le middleware doit implémenter un registre de consentements, vérifier leur validité à chaque inférence et exclure automatiquement toute donnée dont le consentement a été révoqué. Un module de data lineage — traçant l’origine de chaque feature jusqu’à sa source réglementaire — devient ainsi un composant critique de conformité, directement inspectable par l’ACPR.

Enfin, le cas spécifique du refus lié à l’assurance impose une vigilance sur les variables proxy. Un algorithme entraîné sur des données historiques peut apprendre à utiliser le code postal ou la profession comme substitut implicite à un risque de santé. Les établissements doivent donc intégrer des tests d’équité (fairness audits) dans leur pipeline CI/CD, avec des seuils d’alerte déclenchant une revue humaine avant tout déploiement en production. L’ACPR peut demander ces rapports à tout moment dans le cadre de ses missions de contrôle sur pièces.

Questions fréquentes

L’ACPR peut-elle sanctionner une banque dont l’algorithme refuse un crédit pour des raisons liées à l’assurance sans explication ?

Oui. L’ACPR peut prononcer des sanctions administratives, voire des injonctions de mise en conformité, si un établissement ne peut pas justifier un refus algorithmique de manière intelligible. Le client dispose également d’un droit à l’explication au titre de l’article 22 du RGPD, et la CNIL peut intervenir en parallèle.

Les données collectées via DSP2 peuvent-elles être utilisées dans un algorithme de scoring assurantiel ?

Oui, sous réserve du consentement explicite et documenté du client, conformément au cadre DSP2 encadré par la Banque de France. L’algorithme doit être capable de prouver la licéité de chaque source de données lors d’un contrôle ACPR, et tout retrait de consentement doit entraîner l’exclusion immédiate des données concernées.

Qu’est-ce qu’un proxy discriminatoire dans le contexte d’un refus lié à l’assurance ?

Un proxy discriminatoire est une variable apparemment neutre (code postal, profession, CSP) que l’algorithme utilise comme substitut indirect à une caractéristique protégée comme l’état de santé. L’ACPR exige que les établissements réalisent des tests d’équité (fairness audits) pour détecter et éliminer ces corrélations indésirables.

Un réexamen humain est-il obligatoire pour tout refus algorithmique de crédit immobilier ?

Les orientations ACPR imposent qu’une procédure de réexamen humain soit disponible et activable à la demande du client. Cela ne signifie pas que chaque décision doit être revue systématiquement, mais que le client doit pouvoir en faire la demande et obtenir une réponse motivée par un conseiller identifié.

Conclusion & Perspective 2027

D’ici 2027, la convergence entre l’AI Act européen (applicable aux systèmes d’IA à haut risque, dont le crédit) et les orientations ACPR va imposer aux établissements un niveau de documentation algorithmique sans précédent : journaux d’audit standardisés, rapports de biais automatisés et interfaces d’explicabilité accessibles en temps réel aux superviseurs. Les middlewares IA de nouvelle génération intégreront des agents LLM capables de générer automatiquement les justificatifs réglementaires d’un refus — en langage naturel pour le client, en format structuré pour l’ACPR — réduisant le délai de réponse aux injonctions de quelques semaines à quelques heures.

Sources utilisées