Si vous lisez cet article, il y a de bonnes chances que votre organisation exploite des packages SSIS construits il y a 5, 10, voire 15 ans. Et vous vous posez la question que tous les DSI finissent par se poser : est-ce qu’on continue, est-ce qu’on migre, ou est-ce qu’il existe un entre-deux ?
La réponse courte : ça dépend. La réponse longue occupe le reste de cet article.
État des lieux : SSIS en 2026
SSIS n’est pas en fin de vie au sens strict. Il est toujours livré avec SQL Server 2022 et continuera de l’être tant que SQL Server existera. Microsoft n’a annoncé aucune dépréciation. Vous pouvez même exécuter des packages SSIS dans Azure via l’Azure-SSIS Integration Runtime (IR), une machine virtuelle managée qui fait tourner un moteur SSIS dans le cloud.
Mais « pas en fin de vie » ne veut pas dire « en bonne santé ». Le problème réel est ailleurs : SSIS ne reçoit plus d’investissement fonctionnel significatif de la part de Microsoft. Les innovations vont vers Fabric, Dataflow Gen2, Synapse Pipelines. SSIS est en mode maintenance — il fonctionne, il est supporté, mais il n’évolue plus.
Et surtout : le marché de l’emploi s’assèche. Les développeurs SSIS sont de plus en plus rares parce que les nouveaux profils data se forment sur Python, DBT, Spark — pas sur un outil graphique de 2005. Recruter un expert SSIS en 2026, c’est comme recruter un développeur COBOL : c’est possible, mais de plus en plus cher et de plus en plus long.
Les trois scénarios
Scénario 1 : Maintenir tel quel
Si votre environnement SSIS est stable, bien documenté, avec une dette technique maîtrisée (score inférieur à 30), et que vous avez encore des compétences internes ou un prestataire TMA fiable, il n’y a aucune urgence à migrer. SSIS continuera de fonctionner sur SQL Server 2022 jusqu’à au moins 2032 (fin de support étendu).
Ce scénario est viable à court et moyen terme (3-5 ans). Le risque à long terme est la dépendance croissante à des compétences rares et la distance grandissante avec les pratiques modernes (CI/CD, tests automatisés, documentation as code).
Indicateurs pour ce scénario : moins de 200 packages, dette technique faible, équipe interne compétente, pas de problème de performance, pas de pression budgétaire sur l’infrastructure.
Scénario 2 : Migrer intégralement vers le cloud
C’est le scénario que les cloud providers poussent — et pour cause, c’est dans leur intérêt commercial. La migration intégrale vers Snowflake/DBT ou Fabric fait sens quand le patrimoine SSIS est volumineux (500+ packages), que la dette technique est élevée, que les fenêtres de traitement nocturnes débordent, ou que les coûts d’infrastructure on-premise deviennent prohibitifs.
Le piège classique de ce scénario est de sous-estimer l’effort de validation. Convertir le code, même automatiquement, c’est 50-60% du travail. Les 40-50% restants, c’est valider que le nouveau système produit exactement les mêmes résultats que l’ancien — ou des résultats volontairement différents quand l’ancien avait des bugs.
Le piège du lift-and-shift : reproduire la logique SSIS à l’identique dans le cloud, c’est créer du code cloud qui pense comme du on-premise. Les packages SSIS s’exécutent séquentiellement. Snowflake et Fabric sont conçus pour la parallélisation. Si vous ne ré-architectez pas les flux, vous payez le cloud sans en tirer les bénéfices.
Scénario 3 : L’approche hybride
C’est le scénario que nous recommandons le plus souvent, et celui que les intégrateurs cloud ne vous proposeront jamais — parce qu’il génère moins de revenus qu’une migration complète.
Le principe : migrer les composants à forte dette technique ou à forte valeur ajoutée (flux critiques, problèmes de performance), tout en conservant les composants qui fonctionnent bien et pour lesquels la migration n’apporte pas de gain mesurable.
Concrètement, l’audit de patrimoine classe chaque package dans l’une de ces quatre catégories :
À migrer en priorité : packages critiques avec dette technique élevée ou problèmes de performance. Ils bénéficieront le plus d’une réarchitecture cloud.
À migrer plus tard : packages fonctionnels mais qui gagneraient à être modernisés. Pas de risque immédiat, mais un investissement rentable à moyen terme.
À conserver : packages simples, stables, bien documentés. Le coût de migration est supérieur au gain. Ils resteront sur SSIS tant que SQL Server est supporté.
À décommissionner : packages obsolètes — alimentés par des sources désactivées, produisant des tables que personne ne consulte. C’est souvent 15 à 25% du patrimoine. Les supprimer ne coûte rien et réduit immédiatement la surface de maintenance.
technique
technique
Comment décider : la matrice de décision
Plutôt que de choisir par intuition, nous utilisons une matrice à deux axes : la valeur métier du composant (est-il critique pour l’activité ?) et son niveau de dette technique (est-il fragile, lent, mal documenté ?).
Un composant à forte valeur métier et forte dette technique est un candidat évident à la migration prioritaire — c’est un risque opérationnel actif. Un composant à faible valeur métier et forte dette technique est un candidat au décommissionnement. Un composant à forte valeur et faible dette est un candidat à la conservation. Et un composant à faible valeur et faible dette… eh bien, on le laisse tranquille.
Cette matrice ne sort pas d’un PowerPoint — elle est alimentée par les données de l’audit automatisé. Le score de dette technique est calculé objectivement par le scanner. La valeur métier est validée avec les équipes du client lors d’un atelier de qualification.
Les erreurs les plus fréquentes
En accompagnant des dizaines de projets de ce type, nous observons trois erreurs récurrentes.
La première est de décider sans auditer. Beaucoup d’organisations décident de migrer (ou de ne pas migrer) sur la base d’impressions plutôt que de données. « On a beaucoup de packages » ne veut rien dire tant qu’on ne sait pas combien sont actifs, combien sont critiques, combien sont obsolètes.
La deuxième est de migrer sans ré-architecter. Reproduire la logique SSIS à l’identique dans DBT, c’est garder les problèmes du legacy avec les coûts du cloud. Si un package SSIS fait 15 appels séquentiels à des procédures stockées pour construire un cube, le traduire tel quel en DBT va produire 15 modèles exécutés séquentiellement — exactement le contraire de ce que DBT sait faire.
La troisième est de négliger la phase de décommissionnement. Les packages obsolètes ne font de mal à personne tant qu’ils tournent sans erreur. Mais ils consomment du compute, génèrent des alertes fantômes, et brouillent la compréhension du système. Les supprimer est le quickwin le plus sous-estimé de tout projet de modernisation.
Notre recommandation
Commencez par un audit. Pas un audit de 6 semaines par un cabinet qui va vous envoyer 4 consultants juniors. Un audit automatisé qui scanne votre code source en 48 heures et vous donne une vue objective de votre patrimoine : ce qui est actif, ce qui est mort, ce qui est fragile, ce qui est critique.
À partir de là, la décision se prend avec des données, pas avec des convictions. Et dans la plupart des cas, la réponse n’est ni « tout migrer » ni « ne rien toucher » — c’est un plan structuré qui traite chaque composant selon son profil de risque et de valeur.