Mesurer la dette technique de son patrimoine BI : pourquoi et comment

La dette technique est un concept que tout le monde comprend intuitivement mais que personne ne mesure. Dans le monde du développement logiciel, des outils comme SonarQube ont résolu le problème depuis longtemps. Dans le monde de la BI, il n’existait pas d’équivalent — jusqu’à récemment.

Cet article détaille les 12 critères que nous utilisons pour quantifier la dette technique d’un patrimoine SSIS ou SAP BO, et explique pourquoi cette quantification change la nature des décisions que prend un DSI.

Le problème du « je sais que c’est mal mais je ne sais pas à quel point »

La plupart des DSI savent que leur patrimoine BI a de la dette technique. Ils le sentent à travers des signaux indirects : les traitements nocturnes qui dépassent leur fenêtre, les incidents récurrents sur les mêmes packages, les évolutions qui prennent 3 semaines au lieu de 3 jours, le consultant TMA qui dit « il vaut mieux ne pas toucher à ce package ».

Mais sans mesure précise, il est impossible de prioriser. Faut-il investir 200 K€ dans une migration complète ? Ou 50 K€ pour remettre en état les 20 composants les plus critiques ? Sans données, la décision se prend au feeling — et le feeling tend à sous-estimer la dette quand tout « fonctionne » et à la surestimer après un incident grave.

Les 12 critères de mesure

Notre score de dette technique va de 0 (patrimoine neuf, bien structuré) à 100 (risque opérationnel immédiat). Il est calculé automatiquement par rétro-ingénierie du code source, sans accès aux données ni à la production.

Critères de structure (40% du score)

Complexité cyclomatique moyenne. Mesure le nombre de chemins d’exécution possibles dans un package SSIS. Un package avec une complexité >30 est pratiquement impossible à tester exhaustivement et très risqué à modifier. La moyenne saine se situe entre 5 et 15.

Dépendances circulaires. Quand le package A appelle le package B qui appelle le package C qui dépend du résultat de A, on a une dépendance circulaire. C’est un indicateur d’architecture dégradée. Zéro est l’objectif ; au-delà de 3, c’est un signal d’alerte sérieux.

Profondeur des chaînes d’appel. Un job SQL Server Agent qui lance un package maître, qui lance 4 sous-packages, dont un lance à son tour 3 sous-sous-packages, a une profondeur de 3. Au-delà de 4 niveaux, le debugging devient quasiment impossible en cas d’incident nocturne.

Ratio de code dupliqué. Pourcentage de transformations ou de requêtes SQL identiques ou quasi-identiques présentes dans plusieurs packages. Au-dessus de 15%, c’est le signe que le patrimoine a été construit par copier-coller plutôt que par factorisation.

Critères de maintenabilité (30% du score)

Packages sans logging. Un package SSIS sans Event Handler OnError ou sans logging dans une table dédiée est un package aveugle : quand il échoue en production à 3h du matin, personne ne sait pourquoi. Le taux acceptable est inférieur à 10%.

Couverture des gestionnaires d’erreurs. Même quand un Event Handler OnError existe, est-il présent à chaque niveau (package, conteneur, tâche) ? Une couverture partielle est parfois pire que pas de couverture du tout, parce qu’elle donne une fausse impression de sécurité.

Connexions codées en dur. Pourcentage de chaînes de connexion (serveurs, bases de données, identifiants) écrites en dur dans les packages au lieu d’utiliser des variables d’environnement ou des configurations externes. Un seul changement de nom de serveur peut casser des dizaines de packages simultanément.

Utilisation de variables d’environnement. Complémentaire du critère précédent : les packages bien structurés utilisent des variables d’environnement pour les connexions, les chemins de fichiers et les paramètres de configuration. Leur absence est un signe de développement « artisanal ».

Critères d’obsolescence (30% du score)

Références mortes. Packages qui référencent des serveurs ou des bases de données qui n’existent plus. Soit le package échoue silencieusement (et personne ne le sait parce qu’il n’y a pas de logging), soit il a été désactivé mais n’a jamais été supprimé, encombrant le patrimoine.

Composants dépréciés. Script Tasks en VB.NET (déprécié depuis SSIS 2012), composants tiers dont l’éditeur a disparu, sources de données dans des formats obsolètes (fichiers .dbf, connexions ODBC 32-bit).

Versions de format antérieures. Un package créé sous SSIS 2008 peut tourner sur un serveur SSIS 2019, mais son format interne est obsolète. Il n’utilise pas les nouvelles fonctionnalités (Project Deployment Model, Parameters) et peut poser des problèmes de compatibilité lors d’une migration de version serveur.

Taux de composants non utilisés. Pour SAP BO : pourcentage de rapports WebI qui n’ont pas été exécutés depuis plus de 12 mois (mesuré via les logs CMS). Pour SSIS : packages jamais exécutés ou désactivés dans le job Agent.

Ce que le score change dans la prise de décision

Un score inférieur à 30 (« patrimoine sain ») justifie une TMA classique avec des interventions ponctuelles d’amélioration. Un score entre 30 et 60 (« dette significative ») appelle un plan de remédiation ciblé : identifier les 20% de composants qui concentrent 80% de la dette et les traiter en priorité. Un score au-dessus de 60 (« risque opérationnel ») plaide généralement pour une migration vers le cloud plutôt qu’une remédiation du legacy — le coût de remise en état dépasse le coût de remplacement.

Le score n’est pas une fin en soi. C’est un outil de dialogue entre la DSI, les métiers et la direction générale. Dire « notre patrimoine a un score de dette technique de 54/100, voici les 3 scénarios d’investissement » est infiniment plus convaincant que « il faut moderniser notre BI ».