Le problème que personne ne voit venir
Votre patrimoine SSIS fonctionne. Les jobs tournent la nuit, les données arrivent dans le datawarehouse, les rapports s’affichent le matin. Tout va bien. Jusqu’au jour où ça ne va plus — et personne ne comprend pourquoi.
Le scénario est classique. Un package SSIS échoue en production un vendredi soir. L’expert interne est en vacances. Le consultant qui l’avait développé il y a 8 ans a quitté l’entreprise. La documentation n’existe pas — ou pire, elle existe mais ne correspond plus à la réalité du code. Personne ne sait quels rapports sont impactés, quelles tables ne sont plus alimentées, quels processus métier sont bloqués.
Ce scénario n’est pas hypothétique. C’est l’un des motifs de contact les plus fréquents que nous recevons. Et à chaque fois, le même constat : le problème n’est pas le bug du vendredi soir. Le problème, c’est que personne n’avait de visibilité sur ce que contenait réellement le patrimoine SSIS.
Ce que révèle un audit automatisé
Quand nous scannons un environnement SSIS pour la première fois, nous trouvons systématiquement les mêmes pathologies. Pas parce que les équipes ont mal travaillé — mais parce qu’un patrimoine construit sur 10 à 15 ans par des équipes successives accumule naturellement de la dette technique, comme une maison accumule de l’humidité si on n’aère pas.
Les packages fantômes
Ce sont des packages SSIS qui existent dans le répertoire, qui sont parfois même planifiés dans SQL Server Agent, mais qui ne servent plus à rien. Leur source de données a été décommissionnée, ou leur table de destination n’est lue par aucun rapport. Ils tournent dans le vide, consomment du temps de traitement et masquent les vrais problèmes dans les logs. Nous en trouvons entre 15 et 25% du patrimoine total dans quasiment tous les audits.
Les dépendances invisibles
Un package A alimente une table qui est lue par le package B qui alimente une vue utilisée par le rapport C. Si le package A échoue, le rapport C affiche des données obsolètes — mais personne ne fait le lien parce que les trois composants ont été développés par des personnes différentes à des années d’intervalle. L’audit automatisé reconstruit cette chaîne complète en analysant les connexions déclarées dans chaque fichier DTSX.
Les connexions fantaisistes
Des chaînes de connexion codées en dur avec le nom d’un serveur qui a été remplacé il y a 3 ans (mais qui « marche encore » parce qu’un alias DNS redirige vers le nouveau). Des identifiants de connexion stockés en clair dans le fichier DTSX. Des références à des bases de données de développement dans des packages de production. Autant de bombes à retardement.
L’absence de gestion d’erreurs
Un package SSIS sans Event Handler est un package qui échoue en silence. Pas de notification, pas de log détaillé, pas de rollback. Quand le traitement nocturne plante à 3h du matin, personne ne le sait avant que l’utilisateur appelle à 9h pour signaler que ses données sont manquantes. Nous trouvons régulièrement 25 à 40% de packages sans gestionnaire d’erreurs dans les environnements que nous auditons.
L’approche par rétro-ingénierie
L’audit de patrimoine classique repose sur l’interview des équipes et la lecture manuelle du code. C’est lent (2 à 4 semaines pour 200 packages), subjectif (le consultant voit ce qu’il cherche, pas ce qu’il ne connaît pas) et incomplet (personne ne lit 500 fichiers XML de bout en bout).
L’approche par rétro-ingénierie est différente. Le scanner Decinova ouvre chaque fichier DTSX, parse sa structure XML propriétaire, et en extrait automatiquement toutes les informations structurelles : les connexions, les Data Flow Tasks, les Control Flow Tasks, les variables, les expressions, les Event Handlers, les précédences. Il calcule ensuite des métriques de qualité de code sur chaque composant (complexité cyclomatique, duplication, couverture de logging) et des métriques de risque sur l’ensemble du patrimoine (dépendances circulaires, références cassées, serveurs obsolètes).
Le résultat est un rapport de 20 à 40 pages qui contient la cartographie complète de votre environnement, un score de dette technique sur 100, et un plan d’action priorisé. Le tout livré en 48 heures, sans accès à vos données métier.
À quoi sert l’audit si on ne migre pas ?
Question légitime — et la réponse est importante. L’audit n’est pas un prélude obligatoire à une migration. C’est d’abord un outil de gouvernance.
Si vous décidez de maintenir votre patrimoine SSIS, l’audit vous donne la documentation que vous n’avez jamais eue — la cartographie des flux, la matrice de dépendances, l’inventaire des composants obsolètes. C’est le socle sur lequel une TMA efficace peut s’appuyer. C’est aussi votre assurance contre le départ d’un expert clé : le savoir n’est plus dans la tête d’une personne, il est dans un rapport vérifiable et reproductible.
Si vous envisagez une migration, l’audit est le seul moyen d’obtenir une estimation de budget et de planning fiable. Sans lui, vous demanderez à des prestataires de chiffrer une migration sur la base d’un périmètre que vous ne maîtrisez pas — et vous obtiendrez des estimations qui déraperont inévitablement.
Dans les deux cas, la première étape est la même : comprendre ce que vous avez. Et c’est exactement ce que fait l’audit gratuit Decinova.