Rafraichissement BDD SQL

RôleLead Consultant | Architecture Data
Type de projetData Engineering
Secteursoutenabilité
ContexteDUER
PhaseModernisation de l’Infrastructure, Intégration de Données et Fiabilisation du Reporting
Smart and Sustainable City Development Framework in Libya

Objectif du projet

Ce projet visait à moderniser une infrastructure historique de base de données SQL au sein d’une entreprise spécialisée dans la production de rapports pour des branches professionnelles du secteur de la santé en France. L’objectif principal consistait à améliorer significativement les performances, la qualité et l’intégrité des données, tout en renforçant les capacités de reporting et la fiabilité des flux d’information nécessaires aux parties prenantes métier. L’intervention s’inscrivait dans une logique de transformation data à la fois technique et opérationnelle, avec un enjeu fort de continuité de service, de structuration des données et d’optimisation des usages analytiques.

Enjeux stratégiques et cadre d’intervention

Contexte : L’organisation s’appuyait sur une architecture SQL legacy qui soutenait des processus critiques de collecte, consolidation et restitution de données destinées à ses clients institutionnels et branches professionnelles. Avec l’évolution des volumes, de la complexité des traitements et des attentes en matière de reporting, les limites de l’environnement existant sont devenues plus visibles : lenteurs d’exécution, difficultés d’intégration entre sources, hétérogénéité des structures de données et risques accrus sur la cohérence des résultats produits.
Enjeux : Le programme de modernisation devait donc répondre à un double impératif : stabiliser et fiabiliser l’existant tout en créant une architecture cible plus robuste, mieux gouvernée et capable de supporter des besoins de reporting plus exigeants dans un environnement sensible lié à la santé.

Périmètre de la mission

Le projet intégrait une dimension forte de data engineering, avec une attention particulière portée à la maintenabilité, à la lisibilité des transformations, à la traçabilité des données et à la réduction des points de fragilité dans la chaîne de production des rapports.

Chronologie

Phase 1
Diagnostic de l’existant et cartographie des flux
La première phase a porté sur l’audit de l’infrastructure SQL legacy, l’identification des dépendances critiques, la cartographie des tables, vues, procédures et flux d’alimentation, ainsi que l’analyse des irritants techniques et fonctionnels affectant la performance et la qualité des livrables.
Phase 2
Définition de l’architecture cible et des principes de transformation
Une architecture cible a ensuite été définie pour améliorer la structuration du socle data, clarifier les responsabilités entre sources, traitements et couches de restitution, et poser les bases d’un environnement plus évolutif, cohérent et orienté usage métier.
Phase 3
Optimisation SQL et refonte des traitements de données
Cette phase a consisté à revoir les requêtes, procédures et mécanismes d’agrégation afin d’améliorer les temps de traitement, de limiter les redondances, de sécuriser les calculs et de renforcer la stabilité de la chaîne de production analytique.
Phase 4
Intégration de données et fiabilisation des règles de qualité
Les flux d’intégration ont été consolidés pour mieux gérer l’hétérogénéité des sources, standardiser les transformations et introduire des contrôles renforcés sur la complétude, la cohérence et l’intégrité des données utilisées dans les rapports.
Phase 5
Alignement avec les besoins de reporting et restitution
Le modèle modernisé a été structuré pour répondre plus efficacement aux attentes des clients branches professionnelles, avec une meilleure disponibilité des données, une plus grande fiabilité des indicateurs et une capacité renforcée à produire des restitutions plus rapides et plus lisibles.
Phase 6
Stabilisation, documentation et logique de pérennisation
La dernière phase a porté sur la documentation de l’architecture et des flux, la formalisation des règles de gestion et la préparation d’un cadre de maintenance plus durable, afin de faciliter l’exploitation future et les évolutions progressives de la plateforme data.

Parties prenantes

Direction de l’entreprise (sponsor)

Le projet nécessitait une coordination étroite entre besoins opérationnels, contraintes d’infrastructure et exigences de qualité de service.

Directeur Informatique

Point d'entrée au système d'information et interlocuteurs principale pour les différents tests.

Equipes métier

Ce sont les protagonistes et bénéficiaires principaux de la restructuration de la gestion des données.

Clients finaux (branches professionnelles)

Le livrable devait répondre à un besoin commercial évolutif de la part des clients.

Résultats et apports

Lessons apprises

Classification du projet (PMI)

Approche de la Gestion de Projet (Project Management)
PRATIQUES HYBRIDES QUALITE DES DONNEES PERFORMANCE
Responsabilités fonctionnelles
DATA ENGINEERING ARCHITECTURE BASE DE DONNEES MODERNISATION SI
Caractéristiques du projet
REPORTING DONNEES DE SANTE