Récupérer des bulletins de salaire via une API impose un consentement explicite, granulaire et révocable, conforme au RGPD (Règlement UE 2016/679) et aux exigences de la DSP2. Ce consentement doit être collecté avant tout appel API, tracé de bout en bout, et intégré nativement dans l’architecture middleware du dossier de crédit immobilier. Sans ce socle juridique, la donnée collectée est irrecevable et expose l’établissement à des sanctions ACPR.
L’intelligence du crédit de demain basée sur la finance comportementale, disponible aujourd’hui.
Cadre réglementaire : RGPD, DSP2 et crédit immobilier
Les bases légales applicables à la collecte de données salariales
Les bulletins de salaire constituent des données personnelles à caractère financier au sens de l’article 4 du RGPD (Règlement UE 2016/679). Leur collecte automatisée via une API — qu’il s’agisse d’un agrégateur bancaire ou d’un connecteur RH — requiert une base légale explicite. Dans le contexte du crédit immobilier, régi par les articles L313-1 et suivants du Code de la consommation (Légifrance), la base légale retenue est généralement l’exécution d’un contrat (art. 6.1.b RGPD) combinée au consentement explicite (art. 6.1.a) lorsque la collecte dépasse le strict nécessaire à l’instruction du dossier.
La DSP2 (Directive UE 2015/2366, transposée en droit français par l’ordonnance n°2017-1252) encadre quant à elle les services d’initiation de paiement et d’information sur les comptes (AISP). Un agrégateur récupérant des relevés ou des données de paie doit être enregistré auprès de l’ACPR et recueillir un consentement fort, distinct de celui du contrat de prêt. La Banque de France et l’ACPR précisent dans leurs textes de supervision que ce consentement doit être libre, spécifique, éclairé et univoque — quatre critères cumulatifs directement issus du RGPD.
En pratique, pour un middleware de crédit immobilier, la chaîne de consentement doit couvrir : (1) l’accès aux données de paie brutes, (2) leur traitement algorithmique aux fins de scoring, (3) leur transmission éventuelle à des partenaires bancaires tiers. Chaque finalité doit faire l’objet d’une case à cocher distincte, non pré-cochée.
Mécanisme concret : architecture du consentement dans un pipeline API
Flux de collecte, stockage et révocation du consentement
L’implémentation technique du consentement dans un pipeline API de récupération de bulletins de salaire s’articule autour de quatre étapes séquentielles : présentation de la notice d’information, recueil du consentement signé électroniquement (horodatage qualifié eIDAS), émission d’un token de consentement (consent token) transmis à chaque appel API, et mécanisme de révocation en temps réel. Le consent token doit avoir une durée de vie limitée — généralement 90 jours maximum pour les AISP selon les orientations EBA — et être invalidé immédiatement sur demande de l’utilisateur.
Le tableau ci-dessous synthétise les paramètres clés à implémenter selon le type d’accès API :
| Type d’accès API | Base légale RGPD | Durée max. du consentement | Révocation | Obligation ACPR |
|---|---|---|---|---|
| Agrégateur AISP (relevés bancaires) | Art. 6.1.a — Consentement explicite | 90 jours (orientations EBA) | Temps réel, sans frais | Enregistrement ACPR obligatoire |
| Connecteur RH / paie (bulletins PDF) | Art. 6.1.b — Exécution contrat + 6.1.a | Durée instruction dossier | Avant décision finale | Mention dans FISE (fiche info standardisée) |
| Scoring algorithmique interne | Art. 6.1.f — Intérêt légitime (si documenté) | Durée de conservation légale (5 ans) | Droit d’opposition art. 21 RGPD | Analyse d’impact (AIPD) recommandée |
| Transmission à banque partenaire | Art. 6.1.a — Consentement explicite distinct | Ponctuelle, par opération | Avant transmission effective | Clause contractuelle DPA obligatoire |
{
"consent_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"user_id": "USR-20260716-00421",
"scope": ["payslip:read", "scoring:process"],
"granted_at": "2026-07-16T09:00:00Z",
"expires_at": "2026-10-14T09:00:00Z",
"revocable": true,
"legal_basis": "GDPR_6_1_a",
"dsp2_aisp_registered": true,
"acpr_ref": "ACPR-AISP-2024-XXXX"
}Implications pratiques pour le middleware et l’automatisation
Intégrer le consentement comme composant natif du pipeline de scoring
Dans une architecture middleware orientée crédit immobilier, le consentement ne doit pas être une étape manuelle périphérique : il doit être un composant de premier ordre, exposé comme microservice dédié (Consent Management Service). Ce service émet, valide et révoque les consent tokens de manière synchrone avec chaque appel à l’API de récupération des bulletins. Toute requête sans token valide doit retourner un code HTTP 403 avec un corps d’erreur normalisé indiquant l’absence ou l’expiration du consentement.
Du point de vue de l’Open Banking, l’alignement avec le standard Berlin Group (NextGenPSD2) ou UK Open Banking permet d’interopérer avec les banques partenaires sans redévelopper la couche de consentement pour chaque établissement. Le middleware doit stocker un journal d’audit immuable (append-only log) de chaque événement de consentement — collecte, renouvellement, révocation — pour répondre aux exigences de traçabilité de l’ACPR lors d’un contrôle sur place. Ce journal constitue également la preuve opposable en cas de litige avec l’emprunteur sur l’utilisation de ses données salariales.
Enfin, l’intégration d’un LLM dans le pipeline de scoring soulève une question spécifique : si le modèle est entraîné ou affiné (fine-tuning) sur des bulletins de salaire réels, une anonymisation irréversible préalable est impérative, faute de quoi chaque inférence constitue un traitement de données personnelles soumis à l’ensemble des obligations RGPD — y compris le droit à l’effacement (art. 17), techniquement incompatible avec un modèle entraîné sans mécanisme de machine unlearning.
Questions fréquentes
Le consentement RGPD suffit-il pour récupérer des bulletins de salaire via une API dans le cadre d’un crédit immobilier ?
Non, le consentement RGPD (art. 6.1.a) est nécessaire mais pas toujours suffisant. Si l’API passe par un agrégateur bancaire de type AISP, celui-ci doit également être enregistré auprès de l’ACPR conformément à la DSP2. Les deux cadres sont cumulatifs et non alternatifs.
Quelle est la durée maximale de validité d’un consentement pour un accès AISP aux données financières ?
Les orientations de l’EBA (Autorité Bancaire Européenne) fixent à 90 jours la durée maximale d’un consentement pour les services d’information sur les comptes (AISP), après quoi une réauthentification forte de l’utilisateur est requise.
Comment implémenter techniquement la révocation du consentement dans un pipeline API ?
La révocation doit être possible en temps réel, sans frais pour l’utilisateur. Techniquement, elle se traduit par l’invalidation immédiate du consent token dans le Consent Management Service, le retour d’un HTTP 403 sur tout appel ultérieur, et l’inscription de l’événement dans le journal d’audit immuable.
Un LLM entraîné sur des bulletins de salaire réels est-il compatible avec le droit à l’effacement RGPD ?
C’est un point de friction majeur : le droit à l’effacement (art. 17 RGPD) est techniquement difficile à satisfaire sur un modèle entraîné sans mécanisme de machine unlearning. L’anonymisation irréversible des données avant entraînement est la solution recommandée pour sortir du champ d’application du RGPD.
Conclusion & Perspective 2027
D’ici 2027, la convergence entre les API Open Finance (extension de la DSP2 vers les données salariales et fiscales dans le cadre du règlement FIDA en cours de finalisation au niveau européen), les LLM multimodaux capables d’analyser des bulletins PDF en temps réel, et les Consent Management Platforms (CMP) de nouvelle génération devrait permettre une gestion entièrement automatisée du cycle de vie du consentement. Les middlewares de crédit immobilier intégreront des agents IA capables de détecter proactivement l’expiration d’un consent token, de solliciter son renouvellement via une notification push, et de suspendre automatiquement le pipeline de scoring jusqu’à confirmation — le tout sans intervention humaine, tout en restant auditables par l’ACPR à chaque étape.