Expliquer automatiquement un refus de prêt lié à l’assurance emprunteur est possible sans violer le RGPD, à condition de respecter l’article 22 du règlement européen et les obligations de motivation prévues par le Code de la consommation. Le système doit produire une explication intelligible, non discriminatoire et fondée sur des critères objectifs, sans révéler de données de santé brutes ni exposer la logique interne du modèle de scoring au-delà du nécessaire.
Testez notre outil propulsé par l’intelligence artificielle. Générer mon pré-accord IA →
Cadre réglementaire : entre Code de la consommation et RGPD
Les obligations de motivation d’un refus de crédit immobilier
Le Code de la consommation encadre strictement le crédit immobilier aux particuliers. Les articles L313-1 et suivants (Légifrance, LEGITEXT000006069565) imposent aux établissements prêteurs d’évaluer la solvabilité de l’emprunteur et de l’informer des motifs de refus lorsque celui-ci résulte d’une consultation de fichiers. Cette obligation de transparence s’applique également lorsque le refus est indirect, c’est-à-dire lorsque c’est l’impossibilité d’obtenir une assurance emprunteur conforme qui bloque l’octroi du prêt.
Le RGPD (Règlement UE 2016/679) ajoute une couche de protection supplémentaire via son article 22 : toute décision produisant des effets juridiques significatifs sur une personne physique et reposant exclusivement sur un traitement automatisé est en principe interdite, sauf consentement explicite, nécessité contractuelle ou autorisation légale. Or, les données de santé utilisées par les assureurs pour évaluer le risque médical constituent des données sensibles au sens de l’article 9 du RGPD, ce qui impose des garanties renforcées. La Banque de France et l’ACPR rappellent dans leurs textes de supervision que les établissements doivent documenter leurs traitements automatisés et être en mesure de les expliquer à tout moment (Banque de France — Supervision bancaire et réglementation).
La loi Lemoine (2022) a par ailleurs renforcé le droit à l’oubli et limité le questionnaire médical pour certains prêts, réduisant mécaniquement la surface de données de santé traitées. Cela simplifie la conformité RGPD mais ne supprime pas l’obligation d’expliquer le refus de manière compréhensible.
Mécanisme concret : produire une explication conforme sans exposer les données sensibles
Architecture d’une explication automatisée RGPD-compatible
L’enjeu technique est de générer une explication en langage naturel qui soit à la fois suffisamment informative pour satisfaire l’obligation légale et suffisamment abstraite pour ne pas révéler de données de santé brutes ni permettre une réidentification. La technique des counterfactual explanations (explications contrefactuelles) est particulièrement adaptée : plutôt que d’exposer le score médical de l’emprunteur, le système indique quelles conditions objectives auraient conduit à un résultat différent (ex. : « un capital assuré inférieur à X € ou une durée réduite à Y ans aurait permis l’acceptation »).
Le tableau ci-dessous synthétise les types de données impliquées dans un refus lié à l’assurance, leur sensibilité RGPD et la forme d’explication autorisée :
| Type de donnée | Catégorie RGPD | Utilisable dans l’explication ? | Forme recommandée |
|---|---|---|---|
| Âge de l’emprunteur | Donnée ordinaire | Oui | Mention directe possible |
| Montant et durée du prêt | Donnée ordinaire | Oui | Mention directe possible |
| Résultat du questionnaire médical | Donnée de santé (Art. 9 RGPD) | Non (brut) | Explication contrefactuelle uniquement |
| Score de risque médical agrégé | Donnée de santé dérivée | Partiel | Fourchette de risque anonymisée |
| Antécédents déclarés | Donnée de santé (Art. 9 RGPD) | Non | Renvoi vers le médecin conseil |
| Taux d’endettement résiduel | Donnée financière ordinaire | Oui | Mention directe + seuil légal (35 %) |
Implications pratiques : middleware IA, API et Open Banking
Intégrer l’explication conforme dans un pipeline de décision automatisé
Un middleware IA dédié au crédit immobilier doit orchestrer trois couches distinctes pour produire une explication RGPD-compatible. La première couche collecte et normalise les données non sensibles (revenus, durée, capital, taux d’endettement) via des API Open Banking (DSP2). La deuxième couche interroge le moteur de scoring assurance en mode black-box : seul le résultat agrégé (accepté / refusé / conditions restreintes) remonte, sans que les données de santé brutes ne transitent dans les logs applicatifs. La troisième couche, pilotée par un LLM fine-tuné sur le droit de la consommation français, génère l’explication en langage naturel à partir des seules variables non sensibles et du résultat contrefactuel.
Cette architecture garantit la conformité à l’article 22 du RGPD en préservant systématiquement un droit à l’intervention humaine : l’emprunteur peut demander une révision par un conseiller, conformément aux exigences de l’ACPR rappelées dans les textes de supervision de la Banque de France. Le middleware doit également journaliser chaque explication générée (sans les données de santé) pour permettre un audit a posteriori en cas de contrôle de la CNIL.
Sur le plan opérationnel, l’API d’explication doit retourner un objet structuré (voir exemple ci-dessus) contenant : le motif agrégé, les paramètres contrefactuels, un booléen confirmant l’absence d’exposition de données de santé, et la base légale du traitement. Ce niveau de structuration facilite l’intégration dans les CRM bancaires et les plateformes de courtage en ligne, tout en constituant une preuve de conformité opposable.
Questions fréquentes
Un refus de prêt lié à l’assurance doit-il obligatoirement être motivé par écrit ?
Oui. Les articles L313-1 et suivants du Code de la consommation imposent à l’établissement prêteur d’informer l’emprunteur des motifs de refus, notamment lorsque celui-ci résulte d’une consultation de fichiers ou d’une impossibilité d’assurance. Cette obligation s’applique même si le refus est indirect.
Le RGPD interdit-il toute décision automatisée en matière de crédit immobilier ?
Non, mais il l’encadre strictement. L’article 22 du RGPD autorise les décisions automatisées lorsqu’elles sont nécessaires à l’exécution d’un contrat ou autorisées par la loi, à condition que des garanties appropriées soient mises en place, notamment le droit à une intervention humaine et à une explication intelligible.
Comment expliquer un refus d’assurance sans révéler les données de santé de l’emprunteur ?
La technique des explications contrefactuelles permet de formuler le refus en termes de conditions objectives (capital maximum assurable, durée réduite, quotité partielle) sans exposer les données médicales brutes. Seul le résultat agrégé du scoring médical est utilisé, les données de santé restant dans un compartiment isolé non accessible aux logs applicatifs.
Quel rôle joue l’ACPR dans le contrôle des explications automatisées de refus de crédit ?
L’ACPR, sous l’égide de la Banque de France, supervise les établissements de crédit et vérifie que leurs traitements automatisés sont documentés, explicables et conformes aux obligations légales. Elle peut exiger la production des journaux d’audit des décisions automatisées lors de ses contrôles sur place ou sur pièces.
Conclusion & Perspective 2027
D’ici 2027, les LLM spécialisés en droit financier français seront capables de générer en temps réel des explications de refus entièrement personnalisées, multilingues et auditables, directement injectées dans les API bancaires via des connecteurs standardisés (STET, Berlin Group). L’enjeu ne sera plus de produire l’explication, mais de certifier automatiquement sa conformité RGPD avant envoi — une fonction que les middleware IA de nouvelle génération intégreront nativement, réduisant le risque de sanction CNIL à un niveau résiduel et transformant l’obligation légale en avantage concurrentiel pour les établissements les plus avancés.
{
"type_refus": "assurance_emprunteur",
"motif_agregé": "profil_risque_élevé",
"explication_contrefactuelle": {
"capital_max_assurable": 180000,
"duree_max_ans": 15,
"quotite_proposee_pct": 50
},
"donnees_sante_exposees": false,
"base_legale_traitement": "Art. 22 RGPD + Art. L313-1 Code conso.",
"droit_acces_humain": true
}