Webinaire – Data, Explored #6 – Le maillage agentique : repenser l'architecture de l'IA pour l'autonomie et l'alignement

Bon, allons-y. Le sujet d'aujourd'hui est l'avenir de l'entreprise, d'après votre livre, Eric et Davis, intitulé Agen Mesh. J'ai une longue liste de questions à vous poser.

Tout d'abord, bienvenue. C'est un plaisir de vous accueillir, vous et Davis. Je pense que la première question que j'aimerais poser, euh, à vous et à Eric, vous pouvez bien sûr intervenir si vous le souhaitez, mais nous discutons de l'avenir de l'entreprise.

Alors pourquoi ne pas commencer par une brève définition de ce qu'est un agent. Comment cela fonctionne-t-il ? Qu'est-ce que c'est, selon vous, Davis ?

Très bien. Un agent est un acteur logiciel capable d'interpréter le contexte, de poursuivre un objectif, de choisir des actions, d'exécuter des tâches à l'aide d'outils et d'API, d'interagir avec des données, ainsi qu'avec des personnes et d'autres agents. La fonctionnalité principale ici est l'action.

Il ne se contente pas de générer une réponse, mais décide également de la marche à suivre. Il conserve l'état à travers les différentes étapes et s'ajuste en fonction des résultats des étapes précédentes et de l'utilisation de l'entreprise. L'agent doit être traité comme une entité opérationnelle dotée d'autorisations d'identité, de politiques et d'un comportement observable.

Cela le rapproche davantage d'un modèle d'appel, euh, ou d'un chatbot. Et il devient un participant logiciel contrôlé capable d'effectuer un travail limité dans un environnement professionnel. Oh, cool.

Oui. Euh, permettez-moi d'ajouter quelque chose. Euh, excellente réponse, Davis.

Hum, il y a, il y a deux, je, il y a deux types d'agents que, euh, j'aimerais aborder, euh, dans cette discussion. Le premier est celui des agents de codage. Je suis sûr que si vous utilisez Claude Code ou Codex, vous reconnaissez probablement qu'ils ont révolutionné l'ingénierie logicielle et qu'ils s'étendent désormais au domaine de l'ingénierie des données ainsi qu'à celui des affaires. Nous voyons apparaître des innovations extraordinaires telles que Open Claw.

Mais voici la différence, et c'est là que nous entrons dans notre discussion sur l'entreprise : il s'agit d'agents personnels. Ce sont ceux qui fonctionnent sous votre identité, votre rôle, vos autorisations. Vous leur donnez accès à votre environnement.

Vous leur donnez accès à vos ressources. Les agents d'entreprise dont nous allons parler un peu plus sont différents. Ce sont des entités opérationnelles.

Comme Davis l'a en quelque sorte souligné, euh, ils ont des autorisations d'identité, des politiques et un comportement observable, euh, observable. Maintenant, le fait est que ces agents sont désormais des participants logiciels régis au sein de l'entreprise, tout comme n'importe quelle autre application d'entreprise. Et c'est là la différence essentielle, je pense, pour simplement jeter les bases de ce que les gens ont peut-être entendu dire au sujet du code cloud, des agents et autres, et où nous voulons aller, où nous voyons l'environnement évoluer réellement.

Oui. Merci, Eric. Merci d'avoir précisé cela.

Et je suppose, évidemment, que les participants ici présents ont déjà quelques connaissances sur le sujet, ou du moins s'y intéressent, n'est-ce pas ? Nous pouvons donc aborder des aspects légèrement techniques, bien sûr, mais certaines des questions que j'ai préparées sont également de nature plus générale, afin que nous puissions acquérir une compréhension approfondie du sujet dans son ensemble. Et je voudrais commencer par le postulat de votre livre, en fait.

Hum, euh, maintenant que nous sommes dans les détails, comme vous l'avez écrit, vous avez écrit un livre, et évidemment, la question s'adresse à vous deux. N'hésitez donc pas à intervenir tous les deux comme vous le souhaitez. Mais je voudrais commencer par un petit défi, et je pense que c'est peut-être un défi facile.

Vous avez choisi d'écrire un livre sur ce que vous appelez les « Ag mes ». Pourquoi n'avez-vous pas choisi d'écrire un livre sur ce que vous pourriez appeler de manière provocante le « monolithe » ? Pourquoi s'agit-il d'un maillage ?

Pourquoi est-ce un monolithe ? Bien sûr. C'est une excellente question.

Hum, je vais, je vais, euh, citer quelques phrases prononcées par des leaders du secteur. Euh, Andy Jassy, PDG d'Amazon, a déclaré qu'il y aurait un million d'agents dans chaque entreprise. Satya Nadella, de Microsoft, a déclaré que les agents remplaceraient les logiciels en tant que service.

Euh, Jensen Wong, PDG de Nvidia, a déclaré qu'il y aurait des milliers, voire des dizaines ou des centaines de milliers d'agents dans chaque entreprise. Donc, ce que nous savons, c'est que même s'ils se trompent lourdement et qu'il n'y a que mille ou peut-être 10 000 agents dans une entreprise, très peu d'entités logicielles dans une entreprise ont 10 000 de quoi que ce soit. Nous avons donc peut-être vu quelque chose de similaire dans la gestion des microservices.

Et la raison pour laquelle, euh, un maillage entre en jeu, c'est que si vous devez gérer une centaine, un millier, 10 000 ou peut-être un million de quoi que ce soit, vous devez réfléchir à une architecture différente. Un monolithe, euh, ne serait tout simplement pas pratique. Euh, ou gérer un million d'agents dans un monolithe.

Il ne serait probablement pas, euh, déployable dans une architecture moderne significative aujourd'hui. Mais si je les distribue, euh, j'ai une chance. Et, très honnêtement, l'architecture distribuée est ce que nous voyons tous les jours, que vous utilisiez le cloud ou même dans les centres de données, vous voyez des milliers de nœuds.

Nous pensons donc que l'architecture la plus logique pour les agents est, euh, un modèle fédéré et le maillage, euh, celui où, par définition, tout agent peut collaborer avec n'importe quel autre agent, ce qui conduit à une architecture basée sur le maillage. Juste par nécessité pratique, euh, oui, non, très juste. Hum, je pense, euh, c'est juste une observation personnelle, mais au tout début de, euh, jet GPT-3 0.5, je pense qu'il y avait cette idée que, que, que l'avenir de l'IA serait, certains le pensaient, et, et, et cela va sembler terriblement peu technique, mais, mais que l'avenir de l'IA serait en quelque sorte constitué de très gros morceaux de logiciels effectuant quelque chose simplement à cause du terme « grand modèle linguistique », et l'idée que cela se traduirait en quelque sorte par, euh, une sorte d'architecture monolithique.

Mais je suis d'accord pour dire que ce que nous constatons, c'est une compréhension très répandue selon laquelle les architectures génériques doivent exister dans ce que l'on pourrait appeler un maillage, dans le sens où vous aurez un très grand nombre d'agents qui travaillent ensemble dans un maillage. Euh, dans votre livre, Ingen mesh, vous faites la distinction entre, euh, les agents de type libre, si vous voulez, euh, les façons libres de travailler avec l'IA dans l'entreprise. Euh, c'est ce que vous appelez les flux de travail IA, les agents autonomes et les agents de niveau entreprise.

En fait, dans votre définition, Davis, euh, au début de la conversation, euh, euh, vous, vous avez déjà fait allusion à cela, euh, si, si vous le souhaitez, j'aimerais, j'aimerais, j'aimerais développer un peu votre définition et vous demander, d'accord, quelle est la différence entre les flux de travail de l'IA, les agents autonomes et les agents de niveau entreprise ? Très bien. C'est une excellente question, qui touche à certaines des différences que l'IA a connues ces dernières années.

Donc, un workflow IA workflow un système où le modèle linguistique et ses outils suivent un chemin de code prédéfini. Euh, cela signifie que workflow IA workflow avoir toutes les étapes. Il pourrait prendre chaque décision établie à l'avance par celui qui le crée.

Comme quelqu'un l'a dit, vous pouvez utiliser un LM à l'étape quatre ou à l'étape trois pour résumer quelque chose, extraire une information ou classer quelque chose. Mais fondamentalement, chaque étape de ce processus a été définie à l'avance. L'IA ne peut que résumer, elle ne peut extraire que si vous avez déjà atteint cette étape, elle ne peut pas influencer beaucoup les étapes suivantes.

En gros, tout est figé et si quelque chose d'inattendu survient que le concepteur du workflow prévu, vous obtiendrez simplement une erreur. Même dans les cas où le chemin correct peut sembler évident pour un humain, comparez cela à un agent autonome, qui peut déterminer de manière dynamique son propre chemin d'exécution. S'il dispose des outils nécessaires, même dans une situation imprévue, il peut les appliquer et surmonter l'imprévu pour trouver une nouvelle façon de continuer à avancer.

Il peut reconnaître et mettre en œuvre de nouvelles solutions à la demande faire face à des conditions changeantes. Son adaptabilité et sa planification dynamique sont vraiment ce qui le distingue. Et au-delà des agents de niveau entreprise, c'est la façon dont vous intégrez un agent autonome dans l'entreprise pour vous assurer qu'il est détectable, sécurisé, fiable, et toutes les autres choses qui seront nécessaires pour que l'entreprise accepte véritablement les agents.

Oh, oui. D'accord. Donc je, je, je vois la différence, euh, plus clairement, évidemment.

J'ai lu le livre à l'avance pour préparer ce webinaire. J'ai également participé à la révision technique. Je ne l'ai pas précisé au début.

Je ne pense pas avoir dit cela au début. Mais ce dont je suis convaincu, c'est que ce type de réflexion et la façon dont vous le décrivez deviendront, euh, comme, euh, votre livre deviendra une référence pour comprendre les architectures génétiques qu'il est possible de créer dans l'entreprise. Exactement. En raison de ce type de distinctions.

Et peut-être comme tourner un peu le micro vers vous, Eric, euh, en termes de, euh, en termes de, euh, en termes de réalité organisationnelle et d'entreprise, euh, nous avons tendance à penser, nous avons tendance à considérer les agents comme quelque chose où un être humain représente un agent. Or, vous montrez très clairement que dans un contexte organisationnel et, euh, vous ne pouvez pas vraiment penser ainsi. La distinction est que la comparaison doit être un peu différente.

Et donc, nous avons quelques métaphores que vous utilisez pour traduire la réalité de l'entreprise. Donc, vous traduisez... Laissez-moi simplement lire la question pour ne pas compliquer les choses pour les auditeurs ici présents. Comment traduisez-vous une équipe et une organisation en groupes d'agents ?

Que signifie la métaphore de la flotte, et que signifie celle de l'écosystème ? Pouvez-vous nous en dire un peu plus à ce sujet, Eric ? Oui, bien sûr.

Donc, euh, nous utilisons cette analogie dans le livre où nous commençons par une personne qui est comme un agent. Et comme Davis l'a mentionné, euh, un agent, euh, peut élaborer un tâche , peut prendre des décisions tout comme une personne. Nous étendons cette analogie aux équipes.

Tout comme les gens travaillent en équipe et collaborent entre eux, et utilisent des outils que nous appelons des équipes d'agents, nous les appelons des flottes. Maintenant, comme les gens, et comme toute organisation, euh, toute organisation de taille modeste ou même grande, vous avez de nombreuses équipes et de nombreux niveaux d'organisation, et ils peuvent être organisés de différentes manières. En gros, nous appelons cela, euh, une entreprise, une société, si vous voulez.

Hum, dans notre jargon d'agent, nous appelons cela un écosystème, ou un réseau eugen. Ce qui est intéressant, c'est que nous étendons cette analogie aux chaînes d'approvisionnement, par exemple, où plusieurs organisations ont des contrats spécifiques qui définissent comment elles interagissent, avec qui elles peuvent collaborer, quelles sont les attentes en matière de niveau de service ou même de qualité. L'analogie s'étend donc à toutes les chaînes d'approvisionnement manufacturières modernes, par exemple, qui présentent toutes les caractéristiques que j'ai mentionnées.

Mais ce sont exactement les mêmes choses que nous pourrions appliquer aux agents, et nous pensons en fait qu'elles pourraient être appliquées à, euh, ce qui pourrait être un nouveau terme, l'automatisation des processus agentifs pour la distinguer de l'automatisation des processus métier classiques ou de l'automatisation robotique des processus. Euh, nous pensons que l'analogie entre la personne et l'agent, l'équipe et l'organisation de la flotte, l'écosystème, et ensuite l'automatisation des processus est, en fait, la bonne analogie. Hum, et probablement la plus intuitive car, comme vous, comme nous tous, nous interagissons tous avec d'autres personnes, d'autres, nous travaillons en équipe.

En général, nous travaillons au sein d'une organisation, euh, d'une entreprise. Euh, et parfois, nous interagissons même avec plusieurs, euh, entreprises. L'analogie est très pertinente, et c'est pourquoi nous l'avons largement utilisée dans le livre.

Oui, non, je suis d'accord. Je pense aussi que, euh, euh, le niveau de coordination augmente évidemment, euh, plus vous avez d'agents, n'est-ce pas ? Une flotte est quelque chose à laquelle vous pouvez donner une direction relativement facilement et dire, vous irez dans cette direction dans ces conditions, n'est-ce pas ?

Alors qu'un écosystème devient manifestement de plus en plus difficile à coordonner et à diriger à mesure qu'il prend de l'ampleur, et il ne devrait pas aller dans la même direction, n'est-ce pas ? Si vous avez un écosystème d'agents, ce que vous visez, c'est évidemment une multitude de processus différents qui ne sont pas connectés ou qui ne le sont que très vaguement, n'est-ce pas ? Cela vous donne donc un niveau de complexité complètement différent à gérer.

Et je pense que ce qui est vraiment nécessaire dans la conversation autour des agents, c'est qu'elle a tendance à s'arrêter généralement à la comparaison entre les agents humains, alors qu'il faut vraiment autre chose qu'un humain pour comparer, euh, un ensemble d'agents, n'est-ce pas ? Euh, mm-hmm. Donc, j'aime cette question, j'aime beaucoup cette distinction que vous faites dans le livre.

D'accord. Je suis également prêt, c'est une question importante, qui comporte de nombreux aspects différents, et je pense que vous pouvez tous les deux y répondre. Vous avez tous les deux révélé une partie de la réponse, mais j'espère que nous pourrons approfondir le sujet.

Mais c'est une question importante, je vais donc la lire à haute voix et ensuite nous la décomposerons car personne ne sera capable de s'en souvenir de toute façon. Euh, oui. Donc, euh, les agents de niveau entreprise ont sept caractéristiques.

Il s'agit donc ici d'agents de niveau entreprise. Nous allons donc au-delà des agents autonomes. Nous entrons dans le domaine des agents de niveau entreprise, n'est-ce pas ?

Les agents de niveau entreprise les plus perfectionnés présentent sept caractéristiques : sécurité, fiabilité, explicabilité, évolutivité, découvrabilité, observabilité et opérabilité. Personne ne peut se souvenir de cette longue liste. Mais pouvez-vous décrire ce que ces sept caractéristiques combinées représentent pour un agent de niveau entreprise, Blac ? Je pense que nous devrions les passer en revue une par une.

Quel est donc l'aspect sécurité d'un agent de niveau entreprise ? Oui, Davis, je sais que vous avez rédigé le chapitre sur la sécurité dans le livre. Pourquoi ne pas commencer par nous donner votre point de vue sur la sécurité ?

D'accord, donc pour qu'une entreprise accepte un agent dans ses opérations, elle doit savoir que cet agent est sûr. Peu importe la qualité du travail effectué par l'agent, si n'importe qui sur Internet peut accéder à votre base de données et la supprimer. Il doit donc disposer, en gros, d'autorisations, d'une identité, et être intégré à votre système OAuth, afin que vous puissiez définir ce à quoi il a accès et ce à quoi il n'a pas accès.

Elle doit communiquer via des protocoles sécurisés. Vous devez vous assurer que toutes vos communications sont cryptées. Vous devez vous assurer que personne ne peut voir ce que fait l'agent, que personne ne peut dire à l'agent ce qu'il doit faire, et que l'agent ne regarde ni n'accède à des informations.

Cela ne devrait pas être possible pour qu'il puisse faire son travail, si vous pouviez faire tout cela. Eh bien, c'est... Oui, c'est assez intéressant. Davis, il me semble, et c'est quelque chose sur lequel nous reviendrons probablement, que... euh, et c'est quelque chose que nous avons dit dans le livre ou dans d'autres occasions, c'est aussi un agent d'entreprise, euh, tout comme n'importe quelle autre application d'entreprise qui a une identité, des rôles, des autorisations, et dont la communication est sécurisée.

Donc, c'est l'autre chose dont j'ai parlé. Nous parlons de quelque chose qui semble très nouveau à certains égards, mais qui ne l'est pas en réalité. En fait, le modèle que nous avons utilisé dans le livre est que la sécurité pour un agent doit refléter le même niveau de sécurité.

Bien qu'il y ait évidemment quelques différences, cela devrait refléter les mêmes principes et les mêmes idées que n'importe quelle autre application d'entreprise importante. D'accord. Oui, non, c'est tout à fait logique.

Euh, et évidemment, cela complique aussi beaucoup les choses. Euh, d'accord. Mais, euh, mais oui, évidemment, vous en avez besoin, mais vous auriez aussi besoin, je suppose, de toute façon, revenons-y peut-être, car vous auriez aussi besoin d'une sorte d'architecture automatique créée autour de cette sécurité, n'est-ce pas ?

Parce que gérer la sécurité à une telle échelle sera extrêmement compliqué. Euh, Oui, tout à fait. Quand on y pense, prenons l'exemple d'une entreprise que je connais bien, et que la plupart des gens connaissent probablement aussi, si on prolonge l'analogie d'un agent comme une personne, euh, et on pense que c'est tout à fait approprié, un agent doit être intégré comme une personne.

Et une fois que vous êtes intégré, vous êtes évalué : êtes-vous capable de faire le travail ? Avez-vous les compétences et les capacités nécessaires pour le faire ? Euh, une fois que vous êtes intégré, vous avez une identité.

Et une fois que vous avez une identité en tant qu'employé, vous disposez d'un identifiant d'employé. En fonction de votre poste, vous recevez des autorisations pour effectuer votre travail. Hum, donc, l'analogie que nous aimons utiliser à ce sujet est la suivante : tout comme vous avez entendu parler des termes RH ou gestion des ressources humaines, nous pensons que les mêmes disciplines, les mêmes pratiques, dans la mesure du raisonnable, peuvent s'appliquer aux agents.

Les agents peuvent être intégrés. Comme Davis l'a mentionné, les agents ont une identité, les agents ont un rôle, nous pensons, euh, pour inventer une autre expression ici, euh, et je ne sais pas si cela va trop loin, mais tout comme nous avons des pratiques RH ou de ressources humaines, nous devrions probablement réfléchir au minimum à des pratiques AR ou de ressources agents. C'est une bonne analogie, mais nous pensons qu'elle va en fait assez loin en termes de réflexion sur la manière de protéger et de gérer la sécurité autour des agents.

Oui. Euh, non, mais ça rend, euh, oui, encore une fois, c'est, c'est, c'est assez, euh, c'est, c'est, c'est beaucoup de nouveautés, n'est-ce pas ? Mais ça, ça a du sens.

Hum, alors encore une fois, euh, examinons le prochain aspect ici. Hum, la fiabilité. Est-ce que nous pouvons, hum, cela est évidemment lié à la sécurité, mais quel est l'aspect fiabilité d'un agent de niveau entreprise ?

Oui, bien sûr. Je vais prendre celui-ci, euh, sur la fiabilité. Il y a plusieurs définitions différentes.

Hum, et je vais mettre de côté pour l'instant des notions telles que la confiance, car nous en parlerons probablement plus tard. Alors, parlons de la fiabilité dans un contexte très spécifique.

Quand on dit que quelque chose est fiable, on sait ce que ça fait, ce qu'il est censé faire, euh, on peut voir si ça a bien marché et si ça n'a pas marché, on peut le réparer. Hum, c'est donc un aspect de la question, et nous pensons que c'est particulièrement important pour les agents. Ainsi, non seulement ils sont détectables et nous pouvons comprendre leur objectif, euh, et ils peuvent élaborer tâche , mais nous pouvons également voir ce qu'ils ont fait.

Et s'ils n'ont rien fait, nous pouvons nous charger de régler le problème. L'autre aspect de la fiabilité est le suivant : le produit est-il disponible quand je m'attends à ce qu'il le soit ? Dans ce contexte, cela revient au même, aux mêmes principes que nous appliquons à certaines de nos applications qui peuvent être sur le cloud ou à certaines applications SaaS que nous pouvons utiliser dans notre organisation.

Euh, il y aura des attentes en matière de niveau de service concernant leur disponibilité, leur temps de réponse ou leur latence. Euh, toutes ces choses sont, selon nous, celles qui devraient s'appliquer aux agents. Maintenant, ce qui est intéressant à ce sujet, c'est que vous voyez que nous essayons de faire autant que possible des analogies avec des choses que les gens comprennent réellement.

La raison pour laquelle nous faisons cela, tout d'abord, c'est parce qu'ils sont tout à fait appropriés, mais cela démystifie toute l'idée autour des agents. Et ce que nous constatons, c'est que lorsque vous prenez, que vous mettez votre casquette d'architecte pour dire que, euh, les concepts existent depuis longtemps. Par exemple, les défis liés à l'informatique distribuée, c'est-à-dire lorsque vous avez beaucoup d'agents qui fonctionnent sur le cloud ou ailleurs, les problèmes liés à la distribution, les défis liés à l'informatique distribuée, ne sont pas faciles à résoudre, mais ils sont résolubles.

C'est une pratique courante. Cela ne veut pas dire que c'est facile, mais c'est une pratique courante. Donc, en matière de fiabilité, ce sont des pratiques courantes, et nous sommes convaincus que vous devriez les appliquer directement aux agents.

Encore une fois, ce n'est pas différent des autres applications d'entreprise. Oui, non, c'est tout à fait logique. Mais c'est juste que cette transition est difficile, n'est-ce pas ?

Parce qu'il a été conservé par quelques employés triés sur le volet. Et maintenant, lorsque vous développez quelque chose, en tant qu'agence, euh, vous devez, vous devez multiplier cela et diffuser ces connaissances, euh, mm-hmm. Des mesures pour, pour plus d'employés ou au moins, oui, construire, construire l'architecture de manière à ce qu'évolutif

C'est, euh, super, super difficile. Euh, mais on n'en est même pas à la moitié. Mais, euh, peut-être qu'on ne les prendra pas tous.

Euh, je voudrais aussi laisser du temps pour les questions, s'il y en a, de la part des participants qui ont, euh, des questions. Mais passons à la suivante, parce qu'elle est évidente, n'est-ce pas ? L'explicabilité, qu'est-ce que c'est, comment créons-nous des agents, euh, comment les expliquons-nous, en gros ?

Oui, je peux commencer. Et puis Davis, je sais que tu as des opinions assez tranchées sur le sujet. Euh, aujourd'hui, quand on regarde, je vais faire la comparaison avec ce que les gens utilisent aujourd'hui, Claude code, par exemple, ou Codex, ou même chat, GPT, on voit qu'il est question de réflexion.

Et ce que c'est vraiment, c'est que, même si ce n'est pas tout à fait un tâche , c'est un peu une boucle. Euh, mais cela explique ce qu'il fait. Donc, vous pouvez réellement voir cela si vous utilisez l'un des outils de codage modernes ou agents de codage disponibles aujourd'hui. Nous pensons que si vous passez au domaine de l'entreprise où les agents participent pleinement aux processus métier, vous devez non seulement observabilité ils ont fait après coup, mais aussi vérifier s'ils ont fait ce qu'il fallait.

Ainsi, lorsqu'un agent propose un tâche dans notre livre, nous recommandons en fait que ce tâche soit considéré comme un élément essentiel dans le domaine observabilité. Mm-hmm. C'est un élément essentiel dans la mesure où il doit être consigné.

Et une fois tâche l'agent a terminé sa tâche les résultats de celle-ci devraient être joints d'une manière ou d'une autre ou liés à ce tâche . Ensuite, lorsque nous examinons les observabilité , la latence ou la manière dont, vous savez, la tâche a été menée à bien ou non, là encore, elles sont rattachées à ce tâche . Au final, lorsqu'un agent effectue son travail, nous pouvons voir le tâche , ce qu'il pensait devoir faire, nous pouvons examiner les résultats pour voir s'il a bien travaillé, et nous pouvons utiliser les observabilité pour voir à qui il s'est adressé pour accomplir cette tâche.

Ce niveau d'explicabilité n'est pas disponible aujourd'hui. Nous en avons certains, nous travaillons avec certains clients avec lesquels nous commençons à nous engager dans cette voie. Mais les agents de codage que vous voyez aujourd'hui n'ont pas cette capacité.

frameworks d'agents frameworks cette capacité aujourd'hui. Ils peuvent en exercer certaines parties, mais l'explicabilité est la compréhension de bout en bout, ce qu'il pensait, le tâche , comment il a obtenu les résultats liés au tâche et observabilité? À qui a-t-il parlé, s'agissait-il d'outils ou d'autres agents pour mener à bien ce tâche ?

C'est ce que signifie être de première classe, un citoyen de première classe qui est enregistré. Ainsi, toute personne chargée de l'opérabilité qui constate un problème à diagnostiquer peut utiliser ce tâche , les résultats et la liste des collaborateurs pour diagnostiquer le problème. Lorsque vous êtes développeur, cela vous donne les informations nécessaires pour vous assurer que votre agent est réellement testé et débogué.

Cette explicabilité a donc de nombreuses applications, c'est pourquoi nous pensons qu'il s'agit en réalité d'un des éléments qui, bien qu'il ne soit pas facilement accessible aujourd'hui, est probablement l'une des exigences les plus importantes pour les entreprises actuelles. Et cela occupe une place prépondérante dans notre livre. Oui, tout à fait.

Davis, tu veux ajouter quelque chose à ce sujet, ou on passe à autre chose ? Euh, je trouve que la réponse d'Eric était très bonne. Elle couvre bien le sujet.

Euh, une chose que je voudrais ajouter, c'est que vous ne devez pas seulement suivre le plan lui-même. Ce que vous voulez, c'est que l'agent inclue des explications sur les raisons pour lesquelles vous voulez, vous voulez être en mesure de voir pourquoi l'agent fait ce qu'il fait, et inclure cela avec tâche réels en cours d'exécution. Ainsi, vous ne voyez pas seulement que je planifie les étapes 1, 2, 3, vous voulez voir que je fais les étapes 1, 2, 3 pour les raisons X, Y, Z.

Tout à fait. Très bonne remarque, Davis. Tout à fait.

Très bonne remarque.

Hum, et je suis très reconnaissant envers les participants qui ont posté des questions, euh, dans la section questions-réponses. Euh, je pense que nous devrions passer à celles-ci dans un instant. Hum, je voulais juste, pour résumer, nous avons discuté de la sécurité, de la fiabilité et de l'explicabilité.

Hum, pour les agents de niveau entreprise. Nous avons toujours évolutivité, la découvrabilité, observabilité et d'autres capacités à découvrir. Mais je pense que nous devrions passer aux questions qui ont été posées dans le chat.

Hum, je pense que les participants sont là pour obtenir des réponses à leurs questions. Ensuite, hum, nous pourrions faire un ou deux articles de blog sur notre plateforme de données et d'informations Substack, ou même sur notre site web si vous le souhaitez. Mais, euh, passons sans plus attendre aux questions posées dans le chat, euh, ou dans la section questions-réponses, je suis désolé.

Euh, je vois les deux questions dans, euh, dans, dans les questions-réponses et dans, euh, d'accord, je les ai ici. Euh, juste une seconde. Donc, euh, Ronald, Ronald de, euh, Ronald Ban, je crois qu'il vient des Pays-Bas.

C'est formidable de vous avoir parmi nous pour ce webinaire, ce webinaire, ce webinaire. Et il demande : « Je m'intéresse à la manière de tester les agents et de entraîner former ou entraîner afin qu'ils soient à la hauteur de leur travail. Qui devrait s'en charger et comment procéder afin d'avoir des agents certifiés pour certaines tâches ? Je pense que c'est une question plus générale qui aborde certains des points dont nous avons discuté, ou dont nous avons déjà discuté en détail dans les questions précédentes.

Mais, mais peut-être que c'est bien de prendre un peu de recul et, est-ce que vous pensez, est-ce que vous pouvez ressentir, euh, j'ai ma propre définition de cela, mais je ne suis pas sûr de pouvoir apporter une réponse concise à cette question, mais, d'accord, reprenons. Qui devrait, genre, je m'intéresse à la manière de tester les agents et de entraîner former ou entraîner afin qu'ils soient à la hauteur de leur travail. Qui devrait le faire et comment ?

Bon, bon, je vais commencer, et ensuite Davis, euh, je suis sûr que tu as quelques idées. Euh, oui, à première vue, on pourrait dire que tester un agent, c'est comme tester un logiciel. En fait, c'est un exercice très différent.

Et la raison fondamentale amusante, euh, c'est que si je teste un logiciel qui est déterministe, en d'autres termes, qui donne la même réponse pour les mêmes entrées, alors des choses simples comme l'inégalité, l'opérateur, euh, sont des choses évidentes que vous utilisez dans les tests avec des agents. Vous n'avez pas nécessairement cela. Un agent a évidemment un LLM comme cerveau, euh, pour utiliser ce terme.

Hum, mais ces LMS sont non déterministes. En termes simples, cela signifie que si je fournis deux fois les mêmes données, j'obtiens une réponse légèrement différente. Cela signifie que l'opérateur d'égalité traditionnel utilisé dans les tests ne fonctionne plus.

Ce qu'il faut, c'est disposer de différents moyens pour évaluer concrètement un agent. Euh, donc, nous considérons cela davantage comme une gestion des performances ou une évaluation des agents plutôt que comme un test. Nous avons donc élaboré des grilles d'évaluation, par exemple, qui se basent sur euh, le niveau d'autonomie et le niveau de criticité.

Évidemment, si vous êtes très critique et très autonome, vous devrez disposer d'une capacité de test et d'évaluation extrêmement rigoureuse. Et il peut y avoir six ou sept dimensions qui dictent ce que vous pouvez ou ne pouvez pas faire, ou ce que vous devez ou ne devez pas faire. Si vous avez quelque chose qui est peu critique et peu autonome, cela se rapproche peut-être davantage d'un chatbot, je suppose.

Peut-être n'avez-vous pas besoin de faire beaucoup de tests. Cela dépend donc de votre position dans ce continuum. La deuxième chose que je dirais, c'est que lorsque vous testez un agent, ce que nous pensons, et je pense qu'il existe une terminologie à ce sujet.

Vous avez un agent, un agent juge, qui peut juger la réponse d'un autre agent ou d'un juge, LLM. Ce sont des choses que nous voyons réellement sur le terrain. Donc, utiliser un LLM pour tester un LLM, est-ce que cette réponse, est-ce que cette réponse, n'est peut-être pas nécessairement exactement la même ou reproductible, mais l'intention de la réponse est-elle la même ?

C'est là que nous voyons les tests réels entrer en jeu. Nous appelons cela l'évaluation. Je vais maintenant poser quelques questions à Davis sur apprentissage .

Parce que je pense que Davis, euh, il y a, il y a beaucoup de choses. Je sais que vous avez une certaine expérience avec l'un de nos gros clients détaillants il y a quelque temps, concernant, euh, la manière dont ils pourraient commencer à essayer de, euh, reformer le modèle. Et cela pose certains défis.

Et nous avons trouvé, à l'époque, des solutions probablement assez naïves, du genre chiffon. Donc, ce n'est peut-être pas exactement « apprentissage modèle », mais plutôt « équiper le modèle d'informations sur votre entreprise ». Pourquoi ne pas nous en dire un peu plus à ce sujet ?

Évidemment, sans mentionner le client. Oui. Il existe donc différentes façons entraîner agent et d'augmenter ses Fonctionnalités.

L'une d'entre elles consiste évidemment à effectuer une sorte apprentissage modèle sous-jacent, mais il s'agit d'une solution très lourde. Vous avez besoin de nombreux exemples, et vous devez le faire pour chaque agent que vous allez utiliser. Cela n'est tout simplement pas évolutif. Les moyens d'augmenter un agent ou de lui donner de nouvelles compétences qui évoluent de manière un peu plus efficace consistent à lui fournir davantage de données à traiter ou à lui donner davantage d'outils ou de collaborateurs pour gérer le travail.

Vous pouvez lui donner un nouvel outil qui lui confère une nouvelle capacité d'interaction avec le monde. En programmant cette capacité de l'outil et en demandant à l'agent de l'inclure dans le tâche , vous pouvez lui donner des collaborateurs supplémentaires, d'autres agents qu'il peut contacter et qui ont Fonctionnalités agent principal n'a pas, et il peut simplement appeler ces agents et leur demander d'effectuer la tâche. Vous pouvez également fournir à l'agent davantage de données.

Vous pouvez utiliser une approche relativement naïve, ou vous pouvez opter pour des solutions plus avancées comme les graphes de connaissances, ce genre de choses, pour obtenir davantage d'informations. Cela permet à l'IA de prendre de meilleures décisions, car elle dispose de plus d'informations. Ce sont là les principales méthodes que vous utiliserez pour entraîner perfectionner un agent qui s'adaptera aux milliers et milliers d'agents que nous espérons avoir à terme.

Oui, non, je voudrais revenir sur la dernière partie de la question de Ronald concernant la certification. Parce que nous y consacrons en fait un chapitre entier. Cela fait partie de notre cadre de confiance.

Donc, encore une fois, euh, excusez-moi, je vais utiliser une autre analogie, euh, au Canada, et je suppose que c'est la même chose en Europe, mais quand j'achète un grille-pain au Canada, euh, il y a un petit logo au bas de l'appareil qui s'appelle l'Association canadienne de normalisation. Ce que cela signifie, c'est que mon grille-pain ne va pas mettre le feu à ma maison quand je l'utilise. Ce logo signifie que cette marque répond à certaines attentes en matière de service et de qualité, et qu'il certifie que ce grille-pain est conforme aux normes.

Euh, aux États-Unis, ils ont Underwriters Lab qui fait la même chose. Euh, en Europe, je ne suis pas sûr, mais au Canada, encore une fois, si je regarde une prise électrique, je peux voir un petit logo qui indique que cette prise est sûre à utiliser. Nous pensons que le même principe s'applique aux agents, et nous pensons que c'est le niveau supérieur de cette gouvernance .

La pyramide de confiance commence en fait par l'identité et les rôles, puis passe par l'explicabilité, mais fondamentalement, au sommet de la pyramide, nous avons la certification et gouvernance. Nous sommes convaincus qu'il existe aujourd'hui des modèles, tels que ceux de l'Association canadienne de normalisation, du Underwriters Laboratory, leurs gouvernance fédérée, leurs modèles de certification fédérée, qui permettent chaque jour de certifier que des millions, voire des centaines de millions de produits peuvent être utilisés en toute sécurité. Nous pensons que le même principe peut s'appliquer aux agents.

Nous pensons donc, encore une fois, que le modèle est déjà défini pour nous. Il comporte, entre autres, un cadre entièrement délégué qui stipule que je dois respecter des politiques macroéconomiques, puis il descend jusqu'aux spécifications électriques d'un grille-pain, aux spécifications de chauffage, aux spécifications relatives au métal utilisé pour le boîtier du grille-pain. Toutes ces choses ont un cadre de spécifications fédéré et un gouvernance fédéré et des institutions accréditées.

Cela semble très, très compliqué, n'est-ce pas ? Et si vous gérez des centaines de millions de produits, c'est peut-être normal, mais au sein de l'entreprise, ce modèle fonctionne également. Ainsi, au niveau supérieur, nous pouvons dire, par exemple, qu'un agent doit être, euh, conforme au RGPD.

Celui-ci délègue ensuite à, euh, un agent de vérification d'identité. Et cela a et vous, vous tirez des conclusions sur la manière dont cet agent de vérification d'identité serait conforme au RGPD. Vous appliqueriez cela à tous les autres agents également.

Donc, peut-être que ce dont nous avons besoin, c'est d'un ensemble de spécifications techniques, là encore, ventilées par domaine d'activité, probablement à un niveau granulaire. Euh, et ensuite, nous avons des experts qui peuvent valider ces spécifications et vérifier, à l'aide de l'approche d'explicabilité que nous avons mentionnée précédemment, que l'agent respecte bien ces spécifications. Nous pensons que ce modèle garantira, métaphoriquement parlant, que votre agent ne mettra pas le feu à votre centre de données.

Donc, nous voyons beaucoup d'exemples et d'analogies qui simplifient le parcours d'une entreprise. Euh, et ils sont juste devant nous. Ole Oui, non, c'est logique.

Je veux dire, il s'agit en fait de prendre des perspectives étonnamment concrètes, euh, du monde existant et simplement, euh, les appliquer à la réalité agricole, tout simplement. Euh, et je vois aussi, euh, Ronald, euh, merci de nous avoir répondu et, et, et, et que la réponse était, euh, complète. Euh, nous avons également des questions de Michael et de, euh, Sabrina.

Bonjour à vous deux. Je suis ravi de vous accueillir à ce webinaire. Michael, je vais commencer.

Je vois que vous avez posté en premier, mais j'ai également vu votre question, Sabrina. Hum, Michael Wrights souhaite comprendre le point de vue des participants sur l'impact de la couche sémantique définie par l'entreprise sur les fournisseurs de services d'IA, en particulier contrairement à celle du système de santé Epic e HR ou de la plateforme sub EP, qui obligent généralement leurs clients à adopter une grande partie de leurs flux de travail, utilisateur , etc., et il souhaite comparer cela à ce que signifie avoir une architecture Gentech définie par l'entreprise, comment et comment anticiper les fournisseurs de services d'IA, l'IA ouverte et la possibilité de faire évoluer leurs activités si leurs clients ont besoin de leur propre couche romantique définie de manière unique. Oui, je comprends la question.

Tu peux suivre ? Ou est-ce trop long ? Non, non, je suis en train de le lire.

En fait, je l'ai, euh, je l'ai devant moi sur l'écran. Tout d'abord, euh, Michael, c'est une question fantastique et je pense que le moment est très opportun, euh, pour plusieurs raisons différentes. Je ne suis pas un expert en matière de catalogue de données 'espace sémantique, contrairement à Ole, mais laissez-moi vous dire que je suis confronté à ce sujet et que j'ai un point de vue à ce sujet, car nous le voyons dans presque toutes les relations avec nos clients.

Bon, revenons un peu en arrière et reprenons quelques notions de base simples. Lorsqu'un agent tente de répondre à une demande, comme l'a mentionné Davis, nous chargeons les informations relatives à cette entreprise ou à ce sujet aussi près que possible de cette demande afin que l'agent dispose de toutes les informations nécessaires. C'est ce qu'on appelle l'ingénierie contextuelle, qui consiste à trouver le bon contexte au bon moment pour le bon budget de jetons et à l'intégrer dans la fenêtre contextuelle de l'agent afin qu'il puisse faire son travail le plus efficacement possible.

Le défi est le suivant : dans une entreprise qui possède des centaines de téraoctets ou de pétaoctets d'informations, un corpus, qu'il s'agisse de données structurées, de données non structurées, d'images, de vidéos, il y a des pétaoctets de données. Comment puis-je obtenir les bonnes informations à partir de ces pétaoctets ? Et j'obtiens ce qui correspond effectivement à quelque chose entre 200 000 et un million de jetons, un jeton étant environ un mot juste pour, pour, pour, pour le rendre, euh, réel.

Hum, alors, alors, comment je fais ça ? Eh bien, ce que nous avons constaté, c'est que pour faire ça, eh bien, c'est ce que nous appelons, vous devez avoir une connaissance ag, une connaissance agentique, un tissu, un mot sophistiqué pour dire que je dois être capable d'identifier, je dois avoir un gestionnaire de contexte virtuel qui crée le minimum. J'insiste sur le minimum, car il s'agit d'un budget symbolique viable, ce qui signifie qu'il comporte des concepts et des politiques, des limites de décision, et je peux intégrer cela dans les agents ou la fenêtre contextuelle des LLM.

Pour ce faire, vous pouvez utiliser différentes approches. Techniquement, vous pouvez effectuer un enregistrement naïf, comme l'a mentionné Dave, mais cela ne fonctionne pas forcément très bien. Vous pouvez compléter cela avec des graphes de connaissances.

Hum, il y a toute une série de choses différentes. Nous avons discuté avec certains clients qui utilisent des outils tels que le classement des pages pour, en fait, hum, comprendre et relier les concepts dans un très grand, vaste graphique, fondamentalement. Hum, c'est un mécanisme auquel vous devez réfléchir, mais la manière dont vous lui donnez un sens, c'est à travers les taxonomies et les ontologies.

Quels sont les concepts que je devrais saisir ? Comment puis-je représenter concrètement une politique dans un graphe de connaissances ? Comment puis-je concrètement mettre en évidence les relations entre ces politiques qui peuvent s'appliquer à un client dans le sens du ML, dans le sens de la lutte contre le blanchiment d'argent, ce qui est différent d'un client du point de vue des ventes, les attributs sont très, très différents.

Ce sont donc toutes ces choses auxquelles vous devez réfléchir, et nous appelons cela la structure de connaissances agentique qui repose, comme je l'ai dit, sur un graphe de connaissances, une ontologie, une certaine taxonomie Fonctionnalités. Mais en fin de compte, ce dont vous avez besoin, c'est cohérence sémantique, afin de pouvoir fournir les bonnes informations, au bon moment, avec le bon budget de jetons à l'agent. Le LLM nous permet de voir la compréhension sémantique, les taxonomies, les ontologies, qui reposent toutes sur cette structure de connaissances comme la prochaine innovation dans le paysage des agents.

C'est certainement aussi quelque chose que je suis de très près et auquel je réfléchis. Euh, et, euh, évidemment, ce webinaire ne porte pas sur l'action en tant qu'entreprise. Donc, par respect pour les participants, je ne pense pas que je devrais aborder ce sujet ici, mais je pense que c'est très précisément défini et que c'est l'un des défis que nous devrons relever dans un avenir proche.

D'accord. Euh, nous avons une question de Sabrina, et j'ai vu votre question, Sabrina, donc je vais y répondre. Euh, oh, en fait, cela concerne aussi un peu les tests, donc dans la mesure où, euh, je vais y répondre, mais je pense en fait que vous y avez déjà répondu.

Euh, tu le vois aussi, euh, Eric et Davis dans le Oui, je peux le voir, Lee. Oui, je l'ai vu dans le chat du webinaire. Oui, je le vois.

Quoi, qu'est-ce que vous... Peut-être devrions-nous passer à Davis. Euh, avez-vous quelque chose à ajouter à propos de cette question ? Euh, je pense que la réponse précédente couvre en grande partie le sujet, mais il serait peut-être utile de revenir sur certains points.

L'une des premières questions qui se pose est la suivante : qui doit rédiger les tests ? Doivent-ils être rédigés par des agents, par des humains, ou par les deux ? Cela dépendra en grande partie du degré de maturité de votre réseau identitaire à ses débuts. Lorsque vous créez votre premier agent, voire vos premières dizaines d'agents, il est logique que la plupart de vos tests soient effectués par des humains.

Vous êtes encore en train de vous familiariser avec les agents, vous allez donc vouloir procéder à une évaluation manuelle. Mais à mesure que le réseau ENT se développe, que vous disposez de milliers et de dizaines de milliers d'agents, voire plus, vous allez devoir commencer à vous fier davantage à des agents efficaces, des agents de test, simplement pour gérer à l'échelle nécessaire, lorsque vous n'avez pas assez de personnel pour vérifier manuellement chaque résultat à chaque fois. Vous n'allez pas complètement vous passer des tests humains.

Vous aurez toujours besoin d'humains pour vérifier que les tests sont corrects, pour effectuer des contrôles ponctuels, pour vous assurer que tout fonctionne correctement, mais la part d'intervention humaine ou l'âge dépendront de votre maturité dans le développement de votre propre projet. Oui, Davis, l'une des choses dont nous avons parlé est, euh, et je sais que nous avons eu de grands débats avec, euh, certains de nos collègues et certains clients, mais, euh, quand on pense à l'autonomie, à la haute autonomie et à la haute criticité, euh, il y a, il y a une discussion qui dit que c'est pour certains de ces très hautement autonomes et très critiques, je veux dire, les scénarios à haut risque qui, aujourd'hui du moins, changeront peut-être à l'avenir, mais dans un avenir prévisible, nous pensons que ceux-là, il y a un sous-ensemble qui doit impliquer une interaction humaine et une vérification humaine, par exemple en matière de santé, ou peut-être les paiements de grande valeur, où il peut y avoir un risque de fraude ou de blanchiment d'argent. Il existe un sous-ensemble de tests qui, selon nous, doivent être maintenus dans un avenir prévisible, ou du moins impliquer explicitement une intervention humaine ou une supervision humaine.

Oui.

Hum, je pense que je vais, hum, alors que nous approchons de la fin, je, je pense que j'aimerais, hum, poser la dernière question que j'avais préparée, et nous pourrons revenir sur les autres, euh, sujets de discussion, euh, dans, dans des messages. Mais je voudrais vous demander, euh, comment, comment était-ce, comment était-ce d'écrire ce livre ? Euh, parce que je suppose que tous les livres, ils, vous avez un certain sentiment à leur égard.

Ils le sont, ils peuvent être trop précoces, euh, ils peuvent être tout à fait pertinents, ils peuvent être trop tardifs, ils peuvent susciter différents types de réactions. Comme quoi, qu'est-ce qui a été, qu'est-ce qui a été, les, les, les retours jusqu'à présent ? Êtes-vous trop en avance ?

Toi aussi ? Je suppose que tu n'es pas en retard. Eh bien, oui, eh bien, laisse-moi commencer et ensuite, euh, je laisserai Davis répondre à la question de savoir comment c'était de travailler avec son père, je suppose.

Mais, euh, mais, voici ce que je dirais : lorsque Davis et moi avons eu l'idée de ce livre, c'était, Ole le sait, nous avions déjà écrit quelques livres avec O'Reilly. C'est un long processus. C'était il y a environ 16, 14 à 16 mois, et nous ne savions pas comment le paysage des agents allait évoluer.

Euh, nous, il n'y avait pas de Claude Code ou Codex et Chat. GPT en était encore à la version 3.5 ou quelque chose comme ça. Pas très, euh, efficace, pour être honnête avec vous, du moins pas comparé à aujourd'hui.

C'était merveilleux à l'époque, mais comparé à aujourd'hui, ce n'était pas vraiment à la hauteur. Il est intéressant de noter que nous avons réexaminé les analogies. Que s'est-il passé dans l'entreprise lorsque vous êtes passé d'un à plusieurs ?

Donc, à l'époque, j'ai beaucoup travaillé avec les API, et quand on en a une, deux ou trois, ce qui remonte à très, très longtemps, c'est facile de les gérer. Mais quand on en a 10, 100 ou 1 000, il faut réfléchir de manière très, très différente. C'est la même chose avec data products.

Si vous avez un ou deux data products, c'est intéressant, mais quand vous en avez 10, une centaine, voire plus d'une centaine, comme c'est le cas pour certains de mes clients, il faut envisager les choses différemment. Il faut envisager différentes pratiques de gestion. Ainsi, lorsque Davis et moi avons eu l'idée de ce livre et que nous l'avons présentée à O'Reilly, nous avons insisté sur le fait que nous n'allions pas nous arrêter à un seul agent.

Nous allons en avoir des dizaines, des centaines, des milliers. Et les leaders du secteur l'ont confirmé. Donc, pour répondre longuement, Olay, nous pensons que nous sommes au bon moment et au bon endroit, ce que nous ne savions pas il y a 16, 14, 16 mois, mais nous avons la chance d'être là aujourd'hui.

Oui, c'est un peu ce que je ressens aussi. Davis, tu veux intervenir ? J'aimerais avoir plus de détails sur ton travail d'écriture avec ton père.

Oui, écrire avec mon père a été une expérience formidable. Nous nous connaissons évidemment très bien, et nous sommes sur la même longueur d'onde lorsque nous discutons de nos idées. Cependant, cela a été assez différent du travail de conseil que nous faisons habituellement ensemble, notamment parce que mon père a beaucoup plus d'expérience que moi dans l'écriture de livres.

Et je suis très heureuse d'avoir écrit ce livre avec quelqu'un qui avait cette expérience , car cela s'est avéré très utile pour amener le livre au niveau élevé que nous nous étions fixé. Oui, non, c'est tout à fait logique. Je veux dire, c'est aussi, et vraiment, vraiment, c'est juste une expérience vraiment, vraiment différente, euh, d'écrire avec, euh, quelqu'un d'autre et d'écrire un livre pour la première fois.

Mais je pense aussi que, si je devais dire quelque chose sur le timing de votre livre, je dirais qu'il arrive au bon moment, car tout le monde n'en est pas encore conscient. Les gens comprennent qu'il faut réfléchir à la mise en place d'architectures dans leur entreprise, et ils comprennent aussi que ce n'est pas quelque chose que l'on peut prendre à la légère. Ce sera compliqué à mettre en place, n'est-ce pas ?

Je pense donc que ce livre arrive à point nommé et qu'il est extrêmement intéressant à lire. Je tiens donc à vous remercier d'avoir participé à ce webinaire aujourd'hui. Nous reviendrons avec d'autres informations, dans des publications et des articles partagés.

Je peux vous garantir que vous êtes au moins le bienvenu pour écrire pour nous. Et je serais heureux d'écrire avec vous. Je tiens également à remercier tous les participants pour leur patience.

C'était, euh, je suppose, un webinaire un peu technique, mais aussi très nécessaire. Merci à tous de nous avoir écoutés et merci à Eric et Davis. Eh bien, Ole, merci beaucoup à vous et à toute l'équipe d'Acton de nous avoir accueillis.

Merci beaucoup. Et je vous remercie également. C'était formidable d'être ici.

Merci.