Contexte et enjeux
Le service business intelligence d’une société de technologie médicale devait exploiter environ 30 pétaoctets provenant d’ERP, de CRM, de data‑warehouses cloud et de plateformes d’observabilité. La méthode traditionnelle consistait à copier ces sources dans un entrepôt central, ce qui a entraîné des temps de réponse imprévisibles, la duplication de stockage et la perte de contrôles d’accès fins. Chaque modification de schéma en amont nécessitait une mise à jour correspondante dans chaque pipeline, multipliant les coûts opérationnels.
Face à ces limites, l’équipe de 30‑35 personnes a choisi une architecture de requête fédérée afin d’interroger les données à leur source, éliminant ainsi les copies redondantes et conservant les politiques de sécurité propres à chaque système.
Architecture de la requête fédérée
Le moteur distribué, basé sur Starburst/Trino, a été déployé sur un cluster Kubernetes. Il agit comme un planificateur de requêtes qui traduit les requêtes SQL en appels aux connecteurs natifs de chaque source. Cette approche réduit la latence liée aux cycles ETL, mais impose une charge supplémentaire sur le réseau et sur les systèmes sources, qui doivent supporter les requêtes en temps réel. Le modèle conserve les contrôles d’accès basés sur les rôles (RBAC) et les journaux d’audit au niveau de chaque source, évitant ainsi la « flattening » de la gouvernance observée dans les entrepôts centralisés.
Automatisation du déploiement
Initialement, le provisionnement du cluster et les mises à jour de version nécessitaient 3 à 5 jours d’intervention manuelle, avec un risque élevé de dérive de configuration entre les environnements. L’ingénieur DevOps a intégré le processus dans une chaîne CI/CD versionnée, déclenchée depuis un dépôt Git. Chaque exécution crée un cluster identique, applique les paramètres de connexion aux sources et effectue les mises à jour de version sans interruption. Le temps de déploiement est ainsi passé à quelques heures, soit un facteur de réduction d’environ 10 ×.
Pour pallier la perte de logs lors du redémarrage des pods, les flux de journalisation ont été redirigés vers un stockage persistant externe (par exemple, un bucket S3 ou un volume CSI). Cette persistance garantit la traçabilité des incidents et la conformité aux exigences réglementaires du secteur santé.
Extension vers les agents IA et gouvernance
Le même plan de requête fédérée a été exposé aux modèles génératifs via une couche sémantique et un protocole de type MCP (Model‑Control‑Protocol). Au lieu de donner aux modèles un accès direct aux bases, l’interface propose des « data products » pré‑définis, chaque produit étant associé à des règles de gouvernance et à des contrôles d’accès. Ainsi, les agents conversationnels peuvent récupérer des réponses en temps réel tout en respectant les exigences d’audit et de confidentialité propres aux données de santé.
Cette architecture démontre que la fédération de requêtes à l’échelle du pétaoctet peut être rendue reproductible, sécurisée et compatible avec les usages d’IA d’entreprise, à condition d’automatiser le déploiement et de préserver la persistance des journaux.
