01 · Alten · banque
Supprimer les relances manuelles d'un scénario mensuel de scoring
Un traitement mensuel critique qu'il fallait relancer à la main chaque fois que les socles amont n'étaient pas prêts. Reconstruction complète de la logique de contrôle.
- Garde-fou qui bloque proprement quand les socles ne sont pas disponibles
- Reprise automatique quotidienne jusqu'à disponibilité des données
- Arrêt en statut succès, pour ne pas générer de fausse alerte
- Notifications différenciées selon la situation rencontrée
Un scénario mensuel produisait des scores utilisés en aval par plusieurs chaînes. Il dépendait de socles de données alimentés par d'autres équipes, dont la disponibilité variait de quelques jours d'un mois à l'autre.
Quand les socles n'étaient pas prêts, le scénario échouait. Quelqu'un devait constater l'échec, attendre, puis relancer manuellement. Chaque mois.
Pourquoi l'échec n'était pas la bonne réponse
Un scénario qui échoue parce que ses données ne sont pas encore là envoie un signal faux. Ce n'est pas une anomalie : c'est un état d'attente parfaitement normal. Le traiter comme une erreur a deux effets, tous les deux mauvais.
D'abord ça pollue la supervision. Une alerte mensuelle attendue devient une alerte qu'on apprend à ignorer, et le jour où le scénario échoue pour une vraie raison, personne ne réagit différemment.
Ensuite ça impose une intervention humaine pour quelque chose qu'une machine sait très bien faire : vérifier si les données sont arrivées, et réessayer sinon.
Ce que j'ai reconstruit
- Garde-fou
- vérification de la disponibilité effective des socles avant tout traitement
- Sortie propre
- arrêt en statut succès si les données manquent, sans lever d'erreur
- Reprise
- relance automatique le lendemain via le déclencheur, jusqu'à disponibilité
- Notifications
- messages différenciés selon la situation : attente, succès, échec réel
- Amont en échec
- comportement sécurisé si un traitement amont a lui-même échoué
Le point le plus important est la distinction entre attendre et échouer. Le scénario s'arrête en succès quand il attend, ce qui laisse la supervision propre. L'échec reste réservé aux vraies anomalies.
Les notifications suivent la même logique. Un message « socles pas encore disponibles, nouvelle tentative demain » n'a pas la même valeur qu'un message d'erreur, et ne doit pas déclencher les mêmes réflexes chez celui qui le reçoit.
Ce que j'ai aussi corrigé au passage
Le déclencheur lui-même ne s'activait pas correctement, ce qui rendait la reprise automatique impossible même une fois la logique en place. C'est le genre de détail qui invalide tout le reste et qu'on ne voit qu'en testant le scénario complet, pas ses étapes une par une.
J'ai également revu le repositionnement du calendrier : après un vendredi, le traitement devait se replacer au mardi suivant, ce qui n'était pas le cas.
Résultat
Plus aucune relance manuelle dans le fonctionnement normal. Le scénario attend, réessaie, et ne prévient qu'en cas de vrai problème.
Les noms de projets, de tables et de systèmes internes ont été retirés. Les détails techniques sont réels.