Hookdeck : La fausse simplicité des webhooks

Bruno — Les webhooks, c'est un peu comme la petite porte dérobée d'une grande salle de spectacle. On pense que c'est juste un gadget pour faire passer quelques messages. Et puis, au fur et à mesure, on se rend compte que c'est en fait la porte d'entrée sur tout un monde d'architecture événementielle. D'abord, réservé à de très grosses boîtes, cette gateway drug, de, l'event-driven, commence à envahir toutes les équipes à tous les niveaux. Mais alors, pourquoi les webhooks sont-ils devenus indispensables alors qu'on les prenait encore pour des hacks il y a 10 ans ? Qu'est-ce qui se cache vraiment derrière cette fausse simplicité ? L'ingestion sans contrôle, la sécurité, la duplication, les filetantes, bref, tout un énorme de choses. Et surtout, si un visiteur snobbe la porte et passe par la cheminée, on en fait quoi ? Pour répondre à ces questions d'architecture, je ne reçois pas le Père Noël, mais il s'y connaît en scalabilité de dernière minute. Alexandre, bonjour.

Alexandre — Bonjour, excellente introduction. Et puis, il sera mieux récapitulé le sujet.

Bruno — Merci, merci. Alors, Alexandre, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Alexandre — Oui, donc mon nom est Alexandre Bouchard, je suis québécois, vous allez sûrement le voir dans mon accent assez rapidement. Je suis le fondateur d'une compagnie qui s'appelle Hook Deck. Donc, on bâtit un Event Gateway, toutes sortes d'outils au niveau de la gestion des webhooks. Puis peut-être juste pour revenir un peu en arrière, en fait, mon expérience à ce sujet-là commence dans une compagnie antérieure où on avait beaucoup de dépendance sur les webhooks à travers les systèmes qu'on bâtissait. Spécifiquement, dans ce contexte-là, c'était en e-commerce. Donc, on parle de Stripe, de Shopify et tout ça. Et donc, d'un côté, j'avais ma responsabilité d'essayer une boîte en mode féminine. Donc, j'essayais de vendre des bas collants, des bons nylons, des robes, etc. Puis de l'autre côté j'avais comme toutes sortes d'enjeux associés à la gestion des webhook donc ça faisait une dichotomie quand même dure à réconcilier en termes de priorité, puis là une idée en est venue à l'autre donc ça fait maintenant 6 ans que je travaille sur Udeck ok.

Bruno — Alors ce qui m'a justement intéressé quand j'ai découvert Udeck c'est pour moi le webhook ça paraissait être quelque chose d'assez basique parce qu'au final c'est juste on envoie une information, un payload sur une URL, ce qui paraît assez simple. Mais du fait, j'ai découvert, toute la face immergée de l'iceberg au final, au travers des webbooks que j'ai trouvé absolument phénoménal. Et qu'en fait, le webbook, c'est ce que je disais en intro, c'est la gateway drug. Alors, c'était toi qui m'avais donné l'expression en préparation. Mais est-ce que tu peux déjà nous raconter un peu le... Je ne sais pas si tu as l'historique du webbook et de comment ça s'est arrivé. Mais en fait, par quoi ça a commencé et qu'est-ce que ça englobe aujourd'hui avant qu'on creuse un peu différents sujets ?

Alexandre — Oui, absolument. L'histoire, je veux dire, je n'étais pas impliqué dans l'histoire. J'en ai appris par la bande au courant des années. Mais oui, tout à fait. En fait, le webhook est vraiment né d'un besoin d'avoir des réponses asynchrones. Je pense que la première compagnie à avoir fait des webhooks, si je ne me trompe pas, c'est Twilio. À l'époque, ça doit faire une quinzaine, si ce n'est pas même une vingtaine d'années à ce point-ci. Et je pense que quand on a bâti nos outils, nos softwares à la base, tout était vraiment basé sur des requêtes synchrones. Donc nos API et tous les outils qu'on connaît maintenant autour des API. Puis évidemment, on a plusieurs évolutions de l'API, du SOP au REST, au GraphQL, etc. Mais, éventuellement, le besoin de devoir envoyer, dans le fond, ces notifications-là, si on veut, à ses clients incommunés. Généralement, j'aurais tendance à dire les grosses boîtes, mais aussi les boîtes qui étaient, vraiment à la naissance de bâtir des outils pour développeurs. Quand on parle des Twilio, des Stripe et tout ça, c'est des compagnies qui bâtaient, dans le fond, vraiment les premières entreprises qui étaient des API tout et avant tout et qui étaient bâties pour les développeurs. Et aux forces de chercher l'amélioration de l'expérience pour le développeur, tout ça est comme né ce besoin de devoir envoyer des notifications asynchrones, donc le webhook est vraiment né de ça, puis je pense qu'au départ si, je peux présupposer, je pense que c'est venu d'une place un peu naïve où ben oui, on va juste envoyer une requête HTTP, c'est quoi la complexité associée à ça puis je pense qu'au tout début c'était effectivement plutôt simple, dans le sens que. Dans la nature rien de compliqué je pense que la complexité embarque quand soudainement ok. Tes webhook ils viennent plus juste de Twilio ils viennent de maintenant plusieurs vendeurs qui utilisent différents mécanismes de sécurité puis là t'en reçois pas 10 t'en reçois 15 millions puis après ça, ton serveur a des problèmes de performance de régression de performance donc ça prend trop longtemps à répondre à tes webhook ou sinon t'as un outage tu fais des migrations tout ce genre de trucs là, qui là soudainement quand tu bâtis ton application, ta business de façon à ce que dans le fond ces webhooks-là sont critiques dans le fond aux opérations du. Produit ben là tu dois commencer à te poser tout ce genre de questions-là de ok c'est quoi ma contingence dans le cas où mon serveur est pas en mesure de gérer les webhooks c'est quoi ma contingence, dans la situation par exemple Twilio un outage puis une demi-heure plus tard il dans le fond envoie tous les webhooks qu'ils ont pas envoyé dans la dernière demi-heure qui ont eu leur outage etc, Donc, il y a beaucoup de choses qui sont hors de ton contrôle, au final. Puis, je pense que quand on résume ça, en fait, c'est un problème assez classique de « event-driven architecture ». Puis, je pense qu'historiquement, les gens peut-être ne le perçoivent pas comme ça. Puis, c'est d'où vient le « gateway drug to event-driven architecture ». C'est l'idée de dire, pour beaucoup d'équipes, c'est leur première exposition à ce genre de contraintes-là, de challenges, par rapport à gérer les événements qui rendent dans ton infrastructure. Mais plus particulièrement je pense que quand on fait le contraste avec l'Aventure Architecture ce qui est particulier dans le contexte d'un webhook en fait c'est que tu contrôles pas le producer pour utiliser le terme qu'on utilise dans le milieu. Donc ce que je veux dire par là dans le fond c'est que la personne qui t'envoie les événements choisit l'événement ressemble à quoi il choisit le nombre de bêtes il choisit la shape il choisit le système le mécanisme de sécurité etc donc t'es un peu à la merci dans le fond du choix de ton vendeur ou de tes vendeurs qui vont t'envoyer ce webbook là, c'est ça que je crois assez fou dans.

Bruno — Ce que t'évoques c'est que cette notion de Devon Driven Architecture, on était habitué sur des environnements microservices, mais au final effectivement tes microservices en fait tu les contrôles, tu les maîtrises tu maîtrises les messages qui sont envoyés mais tu peux aussi du coup les rejouer facilement parce qu'en fait tu peux refaire appel à ton microservice qui est dans ton environnement et tu sais comment le rappeler et le relancer, alors que là dans ce que t'évoques c'est que le webbook est devenu, ça te permet de considérer Stripe, au même titre que, comme un microservice au sein de ton environnement, sauf qu'il est juste placé à côté mais comme tu le dis, t'en as plus aucune maîtrise quoi.

Alexandre — Oui, tout à fait. Je pense que quand tu y penses qu'on construit des applications maintenant, il y a d'énormes dépendances sur ces services externes que je pense que c'est tout à fait raisonnable de considérer comme un service qui fait partie de ton infrastructure. Au même niveau que ton système de gestion de commandes qui est potentiellement interne et traité un peu de la même façon. C'est sûr que t'as des niveaux critères, mais quand on pense vraiment à l'idée du microservice à la base, l'idée c'était de dire, ok, on va faire des équipes autonomes avec des services qui ont des responsabilités définies, qui vont définir leur propre contrat en termes de ça va être quoi l'API, ça va être quoi les fonctionnalités de ces microservices-là et tout. Et donc, c'est vraiment l'équivalent quand tu regardes un service comme Stripe ou comme Twilio ou peu importe. La seule différence, en fait, c'est que c'est pas dans la même compagnie. Mais idéologiquement, c'est essentiellement la même chose.

Bruno — Du coup, sur tous ces sujets, quand tu gères tes événements au sein de ta propre architecture avec tes services, en général, tu as ton bus d'événements et donc tu as tout un ensemble de systèmes qui te permettent au final de pouvoir auditer tout ça et de les rejouer et de gérer peut-être aussi ta taille de fil d'attente. Comment est-ce que tu peux déjà de manière très simple tu peux intégrer tous les événements que va te balancer un Stripe, un Twilio ou je ne sais quoi dans cette même file d'attente ou tu es obligé de l'avoir encore à côté aujourd'hui.

Alexandre — Je pense que c'est vraiment une décision qui se fait un peu, de façon ad hoc d'une entreprise à l'autre par rapport à leur approche il y en a certains qui prennent des risques en fait qui décident de ne pas faire, faire les devoirs, si on veut, par rapport à la résilience et tout ça de ces webhooks-là. Puis il y en a d'autres, en fait, qui sont déjà très sophistiqués dans leur approche et qui traitent effectivement les webhooks déjà de cette façon-là. Évidemment, il y a des enjeux dans le sens où ça ne peut pas être littéralement traité de la même façon parce qu'il y a ce problème-là de... De compatibilité, si on veut, dans le sens où la requête HTTP doit être mise, dans une queue, mais elle doit aussi être vérifiée, doit aussi répondre à un certain nombre de temps, doit aussi avoir. Des critères de scalability et tout ça pour être capable de gérer le load. Donc oui, le problème se rapproche, mais c'est un peu, de la façon que je l'ai décrit, c'est un peu le problème du API Gateway qui est l'interface HTTP avec les services de message bus et tout ça, l'autre chose aussi qui est potentiellement pertinente c'est souvent le travail qu'il y a à faire en réception à ces webbooks là, oui on peut dire comme oui on va le mettre directement dans la queue mais il y a d'autres enjeux qui rentrent souvent en compte, à cause que tu ne contrôles pas le producer des fois tu vas en savoir beaucoup plus que ce que tu as besoin auquel cas si tu le mets tout dans ta queue ça va te coûter cher, il faut que tu le processes quand même ça va prendre ma capacité sur la queue etc donc il y a souvent, le besoin de pré-filtrer, des fois pré-filter basé sur. Du state dans ton système par exemple, ce webbook là que je reçois est-ce que c'est pour un client qui est toujours un client payant chez nous ou non? Parce que si tu es un client payant, je ne veux pas prendre le coup de gérer ce webbook là pour lui etc, donc il y a ces enjeux là qui rentrent en compte puis l'autre chose c'est souvent tu n'as pas vraiment accès au source of truth donc souvent le source of truth ça va être ton vendeur en tant que tel mais la data est pas nécessairement accessible, facilement par rapport à qu'est-ce qui a été changé qu'est-ce qui est délité souvent tu vas avoir seulement le current state du système auquel cas oui tu peux t'embarquer dans de la réconciliation si jamais tu gères mal certains de ces événements-là Mais l'alternative, en fait, c'est d'être capable d'auditer, de comprendre c'est quoi les webbooks qui ont été reçus, mais aussi de les rejouer. Donc, si jamais il y avait une faute, en fait, dans. Le consumer de cette queue-là, qui a mal processé un certain webbook, qui devait avoir envoyé un certain email ou donner du crédit, etc., puis que ça ne s'est pas passé, il faut être en mesure de retracer ça. Souvent quand c'est tes propres systèmes qui ont généré l'événement c'est beaucoup plus simple d'aller faire ça tout dit mais quand c'est un système externe t'as pas nécessairement accès à la data dans la façon que tu le veux pour être capable de le faire donc, souvent ce qu'on voit chez les compagnies en fait c'est qu'ils vont créer leur propre système de storage puis de recherche puis de replay sur ces webhooks-là, puis dépendamment du niveau de criticalité là certains qui vont peut-être conserver, qui vont peut-être conserver pendant longtemps alors qu'il y a d'autres qui ne vont pas nécessairement conserver. Donc, ça devient un peu un cas par cas, en fait, de chaque webhook, qu'est-ce qu'ils décrivent, c'est quoi le niveau d'importance de ça pour mes opérations.

Bruno — Est-ce que, du coup, dans ce que tu décris, parce qu'on sent que ça te rajoute quand même une complexité au niveau de ton architecture, est-ce que c'est-à-dire que c'est, on va dire, un écosystème ou des problématiques qui sont réservées aujourd'hui à des grosses boîtes, où tu penses que de par une forme peut-être de multiplication des webhooks de différents acteurs ça devient un problème de plus en plus présent même pour des structures de plus en plus petites.

Alexandre — Je pense qu'il y a vraiment deux phénomènes qui se produisent en parallèle en fait donc le premier effectivement je pense qu'il y a juste beaucoup plus, de code d'utilisation pour les webhooks autant que les vendeurs avec lesquels Tanki Tech de plus en plus maintenant offre des Webhook comme une option pour synchroniser la data ou pour recevoir les évènements. Je pense aussi que le nombre de cas de vendeurs qu'on utilise à travers nos applications grandissent aussi. Puis une des choses qu'on voit en ce moment, c'est de plus en plus. De cas d'utilisation pour des systèmes que historiquement, c'est vraiment des humains qui utiliseraient. Je pense que par exemple, il y a du customer support. Historiquement, les agents de customer support étaient dans leur outil, faisaient leurs choses, etc. Maintenant, de plus en plus, la data par rapport au ticket va dans des systèmes pour rouler un agent qui va recommander une réponse, etc. Donc, on voit vraiment comme une croissance dans les scénarios dans lesquels c'est utile de s'abonner à ces événements-là, à ces webhooks-là. Donc, ça, je pense que c'est un phénomène. L'autre phénomène, en fait, tu l'as évoqué plus tôt, quand on parle de Venture in Architecture, historiquement, c'était comme réservé un peu aux grandes entreprises qui avaient, des systèmes de microservices assez compliqués et tout ça. Puis on pense à certaines technologies, par exemple, comme Kafka qui est née, chez LinkedIn pour leurs besoins de LinkedIn. Donc, on ne parle pas des besoins des développeurs moyens. Et donc, je pense que ce que ça a fait, en fait, c'est que les outils ne se sont pas vraiment développés. Avec l'expérience du développeur en tête puis il était vraiment focussé sur, des optimisations de microsecondes de performance puis de large scale et tout ça. Donc, cette espèce de modernisation, si on veut, de nos outils qui s'est passé comme dans le monde de l'API puis du hosting, je pense notamment à des Roku, des Vercel puis toute cette espèce de trend-là de modernisation, de simplification. Je pense qu'il y en a certains qui voudraient ouvrir le débat à ce niveau-là. mais... On va bâtir les outils pour les développeurs de façon différente, de façon à ce que ce soit accessible, de façon à ce qu'une personne individuellement ait la chance de pouvoir toucher à plusieurs aspects sans être obligé d'apprendre, les détails de chaque nuance, de catégorie de problème dans notre métier. Mais bref, tout ça pour dire que cette espèce de mouvement s'est pas passé dans l'asynchrone, parce qu'il y avait cette espèce de, ok, on bâtit des outils pour, des grandes entreprises. Donc, de la façon que je le vois, il y a comme un 5-10 ans de retard en termes de modernisation des outils. Puis je pense que nous, on est un acteur là-dedans en termes d'essayer d'amener cette modernisation-là, mais il y a d'autres compagnies qui approchent le problème différemment. Je pense notablement à, par exemple, Temporal, à Ingest, puis il y a d'autres outils même des Red Panda ce genre de trucs là qui essayent, de prendre ces enjeux là puis les moderniser pour offrir des outils qui sont plus approchables qui sont plus faciles à déployer, qui sont plus faciles à opérer et tout ça puis je pense qu'au fur et à mesure de faire ça il y a aussi, certaines choses qui doivent être remises en question des décisions qui ont été prises de comment des messagebusters étaient supposés fonctionner il y a 20 ans qui font plus nécessairement beaucoup de sens maintenant, pour un paquet de codes d'utilisation. Moi, c'est vraiment quelque chose à quoi je pense beaucoup.

Bruno — Justement, cette évolution, c'est-à-dire que toi, tu ne vois pas comme évolution. Moi, à vue de nez, j'ai envie de dire que peut-être qu'il y a 20 ans, on avait des messages qui étaient beaucoup plus gros puisqu'on a le temps d'être beaucoup plus économe qu'aujourd'hui. Je vois que tu commences un petit peu à jouer avec Stripe. Tu vois que tu as un nombre d'événements. Stripe peut te shooter un nombre d'événements qui est absolument colossal, mais à chaque fois avec des pélotes qui sont très très petits est-ce que c'est ça le genre d'évolution que toi tu vois, une espèce de réduction de la taille des pélotes ou il y a d'autres choses encore ?

Alexandre — Je pense que quand je... C'est tout à fait vrai. Je pense que certains des enjeux et des critères par rapport à l'utilisation changent à travers ça. Mais non, mais ce que je veux dire, c'est même un peu plus fondamental que ça. Je vais donner un exemple dans à peu près tous les messagebusters qui existent maintenant. Tu ne peux pas savoir c'est quoi les messages qui sont dans le messagebus. Donc, l'action de lire le message, c'est ce qui prend un claim, dans le fond, sur... Je ne sais pas ce serait quoi l'équivalent en français, mais qui prend le claim sur ce message-là. Et donc, la seule façon de savoir c'est quoi qui est dans ta queue, c'est de le sortir de la queue. C'est très pratique. Ce qui est... Ce qui, d'un point de vue de delivery guarantee, tout ça, a comme toujours été la norme. Mais quand tu regardes ça d'un point de vue, moi j'ai envie de comprendre pourquoi il y a 5 millions de messages dans ma queue que je ne m'attendais pas à avoir. En fait, il n'y a rien que tu peux faire. Autre que scaler tes les consumers de cette queue-là passent à travers les 5 millions complets et après coup, ils sont comme, ah, c'était ça les 5 millions. Donc, si tu ne veux pas les process, les 5 millions en ta queue, basically, out of luck. Donc, il y a certaines de ces choses-là.

Bruno — Parce que l'idée, du coup, sur le fait que si tu récites un peu comme sur du... Désolé, je perds mes mots. Comme dans la physique quantique, si tu commences à garder un élément, tu changes son état. L'idée, c'était de se dire que ton message dans ta queue, il peut être pris que par un seul receveur. Et donc si tu le lis, t'es considéré comme le receveur, c'est ça, et il disparaît pour éviter qu'on le rejoue plusieurs fois ou ce genre de choses.

Alexandre — Oui, 100%. Mais ça, c'est, une décision qui a été prise, pour les enjeux techniques de consommer la queue en tant que telle. Mais il n'y a pas de raison fondamentale pourquoi c'est le cas. Dans le sens que tu peux avoir deux types de « read ». Tu peux avoir un « read » qui acquire luck et tu peux avoir un « read » qui fait juste visualiser c'est quoi le message qui est dans la queue. Et un n'empêche pas l'autre. Je pense que c'est juste que les attentes et le paradigme par rapport à comment ces systèmes-là fonctionnent a juste comme pas vraiment été remis en question, en fait. Donc, si tu savais le nombre de conversations que j'ai eu avec des ingénieurs qui, à toutes les fois, ont, besoin de régler des problèmes lors d'aide leur Q, que c'est juste l'enfer à gérer. Donc dans le fond peut-être pour faire une petite parenthèse associée à ça, règle générale dans des message bus quand il y a une erreur de processing d'un message dans le fond, donc tu veux passer au prochain message mais tu n'es pas capable. De traiter un message peut-être parce que la data n'est pas dans le payload qui est attendu peut-être qu'il y a un problème sur le serveur ou peu importe, la solution de facto dans l'industrie c'est de mettre ce message dans une autre queue qu'on appelle un dead letter queue mais qui à toute fin pratique est juste un autre queue auquel cas ce que tu fais c'est que tu fais juste empiler les erreurs dans un autre queue que tu peux pas savoir ce qui est dans la queue, et toutes les erreurs peu importe c'est quoi la nature de l'erreur se ramassent dans la même queue, Donc là, inévitablement, si tu as un gros problème, ce que tu te ramasses, c'est avec des dead letter queues qui ont 5 millions, 10 millions, 100 millions de messages dedans, tu sais pas c'est quoi, tu sais pas si ils sont tous là pour les mêmes raisons, tu sais pas ce qui est important, tu sais pas ce qui est pas important. Il n'y a aucune façon de prioriser ce que tu vas consommer là-dedans donc si tu essaies de. Dans le fond de régler le problème puis de consommer cette Deadly RQ là, tu te ramasses d'être obligé de passer à travers l'acquis au complet, même s'il y a seulement 20% des messages que tu avais l'intention de rejouer, etc, donc il y a tout ce genre de truc là que je pense qui est comme pris pour acquis, puis de la même façon qu'on pourrait faire plein de parallèles par rapport à comment les CDN fonctionnaient avant Cloudflare puis avant Vercel puis les API Gateway etc donc je pense que c'est plus que il n'y a pas eu cette espèce de modernisation-là de dire on va s'arrêter puis on va remettre en question certaines de ces décisions-là qui ont été prises, puis on va on va redesigner le système de façon à ce qu'on prend en considération les vrais problèmes que le développeur va avoir d'un point de vue comme opérationnel, avec ces outils-là donc, c'est quelque chose sur quoi j'ai développé de fortes opinions avec le temps parce que je pense qu'il y a beaucoup de ces choses-là qui sont un peu comme devenues, c'est comme ça qu'on fait les choses sans vraiment avoir pris le temps de se poser les questions de comment ça fait-tu vraiment du sens ou non donc c'est ça.

Bruno — Et du coup quand tu commences à considérer un Stripe ou ce genre de service, ou de Twilio alors pour ceux qui ne savent pas Twilio c'est un service qui permet d'enverrer des messages à tes clients sur différentes plateformes c'est peut-être aussi bien du SMS, du mail ou ce genre de choses Stripe c'est une plateforme de paiement, Si tu commences à considérer un Twilio ou un Stripe comme des services de ton environnement et que donc tous les messages doivent être traités comme un event, au sein de ton environnement, comme tu le disais tout à l'heure, en fait, tu ne maîtrises pas l'envoyeur, que ce soit en termes de volume, en termes de format ou ce genre de choses. Est-ce que ça veut dire que ça t'oblige à oublier toutes les règles que tu pouvais avoir sur ton message bus que tu avais en interne en disant, en fait, je peux recevoir tout et n'importe quoi à n'importe quel moment, dans n'importe quel volume, donc je peux mettre, plus aucune règle, plus aucune alerte, plus aucune restriction? Ou est-ce que du coup, c'est-à-dire qu'il faut, quoi qu'il arrive, les refiltrer avant de pouvoir les réintégrer dans ton bus interne?

Alexandre — Oui, je pense qu'inévitablement, tu te ramasses à être obligé de faire un certain, pre-processing sur ces événements-là. Puis en fait. Les critères à quels il faut que tu penses, c'est autant les critères de ton propre service bus, message bus qui t'utilises, mais aussi celui avec qui tu fais l'intégration. Parce qu'à toute fin pratique, quand on pense à Stripe, par exemple, Stripe ont leur propre message bus de leur côté qui envoie les messages puis tous les enjeux que tu as, ils les ont aussi. Juste à l'inverse. Donc, ce que ça veut dire, c'est que le délai, par exemple, si tu penses à un webhook, ton intention, c'est de le traiter rapidement, peut-être parce que ça a un impact important sur l'expérience de ton utilisateur, par exemple. Et que ça prend plus que 30 secondes, c'est quelque chose que l'utilisateur va en vivre les conséquences. Par exemple, j'ai un exemple. Un de nos clients fait des intégrations avec des Uber Eats et tout ça. C'est une compagnie française d'ailleurs. Puis eux, ils envoient les commandes en restaurant pour que la commande soit envoyée au client. Donc ici, eux, leur webhook, ils ne reçoivent pas. En fait, pour chaque seconde qui passe, c'est une seconde de plus que le repas ne sera pas chez le client. Donc si on prend cet exemple-là le délai en fait peut venir de deux places il peut venir du côté de Uber dans ce cas-ci ou Uber eux-mêmes de leur côté peut avoir un délai, et il peut venir de ta propre message queue à toi donc une fois que Uber te l'a envoyé est-ce que toi tu as la capacité de gérer tous les messages que Uber, t'a envoyé donc et de la même façon aussi Uber va avoir leur retry tu vas avoir ton retry sur ta propre message bus etc donc je pense que il faut que. Quand tu penses, dans le fond, à vraiment ton end-to-end, de ta gestion d'événements, tu prends en considération autant les critères de ta propre message queue que les critères de ton sender. Puis l'affaire évidemment qui est particulière, c'est que chaque sender va avoir ses propres critères en termes de retry, en termes de uptime, en termes de garantie aussi, de livraison, en termes de ordering, ce genre de truc-là.

Bruno — Mais alors, si je fais un prétraitement de tous les événements qui arrivent de tous mes fournisseurs et vendeurs externes. Au final, je me retrouve à avoir une queue supplémentaire de pré-traitement. J'ai une queue devant mon système de pré-traitement avant d'ingérer dans ma queue interne.

Alexandre — Oui, donc, règle générale, l'idée, c'est de dire ton pré-traitement doit être, un, très efficace et, deux, tu peux me dire le mot en français, le decoupled, indépendant. Ton système de traitement, en fait, doit être découplé du reste de ton infrastructure. Donc, c'est l'approche qu'on recommande parce qu'en fait, si tu veux éviter d'avoir plusieurs niveaux de queuing, ce qui est souhaitable, parce que pour chacun, après ça, tu as tes considérations de délai, de backpressure et tout ça pour chaque, l'idée, c'est de dire, OK, ton pré-traitement, tu dois le construire de la façon la plus efficace que tu es capable, de façon à ce que ce soit scalable et que ça ne cause pas, qu'il n'y ait pas de dépendance sur, par exemple, ta DB ou sur le nombre de connexions ouvertes sur la DB ou des trucs comme ça. Donc, souvent, on va voir les gens, par exemple, implémenter des systèmes de caching que les systèmes de prêt-têtement vont utiliser. Donc, par exemple, si je prends mon exemple plutôt de, je reçois un webhook, je vais vérifier que c'est pour un client actif chez nous qui a un abonnement. Tu peux avoir une cache qui va être, qui va être populée de façon asynchrone, de ta base que le système de prêt-têtement va vérifier pour voir si ces clients-là est effectivement un client dans un système, etc. Donc, c'est souvent ce qu'on va voir. Donc, donc tu as ton pré-traitement qui envoie dans ta queue, puis après ça, à partir de ta queue, tu fais ton processing, avec tes services.

Bruno — Alors, il y a un mot que tu as évoqué plusieurs fois, que j'aimerais bien creuser un peu, tu as parlé de retry. Pour moi, le retry, c'est un truc où on se dit, c'est évident, en fait, il faut pouvoir rejouer une action si jamais il y a eu un bug ou un truc, mais en fait, pour moi, c'est comme, le undo-redo ou le annuler-refaire sur un logiciel, c'est-à-dire que annuler une action ça paraît simple mais quand tu commences à creuser de te dire comment je fais pour annuler l'action d'un utilisateur en fait c'est en fonction de ce qui a été changé enfin c'est peut-être tout un tas de tannés, et le retry c'est pareil parce qu'en fait quand tu fais un retry il faut que tu saches, Quelles opérations ont déjà été effectuées que tu ne veux pas refaire et reprendre là où tu as arrêté ? Donc quand tu commences à avoir, comme tu le disais, ton vendor qui peut lui aussi faire des retries, parce qu'il considère, qu'en fait, peut-être le message, il ne sait pas s'il l'a envoyé, il ne sait pas s'il était reçu, ou il n'a pas reçu la confirmation à temps, tu peux t'entrer aussi avec des retries que tu ne déclenches pas toi-même. Comment est-ce que tu gères déjà cet enfer du retry dans une queue classique, et encore plus dans un contexte comme ça de vendeurs extérieurs qui t'envoient des retries sans que tu l'aies forcément demandé.

Alexandre — Oui, en fait, je pense que c'est... Premièrement, on ne peut pas parler de retry sans parler d'un sujet qui est absolument essentiel quand on parle d'Avenger in Architecture. Puis en fait, je vais essayer de t'en faire parvenir. En France, on a fait des petits stickers « I love in the potency ». Donc, in the potency, c'est vraiment un concept quand on parle de retry, mais quand on parle d'Avenger in Architecture qui est incontournable. Puis en fait, c'est l'idée de ce que tu disais que si on refait une action en fait refaire une action a le même résultat, auquel cas dans un système non seulement oui il y a l'enjeu des retries mais il y a aussi en fait l'enjeu que n'importe quel événement tu peux le recevoir plus qu'une fois, autant de ton vendor que de ta propre message queue donc ça on appelle ça en fait le least once delivery guarantee donc dans tous les systèmes de message queue, tu dois choisir ta garantie entre at most once ou at least once règle générale, les systèmes utilisent at least once, donc ce que ça veut dire c'est que même sans retry il y a des bonnes chances que tu reçoives le même événement plus qu'une fois. Auquel cas ton système doit être bâti pour pour prendre ça en compte, et spécifiquement la raison pour laquelle je pense que c'est important de bien comprendre le concept d'indépendance c'est que oui tu as l'indépendance sur ton opération en tant que telle ou en fait sur le fait de recevoir ton message mais souvent ton application va faire plusieurs opérations. Peut-être qu'il va envoyer un courriel, il va updater la base de données, il va changer quelque chose dans un système externe, etc. Et chacune de ces opérations-là, en fait, doivent être independent individuellement. Parce que dans le fond, si, par exemple, tu commences le processing de ton événement, tu envoies le courriel, tu updates ta DB, à ce moment-là, problème de mémoire sur le serveur, le serveur meurt. Right ? À ce moment-là, la troisième opération que tu avais dans ta séquence, elle n'aura pas été faite. Et par le moment que l'événement est rejoué, en fait, tu dois être capable de dire l'opération 1, soit je l'ai déjà faite ou je vais être capable de la refaire sans conséquence. L'opération 2, même chose. Et la troisième, ah non, celle-là, je ne l'ai pas faite, je vais la refaire. Donc il y a cette espèce de contexte là que chacune des dépendances en fait dans la chaîne de OVD indépendant, c'est pas juste. La réception de l'événement en tant que tel il y a plusieurs stratégies, puis on peut en parler pendant des heures, les stratégies de comment gérer l'indépendance, dans certains cas c'est assez simple par exemple si tu fais une update dans la base de données, tu fais un upsert, avec une condition de date par exemple, puis ça se fait assez naturellement, dans d'autres scénario, c'est beaucoup plus compliqué. Juste pour donner un exemple, nous, dans notre système, dans le fond, tous les ID qu'on génère, c'est des ID qui sont pas random. En fait, ils sont random, mais ils sont cédés à partir du data qui est dans l'événement. Donc, ça veut dire que toutes les fois qu'on gère l'événement, pour cet événement-là spécifique, on va toujours générer toutes les mêmes ID pour tous les entités qu'on va créer en relation avec cet événement-là. Auquel cas, et donc, on fait jamais de create dans notre base de données, on fait tout le temps des upserts. Donc, c'est toujours « create or update », basé sur ces IDs-là qui sont dérivés, dans le fond, de data qu'on se sait qui est immutable dans notre événement. Donc, souvent, les producers de Webhook vont inclure un ID dans le data auquel tu peux t'affier, dans le fond, pour savoir que cet événement-là est une entité unique.

Bruno — Et que ça t'est lui qui fait. Ça veut dire que ça te permet de t'assurer que, si tu as un retry qui arrive, tu sais qu'en fait c'est un event que tu as potentiellement déjà processé, mais donc il faut que tu aies enregistré quelque part que tel ID a été processé et que ça allait jusqu'au bout.

Alexandre — Oui, exactement. Soit savoir que cette idée-là a été déjà, processée, ou nous, l'approche qu'on a tendance à faire, c'est dire que chacune des opérations qu'on va faire vont dériver de quelque chose d'unique, auquel cas, même si on fait l'opération deux fois, il n'y aura pas de conséquences, il n'y aura pas de changements. Donc il existe toutes sortes d'approches dépendamment de quel genre de système t'essayes d'intégrer avec c'est, quelque chose qui est quand même assez documenté c'est juste que c'est un enjeu, que tu vois beaucoup moins dans tout ce qui est synchrone donc qui tendance à être moins, bien compris ou moins maîtrisé mais même souvent dans une question d'entrevue quand j'interviewe des ingénieurs c'est de m'expliquer la différence, entre un post request puis un put request en HTTP. Et quand tu te penches vraiment sur la distinction, souvent les gens vont me dire « Ah, mais y'en a un que c'est pour créer puis l'autre c'est pour faire une update. » Quand tu te penches vraiment sur la définition, en fait, c'est le fait que le post n'est pas indépendant puis le put est indépendant. Donc, l'idée de dire qu'à chaque fois que tu fais un put, tu vas avoir exactement le même outcome parce que c'est une opération qui est naturellement indépendant. Donc, c'est comme cette nuance-là, elle existe en général dans le développement. N'existe pas juste dans le contexte d'Avenger and Architecture mais je pense que dans l'Avenger and Architecture c'est juste incontournable hum.

Bruno — Hyper intéressant. Écoute, on prend ce bout d'information, de distinction entre post et put, parce que je pense qu'on est nombreux à avoir une limite, une distinction un peu floue. Donc là, moi, tu nous as posé les bases. Il y en a un qui est inimpotent et le post qui l'est pas. Merci beaucoup de ça. Quand on parle aussi de ces notions de volumétrie, tu nous expliquais, d'ailleurs, tu parles le cas d'avoir un fournisseur qui est down pendant 30 minutes, et puis au bout de 30 minutes, il décide de t'envoyer tous les events qui t'as pas envoyés pendant 30 minutes, ce qui peut faire effectivement un peu mal. Ça englobe de manière un peu plus globale peut-être aussi des notions de sécurité parce que ce genre d'événement, ça peut devenir une DDoS pour beaucoup de gens. Comment est-ce qu'on gère aussi la notion de sécurité vis-à-vis de ces webhooks ? Parce que du coup, tu peux avoir quelqu'un qui vient de polluer ta message queue et potentiellement te flinguer ton système.

Alexandre — Ouais, absolument. Puis en fait, l'allusion que tu fais au DDoS, c'est une allusion importante que j'entends beaucoup en fait quand je parle avec les équipes dans ces grosses compagnies-là. Donc justement des conversations avec les équipes de Webbook chez Stripe, chez GitHub, chez Shopify, chez Twilio. Puis c'est tout quelque chose en fait qu'ils sont assez conscients d'eux, qu'en fait ils DDoS leur client. Donc c'est un enjeu comme connu si tu veux. Puis je pense que la réponse par rapport à ça c'est de dire bon nous on va mettre des timeouts assez agressifs sur les requêtes qu'on va faire, donc par exemple en cas de Twilio je pense qu'ils donnent 3 secondes si je ne me trompe pas, ou peut-être 2 secondes, pour retourner une réponse, puis la raison pourquoi ils font ça en fait c'est pour se protéger eux-mêmes, parce que si DDOS, ton serveur répond plus et puis ils sont obligés d'attendre 15, 20, 30, 50 secondes pour chacune des requêtes, ça va créer des problèmes de performance de leur côté, donc, je vais juste rapidement sauter, sur ce truc-là de DDoS qui est tout à fait vrai. », Après ça, c'est vrai qu'il y a aussi un enjeu de sécurité, pas juste au niveau du volume, mais aussi au niveau d'un attaquant, en fait, parce que ce URL-là, dans le fond, que tu vas donner pour envoyer les requêtes HTTP, c'est un URL qui est à toute fin pratique et publique. Et ce qui est particulier avec les webhooks par rapport à des requêtes HTTP et API, c'est que le vendeur par exemple t'appelles Stripe, si t'appelles Stripe avec un API key qui est pas valide et tout ça, ils vont dire non, 401 unontenticated, il te faut une clé d'API valide dans le cas des webhooks, la responsabilité en fait est mise sur le consommateur de ces événements-là. Donc, quand on registre un URL, pour continuer notre exemple de Twilio, Twilio vont signer avec un secret la requête. Donc, on va étudier un hash des bytes de la requête HTTP avec un secret que eux te fournissent. Auquel cas, c'est ta responsabilité en tant que consommateur de vérifier cette signature-là. Et Twilio, bon il y en a certains on voit toutes sortes de choses parce que tout le monde fait un peu ça à sa façon donc il y en a certains qui essayent de vérifier que tu vérifies en fait en envoyant des fausses signatures mais règle générale je peux pas dire que c'est une pratique qui est très commune donc règle générale, le vendeur doit te faire confiance puis assumer que tu le fais correctement, ce qui je peux te dire de façon pratico-pratique est pas du tout toujours le cas donc. Il y en a beaucoup qui sautent cette étape-là Ce qui, à toute fin pratique, ouvre ton API pour être appelé par n'importe qui à toute fin pratique. Donc, les signatures, je dirais, c'est un peu ce qui s'est développé, pas comme un standard, mais plus comme ce qu'on voit de façon plus commune. Après ça, il y en a qui vont utiliser différents algorithmes, qui vont utiliser différents types d'encoding, qui vont avoir différentes attentes par rapport à ce qui compose la signature. Il y en a qui vont inclure des timestamps, il y en a qui ne le feront pas, etc. Juste pour donner une idée avec CookDeck nous on essaie de couvrir comme le plus large. Le plus large qu'on peut en termes de support pour ces mécanismes de sécurité, on a plusieurs centaines à ce point-ci qui sont implémentées et on en a de toute forme donc, de temps en temps on essaie toujours de trouver c'est quel le plus obscur qu'on est capable de temps en temps un utilisateur va nous amener une nouvelle une nouvelle approche qu'on n'a jamais vraiment vue, avant puis je pense que c'est important quand même de souligner aussi qu'il y a eu des efforts de standardiser en fait l'approche, et bon après ça c'est sûr que c'est très difficile de faire des standards à ce point-ci parce qu'il y a des gros problèmes de packwork compatibility et tout ça donc pour un vendeur de dire je vais changer la façon de faire une signature si finalement ça a un impact sur littéralement tout le monde qui utilise leur webhook, donc c'est très très dur de revenir en arrière mais on voit certains standards se développer avec le temps autour de justement des SHA-256 signatures, qui sont vraiment comme les plus communes maintenant.

Bruno — Oui parce que j'imagine qu'effectivement Stripe va pas changer sa manière de faire, du jour au lendemain sans prévenir personne parce que vu le nombre de gens qui ça concerne ce serait un peu compliqué pour eux de faire ça mais comme tu disais tout à l'heure en fait comme tu maîtrises pas ton vendor t'es pas à l'abri d'avoir quelqu'un. Tu nous expliques toutes ces règles que tu as à faire pour vérifier que le webbook que tu reçois c'est le bon expéditeur et qu'il faut le traiter, s'il faut le traiter ou pas, mais du coup c'est à dire que si demain tu as un vendor qui change sa manière de faire d'un coup tu as tous les webbooks que tu reçois et que tu fais le temps que tu remets à jour, ta règle en fait.

Alexandre — Oui mais en fait c'est pire que ça parce que tu as toujours aussi l'option de juste pas le vérifier donc tu vois comment l'incentive des fois peut être un peu nocif dans le sens où, en créant, ce besoin-là d'implémenter une signature custom qu'eux ont inventée, tu es vraiment en train d'encourager la personne à juste ne pas le faire parce qu'elle n'est pas obligée de le faire. Donc, je pense que c'est quelque chose qu'on voit que, dans le fond, plus les signatures sont obscures et custom, moins que les développeurs vont prendre la peine.

Bruno — Parce que du coup si tu vérifies pas ton webbook en fait t'as une porte ouverte sur toute ton architecture, ou tu peux avoir quelqu'un qui vient te défoncer tout ton système de manière quasiment légite parce qu'il faut pas croire que sous prétexte que tu donnes à personne ton URL de réception de webbook que personne va la trouver à un moment quoi.

Alexandre — Non, non, c'est ça, exactement. Puis on le voit des fois, il y a des gens qui font des tentatives de générer des URL comme semi-secrets avec des séquences, random dedans et tout ça, mais règle générale, je ne pense pas que c'est la bonne approche. Je pense que la bonne approche, c'est un, avoir les attentes envers ton vendeur qui fasse une implémentation responsable de signature et tout ça, et que toi, en tant que consommateur, après ça, tu la vérifies. Puis après tu vois nous par exemple chez UGDEC notre approche à ça c'est de dire regarde nous on va vérifier toutes les signatures qu'on reçoit de tous tes vendeurs on va prendre la peine d'implémenter chacune des implémentations custom qui existent, et après ça sur ton serveur à toi en fait la seule chose que tu as besoin de vérifier c'est la signature d'UGDEC en tant que telle donc, puis je pense que l'idée derrière ça c'est de dire bon on est capable de standardiser sans vraiment standardiser à toute fin pratique mais de, d'enlever cette complexité-là du développeur en tant que tel que le développeur, lui, peut juste vérifier la signature de GDAC pis move on. Pis à partir de ce moment-là, en tant qu'organisation, t'as la paix d'esprit en fait que, même en rachetant des nouveaux vendeurs avec des approches de sécurité obscures, que tu t'ouvres pas à cet enjeu-là de sécurité, que dans le fond, le développeur fera pas l'implémentation de la signature, etc.

Bruno — Et du coup, vous, vous pouvez aussi servir de buffer si jamais t'as un overflow, d'un coup, tu as un flux de notifications, tu peux du coup te mettre des buffers et donc vous absorbez une partie de la charge pour que derrière, on a parlé aussi beaucoup de ce cas là ouais.

Alexandre — En fait quand on tombe dans le DDOS, oui tout à fait, en fait pour, pas faire ça juste spécifiquement à OEDEC ce qu'on voit généralement dans l'industrie, c'est que le système que tu bâti pour recevoir ces webbux-là doit être capable de gérer la capacité puis doit être capable de gérer la capacité souvent ça a des implications de coûts soit en termes que, ton auto-scaling doit être vraiment agressif ou sinon ton baseline de concurrency doit être vraiment haut et sans compter juste le temps de engineering et d'effort qui est mis à bâtir ce système-là cette capacité-là. Donc, c'est sûr aussi qu'il y a un des avantages, par exemple, dans notre position, si on reçoit des webhooks pour des milliers de compagnies, qui ont des specs à divers moments. Donc, nous, en tant qu'infrastructure, on fait un peu de l'arbitrage à toute fin pratique entre dire individuellement, on n'a pas tous besoin de bâtir cette capacité-là. Nous, on va bâtir pour un modèle statistique de volume à travers tous les clients ou quelqu'un, on est capable de dire qu'on est capable de le faire de façon beaucoup plus efficace d'un point de vue de coût, parce qu'on n'a pas besoin d'avoir la responsabilité de chacun, dans le fond, d'avoir cette capacité-là. Donc, oui, 100% d'un point de vue gestion des DDoS, puis par rapport à. Être le buffer, en fait, à travers son système, j'aurais tendance à dire que c'est probablement la plus grande valeur ajoutée d'un système comme OCDEC, c'est d'être capable d'agir comme la queue, en fait, devant ton infrastructure. Donc, c'est quelque chose qui est très, très important pour nous, pour nos produits, pour nos clients etc, donc oui tout à fait.

Bruno — Ok alors on a parlé d'idempotence on a parlé d'un peu de sécurité des process d'ingestion de la gestion de ta queue des volumes, est-ce qu'il y a d'autres éléments de cette event-driven architecture qu'on n'aurait pas encore évoqué, alors j'imagine qu'il y en a plein mais un dernier peut-être avant de conclure.

Alexandre — Je pense qu'il y a un sujet qui me tient beaucoup à cœur. On a parlé un peu de l'histoire au début de la conversation des webhooks. Et j'aurais tendance à dire que dans les dix dernières années, il y a eu très peu de changements à ce niveau-là. C'était très statu quo par, rapport aux outils, aux façons de faire et tout ça. Puis on arrive vraiment dans une ère de changement il y a une ère de changement entre autres à cause des outils qui se développent comme les nôtres mais comme ceux d'autres personnes que j'ai nommées plus tôt, mais je pense aussi que la mentalité est en train d'évoluer donc ce que je veux dire, par là c'est par exemple Stripe qu'on a fait référence à plusieurs fois dans, l'application de Stripe maintenant quand tu vas inscrire un webbook c'est plus un webbook en fait qui est inscrit ils appellent ça un event destination, puis le webbook c'est la méthode de transport pour cet événement-là. Donc, ils sont en train de vraiment faire le changement puis la distinction de dire non, non, non, en fait, les webhooks, ça a toujours été des événements. Puis ce qu'on décrivait de webhook, c'est vraiment juste une méthodologie de transport. Et non seulement c'est une méthodologie de transport, mais c'est une méthodologie de transport qui n'est pas particulièrement efficace, qui n'est pas particulièrement secure puis qui n'est pas particulièrement scalable. Et si tu es Stripe et que tu envoies plusieurs milliards de webhooks par jour... Ces enjeux-là, en fait, sont des gros enjeux. Et donc, ce qu'on voit, là, j'ai mentionné Stripe, mais Stripe, pardon, Shopify fait la même chose, Twilio fait la même chose. Donc, les gros joueurs sont en train de changer cette définition-là, de dire, non, non, non, non, c'est pas des webhooks, c'est des events. On va vous donner l'option de le recevoir par webhook, mais de façon plus importante, on va aussi donner l'option de le recevoir directement sur votre message bus. Donc, dans le cas, par exemple, de Stripe, tu supportes AWS EventBridge, dans le gars de Shopify, tu supportes PubSub, pardon, GCP PubSub, AWS EventBridge, Twilio supporte Kinesis, bref. En ce moment, c'est tout dépareillé, tout le monde fait un peu ça à sa façon, la terminologie n'est pas standardisée, mais ce que tu vois vraiment, c'est que ce mouvement-là de dire, non, regarde, on va l'envoyer directement à ton message bus, on va utiliser le protocole, on va utiliser le système de sécurité et tout ça qui existe déjà sur ton message bus puis ça va être l'option idéale pour toi dans le fond de recevoir ces événements-là. Donc, on voit vraiment le mouvement dans cette direction-là. Puis, c'est quelque chose que j'encourage énormément. Mais évidemment, l'enjeu qui vient avec ça, c'est de dire, bon, moi, en tant que développeur, qui veux donner l'option à mes utilisateurs de recevoir les événements directement sur le message BushBus, c'est-à-dire que maintenant, il faut que, je développe mon système pour être compatible avec RabbitMQ, avec PubSub, avec SQS, avec Azure Event Grid et tout ça, tu sais. Donc, nous, un peu l'histoire dans laquelle on s'est embarqués il y a deux ans, c'est de créer une implémentation open source puis une référence, en fait, sur l'implémentation de comment faire ça avec tous les différents messagebuzz. Donc, aujourd'hui, Outpost, c'est le nom du projet, supporte une douzaine d'event destinations, comme on les appelle. Puis l'idée, c'est vraiment de dire, en tant que développeur, on devrait faire cette demande-là à nos vendeurs. On devrait prendre l'opportunité quand elle se présente avec les vendeurs avec elle, on travaille puis pousser l'industrie vraiment à adopter cette approche-là qui dans le fond est bénéfique pour tout le monde donc je pense qu'il y a quelque chose qui est très important sur le futur de où ça s'en vient, ça s'en va puis je pense qu'avec le temps, on va vraiment commencer à regarder les webhooks comme des events, comme du Avenger d'Architecture, puis le webhook en tant que tel va devenir un peu plus comme un mode de transport legacy si on veut là je suis peut-être en train d'être optimiste, ça risque de prendre un certain temps avant que ça s'actualise.

Bruno — Mais cela dit quand tu commences à avoir un acteur comme Stripe qui comme tu le dis on voit quand même des milliards d'événements chaque jour, quand tu as un acteur comme Stripe qui commence à s'emparer d'un sujet il y a quand même des chances que ça se démocratise un peu plus vite d'un coup.

Alexandre — Oui, 100%. J'espère qu'on joue notre part là-dedans. C'est l'intention. Mais oui, tout à fait.

Bruno — Est-ce que l'émergence des LLM aussi, des contextes très agentiques qui ont toujours des délais de réponse qui peuvent être un petit peu plus longs, on voit qu'il y a quand même aussi de plus en plus d'asynchrone qui se met en place dans tout ça. Est-ce que ça a joué aussi dans cette mouvance vers les events et l'explosion des webbooks ou pas tant que ça aujourd'hui ?

Alexandre — Oui, puis c'est quelque chose que j'ai fait allusion un peu plus tôt, dans le sens qu'on voit de plus en plus de use case pool. J'ai donné l'exemple du customer support, par exemple, qui historiquement, c'était vraiment juste des agents. Pardon, quand je dis agents, je réalise que ça peut être mélangeant. Les humains qui allaient dans l'application. Maintenant, c'est les agents. Via les LLM qui commencent à utiliser, dans le fond, ces outils de support et tout ça. Donc oui, il y a ça. je pense pas que cette transition-là est complètement actualisée, en fait on est si on prend un pas de recul, notre expérience avec les LLM jusqu'à maintenant je pense qu'elle était beaucoup driven dans le fond par nous, qui va dans Cloud ou dans Codex ou peu importe, pis qui initie en fait la requête à l'agent de dire ok je veux que tu fasses ci ou je veux que tu fasses ça pis si tu regardes beaucoup d'outils aussi ils vont avoir des concepts de routine là donc de dire ok à tous les matins à 9h j'aimerais que tu fasses telle chose ou telle autre affaire, mais là maintenant Claude, hier Grock, Butt ont annoncé aussi leur support pour les webhooks, Codex aussi maintenant arraché le support pour les webhooks, donc ce qu'on voit c'est inévitablement à un certain point ça sera pas nous avec toute, notre chair à promener qui va aller écrire aux agents quoi faire tout le temps puis évidemment une grande quantité de ça va être en réponse à des événements externes dans le fond qui se passent dans les systèmes externes que ça soit évidemment ça a déjà commencé avec tout ce qui est le code avec GitHub. Qui spécifiquement eux voient qu'ils envoient énormément plus de webhooks qu'avant, mais je pense que ça va vraiment se propager avec tout ce qu'on utilise donc que ça soit un agent en réponse à un changement de météo du prix de bitcoin ou de ou d'un. Je ne sais pas, d'un vol d'avion qui dépore ou de peu importe. Donc, je pense que c'est inévitable qu'on s'en va dans une direction où nos systèmes vont réagir de plus en plus à ces événements-là. De la même façon aussi que tes propres agents, le output de ton agent, risque en forte partie d'être des événements à d'autres agents. Donc, c'est quelque chose à quoi on pense aussi dans le sens où si moi, je suis un agent puis mon output, c'est de dire « Hey, j'ai complété une action ou peu importe. » Mais après ça, c'est quoi cette chaîne? Est-ce qu'il y a un autre tiers passé, un utilisateur ou peu importe, qui est intéressé, dans cet événement-là? Ça me paraît à peu près inévitable que c'est la direction, dans laquelle on va aller. Donc, je suspecte que, oui, nos systèmes en ce moment s'envoient beaucoup de webhooks, mais les agents vont s'envoyer des webhooks à la pelleté aussi. Donc, je pense à la direction dans laquelle on s'en va.

Bruno — OK. Canon. Merci beaucoup Alexandre pour toute cette conversation. J'aurais deux dernières questions pour toi qui sont les questions rituelles de ce podcast. La première c'est est-ce qu'il y a un ou plusieurs contenus que tu souhaiterais partager avec les auditoristes ?

Alexandre — Oui, je réalise qu'Avenger in Architecture, ce n'est pas tout le temps un sujet qui est maîtrisé par tout le monde. Il y a quelqu'un que j'admire beaucoup qui s'appelle David Boyne, qui est anciennement chez AWS, qui travaille justement sur EventBridge, SQS et tout ça, qui fait une série d'illustrations, si on veut, à but éducatif sur l'Avenger in Architecture et qui vraiment couvre tous les sujets possibles et imaginables. Le nom ça s'appelle EDA Visuals donc c'est EDA Visuals on s'est mis de le Google je pense parce qu'il y a comme son nom dans l'URL donc ça s'appelle mal, mais vraiment c'est comme une ressource je pense incontournable pour en apprendre plus sur l'Avengering Architecture les différents patterns, les best practices et tout ça donc je voulais être sûr de le mentionner, c'est ça et je pense que c'est pertinent avec la conversation qu'on vient d'avoir.

Bruno — On mettra un lien, bien évidemment, en description. Et dernière question qui est de loin la plus importante de ce podcast. Alexandre, est-ce que tu es plutôt espace ou tabulation ?

Alexandre — Je t'avoue que j'ai tellement peu d'opinion sur le sujet que je suis obligé d'aller voir. En fait, j'ai ouvert mon éditeur. Avant, je savais que tu allais me poser cette question-là. Donc, j'ai ouvert mon éditeur et j'ai juste comme essayé instinctivement de voir ce que je faisais. Je fais des tables. Donc, mais à quel point je ne pense pas du tout. C'est juste un automatisme pour moi.

Bruno — C'est devenu un réflexe, je vois.

Alexandre — Mais bon, le réflexe, c'est des tables.

Bruno — Très bien. Merci beaucoup, Alexandre.

Alexandre — Ça fait plaisir. Merci beaucoup, Attan.

Bruno — Et merci à tous d'avoir suivi cet épisode. Voilà, je trouve que c'était toujours intéressant d'aller creuser des sujets qui paraissent simples mais qui en fait sont beaucoup plus compliqués, que ce qu'on imagine et qui permet en plus d'ouvrir tout ce monde de l'event-driven architecture qui est peut-être des sujets qu'on évoque de manière générale avec les microservices mais qu'on ouvre comme ça avec tout ça et puis comme le disait en plus Alexandre, on voit que c'est quelque chose qui est en train de se structurer, de se normaliser donc il y a une vraie tendance de la manière que nos téléphones maintenant reçoivent beaucoup plus de notifications push plutôt que d'aller chercher des choses, en fait nos. Infrastructures suivent le même chemin on reçoit des notifications push plutôt que d'aller chercher de l'information si jamais il y a eu des mises à jour. Moi de mon côté comme toujours je vous remercie de partager ce podcast autour de vous bien évidemment abonnez-vous sur toute la plateforme sur laquelle vous pouvez être parce que c'est aussi un moyen de recevoir du coup un event dès qu'il y a un nouvel épisode qui est disponible n'hésitez pas aussi à mettre un commentaire 5 étoiles ça déclenchera un événement de mon côté à moi, comme quoi je recevrai un commentaire et ça je vous en remercie je vous souhaite une très bonne fin de semaine Je vous dis à la semaine prochaine et d'ici là, codez bien.