Migration DataStage vers Semarchy xDI : le guide du freelance

Beaucoup de DSI héritent aujourd'hui d'un patrimoine IBM DataStage constitué sur dix ou quinze ans : des centaines de jobs, des séquences imbriquées, une logique métier dispersée entre les stages et les scripts d'ordonnancement. Le coût des licences, la rareté des compétences et l'envie de pousser la transformation dans la base de données amènent de plus en plus d'entreprises à évaluer Semarchy xDI (ex-Stambia). La question n'est alors plus « est-ce que c'est possible », mais « comment bascule-t-on sans casser la chaîne décisionnelle du lundi matin ». Voici ce qu'une migration DataStage vers Semarchy xDI implique réellement, les pièges qui coûtent cher, et la méthode que j'applique en tant que freelance sur ce type de chantier.

Deux philosophies d'intégration très différentes

La première erreur consiste à traiter cette migration comme une simple traduction outil à outil. DataStage est un ETL classique : les données transitent par un moteur d'exécution propriétaire qui réalise les transformations avant de charger la cible. Semarchy xDI est un ELT à génération de code : l'outil ne transporte pas la donnée, il génère du SQL (ou du code natif) exécuté par la base cible elle-même, à partir de composants réutilisables appelés templates.

Cette différence a des conséquences très concrètes. Un job DataStage lourd en stages de tri, d'agrégat et de lookup n'a pas d'équivalent « stage pour stage » : sa logique doit être repensée en ensembles SQL, ce qui est souvent bien plus performant, mais suppose de comprendre ce que le job faisait vraiment - pas seulement ce qu'il semblait faire. À l'inverse, les mécanismes de reprise sur erreur, de rejets et de journalisation, très codifiés dans DataStage, doivent être reconstruits avec les mécanismes propres à xDI (variables, actions, gestion des rejets par template).

Étape 1 : cartographier avant de convertir

Aucune migration sérieuse ne commence par l'ouverture du designer. Elle commence par un inventaire exhaustif du patrimoine existant, extrait des exports DSX ou du référentiel DataStage : liste des jobs et des séquences, sources et cibles réelles, paramètres, dépendances d'ordonnancement, fréquences d'exécution et volumétries.

Ce travail réserve presque toujours la même surprise : une part significative des jobs est morte ou redondante. Jobs de test laissés en production, traitements dont la cible n'est plus lue par personne, doublons issus d'une réorganisation ancienne. Croiser l'inventaire avec les logs d'exécution des douze derniers mois et l'usage réel des tables cibles permet souvent de sortir 20 à 40 % du périmètre avant même de commencer. C'est le meilleur euro investi du projet : chaque job non migré est un job qui ne sera jamais recetté, ni maintenu.

Étape 2 : construire le socle xDI avant les flux

La tentation est forte de migrer le premier job dès la première semaine. C'est presque toujours une erreur. Ce qui détermine le coût total d'une migration xDI, ce n'est pas le premier flux : ce sont les conventions posées avant lui.

• Métadonnées et modèles : reverse des schémas source et cible, nommage stable, gestion des environnements (dev / recette / production) par variables plutôt que par duplication de projets.
• Templates : choix des templates d'intégration standards, et surtout identification des rares cas qui justifient un template personnalisé. Un template maison mal maîtrisé est une dette technique qui survit dix ans.
• Journalisation et rejets : un schéma unique de logs et de rejets, appliqué à tous les flux, pour que l'exploitation sache lire n'importe quel traitement sans le connaître.
• Livraison : export des livrables xDI, versionnement Git et déploiement automatisé, idéalement via un pipeline Azure DevOps - le sujet le plus souvent oublié dans les migrations d'ETL, et celui qui fait la différence deux ans plus tard.

Étape 3 : migrer par lots, jamais en big bang

Le découpage qui fonctionne le mieux suit les domaines fonctionnels, pas la difficulté technique : un premier lot autoportant (par exemple les référentiels), puis les flux qui en dépendent. Chaque lot suit le même cycle : conversion, tests unitaires, double run, validation métier, bascule.

Le double run est la seule technique de recette réellement fiable sur une migration d'ETL : pendant plusieurs cycles, l'ancien job DataStage et le nouveau flux xDI tournent en parallèle sur les mêmes données, et l'on compare les cibles ligne à ligne. Les écarts découverts à ce moment-là sont précieux - ils révèlent presque toujours une règle métier implicite qui n'était écrite nulle part : un arrondi, un filtre de date, un traitement de valeur nulle hérité d'un correctif de 2014. Découvrir ces écarts en recette coûte une demi-journée ; les découvrir après la bascule coûte la confiance des utilisateurs.

Les pièges qui coûtent le plus cher

• Oublier l'ordonnanceur. Les dépendances entre jobs vivent souvent hors de DataStage, dans Control-M, un ordonnanceur maison ou des scripts shell. Migrer les flux sans migrer le plan d'exécution, c'est livrer une moitié de projet.
• Reproduire le ligne à ligne. Transposer une logique itérative DataStage en boucle xDI donne un flux lent et illisible. L'ELT se pense en ensembles ; c'est là que se gagnent les facteurs 10 sur les temps de traitement.
• Sous-estimer la base cible. Puisque la transformation s'exécute dans la base, la migration déplace la charge vers elle. Index, statistiques, partitionnement et fenêtres d'exécution doivent être revus - avec la même attention que les flux eux-mêmes.
• Ne pas transférer les compétences. Une migration réussie techniquement mais non transmise crée une dépendance. Le transfert de compétences vers l'équipe interne fait partie du chantier, pas de l'après-chantier.

Combien de temps, et avec quel profil ?

Sur les patrimoines que j'ai rencontrés, un flux standard (une à trois sources, une cible, transformations classiques) se convertit et se recette en une demi-journée à deux jours une fois le socle en place. Les flux complexes - logique métier dense, gestion d'historique, réconciliations - demandent naturellement plus. L'ordre de grandeur utile n'est donc pas « le nombre de jobs », mais le nombre de jobs réellement vivants après élagage, pondéré par leur complexité : c'est exactement ce que produit la phase de cartographie, et c'est ce qui permet de chiffrer honnêtement.

Côté profil, ce chantier demande une double compétence rare : connaître l'ETL de départ assez bien pour lire un job hérité sans documentation, et maîtriser xDI assez bien pour ne pas y reproduire les habitudes de l'ancien outil. C'est précisément le terrain que je couvre au quotidien - vous trouverez le détail dans mes articles sur le métier de consultant Semarchy xDI freelance et de développeur Stambia freelance, ainsi que sur ma page expertise.

Freelance ou intégrateur pour ce chantier ?

Une migration DataStage vers xDI est un chantier borné et très technique, dont la valeur tient à la connaissance fine des deux outils, pas au nombre d'intervenants. Passer par un freelance évite les couches d'intermédiaires : vous échangez directement avec la personne qui convertit les flux, le démarrage se compte en jours, et le budget correspond à du temps de production réel. Sur des périmètres importants, le modèle qui fonctionne le mieux reste un freelance expérimenté qui pose le socle, industrialise la conversion et forme l'équipe interne qui prendra le relais.

Télétravail et disponibilité

Ce type de mission se mène très bien à distance : cartographie sur exports, développements sur vos environnements, revues et démonstrations en continu. Je travaille en remote pour des entreprises partout en France, et je peux intervenir en présentiel dans les Hauts-de-France (Valenciennes, Lille, Douai, Cambrai, Maubeuge) quand le contexte le demande - ateliers de cadrage, comités de bascule, transfert de compétences.

En résumé

Migrer de DataStage vers Semarchy xDI n'est pas une traduction, c'est un changement de paradigme - de l'ETL à moteur vers l'ELT à génération de code. Les projets qui réussissent partagent quatre réflexes : cartographier et élaguer avant de convertir, poser le socle xDI avant le premier flux, migrer par lots avec un double run systématique, et traiter l'ordonnancement et la base cible comme des composants à part entière. Bien menée, cette migration ne se contente pas de remplacer un outil : elle réduit la facture, accélère les traitements et rend le patrimoine de flux enfin lisible.