Quand on parle aujourd’hui d’architecture data en Europe ou aux États-Unis, quelques termes reviennent presque mécaniquement : cloud, lakehouse, data mesh, data products, streaming, semantic layer, self-service, gouvernance et désormais IA.

La Chine utilise largement les mêmes briques conceptuelles et technologiques. Apache Flink, Spark, Hudi, Iceberg, Kafka, le stockage objet, la séparation du calcul et du stockage ou encore la modélisation dimensionnelle ne s’arrêtent évidemment pas aux frontières.

Il serait donc excessif de parler d’une « école chinoise » totalement distincte de l’architecture occidentale.

Pourtant, lorsqu’on étudie les publications techniques d’Alibaba, ByteDance, Tencent ou encore Meituan, un centre de gravité particulier apparaît.

La différence n’est pas nécessairement dans les technologies employées.

Elle est dans les problèmes que l’architecture cherche prioritairement à résoudre.

La Chine numérique constitue à cet égard un laboratoire fascinant : commerce électronique massif, paiement numérique, livraison, mobilité, vidéo, recommandation algorithmique et services fonctionnant à des volumes considérables. Dans ces environnements, quelques minutes de retard dans la circulation d’une information peuvent déjà avoir une conséquence opérationnelle.

De cette contrainte ressortent plusieurs leçons qui méritent d’être observées par les architectes data européens.

1. Le data warehouse n’est pas mort : il est devenu temps réel

L’un des premiers enseignements est presque contre-intuitif.

L’essor du Big Data occidental s’est accompagné d’une succession de ruptures annoncées :

Data Warehouse → Data Lake → Lakehouse → Data Mesh → Data Products.

Chaque génération a parfois été présentée comme devant corriger ou remplacer la précédente.

Le corpus technique chinois donne une impression différente.

On continue à y retrouver une architecture extrêmement classique :

ODS → DWD → DWS → ADS

où :

• ODS (Operational Data Store) conserve les données proches des systèmes sources ;
• DWD (Data Warehouse Detail) porte les données détaillées, nettoyées et normalisées ;
• DWS (Data Warehouse Summary) construit les agrégats et données communes réutilisables ;
• ADS (Application Data Store) prépare les données pour les applications et usages finaux.

Cette organisation reste encore documentée en 2026 dans l’écosystème Alibaba.

Mais elle évolue.

Dans les architectures traditionnelles, ces couches sont parcourues par des traitements batch. Dans les architectures temps réel documentées autour de Flink et Hologres, les mêmes principes de structuration sont conservés tandis que la circulation entre les couches devient continue.

C’est une différence intellectuelle importante.

La question n’est plus nécessairement :

« Par quoi remplacer le data warehouse ? »

mais :

« Comment conserver la discipline du data warehouse tout en supprimant la latence qui le sépare du métier ? »

Autrement dit, le problème n’était peut-être pas le warehouse.

Le problème était parfois d’attendre demain matin pour connaître ce qui s’est passé aujourd’hui.

2. La fraîcheur de la donnée devient une propriété architecturale

Cette logique apparaît particulièrement bien dans le cas de Xianyu, la plateforme de seconde main du groupe Alibaba.

Ses ingénieurs expliquaient devoir traiter quotidiennement près de dix milliards d’événements d’exposition, de clics et de navigation. Parmi les problèmes opérationnels : identifier rapidement une anomalie d’exposition d’un produit, produire des rapports temps réel sur une population de produits ou déclencher des alertes personnalisées suffisamment tôt.

Ce type de problème modifie profondément la façon de considérer la donnée.

Dans un reporting financier mensuel, une donnée vieille de quelques heures peut conserver pratiquement toute sa valeur.

Dans un système de recommandation, de livraison, de fraude, de pricing ou de publicité, sa valeur peut diminuer très rapidement.

On pourrait représenter cette propriété par une fonction simple :

Valeur de la donnée = f(fraîcheur)

Cela conduit à une métrique architecturale trop rarement explicitée :

le Time-to-Decision

Il ne suffit plus de mesurer combien de téraoctets la plateforme peut absorber.

Il faut mesurer la distance :

Événement → Donnée disponible → Information → Décision → Action

Une plateforme capable de traiter 10 pétaoctets mais qui restitue une information opérationnelle six heures trop tard peut être moins utile qu’une plateforme plus modeste produisant la bonne information en quelques secondes.

3. Batch et streaming ne devraient peut-être plus constituer deux mondes

Pendant longtemps, une grande architecture data pouvait facilement devenir deux architectures :

                    ┌→ Batch → Data Warehouse
Sources ────────────┤
                    └→ Kafka → Streaming → Real-time applications

Cette séparation crée un problème évident.

La logique métier peut finir par être implémentée deux fois.

Deux pipelines.

Deux systèmes de calcul.

Deux façons de corriger les données.

Deux ensembles de résultats à réconcilier.

Les travaux de ByteDance sont particulièrement instructifs à ce sujet.

L’entreprise décrit une évolution progressive : utilisation de Flink pour des synchronisations batch dès 2018, construction en 2020 de pipelines temps réel entre message queues et Hive/HDFS, puis évolution vers un véritable data lake temps réel.

ByteDance a finalement retenu Apache Hudi comme fondation de certains de ces usages, notamment pour sa capacité à gérer efficacement les upserts, CDC et mises à jour incrémentales.

Dans un cas documenté par ses ingénieurs, le passage d’une ingestion Spark offline à une intégration Flink/Hudi a ramené la visibilité de certaines données de plus d’une heure à environ 5 à 10 minutes, tout en réduisant fortement les ressources de calcul dans le scénario comparé.

La leçon dépasse largement Flink ou Hudi :

Le streaming ne devrait pas nécessairement être une architecture parallèle au warehouse. Il peut devenir une propriété du système analytique lui-même.

4. Une seule donnée ne signifie pas un seul moteur

C’est probablement l’une des idées les plus intéressantes du corpus chinois.

Dans beaucoup d’entreprises, chaque nouveau besoin entraîne historiquement une nouvelle copie :

ERP
 │
 ├──→ Warehouse → BI
 │
 ├──→ Data Lake → Data Science
 │
 ├──→ Elasticsearch → Search
 │
 ├──→ Kafka → Real time
 │
 └──→ ML Platform → AI

Cette architecture fonctionne.

Mais plus elle grandit, plus une question devient embarrassante :

combien de représentations différentes de la même réalité métier sommes-nous en train de maintenir ?

Tencent a formulé le problème d’une manière particulièrement claire : serait-il possible qu’une même donnée satisfasse presque tous les scénarios Big Data ?

Dans l’architecture SSOT présentée par Tencent Cloud, l’idée proposée est que la majorité des données du lac soient partagées entre plusieurs moteurs et clusters, qu’une partie des données transactionnelles puisse être interrogée par fédération et que seules les données nécessitant des performances extrêmes soient matérialisées dans un stockage spécialisé.

Le principe qui en ressort est remarquable :

Single Source of Truth ne signifie pas Single Engine.

Une donnée peut être unique tout en étant consommée par plusieurs moteurs.

5. Amener le calcul vers la donnée plutôt que la donnée vers chaque calcul

Cette idée conduit naturellement au multi-engine architecture.

Alibaba documente aujourd’hui une architecture MaxCompute dans laquelle stockage et calcul sont séparés, les métadonnées peuvent être exposées de manière unifiée et différents moteurs peuvent accéder aux données sous gouvernance commune. L’architecture prévoit également du calcul fédéré entre warehouse, data lakes et bases de données.

ByteDance retrouve une logique comparable : les données Hudi peuvent notamment être consommées depuis Flink, Spark ou Presto.

Le raisonnement architectural devient alors :

                     Spark
                       ↑
                       │
Flink ←────── DATA + METADATA ──────→ Presto
                       │
                       ↓
                      AI

plutôt que :

Data → copie Spark
Data → copie BI
Data → copie ML
Data → copie temps réel

Cela renverse une intuition classique.

L’objectif n’est pas nécessairement de trouver le moteur universel.

Il peut être plus réaliste d’accepter qu’un moteur SQL interactif, un moteur streaming et un moteur ML possèdent des propriétés différentes, tout en évitant que cette spécialisation conduise à multiplier inutilement les données.

6. Le choix technologique part du workload

Le retour d’expérience de ByteDance autour de Hudi est particulièrement révélateur de cette culture.

L’entreprise a comparé notamment Iceberg et Hudi. Elle reconnaissait explicitement les qualités respectives des deux technologies : Iceberg pour certaines abstractions, évolutions de schéma et optimisations ; Hudi pour les upserts, les mises à jour quasi temps réel et les traitements incrémentaux.

La décision s’est finalement appuyée sur une question beaucoup plus concrète :

quel système répond le mieux à notre besoin CDC ?

C’est une excellente discipline d’architecture.

On ne commence pas par :

« Nous devons faire du lakehouse. »

On commence par :

« Quelle est la propriété du workload que nous devons optimiser ? »

Latence ?

Throughput ?

Upsert ?

Coût ?

Ad hoc analytics ?

Disponibilité ?

Machine learning ?

Concurrence ?

Puis vient le choix technologique.

7. Le coût n’est pas une conséquence de l’architecture : c’est une dimension de l’architecture

Cette obsession du workload conduit directement au coût.

Le raisonnement est assez simple.

Si le stockage et le calcul sont intimement liés, augmenter l’un peut conduire à augmenter l’autre.

La séparation compute/storage permet au contraire de faire évoluer les ressources indépendamment.

Mais le corpus chinois pousse le raisonnement plus loin : réduire les copies de données, mutualiser le stockage et choisir le moteur selon le workload devient également une stratégie FinOps.

Dans la présentation de l’architecture Lakehouse Analysis Service issue de l’écosystème ByteDance/Volcano Engine, la séparation stockage-calcul permet à une même donnée d’être exploitée par plusieurs moteurs ; l’architecture documentée revendique également une réduction de TCO de l’ordre de 30 à 50 % dans le contexte présenté.

Il faut évidemment considérer ce chiffre comme celui communiqué pour cette solution et non comme une propriété générale du lakehouse.

Mais le principe est plus intéressant que le chiffre :

Le coût marginal d'une donnée supplémentaire et d'un workload supplémentaire devrait être une préoccupation de design.

Le FinOps commence donc sur le tableau blanc de l’architecte, pas après réception de la facture cloud.

8. La donnée ne termine pas nécessairement sa vie dans un dashboard

C’est peut-être la leçon la plus importante pour les environnements BI traditionnels.

Dans l’architecture classique :

Sources
   ↓
  ETL
   ↓
Warehouse
   ↓
Datamart
   ↓
Dashboard

Le dashboard représente pratiquement la destination finale.

Dans plusieurs architectures chinoises étudiées, l’ADS signifie précisément Application Data Store.

Et les usages documentés ne s’arrêtent pas au reporting.

Les données peuvent servir :

• des interfaces temps réel ;
• des systèmes de recommandation ;
• des alertes ;
• des mécanismes de régulation du trafic ;
• des applications ;
• des API ou RPC ;
• des modèles de machine learning.

Dans l'architecture Xianyu documentée par Alibaba, l'ADS alimente ainsi reporting, monitoring, alertes, contrôle du trafic et services externes.

Une documentation Alibaba récente va jusqu'à donner comme exemples d'ADS un reporting dirigeant, mais également une liste d'utilisateurs destinée à un système de recommandation ou à une action opérationnelle.

Cela transforme la mission du data warehouse.

Il n’est plus uniquement un système d’observation de l’entreprise.

Il devient progressivement un composant du fonctionnement de l’entreprise.

Alors, qu’y a-t-il réellement de chinois dans tout cela ?

Il faut être précis.

Presque aucune de ces idées n’est exclusivement chinoise.

Les architectures occidentales utilisent elles aussi CDC, streaming, Hudi, Iceberg, stockage objet, lakehouse, séparation compute/storage et fédération de requêtes.

Il serait donc artificiel d’opposer :

architecture occidentale contre architecture chinoise.

La différence semble davantage résider dans le centre de gravité.

Une partie importante de la littérature data occidentale récente s’est intéressée à des problématiques telles que :

domain ownership, Data Mesh, Data Products, self-service, gouvernance fédérée et autonomie des équipes.

La littérature technique chinoise que nous venons d’étudier semble particulièrement insistante sur une autre série de problèmes :

temps réel, circulation de la donnée, industrialisation, mutualisation, coûts, performances et exploitation opérationnelle.

On pourrait volontairement caricaturer la différence ainsi :

Cette comparaison n'est volontairement pas une taxonomie universelle. Amazon, Netflix, Uber ou LinkedIn peuvent parfaitement présenter des caractéristiques que nous qualifions ici de « chinoises », tandis que certaines entreprises chinoises restent organisées autour d'architectures beaucoup plus traditionnelles.

Il faut plutôt y voir deux centres de gravité.

La véritable leçon chinoise : réduire la distance entre l’événement et l’action

En prenant du recul, un principe semble relier Alibaba, ByteDance, Tencent et les autres cas étudiés.

Ce n'est ni Flink.

Ni Hudi.

Ni Hologres.

Ni le lakehouse.

C'est la réduction de la distance entre l'événement métier et son exploitation.

EVENT
  ↓
DATA
  ↓
UNDERSTANDING
  ↓
DECISION
  ↓
ACTION
  ↓
NEW EVENT

Dans le commerce électronique, la recommandation, la publicité, la vidéo ou les services numériques, cette boucle possède une valeur économique directe.

Plus elle est courte, plus l'entreprise peut observer et adapter son fonctionnement rapidement.

C'est peut-être pour cela que les architectures chinoises étudiées donnent une telle importance au temps réel, au CDC, aux mises à jour incrémentales et à la capacité de servir directement les applications.

Ce que pourrait en retenir une entreprise française

La bonne conclusion ne serait certainement pas :

« Copions l'architecture d'Alibaba. »

Une banque française, un assureur, un industriel ou une administration n'a ni les mêmes volumes, ni les mêmes contraintes, ni les mêmes métiers.

Mais les questions posées par ces architectures sont universelles.

Combien de fois copions-nous la même donnée ?

Pourquoi maintenons-nous deux chaînes différentes pour le batch et le temps réel ?

Toutes les données ont-elles réellement besoin d'être temps réel ?

À l'inverse, certaines données perdent-elles leur valeur parce que nous les livrons trop tard ?

Avons-nous choisi nos moteurs parce qu'ils correspondent aux workloads, ou parce qu'ils appartiennent à notre plateforme stratégique ?

Notre lakehouse réduit-il réellement la complexité ou a-t-il simplement été ajouté à côté du warehouse existant ?

Combien coûte une nouvelle copie de la donnée pendant cinq ans ?

Et surtout :

la donnée produite par notre plateforme sert-elle uniquement à expliquer ce qui s'est passé, ou permet-elle également au système d'agir ?

De la Business Intelligence à la Business Infrastructure

C'est finalement peut-être la meilleure synthèse.

Pendant plusieurs décennies, l'architecture décisionnelle a principalement cherché à observer l'entreprise.

Le warehouse consolidait.

Le datamart organisait.

La BI expliquait.

Les architectures observées dans les grands écosystèmes numériques chinois suggèrent une étape supplémentaire :

la plateforme data devient progressivement une partie du système nerveux opérationnel de l'entreprise.

Elle reçoit l'événement.

Elle le contextualise.

Elle le combine avec l'histoire.

Elle le rend immédiatement exploitable.

Puis elle permet à une personne, une application ou un algorithme d'agir.

La grande leçon chinoise n'est donc probablement pas une nouvelle technologie.

Elle tient davantage dans une question que tout architecte data devrait désormais se poser :

Combien de temps et combien de systèmes séparent encore un événement métier de la décision qu'il devrait provoquer ?

C'est peut-être là que se joue la prochaine étape de l'architecture des données.