Dans un algorithme de prêt analysant un dossier par IA, les critères de décision doivent rester explicables pour satisfaire aux exigences de l’ACPR et du RGPD : taux d’endettement, reste à vivre, stabilité des revenus et historique bancaire doivent pouvoir être justifiés individuellement. En outre, l’emprunteur dispose d’un droit à l’explication de toute décision automatisée le concernant, et l’établissement prêteur doit être en mesure de restituer les variables déterminantes du refus ou de l’accord.
Cadre réglementaire : ce que l’ACPR et le RGPD imposent aux algorithmes de crédit
L’explicabilité, une obligation juridique et non un simple choix technique
L’utilisation d’algorithmes d’intelligence artificielle dans l’octroi de crédit immobilier est encadrée en France par l’Autorité de contrôle prudentiel et de résolution (ACPR), dont les orientations sur les algorithmes d’octroi de crédit précisent que tout modèle automatisé doit permettre à l’établissement de crédit de justifier ses décisions devant le superviseur. Cette exigence s’articule également directement avec l’article 22 du RGPD, qui interdit toute décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques significatifs pour une personne physique, sauf consentement explicite ou nécessité contractuelle — et impose dans tous les cas un droit à l’explication.
Concrètement, l’ACPR attend des établissements qu’ils documentent la logique interne de leurs modèles, qu’ils identifient les variables les plus influentes sur la décision finale, et qu’ils soient capables de restituer, en langage intelligible, les raisons d’un refus ou d’une modulation de l’offre. Un modèle de type « boîte noire » (deep learning non interprétable, par exemple) ne peut donc pas être déployé seul dans la chaîne de décision : il doit être couplé à une couche d’explicabilité (SHAP, LIME ou équivalent) ou à un système de règles métier auditables.
La DSP2 (Directive sur les services de paiement, transposée en droit français et supervisée par la Banque de France) ajoute une dimension supplémentaire : lorsque l’algorithme exploite des données bancaires issues de l’Open Banking — relevés de compte, flux de dépenses, comportements d’épargne — ces données ne peuvent être utilisées qu’avec le consentement explicite du client. Leur intégration dans le scoring doit donc être tracée et réversible, ce qui renforce l’exigence d’explicabilité variable par variable.
Les critères concrets qui doivent impérativement rester explicables
Cartographie des variables auditables dans un dossier de prêt immobilier traité par IA
Tous les critères utilisés dans un algorithme de prêt ne présentent pas le même niveau de risque réglementaire. On distingue les variables réglementairement sensibles (dont l’usage doit être justifié et dont l’impact doit être mesurable) des variables comportementales issues de l’Open Banking (soumises au consentement DSP2). Le tableau ci-dessous synthétise les principales catégories, leur statut d’explicabilité requis et le risque de non-conformité associé.
| Critère / Variable | Type de donnée | Explicabilité requise | Risque réglementaire si opaque |
|---|---|---|---|
| Taux d’endettement (≤ 35 % HCSF) | Financière réglementaire | Obligatoire — seuil normatif public | Très élevé (non-conformité HCSF) |
| Reste à vivre mensuel | Financière calculée | Obligatoire — variable déterminante | Élevé (discrimination indirecte possible) |
| Stabilité et nature des revenus (CDI, TNS, revenus fonciers) | Socio-professionnelle | Obligatoire — justification du scoring | Élevé (biais de statut professionnel) |
| Historique de remboursement / incidents bancaires | Comportementale bancaire | Obligatoire — variable d’historique | Moyen à élevé |
| Flux de dépenses Open Banking (DSP2) | Comportementale temps réel | Obligatoire + consentement DSP2 | Très élevé si sans consentement tracé |
| Score de crédit composite (modèle interne) | Agrégée / modélisée | Obligatoire — décomposition SHAP requise | Élevé (boîte noire non auditable) |
| Valeur du bien / LTV (Loan-to-Value) | Patrimoniale | Obligatoire — ratio prudentiel | Moyen |
| Données socio-démographiques (âge, lieu de résidence) | Personnelle sensible | Interdite comme variable directe (RGPD) | Très élevé (discrimination prohibée) |
Implications pratiques pour un middleware IA : architecture et API d’explicabilité
Intégrer l’explicabilité dès la conception du pipeline de scoring
Pour un middleware de crédit immobilier, l’explicabilité ne peut pas être une couche ajoutée a posteriori : elle doit être architecturée dès la conception du pipeline. Cela implique de séparer clairement le moteur de scoring (modèle ML) de la couche d’interprétation (SHAP values, règles métier auditables), et d’exposer via API les contributions individuelles de chaque variable pour chaque dossier traité. L’ACPR recommande que cette documentation soit conservée et consultable pendant toute la durée de vie du crédit.
Dans le cadre de l’Open Banking DSP2, le middleware doit également gérer la traçabilité du consentement : chaque donnée bancaire agrégée (flux de dépenses, soldes moyens, comportements d’épargne) doit être associée à un token de consentement horodaté, révocable à tout moment par le client. Si le consentement est retiré, les variables correspondantes doivent être exclues du scoring en temps réel — ce qui suppose une architecture de features store modulaire et non monolithique.
Enfin, la restitution de l’explication au client doit être automatisée et personnalisée : le middleware doit générer, pour chaque décision, un résumé en langage naturel des trois à cinq variables les plus déterminantes, en évitant tout jargon technique. Cette exigence, à la croisée du droit à l’explication RGPD et des orientations ACPR, est aujourd’hui l’un des chantiers les plus actifs des équipes FinTech spécialisées en crédit immobilier.
Même avec un profil complexe, ne devinez plus si votre prêt sera accepté. Testez notre technologie basée sur l’intelligence artificielle propulsée par notre middleware Générer mon pré-accord IA →
Conclusion & Perspective 2027
D’ici 2027, la convergence entre les LLM de génération de texte et les moteurs de scoring explicable devrait permettre de produire automatiquement, pour chaque dossier, une lettre de décision personnalisée et auditables par le superviseur — en quelques secondes. Les API d’Open Banking DSP2 de nouvelle génération fourniront des flux de données comportementales enrichis, mais leur intégration dans le scoring restera conditionnée à l’explicabilité variable par variable, sous peine de sanctions ACPR. Les établissements qui auront investi dès maintenant dans des architectures de scoring modulaires et interprétables disposeront d’un avantage compétitif décisif face aux exigences réglementaires croissantes de l’IA Act européen, dont les premières obligations pour les systèmes à haut risque (dont le crédit) entrent en vigueur progressivement jusqu’en 2027.
Sources utilisées
- DSP2 — Directive sur les services de paiement (Banque de France)
- ACPR — Règles applicables aux établissements de crédit
{
"exemple_middleware_scoring": "fictif illustratif",
"dossier_id": "IMM-2026-00412",
"taux_endettement": 33.2,
"seuil_hcsf": 35,
"reste_a_vivre_mensuel": 1840,
"stabilite_revenus": "CDI_anciennete_4ans",
"ltv": 82.5,
"score_composite": 74,
"shap_top_variables": [
{ "variable": "taux_endettement", "contribution": 0.31 },
{ "variable": "reste_a_vivre", "contribution": 0.27 },
{ "variable": "historique_incidents", "contribution": -0.18 }
],
"decision": "accord_conditionnel",
"explication_client": "Votre taux d'endettement de 33,2 % est conforme au seuil HCSF de 35 %. Un incident bancaire détecté en 2024 a légèrement réduit votre score."
}