Cycle de vie d'une politique de décision

Une politique de décision est la règle que le moteur applique aux dossiers d'un produit de crédit : exclusions, grille de score, zones d'issue et paramètres de l'institution. Dans NEXCLARA, une politique est une donnée versionnée, pas du code : chaque version est créée, simulée, soumise puis approuvée par une personne qui n'en est pas l'auteur, et elle ne change plus une fois soumise.

Les états d'une version

Pas à pas

1. Créer — la direction des risques crée une version depuis une grille de référence de la famille du produit. La version arrive en brouillon, paramètres vides : elle ne peut pas s'activer en l'état.

2. Paramétrer — l'institution saisit ses propres valeurs : seuil de complétude, plafond du produit, taux d'effort cible, durée maximale, bornes d'âge selon la grille… Chaque paramètre déclare son unité et ses bornes ; un taux se saisit en pourcentage. Les paramètres requis encore vides sont listés à l'écran.

3. Simuler — aucune version ne se soumet sans simulation. Deux modes ouvrent la soumission : un cas d'essai fictif, évalué par la version, dont l'écran rend le calcul détaillé ; et le rejeu des derniers dossiers évalués du produit, dans la limite d'un échantillon, qui compte les issues et les dossiers qui changeraient d'issue. Le cas d'essai n'est pas conservé : seul le résumé de la simulation l'est, et il ne contient que des comptes, jamais un dossier.

   Une simulation historique (Politiques › « Simulation historique ») complète ces deux modes sans changer l'état d'aucune version : elle gèle un jeu de dossiers déjà évalués (produit, période, critères), puis rejoue ce jeu sous une version candidate et sous une version de référence, et rend leur comparaison : transitions d'issue de l'une à l'autre, répartitions des scores, exclusions et revues forcées par motif, nombre de dossiers dont un facteur change de points (jamais les points). Le jeu, les deux versions, le moteur et les résultats sont empreintés ; la simulation peut être scellée, puis reconstituée à l'identique. L'effet sur les défauts est déclaré « non mesurable » : aucune donnée d'issue de crédit n'est importée.

4. Soumettre — la version est figée : définition, empreinte et auteurs ne changent plus. Une date d'effet peut être fixée ; elle n'est jamais dans le passé.

5. Approuver ou rejeter — l'approbateur de politique, qui n'est pas un auteur de la version, l'approuve après vérification renforcée de son second facteur, ou la rejette avec un motif codifié (paramètres inadaptés, simulation insuffisante, date d'effet inadaptée, autre) : la version rejetée revient alors au brouillon.

La règle « l'auteur n'approuve pas sa propre version » est vérifiée deux fois : par le service, et par une contrainte de la base de données elle-même.

Les points de la grille

Les points de chaque tranche de la grille sont réservés aux personnes qui conçoivent, approuvent ou auditent la politique. Un analyste voit les points obtenus par un dossier et les facteurs qui ont compté, pas le barème complet qui lui permettrait d'ajuster une saisie.

Ce qui est encore en construction

• Aucun motif n'est recueilli à la soumission ni à l'approbation d'une version : l'auteur et la date sont enregistrés, le motif de la modification ne l'est pas encore.
• Aucun éditeur des points, des zones ou des pondérations : l'institution fixe ses paramètres ; la structure de la grille de référence ne se modifie pas depuis l'interface.
• La simulation compte des dossiers et des changements d'issue ; elle ne calcule aucun montant ni aucun volume d'encours.
• La comparaison porte sur deux versions rejouées sur un même jeu gelé (simulation historique) ; deux simulations différentes ne se comparent pas entre elles, et aucune contrainte ne lie encore deux paramètres (par exemple un âge minimal inférieur à l'âge maximal).

Voir aussi Grilles de référence et Moteur de décision.