Alertes & observabilité métier

Pourquoi

Un dossier de financement ou une garantie peuvent se dégrader silencieusement — une assiette devenue insuffisante, une formalité en retard, une inspection négative. Ce processus détecte ces situations tôt et les porte au bon interlocuteur, sans jamais laisser la démonstration commerciale se mélanger à la réalité opérationnelle.

Comment dans l'application

Deux familles d'alertes couvrent, d'une part, les sûretés et le collatéral (péremption d'inscription, échéance non encaissée, gage potentiellement multiple, mainlevée non effectuée, formalité incomplète ou en retard, configuration juridique non validée, risque de procédure collective, contrôle de terrain négatif, inspection en retard, mandat échéant ou échu, source de coût périmée) et, d'autre part, le servicing du financement institutionnel (offre expirante, conditions suspensives ouvertes, facilité échéante, tirage en attente, échéance à venir ou en retard, assiette insuffisante, décaissement en attente, rapprochement divergent). Chaque alerte porte une sévérité (information, avertissement, critique) et un statut (ouverte, prise en compte, résolue, ou supprimée — jamais effacée : une alerte supprimée reste une décision humaine tracée que le moteur respecte).

Cloisonnement démo/réel. Le tenant retenu pour classer une alerte ou une métrique vient toujours du jeton d'authentification, jamais d'un en-tête envoyé par l'appelant qui pourrait être falsifié. Un tenant dont la classe n'est pas connue compte par défaut comme démonstration — jamais comme réel, ce qui serait le repli dangereux. Pour les institutions, l'axe démonstration vit sur l'espace financeur lui-même plutôt que sur le tenant technique, parce qu'une banque de démonstration existe malgré tout comme tenant réel sur la plateforme ; les agrégats de pilotage excluent donc explicitement les institutions de démonstration de leur périmètre réel, sauf demande contraire explicite.

Garde-fous

• Le vocabulaire des types d'alertes est verrouillé jusqu'en base de données par une contrainte explicite, pour qu'un type d'alerte déclaré côté applicatif mais non reconnu par cette contrainte ne puisse jamais être écrit silencieusement — un tel écart, déjà constaté et corrigé, a empêché plusieurs types d'alertes d'être enregistrés jusqu'à sa correction.
• Aucune alerte mutualisée au niveau du réseau ne peut porter une donnée commerciale sensible (taux, quotité, marge, montant, score, éléments KYB) — la confidentialité est vérifiée avant l'écriture, pas après.
• Une alerte n'est jamais supprimée définitivement : sa résolution ou sa suppression reste un événement conservé dans l'historique du dossier.