Le DSI avisé : Épisode 1 – « Votre LLM peut-il passer un audit ? »
Dans ce premier épisode de « The Savvy CIO », l’animateur Bradd Busick s’entretient avec le Dr Radha Plumb, vice-présidente d’IBM chargée de la transformation axée sur l’IA et ancienne directrice numérique et de l’IA au Pentagone, sur la manière de préparer les déploiements d’IA en milieu réel à un audit. Elle aborde des questions épineuses, telles que : en quoi votre modèle de langage à grande échelle (LLM) diffère-t-il des systèmes traditionnels auxquels votre auditeur est habitué ? Quels risques diffuses devez-vous surveiller si vous souhaitez maintenir le rythme du progrès ? Le fait de vous assurer que vos systèmes fonctionnent comme prévu peut-il réellement accélérer votre gouvernance de l'IA ?
Ils abordent également les obstacles à la conformité de bout en bout : le contrôle d'accès basé sur les rôles et les décisions relatives à l'accès aux données ; la nécessité d'une couche d'orchestration pour acheminer les données entre les modèles de langage à grande échelle (LLM) et les méthodes déterministes ; et les raisons pour lesquelles de nombreux échecs surviennent à cette intersection entre technologie et processus.
En s'appuyant sur le modèle d'IBM, où l'on « goûte à sa propre cuisine », le Dr Plumb met l'accent sur la transparence du modèle, l'importance de disposer de données bien délimitées pour prendre des décisions conformes à la réglementation, explique pourquoi l'implication précoce du RSSI est essentielle lors de la conception de la sécurité, et pourquoi la documentation des flux de travail de l'entreprise permet non seulement un déploiement plus rapide de l'IA, mais aussi un déploiement capable de résister à un audit.
Transcription de l'épisode « Votre LLM peut-il passer un audit ? »
Dr Radha Plumb : Il faut une coordination et une bonne connaissance des préférences de l’organisation, et c’est quelque chose que vous allez devoir déterminer et mettre en place pour votre organisation. Je pense que cette couche d’orchestration est la première véritable grande question à laquelle les DSI doivent commencer à réfléchir. Quel est votre système d’exploitation d’IA ? Où placez-vous ce plan de contrôle, et comment allez-vous l’adapter à vos besoins spécifiques ?
Bradd Busick : Vous écoutez « The Savvy CIO : Modernize Wisely », une émission proposée par Park Place Technologies, qui aide les entreprises à stimuler l’innovation en réduisant le temps et l’argent consacrés à la gestion de l’infrastructure informatique, tout en améliorant les performances et la disponibilité. Je suis votre animateur, Bradd Busick.
Vous êtes-vous déjà demandé : « Comment suis-je censé moderniser mon entreprise alors que le budget ne le permet pas ? » « Puis-je mener à bien cette innovation sans mettre en péril l'ensemble de l'activité ? » Y a-t-il quelqu’un qui parvient réellement à tout faire alors qu’on a l’impression de manquer de tout ? Si vous avez répondu oui à l’une de ces questions, alors cette émission est pour vous, car vous n’êtes pas seul. Et pour le prouver, je vais parler des contraintes budgétaires, l’IA, les audits, la sécurité et l’art de maintenir l’activité sans tout faire capoter, aux côtés de ceux qui s’attaquent réellement à ces problèmes jour après jour.
Tous les DSI subissent actuellement la même pression : agir rapidement dans le domaine de l’IA ou se faire distancer. Mais cette course à la rapidité est assombrie par une menace : le défi de l’audit. Le Dr Radha Plumb connaît les deux facettes de cette équation mieux que quiconque. Elle a passé des années aux plus hauts échelons du ministère américain de la Défense. Elle a occupé le poste de responsable du numérique et de l’intelligence artificielle au Pentagone, où elle a dirigé les efforts du département en matière d’adoption de l’IA, des données et de l’analyse, et a ouvert de nouvelles voies pour acquérir et déployer à grande échelle les technologies numériques au sein de l’une des organisations les plus grandes et les plus strictement réglementées de la planète. En somme, elle a abordé les questions des données, des risques et de la responsabilité sous pratiquement tous les angles imaginables.
Aujourd’hui, en tant que vice-présidente d’IBM chargée de la transformation axée sur l’IA, elle mène une initiative qu’elle appelle « client zéro » : il s’agit de mettre en œuvre en interne les technologies et concepts d’IA afin de les tester avant de les déployer chez les clients. En substance, IBM goûte à sa propre cuisine, le tout sous son œil avisé et son palais raffiné. Je m’entretiens aujourd’hui avec elle de ce qu’il faut pour que le déploiement de votre IA soit réellement prêt pour un audit, non pas en théorie, mais dans la pratique. Ce que les auditeurs vont demander, ce à quoi la plupart des organisations ne sont pas préparées, et pourquoi le compromis entre rapidité et sécurité pourrait bien être la plus grande idée fausse qui freine actuellement les DSI.
Dr Radha Plumb, bienvenue dans « The Savvy CIO ».
Dr Radha Plumb : Merci beaucoup de m'avoir invitée.
Bradd Busick : Je suis ravi d’être parmi vous. J’avais vraiment hâte de passer ce moment avec vous aujourd’hui. Pour commencer, pourriez-vous nous parler un peu de vous, de votre rôle chez IBM, et nous expliquer pourquoi vous êtes exactement la personne idéale à qui je peux poser toutes ces questions sur la manière de faire valider un LLM lors d’un véritable audit ?
Dr Radha Plumb : Eh bien, je pense que je vais commencer par dire que je suis en fait économiste de formation, et beaucoup de gens me demandent : « Comment, en tant qu’économiste, avez-vous fini par atterrir ici ? » Et j’aime plaisanter en disant que je ne suis pas ce genre d’économiste. J’ai donc grandi en pratiquant l’économétrie appliquée, ce qui correspondait au « big data » avant même que le « big data » n’existe. J’ai donc réfléchi de manière fondamentale à ce que signifie disposer de données et les utiliser dans toute une série d’applications différentes pour qu’elles aient un sens. Et je pense qu’une grande partie du débat actuel sur l’IA porte en réalité sur les données. Je suis donc ravie d’avoir l’occasion d’aborder ce sujet ici et d’expliquer à quoi cela ressemble dans la vie réelle, car, honnêtement, ce n’est pas très glamour et il n’y a pas de solution miracle, mais il y a certaines choses que nous pouvons faire, en tant que communauté, pour progresser dans ce domaine.
Bradd Busick : J’adore votre approche axée sur les données, ce qui est vraiment intéressant, car vous êtes passé du monde universitaire à Google, puis à Facebook, au Pentagone et enfin à IBM. Je veux dire, quand on regarde ce parcours, on a l’impression que vous avez abordé le même problème fondamental sous toutes sortes d’angles différents. Comment faites-vous pour amener de grandes organisations complexes à prendre de bonnes décisions grâce aux données tout en gérant les risques de manière responsable ?
Dr Radha Plumb : Souvent, il s’agit avant tout d’être très, très clair sur la nature du risque, sur les personnes concernées et sur celles qui peuvent en assumer la responsabilité pour agir. Ainsi, très souvent, les gens se retrouvent bloqués, freinés ou ont l’impression de ne pas pouvoir agir parce qu’ils se disent : « C’est risqué. Il y a un risque de sécurité, un risque de conformité, un risque lié à l’auditabilité. » Et en creusant la question, en épluchant cet oignon jusqu’à la couche la plus fine, quel est le risque réel ? Et maintenant, définissons-le. Que peut-on faire pour l’atténuer ou non ? Et qui va assumer ce risque, en fin de compte ? Sera-ce le directeur juridique ? Sera-ce le directeur de la sécurité ? Sera-ce le responsable du compte de résultat ? Et demandez-leur : « Ce risque vaut-il la peine d’être pris ? » Souvent, grâce aux mesures d’atténuation, c’est le cas ; mais souvent aussi, le jeu n’en vaut pas la chandelle, et vous parvenez alors à une décision qui vous permet de passer à autre chose. Mais je pense que cette zone grise de risque indéfini est véritablement l’ennemi du progrès.
Bradd Busick : Et il ne peut y avoir de risque sans gouvernance. Donc, en fait, cela me rappelle un peu l’évolution du DevOps, où, en tant que secteur, nous avons passé des années à considérer la rapidité et la stabilité comme des forces opposées avant de réaliser qu’il s’agissait en réalité d’un problème de conception du système, et non d’une caractéristique inhérente au développement de logiciels. Est-ce là un parallèle pertinent avec la situation actuelle en matière de gouvernance de l’IA ?
Dr Radha Plumb : Oui. J’aime bien dire, je suppose, que la meilleure analogie qui me vienne à l’esprit est celle-ci : de meilleurs freins permettent d’avoir des trains plus rapides, et cela vient de l’évolution des trains, où, bien sûr, contre toute attente, on a réussi à faire rouler les trains plus vite entre deux arrêts grâce à des freins plus performants et plus fiables. Et je pense à la gouvernance de l’IA dans ce contexte, où, en réalité, la gouvernance de l’IA est l’élément fondamental qui vous permet de savoir que vos solutions d’IA font ce que vous voulez qu’elles fassent et ne font pas ce que vous ne voulez pas qu’elles fassent. Voilà en quelques mots. Et en réalité, c’est également ce dont vous avez besoin pour que cela soit efficace. Donc, pour agir rapidement, vous devez intégrer ces étapes de gouvernance dans le processus, les y ancrer, et lorsque vous le faites, vous obtenez plus rapidement un résultat bien plus solide, pour poursuivre l’analogie.
Bradd Busick : Quand on pense aux entreprises, on pense à des personnes, à des processus et à la technologie. Partons donc de ce cadre de référence, en gardant à l’esprit que toutes les entreprises ont besoin de l’IA, afin de préparer le terrain pour notre public. L’une des choses qui rend les modèles de langage de grande envergure (LLM) si uniques, c’est que même leurs créateurs eux-mêmes ne comprennent pas encore pleinement ce qui se passe dans cette « petite boîte noire », pour ainsi dire. Ainsi, vous et moi pourrions tous deux recevoir une même consigne et générer des réponses significativement différentes, et personne ne déteste davantage cette imprévisibilité qu’un auditeur, car son travail consiste entièrement à vérifier pourquoi le système a agi ainsi, et sa tâche devient incroyablement plus difficile avec un LLM. Plongeons-nous donc dans ce vrai cas épineux. Expliquez-moi, ainsi qu’à l’auditoire, en quoi un LLM est fondamentalement différent du type de systèmes que votre auditeur a l’habitude d’évaluer, et pourquoi il est nécessaire de comprendre cet écart.
Dr Radha Plumb : Je pense qu’il est utile de décomposer cette « boîte noire » en différents éléments qui la composent. Il y a donc les entrées de cette boîte, qui correspondent essentiellement aux données et au contexte. Par « données », j’entends littéralement les données, qui peuvent être des données structurées, comme vos informations financières et vos chiffres, des données semi-structurées, comme des éléments tirés de vos contrats, ou encore des données véritablement non structurées, comme de longs documents ou même des images. Et tout cela est intégré dans vos algorithmes avec le contexte, c’est-à-dire la manière dont ces données sont liées à l’activité et à leurs utilisations ?
Nous avons l'habitude de combiner ces éléments pour obtenir des résultats déterministes. Je prends donc un peu de contexte ; je vais utiliser l’analogie la plus simple : je prends un ensemble de données dans un fichier plat, comme une feuille de calcul, et j’applique une formule statistique connue, comme une moyenne, je l’introduis, j’obtiens la moyenne, et je peux répéter cette opération autant de fois que je le souhaite pour obtenir une distribution, ou je peux observer ces données au fil du temps pour obtenir une série chronologique. Ce sont là des résultats déterministes.
Ce que les grands modèles de langage (LLM) apportent, c’est de s’appuyer sur cette immense quantité de données et de liens que nous connaissons et que nous ignorons, et d’y ajouter une couche d’inférence pour générer des combinaisons d’informations que nous ignorons et que nous n’aurions pas pu prévoir, afin d’obtenir un résultat inférentiel plutôt que déterministe. C’est la boîte noire. C’est en quelque sorte la recette secrète. L’avantage, c’est que cela permet de créer beaucoup de choses auxquelles vous n’auriez peut-être pas pu accéder auparavant, ni même auxquelles vous n’auriez jamais pensé. L’inconvénient, c’est que l’on ne connaît pas exactement tous les éléments qui ont conduit à ce résultat, ni comment le reproduire à chaque fois.
Je pense donc que vous devez vraiment vous demander, dans votre processus : « À quel moment ai-je besoin d’une approche créative, nouvelle et différente ? » Et c’est là que les LLM entrent en jeu. À quel moment ai-je besoin de résultats déterministes ? C’est là que vous pouvez utiliser vos outils analytiques traditionnels ou vos MLOps, à l’instar des méthodes d’IA classiques. Tout ne doit pas nécessairement passer par les LLM. Et ensuite, comment puis-je combiner, quel est le plan de contrôle qui les combine pour produire le résultat que je souhaite, qui soit à la fois un résultat prévisible pour les auditeurs, l’avantage du génératif là où vous en avez besoin, et la prévisibilité du déterministe là où cela s’impose ?
Bradd Busick : J’adore cette approche. Et si l’on se place du point de vue d’un DSI qui, dans certains cas, n’a pas encore emprunté cette voie, ou dans d’autres cas, l’a déjà empruntée, quel sera, selon vous, le premier obstacle en matière de conformité dont un DSI devrait se préoccuper s’il en est encore aux prémices de ce parcours et s’apprête à passer à un système basé sur l’IA ? À quoi devrait-il réfléchir ?
Dr Radha Plumb : Permettez-moi d’aborder la question du point de vue d’IBM, simplement parce que je pense que cela constitue une illustration utile. Vous avez votre couche de données, et vous avez besoin d’une gouvernance et de contrôles des données. Souvent, pour les DSI, cela relève de la compétence d’un directeur des données, et il y aura une gouvernance et des contrôles des données, comme vous le savez. La toute première question qu’on va donc vous poser est la suivante : comment décidez-vous qui a accès à quelles données pouvant être extraites ? Quel est votre contrôle d’accès basé sur les rôles ? Comment gérez-vous les identités et les informations d’authentification ?
Donc, la première étape, chez IBM par exemple, consiste à disposer d’un système qui relie votre identifiant utilisateur, comme c’est le cas dans la plupart des grandes entreprises, à votre rôle et à cet accès. À présent, vous devez intégrer ces données dans votre système algorithmique, et une fois que vous l’avez fait, vous avez besoin d’un outil d’orchestration : ces données sont-elles destinées à une conversation avec un modèle de langage de grande envergure (LLM) ? Ces données sont-elles destinées à un sondage déterministe ? Sont-elles simplement transmises à un tableau de bord ? Sont-elles intégrées à un rapport ? Ce plan de contrôle est un domaine où vous avez besoin d’orchestration et d’une connaissance des préférences de l’organisation, et c’est quelque chose que vous allez devoir définir et mettre en place pour votre organisation. Les entreprises ne seront pas toutes identiques sur ce point, et cela variera également selon les applications.
Nous, par exemple, abordons la gestion des données financières de manière très différente de celle que nous adopterions pour la gestion des règles relatives aux couleurs et aux éléments graphiques de la marque qui doivent être intégrés au contenu. Ces deux aspects sont soumis à des règles. Nous ne pouvons pas avoir 87 nuances de bleu différentes pour IBM. Mais nous allons traiter cela différemment de la manière dont nous traitons la comptabilisation des bénéfices et du chiffre d’affaires dans nos systèmes financiers, et il y a beaucoup d’éléments entre ces deux extrêmes. Je pense donc que cette couche d’orchestration est la première véritable grande question à laquelle les DSI doivent commencer à réfléchir. Quel est votre système d’exploitation d’IA ? Où placez-vous ce plan de contrôle, et comment allez-vous l’adapter à vos besoins spécifiques ?
Bradd Busick : Oui. Je trouve que c'est très bien dit. Et quand on réfléchit à ce que signifie réellement l’auditabilité du point de vue d’un auditeur, être capable d’articuler clairement, comme vous l’avez souligné, le contrôle d’accès basé sur les rôles, c’est-à-dire ce à quoi cette personne a accès ou non, voici ce qui était l’entrée et voici ce qui était la sortie dans ce plan de contrôle orchestré, avec un rythme, un ordre et une discipline, plus facile à dire qu’à faire, comme nous le savons tous les deux très, très bien. Comme vous avez vu tant de types différents de ces déploiements dans tant de secteurs différents, où pensez-vous que se situe le plus grand problème pour la plupart des entreprises ? Est-ce les données ? Est-ce le modèle ? Est-ce quelque part entre les deux ? Donnez-moi quelques précisions à ce sujet.
Dr Radha Plumb : Je dirais que c’est probablement à la croisée de la technologie et des processus. C’est un peu à la fois les données et le modèle, mais c’est vraiment… On a l’impression aujourd’hui, je crois, qu’il suffit d’ajouter une pincée de magie de l’IA à un processus peut-être trop complexe ou mal défini pour obtenir des résultats commerciaux réellement mesurables, mais ce n’est tout simplement pas le cas. Aucun directeur des systèmes d’information ne pourra régler ce problème tout seul. Je pense donc que la véritable solution consiste à essayer d’imposer une discussion difficile sur ce que devrait être le processus, où la technologie doit s’intégrer, ce qu’elle doit faire, mais aussi où le processus doit être modifié pour bien fonctionner.
Je vais vous donner un exemple concret. Nous travaillons actuellement sur ce workflow « agentique » dans le domaine de la finance afin de comparer les prévisions budgétaires aux résultats réels, un problème très courant. Et oui, nous pouvons le faire, mais il faut réfléchir au rôle de l’agent et définir des préférences quant à l’ampleur de l’écart qui va vous intéresser. Mais il faut également en quelque sorte standardiser les rapports, car on ne peut pas automatiser la détection des écarts pour une infinité de cas. Ce n’est pas un problème technologique. Nous pouvons choisir le seuil que vous souhaitez. C’est une question de processus et de contrôles. Et cela doit venir de l’entreprise, puis être relié à la technologie ; cette transposition doit avoir lieu. Ensuite, cela doit être intégré de manière prévisible et vérifiable, afin que, lorsque notre directeur financier demande : « Pourquoi examinons-nous cet écart et pas celui-là ? », Il y a une réponse métier claire, puis une solution technologique qui la sous-tend et qui peut être démontrée concrètement pour l’étayer. Et cette combinaison, je pense, représente une grande complexité qui doit être résolue.
Bradd Busick : On a vraiment l'impression qu'il y a un peu d'art et de science là-dedans, et on a l'impression que les gens confondent la gestion des données avec la gestion du modèle lui-même.
Dr Radha Plumb : Oh, oui.
Bradd Busick : Comment envisagez-vous cette différence dans le cadre du travail que vous menez et dirigez actuellement ?
Dr Radha Plumb : J’essaie d’aborder cette question par étapes, en quelque sorte, car je pense que la gouvernance des données constitue, d’une certaine manière, une condition préalable indispensable avant de pouvoir mettre en place tout type d’IA ou de solution numérique. C’est un peu comme le carburant qui va alimenter votre modèle d’IA ; il faut donc mettre en place cette couche de gouvernance de manière adéquate. Je pense que le problème, c’est souvent que l’on s’arrête là. On a donc sa gouvernance des données, ses métadonnées, son contrôle d’accès basé sur les rôles, ses systèmes de référence, et on se dit : « Super. Maintenant, je vais mettre l’IA à contribution. » Et vous devez alors réfléchir : bon, une fois que j’aurai fourni mes données à ce système, que va-t-il se passer ? De quelle gouvernance des modèles ai-je besoin ? De quelles informations ai-je besoin pour pouvoir voir ce que fait le modèle, à quelles données il accède, l’actualité de ses données, les performances du modèle au fil du temps, et si je constate des biais particuliers ? Tous les éléments que l’on testerait habituellement dans des solutions analytiques, disons des solutions déterministes, doivent être réintégrés.
Mais le problème auquel nous sommes confrontés est qu’il n’existe pas de tests reconnus de la même manière pour ce type de modèles. Nous essayons donc de nous concentrer davantage sur la transparence, en cherchant à comprendre ce que fait le modèle, à quelles données il accède, à quel moment il effectue des inférences, en essayant d’apporter plus de transparence aux différentes étapes du processus d’inférence, et d’utiliser cela pour tenter de déterminer d’où pourraient provenir d’éventuels écarts et résultats inattendus. Espérons qu’avec le temps, nous disposerons également de meilleurs outils d’évaluation, et le secteur continue de les développer. Mais je pense que c’est là que réside véritablement la complexité actuelle : il n’existe pas de méthode intégrée et bien établie pour tester l’exactitude ou la précision de la même manière que celle à laquelle nous sommes habitués.
Bradd Busick : Je pense que votre remarque est tout à fait pertinente. En effet, on a vraiment l’impression de piloter l’avion tout en essayant encore de le construire, dans un contexte réglementaire qui est encore en cours d’élaboration. D’après votre expérience auprès de toutes les organisations avec lesquelles vous avez eu l’occasion d’interagir, si un auditeur venait s’asseoir à côté de la plupart des directeurs informatiques avec lesquels vous avez travaillé aujourd’hui, pensez-vous que ces organisations auraient réellement une réponse toute prête à donner si un auditeur leur disait : « Alors, dites-moi ce qui entre et sort de votre LLM. Comment est-il gouverné ? »
Dr Radha Plumb : C’est drôle, parce que je venais justement d’avoir une conversation avec le directeur des investissements d’une grande banque qui disait, en substance, que nous n’utilisons pas l’IA pour bon nombre de nos décisions d’investissement pour cette raison. Nous ne pouvons pas prendre de décisions sans pouvoir justifier les données qui entrent et qui sortent.
Il y a des choses que nous pouvons faire et d’autres que nous ne pouvons pas faire, et je pense que c’est là un bon exemple de situation où nous allons devoir collaborer avec les auditeurs et les autorités de régulation pour trouver un juste milieu raisonnable. Ce que vous pouvez faire, et ce que tout le monde devrait faire, c’est préciser, pour les décisions soumises à une réglementation stricte, quel est l’ensemble restreint de données que le modèle peut utiliser pour prendre cette décision. Et cela constituera, je pense, un excellent point de départ pour les régulateurs. Je pense ensuite que la deuxième chose à faire est d’utiliser des outils ; là encore, nous en avons un chez IBM qui s’appelle Watsonx Governance, mais il existe toute une gamme d’outils de gouvernance qui vous indiquent précisément ce que fait votre modèle. Alors, sur quoi votre modèle effectue-t-il ses inférences ? Comment se comporte-t-il ? Cette transparence va être vraiment importante pour les autorités de régulation.
Et puis, la dernière étape, c’est quand on a ajouté des solutions basées sur des agents… Si vous réfléchissez à ce qu’est un agent, il s’agit d’une RPA reliée à un ensemble de signaux issus d’un vaste ensemble de données que vous traitez essentiellement à l’aide du traitement du langage naturel. Ces ensembles d’actions doivent donc être reliés aux données. Vous devriez pouvoir affirmer en toute transparence : « Voici l’ensemble des actions qu’il effectue. Voici les seuils à partir desquels ces actions sont déclenchées. » Et cela fournit désormais à l’auditeur toutes les informations nécessaires, à l’exception de la manière très détaillée dont les données sont transformées par le modèle pour atteindre ces seuils, et je pense que pour la plupart des secteurs réglementés, mais pas tous, secteurs réglementés, cela vous permettra de mener à bien un entretien avec un auditeur.
Il convient toutefois de préciser qu’il existe actuellement certains éléments que nous ne savons pas encore intégrer correctement dans ces systèmes LLM, et qu’il s’agit en partie d’accepter ce que l’on ne peut pas changer. Il y aura donc des cas où vous pourrez le faire et contribuer à rationaliser les processus grâce à cet outil, mais cela devra être transmis à un être humain, et c’devra examiner le dossier et prendre la décision en fonction des exigences légales, et c’est là encore un ensemble de questions que nous ne devrions tout simplement pas essayer de résoudre uniquement par la technologie pour le moment.
Bradd Busick : À l’heure actuelle, il est assez largement admis que la plupart des organisations considèrent la sécurité et la rapidité comme les deux extrémités d’une balançoire. Quand la rapidité augmente, la sécurité diminue. Quand la sécurité augmente, cela ralentit le processus. Pensez-vous que cette conception de la vitesse et de la sécurité s’applique réellement à l’IA ou est-il possible de concilier les deux ?
Dr Radha Plumb : Je pense qu’il faut les deux, et qu’il faut donc changer la donne quant à la place qu’occupe la sécurité dans le débat. Ainsi, chez IBM — et c’était déjà le cas au Pentagone —, nous mettons particulièrement l’accent sur le fait qu’il faut intégrer la sécurité dès la conception. Les toutes premières discussions que j’ai au sujet de tout nouvel outil d’IA ont lieu avec notre RSSI. Je m’entretiens avec lui de nombreuses fois par jour et je connais pratiquement tous les membres de son équipe par leur nom. Ce n’est pas un hasard. C’est parce que si je ne parviens pas à définir correctement les règles de sécurité et les informations dont ils ont besoin, je ne peux pas procéder au déploiement.
Et en entamant ces discussions dès le départ, je sais s’il s’agit d’une décision de développement ou d’achat, les questions qu’ils doivent poser, les intégrations qu’ils souhaitent tester, je sais tout cela dès le départ, et je peux obtenir rapidement des réponses et me faire une idée précise de la viabilité du projet. Cela signifie qu’au final, nous obtenons un résultat dont nous savons qu’il sera conforme et évolutif. Et cette sécurité intégrée, je pense, est ce qui nous permet de trouver un équilibre entre rapidité et sécurité. Et je n’irais même pas jusqu’à parler d’équilibre. Je dirais plutôt que cela crée une dynamique vertueuse : la sécurité dès la conception garantit des résultats conformes, ce qui permet un déploiement rapide, ce qui permet à son tour de renforcer encore davantage la sécurité dès la conception. Cette dynamique vous fait avancer beaucoup plus vite.
Bradd Busick : J’apprécie beaucoup la façon dont vous expliquez l’importance de connaître par leur nom tous les membres de l’équipe de sécurité. Je dirais à nos auditeurs que c’est un concept qui leur est vraiment étranger. Dans certains cas, le RSSI travaille contre eux plutôt qu’avec eux. Et pourtant, ce que je retiens de vos propos, c’est justement l’importance cruciale – et peut-être même l’avantage concurrentiel – d’impliquer les équipes de sécurité et de gestion des risques dès le début d’une initiative ou d’un projet, plutôt qu’à la fin. Pourquoi pensez-vous que cela soit si rare aujourd’hui, compte tenu du nouveau monde dans lequel nous vivons ?
Dr Radha Plumb : Je pense que, bien souvent, les gens veulent déployer des solutions rapidement, et ils pensent que s’ils parviennent simplement à démontrer une valeur métier suffisante grâce à ces utilisations, ils pourront convaincre l’équipe de sécurité de les suivre. Et souvent, cela entraîne cette discussion sur les risques dont nous parlions au début, où l’on dit : « Il y a ce risque majeur dont l’atténuation va nous coûter très cher, et il y a cette valeur commerciale importante : qui, entre le responsable du compte de résultat et le RSSI, souhaite assumer ce risque ? » Et c’est une solution possible, mais c’est un processus lent qui engendre soit un risque supplémentaire, soit un refus.
Nous avons constaté qu’il était bien plus efficace de limiter d’emblée la discussion à quelques questions clés, à savoir : « Où pouvons-nous utiliser cela ? Comment souhaitons-nous l’utiliser ? Quelles données allons-nous utiliser ? Quels risques cela engendre-t-il ? » Et avec le RSSI, toute une série de mesures d’atténuation et d’ajustements progressifs qui interviennent au fur et à mesure que vous développez votre MVP ou que vous effectuez vos premiers tests d’intégration, selon qu’il s’agisse d’une solution développée en interne ou achetée, vous pouvez mettre en œuvre toutes ces mesures parallèlement, ce qui signifie concrètement que la décision finale que vous prenez est la suivante : « Bon, nous avons ici quelques risques que nous ne pouvons pas atténuer. Nous ne pensons pas qu’ils soient si importants, compte tenu de la valeur métier. Allons-y. » Tout le monde est vraiment satisfait de cette décision. Mais cela nécessite beaucoup plus de travail en amont avec l’équipe, et les gens n’ont tout simplement pas encore pris la décision mentale de déplacer l’ensemble du processus plus en amont. C’est une caractéristique de conception. Ce n’est pas un contrôle de conformité.
Bradd Busick : Ouais. J’adore ça. L’idée que ce soit une fonctionnalité de conception est tout à fait pertinente. Je pense que c’est nouveau, et je pense que pour certains, c’est inhabituel, notamment parce qu’ils n’ont pas pris le temps de réfléchir à la manière dont nous voulons réellement planifier. Dans certains cas, on les a directement plongés dans la situation suivante : « Au fait, vous disposez d’une plateforme d’IA, qu’allez-vous en faire ? » Donc, si l’on pense aux DSI du monde entier qui disposent aujourd’hui de plateformes qui n’avaient pas d’IA il y a dix ans, mais disposaient du Big Data, et qui se retrouvent aujourd’hui face à une plateforme dotée de capacités agentiques qui s’activent chaque nuit, quelle est la seule chose que vous leur diriez de commencer à faire différemment dès demain ?
Dr Radha Plumb : C’est drôle, parce qu’on a l’impression que ça devrait être une question de technologie, alors que je vais parler exclusivement d’une question de processus, ce que je conseillerais à vos DSI, c’est d’aller comprendre les flux de travail et comment ils s’articulent au sein de votre entreprise. Encore une fois, je vais prendre l’exemple d’IBM, mais nous avons fait exactement la même chose au Pentagone : nous avons décomposé l’activité en 10 grandsde bout en bout, au sein desquels se trouvent des ensembles d’activités, et c’est ainsi que nous envisageons le déploiement des agents. Mais si vous disposez de ce catalogue, dès que vous identifiez de nouvelles fonctionnalités, dès que vous identifiez de nouvelles capacités, vous pouvez les associer très rapidement à l’ensemble des opportunités concernées, en précisant où et comment elles s’appliquent, puis rassembler ces équipes pour former une équipe interfonctionnelle chargée de mettre en œuvre et de déployer cette nouvelle technologie.
Mais si vous n’avez pas mis en place dès le départ ce genre de processus un peu fastidieux lié à votre technologie, qui vous permet de savoir, par exemple : « Bon, voici les différentes étapes de notre processus de vente et voici comment elles sont reliées à notre Sales Cloud. » Maintenant, j’ai de nouvelles fonctionnalités qui viennent d’être lancées sur mon Sales Cloud, ou une nouvelle application avec laquelle nous venons de conclure un partenariat et que nous achetons, je devrais savoir exactement où les placer et je devrais savoir qui j’ai pouvoir appeler pour dire : « Salut, formons une équipe pour examiner ça, faisons un test rapide de 30 jours pour voir si ça améliore réellement la productivité, puis on recommence. » Et c’est en quelque sorte l’approche que nous avons adoptée : cet investissement initial est fastidieux, mais il permet vraiment d’accélérer le déploiement.
Bradd Busick : Eh bien, j’espère que nos auditeurs avaient les mains libres aujourd’hui, car vous nous avez vraiment fait découvrir plein de choses. Ce fut un plaisir de discuter avec vous, Radha. Un grand merci d’avoir participé à l’émission « The Savvy CIO ».
Dr Radha Plumb : Merci de m'avoir invitée.
Bradd Busick : J’ai beaucoup apprécié la conversation d’aujourd’hui avec le Dr Plumb. Je pense que plusieurs points m’ont particulièrement marqué. Premièrement, intégrer la sécurité dès le début et de manière régulière fait souvent la différence entre la réussite et l’échec d’un déploiement. Et j’ai beaucoup apprécié quand elle a souligné : « Je connais tous les responsables de la sécurité par leur prénom. » Imaginez cela à grande échelle dans un endroit comme le Pentagone, où, franchement, il faut presque nécessairement entretenir ce genre de relations pour faire avancer les choses. Tant de DSI qui nous écoutent aujourd’hui comptent sur leurs RSSI et leur équipe de sécurité pour toutes ces choses dont personne ne se soucie tant qu’elles ne posent pas de problème.
Je pense que l’appel du Dr Plumb à mieux comprendre les flux de travail est essentiel. En l’absence de flux de travail, on se contente d’appliquer l’IA à n’importe quoi en espérant qu’il en résulte quelque chose d’extraordinaire, et comme nous le savons tous, les entreprises ne fonctionnent pas à l’espoir. Je pense donc que consacrer du temps à appliquer cette discipline, à documenter vos processus, à les comprendre afin de pouvoir, lors d’un audit, aligner ces processus sur la technologie, constitue une meilleure recette du succès.
C'est tout pour aujourd'hui. Merci beaucoup de nous avoir écoutés. N'hésitez pas à nous suivre pour ne manquer aucun épisode. Vous écoutiez « The Savvy CIO », une émission présentée par Park Place Technologies. Si vous souhaitez en savoir plus sur Park Place, rendez-vous sur www.parkplacetechnologies.com. Et maintenant, un dernier mot de notre invitée. Radha, puisque l’émission s’intitule « The Savvy CIO », quel est le choix le plus avisé que vous ayez fait dans votre carrière jusqu’à présent ?
Dr Radha Plumb : Je pense que c’est le fait d’avoir décidé de se consacrer entièrement à la compréhension de l’IA d’entreprise. Je pense que c’est dans ce domaine que les gens vont passer les cinq à dix prochaines années à transformer en profondeur tous les aspects de la société, et c’est vraiment passionnant de pouvoir prendre part à cette aventure.
Bradd Busick : J’adore ce point de vue et je suis tout à fait d’accord avec vous. Je suis votre animateur, Bradd Busick. Et comme toujours, l’informatique ne devrait pas se contenter d’être présente à la table. L’informatique, c’est la table. Prenez soin de vous.