Les débats sur l'architecture Data se transforment souvent en affrontements de convictions : Lakehouse contre Data Warehouse, architecture Médaillon contre modélisation dimensionnelle, Data Mesh contre plateforme centralisée. Pourtant, ces approches ne s'opposent pas réellement. Chacune répond à un contexte, à une contrainte organisationnelle ou à un besoin spécifique. Adopter une architecture parce qu'elle est populaire, sans rencontrer le problème qu'elle cherche à résoudre, revient souvent à hériter de sa complexité sans bénéficier de ses avantages.
Le Data Mesh, par exemple, apporte une réponse à des organisations où les domaines métier sont nombreux, autonomes et difficilement pilotables par une seule équipe centrale. Sans cette contrainte organisationnelle, il peut créer davantage de coordination que de valeur. De la même manière, l'architecture Médaillon structure efficacement les différents niveaux de qualité et de transformation de la donnée, mais multiplier systématiquement les couches sur des flux simples relève parfois davantage de l'habitude que d'un réel besoin d'ingénierie.
Les choix d'architecture les plus importants se situent souvent ailleurs. Faut-il privilégier le batch ou le streaming, et pour quels bénéfices métier ? Quel niveau de latence est réellement nécessaire ? Quels formats de stockage et quelles tables ouvertes permettront de préserver l'interopérabilité à long terme ? Où positionner les frontières entre ingestion, transformation, exposition et consommation des données ? Comment faire coexister plusieurs plateformes, telles que Fabric, Databricks, Snowflake ou BigQuery, sans chercher systématiquement à tout remplacer ?
L'arrivée de l'IA introduit également de nouvelles dimensions architecturales. Les données seules ne suffisent plus. Les modèles sémantiques, les ontologies métier, les graphes de connaissances et les couches de gouvernance deviennent des composants à part entière de l'architecture. La question n'est plus uniquement de savoir où stocker les données, mais aussi comment représenter le sens qu'elles portent afin qu'elles puissent être comprises et exploitées par des humains comme par des agents d'intelligence artificielle.
Cette section rassemble des retours d'expérience, des schémas de référence, des comparatifs d'approches ainsi que les critères d'aide à la décision observés sur le terrain. L'objectif n'est pas de désigner une architecture gagnante, mais de comprendre dans quel contexte chaque approche devient pertinente, ainsi que les compromis qu'elle implique en matière de coûts, de gouvernance, de performance et d'évolutivité.
Les questions que l'on se pose
- Lakehouse ou data warehouse : sur quels critères trancher réellement ?
- L'architecture médaillon est-elle toujours justifiée ?
- À partir de quand un data mesh devient-il pertinent ?
- Comment faire coexister Fabric avec Databricks ou Snowflake sans tout migrer ?
- Quand le temps réel vaut-il sa complexité supplémentaire ?
