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

L’ACPR attend d’un algorithme d’octroi de crédit immobilier qu’il intègre, documente et trace explicitement l’évaluation de l’équivalence de garanties lors d’un changement d’assurance emprunteur. Cela implique une gouvernance algorithmique formalisée, une auditabilité complète des décisions et une conformité aux orientations de l’ACPR sur les systèmes automatisés de décision de crédit.

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

Gouvernance, explicabilité et traçabilité des décisions automatisées

L’ACPR, dans ses règles applicables aux établissements de crédit, pose un principe fondamental : tout algorithme participant à une décision d’octroi ou de maintien d’un crédit immobilier doit être gouverné, documenté et auditable. Cela signifie que l’établissement prêteur doit être en mesure de reconstituer, a posteriori, la logique ayant conduit à accepter ou refuser un changement d’assurance emprunteur, et d’en rendre compte à l’autorité de supervision sur simple demande.

Concrètement, l’ACPR attend que l’algorithme d’octroi soit soumis à une validation interne formalisée (comité de modèles, back-testing régulier) et que ses paramètres de pondération — notamment ceux relatifs à l’évaluation de l’équivalence de garanties — soient consignés dans une documentation technique accessible aux équipes de contrôle interne et aux inspecteurs de l’ACPR. Toute modification substantielle du modèle doit faire l’objet d’une nouvelle validation avant mise en production.

Par ailleurs, l’ACPR insiste sur la non-discrimination algorithmique : les variables utilisées pour scorer un emprunteur souhaitant changer d’assurance ne doivent pas, directement ou par proxy, introduire de biais fondés sur des critères prohibés (état de santé, origine, etc.). Un audit de biais doit être conduit périodiquement et ses résultats conservés.

Mécanisme concret : les contrôles attendus étape par étape lors d’un changement d’assurance

De la réception de la demande à la décision algorithmique tracée

Lorsqu’un emprunteur sollicite un changement d’assurance emprunteur (dans le cadre de la loi Lemoine ou à l’échéance annuelle), l’algorithme d’octroi doit exécuter une séquence de contrôles précis et les journaliser. Le recours aux données bancaires ouvertes via DSP2 — qui autorise l’accès aux données de compte avec consentement explicite du client — peut enrichir l’évaluation de la solvabilité résiduelle de l’emprunteur, à condition que ce consentement soit tracé et révocable.

Le tableau ci-dessous synthétise les contrôles que l’ACPR peut auditer à chaque étape du traitement algorithmique d’une demande de substitution d’assurance :

{
  "demande_id": "IMM-2026-00471",
  "type_evenement": "substitution_assurance_emprunteur",
  "date_reception": "2026-07-15T09:32:11Z",
  "score_equivalence_garanties": 87,
  "seuil_acceptation": 80,
  "donnees_dsp2_utilisees": true,
  "consentement_dsp2_id": "CONS-DSP2-88821",
  "decision": "ACCEPTE",
  "modele_version": "v3.4.1",
  "auditeur_interne": "Comite_Modeles_2026Q2",
  "log_immuable": true
}

Implications pratiques : intégrer ces contrôles dans un middleware IA de crédit immobilier

Automatisation, Open Banking et conformité ACPR by design

Pour un middleware IA opérant en production sur des dossiers de crédit immobilier, l’enjeu est de rendre ces contrôles natifs et non contournables. Cela passe par une architecture en couches : une couche de collecte de données (intégrant les flux DSP2 avec gestion du consentement), une couche de scoring (modèle versionné et gelé à chaque décision), et une couche d’audit (logs immuables, exportables en format structuré pour l’ACPR). Chaque appel API déclenchant une décision sur un changement d’assurance doit retourner un objet JSON incluant la version du modèle, le score d’équivalence et le motif de décision — exactement comme illustré dans l’exemple ci-dessus.

L’Open Banking via DSP2 offre ici un levier puissant : en agrégeant les flux de revenus et de charges de l’emprunteur en temps réel, le middleware peut recalculer le taux d’effort résiduel après substitution d’assurance, et vérifier que la nouvelle prime ne dégrade pas la solvabilité au-delà des seuils prudentiels. Ce calcul doit lui aussi être tracé et soumis à la même gouvernance de modèle que le scoring principal.

Enfin, la documentation technique du modèle (model card) doit être maintenue à jour et inclure : la liste des variables d’entrée, leur poids relatif, les résultats des tests de biais, les performances sur données de validation et la date de la dernière revue par le comité de modèles. C’est ce document que l’ACPR demandera en priorité lors d’un contrôle sur place ou sur pièces.

Questions fréquentes

Conclusion & Perspective 2027

D’ici 2027, la convergence entre les LLM de nouvelle génération et les pipelines RAG spécialisés en droit financier permettra aux middlewares de crédit de générer automatiquement la documentation réglementaire exigée par l’ACPR — model cards, rapports de biais, journaux de décision — en temps réel et dans un format directement exploitable par les inspecteurs. L’enjeu ne sera plus de produire la conformité après coup, mais de l’embarquer comme une sortie native de chaque décision algorithmique, transformant le contrôle ACPR d’une contrainte ponctuelle en un flux continu de supervision augmentée.

Sources utilisées

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