Quand l’architecture défie la gravité, ce sont les opérations qui en paient le prix

• • Les piles intégrées au stockage supposent que les données arrivent dans l’espace de nommage. Les contraintes qui s’exercent sur l’infrastructure d’une entreprise montrent que ce ne sera pas le cas.
  • La promesse d’un « espace de nommage unifié » est un pari à l’encontre des trois formes de données.
  • Le coût architectural est structurel : responsabilité des pipelines, dette de réconciliation, couplage des schémas, double tenue de la gouvernance, opacité des coûts.
  • Les contraintes externes (réglementation, couplage applicatif, contrats, propriété) rendent ce coût permanent, et non transitoire.
  • Un plan de contrôle fédéré agit sur les données à leur emplacement d’origine et ne les déplace que lorsque cela est pertinent.

Si vous évaluez des plateformes de données d’IA, les éléments de la proposition commerciale ne sont pas les seuls coûts à prendre en compte. La vraie facture apparaît plus tard : dans les pipelines que vous devez construire, les ressources humaines que vous mobilisez pour les maintenir en fonctionnement et la perte d’optionalité chaque fois que les données doivent être déplacées simplement pour être exploitables.

Data has gravity, the real enterprise estate is full of distortions that hold data in place, and “data” itself isn’t one substance — it’s three forms (data, metadata and vectors), each with different characteristics and requirements. This post is about what happens when an architecture pretends those laws don’t apply.

L’hypothèse architecturale sous-jacente à chaque pile intégrée au stockage

Les piles d’IA intégrées au stockage, dont VAST AI OS est l’exemple le plus visible, reposent sur une hypothèse unique : les services d’IA s’exécutent sur des données déjà présentes dans la plateforme. Ces données doivent donc être hébergées sur cette dernière. Tout ce qui se trouve en dehors de l’espace de nommage est, de son point de vue, invisible.^1,4

Ainsi, la plateforme est fournie avec des outils permettant d’y rapatrier les données. Elle s’accompagne d’un discours selon lequel la centralisation des données simplifie les opérations. Elle propose également une interface utilisateur unifiée qui, dans la démo, donne l’impression d’un ensemble homogène et parfaitement unifié.

Ce discours présente une cohérence interne. Mais il constitue aussi un pari à l’encontre des forces structurelles à l’œuvre dans les infrastructures réelles des entreprises.

Les trois formes montrent qu’il n’est pas nécessaire de déplacer les données les plus volumineuses.

Ce que les entreprises appellent « données » recouvre en réalité trois éléments distincts :

• • Données — Lourdes. Restent là où elles se trouvent. Fichiers, enregistrements, images, vidéos, télémétrie, tableaux réglementés.
  • Métadonnées — Légères. Diffusion peu coûteuse. Permettent à chaque système d’IA d’avoir une visibilité sur tous les actifs, où qu’ils se trouvent.
  • Vecteurs — Sensibles à la localité. Transmettent du sens à travers l’infrastructure sans déplacer les données elles-mêmes.

Les architectures qui traitent ces trois éléments comme la même substance aboutissent à une réponse inadaptée : tout déplacer. Celles qui les traitent distinctement peuvent laisser les données gouvernées volumineuses là où elles se trouvent, diffuser les métadonnées à travers l’ensemble de l’infrastructure et laisser les vecteurs assurer le raisonnement transversal dont l’IA a réellement besoin.

Un espace de nommage unifié constitue une réponse cohérente si la seule forme reconnue est celle des données. Il devient une mauvaise réponse dès lors que l’on admet que les métadonnées et les vecteurs existent en tant qu’éléments à part entière.

Le coût structurel de l’architecture consistant à rapatrier l’ensemble des données

Lorsqu’une architecture repose sur l’hypothèse que les données doivent être réunies au préalable pour que l’IA puisse y accéder, chaque contrainte externe devient, au sein de l’entreprise, une obligation opérationnelle :

• • Responsabilité du pipeline. Toutes les sources, y compris Snowflake, SharePoint, S3, Kafka, le stockage tiers, les solutions SaaS, nécessitent un processus de synchronisation ¹. Chaque synchronisation implique une intervention humaine.
  • Dette de réconciliation. Chaque copie finit par diverger de sa source. Les schémas évoluent, des pics de latence apparaissent selon les régions, et des troncatures silencieuses surviennent lorsque la longueur des champs sources change sans que personne n’en soit informé. Quelqu’un doit en permanence détecter et corriger ces écarts.
  • Couplage des schémas. Lorsque les systèmes sources évoluent, les copies en aval cessent de fonctionner et les services d’IA qui en dépendent sont impactés à leur tour.
  • Double tenue de la gouvernance. Les contrôles d’accès, les politiques de conservation, les obligations réglementaires et les pistes d’audit doivent être conservés en double, à la source comme dans les copies.
  • Opacité des coûts. Votre équipe FinOps doit désormais suivre les flux de données, la duplication du stockage et les frais de sortie dans une architecture pourtant présentée comme une consolidation.

Rien de tout cela n’est dissimulé intentionnellement. Il s’agit d’une contrainte structurelle. C’est ce qui se produit lorsqu’un modèle fermé, intégré au stockage, se heurte à une infrastructure ouverte et distribuée : il cherche à la rapatrier dans son périmètre^1,4.

Le vocabulaire employé par les fournisseurs est ici déterminant. « Le moteur de synchronisation est gratuit » et « la synchronisation est gratuite » ne sont pas des phrases équivalentes. Une synchronisation n’est pas une migration ponctuelle. C’est une relation permanente entre deux systèmes, qui doivent rester cohérents dans la durée : malgré les évolutions de schéma, les incidents réseau, les changements d’autorisation, les politiques de conservation, les contraintes réglementaires et les pannes occasionnelles de part et d’autre⁴. Multipliez cela par chaque système source sollicité par vos charges applicatives d’IA et vous n’avez pas simplifié votre architecture. Vous avez ajouté un nouveau plan de copie spécifique au fournisseur qui fonctionne sous le plan de copie existant¹.

Les contraintes externes rendent ce coût permanent

Si ce coût ne s’atténue pas avec le temps, c’est parce que les forces qui le génèrent ne sont pas transitoires. Elles constituent des caractéristiques structurelles de l’entreprise :

• • Contraintes réglementaires et de souveraineté. RGPD, HIPAA, lois de localisation des données, contrôles à l’exportation. Certaines données doivent être traitées là où elles se trouvent. Une tâche de synchronisation qui franchit une frontière de souveraineté devient une tâche de synchronisation susceptible de se transformer en incident de conformité.
  • Exigences des applications. Les applications faisant autorité, telles que les ERP, CRM, dossiers médicaux électroniques et systèmes transactionnels, sont étroitement liées à leurs propriétaires. Elles n’ont pas été conçues pour alimenter un espace de nommage propre à un fournisseur. Elles ont été conçues pour faire fonctionner l’entreprise.
  • Friction contractuelle. Les frais de sortie des hyperscalers et les formats exclusifs rendent l’extraction des données plus coûteuse que leur maintien en place. Le fait de déplacer des données pour les rapatrier ailleurs devient une ligne de coût que votre direction financière finira inévitablement par identifier.
  • Dynamique organisationnelle. Deux unités opérationnelles revendiquant les mêmes données, l’intégration soudaine de l’infrastructure d’une société acquise, un responsable qui refuse de lever des contraintes de gouvernance : l’organisation hiérarchique prime régulièrement sur l’idéal architectural.
  • Données inconnues ou non cataloguées. Des données dont on sait qu’elles existent, mais qu’il est impossible de recenser. Vous ne pouvez pas synchroniser ce que vous ne trouvez pas. Et ce que vous ne pouvez pas synchroniser reste invisible pour l’IA, du moins dans un modèle intégré au stockage.

Chacune de ces contraintes constitue une caractéristique permanente de l’environnement dans lequel opère une entreprise. Les architectures qui supposent qu’elles disparaîtront devront en supporter le coût indéfiniment.

L’alternative fédérée

La plateforme de données d’IA de Dell repose sur un postulat fondamentalement différent. Plutôt que d’exiger des clients qu’ils répliquent leurs données dans un espace de nommage contrôlé par un fournisseur avant de les exploiter, l’approche de Dell repose sur un modèle fédéré : un plan de contrôle intervient directement sur les données là où elles se trouvent (qu’il s’agisse de PowerScale, ObjectScale, de stockages tiers, d’entrepôts, de solutions SaaS ou du Cloud public) et ne les déplace que lorsque cela s’impose réellement^4,5.

Cette décision de conception unique est une application directe des trois formes de cadrage :

• • Les données restent là où elles se trouvent et sont régies par les équipes qui en ont déjà la responsabilité.
  • Les métadonnées se propagent partout, permettant à chaque système d’IA d’avoir une visibilité sur tous les actifs, indépendamment de leur localisation.
  • Les vecteurs véhiculent le sens à travers l’ensemble de l’infrastructure, de sorte que l’IA peut raisonner sur les données sans avoir à les déplacer au préalable.

Cela ne signifie pas pour autant que les architectures fédérées ne déplacent jamais les données. Elles le font lorsque cela a du sens. En revanche, elles ne font pas du déplacement des données une condition préalable à la création de valeur sur la plateforme. Ce choix architectural unique permet d’éliminer l’essentiel du coût opérationnel décrit précédemment, car ce coût n’existe que si l’architecture repose sur l’hypothèse que les données doivent être déplacées avant que l’IA puisse y accéder⁴.

Il préserve également ce qui importe le plus à la direction financière : l’optionalité. Un plan de contrôle fédéré n’enferme pas l’architecture dans un espace de nommage d’un fournisseur. Il maintient les données là où elles se trouvent déjà, sous la gouvernance des équipes en place et les rend exploitables par l’IA sans nécessiter leur déplacement^2,4.

Les analystes indépendants commencent de plus en plus à mettre en lumière cette dynamique. Un article récent souligne que, malgré la prise en charge de normes ouvertes par VAST, son « architecture unifiée pourrait créer des dépendances rendant les migrations futures plus difficiles ». Une manière élégante de dire que plus vous synchronisez de données, plus il devient difficile de s’en extraire². Un autre article observe que l’approche de VAST est « plus proche du modèle d’infrastructure hyperconvergée, avec une pile fortement intégrée et prescriptive, où VAST contrôle l’ensemble de l’expérience »³. L’infrastructure hyperconvergée a déjà montré ce qui se produit lorsque ce modèle est confronté à l’hétérogénéité à grande échelle. Les mêmes enseignements s’appliquent ici.

Trois questions à se poser avant de s’engager

À intégrer directement dans votre appel d’offres.

1. 1. À l’état stable, combien de pipelines devront alimenter votre espace de nommage ? Demandez une estimation réaliste fondée sur une infrastructure comparable à la vôtre et non sur une architecture de référence conçue pour un environnement vierge. Confrontez cette estimation à vos contraintes réglementaires et vos dépendances applicatives.
   2. Qui prend en charge la réconciliation lorsqu’un système source évolue ? Si la réponse est « vos équipes, avec nos outils », vous tenez là votre coût opérationnel. Chiffrez-le.
   3. Si je souhaite interrompre la synchronisation d’une source au cours de la troisième année, que se passe-t-il concrètement ? La réponse donne une mesure directe de l’optionalité que vous abandonnez et du degré de friction que l’architecture introduit en matière de sortie.

En résumé : ne payez pas pour une infrastructure dont le coût ne vous a jamais été clairement annoncé.

Prochaines étapes

Dans le prochain billet, j’aborderai à nouveau le sujet du data center, car ce coût architectural ne se résume pas à une question d’ETP. C’est aussi une question d’économie des processeurs graphiques. Lorsque les données doivent être préalablement rapatriées avant que les calculs puissent s’exécuter, le poste le plus coûteux de votre infrastructure IA est celui qui finit par en supporter la facture.

¹ VAST Data, « DataSpace and SyncEngine », documentation sur le produit.

² DataPro.news, « VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole? » Juin 2025.

³ NAND Research, « How to Think about VAST Data », février 2026.

⁴ Prowess Consulting, « Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS », réalisé à la demande de Dell, avril 2026.

⁵ Dell Technologies, « Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations », PR Newswire, mars 2026.