Votre patrimoine SSIS est-il sous contrôle ? L’approche par rétro-ingénierie

Combien de packages SSIS tournent dans votre organisation ? Si vous ne connaissez pas la réponse exacte, vous n’êtes pas seul. La majorité des DSI que nous rencontrons connaissent un ordre de grandeur (« quelques centaines ») mais pas le chiffre précis. Encore moins les dépendances entre ces packages, les tables qu’ils alimentent, ou ceux qui sont devenus obsolètes.

C’est un problème classique des environnements construits incrémentalement sur 10 à 15 ans par des équipes successives. Chaque génération de développeurs ajoute des packages sans nécessairement documenter ou nettoyer ce que la précédente a laissé.

Ce que révèle la rétro-ingénierie

La rétro-ingénierie de packages SSIS consiste à analyser le code source (les fichiers .dtsx) pour en reconstituer la carte complète, sans dépendre de documentation existante ni de savoir oral.

Le scanner Decinova parse chaque fichier DTSX et en extrait cinq catégories d’information.

Les connexions : quelles bases de données sources et destinations chaque package utilise. C’est la première surprise pour beaucoup de clients — on découvre des connexions vers des serveurs qui n’existent plus depuis 2 ou 3 ans, des packages qui échouent silencieusement chaque nuit parce que leur source a été décommissionée.

Les dépendances : quel package alimente quelle table, quelle table est lue par quel autre package, quelles procédures stockées sont appelées. Le résultat est un graphe orienté de dépendances — la « carte du métro » de votre environnement data.

La complexité : le nombre de composants par Data Flow Task, la profondeur des chaînes d’appel, la complexité cyclomatique de la logique de contrôle. Un package avec 3 Data Flow Tasks simples n’est pas le même qu’un package avec 15 containers imbriqués et des boucles For Each sur des résultats de requêtes.

La qualité du code : présence ou absence de gestion d’erreurs (Event Handlers), de logging, de paramétrage par variables d’environnement (plutôt que des chaînes de connexion codées en dur). C’est ce que le code révèle sur les pratiques des équipes qui l’ont écrit.

L’obsolescence : packages qui font référence à des composants dépréciés (Script Tasks en VB.NET au lieu de C#, connexions via des drivers obsolètes, formats de version DTSX antérieurs).

Le score de dette technique

Les cinq catégories ci-dessus sont agrégées en un score unique de 0 à 100 — le score de dette technique. Ce score est calculé à partir de 12 critères pondérés, regroupés en trois axes : structure (40%), maintenabilité (30%), obsolescence (30%).

Un score inférieur à 30 signifie un patrimoine sain. Entre 30 et 60, la dette est significative mais gérable — des actions ciblées peuvent la réduire. Au-dessus de 60, le patrimoine représente un risque opérationnel sérieux : un incident majeur n’est pas une question de « si » mais de « quand ».

Le score est décomposé par package, ce qui permet d’identifier les « bombes à retardement » — les quelques packages qui concentrent la majeure partie du risque. Dans la plupart des environnements, 10 à 15% des packages concentrent 60 à 70% de la dette technique.

Du diagnostic à l’action

L’audit ne sert à rien s’il ne débouche pas sur un plan d’action. Le rapport Decinova inclut systématiquement un classement de chaque composant selon la matrice valeur métier × dette technique, avec quatre recommandations possibles : migrer en priorité, migrer plus tard, conserver en l’état, ou décommissionner.

Ce classement est accompagné d’une estimation d’effort pour chaque scénario. Le DSI peut ainsi comparer : « si je migre uniquement les 30% les plus critiques, ça coûte X et ça prend Y semaines » versus « si je migre tout, ça coûte 3X et ça prend 3Y ». La décision se prend avec des chiffres, pas avec des convictions.

Un audit qui ne touche pas vos données

Point important pour les organisations soumises à des contraintes réglementaires fortes : le scanner analyse le code source, pas les données. Il n’a besoin d’aucune connexion à vos bases de production. Vous nous transmettez les fichiers DTSX (via un transfert sécurisé), nous les analysons dans un environnement isolé, et nous vous restituons le rapport. Aucune donnée métier ne quitte votre périmètre.