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

• • Les piles intégrant le stockage supposent que les données arriveront dans l’espace de nommage. Les forces qui s’exercent sur le parc informatique d’une entreprise indiquent que ce ne sera pas le cas.
  • L’argumentaire de l’« espace de nommage unifié » est un pari contre les trois formes de données.
  • Le coût architectural est structurel : propriété des pipelines, dette de rapprochement, couplage des schémas, double comptabilité en matière de gouvernance, opacité des coûts.
  • Les forces externes (réglementation, couplage des applications, contrats, propriété) rendent ce coût permanent, et non transitoire.
  • Un plan de contrôle fédéré fonctionne sur les données là où elles se trouvent, et ne les déplace que lorsque ce déplacement constitue la bonne solution.

Si vous évaluez des plateformes de données d’IA, les postes mentionnés dans le devis ne constituent pas vos seuls coûts. La véritable facture arrive plus tard : dans les pipelines que vous devez construire, dans le personnel que vous affectez à leur maintenance et dans l’optionalité à laquelle vous renoncez chaque fois que les données doivent être déplacées simplement pour être exploitables.

Les données ont une gravité, l’environnement d’entreprise réel est rempli de distorsions qui les maintiennent en place, et les « données » elles-mêmes ne sont pas une substance unique; il s’agit de trois formes (données, métadonnées et vecteurs), chacune ayant des caractéristiques et des exigences différentes. Cet article explique ce qui se passe lorsqu’une architecture refuse de tenir compte de ces lois.

L’hypothèse architecturale sous chaque pile intégrant le stockage

Les piles d’IA intégrant le stockage, dont VAST AI OS est l’exemple le plus connu, sont construites sur une hypothèse architecturale unique : les services d’IA s’exécuteront sur des données déjà stockées dans la plateforme. Ces données doivent impérativement se trouver dans la plateforme. Tout ce qui est en dehors de l’espace de nommage est, du point de vue de la plateforme, invisible^1,4.

Ainsi, la plateforme est livrée avec des outils qui permettent d’importer des données. Elle s’accompagne d’un discours expliquant en quoi la centralisation des données simplifie les opérations. Elle comprend une interface utilisateur unifiée qui, dans la démonstration, donne l’impression que l’ensemble du parc informatique forme un tout homogène.

Ce discours est cohérent en soi. C’est également un pari contre les forces structurelles qui agissent sur les parcs informatiques réels des entreprises.

Les trois formes montrent que vous n’avez pas à déplacer les données lourdes

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

• • Données – Lourdes. Elles restent là où elles sont. Fichiers, enregistrements, images, vidéos, télémétrie, tables réglementées.
  • Métadonnées – Légères. Peu coûteuses à propager. Elles permettent à chaque IA de voir chaque ressource, n’importe où.
  • Vecteurs – Sensibles à la localité. Ils transmettent du sens dans l’ensemble du parc informatique sans transporter les données elles-mêmes.

Les architectures qui traitent ces trois éléments comme une seule et même entité aboutissent systématiquement à une mauvaise solution : tout déplacer. Les architectures qui les traitent comme des entités distinctes peuvent laisser les données lourdes régies là où elles se trouvent, propager les métadonnées dans l’ensemble du parc informatique et laisser les vecteurs effectuer le raisonnement inter-environnement dont l’IA a réellement besoin.

Un espace de nommage unifié est une réponse cohérente si la seule forme que vous reconnaissez est celle des données. Il s’agit de la mauvaise réponse à partir du moment où vous acceptez que les métadonnées et les vecteurs existent en tant qu’éléments à part entière.

Le coût architectural lié à l’internalisation du parc

Lorsqu’une architecture repose sur l’hypothèse selon laquelle les données doivent arriver avant que l’IA puisse y accéder, chaque force externe de votre entreprise devient une obligation opérationnelle :

• • • Propriété des pipelines. Chaque source, notamment Snowflake, SharePoint, S3, Kafka, les solutions de stockage tierces et les logiciels-services, nécessite une tâche de synchronisation¹. Derrière chaque tâche de synchronisation se cache une personne.
    • Dette de rapprochement. Chaque copie s’écarte de sa source. Dérive de schéma, pointes de latence régionale, troncatures silencieuses lorsqu’une longueur de champ source change sans que personne n’en soit informé. Quelqu’un doit détecter et corriger cette dérive, pour toujours.
    • Couplage des schémas. Lorsque les systèmes sources changent, les copies en aval cessent de fonctionner et les services d’IA qui en dépendent tombent en panne avec elles.
    • Double comptabilité en matière de gouvernance. Les contrôles d’accès, les politiques de conservation, les mises en suspens réglementaires et les pistes de vérification doivent être gérés à deux reprises : dans la source et dans la copie.
    • Opacité des coûts. Votre équipe des opérations financières suit désormais le mouvement des données, la duplication du stockage et les sorties de données au sein d’une architecture qui avait été présentée comme une solution de consolidation.

Rien de tout cela n’est caché de mauvaise foi. Il s’agit d’une question de structure. C’est ce qui se produit lorsqu’un modèle fermé, avec stockage intégré, se heurte à un parc de données ouvert et distribué et tente de l’intégrer^1,4.

Le choix des termes utilisés par le fournisseur est important ici. « Le moteur de synchronisation est gratuit » et « la synchronisation est gratuite » ne sont pas la même chose. Une tâche de synchronisation n’est pas une migration ponctuelle. Il s’agit d’une relation permanente entre deux systèmes qui doivent rester cohérents en permanence : face aux modifications de schéma, aux événements de réseau, aux modifications d’autorisations, aux politiques de conservation, aux mises en suspens réglementaires et aux pannes occasionnelles de l’un ou l’autre côté⁴. Multipliez cela par chaque système source concerné par vos charges de travail d’IA, et vous constaterez que vous n’avez pas simplifié votre architecture. Vous y avez ajouté un nouveau plan de copie propre au fournisseur, exécuté en arrière-plan¹.

Les forces externes rendent ce coût permanent

La raison pour laquelle ce coût ne s’estompe pas au fil du temps, c’est que les forces qui le créent ne sont pas transitoires. Il s’agit de caractéristiques structurelles de l’entreprise :

• • Contraintes réglementaires et souveraines. RGPD, HIPAA, loi sur la résidence des données, contrôles des exportations. Certaines données doivent être traitées là où elles se trouvent. Une tâche de synchronisation qui traverse une limite souveraine devient un incident de conformité.
  • Exigences applicatives. Les applications de référence telles que les systèmes ERP, CRM, DSE et transactionnels sont indissociables de leurs propriétaires. Elles n’ont pas été conçues pour alimenter l’espace de nommage d’un fournisseur. Elles ont été conçues pour faire fonctionner une entreprise.
  • Frictions contractuelles. Les frais de sortie facturés par les fournisseurs de services infonuagiques à très grande échelle et les formats propriétaires rendent l’extraction des données plus coûteuses que leur conservation sur place. Extraire des données pour les déposer ailleurs constitue un poste de dépenses que votre directeur financier finira par repérer.
  • Dynamiques organisationnelles. Deux unités opérationnelles réclamant les mêmes données, le parc d’une entreprise acquise qui débarque du jour au lendemain, un gestionnaire qui refuse de céder le contrôle de la gouvernance : l’organigramme supplante régulièrement l’idéal architectural.
  • Données inconnues ou non cataloguées. Les données dont vous connaissez l’existence, mais que vous ne pouvez pas cataloguer. Vous ne pouvez pas synchroniser ce que vous ne trouvez pas. Et ce que vous ne pouvez pas synchroniser, votre IA ne peut pas le voir, du moins pas dans un modèle intégrant le stockage.

Chacune de ces forces est une caractéristique permanente de l’environnement dans lequel une vraie entreprise opère. Les architectures qui comptent sur leur disparition en paieront le prix indéfiniment. 

L’alternative fédérée

Dell AI Data Platform repose sur un principe très différent. Plutôt que de demander aux clients de copier leurs données dans un espace de nommage contrôlé par le fournisseur avant qu’ils ne puissent les utiliser, l’approche de Dell est fédérée : un plan de contrôle qui fonctionne sur les données là où elles se trouvent, qu’il s’agisse de PowerScale, d’ObjectScale, de solutions de stockage tierces, d’entrepôts, de logiciels-services et du nuage public, et qui ne déplace les données que lorsque ce déplacement constitue réellement la meilleure solution^4,5.

Ce choix architectural unique est une application directe du cadre des trois formes :

• • Les données restent là où elles se trouvent, gouvernées par les équipes qui les gouvernent déjà.
  • Les métadonnées se propagent partout, de sorte que chaque IA que vous choisissez a accès à toutes les ressources, quel que soit leur emplacement.
  • Les vecteurs véhiculent le sens à travers l’ensemble du parc informatique, de sorte que l’IA peut raisonner à partir des données sans avoir à les déplacer d’abord.

Cela ne signifie pas que les architectures fédérées ne déplacent jamais les données. Elles le font, quand cela a du sens. Mais elles ne font pas du déplacement des données la condition préalable pour tirer de la valeur de la plateforme. Et ce choix architectural unique élimine la majeure partie du coût opérationnel mentionné ci-dessus, car ce coût n’existe que si vous avez construit votre architecture en supposant que les données doivent être déplacées avant que l’IA ne puisse y accéder⁴.

Cela préserve également ce qui importe le plus au directeur financier : l’optionalité. Un plan de contrôle fédéré ne piège pas le parc de données dans l’espace de nommage d’un fournisseur. Il laisse le parc là où il se trouve déjà, gouverné par les équipes qui le gouvernent déjà et le rend exploitable par l’IA sur place^2,4.

Les analystes indépendants dénoncent de plus en plus cette dynamique. Un article récent a noté que, malgré le soutien de VAST aux normes ouvertes, son « architecture unifiée pourrait créer des dépendances qui rendraient les migrations futures difficiles », une façon polie de dire que plus vous synchronisez de données, plus il est difficile de s’en détacher un jour². Un autre a observé que l’approche de VAST est « plus analogue au modèle d’infrastructure hyperconvergée, offrant une pile fortement intégrée et dictée par le fournisseur, où VAST contrôle l’expérience complète ».³ L’infrastructure hyperconvergée a montré au secteur ce qui se passe lorsque ce modèle se heurte à l’hétérogénéité à grande échelle. Les mêmes leçons s’appliquent ici.

Trois questions à poser avant de signer

Ces questions doivent figurer directement dans votre appel d’offres.

1. 1. En régime de croisière, combien de pipelines vais-je exécuter dans votre espace de nommage? Demandez une estimation réaliste basée sur un parc de données qui ressemble au vôtre, et non sur une architecture de référence conçue pour un projet entièrement nouveau. Comparez cela à votre parc réglementaire et lié à vos applications.
   2. Qui est responsable du rapprochement lorsque le système source change? Si la réponse est « votre équipe, à l’aide de nos outils », cela représente un coût opérationnel pour vous. Évaluez-le.
   3. Si je souhaite arrêter la synchronisation d’une source au cours de la troisième année, comment cela se passe-t-il? La réponse reflète directement le degré d’optionalité auquel vous renoncez et indique clairement le niveau de friction que l’architecture engendre en cas de sortie.

En résumé : ne payez pas pour l’infrastructure dont personne ne vous a dit que vous alliez l’acheter.

Quelle est la prochaine étape?

Dans le prochain article, je reviendrai sur le plancher du centre de données, car la conséquence de ce coût architectural n’est pas seulement un problème d’ETC. Il s’agit d’un problème d’économie lié aux processeurs graphiques. Lorsque les données doivent être transférées avant que le calcul puisse être exécuté, le poste le plus coûteux de votre infrastructure d’IA est celui qui paie la facture.

¹ VAST Data, documentation produit « DataSpace et SyncEngine ».

² 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 », commandée par 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.