Le verrouillage par la donnée ne porte pas sur la donnée, mais sur ce qu'elle attire ; réversibiliser la donnée seule laisse intacte la structure qui retient.

McCrory (2010) établit la direction du mouvement : passé un certain volume, le calcul migre vers la donnée. Son modèle ne formalise pas, en revanche, ce qui se produit lorsque ce calcul opère en continu sur un flux plutôt que sur un stock interrogé ponctuellement. Le présent volume propose d'actualiser la data gravity aux contraintes des pipelines temps réel par la notion d'inertie cinétique : la masse opérationnelle d'un jeu de données ne se mesure plus seulement à son volume stocké, mais à la rupture de latence que provoquerait l'éloignement du calcul qui la traite en continu. Ce n'est pas une conséquence directe du modèle original de McCrory, mais une extension proposée ici pour rendre compte des architectures de streaming et de traitement quasi temps réel apparues depuis 2010.

Le format propriétaire historique de Snowflake (micro-partitions) a longtemps rendu la donnée illisible hors de la plateforme. L'adoption récente du format ouvert Apache Iceberg atténue cette contrainte sans la supprimer : les catalogues restent, dans de nombreuses configurations, gérés par Snowflake, et des coûts de sortie s'appliquent dès qu'un traitement s'exécute ailleurs. L'écosystème natif — Marketplace, applications natives, résolution d'identité exécutée sur place — matérialise la gravité en acte : ce sont le calcul et les services tiers qui viennent à la donnée, non l'inverse.

Databricks oppose à l'accusation de verrouillage un argument d'ouverture par construction : Delta Lake open source dès l'origine, Unity Catalog lui-même open-sourcé, interopérabilité revendiquée avec les formats Iceberg et Parquet. Cet argument porte sur la bonne couche mais pas sur la bonne question. La gravité ne réside plus dans l'extension du fichier — celle-ci est effectivement ouverte — mais dans la centralisation du plan de gouvernance : un métastore unique, un système de lignage unique, des politiques d'accès définies une seule fois pour l'ensemble des usages. Quitter la plateforme laisse le fichier accessible ; cela ne restitue ni le graphe de lignage, ni la structure de gouvernance qui gouvernait son accès, qu'il faut reconstruire intégralement ailleurs. Un format ouvert au niveau du fichier n'implique pas un centre de gravité ouvert au niveau organisationnel.

L'intégration native de BigQuery avec Vertex AI et Looker permet l'entraînement et l'exécution de modèles directement en SQL, sans export préalable de la donnée. BigQuery Omni autorise l'interrogation de données situées hors de Google Cloud, mais l'orchestration de ce service reste pilotée depuis Google Cloud. L'écart n'est pas seulement contractuel : aux tarifs standard 2026, l'egress internet facturé par Google Cloud s'échelonne de 0,08 à 0,12 dollar par gigaoctet selon le palier de volume, et jusqu'à 0,23 dollar par gigaoctet pour un transit intercontinental — soit, pour un pétaoctet exporté, un ordre de grandeur de 80 000 à plus de 200 000 dollars. Un traitement in situ, dans la même région, sur un service Google natif via l'accès privé Google, n'engage en comparaison aucun frais de sortie. Le temps de transfert renforce ce constat : à un débit soutenu de 10 Gbit/s, déplacer un pétaoctet demande de l'ordre de neuf jours de transfert continu — une limite physique théorique optimale, calculée sans dégradation, sans contention et sans interruption, donc un plancher, non une moyenne observée. Que ce plancher théorique s'établisse déjà à l'échelle de la semaine suffit à lui seul à ruiner la viabilité opérationnelle de tout pipeline externe construit sur ce jeu de données : aucune amélioration réaliste des conditions de transfert ne ramènera ce délai à l'échelle de la milliseconde qu'exige un traitement in situ. Le verrouillage qui en résulte n'est alors plus une politique de prix réversible, mais une conséquence de la physique du transfert elle-même. Vertex AI et Looker sont donc structurellement incités à opérer sur une donnée déjà résidente dans BigQuery non par choix contractuel, mais parce que le coût et le temps de tout autre scénario sont mesurables et prohibitifs à l'échelle du pétaoctet.

Le mécanisme de coûts de changement formalisé par Klemperer (1987) reposait, dans sa composante la plus directement chiffrable, sur la capacité du prestataire en place à facturer la sortie elle-même — la taxe d'extraction réseau documentée en I.2 pour Snowflake, Databricks et BigQuery. L'article 29 neutralise précisément cette composante : à compter du 12 janvier 2027, aucune plateforme ne pourra plus opposer un ordre de grandeur de 80 000 à plus de 200 000 dollars par pétaoctet exporté pour dissuader un changement de prestataire. Sur ce plan tarifaire précis, le bouclier réglementaire fonctionne.

Le Chapitre I.2 a établi, pour Databricks, que la gravité ne réside plus dans le format du fichier — déjà ouvert — mais dans la centralisation du plan de gouvernance : un métastore unique, un système de lignage unique. Pour BigQuery, la gravité procède de l'intégration native avec Vertex AI et Looker. Ni le métastore et le graphe de lignage d'un catalogue de gouvernance, ni les modèles de machine learning entraînés sur la donnée en place, ni les tableaux de bord et pipelines construits sur cette intégration native ne relèvent du « service de base » que l'article 30 oblige à rendre fonctionnellement équivalent ailleurs. La gratuité de sortie obtenue par l'article 29 s'applique au transport de la donnée ; elle ne s'étend pas à la reconstruction de ce qui a été agrégé autour d'elle.

Le mécanisme documenté en I.1 suppose une masse accumulée en un point unique. La première réponse architecturale consiste à empêcher qu'un tel point unique se constitue : répartir le patrimoine de données selon des frontières de domaine métier plutôt que de le consolider dans un entrepôt analytique unique, de sorte qu'aucun sous-ensemble ne franchisse seul le volume critique qui déclenche la dynamique gravitationnelle.

La donnée de chaque domaine est stockée dans un format de table ouvert, interrogeable directement par n'importe quel moteur de calcul compatible, sans duplication préalable dans le format propriétaire d'une plateforme donnée. Le Chapitre I.2 a établi, pour Databricks, que l'ouverture du format de fichier ne suffit pas à elle seule à supprimer la gravité si le catalogue de gouvernance — métastore, lignage, contrôle d'accès — reste, lui, hébergé et opéré par un seul fournisseur. La présente proposition retient donc que la couche de gouvernance elle-même doit être hébergeable indépendamment de tout éditeur unique, faute de quoi le découplage au niveau du fichier ne fait que déplacer la gravité d'un étage, sans la supprimer — exactement le mécanisme documenté en I.2.

Fragmenter la donnée par domaine dégrade les requêtes transverses : une jointure portant sur plusieurs domaines exige de traverser plusieurs catalogues plutôt qu'une source unique de vérité instantanée, avec un coût de latence et d'ingénierie que ne connaît pas un entrepôt consolidé. Découpler le calcul de la donnée prive également l'organisation des optimisations propriétaires — indexation avancée, mise en cache intégrée, accélération native — qu'un fournisseur unique peut offrir précisément parce qu'il contrôle l'ensemble de la pile. Chaque domaine doit enfin maintenir son propre effort d'intégration et de gouvernance, dupliquant un travail qu'une plateforme centralisée mutualiserait.

Le Chapitre I a établi que la donnée accumulée exerce une attraction physique et économique sur le calcul et les services qui l'entourent, indépendamment de toute clause portant sur la donnée seule. Le Chapitre II a établi que le Data Act européen neutralise réellement la composante tarifaire de ce mécanisme, mais laisse hors de son périmètre la couche de gouvernance, de métastore et de modèles agrégée par-dessus le service de base. Le Chapitre III répond spécifiquement à cette limite par une fragmentation délibérée et un découplage calcul/donnée par conception, au prix énoncé en III.3 : une performance transverse et une cohérence globale sacrifiées.

Le seul point resté ouvert au moment du cadrage portait sur le Chapitre I.2 : fallait-il nommer les trois acteurs dès le premier jet, ou garder un mécanisme générique jusqu'à un cadrage Gemini ultérieur ? Amine a tranché pour les nommer immédiatement, ce qui a déclenché, avant toute rédaction, une recherche indépendante sur chacun des trois acteurs — leur format de stockage, leur catalogue de gouvernance, leurs tarifs de sortie réseau — plutôt qu'une intégration de mémoire.

La correction demandée portait sur deux points distincts. D'une part, la requalification explicite de l'inertie cinétique comme extension proposée par ce volume plutôt que conséquence directe de McCrory. D'autre part, l'injection d'un ordre de grandeur empirique sur BigQuery : plutôt que d'avancer un chiffre de mémoire, une recherche indépendante a vérifié les tarifs d'egress Google Cloud 2026 (0,08 à 0,23 dollar par gigaoctet selon la destination) et le débit de référence de 10 Gbit/s, permettant de calculer un ordre de grandeur de 80 000 à plus de 200 000 dollars par pétaoctet exporté, puis un temps de transfert théorique d'environ neuf jours, lissé dans un second temps pour être qualifié explicitement de limite physique plancher plutôt que de moyenne observée.

Cet audit global a produit une recommandation d'enrichissement théorique pour la section I.1 — une référence complémentaire destinée à armer le passage de la dépendance logicielle individuelle à la capture par l'écosystème tiers. Une recherche indépendante n'a permis de confirmer ni l'année ni le contenu exact de la référence proposée. Plutôt que de l'intégrer sous réserve, la référence a été explicitement abandonnée : contrairement au Volume VII, où l'audit global avait produit un enrichissement effectivement intégré (Teece, 1986), l'audit global de ce volume a ici été suivi d'un retrait, la règle de vérification factuelle s'appliquant à une recommandation de l'audit global au même titre qu'à tout autre exemple nommé.