La question que nous posent les PME luxembourgeoises sur ce sujet est presque toujours « Databricks est-il meilleur que DataStage ? ». Ce n'est pas la bonne question. Les deux plateformes traitent les données de manière fiable et continuent toutes deux d'être développées activement. La décision se joue ailleurs : sur le modèle de facturation, sur l'état réel de votre parc de jobs et sur la question de savoir qui exploitera la plateforme ensuite.

La migration se justifie si votre charge de traitement est fortement irrégulière et si votre équipe travaille déjà en SQL et en Python. Elle ne se justifie pas si vous exploitez un parc stable à charge constante et si votre compétence ETL repose sur quelques spécialistes DataStage.

Avant d'évaluer une migration, il faut savoir que les deux plateformes ont sensiblement bougé.

IBM n'a pas annoncé la fin de DataStage, bien au contraire. Le produit reste disponible selon trois modes d'exploitation : on-premises classique, au sein de Cloud Pak for Data, et désormais en service entièrement managé, avec une interface de conception dans le cloud et un plan d'exécution séparé permettant aux données de rester là où elles se trouvent. Si vous pensiez devoir migrer parce que le produit s'arrête, ce n'est pas le cas.

De son côté, Databricks a regroupé son offre d'ingénierie de données sous le nom Lakeflow : Lakeflow Connect pour l'ingestion, Lakeflow Jobs pour l'orchestration, Lakeflow Designer pour la préparation.

Une offre commerciale, un article ou une documentation interne qui emploie encore les anciens noms de produits n'est plus à jour – un critère utile pour juger la fraîcheur de toute proposition de prestataire qui arrive sur votre bureau.

C'est la question qui détermine la charge de travail, et elle est presque toujours posée trop tard.

Dans un environnement DataStage qui s'est construit au fil des années, une part importante des jobs est de fait à l'arrêt fonctionnel : ils alimentent des rapports que plus personne n'ouvre, remplissent des tables qu'aucune application ne lit, ou dupliquent la logique d'un projet abandonné depuis longtemps. Migrer ce parc sans l'auditer revient à payer la traduction d'une logique qui ne sert plus.

Avant de solliciter le moindre devis, établissez donc trois choses :

• Exécutions : quels jobs ont réellement tourné ces six derniers mois – et à quelle fréquence ?
• Consommateurs : quelles tables cibles sont vraiment lues par un rapport ou une application ?
• Doublons : quels jobs portent une logique identique ou quasi identique ?

La principale différence entre les deux plateformes n'est pas technique, elle est financière.

Databricks facture à l'usage, en DBU, à la seconde près, avec des conditions plus avantageuses en cas d'engagement de volume. La licence ETL classique repose au contraire sur la capacité : vous payez une configuration définie, que vous l'utilisiez pleinement ou non.

Le modèle le plus économique dépend uniquement de votre profil de charge. Si vos traitements se concentrent en pics – clôture mensuelle, activité saisonnière, analyse de campagne – et que l'infrastructure reste inutilisée entre-temps, le modèle par capacité vous fait payer en permanence le besoin de pointe. Le changement génère alors une économie réelle.

Si vos traitements tournent au contraire de façon régulière, l'effet s'inverse : à charge de base constante, la facturation à l'usage est rarement moins chère, et elle est plus difficile à budgéter. Pour une PME au budget informatique fixe, une facture mensuelle variable est un vrai inconvénient, souvent négligé dans l'enthousiasme pour l'élasticité.

Si vous prenez cette voie, prévoyez dès le premier jour des alertes budgétaires et une imputation des coûts par service – sinon vous découvrirez le volet financier à la première facture désagréable.

C'est là que les migrations échouent le plus souvent dans les PME, bien plus que sur la technique.

DataStage se développe graphiquement. Databricks s'utilise fondamentalement en SQL et en Python, même si des interfaces de préparation sans code existent désormais. Pour une équipe qui a modélisé graphiquement pendant des années, ce n'est pas un changement d'outil, c'est un changement de métier.

Concrètement, pour une structure de deux ou trois personnes sur le périmètre données, cela signifie : soit un budget de montée en compétence réelle – pas un séminaire de deux jours, mais un accompagnement projet sur plusieurs mois – soit un partenaire d'exploitation externe. Intégrez ce poste au budget de migration. Une plateforme que seul un prestataire externe comprend après la bascule n'a pas réduit votre dépendance, elle l'a déplacée.

Il existe des situations où nous déconseillons la migration – même si cela va à l'encontre de notre propre activité de projet :

• Parc stable, charge régulière, exploitation qui fonctionne. Une migration mobilise vos meilleurs profils pendant des mois. Ce budget est presque toujours mieux investi dans la qualité des données ou auprès des métiers.
• La compétence ETL repose sur une ou deux personnes. Le sujet n'est alors pas la plateforme mais votre risque RH. Cela se traite par la documentation et un second profil, pas par une nouvelle technologie.
• Le cadre réglementaire n'est pas clarifié. Dans le secteur financier luxembourgeois, l'externalisation vers des services cloud est soumise à des exigences prudentielles. Cette analyse se place en début de projet, pas à la fin.
• La douleur réelle est ailleurs. Très souvent, le problème n'est pas l'outil ETL mais l'absence de responsabilités sur les données, des référentiels hétérogènes ou des rapports auxquels personne ne fait confiance. Aucune plateforme ne corrige cela.

Si les trois questions plaident pour la migration, une approche par étapes a fait ses preuves, plutôt qu'une bascule à date fixe :

1. Inventaire et mise hors service de tous les jobs devenus inutiles.
2. Un périmètre métier délimité en pilote : porteur de valeur réelle, mais non critique.
3. Fonctionnement en parallèle avec réconciliation des résultats – l'ancien et le nouveau doivent produire les mêmes chiffres, faute de quoi vous perdez la confiance des métiers.
4. Reprise progressive des autres périmètres, chacun clôturé et documenté.
5. Arrêt de l'ancien environnement seulement lorsque les métiers font réellement confiance à la nouvelle plateforme.

Le fonctionnement en parallèle coûte temporairement double. C'est le prix de la possibilité d'arrêter le projet à tout moment – et pour une PME, cette option de repli vaut davantage que quelques mois de délai gagnés.

Deux points absents des comparatifs internationaux, mais déterminants pour les entreprises implantées ici.

Résidence des données. Vérifiez tôt dans quelle région s'effectue le traitement et où résident les métadonnées de la plateforme – pas seulement les données métier. Pour les entreprises servant le secteur financier ou public, ce n'est pas un détail : c'est souvent le critère qui détermine l'architecture.

Aides publiques. Les projets de digitalisation des PME sont éligibles à des programmes de soutien au Luxembourg, les prestations de conseil et de conception étant en général mieux couvertes que les coûts d'exploitation récurrents. Les noms de programmes et les taux évoluent – l'état actuel se consulte sur guichet.lu. Le calendrier est essentiel : la demande doit être déposée avant le début du projet. Migrer d'abord et demander ensuite ne donne droit à rien.

La migration de DataStage vers Databricks est une décision de gestion, pas une décision technique. Confrontez votre profil de charge au modèle de facturation, nettoyez votre parc de jobs avant toute demande de devis, et budgétez la montée en compétence de votre équipe comme un poste de projet à part entière. Si votre environnement actuel est stable et votre charge régulière, rester est la décision économiquement juste – même si elle est moins spectaculaire.

• IBM DataStage – présentation du produit et modes de déploiement
• Databricks – Data Engineering et Lakeflow
• Databricks – modèle tarifaire et DBU
• guichet.lu – Aides financières aux entreprises