Par Virginie Brard, RVP France & Benelux chez Fivetran
Alors que les entreprises passent de l’analytique à l’IA en production, les limites du modern data stack deviennent rapidement visibles. Pensées autour du data warehouse, ces architectures peinent à absorber des usages plus distribués, plus rapides et plus coûteux. Loin de devoir remplacer les plateformes existantes, l’enjeu consiste désormais à repenser l’endroit où vivent les données.
Ne pas quitter les plateformes, mais changer le centre de gravité
Le modern data stack répondait à un vrai besoin il y a dix ans : centraliser les données, les modéliser, permettre aux analystes de les interroger. Les data warehouses ont parfaitement rempli cette mission. Mais la mission a changé. Mettre de l’IA en production sur une architecture centrée sur le warehouse revient souvent à accepter des coûts de calcul difficiles à justifier, une latence mal adaptée aux usages produit, et une multiplication de copies de données dont la gouvernance devient fragile. L’architecture n’est pas cassée ; elle accomplit simplement une tâche pour laquelle elle n’a pas été conçue.
Les grandes plateformes data conservent un rôle central pour le calcul, l’analytique et les usages d’IA. Leurs capacités intégrées couvrent déjà de nombreux besoins opérationnels, qu’il s’agisse d’analyse avancée, d’automatisation ou de traitement de workloads IA. Or les données doivent-elles continuer à vivre principalement dans un seul système ou devenir accessibles à plusieurs moteurs ?
La limite ne vient pas des outils, mais du couplage entre stockage et calcul. Dès qu’un cas d’usage IA nécessite un autre modèle, un autre moteur ou un autre environnement, les équipes doivent copier les données, reconstruire des pipelines et gérer des incohérences. C’est ainsi que les coûts montent, que la latence s’installe et que le contexte se fragmente.
L’Open Data Infrastructure propose une autre logique, qui consiste à stocker les données une seule fois dans un lake ouvert et gouverné, puis à permettre à différents moteurs de calcul d’accéder à la même source de vérité. Dans une entreprise où les équipes métiers, data science et IA n’utilisent pas nécessairement les mêmes environnements, ce socle commun évite la multiplication des pipelines, les ingestions redondantes et l’apparition de versions concurrentes d’une même donnée.
Les data lakes d’hier ne sont pas ceux d’aujourd’hui
L’objection revient régulièrement. De nombreuses entreprises ont expérimenté les data lakes autour de 2018, avec à la clé des environnements difficiles à gouverner, parfois réduits à de simples zones de stockage de données désorganisées. Ces échecs s’expliquaient par des limites bien identifiées, notamment des dépôts de fichiers sans garanties transactionnelles, une dérive permanente des schémas, une gouvernance ajoutée trop tard et des moteurs de requête plus lents que les warehouses.
La situation a changé. Les formats de table ouverts apportent désormais des transactions ACID, l’évolution des schémas et le time travel au-dessus du stockage objet. Les catalogues ont mûri. Les moteurs capables de lire ces formats sont devenus compétitifs pour de nombreux workloads. Ces capacités ne suffisent toutefois pas seules. Il faut encore acheminer les données dans les bons formats, les maintenir à jour, gérer les changements de schéma et publier les métadonnées dans les catalogues. C’est précisément sur cette complexité opérationnelle qu’interviennent les services managés, en automatisant la livraison des données, la synchronisation continue et la mise à disposition des métadonnées pour l’ensemble des moteurs.
L’ouverture n’est pas absolue, mais elle change le rapport de force
L’ouverture doit être examinée avec précision. Sur le plan des formats, elle est bien réelle : les formats de table ouverts peuvent être lus et exploités par plusieurs moteurs de calcul, au lieu d’être enfermés dans un environnement unique. Les données restent dans un stockage objet contrôlé par l’entreprise, dans un format interopérable et réutilisable. C’est une différence majeure avec un stockage propriétaire, captif d’un seul data warehouse.
Sur le plan de la gouvernance, la situation est plus nuancée. Aucun modèle n’est totalement neutre, certains standards restants influencés par les acteurs qui les ont créés, les financent ou les font évoluer. Mais le critère décisif est opérationnel. Si une entreprise peut changer de moteur de requête sans réingérer des volumes massifs de données, elle conserve un véritable levier de négociation et d’évolution. L’Open Data Infrastructure permet cette marge de manœuvre ; les architectures fondées sur un stockage propriétaire la limitent fortement.
Ce modèle n’efface pas tous les arbitrages. Un stack plus modulaire introduit de la complexité, notamment lorsqu’il faut assembler catalogue, moteur de requête, orchestration et gouvernance. Mais les couches les plus critiques, en particulier le stockage et le catalogue, se standardisent progressivement. Des offres managées permettent aussi d’adopter cette architecture sans exploiter chaque composant en interne. Le vrai choix n’oppose donc pas modularité et consolidation, mais simplicité immédiate et flexibilité future.
Repositionner les données avant de reconstruire le reste
Les premiers tests d’IA ne cassent pas toujours le modèle économique. Le point de rupture arrive lorsque les workflows deviennent fréquents, automatisés et exécutés à grande échelle. Une tâche d’agent, comme générer une recommandation, peut déclencher une récupération de comportements utilisateurs, une recherche produit, une vérification d’inventaire, une inférence de modèle et une étape de re-ranking. Ce qui semble être une seule requête devient une chaîne d’opérations. À grande échelle, le coût par tâche et la latence deviennent difficiles à défendre sur une architecture centrée sur le warehouse.
Il n’est pourtant pas nécessaire de retirer brutalement le data warehouse. Il faut d’abord cesser de le traiter comme le centre de l’univers. La première étape consiste à déplacer la couche de stockage vers des formats ouverts, sur un stockage objet réellement contrôlé par l’entreprise. Il ne s’agit pas d’abandonner l’existant, mais de repositionner les données pour les rendre accessibles à d’autres moteurs.
La deuxième étape consiste à sortir un workload ciblé du warehouse : récupération à haute fréquence, pipeline de features pour un cas d’usage machine learning, workflow d’agent générant des coûts inattendus. En l’exécutant sur un autre moteur, à partir du même stockage, l’entreprise obtient une preuve concrète en coûts, en latence et en performance.
La dernière étape concerne la couche de contexte, c’est-à-dire les métadonnées, la sémantique et les définitions partagées. Ces éléments peuvent sembler secondaires tant que seuls des analystes interrogent les données. Ils deviennent critiques lorsque des agents prennent des décisions ou déclenchent des actions. Pour l’IA, cette couche n’est pas un simple supplément de gouvernance. Elle détermine la différence entre des agents fiables et des agents dangereux.
L’avenir du data stack ne se jouera donc pas dans le remplacement d’un fournisseur par un autre. Il dépendra de la capacité des entreprises à distinguer ce qui doit rester stable, comme la donnée, son contexte et sa gouvernance, de ce qui doit rester interchangeable, comme les moteurs, les modèles et les outils. C’est précisément le rôle de l’Open Data Infrastructure.
