Concevoir un scénario Dataiku qui anticipe les pannes

Un scénario Dataiku créé par défaut gère un seul cas : celui où tout se passe bien. Les données sont là, l'amont a réussi, le volume est normal. Dès qu'on sort de ce cas, le comportement par défaut est l'échec, et l'échec appelle un humain.

Sur un traitement qui tourne chaque nuit, ça veut dire qu'une personne devra intervenir régulièrement pour des situations parfaitement prévisibles.

Ce qui peut réellement mal tourner

Avant de coder quoi que ce soit, je liste les situations. Il y en a six qui reviennent sur presque tous les traitements.

Les six situations à prévoir

Données amont absentes: le socle n'est pas encore alimenté, mais il le sera
Amont en échec: le traitement qui produit les données a lui-même planté
Volume anormal: le traitement réussit mais produit dix fois moins de lignes que d'habitude
Exécution hors fenêtre: le scénario démarre trop tard pour que le livrable soit prêt à temps
Dépendance inter-projets: un projet aval attend un résultat qui n'arrivera pas
Déclencheur inactif: le scénario ne démarre pas du tout, et rien ne le signale

Les deux dernières sont les plus coûteuses, parce qu'elles ne produisent aucune erreur. Rien n'échoue, donc rien n'alerte.

Ce qu'on fait par défaut, et pourquoi c'est un problème

Par défaut, toutes ces situations aboutissent au même résultat : le scénario passe en échec. C'est confortable à écrire et coûteux à vivre.

Ça abîme la supervision. Une alerte récurrente et attendue devient une alerte qu'on classe sans lire. Le jour où le scénario échoue pour une vraie raison, le message se noie dans les précédents.

Ça impose une intervention humaine pour une tâche entièrement mécanique : regarder si les données sont arrivées, et relancer sinon.

Et ça ne couvre pas les pannes silencieuses. Un scénario qui ne démarre pas ne passe pas en échec. Il ne passe nulle part. Les données de la veille restent en place et les tableaux de bord affichent quelque chose de parfaitement cohérent.

La bonne pratique : trois états, pas deux

La distinction qui change tout est entre attendre et échouer. Attendre des données n'est pas une anomalie, c'est un état normal du système.

Trois états, trois comportements

Attendre: arrêt en statut succès, notification d'attente, nouvelle tentative au prochain déclenchement. Aucune alerte d'erreur.
Réussir: exécution normale, notification de succès, livrable diffusé.
Échouer: statut échec, alerte, intervention humaine. Réservé aux vraies anomalies.

Le garde-fou

Une première étape vérifie la disponibilité effective des données amont. Pas seulement l'existence de la table, mais la présence des données attendues pour la période visée. Si elles manquent, le scénario s'interrompt proprement, sans lever d'exception : dans une étape en code, une sortie explicite suffit.

La reprise

Un déclencheur quotidien relance le scénario. Tant que les données ne sont pas là, il s'arrête au garde-fou. Le jour où elles arrivent, il déroule normalement. Plus personne n'a besoin de surveiller.

Les notifications différenciées

Trois messages pour trois situations. Un message « en attente, nouvelle tentative demain » ne doit pas ressembler à un message d'erreur, sinon on retombe exactement dans le problème de départ.

Le délai maximal

C'est l'oubli le plus fréquent. Si les données n'arrivent jamais, le scénario réessaiera indéfiniment sans que personne ne s'en rende compte. Il faut un seuil au-delà duquel l'attente devient une vraie anomalie et déclenche une alerte.

Le contrôle de fraîcheur

Pour détecter les non-démarrages, on ne peut pas attendre un événement : il faut interroger l'état. Un scénario de supervision compare la dernière exécution réussie à un délai attendu. Au-delà, c'est une anomalie, même sans erreur.

Le superviseur ne doit pas dépendre de la chaîne qu'il surveille. S'ils partagent le même déclencheur, ils tombent ensemble et vous perdez la seule alerte utile.

Deux pièges à éviter

Confondre « pas encore arrivé » et « ne viendra pas ». Si l'amont a échoué, attendre ne sert à rien. Le garde-fou doit faire la différence, sinon vous attendez des données qui ne seront jamais produites.

Tester les étapes au lieu du scénario. J'ai déjà vu une logique d'attente parfaitement correcte rendue inutile parce que le déclencheur ne s'activait pas. Ce défaut ne se voit qu'en laissant tourner le scénario complet sur plusieurs jours.

Checklist avant de mettre un scénario en production

J'ai listé ce qui peut manquer en entrée, et le scénario le vérifie avant de travailler
L'attente se termine en succès, pas en échec
Une reprise automatique est en place, et j'ai vérifié que le déclencheur part vraiment
Les notifications distinguent attente, succès et échec réel
Un délai maximal transforme l'attente en anomalie
Un contrôle de fraîcheur externe détecte les non-démarrages
Le scénario de supervision ne dépend pas de la chaîne qu'il surveille
J'ai laissé tourner l'ensemble plusieurs jours avant de considérer que c'est fini