Convertir automatiquement SSIS en DBT : retour d’expérience

La conversion manuelle de packages SSIS en modèles DBT est un travail répétitif, coûteux et source d’erreurs. Un consultant senior traite en moyenne 3 à 5 packages par jour. Sur un patrimoine de 500 packages, cela représente 100 à 170 jours-homme de travail — soit 6 à 10 mois pour une équipe de 2 personnes. C’est pour cette raison que nous avons investi dans un convertisseur automatisé.

Comment fonctionne le convertisseur

Le convertisseur opère en trois étapes distinctes.

La première est le parsing du DTSX. Un fichier .dtsx est un XML propriétaire Microsoft qui décrit l’intégralité d’un package SSIS : les connexions aux sources et destinations, les Data Flow Tasks (les flux de données), les Control Flow Tasks (la logique de contrôle : boucles, conditions, containers), les variables et paramètres. Le parseur extrait cette structure et la convertit en une représentation intermédiaire (IR) indépendante du format source.

La deuxième étape est la traduction de la logique. Chaque composant SSIS est mappé vers son équivalent DBT/Snowflake. Une source OLE DB devient une référence à une table Snowflake (via un modèle source DBT). Un composant Derived Column devient une clause SQL dans un modèle de transformation. Un Conditional Split devient un CASE WHEN. Un Merge Join devient un JOIN. Et ainsi de suite pour la trentaine de composants SSIS les plus courants.

La troisième étape est la génération du code. Le convertisseur produit un projet DBT complet : les modèles SQL (staging, intermediate, marts), le fichier schema.yml avec les tests et la documentation, le dbt_project.yml avec la configuration, et les scripts d’orchestration Snowflake (TASK objects) pour remplacer SQL Server Agent.

Ce que le convertisseur gère bien

Les cas standards représentent 60 à 80% d’un patrimoine SSIS typique. Ce sont les packages qui font de l’extraction depuis une ou plusieurs sources SQL, appliquent des transformations classiques (jointures, filtres, agrégations, lookup, derived columns), et chargent le résultat dans des tables du datawarehouse. Ces packages sont convertis automatiquement avec un taux de succès élevé.

Le convertisseur gère aussi la traduction du T-SQL standard vers Snowflake SQL : les CTE (Common Table Expressions), les fonctions de fenêtrage (ROW_NUMBER, RANK, LAG/LEAD), les agrégations, les jointures complexes, et les blocs procéduraux simples.

Ce que le convertisseur ne gère pas (encore)

Les cas complexes nécessitent une intervention manuelle. Les Script Tasks en C# ou VB.NET (code .NET embarqué dans SSIS pour des logiques non standard) ne sont pas convertibles automatiquement. Les curseurs imbriqués en T-SQL, le SQL dynamique (EXEC sp_executesql avec des requêtes construites à la volée), et les blocs TRY/CATCH avec gestion de transactions complexes nécessitent une reprise manuelle.

Pour ces cas, le convertisseur génère un squelette commenté qui indique ce que faisait le composant SSIS et suggère une approche Snowflake. Le consultant senior n’a pas à repartir de zéro — il a un point de départ structuré.

Résultats observés

Sur les projets réalisés avec le convertisseur, les gains mesurés sont les suivants. Le temps de conversion est réduit de 60 à 70% par rapport à une réécriture manuelle. Le taux d’erreurs de conversion est de l’ordre de 2 à 3% (détectés et corrigés pendant la phase de validation parallèle). Le code généré est immédiatement exploitable dans un workflow CI/CD avec Git, tests automatisés et documentation auto-générée — ce que SSIS ne permettait pas nativement.

Le bénéfice le plus inattendu est la documentation. Chaque modèle DBT généré inclut un commentaire d’origine (« converti depuis le package SSIS XYZ, Data Flow Task ABC ») et des tests de base (not_null, unique, accepted_values). Pour la première fois, le patrimoine data est documenté et testable — deux propriétés que le legacy SSIS ne fournissait jamais.