C’est le sale secret du boom de l’IA : les modèles sont géniaux, mais la plomberie est ancienne.
Vous construisez un modèle de transformateur de pointe. Vous sécurisez les clusters GPU H100. Mais ensuite, vous attendez 24 heures pour que le pipeline ETL (Extract, Transform, Load) s’exécute afin que votre modèle puisse réellement voir les nouvelles données de ventes. Au moment où l’inférence s’exécute, le client a déjà changé d’avis.
Il s’agit de la « taxe de friction des données » qui tue le retour sur investissement de l’IA.
En 2025, l’industrie répare enfin la plomberie. Les équipes d’ingénierie passent de l’ère du Data Warehousing à l’ère des Plateformes de données unifiées, en particulier des architectures construites autour d’une philosophie « Zéro copie ». Si vous construisez des systèmes d’IA, vous devez comprendre pourquoi la copie de données devient un anti-modèle architectural.
La physique du problème : pourquoi ETL évolue mal
Pour comprendre pourquoi Zero-Copy est important, il faut examiner l’inefficacité des piles traditionnelles.
Dans une entreprise standard, les données vivent efficacement dans des « puits gravitationnels » : Salesforce pour CRM, SAP pour ERP, AWS S3 pour les journaux. Pour analyser ces données, les ingénieurs construisaient historiquement des pipelines pour les copier physiquement de la source A vers la destination B (généralement un entrepôt de données comme Redshift ou Snowflake).
Cela introduit une équation fondamentale de latence :
Chaque fois que vous copiez des données, vous introduisez :
- Latence : le problème des « données obsolètes ». Si le pipeline fonctionne la nuit, l’IA a toujours 24 heures de retard sur la réalité.
- Coût : les entreprises paient des frais de stockage spécifiques pour le duplicata. Le stockage de 1 Po de données est gérable ; en stocker 5 exemplaires (Raw, Bronze, Silver, Gold, Warehouse) est exorbitant.
- Surcharge de sérialisation : le coût du processeur lié à la standardisation de JSON/CSV en Parquet/Avro (SerDes) consomme d’énormes quantités de calcul qui pourraient être utilisées pour l’inférence.
- Drift : le schéma de la source A change (par exemple, un développeur renomme
user_idenuuid), interrompant ainsi le pipeline vers la destination B.
Dataversity prévient que la mauvaise qualité des données, souvent due à ces pipelines fragiles, pourrait entraîner l’abandon de 60 % des projets d’IA au cours de l’année à venir. La solution ne réside pas dans des pipelines plus rapides ; ce n’est pas de pipelines.
L’évolution de la gravité des données
Pour apprécier la révolution Zero-Copy, il est utile de cartographier la trajectoire de l’architecture des données au cours des deux dernières décennies. L’industrie a oscillé entre couplage et découplage.
Phase 1 : Le Monolithe (1990-2010)
Au début, il y avait la base de données Oracle. Le stockage et le calcul étaient étroitement couplés. Si vous vouliez exécuter une requête plus rapide, vous achetiez une boîte plus grande. C’était cohérent et rapide (conforme à l’ACID), mais il ne pouvait pas évoluer horizontalement. Il s’étouffait avec le volume de données à l’échelle du Web.
Phase 2 : Le Data Lake / Le « Marais » (2010-2018)
L’ère Hadoop a introduit HDFS. La philosophie était « Schéma en lecture ». Videz simplement tous les journaux JSON dans un stockage bon marché et découvrez-le plus tard. Cela a résolu le problème des coûts de stockage mais a créé un « marécage ». Les performances des requêtes étaient épouvantables et sans transactions, l’intégrité des données disparaissait. Les modèles d’IA entraînés sur ces données hallucinaient fréquemment parce que les données d’entrée étaient erronées ou incomplètes.
Phase 3 : L’entrepôt cloud (2018-2023)
Snowflake et BigQuery ont séparé le stockage (S3/GCS) du calcul. Ce fut une percée. Vous pouvez faire évoluer le stockage à l’infini et lancer des clusters de calcul à la demande. Cependant, le format restait propriétaire. Pour utiliser Snowflake, vous deviez COPY INTO Snowflake. Les données étaient verrouillées dans leurs micro-partitions. Il fallait quand même déplacer les octets.
Phase 4 : Le Lakehouse sans copie (2024+)
C’est le point d’inflexion actuel. Les données restent dans S3, mais dans des formats ouverts (comme Apache Iceberg). Le moteur de calcul (Snowflake, Spark, Trino, Dremio) visite les données là où elles se trouvent. Il n’y a pas de COPY INTO. Il n’y a que SELECT * FROM.
Analyse technique approfondie : comment fonctionne réellement le Zero-Copy
« Zero-Copy » est un terme inapproprié. Les bits existent sur un disque quelque part. D’un point de vue architectural, cependant, cela signifie que le système ne déplace pas les octets vers le calcul ; il apporte les autorisations de calcul aux octets (ou plus précisément, partage les pointeurs).
Les « formats de table ouverte » modernes comme Apache Iceberg, Delta Lake et Apache Hudi sont les catalyseurs ici. Ils permettent à différents moteurs de calcul d’examiner les mêmes fichiers dans le stockage d’objets sans avoir besoin de les « posséder ».
La couche de métadonnées
La magie opère dans les métadonnées. Au lieu de copier une table de 10 To, un système Zero-Copy partage un fichier manifeste : une liste de pointeurs vers les fichiers Parquet stockés dans S3.
Lorsqu’un ingénieur « clone » une base de données dans Snowflake ou crée une branche dans Dremio Arctic, le système ne duplique pas les 10 To. Il duplique les métadonnées (kilo-octets) et les pointe vers les mêmes blocs de stockage sous-jacents.
Les mécanismes de l’isolement : Zero-Copy s’appuie fortement sur Snapshot Isolation.
- La Liste des manifestes pointe vers un « instantané » spécifique (par exemple, l’instantané S1).
- L’instantané S1 pointe vers un ensemble de fichiers manifestes.
- Les fichiers manifestes pointent vers les fichiers de données réels (Parquet).
Lorsqu’un modèle d’IA commence l’entraînement à 10h00, il se verrouille sur Snapshot S1. Si une tâche ETL met à jour la table à 10h05, elle crée un instantané S2 (écriture de nouveaux fichiers Parquet et d’un nouveau manifeste). Le modèle d’IA continue de lire S1 sans être dérangé. Il n’y a pas de verrous et aucun lecteur ne bloque les écrivains.
Optimisation du refoulement des requêtes :
Le moteur analytique envoie les filtres à la base de données source. Si la requête demande SELECT * WHERE region = 'Western-Region', le système source utilise les métadonnées pour identifier quelles micro-partitions spécifiques contiennent des données « Région occidentale ». Il renvoie uniquement ces blocs spécifiques. Cela réduit efficacement le transfert réseau de plusieurs ordres de grandeur par rapport à une analyse de table complète.
Le concept “Unistore”
Le but ultime de Zero-Copy est l’unification des charges de travail transactionnelles (OLTP) et analytiques (OLAP), un concept souvent appelé HTAP (Hybrid Transactional/Analytical Processing).
Les paradigmes Unistore de Snowflake et Lakehouse de Databricks visent à combler cet écart. Imaginez une application de vente au détail dans laquelle un achat est écrit dans un magasin en ligne transactionnel. Dans un monde traditionnel, cette ligne n’apparaîtrait pas dans l’entrepôt d’analyse avant le travail par lots nocturne. Dans un monde Unistore sans copie, cette ligne est immédiatement visible par le moteur analytique via une abstraction de table unifiée.
Pour l’IA, cela change la donne. Les systèmes de recommandation peuvent réagir au clic d’un utilisateur au cours de la même session, et pas seulement le lendemain.
La réalité de 2026 : les « écosystèmes vivants »
Ce changement architectural ne concerne pas seulement l’économie d’espace disque. Il s’agit d’une question d’agilité organisationnelle.
Les perspectives des services financiers 2026 de Slalom prédisent le passage de « solutions statiques et cloisonnées » à des « écosystèmes vivants et adaptatifs » où les données circulent librement. Ils identifient les Fondations de données unifiées comme condition préalable à cela. Si l’IA de détection de fraude d’une banque doit attendre un travail par lots nocturne, elle est inutile contre les menaces en temps réel de 2026. Le rapport souligne que « la gouvernance permet à la fois rapidité et confiance », suggérant que la couche de métadonnées deviendra le nouveau plan de contrôle.
Les tendances technologiques de McKinsey renforcent ce point, en soulignant que le « déficit d’exécution » dans l’IA est en grande partie un problème de disponibilité des données. Leur analyse suggère que les organisations capables d’agir sur la base d’informations en temps réel sont 1,6 fois plus susceptibles de connaître une croissance à deux chiffres. La possibilité d’interroger les données « sur place » permet de créer des produits de données instantanément utilisables par d’autres équipes sans avoir à créer de nouveaux pipelines.
L’essor de l’architecture de données « sans tête »
Tout au long de l’année 2026, les analystes s’attendent à une domination des architectures de données « sans tête ». Dans ce modèle, le stockage et la couche sémantique sont totalement découplés de l’outil de consommation.
- Stockage : S3/Azure Blob (bon marché, infini).
- Format : Iceberg/Delta (Ouvert, Transactionnel).
- Catalogue : Nessie/Unity Catalog (Le “Cerveau” gardant la trace des pointeurs).
- Calcul : tout ce que l’utilisateur souhaite. Le Data Scientist utilise PySpark ; l’analyste utilise SQL ; le PDG utilise un tableau de bord. Ils touchent tous à la même source unique de vérité.
Conclusion : La plateforme est le pipeline
Pour l’ingénieur de données, l’ensemble des compétences évolue. L’écriture de scripts PySpark ETL efficaces pour déplacer les données d’un point A vers un point B devient moins utile que la conception de stratégies robustes de gouvernance des métadonnées. La valeur ne réside pas dans le déplacement des données ; il s’agit de rendre les données accessibles sans les déplacer.
Le pipeline, tel qu’on l’entend traditionnellement, est mort. Vive la plateforme.
Nos sources (5)
- engineering.salesforce.com Zero Copy Revolutionizes Data Cloud
- slalom.com Financial Services Outlook 2026
- dataversity.net Data Management Trends 2026
- mckinsey.com Top Trends in Tech 2025
- arcadia.io Zero-Copy Data Lake
🦋 Discussion sur Bluesky
Discuter sur Bluesky