Comment modéliser en JSON la règle HCSF de 35% pour un profil avec un prêt in fine ?

La règle HCSF impose un taux d’effort maximal de 35 % assurance comprise (Décision D-HCSF-2021-7), applicable y compris aux prêts in fine dont seuls les intérêts sont remboursés mensuellement. Modéliser cette contrainte en JSON nécessite de distinguer la mensualité théorique (intérêts + assurance) du capital différé, et d’intégrer le flag dérogatoire prévu par la même décision pour les 20 % de dossiers hors norme.

Cadre réglementaire : la règle HCSF 35 % et le prêt in fine

Ce que fixe la Décision D-HCSF-2021-7

La Décision contraignante D-HCSF-2021-7 du Haut Conseil de Stabilité Financière, publiée au Journal officiel et disponible sur Légifrance, fixe deux critères cumulatifs d’octroi : un taux d’effort maximal de 35 % des revenus nets, assurance emprunteur comprise, et une durée de remboursement plafonnée à 25 ans (27 ans en cas de différé d’amortissement lié à l’acquisition dans le neuf). Ces seuils s’appliquent à l’ensemble des crédits immobiliers à la résidence principale, sans exception de structure de prêt.

Le prêt in fine constitue un cas particulier : l’emprunteur ne rembourse que les intérêts pendant toute la durée du crédit, le capital étant restitué en une seule fois à l’échéance. Le taux d’effort mensuel est donc calculé sur la base des intérêts périodiques + prime d’assurance, sans amortissement du capital. Cette mécanique allège la mensualité apparente mais ne dispense pas du respect du seuil de 35 %, tel que rappelé par le Ministère de l’Économie dans la présentation officielle des mesures HCSF.

L’ACPR, dans ses publications et rapports d’études, souligne que les établissements de crédit doivent documenter précisément le calcul du taux d’effort pour chaque dossier, y compris pour les structures atypiques comme l’in fine, sous peine de sanction prudentielle. La modélisation JSON d’un tel profil doit donc être exhaustive et auditable.

Mécanisme de calcul et structure JSON pour un prêt in fine

Décomposition des champs obligatoires du modèle de données

Pour un prêt in fine, le calcul du taux d’effort se résume à :

taux_effort = (interets_mensuels + prime_assurance_mensuelle)/revenus_nets_mensuels.

Le capital n’entre pas dans le numérateur. Le modèle JSON doit exposer chaque composante de façon atomique pour permettre l’audit automatisé par un middleware ou un moteur de règles métier. Le champ derogation_hcsf permet de tracer l’utilisation du quota de 20 % de dossiers dérogatoires autorisés par la Décision D-HCSF-2021-7.

{
  "type_pret": "in_fine",
  "capital_emprunte": 250000,
  "taux_nominal_annuel": 3.85,
  "duree_mois": 240,
  "interets_mensuels": 802.08,
  "prime_assurance_mensuelle": 62.50,
  "mensualite_hcsf": 864.58,
  "revenus_nets_mensuels": 3200,
  "taux_effort_calcule": 27.02,
  "seuil_hcsf": 35,
  "conforme_hcsf": true,
  "derogation_hcsf": false,
  "reference_reglementaire": "D-HCSF-2021-7",
  "date_calcul": "2026-07-15"
}

Implications pratiques : intégration dans un middleware et Open Banking

Automatiser la règle HCSF via API et moteur de scoring

Un middleware de crédit immobilier peut exposer ce schéma JSON comme contrat d’interface (OpenAPI / JSON Schema) entre le front applicatif et le moteur de règles métier. Chaque champ atomique — notamment interets_mensuels, prime_assurance_mensuelle et revenus_nets_mensuels — peut être alimenté en temps réel par les flux Open Banking issus du cadre DSP2, dont le référentiel technique est publié par la Banque de France. Les relevés de compte agrégés permettent de calculer les revenus nets observés sur 12 mois glissants, réduisant le risque de déclaration inexacte.

Le champ dérogation HCSF joue un rôle stratégique : il doit être piloté par un compteur de quota au niveau de l’établissement prêteur. La Banque de France publie trimestriellement les statistiques d’utilisation de ce quota dérogatoire (20 % de la production, dont au moins 80 % réservés à l’acquisition de résidence principale). Un middleware intelligent peut interroger ces données agrégées pour anticiper la saturation du quota et orienter dynamiquement les dossiers in fine — structurellement plus risqués en cas de dépréciation de l’actif nanti — vers la file dérogatoire ou vers un refus motivé.

L’ACPR recommande par ailleurs que les modèles d’IA utilisés dans le scoring de crédit soient explicables et auditables. La structure JSON proposée ici répond à cette exigence : chaque décision (conforme_hcsf) est traçable jusqu’à ses composantes élémentaires, ce qui facilite la production des rapports prudentiels et la réponse aux demandes d’explication des emprunteurs.

Conclusion & Perspective 2027

D’ici 2027, les middlewares de crédit immobilier intégreront nativement des LLM capables de générer et valider dynamiquement des schémas JSON conformes à la réglementation HCSF en vigueur, en interrogeant en temps réel les flux DSP2 pour les revenus et les API de la Banque de France pour les statistiques de quota. Pour les prêts in fine, la modélisation JSON deviendra le standard d’échange entre courtiers, banques et régulateurs, permettant un audit automatisé bout-en-bout et une réduction drastique des délais d’instruction — de plusieurs semaines à quelques heures.

Sources utilisées

• Décision D-HCSF-2021-7 — Conditions d’octroi de crédits immobiliers
• HCSF — Mesure relative à l’octroi de crédits immobiliers
• Banque de France — Statistiques sur les crédits immobiliers
• Banque de France — API Open Banking et DSP2
• ACPR — Publications, rapports et études