Orchestrer des traitements entre projets

Sur cette plateforme, les chaînes n'appartiennent pas toutes au même projet Dataiku. Un projet produit un référentiel, un autre le consomme pour un scoring, un troisième croise les deux. Il faut coordonner des exécutions qui ne partagent ni le même propriétaire ni le même calendrier.

Le piège des dépendances implicites

La méthode la plus répandue consiste à coordonner par les horaires : le projet B se lance à 4 h parce que le projet A finit « en général » vers 3 h 30. Ça marche jusqu'au jour où A dure plus longtemps. B part alors sur les données de la veille sans que rien ne le signale.

Ce type de dépendance est invisible dans la configuration : elle n'existe que dans la tête de la personne qui a choisi l'horaire. Quand cette personne change d'équipe, plus personne ne sait pourquoi le déclencheur est à 4 h.

Ce que j'ai mis en place

Des scénarios de lancement inter-projets, qui rendent la dépendance explicite : le projet aval est déclenché par la réussite effective du projet amont, pas par une heure. Quand la dépendance ne peut pas être exprimée directement, un contrôle vérifie la fraîcheur des données d'entrée avant de démarrer.

Diagnostiquer quand ça casse

L'autre moitié du travail est l'analyse de cause racine. Sur des chaînes longues, la panne visible est rarement la cause. Un job qui échoue en fin de parcours vient souvent d'un référentiel modifié trois étapes plus tôt, dans un projet différent.

Remonter le flow en comparant les volumétries à chaque nœud localise le problème bien plus vite que de commencer par lire les logs du job en échec.

Ce travail m'a aussi conduite à réconcilier des volumétries entre systèmes, pour vérifier qu'un même périmètre donnait les mêmes comptes de part et d'autre. C'est fastidieux, et c'est souvent là qu'on découvre des écarts de règles de gestion que personne n'avait documentés.