Nos clients nous confient la confidentialité de leur nom. En échange, nous détaillons nos projets avec une transparence technique que d’autres ne peuvent pas se permettre.
Un groupe bancaire européen devait moderniser son infrastructure décisionnelle vieillissante sans interrompre les reportings réglementaires quotidiens.
Le client exploitait un datawarehouse SQL Server 2016 alimenté par 623 packages SSIS, 89 procédures stockées et 34 jobs SQL Server Agent. L’ensemble produisait les reportings réglementaires (COREP, FINREP, ratios prudentiels) et les tableaux de bord commerciaux consommés par 450 utilisateurs via Power BI et Excel.
Le problème était triple. Les fenêtres de traitement nocturnes dépassaient régulièrement 7 heures, empiétant sur les heures ouvrables. Le serveur SQL Server physique arrivait en fin de support hardware. Et les équipes internes ne trouvaient plus de développeurs SSIS sur le marché.
L’audit automatisé a révélé que 142 des 623 packages étaient obsolètes (alimentés par des sources décommissionées ou produisant des tables que personne ne consultait). Ces 142 packages ont été désactivés sans migration — une économie immédiate de 23% du périmètre.
Les 481 packages restants ont été traités par le convertisseur. 338 ont été convertis automatiquement en modèles DBT (taux de conversion de 70%). Les 143 restants ont nécessité une reprise manuelle — principalement des packages avec du T-SQL dynamique, des curseurs imbriqués ou des Script Tasks en C#.
Les procédures stockées contenant la logique métier réglementaire (calculs de ratios, agrégations normalisées) ont été converties en modèles DBT avec des tests automatisés intégrés — chaque modèle valide ses propres résultats par comparaison avec le système legacy.
Le déclic : lors de la phase de tests parallèles, nous avons découvert 7 écarts entre l’ancien et le nouveau système. 5 étaient des bugs du convertisseur (corrigés en 48h). Les 2 autres étaient des erreurs de calcul présentes dans le système legacy depuis des années, jamais détectées. La migration a corrigé des problèmes que personne ne savait exister.
Audit automatisé. Découverte des 142 packages obsolètes. Cadrage du forfait.
Conversion automatisée des 481 packages. Reprise manuelle des 143 cas complexes.
Tests parallèles sur données de production. Correction des 7 écarts identifiés.
Bascule par vagues (3 lots). Migration des connexions Power BI.
Hyper-care. Transfert de compétences DBT aux équipes internes.
Une mutuelle santé régionale a dû remplacer son prestataire TMA en urgence après une rupture de contrat, sans perte de continuité de service.
La mutuelle exploitait SAP BusinessObjects BI 4.2 SP06 avec 47 univers, 1 847 rapports Web Intelligence et 312 rapports Crystal Reports. L’environnement alimentait les directions métier (sinistres, prestations, cotisations, réseau de soins) et les reportings réglementaires ACPR.
Le prestataire historique a mis fin au contrat avec un préavis de 3 mois. Le problème : aucune documentation à jour, aucun transfert de connaissances prévu, et un consultant unique qui détenait tout le savoir sur l’environnement.
Nous avons déployé le scanner dès la première semaine pour cartographier automatiquement les 47 univers (jointures, filtres, objets calculés, liens avec les rapports) et les 1 847 rapports WebI (requêtes, formules, alerteurs, planifications). En parallèle, un consultant senior a travaillé en binôme avec le consultant sortant pendant 3 semaines.
À la semaine 4, nous avions une compréhension complète de l’environnement — documentée et reproductible, contrairement au savoir oral du précédent prestataire. À la semaine 6, la transition était achevée et le SLA contractuel actif.
Au passage, l’audit a identifié 423 rapports non utilisés depuis plus de 12 mois (aucune exécution enregistrée dans les logs CMS). Après validation métier, ces rapports ont été archivés, réduisant la surface de maintenance de 23%.
En plus de la TMA : nous avons planifié et exécuté la conversion de 31 univers .unv vers .unx en préparation de la future migration vers BI 4.3 SP05, et repointé les 1 200+ rapports concernés vers les nouveaux univers. Cette opération, réalisée sur 8 week-ends par lots, n’a généré aucun incident de production.
Un seul dépassement de SLA sur l’année (incident lié à un patch OS, résolu en 3h au lieu de 2h).
Réduction de 23% de la surface de maintenance, sans impact métier.
Préparation terminée pour la migration BI 4.3/2025.
Principalement grâce à l’automatisation de l’audit initial et la réduction du périmètre.
Un groupe industriel devait cartographier un environnement data construit sur 15 ans par des équipes successives, sans documentation, avant de décider quoi moderniser.
Le groupe exploitait en parallèle un environnement SSIS/SQL Server (847 packages, 156 procédures stockées) pour l’alimentation du datawarehouse et un environnement SAP BusinessObjects BI 4.2 (234 univers, 1 203 rapports) pour le reporting. Les deux systèmes avaient été construits progressivement sur 15 ans par au moins 5 prestataires différents.
Le DSI faisait face à un dilemme classique : il savait que le système avait de la dette technique, mais il n’avait aucune visibilité sur son ampleur réelle. Faut-il tout migrer vers le cloud ? Peut-on moderniser par morceaux ? Quel budget prévoir ?
L’audit complet des deux environnements a été livré en 48 heures. Le score de dette technique de 37/100 indiquait un patrimoine « fatigué mais gérable » — pas en état critique, mais avec des zones de fragilité bien identifiées : 34% des packages sans logging, 3 dépendances circulaires, 18% de code dupliqué, et 7 connexions vers des serveurs décommissionés depuis 2 ans.
Sur la base de l’audit, nous avons recommandé une stratégie hybride plutôt qu’une migration intégrale. Les packages SSIS les plus critiques (alimentation des données de production industrielle, temps réel) ont été migrés vers Microsoft Fabric avec des pipelines Dataflow Gen2. Les packages de reporting classique (alimentation du DWH pour les tableaux de bord) ont été convertis en modèles DBT sur Snowflake. L’environnement SAP BO a été conservé et monté en BI 4.3 SP05, avec conversion UNV → UNX réalisée dans la foulée.
Le choix hybride s’explique : migrer 100% du patrimoine vers une seule cible aurait coûté 3 fois plus cher et pris 12 mois de plus. La stratégie hybride a permis de moderniser les composants à plus forte dette technique en premier, tout en préservant les composants SAP BO qui fonctionnent bien et pour lesquels les utilisateurs métier n’ont pas de besoin de changement.
Grâce à la parallélisation native de Snowflake et à l’élimination des packages obsolètes.
Élimination du serveur physique SQL Server. Snowflake facturé à l’usage uniquement.
Migration vers BI 4.3 SP05 avec support SAP maintenu. Univers .unx prêts pour BI 2025.
Cartographie des flux, dictionnaire de données, documentation DBT auto-générée. Le client ne dépend plus d’un seul prestataire.
Votre projet ressemble à l’un de ces cas ?
En 48 heures, vous saurez exactement où vous en êtes. Pas d’engagement, pas d’accès à vos données métier.