Point de vue d’un directeur technique : discussion avec votre PDG à propos de l’IA agentique

Arvind Mathur :
Merci d’être avec nous pour cet épisode d’Executive Insights. Je m’appelle Arvind Mathur et je suis stratège d’entreprise chez AWS. Aujourd’hui, j’ai l’immense plaisir de m’entretenir avec mon collègue, Matthias Patzak. Matthias a récemment écrit un blog sur LinkedIn qui a suscité de nombreuses discussions. Aujourd’hui, nous aborderons le contenu de cet article et les raisons pour lesquelles il a suscité tant de débats. Matthias, bienvenue dans l’émission.  

Matthias Patzak :
Merci beaucoup. Oui, en fait, cela a suscité beaucoup de discussions. J’ai reçu de nombreux commentaires.

Arvind Mathur :
Et plus que toute autre chose, c’est la conversation déclenchée par ces éléments stimulants qui est si importante.

Je pense que c’est ce qui a créé beaucoup d’engagement. Effectivement, en tant que leaders technologiques, nous avons tous connu cette situation où nous savions que nous devions surveiller cette nouvelle tendance, mais où ne nous lui avons pas prêté assez d’attention. Et puis le PDG, ou un autre dirigeant, vient poser des questions… et là, on se retrouve toujours pris au dépourvu. Je pense que c’est ce qui a parlé à beaucoup de monde et qui a suscité autant d’engagement. 

Matthias Patzak :
Oui, c’est vrai. Et je suppose que c’est ce qui a suscité beaucoup d’impressions sur cet article sur LinkedIn, le PDG ayant dû demander au directeur technique : « Hé, c’est quoi cette histoire d’IA agentique ? » Et voici ce que je constate encore dans de nombreuses organisations : le directeur technique, le directeur informatique et les vice-présidents de l’ingénierie sont trop occupés par les activités quotidiennes, par le fonctionnement de l’entreprise et par la répartition de la capacité sur toutes les priorités actuelles. Et ils n’ont pas vraiment les capacités non seulement mentales, mais aussi physiques et le budget nécessaires pour vraiment profiter des nouvelles technologies. 

Arvind Mathur :
Tout à fait d’accord. Et je pense qu’aujourd’hui plus que jamais, il est important que les directeurs techniques et les leaders technologiques y consacrent plus de temps, car les choses évoluent si rapidement. Et surtout, bon nombre de ces fonctionnalités ont été tellement consumérisées et les chefs d’entreprise en sont tellement conscients qu’on ne peut pas se permettre d’être pris au dépourvu lorsque ces questions se posent. Vous devez consacrer des ressources à surveiller ces évolutions et même à initier vos chefs d’entreprise à ces sujets, comme vous l’avez très bien suggéré également, n’est-ce pas ?

Matthias Patzak :
Oui.

Arvind Mathur :
Passons à vos recommandations sur la manière d’aborder cette question. Je sais que cela a également suscité une certaine conversation. Les « je t’aime » ont été très provocateurs avec certaines de vos suggestions, et je pense qu’il serait bon d’aborder certaines de ces questions et de les examiner plus en détail.

Matthias Patzak :
La première étape que j’ai réellement recommandée a été d’en faire une conversation stratégique. Effectivement, la plupart du temps encore, les directeurs techniques et les DSI veulent simplement comprendre les nouvelles technologies. Ils veulent comprendre les barrières de protection, ils veulent comprendre les coûts, mais ils ne raisonnent pas vraiment, comme nous le dirions chez Amazon, en partant des clients à rebours. Ils ne sortent pas vraiment du bâtiment, ils n’observent pas vraiment leurs clients et leurs utilisateurs. Ils ne comprennent pas vraiment les besoins et les problèmes des clients et, en tant qu’experts informatiques, ils ne sont pas en mesure d’avoir une conversation stratégique avec leurs pairs du monde des affaires. Et c’est le premier point que j’ai soulevé dans cet article sur LinkedIn : transformer la discussion en une conversation stratégique.

Arvind Mathur :
Tout à fait d’accord. Je pense que cela doit être une conversation stratégique, car c’est l’occasion d’avoir un impact stratégique. Il ne s’agit pas simplement d’une amélioration de ce qui est dorsal. Je pense que la discussion suscitée par cet article portait sur cette idée de rechercher les idées à impact multiplié par 10, et pas seulement les améliorations de 10 %. Et je vous le dis, j’adore cette idée parce qu’elle est tellement provocatrice. Et surtout avec l’IA agentique, il est désormais possible de trouver davantage de ces opportunités à impact décuplé qu’avec de nombreuses autres technologies du passé. Mais la réalité est que dans notre vie, nous travaillons sur environ 90 idées d’amélioration de 10 %, puis sur 5 à 10 de ces idées à impact décuplé. Pourquoi mettez-vous l’accent sur les idées à impact décuplé ?

Matthias Patzak :
En général, je pense que ces améliorations itératives progressives de l’organisation sont ce qui fait vraiment le succès d’une organisation, car cela en fait une organisation apprenante. Si vous êtes conscient de votre activité et de vos technologies, et que vous vous améliorez semaine après semaine, jour après jour, de 1, 2, 3, peut-être 10 %. Mais ce que j’observe dans les discussions sur l’IA générative, sur l’IA en général et maintenant sur l’IA agentique, c’est que de nombreuses organisations pensent simplement à améliorer leur efficacité interne, sans vraiment réfléchir à la manière de faire évoluer leur modèle commercial. Et de mon point de vue, ce qui va se passer, c’est ce que nous avons vu il y a 10 ou 20 ans, lorsque des entreprises natives du numérique ont émergé, puis que nous avons eu des entreprises axées sur le mobile. Nous allons voir des entreprises natives d’IA générative et nous allons voir des organisations d’IA agentique émerger. Dans ce cas, si vous vous êtes contenté de travailler dans le cadre de votre modèle commercial actuel, vous risquez d’être perdu.

Arvind Mathur :
Oui, je suis d’accord. Plus tôt vous pouvez commencer à rechercher les opportunités à impact décuplé, mieux c’est. La seule mise en garde que je me permets dans des situations comme celle-ci, c’est que si vous n’êtes pas au fait des choses et qu’un chef d’entreprise vient vous voir, il arrive souvent qu’il ait déjà une idée en tête. D’après ce que j’ai observé, c’est que, dans cette dynamique, il faut savoir lire la situation. Parfois, il faut travailler rapidement et montrer des résultats sur l’idée que le PDG a pu vous proposer : « Bonjour, le problème de l’IA agentique m’a toujours inquiété. Pouvons-nous le résoudre par ce moyen ? » Il est généralement très utile de trouver rapidement un moyen d’y parvenir. Et puis en parallèle, une fois la confiance et la crédibilité établies, vous pouvez commencer à dire : « Ce n’est pas juste une opportunité d’amélioration mineure. Nous pouvons en réalité faire beaucoup plus avec ça. » Je sais qu’il y a eu une bonne discussion sur ce sujet lors de la discussion en ligne également, mais j’adore l’idée. Passons au deuxième point.

Matthias Patzak :
Le deuxième point est donc le conseil classique que je reformule ici comme suit : il faut former une équipe de transformation, et non une équipe technique. Mais en réalité, le message est qu’il ne faut pas se contenter de travailler dans les silos informatiques classiques. Bien sûr, il faut d’abord comprendre les concepts fondamentaux de la nouvelle technologie. Mais si vous voulez vraiment livrer des prototypes et si vous voulez vraiment en savoir plus sur les possibilités commerciales, vous devez également avoir votre responsable des ventes, le personnel des opérations, le personnel des finances et le personnel juridique dans la salle. Et pas seulement pour superviser, mais pour réellement discuter d’une transformation interfonctionnelle. Parce qu’il ne s’agit pas simplement d’un projet technologique, mais d’une réinvention de l’entreprise.

Arvind Mathur :
Et je pense qu’il y a eu un alignement et un accord complets à ce sujet au cours de la conversation. Je suis également convaincu de la même chose, surtout avec quelque chose comme l’IA agentique. Et si vous voulez vous concentrer sur les idées à impact décuplé, il ne s’agit pas d’idées d’amélioration technologique interne. Ce sont des occasions de réimaginer la façon dont nos clients font l’expérience de nos produits et services, ce dont nos produits et services sont capables, et bien plus encore. Cela nécessite donc une transformation en profondeur.

Matthias Patzak :
Comment percevez-vous et comment observez-vous cela dans vos conversations avec vos clients ? Voyez-vous vraiment des organisations fonctionner en équipes interfonctionnelles au sein de ces équipes de transformation, ou voyez-vous des silos informatiques ?

Arvind Mathur :
La situation est évidemment très variée. Certaines organisations sont plus matures, elles comprennent ce point et ont constaté que traiter cela uniquement en tant que projet technologique ne fonctionne pas. Mais il y a aussi un grand nombre d’organisations qui s’occupent encore de certains de ces projets comme si ce n’était que de la technologie. Et c’est le rôle que nous jouons lorsque nous discutons avec les directeurs techniques ou les dirigeants de l’entreprise : nous les aidons à comprendre, à considérer cela comme une opportunité transversale qui dépasse les silos fonctionnels. En outre, j’ai également beaucoup appris à ce sujet personnellement grâce à ma propre expérience. Lorsque je travaillais dans une compagnie d’assurance, nous essayions de transformer des processus tels que la souscription et les réclamations. Bien que ces processus relèvent de l’organisation des opérations, il ne s’agit pas seulement des opérations, mais aussi des ventes, des produits, des risques et de l’expérience client. Tous ces éléments doivent être impliqués si vous apportez des modifications. Dans notre cas, nous essayions de faire passer le délai de traitement des réclamations de trois à quatre semaines à moins d’une heure. Et il s’agit d’un changement radical, qui ne provient pas simplement de l’amélioration des processus opérationnels internes. Donc tout à fait d’accord.

Arvind Mathur :
Très bien, passons à la troisième étape.

Matthias Patzak :
Donc, troisième étape, ce que j’ai recommandé était de choisir deux à trois cas d’utilisation pertinents et d’agir rapidement. Et il s’agit vraiment d’évoluer rapidement, de faire fonctionner ces pilotes en parallèle et non de manière séquentielle, en alliant rapidité et barrières de protection. Et les barrières de protection sont importantes si vous menez de telles expériences, cela vaut mieux qu’une planification parfaite. Parce que ce que je vois, et c’est une citation que l’un des collègues de notre équipe, Jake Burns, avait l’habitude de faire, c’est : « Ne commencez pas quand vous êtes prêt, mais devenez prêt en commençant. » J’aime beaucoup cette idée, et je la recommande avec l’IA agentique en particulier. De plus, l’évolution rapide et l’exécution de projets pilotes en parallèle présentent un autre aspect, car il s’agit d’une nouvelle technologie et de nouveaux cas d’utilisation. Et comme il s’agit d’une expérimentation, il faut s’attendre à ce que 70 % des expériences échouent.

Ainsi, si vous exécutez vos projets pilotes de manière séquentielle, le premier, le deuxième et le troisième risquent d’échouer et seule la quatrième itération, la quatrième expérience, a vraiment des chances de réussir. C’est pourquoi je vous recommande, en tant que directeur technique, d’avoir des capacités, des capacités mentales, mais également des moyens budgétaires et humains, afin de pouvoir exécuter vos projets pilotes en parallèle. Et cela a fait l’objet de nombreuses discussions, car il semble que certaines organisations n’aient ni cet appétit, ni cette capacité.

Arvind Mathur :
Vous m’avez posé des questions tout à l’heure sur mes conversations avec les clients. C’est probablement le défi numéro un. En effet, la plupart des directeurs techniques, lorsqu’ils sont placés dans une telle position, n’ont pas la capacité, et donc pas la confiance qu’il faut pour gérer plusieurs grands projets en parallèle. Ils cherchent un certain réconfort, et moi-même, lorsque je manquais de confiance face à une nouveauté, j’étais plus à l’aise en expérimentant sur certains sujets, qui n’étaient souvent pas sous les feux de la rampe, pour apprendre et renforcer cette confiance avant de pouvoir aller plus vite.

Et voici le point à mon avis le plus important à souligner ici : j’espère que vous avez procédé ainsi avant d’avoir cette conversation avec le PDG. Effectivement, si vous avez fait des expériences plus petites, vous avez la confiance nécessaire pour trouver ces idées à impact décuplé et commencer à les réaliser en parallèle. Je pense que le point central de cet article, que j’ai beaucoup aimé, était que cette conversation ne devrait pas être initiée par le PDG. Vous devriez déjà avoir mené les expériences et l’aborder avec des idées, pour être prêt à faire avancer les choses en toute confiance.

Matthias Patzak :
Oui, cela doit réellement faire partie de votre modèle opérationnel et de votre culture.

Arvind Mathur :
L’une des questions qui ont été posées lors de la discussion était la suivante : il y a tellement de nouvelles choses qui émergent, il y a l’IA agentique, la robotique qui évolue dans une direction différente, l’IA de base, des données et de nouvelles façons de gérer les données et les capacités d’analyse, et bien plus encore. Comment garder un œil sur tout ce qui se passe, tout en expérimentant suffisamment pour pouvoir aller ensuite voir les chefs d’entreprise de manière proactive ? Quelles sont les meilleures pratiques que vous avez observées ?

Matthias Patzak :
En fait, vous ne pouvez pas jouer, expérimenter et acquérir des connaissances sur chaque tendance. C’est pourquoi il faut également disposer d’une capacité d’innovation ou de radar technologique au sein de l’organisation. Un leader d’opinion, Pascal Finette, a écrit un livre, intitulé Disrupt Disruption. Il explique comment repérer les signaux, la technologie, le marché et l’évolution des signaux des clients. Et puis la question est la suivante : à quelle fréquence rencontrez-vous des signaux ? Si certains signaux de certaines technologies apparaissent souvent, il faut sauter dessus et faire des expériences. C’est pourquoi il faut également avoir différentes méthodes de travail pour expérimenter.

Ainsi, selon certains signaux, il se peut qu’un développeur individuel, un designer ou un chef de produit expérimente un prototype avec de vrais clients un vendredi après-midi. Pour d’autres expériences, il faut une capacité libre pour une équipe pendant deux semaines avec une plage horaire. Les personnes concernées devront réaliser quelque chose au cours de ces deux semaines. Vous n’allez pas investir plus d’argent, ni plus de capacités, ni plus de temps. Mais il faut être capable de repérer les signaux et d’agir en conséquence. Et c’est peut-être l’aspect le plus important : dire non à certains signaux dans certains aspects. Il est essentiel de pouvoir donner la priorité à cela.

Arvind Mathur :
Oui, et je pense que ce que vous avez dit tout à l’heure est un autre aspect vraiment essentiel que j’ai personnellement pratiqué et conseillé aux gens : la culture de la curiosité et de l’expérimentation. Cela mène à l’innovation en fin de compte. Et ce que j’ai remarqué, dans mon expérience pratique personnelle également, c’est que si vous créez cette culture au sein de l’équipe, dans l’organisation, les membres de l’équipe feront des expériences et garderont un œil sur ce qui se passe, sur ce qui émerge du radar, même sans définir spécifiquement de stratégie ou de plan d’action à ce sujet. Mes situations les plus utiles ont été celles où une équipe est venue me voir et m’a dit : « Bonjour Arvind, nous avons exploré cette question et je pense qu’il y a du potentiel ici. » Cela me donne l’occasion de m’adresser à une équipe métier et de lui dire : « Bonjour, nous avons trouvé une solution. Y a-t-il un moyen d’agir concrètement dessus ? » Donc, si vous avez cette culture, c’est génial. Si ce n’est pas le cas, commencez à la créer dès aujourd’hui. Parce que dans le monde d’aujourd’hui, si l’équipe ne fait pas d’analyse et d’expériences de manière autonome, il est très difficile de le faire lorsque l’occasion se présente.

Matthias Patzak :
Oui, tout à fait d’accord. Pour ce faire, il est essentiel de pouvoir démontrer les succès et les échecs de vos expériences. Sinon, les chefs de produit ou les collègues de travail finiront par se plaindre, car une partie des capacités des équipes est occupée par les nouvelles technologies, au détriment de la livraison de valeur ou de nouvelles fonctionnalités. C’est pourquoi il faut vraiment célébrer le succès. Et l’échec d’une expérience est aussi une réussite en soi, mais il faut vraiment le valoriser au sein de l’organisation. Ensuite, vous créez cette culture où on peut supprimer des capacités et expérimenter de nouvelles technologies ou de nouvelles idées métier.

Arvind Mathur :
Formidable. Passons à la quatrième étape.

Matthias Patzak :
Oui, la quatrième étape. De mon point de vue, c’est là que j’ai trouvé les commentaires vraiment très intéressants. Le conseil est de financer la mise à l’échelle dès la phase pilote. Ne vous contentez donc pas de prototyper de jolies démonstrations, mais créez des solutions prêtes à la production et capables de gérer le volume de l’entreprise dès le premier jour. De mon point de vue, il existe différents types d’agents, notamment des agents conçus pour les travailleurs du savoir. Par exemple, si un agent du service client utilise un agent sur son poste de travail pour automatiser l’un de ses processus. Mais en tant qu’ancien directeur technique, je trouve les agents qui sont des microservices dotés d’une intelligence artificielle bien plus intéressants. Il est cependant difficile d’introduire ces agents au sein des architectures dans les applications.

Il faut disposer d’une architecture pilotée par les événements. Il faut être en mesure de mettre en place une observabilité adéquate et, au moins au début d’un prototype, il faut être en mesure d’avoir des humains dans la boucle, dans les boucles, parfois en dehors des boucles. Vous pouvez vraiment comprendre les capacités des agents s’ils sont en production, peut-être pas avec 100 % de votre trafic, mais avec 1 % de vos utilisateurs, 1 % de votre trafic, afin de limiter le rayon d’impact tout en essayant des idées à impact décuplé. Mais cela a été très difficile à comprendre et à adopter pour beaucoup, car la culture de l’échec leur fait probablement défaut.

Arvind Mathur :
Et je pense que ce que vous voyez ici est également bien lié au point précédent, à savoir qu’en fait, même dans le cadre d’une expérimentation, il y a des étapes. Il se peut que vous meniez des expériences complètement déconnectées de votre entreprise. Et si certaines d’entre elles deviennent prometteuses, vous pouvez alors lancer des expériences en interne, d’abord dans le domaine informatique. Comme vous venez de le décrire, j’aime vraiment beaucoup ce point. Vous avez déjà des processus métier gérés par des services et des API, puis une intelligence artificielle est introduite dans ces éléments. Cela donne l’expérience et le confort dans le développement de capacités d’IA agentique de niveau production. Lorsque vous aurez cette conversation sur les opportunités d’impact décuplé en interfonctionnel, vous aurez la confiance nécessaire pour aller de l’avant et commencer à travailler en production en parallèle, sur plusieurs idées. Très bon point. C’est une étape de ce parcours d’expérimentation vers l’innovation que de commencer par travailler en interne, dans le domaine de la technologie.

Maintenant, je comprends les commentaires qui ont été faits à ce sujet selon lesquels, encore une fois, beaucoup de gens ne sont pas à l’aise avec cela. Ils pensent qu’il est important de faire certaines expériences dès le début, comme vous l’avez dit, pour réduire le rayon d’impact. Et ce que nous voulons vraiment dire ici, c’est qu’il faut le faire avant d’avoir une conversation stratégique. Tous ces petits pilotes, projets et expériences à faible impact, si vous les avez déjà fait, vous permettent d’agir rapidement lorsque l’opportunité commerciale se présente. À ce stade, vous ne serez plus en phase d’expérimentation, et idéalement, vous aurez dépassé la phase des 70 % d’échecs et pourrez fournir des capacités plus cohérentes.

Matthias Patzak :
Oui, je suis tout à fait d’accord. C’est pourquoi les utilisateurs doivent se familiariser très tôt avec les nouvelles technologies. Je recommande d’inclure des partenaires, d’inclure les équipes AWS chargées des comptes et de les laisser vous montrer comment vous familiariser avec les nouvelles technologies.

Arvind Mathur :
Très bien, passons à la cinquième étape.

Matthias Patzak :
Oui, cinquième étape. Je dirais que c’est une évidence, mais on peut toujours en débattre. La cinquième étape consiste donc à mesurer l’impact commercial, et non les indicateurs techniques. Suivez donc l’augmentation des revenus, la réduction des coûts, l’amélioration de la durée du cycle, l’évolution du taux de conversion, et non la précision des modèles ou les taux d’adoption des utilisateurs. Bien sûr, ces indicateurs avancés sont nécessaires pour adapter les taux. Il faut connaître certains indicateurs de qualité, mais il faut introduire de nouvelles technologies non pas pour les nouvelles technologies, mais pour améliorer de 10 % les processus métier ou pour être en mesure de proposer un cas d’utilisation à impact décuplé. C’est pourquoi il faut vraiment évaluer chaque solution en production auprès de vrais utilisateurs et mesurer l’impact réel sur l’entreprise. Le but n’est pas de cocher une case dans une liste de fonctionnalités, mais bien de pouvoir dire : « Grâce à cette nouvelle IA agentique, nous avons pu réduire les taux de sortie sur le site Web de tel ou tel pourcentage. »

Arvind Mathur :
Et je pense qu’il y avait un accord universel sur ce point. Je voulais seulement partager rapidement mon expérience personnelle à ce sujet également dans le cadre de cette même procédure d’accélération du processus de réclamation. Au départ, lors de ce projet, nous faisions l’erreur d’évaluer plusieurs personnes au sein de l’équipe. Notre équipe des opérations n’a donc eu qu’une seule mesure opérationnelle. Notre équipe technique avait une autre mesure opérationnelle pour fournir des fonctionnalités, et notre équipe commerciale avait d’autres mesures. L’impact décuplé n’était pas atteint à cause de cela. Ce n’est que lorsque tout le monde s’est fixé sur le même objectif, à savoir passer de trois semaines à cinq minutes, que l’alignement s’est fait et que la créativité a été stimulée. Les obstacles au passage à des solutions à impact décuplé ont été surmontés, et des solutions vraiment créatives ont été proposées de manière transversale. Ce n’est donc pas qu’une question de mesure. C’est un excellent moyen d’aligner les équipes et de les amener à se concentrer sur les véritables obstacles qui nous empêchent de livrer des solutions à impact décuplé.

Matthias Patzak :
Oui, vous avez raison. La partie alignement est vraiment importante.

Arvind Mathur :
Conversation très intéressante à ce sujet. J’espère que nous pourrons continuer à dialoguer avec des gens et à obtenir plus de commentaires à ce sujet. Mais la première chose que je retiens de cette conversation, de mon apprentissage personnel et je vais le recommander à tout le monde, c’est de commencer à surveiller activement. De nombreux changements sont en cours, et il faut avoir une longueur d’avance pour comprendre ce qui est possible et présenter ces idées aux chefs d’entreprise. Sur cette base, je vous suggère d’accéder à votre compte AWS dès aujourd’hui, de parler aux équipes chargées de votre compte et de déterminer comment commencer à utiliser ces outils et à créer dès maintenant.

Matthias Patzak :
Oui, tout à fait d’accord. Et l’outil ou le service Amazon à utiliser est Amazon Bedrock AgentCore. Nous proposons donc différents services liés aux agents, mais la base pour intégrer des agents dans votre architecture est Amazon Bedrock AgentCore. C’est vraiment le service que je recommande aux organisations d’adopter le plus rapidement possible.

Arvind Mathur :
Génial. Commençons à créer.

Matthias Patzak :
Commençons à créer.

Écouter maintenant

Écouter maintenant

Écouter maintenant