De DataStage à Kestra : ce qui change vraiment dans l'orchestration data
Presque 20 ans passés dans l'univers DataStage. C'est assez pour avoir une opinion sur ce que « moderniser l'orchestration data » veut dire concrètement.
Dans les architectures ETL classiques, la logique se répartissait sur deux niveaux. Les Sequence Jobs DataStage géraient les dépendances internes et l'enchaînement des traitements. Au-dessus, un ordonnanceur d'entreprise portait le plan batch global, les calendriers, les contraintes d'exploitation. Ce modèle était robuste, industriel, et il a fait tourner des systèmes critiques pendant des années.
Mais la logique d'un flux finissait éparpillée entre un job DataStage, un Sequence Job, un script shell, une règle dans l'ordonnanceur et une documentation rarement à jour. Reprendre un traitement ancien, c'était d'abord reconstituer une intention.
Pourquoi ce job est-il lancé à cette heure-là ? Que se passe-t-il si cette étape échoue ? Le rejet est-il technique ou fonctionnel ?
Tous ceux qui ont exploité des chaînes data critiques connaissent ces questions.
Le paradigme déclaratif
Avec Kestra, le paradigme évolue. Les workflows sont déclaratifs, versionnés en YAML, lisibles. Scripts Python, SQL, API, dbt, Snowflake, contrôles qualité : tout se pilote dans un même cadre. Un workflow décrit une intention d'exécution, pas seulement une séquence de tâches.
Adopter Kestra ne signifie pas pour autant supprimer l'ordonnanceur d'entreprise. Dans beaucoup de SI, Control-M, VTOM ou Dollar Universe gardent une vraie valeur : vision globale du plan batch, dépendances inter-applicatives, contraintes d'exploitation au-delà du seul périmètre data. Le bon équilibre que je rencontre le plus souvent : l'ordonnanceur garde la vision transverse du SI, Kestra porte l'orchestration détaillée des chaînes data, et l'architecture clarifie les responsabilités entre les deux.
Les fondamentaux ne changent pas
Les fondamentaux, eux, n'ont pas changé. Gérer les dépendances, tracer les exécutions, prévoir les reprises sur erreur, distinguer incident technique et rejet fonctionnel, rendre les chaînes maintenables pour ceux qui les exploiteront après vous. La modern data stack rend ces enjeux plus visibles, pas moins importants. Les architectures distribuées multiplient les points de coordination. Sans orchestration claire, on ne modernise pas. On déplace la complexité.
Ce que l'expérience des ETL historiques nous a appris reste précieux. Kestra apporte une manière plus ouverte et plus lisible de traiter les mêmes enjeux.
Les outils changent. Les fondamentaux restent.
Un retour d'expérience à confronter ?
Vos chaînes data, vos choix d'orchestration — échangeons.