Au-delà du pilote : ce qu’il faut vraiment pour mettre l’IA en production avec Beth Williams de Dell

Corey Noles : Bienvenue dans eSpeaks d’eWeek. Je suis Corey Noles.

À ce stade, la plupart des entreprises n’ont pas besoin d’une nouvelle démonstration de la capacité de l’IA à faire quelque chose d’intéressant. La question la plus difficile est la suivante : que se passe-t-il après la démonstration ?

Passer d’un pilote réussi à une IA capable de fonctionner de manière fiable dans toute l’entreprise soulève des difficultés liées aux données, à l’infrastructure, à la sécurité, à la gouvernance, aux coûts et même à la personne qui est finalement responsable lorsque ces systèmes prennent des décisions ou agissent.

Pour m’aider à décrypter cette transition, je reçois aujourd’hui Beth Williams, de Dell Technologies. Beth, merci d’être avec nous.

Beth Williams : Bonjour, Corey. Merci beaucoup de m’avoir invitée.

Corey : Excellent. Je suis ravi de vous recevoir.

Nous sommes un peu arrivés au point où les pilotes d’IA sont partout. Mais pourquoi le passage d’un pilote prometteur à un véritable environnement de production reste-t-il si difficile pour tant d’entreprises ?

Beth :Oui, c’est quelque chose que nous constatons souvent chez nos clients : beaucoup de pilotes s’enlisent, les équipes restent simplement à cette étape. Et je pense qu’il y a de nombreuses raisons à cela.

L’une des principales raisons que nous observons est que, lorsqu’ils se concentrent sur des pilotes ou des démonstrations, les gens essaient essentiellement de faire fonctionner la technologie, n’est-ce pas ? Ils disposent peut-être de leur petit environnement quelque part. Peut-être ont-ils un joli petit GB10 ou quelque chose de ce genre. Ce n’est pas un environnement évolutif.

Ils ont probablement aussi sélectionné les données avec soin, n’est-ce pas ? Ils les ont triées, toutes trouvées et rassemblées pour que le système fonctionne techniquement. Et ils ont probablement sélectionné les utilisateurs de la même manière, s’ils l’ouvrent à un nombre limité de personnes. Nous sommes d’ailleurs dans cette situation avec l’un de nos pilotes : nous avons littéralement choisi un sous-ensemble d’utilisateurs pour aller tester tout ça.

Tout cela est formidable pour un pilote, mais dès que l’on passe en production, c’est un tout autre jeu, n’est-ce pas ?

Tout d’abord, vous aurez probablement besoin de plus qu’un ordinateur portable pour faire fonctionner le système. La plateforme sur laquelle vous allez exécuter ces éléments constitue donc une grande partie du problème, et bon nombre de nos clients n’ont pas encore réellement établi de plateforme pour les faire fonctionner, en dehors de l’utilisation éventuelle d’un cloud public.

Et les données entrent alors dans l’équation. J’ai expliqué que, dans beaucoup de pilotes, on sélectionne et on prépare les données pour parvenir à un fonctionnement technique. Mais lorsqu’on commence à passer en production, on recherche souvent des données réellement automatisées, n’est-ce pas ? On veut que les données soient disponibles quand on en a besoin, et on veut pouvoir leur faire confiance. Or une grande partie des données que nous voyons chez nos clients n’est tout simplement pas prête.

C’est donc la combinaison de nombreux éléments. Et si vous ajoutez des éléments comme l’IA agentique, nous voyons actuellement beaucoup de gens piloter des workflows agentiques parce qu’ils sont très puissants et que leur autonomie est très séduisante. Dès que vous entrez dans ce domaine, vous abordez une question de sécurité particulièrement intéressante. Vous avez probablement vu récemment dans les médias pas mal d’histoires d’agents qui deviennent un peu incontrôlables.

Corey : C’est le cas. Ils deviennent un peu incontrôlables.

Beth : Ils se retrouvent sur de petits forums et discutent entre eux de la manière de sortir des environnements isolés et de toutes sortes de choses amusantes. Il faut donc vraiment commencer à réfléchir à ces questions, n’est-ce pas ? Ce n’est pas quelque chose auquel on peut penser après le passage en production. Il faut l’intégrer dès le départ. Tout tourne autour d’éléments comme les politiques, les autorisations et la sécurité.

Et puis, qui assurera le support à long terme ? Là encore, beaucoup de gens se concentrent surtout sur le fait de faire fonctionner la technologie. Mais lorsqu’on réfléchit au passage en production, qui en sera responsable ? Qui sera responsable de vérifier qu’elle se comporte correctement ? Comment sera-t-elle supervisée ? Comment pourrez-vous revenir en arrière, et ainsi de suite ?

Toutes ces questions sont assez difficiles à résoudre si l’on ne l’a jamais fait auparavant. Bien sûr, nous l’avons déjà fait, et c’est pourquoi nous pouvons aider ; ou alors vous disposez déjà d’une plateforme sur laquelle vous pouvez déployer le système, comme l’AI Factory avec NVIDIA, par exemple. C’est simplement une plateforme prête à l’emploi sur laquelle vous pouvez le déployer. Donc, comme je le disais, le problème comporte de multiples dimensions.

Corey : C’est logique. Les entreprises subissent également beaucoup de pression pour trouver davantage de cas d’usage de l’IA, mais toutes les expérimentations n’ont peut-être pas besoin de devenir des systèmes de production.

Comment les dirigeants doivent-ils déterminer quels pilotes méritent réellement de passer à l’échelle ?

Beth :Oui, je pense que beaucoup de gens adoptent l’idée suivante : « Si j’ai un pilote qui fonctionne techniquement, il doit toujours passer en production », n’est-ce pas ? Or un pilote sert à apprendre. Il s’agit essentiellement de déterminer si quelque chose va fonctionner pour l’utilisateur et si cela va fonctionner techniquement. Et avec l’IA, la question devient très intéressante, notamment parce que l’on utilise des modèles susceptibles d’halluciner.

J’essaie notamment d’aider les clients et les équipes en interne à comprendre que, lorsqu’on lance un pilote, il faut vraiment rester détaché de ce qui lui arrivera ensuite. Il faut se demander : « D’accord, qu’avons-nous appris ? Pouvons-nous maintenant passer à la production ? Ou devons-nous peut-être réorienter ce que nous sommes en train de faire ? »

Ou peut-être — et c’est le modèle de l’échec rapide — que nous devons simplement dire : « Ce cas ne convient pas à l’IA. Nous avons besoin de quelque chose de totalement fiable, et ce système ne nous l’apporte pas. » Nous pouvons alors nous arrêter et repenser l’approche. Il s’agit en grande partie de rester très détaché de l’issue des pilotes.

Mais il faut aussi se demander quels indicateurs clés de performance on examine pendant le pilote lui-même. Là encore, l’une des choses que nous faisons en interne et que nous aidons nos clients à faire consiste à réaliser ce que nous appelons une preuve de valeur pour un pilote. Décidons quels sont les indicateurs importants. Prouvons ces éléments pendant le pilote — pas seulement la technologie, mais aussi le fait qu’elle produise le résultat métier recherché. S’agit-il de revenus ? D’économies ? De meilleures performances ? Qu’attendez-vous exactement ? Mesurons ces éléments pendant le pilote.

Il faut également garder à l’esprit qu’une fois le système passé en production, il faudra continuer à mesurer ces éléments. Il ne s’agit pas de mesures ponctuelles. Le système continue-t-il à produire tous ces résultats ?

L’autre chose que nous avons faite chez Dell — car, soit dit en passant, les cas d’usage ne sont pas le problème. Ils ne sont vraiment pas le problème. Il existe des centaines et des centaines de cas d’usage potentiels. Nous en avions plus de 800 il y a quelques années, lorsque nous avons commencé notre parcours, et chacun lançait de petits pilotes de son côté. Nous nous sommes alors dit : « Il faut vraiment réduire tout cela. Il faut déterminer ce qui va réellement faire bouger les lignes pour nous. » Quels sont les cas d’usage vraiment importants ?

Nous avons examiné notre activité. Que faisons-nous, chez Dell ? Nous avons retenu trois ou quatre cas d’usage. C’est tout. Trois ou quatre cas d’usage dont nous savions qu’ils définissaient Dell. Nous nous sommes mis d’accord sur tous les indicateurs clés de performance, puis nous avons également mené tout un travail sur la maturité des données.

Car c’est très bien de dire : « Ces cas d’usage vont faire bouger les choses. » Mais s’il faut énormément de temps pour préparer les données correspondantes, on se retrouve de nouveau face à un point de décision où l’on se dit : « Bon, peut-être que ce n’est pas le meilleur choix pour les premiers pilotes. »

Nous avons donc fait la même chose en interne. Nous avons donné la priorité aux cas d’usage que nous voulions mettre en production, vérifié que nous comprenions bien les données à préparer et nous nous sommes préparés au déploiement en production. Puis nous avons continué à surveiller ces indicateurs clés de performance.

Corey : C’est logique. Je suis heureux que vous mentionniez les données. On entend toujours dire que la stratégie d’IA est, en définitive, une stratégie de données. Lorsqu’une entreprise commence à prendre l’IA en production au sérieux, que signifie concrètement la maturité des données ?

Beth :Oui, personne n’a vraiment envie d’en parler, n’est-ce pas ? Parce que ce n’est pas la partie la plus amusante. Ce n’est pas : « J’ai cette charge de travail gigantesque, je fais ceci et cela, regardez, c’est incroyable. » Ce n’est pas vraiment amusant, sauf si l’on travaille dans le domaine des données.

Nous avons une évaluation de la maturité des données que nous réalisons dans le cadre de nos propres activités, et que nous proposons également à nos clients. Nous examinons notamment les éléments suivants. Tout d’abord, nous disons : ne regardez pas toutes vos données. C’est tout simplement accablant.

Quand nous parlons de maturité des données, nous parlons des cas d’usage prioritaires, et vous constaterez probablement que la quantité de sources de données à intégrer est limitée. Concentrez-vous donc sur leur maturité. Où sont ces données ? Pouvez-vous les trouver ? Sont-elles découvrables ?

Deuxièmement — et c’est particulièrement important lorsqu’on commence à travailler avec l’IA agentique — disposez-vous des autorisations adéquates ? Il faut vraiment être prudent avec les agents autonomes qui accèdent à des données auxquelles ils ne devraient pas accéder.

Et pouvons-nous les tracer ? Pouvons-nous remonter à leur origine ? La traçabilité des données est-elle claire ? Avons-nous créé quelque chose comme un produit de données ? Nous parlons beaucoup de ces produits de données, c’est-à-dire du fait de traiter les données comme des produits.

Mais c’est essentiellement cela. Avons-nous les autorisations adéquates ? Pouvons-nous retracer leur origine ? Sont-elles adaptées au bon cas d’usage ? Quelqu’un en est-il responsable ? Sont-elles gouvernées ? 

Et c’est également très important : leur gestion du cycle de vie est-elle assurée ? Lorsque vous entrez dans un monde où les données sont des produits, vous confiez réellement la responsabilité aux responsables de ces produits de données. Ils doivent non seulement fournir les données en temps voulu, mais aussi veiller à ce qu’elles soient exactes, correctes, gouvernées, soumises aux autorisations et conformes aux politiques. Tant que vous n’avez pas adopté ce modèle, il devient très difficile de passer à l’échelle, car vous retombez dans un monde de jeux de données préparés manuellement, où les pipelines de données ne font pas le travail à votre place. Passer à ce type de modèle fondé sur les produits de données change donc vraiment la donne. Nous l’avons fait assez tôt chez Dell pour nous aider avec bon nombre des cas d’usage que nous déployons aujourd’hui.

Corey : C’est formidable. Je vois beaucoup d’organisations commencer à expérimenter l’IA en utilisant simplement l’infrastructure à laquelle elles accèdent le plus facilement — en gros, celle qu’elles possèdent déjà. Mais lorsque l’utilisation devient persistante et commence à s’étendre à toute l’entreprise, comment cette réflexion sur l’infrastructure doit-elle évoluer ?

Beth :Oui, vous avez raison. Beaucoup de pilotes sont réalisés sur tout ce que les équipes peuvent trouver. Cela peut être leur propre matériel — je suis moi-même coupable, je l’ai fait sur mon ordinateur portable. Cela peut être n’importe quoi. Une ressource empruntée, par exemple. Peu importe. Leur objectif est de faire fonctionner le système.

Une fois arrivé au point où vous vous dites : « D’accord, maintenant je dois passer en production », il est très peu probable que l’infrastructure utilisée pour le pilote soit suffisante. Il est très peu probable qu’elle puisse évoluer. Il faut donc commencer à réfléchir à la façon d’assurer cette évolutivité du point de vue de l’infrastructure. Il existe plusieurs manières de découper le problème.

Au départ, nous disions : « D’accord, tout le monde doit acheter une grande AI Factory », mais cela représentait un investissement très, très important pour les clients, surtout lorsqu’ils n’avaient qu’un seul cas d’usage. Lorsqu’on arrive à plusieurs cas d’usage, on comprend parfaitement que cette approche de l’infrastructure et de l’AI Factory ait tout son sens à grande échelle.

Chez Dell, nous avons donc un peu réduit l’ambition et dit : « En fait, tirons les enseignements que nous avons maintenant compris de l’industrie : les entreprises ont tendance à commencer petit. »

Tout ce dont vous pouvez avoir besoin, c’est de vous assurer que vous disposez, par exemple, d’un bon serveur GPU pour l’IA, équipé de la pile logicielle adéquate. Cela peut suffire pour commencer. Vous faites peut-être simplement de l’inférence à petite échelle, puis vous pouvez monter en puissance. Vous pouvez ajouter des éléments d’infrastructure modulaires, passer à l’inférence d’entreprise, puis même à l’inférence distribuée en ajoutant progressivement ces couches, ces modules, si vous préférez.

Commencer petit reste donc vraiment important. L’écart entre l’infrastructure d’un pilote et une grande AI Factory distribuée est considérable. Prévoir des étapes intermédiaires pour y parvenir, en fonction des cas d’usage exécutés, constitue une stratégie très importante.

Il faut également préciser que tout ne sera pas nécessairement déployé sur site. Vous allez vous orienter vers une sorte d’approche hybride. C’est le cas de la plupart des clients. Si vous examinez les choses du point de vue des charges de travail d’IA, et notamment lorsque vous parlez d’agents, vous constaterez que certaines parties de ces workflows n’auront potentiellement pas besoin d’être exécutées sur site. Elles pourraient être dans le cloud. Elles ont peut-être besoin d’un autre type d’évolutivité. Et certaines fonctions devront rester sur site, notamment potentiellement en raison des données et de la sécurité.

Nous élaborons donc ce que nous appelons une stratégie de placement des charges de travail, fondée sur les cas d’usage que nous mettons en œuvre avec nos clients. Puis, en fonction de ce placement, nous déterminons les plateformes dont nous avons besoin. 

« Ce cas d’usage doit rester sur site. Très bien : AI Factory. » 

« Cette partie du cas d’usage pourrait éventuellement fonctionner sur un modèle de cloud public. Très bien. »

C’est donc ce type de stratégie. Nous parlons de modèles hybrides, mais il s’agit en réalité d’un processus de décision concernant les charges de travail d’IA : à quoi votre infrastructure doit-elle ressembler, que pouvez-vous utiliser dans le cloud public, que devez-vous conserver sur site et quelle approche vous permettra d’obtenir le résultat le plus rapidement ?

Corey : C’est logique. Et cela nous amène très bien à l’éléphant dans la pièce, à savoir le coût. L’IA peut sembler vraiment peu coûteuse quand on mène une petite preuve de concept. Mais à grande échelle, quand on parle de calcul, de stockage, d’inférence, de réseau et de déplacement des données, les coûts s’accumulent rapidement et atteignent des montants considérables.

Comment les entreprises doivent-elles envisager différemment l’économie de l’IA une fois que celle-ci devient une charge de travail opérationnelle ?

Beth : Oui, je pense que nous avons tous entendu le terme « tokenomics ». C’est probablement l’une des expressions les plus galvaudées en ce moment. Et quand les gens pensent aux tokenomics, ils pensent : « D’accord, il s’agit de la consommation ou du coût des jetons », c’est-à-dire, si vous voulez, du coût du modèle. Mais ce n’est qu’une partie de l’équation.

Vous l’avez mentionné. Ce n’est qu’une partie de l’équation lorsqu’il s’agit de déterminer ce qu’il vous en coûtera pour faire fonctionner tout cela en production. Si vous utilisez un modèle fondé sur des jetons, ce coût constitue un élément, mais ce n’est qu’une partie de l’ensemble.

Il faut procéder à une analyse du coût total de possession, qui inclut cette approche hybride. Il y a peut-être ici un coût de consommation de jetons pour cette charge de travail particulière exécutée dans le cloud, mais examinons aussi le coût d’exécution des éléments sur site. Cela doit faire partie de l’équation.

Nous examinons donc des éléments comme le calcul, le stockage et le réseau. Nous examinons le déplacement des données. Nous examinons les coûts d’entrée et de sortie. Mais nous prenons aussi en compte les coûts logiciels, l’électricité et le refroidissement. Chaque fois que vous exécutez une requête sur un modèle sur site, cela consomme de l’électricité. C’est une composante de l’équation.

Nous devons donc raisonner en termes de coût unitaire pour effectuer une tâche — une tâche utile — de bout en bout. À quoi cela ressemble-t-il réellement selon l’endroit où elle est exécutée ?

C’est réellement un calcul complexe, et aussi un calcul continu, car ces éléments ont tendance à évoluer. Tous les modèles n’auront pas le même coût par jeton à l’avenir. Il faut donc avoir cette conversation continue — je dirais plus large — sur les tokenomics, et pas seulement sur la consommation de jetons, mais sur tout ce qui l’entoure.

Vous devez assurer cette supervision dans la durée afin de pouvoir vous adapter, changer les choses et les déplacer vers l’emplacement optimal, selon qu’elles nécessitent ou non une fréquence élevée et une faible latence, en fonction de l’usage que vous cherchez à faire du cas d’utilisation. Et mettre en place un placement automatisé des charges de travail fondé sur ce type de paramètres de coût.

Corey : Oui. C’est très pertinent. Et je pense qu’un élément que les gens oublient parfois, c’est que les anciens coûts sont toujours là aussi. Il n’y a pas que les jetons.

Beth : Exactement. Cloud privé, cloud public — cela fait des années que nous avons cette conversation. C’est donc essentiellement un cloud d’IA, n’est-ce pas ? C’est très similaire.

Les calculs de coût total de possession sont très similaires jusqu’à un certain point, puis il faut ajouter cette nuance : « D’accord, maintenant j’utilise l’IA. Quels autres coûts dois-je engager ? Quels autres éléments dois-je prendre en compte quand je réfléchis à la meilleure stratégie économique pour exécuter ces charges de travail d’IA ? »

Mais vous avez raison. Il n’y a pas une grande différence entre ce dont nous parlions auparavant avec les comparaisons entre cloud public et cloud privé et l’IA. Il y a simplement quelques nuances.

Corey : C’est cela. Une fois que l’IA est en production, le modèle lui-même n’est qu’un élément d’un système bien plus vaste. Que faut-il superviser et gérer tout au long de ce cycle de vie pour garantir que l’application continue à fonctionner comme l’entreprise le souhaite ?

Beth : Oui. Comme nous venons de le mentionner, certaines parties de cette solution, notamment la plateforme, disposent déjà de solutions de supervision assez performantes. Les clients à l’échelle de l’entreprise appliquent déjà une couche de journalisation et de supervision.

Tout d’abord, assurez-vous donc que ces éléments sont en place. Ce sont les règles de base, le minimum requis, si vous préférez. Ensuite, vous devez vous demander : quels sont les nouveaux éléments auxquels nous devons réfléchir quand nous parlons d’IA, en particulier d’IA agentique ?

Il faut ensuite commencer à réfléchir au modèle lui-même. Peut-être à la dérive du modèle. Nous devons l’examiner et disposer d’un moyen de la superviser. Il faut aussi examiner les données. Les gens l’oublient souvent, mais la dérive des données est vraiment importante. Il faut également observer l’adoption de la solution correspondant au cas d’utilisation que nous avons déployée. Tant de gens sont impatients de mettre des éléments en production, mais ils ne vérifient pas vraiment si les utilisateurs s’en servent et obtiennent ensuite les retours en matière de coûts, de revenus ou autre indicateur clé de performance qui avait été défini lors du projet pilote. 

J’ai déjà mentionné l’importance de continuer à assurer cette supervision dans la durée. Il ne s’agit pas seulement de superviser les aspects techniques : « D’accord, ma pile fonctionne-t-elle correctement ? Mon IA fonctionne-t-elle correctement ? Mon agent fonctionne-t-il correctement ? Est-ce que je m’assure de ne pas avoir de vecteurs d’attaque sur mon modèle ? »

Il faut aussi se demander : « Est-ce que j’atteins réellement les objectifs que je m’étais fixés en matière d’indicateurs clés de performance ? » C’est également une composante très importante de la supervision, que les gens négligent souvent. Ils maintiennent les systèmes en production, mais ceux-ci n’apportent peut-être tout simplement pas la valeur attendue. Le retour sur investissement n’est peut-être pas à la hauteur de nos besoins.

Il faut donc, une fois encore, garder à l’esprit le coût récurrent et le retour sur investissement récurrent, en plus de la supervision technique.

Corey : L’IA en production change aussi, je dirais, les enjeux en matière de gouvernance. Lorsque ces systèmes commencent à influencer des décisions, à interagir avec les données de l’entreprise ou à agir par l’intermédiaire d’autres agents, où se situe finalement la responsabilité ?

Beth : Oui. On ne peut pas dire : « C’est le modèle qui m’a dit de le faire », n’est-ce pas ?

Corey : Non, cela ne marche pas.

Beth : Certains essaient pourtant. Mais cela ne peut tout simplement pas fonctionner.

La responsabilité se répartit à plusieurs endroits. Si vous utilisez l’IA pour effectuer une action au travail, que vous êtes le dernier humain dans la boucle et que vous allez concrètement faire quelque chose à partir de cette action, c’est votre responsabilité. Nous nous le rappelons constamment.

Nous disposons en interne de nombreux excellents outils d’IA, et nous répétons sans cesse : « Écoutez, si vous utilisez cet outil et que vous faites quelque chose avec, vous êtes responsable de cette dernière action. »

Tout ce qui a conduit à cette action relève de votre décision. Une personne dans cette boucle est donc l’utilisateur. Mais l’autre personne dans cette boucle, je dirais, surtout s’il s’agit d’un fonctionnement plus autonome avec des agents, est le responsable du processus métier. Le processus métier qui est automatisé et amélioré grâce à l’IA et à l’IA agentique : ce sont les responsables de ce processus métier, y compris de toute l’IA qu’il utilise.

Désormais, sous la responsabilité de ce responsable de processus métier, vous avez également plusieurs autres responsables. Nous avons parlé des produits de données. Si vous évoluez dans cet univers des produits de données, le responsable du produit de données sera responsable des données qui constituent une partie de cette solution.

Vous pouvez avoir un responsable de plateforme, par exemple un responsable de la plateforme AI Factory with NVIDIA. Il sera chargé de s’assurer que la plateforme fonctionne correctement. Vous pouvez aussi avoir un responsable du modèle si vous entraînez votre propre modèle.

Sous la responsabilité globale du responsable métier du processus, tous ces acteurs clés veillent également à ce que leurs composants respectifs respectent les règles que nous avons établies et atteignent les niveaux de service que nous avons jugés nécessaires.

Il y a donc beaucoup d’acteurs différents. Mais au bout du compte, l’utilisateur — s’il est la dernière personne dans ce flux de travail — doit s’assurer que tout est correct avant d’appuyer sur le bouton de lancement.

Et le responsable du processus métier, dont vous automatisez effectivement le processus avec l’IA : ce sont, je dirais, les deux principaux niveaux de responsabilité.

Corey : C’est une très bonne approche. Il faut comprendre que vous avez ces êtres humains et ces éléments clés qui se disent : « Cette partie relève de vous. Cette partie relève de vous. Veillez simplement à ce que tout fonctionne. Assurez-vous que le système fait ce qu’il doit faire. Assurez-vous qu’il ne déraille pas et ne se mette pas à attaquer des sites web ou quelque chose de ce genre. » C’est ce type de vigilance qu’il faut privilégier. 

Dans quelle mesure la réussite du déploiement de l’IA en production relève-t-elle d’un problème technologique, et dans quelle mesure pensez-vous qu’il s’agit d’un problème organisationnel ? Et une fois que l’on dépasse cette équipe d’innovation isolée, qui prend le relais et en devient responsable ?

Beth : Oui, je dirais que la technologie est la partie facile. C’est amusant, parce que c’est la partie sur laquelle nous nous concentrons tout le temps. Nous en parlons sans cesse. Nous parlons de la capacité technique de nos projets pilotes, et ainsi de suite.

Honnêtement, la partie la plus difficile est réellement le changement organisationnel. Cela a toujours été le cas pour tout projet de transformation. Ce n’est pas la transformation technologique. C’est la transformation humaine. C’est l’évolution organisationnelle qui doit être mise en œuvre. C’est la contrainte la plus difficile à surmonter dans le cadre de ces cas d’utilisation.

Nous l’avons toujours constaté, mais cela est désormais légèrement amplifié par l’autonomie de l’IA, car les choses évoluent de manière assez spectaculaire dans ce domaine. Les organisations changent beaucoup plus vite et plus rapidement qu’auparavant.

Les éléments dont nous parlons — et dont j’ai déjà parlé — sont les suivants : il faut avoir un responsable. C’est la première chose. Si vous envisagez de passer à la production, la préparation organisationnelle doit notamment répondre aux questions suivantes : qui sera le responsable ? Qui financera cela une fois en production ? D’où viendra l’argent ? Qui approuvera les changements ? Si j’ai besoin de modifier quelque chose, à qui dois-je m’adresser ? Qui approuvera cette modification ? Qui mesurera la valeur dans la durée et qui décidera si c’est utile ou non ?

En définitive, qui est responsable lorsque les choses commencent à dérailler ?

Tout ce que nous savons avec certitude pour les logiciels devient encore plus important avec les logiciels d’IA. Modèle opérationnel, sponsor métier, responsable produit, responsabilité des données et de la plateforme : nous en avons déjà parlé.

La sécurité et les risques doivent être des acteurs clés dans tout cela. Il faut mettre en place une gouvernance adéquate.

Vous devez disposer d’un plan d’adoption et observer également ce qui se passe réellement en matière d’adoption. L’évolution organisationnelle ne consiste pas seulement à déterminer qui maintiendra la solution en fonctionnement. Il faut aussi se demander : comment inciter les gens à utiliser cette solution ? C’est un point important.

Si l’on pense à l’IA et à certaines des craintes qu’elle suscite, les gens sont parfois un peu prudents : « Je vais commencer à l’utiliser pour mon travail, et peut-être qu’elle fera mon travail à ma place. » Une partie du changement organisationnel consiste donc à aider les gens à comprendre que l’IA est là pour leur permettre d’être plus rapides, plus performants et plus efficaces, et pour éliminer toutes les tâches rébarbatives. 

Nous avons également dû le faire en interne. Nous avons mis en œuvre plusieurs programmes pour nous aider à adopter l’IA en interne. Il n’y a donc pas seulement des équipes chargées de s’assurer que la solution elle-même fonctionne toujours correctement et affiche de bonnes performances : toute une équipe veille à ce que les collaborateurs l’utilisent de la bonne manière et s’en servent réellement pour les aider dans leur travail. Il y a donc de nombreux domaines différents. C’est très similaire à la plupart des transformations, mais l’IA apporte encore une fois quelques nuances, notamment en matière d’adoption.

Corey : Oui. Si nous nous projetons dans quelques années, qu’est-ce qui, selon vous, distinguera les entreprises qui auront véritablement opérationnalisé l’IA de celles qui continueront à mener une série d’expériences déconnectées les unes des autres ?

Beth : À quoi cela ressemblera-t-il ? Comment vais-je savoir si ces entreprises y sont vraiment ou non ? 

Si nous nous prenons comme exemple, je pense que nous y sommes pratiquement. Nous disposons d’un certain nombre de bons cas d’utilisation prêts pour la production et d’un processus de gouvernance solide.

L’une des premières choses que nous avons faites a été de nous assurer que nous n’avions pas simplement un ensemble de projets pilotes d’IA, mais un portefeuille d’IA. Examinons donc cela comme un ensemble de services que nous pouvons soit proposer nous-mêmes en interne pour gagner en efficacité et en productivité, soit proposer à nos clients. Ce sont tous des services. Ce sont désormais tous des produits. Traitez-les comme tels : des services et des produits.

L’autre signe de maturité, outre le fait qu’il s’agit d’un portefeuille et non d’une multitude de projets pilotes exécutés quelque part, est la réutilisabilité. On peut savoir qu’une entreprise opérationnalise l’IA lorsqu’elle peut prendre un projet pilote qui a validé tous ses indicateurs clés de performance et dire : « Hop, il est maintenant en production », parce que toute cette base réutilisable est déjà en place. J’ai des produits de données réutilisables. J’ai peut-être créé auparavant un produit de données utilisé par un autre cas d’utilisation. Je peux maintenant réutiliser ce produit de données pour ce cas d’utilisation particulier.

La fabrique sous-jacente elle-même — nous l’appelons AI Factory with NVIDIA, parce que c’est une fabrique. Elle est conçue pour fonctionner ainsi : « il suffit de l’activer et le résultat sortira ». Il est donc très facile de déployer des solutions sur une plateforme existante, déjà sécurisée et gouvernée.

C’est un autre élément clé : sa répétabilité.

Et encore une fois, l’idée est de ne pas mesurer uniquement les clics de déploiement. Vous mesurez si cet élément vous apporte ou non le retour sur investissement dont vous avez besoin dans la durée. Le suivi continu des indicateurs clés de performance, des caractéristiques de fonctionnement et de tous ces éléments : voilà ce qu’est un environnement d’IA opérationnalisé et hautement performant.

Corey : C’est certain. Eh bien, Beth, merci beaucoup de nous avoir rejoints aujourd’hui.

Avant de vous laisser partir, où les gens peuvent-ils en apprendre davantage sur les activités de Dell Technologies dans le domaine de l’IA d’entreprise ?

Beth : Une quantité considérable d’informations est disponible sur Dell.com, et j’encourage vivement les gens à aller y jeter un œil. De là, vous pourrez accéder à de nombreux autres contenus.

Vous pouvez accéder à mon domaine, qui concerne les services. Vous pourrez découvrir tous les excellents services que nous proposons, comme les services de gouvernance, les services AI Factory, les services de données — tous ces éléments y sont également disponibles.

Commencez donc par Dell.com. Vous y trouverez une quantité impressionnante d’informations sur nos produits, nos services, notre approche et la manière dont nous avons procédé ; cela vous guidera vers les sujets qui vous intéressent.

Corey : Excellent. Beth, merci beaucoup d’avoir pris le temps de vous entretenir avec nous aujourd’hui.

Beth : Merci beaucoup.

Corey : Et pour découvrir d’autres conversations de ce type, rendez-vous sur eWeek.com. Vous pouvez également aimer cette vidéo et vous abonner, où que vous la regardiez, et suivre eWeek sur LinkedIn, Facebook et X.

Je suis Corey Noles. Merci d’avoir regardé. À la prochaine dans eSpeaks.