De nombreuses grandes entreprises ont passé ces dernières années à investir dans l’infrastructure, les logiciels et la mise en œuvre de l’intelligence artificielle. Les conseils d'administration ont approuvé les plans. La finance a élaboré les analyses de rentabilisation. Achat négocié pour la capacité de calcul.
Une question restait. Comment géreraient-ils les données sous ces systèmes ?
Ce n’est pas le genre d’échec qui fait encore la une des journaux. Il n’y a pas de panne, de rupture ou de rappel majeur. Au lieu de cela, il s’agit d’un frein discret et cumulatif qui se manifeste sous la forme d’effectifs imprévus et de délais glissants. Parlez à suffisamment de responsables de l'infrastructure de ce qui s'est passé et vous entendrez plus d'une fois l'expression « gravité des données ».
L’ampleur du problème est visible dans les chiffres. UN Rapport 2025 de l'initiative NANDA du MIT a constaté que 95 % des projets pilotes d'IA générative d'entreprise ont produit peu ou pas d'impact mesurable sur le compte de résultat. Le rapport souligne des lacunes dans la manière dont les entreprises intègrent l’IA dans leurs opérations, et pas seulement pour modéliser la qualité. Ces chiffres devraient changer la façon dont les entreprises élaborent des analyses de rentabilisation en matière d’IA : un projet pilote réussi ne prouve pas qu’une organisation peut exécuter le même système sur l’ensemble de son parc de données.
L’hypothèse inscrite dans le budget
La plupart des architectures d’IA d’entreprise supposent toujours que les données seront déplacées là où se trouve la nouvelle plateforme. Rassemblez les données au même endroit et la couche d'intelligence située au-dessus fonctionnera tout simplement. C’est une hypothèse raisonnable, mais elle n’est presque jamais vraie à l’échelle de l’entreprise.
Les données d'entreprise ont de la gravité. Les réglementations dictent l'endroit où certains documents peuvent résider. Les règles de souveraineté maintiennent les autres ensembles de données au sein d’une juridiction, même lorsque le calcul est moins cher ailleurs. Les unités commerciales qui ont passé une décennie à bâtir une gouvernance autour d’un ensemble de données sont peu incitées à le confier à un nouveau magasin central et n’ont parfois aucun moyen légal de le faire. Les applications construites autour de leurs données peuvent également se briser de manière coûteuse lorsque quelqu'un tente de séparer les deux.
Ceci est généralement caché dans une preuve de concept. Il fonctionne sur une petite tranche de données pré-nettoyée. Les coûts apparaissent plus tard, lorsque le programme doit faire face à la majorité désordonnée exclue de la démo.
La « gravité des données » est l’idée selon laquelle de grandes accumulations de données attirent les applications vers elles et non l’inverse. Plus l’ensemble de données est volumineux, plus son déplacement coûte cher. Les frais de transfert ne sont qu’un début ; la latence, la bande passante, les contrôles de sécurité et les efforts opérationnels s'ajoutent à la facture avant qu'un modèle ne produise une réponse utile.
Où la facture arrive à échéance
Le coût n’apparaît généralement pas sous la forme d’un seul élément de ligne. Cela se traduit par des dizaines de petites demandes adressées à des équipes qui ont déjà trop de choses à gérer. Ils doivent créer et entretenir des pipelines pour déplacer les données hors de systèmes qui n'ont jamais été conçus pour ce type de trafic, réconcilier chaque copie avec l'original lorsque le système source change et appliquer les mêmes contrôles de gouvernance partout où les données sont stockées. Ils doivent également suivre les ensembles de données supplémentaires créés pour le développement, les tests, l'analyse et la formation.
Aucune de ces tâches ne semble désastreuse en soi. Ensemble, ils deviennent une taxe sur le programme, une taxe qui devient de plus en plus coûteuse à mesure que l'organisation tente de l'étendre.
Pourquoi la facture arrive en retard
L’aspect le plus dangereux de cette taxe est son timing. Cela apparaît souvent 12 à 24 mois après l’acquisition de la plateforme et la constitution de l’équipe, lorsque les indicateurs de réussite initiaux ont déjà été signalés à la hausse.
D’ici là, les contrats sont signés, les équipes sont embauchées et la direction est publiquement engagée. Déployer une architecture axée sur la centralisation est bien plus coûteux que concevoir dès le départ autour de la gravité des données. Le calcul est facile à identifier et à attribuer à un budget ; la maintenance du pipeline, le rapprochement, la gouvernance, les examens de sécurité et le personnel nécessaire au fonctionnement du système sont répartis dans différentes organisations.
La couche manquante est le contexte, pas seulement le stockage
De nombreuses analyses post-mortem sur les programmes d’IA au point mort s’arrêtent à « nos données n’étaient pas prêtes ». Ce diagnostic est précis mais incomplet. Le problème le plus profond est que les organisations tentent de résoudre un problème de contexte grâce à une stratégie de stockage.
Un modèle n’a pas besoin de données brutes devant lui. Cela nécessite du contexte : la capacité de trouver le bon document, de le comparer à la politique, de respecter les règles d'accès et de travailler à partir d'informations actuelles plutôt que d'un instantané de la semaine de début du projet. Cela ne vient pas d’un entrepôt plus grand. Il provient d'une couche contextuelle à l'échelle de l'entreprise : une manière cohérente et gouvernée de découvrir, de connecter et de récupérer des informations sur tous les systèmes et emplacements sans que chaque source ait à transmettre ses données à un magasin central.
Les enregistrements sous-jacents, les métadonnées et les vecteurs que les systèmes d’IA utilisent pour raisonner sur le sens ne sont pas la même chose. Les archives restent limitées par la réglementation, la souveraineté, la propriété et les applications construites autour d'elles. Les métadonnées et les vecteurs peuvent aider l’IA à trouver et à raisonner sur ces enregistrements sans hériter de toutes les contraintes qui maintiennent les données sources là où elles se trouvent.
La question n’est pas de savoir comment rassembler toutes les données au même endroit. Il s'agit de savoir comment rendre le bon contexte disponible partout où les données se trouvent déjà, quelles que soient les règles qui les régissent. Les entreprises qui considèrent le contexte, et non la consolidation, comme ce qu’elles construisent évitent de reconstruire le même impôt sous une architecture différente deux ans plus tard.
Les quatre questions clés à poser
Avant de signer un investissement majeur dans une infrastructure d’IA, une organisation doit être en mesure de répondre à quatre questions fondamentales : quels ensembles de données sont réglementés ou contractuellement limités en déplacement ? À qui appartient aujourd’hui la gouvernance de chaque ensemble de données, et que se passe-t-il lorsqu’une copie existe ailleurs ? Comment ces copies resteront-elles synchronisées à mesure que les systèmes sources évoluent ? Et l’intelligence peut-elle aller là où se trouvent déjà les données, ou l’architecture nécessite-t-elle que tout soit centralisé ? Ces questions ne permettent pas de choisir le fournisseur à votre place, mais elles façonneront la liste restreinte.
Le bon choix d'architecture et la bonne sélection de fournisseurs vous mèneront aux résultats de l'IA et automatiseront vos processus métier plus rapidement et à moindre coût. Ces questions permettent à l’architecture de données d’être un élément de première classe dans l’analyse de rentabilisation de l’IA, et non un détail à résoudre une fois l’accord de calcul conclu.
Le vrai problème du retour sur investissement
L'instinct de l'industrie est de mesurer le retour sur investissement de l'IA en termes de jetons, de débit et d'utilisation du GPU. Ces mesures sont utiles pour évaluer l’efficacité du calcul, mais elles ne racontent que la moitié de l’histoire. L’autre contrainte sur la valeur de l’IA d’entreprise se situe en amont du calcul : la question de savoir si les données qui alimentent le modèle peuvent être fiables, gouvernées et tenues à jour sans imposer une taxe toujours croissante aux personnes qui les entourent. La longueur du jeton et l’efficacité du GPU vous indiquent ce qu’il en coûte pour exécuter un modèle. Ils ne vous disent pas si le modèle dispose du contexte dont il a besoin pour prendre une bonne décision. Cela dépend si les données sous-jacentes sont exactes, à jour, gouvernées et connectées au bon processus métier. C'est le contexte élaboré à partir des données qui détermine l'exactitude des actions agents et si vous êtes sur la bonne voie pour devenir une organisation native de l'IA ou si vous vous en éloignez.
Le calcul est un poste pour lequel les entreprises savent budgétiser. La gravité des données est l’élément de campagne que beaucoup découvrent encore, généralement longtemps après la validation du chèque. Les entreprises qui tireront le meilleur parti de l’IA seront celles qui concevront leur architecture de données pour servir les agents contextuels nécessaires sans déplacer ni centraliser l’ensemble de l’état distribué.
Gaurav Chawla est membre et vice-président de Dell Technologies Inc., directeur de la technologie. Il a écrit cet article pour SiliconANGLE.
