Intégrez vos contraintes métiers avec des vérifications personnalisées

L’équipe Risque de la banque a étudié votre rapport avec la plus grande attention. Grâce à la métrique sur-mesure "Credit Gain" que vous avez intégrée au chapitre précédent, ils ont pu constater noir sur blanc que l'exactitude rassurante de ~95 % de votre modèle de régression logistique masquait en réalité une perte virtuelle désastreuse de 423 unités financières.

Face à ce constat, l'équipe Risque souhaite désormais instaurer des garde-fous stricts : aucun modèle ne doit pouvoir être validé s’il génère une perte financière.

Vous savez déjà calculer ces contraintes, mais il faut maintenant automatiser cette vérification pour qu'elle devienne une règle incontournable dans votre processus. Dans ce chapitre, vous allez apprendre à transformer vos règles métiers en véritables alarmes automatisées grâce aux vérifications personnalisées (Custom Checks) de Skore.

Définissez une classe de vérification personnalisée

Jusqu'à présent, vous deviez regarder manuellement le score de votre métrique "Credit Gain" et déduire par vous-même si le résultat était acceptable. Mais dans un environnement de production où des dizaines de modèles sont entraînés, l'analyse manuelle est source d'erreurs.

Pour automatiser ce contrôle, Skore met à votre disposition un protocole Python nommé Check. En créant une classe qui hérite de ce protocole, vous pouvez dicter à Skore comment analyser votre modèle et sous quelles conditions déclencher une alerte de santé (une Issue).

Pour qu'un test personnalisé soit valide, il doit comporter certaines métadonnées obligatoires :

• Un code unique (par exempleCSTM001) pour l'identifier facilement.

• Un titre descriptif.

• Une sévérité, qui peut être définie sur"issue"(problème bloquant à corriger) ou"tip"(simple conseil ou point de vigilance).

• La méthode check(), qui contient la logique mathématique ou métier de votre vérification.

Vous allez apprendre à structurer une vérification personnalisée en utilisant le protocole Check de Skore. Vous allez découvrir comment coder concrètement la règle imposée par l'équipe Risque : déclencher une alerte automatique si le modèle engendre une perte financière (c'est-à-dire si le Credit Gain est inférieur à zéro).

Dans cette vidéo, vous avez vu comment encapsuler une règle financière stricte au sein d'une classe Python standardisée par Skore. Vous avez désormais transformé une consigne métier ("ne perdez pas d'argent") en une vérification algorithmique systématique. Il est maintenant temps d'appliquer cette vérification à votre rapport !

Je vais vous montrer à présent comment instancier vos classes de vérification et les intégrer à l'écosystème Skore. Vous allez découvrir comment déclencher un audit complet de votre algorithme, via la méthode.checks.add().

Grâce à l'intégration de vos vérifications via.checks.add(), le diagnostic de Skore ne se contente plus de repérer le sous-apprentissage. Il lève désormais un drapeau rouge si votre modèle vous fait perdre de l'argent. Apprenons maintenant à interpréter globalement ces résultats pour décider de la marche à suivre.

Interprétez les résultats de la vérification personnalisée

L'automatisation des diagnostics métiers et réglementaires marque une étape charnière dans votre projet. Elle vous permet de confronter directement la théorie mathématique de votre modèle à la réalité du terrain.

Lorsqu'une alerte personnalisée se déclenche, elle annule instantanément toutes les conclusions hâtives que l'on pourrait tirer des métriques globales. Vous vous rappelez de votre exactitude à ~95 % ? Elle n'a désormais plus aucune importance face aux alertes levées par l'outil.

L'interprétation de ces vérifications est le pont indispensable entre l'équipe Data et la direction. C'est en lisant ces résultats que vous justifiez techniquement la nécessité d'allouer plus de temps ou de ressources pour retravailler un algorithme.

L'objectif de cette vidéo est d'apprendre à synthétiser les informations remontées par les vérifications personnalisées afin de poser un diagnostic clair sur l'état de votre modèle. Vous verrez comment formuler un plan d'action pour résoudre les blocages identifiés.

Vous savez maintenant interpréter les résultats de vos vérifications pour statuer formellement sur l'invalidité d'un modèle. Les garde-fous que vous avez mis en place fonctionnent parfaitement. Il est temps pour vous de mettre les mains dans le code et de configurer ces blocages de sécurité par vous-même !

À vous de jouer !

Contexte

Votre métrique métier a convaincu la direction, et votre régression logistique reste sous surveillance permanente. Mais un tableau de bord ne sert à rien si quelqu'un doit encore le lire à l'œil nu avant chaque mise en production. L'équipe Risque vous demande d'aller plus loin, en gravant une règle financière simple dans le processus de validation lui-même : aucun modèle ne doit être recommandé s'il fait perdre de l'argent à la banque.

Dans cet exercice, vous allez :

• compléter une classe métier qui hérite du protocoleCheckdeskore,

• y encoder une règle financière non négociable à partir d'une métrique déjà construite,

• greffer cette vérification à un rapportskoreviareport.checks.add,

• lire le verdict dansreport.checks.summarize()et conclure sur la mise en production.

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import confusion_matrix, make_scorer
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from skore import evaluate

home_loans = pd.read_csv("home_loans.csv")
target = home_loans["defaut"]
data = home_loans.drop(columns="defaut")

scaled_model = make_pipeline(StandardScaler(), LogisticRegression())
report = evaluate(scaled_model, data, target, splitter=0.2)


def strict_business_gain(y_true, y_pred):
    tn, fp, fn, tp = confusion_matrix(y_true, y_pred).ravel()
    return tn * 1 + fp * (-1) + fn * (-10) + tp * 0


strict_gain_scorer = make_scorer(strict_business_gain, greater_is_better=True)
report.metrics.add(strict_gain_scorer, name="Strict Credit Gain")
report.metrics.summarize()

Consigne

La classe ci-dessous encode le protocoleCheckdeskore, celui-là même utilisé dans la vidéo précédente pour détecter un écart de performance entre groupes sensibles. Elle est incomplète, chaque...marque une information manquante.

1. Renseignez les métadonnées manquantes, un code unique et un niveau de sévérité, puis terminez la méthodecheck_functionpour qu'elle renvoie un message d'alerte explicite quand le Credit Gain est négatif, etNonesinon.

2. Instanciez cette vérification et ajoutez-la au rapport avecreport.checks.add.

3. Affichezreport.checks.summarize()et repérez dans quelle section, Issues, Tips ou Passed, apparaît votre nouveau check.

4. Concluez, en 2 ou 3 phrases, sur la mise en production de ce modèle.

En résumé

• Le protocoleCheckde Skore permet d'encapsuler vos règles métiers complexes (financières ou réglementaires) au sein d'une classe Python standardisée.

• Chaque vérification personnalisée requiert des attributs obligatoires : un code unique, un titre, une méthodecheck(), et un niveau de sévérité ("issue"ou"tip").

• La méthode.checks.add()permet de greffer définitivement vos règles métiers à un rapport Skore pour qu'elles soient évaluées automatiquement lors de chaque diagnostic.

• Un diagnostic métier automatisé empêche le déploiement d'algorithmes qui, bien que présentant une bonne exactitude statistique, seraient financièrement déficitaires.

• L'accumulation d'alertes natives (comme le sous-apprentissage) et d'alertes métiers justifie techniquement la nécessité d'abandonner un modèle simpliste au profit d'une approche algorithmique plus poussée.

Maintenant que vous avez mis en place un filet de sécurité impénétrable autour de votre projet, rendez-vous dans le chapitre suivant pour apprendre à riposter : vous allez entraîner un modèle plus performant, ajuster son seuil de décision et comparer vos rapports pour enfin atteindre la rentabilité !