- Data
Migrer un patrimoine Talend : ce qu'il faut décider avant d'écrire une ligne
Une migration Talend échoue rarement techniquement. Elle échoue parce que personne n'a tranché ce qui devait être migré, ce qui devait être supprimé, et qui arbitre les règles de gestion.
· 4 min de lecture · AzerOps
Un patrimoine Talend de plusieurs centaines de jobs se migre en six à dix-huit mois. La partie technique n'est pas la plus difficile. La partie difficile consiste à décider ce qui mérite d'être migré, et à faire accepter cette décision.
La première question n'est pas technique
Avant de choisir dbt, Spark ou un ETL managé, il faut répondre à une question de gouvernance : qui a le droit de décider qu'un flux ne sera pas migré ?
Sans cette réponse, la migration devient une transposition à l'identique. Or dans un patrimoine ancien, une part importante des flux n'a plus de consommateur. Ils tournent chaque nuit, produisent des tables que personne n'interroge, consomment une fenêtre de traitement et créent des dépendances qui bloqueront la migration.
Les migrer coûte plusieurs mois de travail pour un bénéfice nul.
L'inventaire avant tout
Trois semaines suffisent généralement à produire l'inventaire réel : la liste des jobs, leur fréquence, leurs dépendances, et surtout le lignage jusqu'aux rapports effectivement consultés.
Le lignage est le point clé. Tant que vous ne savez pas quel tableau de bord dépend de quel flux, personne n'osera rien supprimer, et le patrimoine ne peut que grossir.
Pour retrouver les consommateurs réels, la méthode la plus fiable n'est pas de demander aux équipes — elles répondent par prudence que tout est utile — mais d'analyser les journaux d'accès de l'outil de restitution sur douze mois glissants. Un rapport ouvert zéro fois en un an n'a pas de consommateur, quoi qu'en dise l'organigramme.
Décider avant de construire
À l'issue de l'inventaire, classez chaque flux dans l'une de quatre catégories :
- Supprimer. Aucun consommateur identifié sur douze mois. C'est le gain le moins cher disponible.
- Migrer tel quel. Le flux est utile et sa logique est saine.
- Refondre. Le flux est utile mais sa logique a dérivé, ou il duplique un autre flux.
- Reporter. Le flux est utile mais son consommateur va disparaître dans l'année.
Faites valider ce classement par écrit, par une personne nommée. C'est cette validation qui vous protège quand quelqu'un réclame, huit mois plus tard, un flux supprimé.
La couche sémantique règle un problème plus ancien
La migration est l'occasion de traiter la cause des chiffres divergents entre rapports. Ce n'est presque jamais un bug : ce sont deux définitions métier différentes du même indicateur, chacune correcte dans son contexte d'origine.
Profitez de la migration pour faire trancher chaque définition par le contrôle de gestion et l'écrire dans la couche sémantique. C'est un travail ingrat qui produit plus de valeur perçue que la migration technique elle-même.
Le double run n'est pas optionnel
Ancien et nouveau pipeline tournent en parallèle sur la même fenêtre, avec un job de contrôle qui compare ligne à ligne et agrégat à agrégat. Tout écart bloque la bascule tant qu'il n'est pas expliqué.
Comptez quatre à huit semaines de double run selon la criticité. C'est la seule méthode qui donne une garantie réelle, et c'est aussi ce qui rend la bascule acceptable pour les équipes métier.
L'étape que tout le monde saute
Le décommissionnement. Éteindre formellement les anciens jobs, archiver, libérer les licences, retirer les droits d'accès. Sans cette étape, vous payez deux plateformes pendant trois ans et le patrimoine « ancien » continue discrètement de tourner.
Inscrivez le décommissionnement dans le périmètre contractuel du projet, avec un jalon de paiement associé. C'est le seul moyen fiable de s'assurer qu'il aura lieu.