Les six couches d'une data platform, et leurs pièges les plus coûteux

Un terme omniprésent, une architecture méconnue

Le terme data platform circule dans tous les comités de direction depuis bientôt trois ans, mais quand vient le moment de l'instruire, le décalage entre les attentes et l'architecture réelle se révèle souvent.

La raison tient à un détail simple : une data platform moderne s'organise en six couches qui ont chacune leur logique, leurs outils et leurs pièges. Les confondre revient à comparer un moteur à une carrosserie.

Les sources : cartographier avant d'acheter

La première couche est celle des sources, qu'il faut cartographier avant même d'évoquer l'achat d'une plateforme. Une source ERP n'a rien à voir avec une source IoT ni avec un flux de capteurs, et la nature des sources contraint toutes les couches suivantes, du modèle d'ingestion au mode de gouvernance. Une cartographie superficielle au démarrage devient une dette structurelle qui se paie six mois plus tard, quand un cas d'usage prioritaire bute sur une donnée non identifiée.

L'ingestion : un choix d'outil qui engage la facture

Vient ensuite l'ingestion, étape historiquement assurée par les outils ETL et désormais largement migrée vers l'ELT, où la transformation se fait après chargement. Le choix d'outil engage durablement, avec des modèles tarifaires très différents (rows, capacité, compute) qui changent radicalement le coût final. Une mauvaise lecture du pricing peut tripler la facture annuelle sans que personne ne s'en aperçoive avant le renouvellement.

Le traitement : la stack dépend des compétences autant que des volumes

Le traitement assure la transformation, la qualité et la normalisation. Apache Spark et dbt dominent ce terrain, à ceci près que le choix dépend autant des compétences en interne que des volumes traités. Une stack dbt sans data engineer expérimenté tient deux trimestres, pas trois.

Le stockage : warehouse, lake ou lakehouse

Le stockage tranche entre data warehouse, data lake et lakehouse, avec des arbitrages structurants sur la séparation compute/stockage et le coût à l'échelle. Les chiffres parlent : Databricks affiche 5,4 Md$ de run-rate en croissance de 65 %, Snowflake compte 13 300 clients, et Microsoft Fabric en revendique 31 000 (+60 %/an). La tendance va vers le lakehouse, mais le warehouse pur garde sa pertinence quand la BI domine et que la prévisibilité du coût prime.

L'analyse et la visualisation : là où l'adoption se joue

L'analyse exploite ensuite les données préparées au moyen de SQL, de modèles statistiques ou de ML.

La visualisation, dernière couche, conditionne en grande partie l'adoption réelle : une donnée parfaitement préparée mais mal restituée ne sera jamais utilisée par les métiers.

Rendre visibles les vrais choix

Cette mécanique en six étages n'a pas vocation à impressionner. Elle a le mérite de rendre visibles les vrais choix : où automatiser, où outiller, où former. Une plateforme bien dimensionnée vaut toujours mieux qu'une plateforme bien vendue. Ce travail de calibrage par couche fonde chacune des missions data que nous menons chez NDA.

Cet article est le deuxième d'une série de cinq sur les data platforms. Le prochain tranche le grand match : Snowflake, Databricks, Microsoft Fabric.

‍