Corey Knowles : « Bienvenue dans eSpeaks, où nous explorons les technologies qui façonneront l’avenir de l’informatique d’entreprise. Je suis votre hôte, Corey Knowles. Dans l’épisode d’aujourd’hui, nous allons aborder les défis liés aux données qui peuvent faire réussir ou échouer les initiatives d’IA, la façon dont les entreprises peuvent simplifier leurs environnements de données, et ce que les organisations doivent prendre en compte à mesure que les charges de travail liées à l’IA évoluent.
Notre invité aujourd’hui est Vrashank Jain, Lead Product Manager pour la Dell AI Data Platform, qui va nous en dire davantage sur ces défis. Vrashank travaille à l’intersection de l’innovation produit et de la stratégie d’entreprise. Il aide les organisations à repenser la gestion de leurs données afin de soutenir l’IA à grande échelle. Vrashank, bienvenue dans le podcast. »
Vrashank Jain : « Corey, c’est un plaisir d’être ici. Merci. »
Corey : « Génial. Nous sommes ravis de vous accueillir. Commençons directement. De nombreuses organisations disent vouloir se lancer dans l’IA, mais elles se heurtent rapidement à des problèmes de données. De votre point de vue, notamment avec votre travail sur la Dell AI Data Platform, quel est aujourd’hui le problème lié aux données le plus courant qui freine les initiatives d’IA ? »
Vrashank : « Beaucoup d’organisations disent que le problème, ce sont les données, mais je pense qu’il faut être plus précis. Selon moi, le principal facteur qui freine les projets d’IA n’est pas le modèle. Ce n’est plus un problème de modèle. C’est un problème de préparation des données.
Et il ne s’agit pas seulement des données en elles-mêmes. Il s’agit de leur disponibilité et de la capacité à les trouver. Chaque organisation, en particulier les grandes entreprises, possède d’énormes volumes de données, mais celles-ci sont fragmentées entre différents systèmes : certaines sur site, d’autres dans le cloud, d’autres encore dans des bases de données, dans Salesforce, dans ServiceNow, dans des sources de streaming, etc. Aucun de ces éléments n’a été conçu pour communiquer avec les autres.
Vous avez des données structurées dans un entrepôt de données. Vous avez des données non structurées, comme des images, des vidéos et des e-mails, dans un stockage objet ou sur un partage de fichiers. Vous avez des journaux qui arrivent de partout depuis la périphérie. Dans cet état, ces données ne peuvent pas réellement être exploitées par un modèle.
L’autre dimension importante concerne les métadonnées ou le lignage des données. Elles sont devenues plus importantes que jamais au cours de la dernière année environ. Les équipes passent des semaines simplement à comprendre quelles données elles possèdent, si elles sont propres et si elles ont même le droit de les utiliser pour un cas d’usage d’IA donné. Et le temps qu’elles répondent à ces questions, le projet a déjà perdu son élan.
Ce qui distingue les organisations rapides des organisations lentes, c’est que les plus rapides disposent généralement d’une excellente compréhension de la gouvernance et du catalogage de leurs données avant même de commencer à se lancer pleinement dans l’IA. »
Corey : « C’est logique. Et c’est assurément quelque chose qu’il faut régler en amont. Pour les entreprises dont les données sont réparties entre le cloud, les systèmes sur site et les appareils en périphérie, qu’est-ce qui rend si difficile la création d’un pipeline de données d’IA fiable ? »
Vrashank : « La première chose à faire est de bien distinguer les pipelines d’IA des pipelines de données d’IA. Les pipelines d’IA peuvent parfois être confondus avec les workflows d’agents, qui sont aujourd’hui très courants, avec Anthropic, LangChain et d’autres approches similaires. Un pipeline de données d’IA consiste plus précisément à s’assurer que les modèles reçoivent la bonne quantité de données, au bon moment et au bon endroit.
Le principal défi, à mon avis, est que nous avons historiquement construit les pipelines de données de la même manière que les pipelines ETL : ils sont orientés batch, relativement prévisibles et peuvent tolérer une certaine latence.
Les pipelines d’IA, eux, exigent beaucoup plus de débit. Ils sont sensibles à la latence. Ils ont besoin de données dans un format spécifique, souvent différent de celui dans lequel les données sont stockées opérationnellement. Si l’on ajoute à cela le multicloud et la périphérie, parce que les données sont dispersées partout, on ne parle plus seulement de silos de données. On parle, en quelque sorte, de physique des réseaux.
Déplacer de grands ensembles de données d’un bucket cloud vers un cluster GPU sur site pour l’entraînement a de réelles implications en termes de coût et de latence. Le problème de cohérence est également important. Si les données d’entraînement et les données d’inférence proviennent de systèmes différents qui ne sont pas synchronisés, votre modèle commence à se comporter de manière très difficile à déboguer.
C’est particulièrement vrai parce que les modèles sont désormais non déterministes. Cela signifie que vous pouvez poser plusieurs fois la même question au modèle et obtenir des réponses légèrement différentes. Il devient donc très difficile de remonter à la source de la prédiction. C’est ainsi que le pipeline devient une source d’erreurs du modèle, alors que cela ressemble à un problème de modèle mais qu’il s’agit en réalité d’un problème de données. »
Corey : « C’est vraiment intéressant. Tout le monde dit que l’IA a besoin de “bonnes données”, mais cette expression peut vouloir dire beaucoup de choses. En pratique, qu’est-ce qui distingue les données réellement utiles pour l’IA des données qui occupent simplement de l’espace de stockage ? »
Vrashank : « C’est une question assez simple, parce qu’elle nous ramène aux fondamentaux. C’est exactement le type de sujet que nous abordions déjà il y a une dizaine d’années. L’expression “bonnes données” est effectivement utilisée très souvent. Je la décompose généralement en trois grands points.
Le premier est la pertinence. Même si vous disposez de beaucoup de données, représentent-elles réellement le domaine du problème ? De nombreuses entreprises possèdent d’immenses archives de données historiques qui sont techniquement propres, mais qui ne reflètent plus leur réalité opérationnelle actuelle. C’est donc le premier point.
Le deuxième est la complétude et la cohérence. Il peut manquer des valeurs, votre schéma peut dériver au fil du temps, ou vos fichiers PDF et vos e-mails peuvent être étiquetés de manière incohérente. C’est le deuxième problème.
Le troisième est l’accessibilité. Cela concerne peut-être moins les petites organisations, mais dans les grandes et moyennes entreprises, même si vous disposez de données de haute qualité, et même si ces données sont utiles, elles deviennent inutilisables si le chemin pour les récupérer est trop lent ou si leur format est incompatible.
Il s’agit donc d’une combinaison : les données doivent être pertinentes, complètes et accessibles de la bonne manière, au bon moment. C’est ce qui distingue les bonnes données des autres.
J’ajouterais aussi qu’avec l’IA, en particulier, la diversité représentative est essentielle. Les chatbots feront un meilleur travail si on ne leur donne pas seulement une conversation par e-mail, mais si on leur permet aussi d’interroger une base de données pour vérifier les détails sous-jacents de leur résultat. Les modèles de raisonnement sont désormais entraînés à poser des questions et à vérifier leurs réponses. Cela signifie qu’à chaque fois qu’ils le font, il est très utile qu’ils puissent accéder à beaucoup de données réellement fiables. »
Corey : « Oui, tout à fait. Nous parlons ici, au fond, de rapprocher les données des insights, ce qui paraît simple, mais qui est techniquement très difficile, si je comprends bien. Pourquoi l’emplacement des données est-il si important pour les performances de l’IA ? Et quels problèmes apparaissent lorsque les données et la puissance de calcul sont trop éloignées ? »
Vrashank : « Cela nous ramène à ce vieil adage : rapprocher les insights des données, plutôt que les données des insights. Parce que, très franchement, les données ont beaucoup plus de poids que tout le reste dans l’entreprise. Et c’est là, encore une fois, que la physique entre en jeu.
Les GPU sont très rapides, mais ils ne sont rapides que s’ils sont alimentés rapidement. S’ils restent affamés, c’est de l’argent qui est gaspillé. Si votre stockage ne parvient pas à suivre les exigences de débit d’un cluster GPU — et, soyons honnêtes, ces exigences doublent, triplent ou quadruplent chaque année —, on parle désormais de centaines de gigabits par seconde. Vous vous retrouvez alors avec des GPU sous-alimentés. Et c’est aujourd’hui l’un des postes les plus coûteux de tout le budget informatique.
L’une des erreurs d’infrastructure les plus coûteuses que nous observons consiste à acheter les GPU les plus récents et les plus performants, tout en sous-investissant dans le stockage et dans le débit du stockage.
C’est particulièrement important lorsqu’on parle d’inférence pour un grand nombre d’utilisateurs avec des modèles de plus en plus grands. Si votre modèle doit communiquer avec un stockage distant pour récupérer du contexte ou des embeddings, voire consulter d’anciens tokens déjà générés, vous ajoutez des allers-retours réseau. Ce qui devrait être une latence inférieure à 100 millisecondes finit par devenir une latence d’une seconde, ce qui est tout simplement intenable.
C’est ici qu’intervient la notion de localité des données. Si vos jeux de données les plus sensibles sont stockés sur site, il est beaucoup plus logique de rapprocher la puissance de calcul de ce stockage — potentiellement dans le même centre de données, voire dans le même sous-réseau de cluster. C’est là que des solutions de stockage comme PowerScale entrent en jeu : elles sont conçues pour fournir un débit élevé et soutenu lorsqu’elles sont déployées à proximité du cluster GPU, lorsque cela a du sens. »
Corey : « C’est très clair. Et cela donne vraiment l’impression que les entreprises peuvent perdre beaucoup d’argent si elles ne font pas attention. Les entreprises n’exécutent plus une seule charge de travail d’IA. Elles expérimentent avec l’entraînement, l’affinage, l’inférence, l’analytique, et bien plus encore. Comment cette diversité croissante des charges de travail change-t-elle ce que les entreprises attendent de leur infrastructure de données ? »
Vrashank : « C’est une question difficile, parce qu’il y a peut-être encore deux ans, lorsque nous parlions d’IA, nous avions surtout un ou deux cas d’usage en production. Ils concernaient principalement l’inférence, parce que nous étions simplement impressionnés par le fait qu’un LLM puisse effectuer des tâches en langage naturel.
Aujourd’hui, même les organisations de taille moyenne exécutent probablement des tâches d’entraînement, parce que les modèles sont devenus très bons, plus petits, mais aussi extrêmement puissants. Elles exécutent des pipelines d’affinage, de l’inférence par lots et de l’inférence en temps réel. Et il ne faut pas oublier qu’elles continuent aussi à faire de l’analytique traditionnelle, comme elles l’ont toujours fait.
Chacune de ces charges de travail a un profil d’E/S très différent. L’entraînement est séquentiel et exige un débit élevé. Il faut déplacer beaucoup de données très rapidement. L’inférence en temps réel relève de l’accès aléatoire : n’importe quel objet ou fichier peut être sollicité n’importe où, et elle est extrêmement sensible à la latence. L’analytique peut nécessiter de vastes analyses de données archivées très anciennes pour trouver l’aiguille dans la botte de foin.
Ce que j’essaie de dire, au fond, c’est qu’aucun niveau de stockage unique n’est optimal pour tous ces cas. La question d’infrastructure devient donc : comment construire quelque chose d’assez intelligent et d’assez performant pour prendre en charge tous ces schémas, sans forcer une équipe à faire des compromis au profit d’une autre ? Et comment faire cela sans devoir gérer cinq systèmes de stockage différents ?
C’est un axe essentiel de notre AI Data Platform. Nous essayons de fournir une plateforme de données aussi unifiée que possible, tout en offrant la capacité de prendre en charge des charges de travail variées sans faire exploser la complexité opérationnelle liée à sa mise en place et à son exploitation dans la durée. »
Corey : « Une grande partie des discussions sur l’IA se concentre sur les modèles et les GPU. Mais d’après votre expérience, Vrashank, l’infrastructure de données est-elle en train de devenir le principal goulot d’étranglement pour l’adoption de l’IA en entreprise ? »
Vrashank : « Honnêtement, oui. Si l’on regarde la GTC de cette année, lorsque Jensen a parlé des investissements de NVIDIA dans cuDF et cuVS, j’y vois un message de Jensen à ses investisseurs — qui, très franchement, incluent à peu près tout le monde à ce stade — pour dire que les données sont un problème majeur. Et si NVIDIA cherche à résoudre ce problème, c’est un signal assez clair que cela se produit partout dans le monde.
Ces dernières années, comme vous l’avez dit, les discussions étaient dominées par les modèles et par l’approvisionnement en GPU. Rien que l’an dernier, six ou sept modèles différents ont été considérés comme numéro un à différents moments de l’année. Je pense que les clients commencent maintenant à voir que les modèles deviennent suffisamment bons. Les investissements se déplacent désormais vers les bases de données vectorielles, l’orchestration des données et les feature stores.
Tout cela a toujours figuré sur notre feuille de route. Nous ne nous y étions simplement pas encore vraiment consacrés, parce qu’il manquait un cas d’usage suffisamment convaincant. Aujourd’hui, ce cas d’usage existe. Une fois que les entreprises auront dépassé la pénurie de GPU dont on parle tant, elles commenceront à parler du goulot d’étranglement lié à l’architecture des données, parce qu’à l’heure actuelle, ces GPU ne peuvent tout simplement pas être alimentés en données de manière suffisamment efficace. »
Corey : « C’est vrai. Et cela ne va pas ralentir. De nombreuses équipes informatiques se sentent dépassées par le nombre d’outils impliqués dans les pipelines d’IA modernes : data lakes, bases de données vectorielles, feature stores et outils d’orchestration. À quoi ressemble concrètement la simplification de la gestion des données pour l’IA ? »
Vrashank : « C’est la question à un million de dollars. »
Corey : « Peut-être plutôt à mille milliards. »
Vrashank : « Oui, peut-être même à mille milliards. Il existe un investisseur en capital-risque nommé Matt Turck, qui publie chaque année une carte du paysage MAD — machine learning, analytics and data. Il a commencé il y a environ cinq ou six ans avec une poignée de logos, peut-être une cinquantaine. Dans la version la plus récente, il faut littéralement faire défiler toute la page pour parcourir tous les logos.
C’est donc un marché très fragmenté et très diversifié. Mais je ne pense pas que ce soit le problème en soi. Je ne pense pas que la variété des technologies soit le véritable problème. Le vrai problème consiste plutôt à réduire le nombre de passages de relais qu’un data scientist ou un ingénieur en machine learning doit gérer lorsqu’il navigue dans cet univers d’outils.
Dans beaucoup d’entreprises aujourd’hui, les jeux de données sont préparés à l’aide de six ou huit outils différents qui ne communiquent pas nécessairement entre eux : un catalogue de données, un moteur Spark, un feature store, une base de données vectorielle, une couche d’orchestration de pipeline, un outil d’observabilité, un système de supervision.
Le problème, c’est que tous ces outils paraissent excellents lorsqu’on les considère individuellement. Mais lorsqu’il faut les gérer à grande échelle, cela devient un cauchemar. À mon sens, simplifier ne signifie donc pas nécessairement supprimer tous ces outils ou les condenser en un seul outil — soyons réalistes, cela n’arrivera jamais.
Je pense qu’il faut plutôt une couche unifiée de métadonnées et de lignage, capable de suivre en quelque sorte les données lorsqu’elles passent d’un outil à l’autre. En tant que responsable ou propriétaire des données, vous n’avez alors pas à vous inquiéter de l’outil dans lequel les données circulent. Vous devez simplement vous assurer de toujours savoir dans quel outil elles vont, ce qui leur arrive et comment les retours d’information sont produits.
Au fond, il s’agit donc de ne jamais perdre le fil : d’où viennent les données, où vont-elles, et vers quel outil iront-elles ensuite dans cette chaîne d’outils qui existera toujours. »
Corey : « En somme, de bons journaux unifiés. »
Vrashank : « Oui, exactement. Certains disent que nous avons besoin d’un outil unifié, qu’ils aimeraient qu’un seul outil fasse tout pour eux. Premièrement, c’est un rêve irréaliste. Deuxièmement, c’est une recette pour une forte dépendance à un fournisseur. »
Corey : « C’est vrai. Vous travaillez depuis des années avec de grandes entreprises, notamment des entreprises du Fortune 500. Quels schémas observez-vous chez les entreprises qui réussissent à déployer l’IA à grande échelle, par rapport à celles qui rencontrent encore des difficultés ? »
Vrashank : « Je pense qu’il y a des entreprises qui s’en sortent bien et d’autres qui rencontrent des difficultés avec l’IA. Et oui, certains schémas se dégagent. Les entreprises qui réussissent généralement font quelques choses très bien.
Premièrement, elles traitent toujours les données comme un produit de premier plan, et non comme une réflexion après coup. Cela signifie qu’elles ont des politiques ou des structures organisationnelles solides, des SLA sur la qualité des données, des propriétaires de données, et des pipelines qui sont surveillés de la même façon que des logiciels de production. Elles ont donc une bonne hygiène des données.
Deuxièmement, elles conçoivent leur approche pour l’itération, pas pour la perfection. Elles commencent avec des données imparfaites, investissent dans des boucles de rétroaction et améliorent la qualité au fil du temps, au lieu de rester bloquées parce qu’elles n’ont pas un jeu de données parfait — ce qui, franchement, n’arrive jamais.
Troisièmement, elles prennent des décisions délibérées sur l’endroit où les charges de travail d’IA doivent s’exécuter. Elles ne se contentent pas de tout transférer dans le cloud parce qu’un mandat cloud l’exige. Elles réfléchissent à la gravité des données, aux contraintes réglementaires et au coût par inférence.
Plus vous introduisez d’intelligence dans ce processus et plus vous prenez de petites décisions intentionnelles, plus vous devenez agile. À l’inverse, les entreprises qui rencontrent des difficultés donnent souvent l’impression de vouloir faire bouillir l’océan. Elles lancent un grand programme de transformation des données sur deux ou trois ans qui ne se concrétise jamais, ou bien elles mènent trop d’expérimentations isolées.
Elles ont une idée ici, une idée là, mais elles ne relient jamais vraiment les points pour se demander : sommes-nous en train de construire une plateforme cohérente, ou essayons-nous simplement de résoudre un problème à la fois ? Ce sont les deux schémas que j’observe entre les entreprises qui réussissent et celles qui peinent encore. »
Corey : « Cela correspond assez bien à ce que l’on pourrait attendre. Parlons de transformation par l’IA. Il ne s’agit pas seulement d’un changement technologique. Cela exige souvent de nouvelles formes de collaboration entre les ingénieurs de données, les équipes de machine learning et les équipes d’infrastructure informatique. Comment voyez-vous les organisations adapter leurs équipes et leurs workflows pour réussir dans ce nouvel environnement d’IA piloté par les données ? »
Vrashank : « Il faut revenir aux équipes qui font cela très bien. Une chose que j’ai oublié de mentionner, c’est qu’elles ont aussi abattu les murs entre les rôles. Il y a quelques années, nous savions exactement ce que faisait un ingénieur de données, ce que faisait un ingénieur en machine learning, ce que faisait un analyste de données et ce que faisait un ingénieur IA. Aujourd’hui, ces frontières ne sont plus aussi nettes.
Tout le monde peut construire un peu de tout. Les entreprises agiles disent donc : votre travail ne consiste pas seulement à faire de l’ingénierie des données. Votre travail consiste à réfléchir à l’IA à grande échelle, afin de construire les bons pipelines avec l’IA en tête.
Les équipes doivent penser au-delà de leurs tâches quotidiennes. À grande échelle, cela nécessite une collaboration beaucoup plus étroite. Les bonnes organisations intègrent une fonction IA dans chaque ensemble de compétences dont elles disposent, au lieu de continuer à les cloisonner dans des rôles traditionnels.
Cela appelle aussi une réponse technologique, bien sûr. Il faut des outils qui permettent aux équipes de penser au-delà de leur domaine immédiat. Mais, dans l’ensemble, vous avez raison : c’est davantage une question de workflows organisationnels qu’une simple question de technologie.
Je vois aussi les ingénieurs en machine learning mûrir très rapidement, et les outils MLOps s’améliorer fortement. Beaucoup commencent à se présenter comme AgentOps ou AIOps, et ce n’est pas sans raison. Ils constatent que le machine learning traditionnel existe toujours, mais qu’il est désormais réintégré dans un projet d’IA plus vaste, dont il n’est plus qu’une partie. Ce n’est plus la partie dominante. »
Corey : « Oui, plutôt la racine. »
Vrashank : « Exactement. »
Corey : « Si l’on se projette dans trois à cinq ans, comment pensez-vous que les plateformes de données d’IA en entreprise vont évoluer à mesure que les modèles deviennent plus grands, que les charges de travail s’étendent et que l’IA en temps réel se généralise ? »
Vrashank : « Je peux le résumer en deux ou trois points. Certains me viendront peut-être en parlant. Il y a quelques éléments dont je suis assez certain. Le premier — et je crois que nous en avons déjà parlé — est que la frontière entre calcul et stockage va s’estomper. Nous voyons déjà le traitement se rapprocher de l’endroit où se trouvent les données. Nous voyons d’importants investissements dans le calcul sur site pour les GPU. Les résultats de Dell le montrent aussi, et c’est un signe de la direction que prend le marché.
Je pense que cette tendance va s’accélérer, parce que les modèles vont devenir plus grands et meilleurs. Ils dépendront donc encore davantage de données en temps réel situées à proximité.
Le deuxième point est que les 20 % de données qui sont accessibles aujourd’hui — les données non structurées — vont devenir des données de premier plan et commencer à dominer. Par là, je veux dire que nous allons élargir notre définition de ce qu’est un système d’enregistrement pour une entreprise. Ce ne sera plus seulement un entrepôt de données, mais un jeu de données multimodal, bien étiqueté et de grande qualité, comprenant du texte, des images, de la vidéo et de l’audio.
Comme ces données devront traverser plusieurs technologies pour être exploitées, cela nécessitera, selon moi, un paradigme de gestion différent et une technologie différente.
Le troisième point concerne peut-être l’intégration plus étroite entre les données et l’orchestration autour de ces données. C’est déjà ce qui se passe dans le monde de l’IA. Nous avons d’abord construit les modèles, puis les frameworks d’agents, et maintenant nous automatisons les agents parce qu’ils deviennent autonomes. La même chose va se produire avec les données.
Nous avons commencé par construire des plateformes de données. Ensuite, nous avons construit des pipelines de données. Maintenant, nous allons construire une orchestration qui automatisera ces pipelines. Ce ne sera pas quelque chose de passif, mais plutôt quelque chose d’actif : lorsqu’un modèle de raisonnement estime qu’il a besoin de réponses, le pipeline devrait se mettre en marche. »
Corey : « Ce serait donc davantage quelque chose que l’on surveille qu’une tâche que l’on exécute soi-même. »
Vrashank : « Exactement. Il s’agit davantage de laisser un modèle dicter ce dont il a besoin à un moment donné. Votre travail consiste alors, pour revenir à votre remarque, à vous assurer que les pipelines sont performants, qu’ils ne ralentissent rien et qu’ils sont sécurisés. »
Corey : « Oui. Et ensuite des agents pour corriger tout cela. »
Vrashank : « Et ensuite des agents pour corriger tout cela également. Exactement. C’est un monde d’agents. »
Corey : « Vrashank, merci beaucoup de nous avoir rejoints aujourd’hui et d’avoir partagé vos perspectives sur le rôle essentiel de l’infrastructure de données à l’ère de l’IA. Nous avons été ravis de vous recevoir. »
Vrashank : « Merci de m’avoir invité, Corey. J’ai beaucoup apprécié cet échange. »
Corey : « Alors que l’adoption de l’IA s’accélère dans tous les secteurs, une chose devient de plus en plus claire : le succès ne consiste pas seulement à construire des modèles plus intelligents. Il s’agit de s’assurer que ces modèles ont accès aux bonnes données, au bon endroit et au bon moment. Pour de nombreuses organisations, résoudre ce défi lié aux données déterminera finalement jusqu’où leurs stratégies d’IA pourront aller. Merci d’avoir écouté eSpeaks, et à la prochaine. »
