Edge computing : l'avenir de la webperf, de l'analytics et des tests A/B

0:00 Merci Noémie. Bonjour à tous. Je suis Sam Ramachandra, située du Parisien, et je suis ravie d'animer ce meet-up en présence d'Antoine et Sacha. Et pour ceux qui me connaissent un peu sur LinkedIn, et je vois qu'il y a aussi Lucas de Libération qui est connecté et qui me connaît un peu, la réduction de temps de latence et le travail sur la webperf, c'est vraiment au cœur de mes problématiques. Et je pense qu'elle est aussi au cœur des problématiques de tous ceux qui travaillent dans la tech, sur des sites à fort trafic. Donc aujourd'hui, nous allons parler d'Edge Computing et comment cette nouvelle pratique va permettre d'accélérer la WebPerf, améliorer l'Analytics et les A-B-Tests. Ce meet-up va se dérouler en deux temps, puis nous aurons donc une partie questions-réponses, comme vous l'a indiqué Noémie. N'hésitez pas à indiquer vos questions durant la presse. Je vais, je pense, sélectionner à la fin et je ne sais pas si on peut voter ou non sur des questions pour avoir une pondération, mais en fonction, j'indiquerai vos questions à Sacha et Antoine. Du coup, dans un premier temps, nous avons Antoine Brossault, qui est CTO Sales Engineer chez Fasli, qui est une solution de CDN, mais pas que.

1:06 Et Antoine va nous parler justement de ces produits et faire un focus sur l'AB testing, sur lequel je pense qu'on se casse tous les dents. À toi de jouer, Antoine. Oui, donc je vais partager mon écran, je vais me présenter. On va parler aujourd'hui de l'edge computing, comme l'a dit Sacha. Je pense que ce n'est pas forcément un concept qui est clair pour tout le monde et qui le sera forcément plus après. après cette présentation. Donc, pour me présenter, moi, c'est Antoine. J'ai mis plusieurs choses qui me définissent en dessous de ma photo de profil. Je suis sales engineer, développeur, et j'ai beaucoup travaillé sur le sujet de web performance, notamment chez Google. Pendant six ans chez Google, j'ai accompagné les plus grosses marques que vous connaissez, peut-être sûrement certains d'entre vous, sur des sujets web perf. J'ai vu beaucoup de choses, notamment au sujet de l'AB testing chez beaucoup de grands acteurs.

2:08 Donc, j'ai beaucoup à dire sur ce sujet. Et l'idée de ce talk, ça va être de voir un petit peu comment ces problématiques d'AB testing que vous avez tous en tête, mais qu'on va se rappeler, peuvent être résolues par l'Edge Computing. Après ma présentation, je passerai la main à Sacha, aussi qui vous donnera sa perspective et son point de vue sur ce sujet. Donc, on est parti. La présentation que j'ai faite, c'est d'abord une mise en situation. Mais la première chose qu'on peut dire, c'est que je pense qu'on a été quand même assez loin avec les tags JavaScript, les solutions tiers qu'on a ajoutées à nos sites. Et la question, c'est peut-être qu'on est allé un petit peu trop loin et que la WebPerf aujourd'hui, votre WebPerf, elle souffre grandement. de ces solutions tiers qu'on a fini par empiler, que les gens du marketing ont ajouté à nos sites. Donc, mise en situation.

3:11 Vous êtes une entreprise, une application globale. Vous avez la chance d'avoir du trafic mondial avec un business qui a pour objectif de scaler. Et comme tout le monde, vous avez plusieurs objectifs. Premier objectif, de créer une expérience rapide pour tous les utilisateurs, peu importe où ils sont dans le monde. Que votre produit soit ce qu'on appelle snappy, très responsive, mais pas dans le sens... Responsive design, mais quand on l'utilise, il répond vite. Et on a aussi comme objectif, vous avez comme objectif de convertir les visiteurs en acheteurs ou en abonnés. Et bien sûr, on va faire tout ça en gardant des coûts les plus réduits pour avoir un retour sur investissement le plus élevé possible. Ok? Donc, dans ce cas-là, on est cette boîte mondiale. On va avoir, puisqu'on travaille sur le trafic mondial, on va avoir besoin d'un CDN.

4:18 Et puisqu'on est aussi... Des gens qui sont data-driven, donc on base nos décisions sur de la donnée, on a envie d'améliorer notre interface, on a envie d'améliorer améliorer notre produit, on va le faire basé sur des chiffres et on va notamment faire de l'A-B testing. Donc souvent, et c'est quelque chose que j'ai quand même beaucoup vu dans mes années web performance, la partie A-B testing sur les applications web, c'est géré au niveau du front. Ok? Puisque, en fait, avec des solutions d'AB testing front-end, on va pouvoir tester si... de manière assez caricaturale, est-ce que le bouton vert convertit plus que le bouton bleu ? Est-ce que cette présentation produit est meilleure qu'une autre, etc. Et qui a la responsabilité de ces outils d'AB testing? C'est plutôt les équipes produits, c'est plutôt les équipes marketing que les équipes tech.

5:23 Et par définition, les équipes produits marketing ne sont pas des gens qui codent, ce ne sont pas des gens qui ont les mains dans le code. Donc, en fait, on leur a mis à disposition des outils d'AB testing complètement en front, qui sont aussi simples à installer que de mettre un tag JavaScript sur une page. Mais ce qui se passe, et ce que j'ai vu quand même très souvent, c'est que lorsqu'on injecte ce genre de solution en front sur nos pages, on va avoir des problèmes de performance. Donc ici, ce que j'ai mis dans cette slide, ce n'est pas rare d'avoir quelqu'un qui monitore la partie web performance, l'expert web performance ou même les équipes qui s'occupent du SEO, qui font remonter des problématiques de performance aux équipes marketing en disant, Là, les gens du market vous font tourner beaucoup de tests, il y a quelque chose qui ne va pas, notre performance en fait.

6:30 a été dégradé. Et quelle est la réponse des équipes marketing? Oui, mais cette solution d'AB testing qu'on a installée, Nous, on a dit que ça n'allait avoir aucun impact au niveau de la web perf. Parce qu'on nous a dit que le script était asynchrone et qu'il n'y a aucun impact sur la performance. Donc, souvent, les équipes marketing ne comprennent pas bien, en fait, pourquoi les équipes tech reviennent vers eux avec cette problématique de web performance. Et moi, c'est ce que j'ai vu quand même souvent quand je faisais des audits de sites. Si vous prenez WebPageTest, Vous faites un test vanilla sans rien bloquer et ensuite vous faites le même test en bloquant tous les sort parties. Vous pouvez avoir votre page qui génère 80 sur 100 sur un score Lighthouse sans les sort parties et la même page avec les sort parties qui n'a plus qu'un score de 50%. Donc les sort parties peuvent avoir un réel impact sur la web performance.

7:37 Donc, on est aujourd'hui dans un monde où toute la logique, en fait, une bonne partie de la logique front-end et ses solutions tiers sont uniquement gérées en front. Et on a beaucoup dit, ou ces solutions ont en tout cas beaucoup dit, ou trop dit, que ça n'avait aucun impact. Au niveau de la web perf. Parce que les équipes marketing, elles vont vous dire, un site rapide, c'est quoi? C'est un site qui charge visuellement rapidement. Mais depuis 5, 6, presque même 8 ans maintenant, il faut aller au-delà de ce concept d'un site rapide, c'est juste un site qui charge de manière rapide visuellement. On a des métriques visuelles, vous connaissez sûrement. Le first content full paint, le largest content full paint, le speed index, qui sont en fait des mesures qui vont mesurer combien de temps il faut attendre pour que les éléments s'affichent à l'écran.

8:42 Donc ça, c'est un bon début quand on commence un sujet web performance. Par exemple, le first content full paint, combien de temps il faut attendre pour avoir quelque chose d'utile qui s'affiche à l'écran? Ça, c'est un bon début, mais il ne faut pas se limiter à ça, puisque aujourd'hui, surtout quand on parle d'applications web, j'imagine que vous êtes nombreux, en fait, où aujourd'hui, on est au-delà d'un simple site Internet, mais on est sur une web app, on est sur... Des applications avec du Next, avec du React, du Vue, etc. Où le JavaScript, l'exécution de la vitesse du JavaScript est primordiale pour créer une expérience rapide. Donc, il faut aller au-delà. De la simple mesure visuelle, il faut aller regarder aussi ce qui se passe au niveau au niveau du JavaScript. Au niveau du JavaScript, pour mesurer la performance, on va avoir tout un tas de métriques. Une métrique qui est intéressante, c'est le time to interactive. Combien de temps ont été nécessaires pour avoir une fenêtre d'exécution?

9:49 De nos scripts sur le main thread. Donc, une métrique aussi qui est intéressante, c'est le total blocking time. C'est toutes les millisecondes, en fait, qui sont sur des tâches JavaScript, tout ce qui va être supérieur à 50 millisecondes. Pourquoi en fait on va prendre ce overhead et l'ajouter à un compteur qu'on appelle le total blocking time? Puisque comme le JavaScript est un... Un langage qui est monothreadé. Si vous essayez par exemple de déplier un menu pendant qu'il y a une longue tâche JavaScript qui s'exécute, vous pouvez cliquer autant de fois que vous voulez. Il va falloir attendre que la tâche est finie de s'exécuter pour pouvoir par exemple déplier le menu. Ce qui va créer en fait une expérience assez laggy. Donc, ce que j'ai essayé de vous expliquer dans ces premières slides, c'est que les outils d'AB testing, ou même les outils sur partie en général,

10:59 certes, ils peuvent avoir un impact peut-être négligeable sur la partie visuelle, mais il faut aller au-delà de ça et bien regarder en fait quel est l'impact sur... l'exécution du JavaScript et l'impact global sur votre application. Ok? Donc, c'est souvent le discours qui est servi aux équipes marketing. De toute façon, il n'y a aucun impact sur la web perf. Et quand on regarde un petit peu plus ce qui se passe au niveau de la trave, CPU, quand on analyse ce qui se passe sur le main thread, ce n'est pas rare. J'ai caché la marque de ce site, mais c'est un gros site français. Mais on voit en fait ce genre d'exécution. Donc ici, c'est les long tasks dont je vous ai parlé. Ici, on a forcément un drop en termes de FPS. Lorsqu'on exécute cette tâche. Ici, notre utilisateur peut cliquer autant de fois qu'il veut sur des éléments, ça ne va pas se déplier, ou en tout cas, ça va être une expérience très dégradée.

12:07 Un autre exemple, ça c'est un script tiers. Un outil d'AB testing. Encore une fois, j'ai caché le nom. L'idée, ce n'était pas de pinpointer un fournisseur, mais c'est vraiment quelque chose qui est très courant. Donc, les outils d'AB testing ont un vrai impact. Pourquoi je parle aussi beaucoup des outils d'AB testing en particulier, parce que ça c'est applicable à beaucoup d'outils third party, c'est que les outils d'AB testing peuvent faire des trucs de drogue. Par exemple, pour éviter un effet qu'on appelle le flickering, je pense que c'est quelque chose que vous connaissez tous, mais je vais le redéfinir rapidement. Donc, un outil d'AV testing a la possibilité d'injecter dans votre page un experiment. Et cette injection, elle se fait au niveau JavaScript. Et pour éviter un effet de clignotement où je vais sur une page, j'ai la page, le script JavaScript, le script d'AB testing se charge et du coup, réarrange ma page, j'ai un énorme effet de clignotement.

13:14 Les outils d'AB testing, ce qu'ils font, c'est qu'ils cachent le body de la page. Ce qui fait que là, ça va avoir un impact au côté visuel. Les outils d'AB testing aussi, pourquoi je les ai pris en grippe, mais en tout cas, je suis un peu critique, c'est qu'il y a aussi une mauvaise utilisation de ces outils. Par les équipes marketing. Plus d'une fois, je suis arrivé pour faire des audits et je leur disais, OK, cette bannière-là, pourquoi elle est injectée en JavaScript? Pourquoi elle ne fait pas partie du shell du site? Ah oui, mais parce qu'en fait, là, on est sur une promotion. Donc, les équipes marketing ont décidé de lancer une experiment JavaScript à 100% au lieu d'aller demander aux équipes dev d'implémenter, par exemple, une manière.

14:14 Donc, ce n'est pas rare de voir des outils d'AB testing qui sont utilisés pour patcher le site. Donc, on charge beaucoup, beaucoup de JavaScript pour des petits éléments. Une autre chose, un petit peu dingue aussi que j'ai vu avec des outils d'AB testing, c'est lorsqu'on a une single page application, on n'a pas tous les éléments dans le DOM. Okay. En tout cas, pas au chargement immédiat. Donc, on peut voir des outils d'AB testing qui font des 7 intervalles jusqu'à trouver l'élément dans la page pour ensuite exécuter l'experiment. Donc, encore une fois, c'est des tâches JavaScript qui tournent, qui tournent, qui tournent et qui vont avoir un impact. sur la performance, non pas cette fois visuelle, mais vraiment sur l'expérience globale, la réactivité de votre application. On a aussi des tests qui tournent, peu importe, sur mobile ou sur desktop.

15:16 On peut avoir des experiments qui sont uniquement sur desktop, mais un outil d'AB testing qui tourne sur mobile et sur desktop. Donc, maintenant que j'ai un petit peu peint cette situation de problèmes liés à des solutions d'AB testing et aussi des problèmes sur les serve parties, qu'est-ce qu'on peut faire? Quelles sont les solutions qu'on peut mettre en œuvre? Premièrement, On peut arrêter de faire de la BTS, mais comme je vous l'ai dit, si on est une entreprise, si on est une application mondiale et qu'on est data-driven, ce n'est pas ça qu'on va choisir. On peut aussi faire du chargement différencié de ce script en fonction du device. On pourrait avoir, et ça c'est le rêve de tout le monde qui est connecté à ce webinar, c'est que l'entreprise au global, que toutes les équipes aient

16:19 cette connaissance et cette culture de la web pair, que ce soit les équipes marketing, que ce soit les équipes produits. Mais ça, c'est quelque chose qui est très dur à implémenter. Ou alors, ça c'est un petit peu des vœux pieux ce que j'ai fait sur les trois premiers points, ou alors on pourrait faire peut-être de l'AB testing côté back-end. Mais faire de l'AB testing côté back-end, ça veut dire qu'on ne va pas pouvoir mettre grand-chose en cache puisqu'on va devoir exécuter une logique de notre côté. Ou alors, ce qu'on va pouvoir faire, c'est d'utiliser de l'edge computing. C'est maintenant que je vais vous parler de computing et que je vais vous expliquer en quoi ça peut être utile et en quoi c'est quand même une certaine révolution. Pour la gestion des scripts tiers. Donc, l'edge computing, et c'est ce qu'on fait chez Fastly, ce sont des serverless functions,

17:26 Et là, vous allez me dire, oui, mais des serverless functions, comme je connais déjà, comme AWS Lambda, comme ce qu'on peut faire chez GCP, chez Vercel, etc. Oui, mais la différence, c'est que nous, on n'a pas de call start. C'est qu'on va démarrer l'exécution de votre code en moyenne 35 microsecondes. qu'on va être capable de scaler de manière globale et instantanée. Je vais vous expliquer ça dans les prochaines slides. Si vous décidez de déployer une serverless function chez AWS avec Lambda, Vous allez choisir une région. C'est ce que j'ai mis ici. EU, donc Europe Ouest 2. Donc, vous allez vous retrouver en fait avec une logique qui est déployée uniquement en Europe, dans la région qu'on a définie. Si je souhaite faire la même chose avec Fastly, Donc d'utiliser une serverless function avec Fastly, je vais utiliser ça, Fastly Compute Publish, et vous voyez ici que je n'ai pas mis de point géographique.

18:36 Je n'ai pas décidé que j'allais le déployer dans une zone spécifique, parce que quand je fais Fastly Compute Publish, je vais pouvoir déployer une logique back-end, une partie de ma logique back-end, tout autour du monde, dans l'ensemble des pop, des point of presence de Fastly. On a plus d'une centaine dans le monde. La carte que j'ai faite n'est pas représentative des point of presence que l'on a. Donc, cette logique que l'on va écrire avec de l'edge computing, de faire notre logique backend déportée tout autour du monde, on va pouvoir l'écrire soit en JavaScript, soit en Rust, soit en Go, ou même avec d'autres langages, puisqu'on va utiliser ces langages pour compiler vers WebAssembly. La tech derrière ces serverless functions que l'on a chez H, c'est qu'on utilise le moteur V8 de Chrome. Et donc, du coup, on utilise WebAssembly pour exécuter ce code ultra rapidement.

19:40 Je vous montre ce que ça donne de, par exemple, vouloir créer de l'AB testing avec de l'edge computing. Dans la serverless function que je crée, c'est assez basique comme exemple, mais c'est vraiment pour vous donner une première idée. Ici, je l'ai écrit en écrit. en JavaScript, mais on peut avoir plus de performance avec du Rust, Sacha nous en parlera tout à l'heure. Mais ici, quand je tape par exemple ma homepage, je peux lui dire, OK, va chercher dans mon origine, va chercher sur mon serveur, une page, et ensuite je vais aller insérer mon expérience d'AB testing, je vais modifier ma page HTML en back et le renvoyer à l'utilisateur. Donc je vais faire quelque chose comme ça. Où j'ai mon utilisateur, ma fonction, ma serverless function dans le edge compute, soit JavaScript, soit du Rust, soit du Go.

20:53 Ici, je vais pouvoir faire toute une logique Donc CRUD, donc create, read, update, delete, puisque je vais aussi avoir accès à une base de données. Ici, je vais pouvoir faire une partie de ma logique, notamment ma logique de mon test AB, et le renvoyer à l'utilisateur. Et ça, sans mettre dans le mix ou de manière très ponctuelle mon origine. Donc, même au-delà de la partie A-B testing, ce que je pense que vous voyez de manière assez claire maintenant avec l'edge computing, c'est qu'on va pouvoir... créer notamment de la personnalisation, on va pouvoir en fait, au global, déporter la logique que l'on a au niveau de notre origine, mais à l'aide du network, à la périphérie du réseau. Je vous montre un autre exemple qui, ici, qui est un petit peu plus avancé, qui notamment prend en charge, qui fait des appels par une base de données, pour voir ce que ça donne.

21:58 Ici, pareil, quand je récupère ma page d'accueil, je peux par exemple faire une géolocalisation de l'adresse IP, si par exemple je souhaite faire une expérience, basé sur la localisation de l'utilisateur. Ensuite, ici, je vais pouvoir me connecter à une base de données qui est à l'aise du réseau, parce que ça n'aurait aucun sens d'être d'ici, d'appeler une base de données post-grès qui est à l'autre bout du monde. Non, je vais avoir une partie. Je vais pouvoir déporter une partie de ma base de données dans des centaines de points dans le monde, toujours à l'aide du réseau. Donc ici, par exemple, je récupère l'experiment que je souhaite faire tourner. Je récupère ma page et ensuite, ici, Je stitch le content. C'est-à-dire que je reconstruis ma page à l'aide du réseau et je renvoie cette...

23:00 Cette réponse. Donc, c'est vraiment l'idée de la partie edge computing. Maintenant, je pense que ce que vous avez en tête, c'est, OK, on comprend bien maintenant la logique de ce qu'on peut faire, comment on peut utiliser l'edge computing pour faire de l'AB testing. Mais si vous utilisez un provider, XYZ pour faire cette solution, ou si vous avez des outils, des scripts d'analyse tiers, notamment Fair Analytics, etc., vous n'allez pas recoder tout ce que je vous ai montré à l'écran. Donc, il existe des solutions, et je vais bientôt passer la parole, et Sam passera la parole à Sacha, mais pour vous expliquer comment on peut faire ça, de manière simple en conservant les solutions que vous utilisez déjà. Donc, comment convertir la partie, vos workloads JavaScript front-end en back? Sam, je te rends la parole.

24:04 Merci Antoine. Je ne vois pas beaucoup de questions. Alors, je ne sais pas, je pense qu'il y a des questions qui vont arriver, donc on les garde pour la fin. Maintenant, nous allons passer à Sacha. Sacha Morard qu'on ne présente plus, je pense, tellement il est connu. Je vous rassure, venant de l'e-commerce, je ne le connaissais pas du tout. Je sais, un abandon très parisien. Mais je pense que peut-être que Romain Curie, qui est au Galerie La Fête, ou même David, qui est au Printemps, pourront le confirmer ou pas. Donc, Sacha, qui est, comme il va nous présenter les solutions d'Edgy autour de l'analytics et notamment de la vitesse, je suis sûre que sa renommée va s'étendre dans l'e-commerce. C'est ce que je lui souhaite en tout cas. Donc, Sacha, ex-CTO du Monde et co-founder d'Edgy, il va nous expliquer pourquoi on devrait aller vers du edge computing, ce que ça va nous apporter au quotidien, et puis il va faire un focus sur l'analytics et la b-test sur le edge, car ce sont les deux problématiques. majeur qu'on tente d'adresser pour tous les sites, notamment de médias, mais pas que, aussi d'e-commerce, toujours à fort trafic.

25:10 Sacha, c'est à toi. Merci beaucoup. Me voilà à me partager mon écran. C'est bon, vous voyez bien mon écran, il n'y a pas de souci. Je crois qu'on est bon. Ok, donc, merci à tous. Merci Sam pour l'intro. Je vais juste brièvement me présenter, puisque pour ceux, certains qui ne me connaissent pas, qui sont du e-commerce, puisque Sam, tu as commencé par dire que j'étais hyper connu, mais après qu'en fait, tu ne me connaissais pas quand tu étais dans l'e-commerce. Donc, il y en a certains, encore heureusement, qui ne me connaissent pas. J'ai d'abord été musicien pendant quelques années. Moi, j'ai un parcours un peu bizarroïde, mais en tout cas, j'étais musicien pendant six ans. Je ne connaissais rien au code. Je n'ai pas fait d'école d'ingénierie, rien du tout. Et j'ai été forcé de changer de métier parce que la musique, c'était trop difficile à vivre. Du coup, j'ai appris à coder, vous voyez, entre 2018 et 2010, quand j'étais designer. Et je suis devenu développeur en 2010. Je suis devenu passionné par le code. Et ça m'a permis notamment de gravir un petit peu les échelons et de devenir CTO de quelques boîtes assez prestigieuses, dont le Parisien notamment, avec qui j'ai fait un petit parcours chez eux, et du Monde aussi, le groupe Le Monde, pendant six ans.

26:19 Moi, ce que j'aime bien, c'est élaborer des stratégies techniques en se servant de l'innovation, notamment pour booster un business. Je donne souvent cet exemple, c'est un peu... Égocentré, désolé, mais quand je suis arrivé au monde, on avait 200 000 abonnés numériques. Quand j'en suis reparti, on en avait 600 000. Et c'est justement en mettant en place avec toutes les équipes marketing, technique, des innovations particulières, une optimisation de la web perf, l'amélioration du parcours client, l'amélioration du parcours d'abonnement, etc., qu'on a réussi à atteindre ces scores, bien évidemment avec le formidable travail de la rédaction, bien évidemment. Je suis désormais entrepreneur. J'ai fondé Edgy. Ce n'est pas facile de se relancer dans l'entrepreneuriat quand on vient d'une belle marque comme Le Monde. Mais il y a un peu plus d'un an, j'ai eu une révélation. J'ai eu cette idée de construire ce framework, cette plateforme edgy qui va pouvoir permettre de résoudre les problématiques, en tout cas que je rencontrais quand j'étais CTO du monde, mais que je suis sûr que

27:24 des CTO ou responsables techniques rencontrent quand ils sont dans le retail, e-commerce, travel, peu importe. En fait, on a tous à peu près les mêmes problématiques. Et c'est pour ça que je suis parti, c'est pour essayer de trouver des outils à donner aux développeurs pour qu'ils puissent résoudre les problématiques qui sont grandissantes aujourd'hui. Je vais vous les expliquer. Alors, on va parler de Edge-Oriented Application. Ça fait un petit moment que le buzzword Edge Computing est apparu. On en parle depuis quelques années. Mais je me suis vraiment intéressé à cela il y a environ trois ans, en essayant tout un tas de technologies, en essayant... de voir si le buzzword allait être incarné par un vrai use case. Et chez Edge, justement, on pense que le Edge Computing en est au stade des LLM il y a encore trois ans, en tout cas on espère. Il y a trois ans, on s'extasiait, nous, les TECOS, de GPT-3 à l'époque, et on ne savait pas trop ce qu'on allait pouvoir en faire. Puis il y a ChatGPT qui est arrivé, vous connaissez la suite.

28:26 On espère et on pense que ça va être la même chose avec le Edge, c'est-à-dire que le Edge, c'est une formidable technologie, un formidable concept. Il nous manque encore un cas d'usage très spécifique pour qu'il soit incarné et compris de l'ensemble des techniciens. Ça ne rentrera pas dans les foyers tels que ChatGPT est rentré, mais ça ne sera peut-être pas autant populaire. En tout cas, chez la communauté technique, on espère et on pense que ça va devenir vraiment un outil. Vraiment très spécial et très important. Nous, on arrive avec ce concept de Edge-Oriented Application. En gros, aujourd'hui, une application, elle se construit sur deux principales couches, le front-end et le back-end. Et on pense que notre industrie a de plus en plus besoin de s'appuyer sur une nouvelle couche, le Edge, et je vais vous expliquer pourquoi. Les applications edge-oriented, elles sont spécifiquement conçues pour tirer parti de la puissance de calcul des capacités de traitement de données à la périphérie du réseau. Donc, vraiment, traitement de données dans le edge.

29:28 Et contrairement aux applications... traditionnelles, qui reposent elles sur des centres de données localisés, des data centers qui sont situés à un endroit, éventuellement deux, trois, on les redonde un petit peu, les applications edge-oriented exécutent certaines de leurs charges de travail à la périphérie du réseau. Ce qui permet notamment un traitement de données, une exécution en temps réel, une prise de décision plus proche de la source de données, c'est-à-dire de l'utilisateur. Et pour comprendre pourquoi c'est utile les Edge-Oriented Applications, il faut analyser. visé avec précision le contexte dans lequel nous, les fabricants de software, évoluons. Et on va essayer de lister ici toutes les barrières qui entravent notre capacité à effectuer des traitements de données, à effectuer notre travail de développeur. Bien, alors le device, comme l'a dit tout à l'heure Antoine, c'est devenu le lieu où tout s'exécute, ou quasiment tout s'exécute. J'estime qu'environ 70 à 80% des traitements liés à un site ou une application mobile s'effectuent côté device.

30:34 Et ça s'effectue en trois temps généralement. Le premier temps, c'est la première requête. Quand un browser vient visiter une page, en tout cas que l'utilisateur demande à son browser d'aller visiter une page, il y a d'abord une requête HTTP qui est envoyée vers une destination. Et ensuite, au bout de cette destination, il y a un serveur qui va construire une page et qui va renvoyer une réponse HTTP. Donc là, c'est le deuxième temps. Et puis, troisième temps, computation dans le device, donc dans le client. Jusque là, c'est assez simple. Et une fois cette réponse arrivée côté device, Celui-ci, il effectue tout un tas de processing, en fait. Et moi, je constate huit catégories de processing. Premier, la présentation, Frontend UI. Deuxième, de la logique opérée dans le client. Par exemple, si l'utilisateur a tel droit ou tel droit, je lui affiche ou pas tel bloc, un paywall, est-ce qu'il est connecté ou pas connecté, ça peut souvent arriver directement, ça s'opère souvent côté client.

31:40 Ensuite, du stockage. Vous connaissez les cookies, qui est un moyen de stockage, mais aussi le local storage, session storage, etc. De l'AB testing, Antoine en a beaucoup parlé, oui on peut faire de l'AB testing et généralement ça se fait côté client, côté device. De l'analytics qui est opéré côté device majoritairement. La gestion du consentement qui est devenue un des... Une des choses principales qu'on traite aujourd'hui, nous les éditeurs de solutions, en tout cas des éditeurs d'applications, on a des systèmes de gestion de consentement, client-side, de la personnalisation, Et puis pour finir, de la pub, bien évidemment, la publicité en ligne qui s'opère que côté client quasiment. Chacun de ces processings peut être altéré ou entravé par trois grandes barrières. Premièrement, les limitations imposées par le device lui-même. Donc ça peut être pas beaucoup de CPU disponible ou alors une mémoire saturée. Ou éventuellement, si vous êtes en mobile 3G, vous aurez forcément une connectivité qui est assez faible.

32:44 Donc un problème de connectivité, par exemple. Puis après, vous allez avoir des problématiques de performance de votre code, des problématiques de conflits entre différentes librairies. Vous avez aussi des restrictions des navigateurs qui sont de plus en plus importantes. On connaît bien évidemment Safari qui a mis en place quelque chose qu'on appelle ITP, qui contraint fortement la façon dont on opère des librairies directement dans le client. Vous avez bien évidemment ce qui est le plus connu, c'est les cookies third party, donc les cookies tiers qui sont voués à disparaître. Ils ont déjà disparu de Safari, ils ont disparu de Firefox. Google Chrome avait annoncé leur disparition, ils ont reculé plusieurs fois, puis finalement ils vont finir par disparaître, mais ce sera au choix de l'utilisateur. Bon bref, les cookies sur partie disparaissent et ça pose tout un tas de problèmes, notamment dans le milieu de l'advertising. Bien, ensuite, ça c'est la première des barrières. Vous voyez, il y en a pas mal. Ensuite, la deuxième barrière, c'est les adblockers. Les adblockers, elles ne bloquent pas que des technologies publicitaires. Bien au contraire, en fait, elles bloquent tout ce que vous voyez au-dessus, donc la perso, la CMP, l'analytics, la B-testing.

33:49 Client storage, ça peut aussi impacter. En fait, les adblockers ne bloquent pas que des technologies publicitaires et elles nous empêchent beaucoup, ils nous empêchent beaucoup de faire des choses qu'on veut faire directement dans le device. Et puis dernier point, la régulation. Alors la régulation, ce n'est pas spécifiquement une barrière, mais en tout cas, c'est une contrainte supplémentaire, nous, en tant que développeurs, de faire en sorte, bien évidemment, de respecter la régulation, de respecter le choix de l'utilisateur en matière de données personnelles. C'est une contrainte, en tout cas une complexité supplémentaire qui nous empêche de temps en temps aussi de collecter correctement de l'information, par exemple. Donc, imaginons quelques cas d'utilisation affectée. Par exemple, ces barrières que vous voyez en bas pourraient très bien générer des problèmes de réactivité et de performance sur des appareils variés. Ou alors, en matière d'AB testing, justement, un adblocker va compliquer la collecte des résultats et même complètement altérer l'affichage des scénarios d'AB test.

34:52 Les CMP aussi, par exemple. Les CMP sont adblockés. Donc, par définition, un adblocker, du moment que vous l'avez installé, vous n'avez plus à consentir ou non. donc consentir puisque le CMP ne se lance pas la plupart du temps. Et comme le CMP ne se lance pas, tout ce qui devait déclencher en cas de refus ou d'acceptation du traitement d'un données personnelles ne se lance pas non plus. Tout ça en cascade fait qu'aujourd'hui, côté client, on arrive dans une situation qui devient de plus en plus problématique. Ok, alors là, on va voir deux architectures. L'architecture traditionnelle, donc ça, c'est en gros, vous voyez l'architecture d'une application traditionnelle avec d'un côté le front-end, le user device, et d'un côté le back-end. Vous avez toutes les mécaniques, tous les processings qui sont opérés chacun d'un côté. Et on va regarder ce qu'on peut faire avec une application edge-oriented. Une application edge-oriented, ça veut dire qu'on va déplacer des workloads, donc des charges de travail qui étaient initialement opérées côté device, dans le edge, pour se libérer des contraintes.

35:57 Donc on va commencer par l'analytics, on va le mettre côté edge. Et là, à ce moment-là, il n'est plus dans le device, on se libère de contraintes. On peut faire ça avec l'AB testing aussi. On peut faire ça avec les CMP notamment, je vous en parlerai un petit peu plus en détail tout à l'heure. On peut faire ça avec la personnalisation, avec l'advertising et également avec la sécurité. Alors l'idée aussi c'est que le Edge puisse être un lieu où on va déplacer des workloads depuis le front, mais également depuis le back aussi. La sécurité souvent ça s'applique côté back, mais vous voyez que là on peut aussi en mettre côté Edge Computing. Donc si on résume, Dans cette architecture edge-oriented application, le device va principalement exécuter des tâches nécessitant un traitement local et léger. Le backend, tout en haut, continue d'exécuter des tâches nécessitant de lourdes ressources informatiques. Et le Edge, lui, va exécuter des tâches qui impliquent une grande distribution, une extrême scalabilité et performance. Ok, donc maintenant on va pousser le concept, on va vous expliquer comment chez Edge, on fait bouger les librairies d'analytics depuis le client vers le Edge.

37:07 Mais avant cela, parce que j'aime bien faire du teasing, cette petite phrase de Jay Poynter, qui est l'ancien CEO de LinkedIn,« Data really powers everything that we do», ce qui veut dire qu'en gros, chacun de nous se définit comme étant data-driven. Antoine le disait aussi tout à l'heure, qu'on travaille dans la pub, le e-commerce, le travel, les médias, peu importe en fait. On se dit tous data-driven. Sauf qu'en réalité, on subit depuis des années déjà, et de façon assez passive malheureusement, tout un tas de barrières qui nous empêchent d'y voir clair, et je vous les ai nommées tout à l'heure. En fait, je vais vous poser cette question et vous pouvez éventuellement répondre dans le chat. Alors préparez-vous à écrire. Ok? Vous êtes prêts? Il va falloir aller très vite. Est-ce que vous savez estimer le pourcentage d'utilisateurs qui ne sont pas capturés par vos outils d'analytique? qui s'installait sur vos sites. Allez, c'est parti, on y va. Pour ceux qui savent. Il n'y a pas de réponse.

38:09 Ça voudrait dire que personne ne sait. Ou que vous êtes timide, peut-être, c'est aussi possible. Merci Romain. 27, 27. Wow. Wow. 80, c'est très, très varié. C'est intéressant, ça. Oui, en effet, en France, en Europe, on peut dire 40%, 70%. C'est marrant. Alors, ça dépend. En effet, je pense que vous avez tous une bonne réponse, puisque ça dépend beaucoup du secteur. Si vous êtes dans le gaming, par exemple, vous avez des taux d'adblock qui sont très, très importants. Donc, du coup, il est fort à parier que vous collectez beaucoup moins dans le gaming que si vous étiez, par exemple, dans le média. Dans le média, il y a quand même beaucoup de contraintes, mais peut-être qu'il y a des gens, ça dépend des médias, des utilisateurs qui ont un peu moins d'adblockers installés. Ok, donc moi je vais vous dire ce que j'ai mesuré sur un grand site média, dont je tairai le nom. c'est que 27% des utilisateurs, ce qui représente 39% des pages vues, sont invisibles dans les analytics.

39:15 Ce qui veut dire que les outils d'analytics ne sont pas capables de mesurer ces 27% d'utilisateurs ou ces 39% de pages vues. Donc là, on parle d'un use case média. Et comme je vous l'ai dit, ça change en fonction du secteur. Et ce qui est plus intéressant dans ce use case, c'est de regarder... Qu'est-ce qu'il nous manque quand on essaie de segmenter sur les core users ? Les core users, c'est des gens qui font plus de 4 sessions par jour. Eh bien, il nous en manque 40%. Pourquoi? C'est bizarre, cette perte n'est pas linéaire. C'est tout simplement parce que les gens qui sont les plus fidèles n'ont pas le même comportement et le même usage d'Internet que les gens qui le sont moins. Ils ont plus d'adblockers, ils consentent moins au traitement des données personnelles, ils ont plus de problématiques liées aux clients. Beaucoup d'ongles ouverts, ils sont peut-être en 3G. Vous voyez, il y a plein de facteurs qui font qu'en fait, on les connaît encore moins. Et puis, c'est justement eux qu'on veut connaître. C'est justement les utilisateurs qui viennent souvent sur nos infras, qu'on veut connaître, qu'on veut retenir, qu'on veut convertir.

40:16 C'est eux qu'on ne peut encore moins convertir parce qu'on les connaît encore moins. Et donc, j'ai souvent cette remarque des gens qui disent, oui, OK, je sais que j'ai une perte, mais ce n'est pas grave, je regarde les tendances. Et moi, je considère qu'il est très difficile de regarder des tendances quand la perte n'est pas linéaire. La perte, elle n'est pas linéaire. C'est-à-dire que vous pourrez très bien demain avoir une tendance sur vos core users qui vous dit que vous avez tant de pourcentages d'entrée dans votre tunnel. Mais le lendemain qui n'a rien à voir. Parce que, je ne sais pas, vous avez un pic de charge lié à une communication particulière, et là, du coup, tout de suite, vous avez des gens qui sont un peu plus volatiles et qui vont impacter même les résultats des statistiques des gens qui sont un peu plus fidèles. Donc, en fait, les tendances, pour moi, ça ne marche pas tout à fait. On a besoin d'avoir une vue éclairée sur les données et force est de constater qu'aujourd'hui, on ne l'a plus, cette vue. J'ai passé ce slide parce que c'est un peu compliqué et c'est redondant. Le seul problème qu'on a, c'est que là aujourd'hui, on est de plus en plus blind sur les données qu'on collecte.

41:17 Et puis, ce n'est pas fini. Ça va être de pire en pire. Il est, à mon avis, absolument improbable que la législation s'allège concernant la collecte des données personnelles. Les adblockers continuent de bloquer tout un tas d'usages. Et puis, il y en a des nouveaux, des nouvelles générations d'adblockers qui arrivent, des adblockers DNS, VPN, pardon, qui viennent s'inviter dans le mobile, notamment. Um, Il y a des problèmes de plus en plus de congestion réseau, de performance, etc. Les nouvelles versions d'iOS sont de plus en plus restrictives sur la question de la collecte de données. Donc voilà, ni bout à bout, de toute manière, on va dans un monde où on pourra de moins en moins collecter, si tant est qu'on continue de collecter côté client. Oui, ça c'est la même chose, je vous dis que c'est la même chose. Bien, alors la solution, la solution c'est quoi? Alors on va reprendre juste brièvement le concept de collecte de données standard sur une application standard avec seulement deux layers, le backend et le frontend.

42:23 Alors ici, je ne sais pas si vous voyez ma souris, je ne pense pas. Si vous devez la voir, je ne sais pas. Donc, vous avez le client qui effectue une requête. Quand vous visitez un site, vous avez la page qui est envoyée. Ok, merci. Vous avez une requête qui est envoyée vers une destination, la destination construit la page, et donc le développeur qui a développé cette application a fait en sorte que cette page soit la plus rapide possible. Et dans cette page, il la renvoie, mais dans cette page, il a également injecté, inséré des librairies JavaScript. Donc là, vous en voyez quelques-unes, Google Analytics, Facebook API, AB Testy, évidemment, il y en a pléthore. Et ces librairies JavaScript, du coup, c'est le browser qui va les exécuter, qui va les interpréter, et elles vont demander elles-mêmes au browser d'effectuer tout un tas de traitements, notamment des collectes de données. Donc, c'est ça qui est limité dans l'analytics, parce qu'il faut normalement faire, si on a reculé le concentrant d'abord, elles sont contraintes par les adblockers, c'est-à-dire, par exemple, Google Analytics sera adblocké, et il y aura des problématiques de performance.

43:24 Il est fort à parier que... Un utilisateur qui est connecté en mobile 3G sur votre site, le hit vers Google Analytics ne passe pas 100% du temps, par exemple. Qu'est-ce qu'on fait chez Edge? Edge, c'est une plateforme et framework de Edge Computing installée chez Fastly. On est partenaire avec Fastly et c'est pour ça que ça marche si bien d'ailleurs. Donc d'abord, la requête est envoyée vers Edge. Et G fait passe-plat à ce moment-là, renvoie la requête vers votre origine. L'origine construit la page, et là le développeur, il ne va pas mettre la librairie de Google Analytics, prenons cet exemple, dans la page, mais il va mettre la librairie de G. Et ensuite, la page est renvoyée à Edge dans la réponse HTTP et Edge voit que le développeur lui a demandé de faire quelque chose puisqu'il a intégré le SDK de Edge et il va opérer la collecte directement depuis le Edge. Avec les mêmes outils. C'est-à-dire que si vous êtes client Google Analytics, Amplitude, Mixpanel, peu importe, vous allez avoir ce qu'on appelle des components, WebAssembly components, qui vont être installés directement sur Edge.

44:30 Donc l'avenir des SDK client-side, finalement pour nous, c'est du WebAssembly component qui va être plugué directement sur notre software Edge. Et là, c'est ces components qui vont opérer la collecte directement depuis les serveurs d'Eji, et du coup, sans exposer l'utilisateur. La page est renvoyée au client, nettoyée, il n'y a pas de script qui tourne, il n'y a rien du tout, et la collecte a été effectuée. concept de base, ça va évidemment beaucoup plus loin que ça, je suis sûr que vous avez déjà des questions dans votre tête que vous pourrez me poser à la fin. Et les résultats, c'est quoi? Si on doit le résumer, c'est 100%, le chiffre 100%. 100% des données peuvent être collectées désormais. 100% légalement parce que tant qu'on n'a pas reçu le consentement de l'utilisateur, nous on assure qu'on va récolter que des données anonymes. Je vous ai dit, c'est nos serveurs qui effectuent les requêtes vers les analytics providers, ce qui veut dire que ce n'est pas le client, ce n'est pas le browser ou ce n'est pas l'application mobile.

45:31 Donc il n'y a pas l'IP du client. Comme il n'y a pas l'IP de l'utilisateur, la première des données personnelles, par définition, elle n'est pas dans la collecte de données. Ça, ça arrange beaucoup de choses. Puis on effectue aussi deux autres couches d'anonymisation sur les référeurs et les GTM, dont on pourra parler plus tard, ce qui assure que, sans avoir reçu le consentement, on collecte de la donnée, mais de façon anonyme, consentless, on a le droit de le faire, pas de souci, puisque de toute manière, cette donnée ne vous permettrait pas, permettrait personne de pouvoir cibler l'utilisateur et le retrouver. Et puis 100% pour une meilleure UX parce qu'en libérant mécaniquement des librairies assez gourmandes côté client, on améliore l'expérience de lecture. On va très vite basculer sur le système d'AB test parce que je vous ai montré plusieurs use cases. On a focus bien sur l'analytics, mais évidemment, on peut faire plusieurs choses avec Edgy et notamment de l'AB testing. L'AB testing, finalement, vous le savez, c'est au cœur de nos stratégies digitales. On peut difficilement améliorer nos conversions si on change. cherche pas un minimum à optimiser le parcours d'un utilisateur et donc depuis des années on fait de la BTC.

46:35 Mais ces technologies, comme l'a dit Antoine, pour la plupart du temps, sont des solutions client-side, donc elles s'exécutent côté client. Et pour vous rendre le service qu'elles vous promettent de vous rendre, elles sont obligées de solliciter le device. Voilà, c'est logique. Et ça donne souvent ce genre d'effet, les effets flickers dont a parlé notamment Antoine. Après, vous avez moyen d'optimiser ça et de faire en sorte que ce soit le moins visible possible, ça, il n'y a pas de problème. Et donc, ce matin, pour les besoins de ce meet-up, j'ai fait un test très simple. Je suis allé sur le site d'une de ces technologies d'AB testing. J'ai regardé leur liste de clients. J'en ai choisi un au hasard, un grand média américain. Et j'ai effectué toute une série de tests, plusieurs, vraiment plusieurs tests à la filet pour récupérer des moyennes. Et de d'abord analyser les performances du site avec la librairie d'AB testing bien connue et d'analyser en bloquant cette librairie d'AB testing. C'est comme ça que j'ai opéré le test.

47:37 Et ce tableau représente le temps en millisecondes passé par le navigateur à effectuer des tâches et groupées par catégorie. Donc, loading, scripting, rendering, etc. Donc, ça, c'est les millisecondes. Et vous voyez, il y a deux colonnes, AB testing on, AB testing off. Donc, on voit qu'en moyenne, lors de mes tests, la page de ce site fait travailler le navigateur pendant 19,4 secondes environ. Et lorsque je bloque la librairie d'AB Testing, le navigateur économise 4 secondes de travail effectif. On ne parle pas de temps de chargement, on parle vraiment de temps pendant lequel le navigateur effectue des tâches. Autrement dit, ça veut dire que cette simple librairie d'AB testing occupe 20% de l'ensemble du temps de traitement du navigateur pour afficher cette page. C'est quand même assez important. Et de plus, comme les technologies d'analytics, les solutions d'AB testing client-side sont très contraintes par les mêmes barrières que tout à l'heure et elles ne s'exécutent pas 100% du temps à cause des adblockers, à cause des limitations côté client et à cause de la régulation également.

48:46 Donc la solution, c'est pareil, la solution c'est le Edge. Et là je vais vous découper vraiment step by step comment peut fonctionner une librairie d'AB testing comme Optimizely, Cameloon, AB Testy, mais avec le Edge, avec cette version de component qu'on est en train de développer. Donc d'abord, le client effectue une requête. Cette requête arrive chez Edge. Edge renvoie la requête vers votre origine, votre serveur. Là, vous construisez la page en mettant toujours la librairie de Edge dans cette page et vous renvoyez la réponse à Edge. Edgy reçoit cette réponse, voit très bien selon les instructions que le développeur lui a données qu'il y a de l'AB testing à opérer côté Edge directement. Et c'est là où, selon comment vous l'avez configuré, vous avez le component, par exemple, d'Optimizer. qui va intervenir et qui va injecter directement dans la réponse, on the fly, le scénario de test et aussi collecter les informations d'affichage de ce scénario. On change complètement d'approche. On injecte directement du contenu dans la réponse HTTP, côté réseau.

49:52 Et c'est toujours 100%. 100% des tests sont désormais affichés, alors qu'avant, rien qu'un adblocker empêchait pas... une certaine partie des tests d'être affichés. 100% aussi de la donnée liée au test est collectée, la donnée d'affichage, la donnée de performance d'un test, et 100% également de la même manière que l'Analytics, et encore 100% avec le meilleur UX, parce que là, pour le coup, vous voyez très bien qu'avec mon exemple, on peut économiser 4 secondes de temps de processing du navigateur simplement en déplaçant ça côté Edge. Donc voilà ce qu'on fait chez Edge. Et alors après, on ira beaucoup plus loin que ça, en mettant également des CMP côté Edge, en mettant de la perso, etc. Côté Edge. L'idée, c'est vraiment d'avoir un écosystème, une librairie, une framework qui est disponible pour les développeurs pour qu'ils puissent faire du Edge plus facilement et plus aisément que ce qu'ils ont fait jusqu'ici. J'en ai fini. Je pense que c'est l'heure des questions.

50:55 On va regarder. Les questions, je prends les dernières. Alors, je n'ai pas de vote sur les questions. J'ai Guillaume qui indique. Alors, je lis la question car je ne l'ai pas lue auparavant. En plus des avantages vis-à-vis des contraintes listées, ce serait une opportunité intéressante au niveau de la sobriété numérique? Non, n'est-ce pas plutôt? Calcul optimisé côté Edge Computing, moins de charges côté Device Client. Possibilité de limiter l'obsolescence du matériel, moins de consommation d'énergie. Est-ce qu'à ce niveau, vous auriez fait des études? vous auriez des premières estimations qui pourraient être valorisées dans ce cadre ? Alors, moi, personnellement, non, je n'en ai pas encore. J'attends impatiemment, justement, de pouvoir mener ces études-là.

51:57 Mais tu as raison, Guillaume, il est évident qu'en libérant le device, de librairies qui sont consommatrices d'énergie, parce que derrière, c'est que de l'énergie, on améliore son obsolescence parce que mécaniquement, on va simplifier les workloads qu'il a effectués. Donc, moins de consommation de batterie. Beaucoup plus de compatibilité, c'est-à-dire peu importe en fait si on a une puce M2 ou si on est sur une ancienne version de processeur, peu importe vraiment la version de son navigateur, on redevient des concepts un peu plus simplifiés avec du HTML, du CSS, un peu JS bien évidemment il en faudra, mais en tout cas moins de compatibilité entre les différentes versions de JS par exemple. Oui, il est évident que ça va améliorer l'obsolescence des machines et donc avoir un impact sur la consommation énergétique des applications. On va passer à la question de Romain.

53:01 Donc, il dit pour le premier rendu, ça marche. Mais si je veux loader de l'AB test sur une page atteinte en navigation côté client en mode SPA, comment ça se passe? Très bonne question Romain, c'est une question de quelqu'un qui s'y connaît très bien. Alors bien évidemment, chez Edge, on prévoit ce cas d'usage. Si vous allez sur edge.cloud, notre site, vous verrez que c'est une SPA et Edge est installé sur edge.cloud. Et donc, on gère évidemment cette... Sur la première requête, en effet, ça va être une collecte côté Edge. Mais comme je vous ai dit tout à l'heure, le développeur, il a injecté la librairie d'Eji directement depuis son backend, qui a intercepté côté Edge dans la première requête. Mais si ensuite, vous avez un mécanisme qui ne se passe que côté client, ou que vous voulez collecter d'ailleurs un événement que côté client, le clic sur un bouton par exemple, c'est la librairie d'Eji qui est renvoyée directement dans le client quand même, qui elle va prendre le relais. Mais elle prend le relais d'une façon tout à fait particulière. En fait, elle est injectée et contrôlée par le hedge.

54:04 Ce qui permet de pouvoir opérer des stratégies pour éviter que cette librairie soit bloquée et que les points de collecte soient bloqués également. On peut creuser le sujet si vous voulez, je ne vais pas vous faire la démo là, mais en tout cas, bien évidemment que ce cas d'usage est géré par Eiji. SPA, pas SPA, événement client-side ou pas, Eiji s'est collecté. De façon sécurisée. On a eu Eric qui a posé une question, mais je pense que tu as répondu durant ta presse, Sacha. Légalement, c'est plutôt PII qui bloque. Il n'y a rien qui empêche de traquer des données de trafic si anonyme. Donc, effectivement, tu as répondu que comme l'IP était une des données les plus stratégiques, comme on ne les avait pas, on pouvait effectivement les collecter si tu veux rajouter plus d'informations. Oui, c'est tout à fait juste. Aujourd'hui, on a tous le droit et on est tous capables de collecter de la donnée du moment qu'elle est anonyme. Ce qu'on appelle le mode consentless. Moi, j'appelle ça le mode consentless. Vous avez certaines librairies d'analytics, par exemple, qui ont un mode consentless.

55:10 Je pense à Piano Analytics, je pense à Amplitude. En fait, vous en avez certaines qui vont vous certifier le fait que vous allez pouvoir les utiliser d'une certaine manière et qu'en les utilisant de cette façon, elles ne vont pas collecter de données personnelles ou en tout cas, elles vont les jeter très vite. Ça marche, mais en tant que développeur, vous allez devoir lancer la librairie en mode consentless et quand vous avez le consentement, changer de librairie et mettre la consentful. C'est une opération à effectuer côté dev qui est assez pénible, surtout quand vous avez pléthore de solutions d'analytics et que vous devez les orchestrer. Chez EJ, c'est natif en fait. Vous n'avez rien à faire de particulier. Si l'utilisateur, en gros, si vous ne passez pas des données personnelles, il n'y a pas de données personnelles qui transitent. Et il y a aussi ce mécanisme de sécurité absolue en matière de données personnelles qui est que la requête envoyée à Analytics, elle est effectuée depuis nos serveurs. Donc l'IP de l'utilisateur n'est pas exposée. L'IP, c'est une PII. Elle est considérée comme une PII, même si elle n'est pas fiable à 100%, on est d'accord. Elle est considérée comme une PII, donc une donnée hautement identifiable.

56:14 Et donc, pour cela, en fait, la passer directement en mode proxy, l'IP n'est pas exposée, ça permet de lever tout un tas de contraintes juridiques. Et moi, j'ai une question en attendant d'autres. En fait, est-ce que... Est-ce que le fait de déporter tous nos workloads côté edgy, ça va vraiment prévenir les adblockers de s'adapter ? Sur leur méthode de blocage. Il y a, comme je l'ai dit tout à l'heure, il y a ce qu'on peut collecter, opérer côté edge. Et dans certains cas, d'une SPA par exemple, ou d'événements à collecter côté client, il y a toujours des opérations qui vont être opérées côté client. Que le hedge va tenter de contrôler et faire en sorte qu'il ne soit pas adloqué par exemple. Donc nous, on a tout un mécanisme comme ça. On a vraiment réfléchi très longuement à essayer de trouver un moyen pour que même les événements ou les workloads qu'on effectue côté client ne soient pas adblockés. Après, je ne peux pas garantir qu'un jour, il n'y a pas quelqu'un de EasyList qui va dire« Ah, mais j'ai trouvé le moyen et j'ai le bloqué.

57:15 » OK, dans ce cas-là, on opérera, je ne sais pas, une autre stratégie. On a déjà deux, trois choses déjà sous le cas, en tout cas dans les cartons. Mais ça concerne les opérations qui sont effectuées côté client. Il faut savoir que ce qui est opéré côté client, ce qui est collectable côté client, ça représente 10% de ce qui est collectable en tout. Parce que la majeure partie de ce qu'on peut collecter de côté edge, et là côté edge, je sais vous certifier que, ce n'est pas accessible. C'est comme si aujourd'hui, depuis vos serveurs applicatifs, directement, vous envoyez un hit vers Google Analytics, aucun adblocker pourrait faire quoi que ce soit. Rien. Et quelque part, on peut m'exposer quand même, je trouve ça assez normal, c'est vous qui prenez la responsabilité de le faire. C'est vous, éditeur d'options, qui prenez la responsabilité juridique d'opérer le traitement de données. Je pense que je n'ai pas d'autres questions. On est pile dans le timing. Noémie, si je n'ai pas loupé de questions, n'hésite pas à m'indiquer.

58:17 Il y a une dernière, je crois, de Luc qui vient d'arriver. Oui, comment se moque des déclenchements de tags loadés par un GTM dans le Edge? Alors, je ne sais pas si je comprends bien. Est-ce que c'est comment vit GTM, par exemple, avec une solution comme Edge, c'est ça? Parce que les deux, en fait, ne sont pas tout à fait... Pas tout à fait comparable. Google Tag Manager, en gros, même si c'est la version server-side, il opère côté client. Vous avez une librairie côté client qui est exécutée et si elle est bloquée, elle est bloquée. Ça, vous ne pouvez rien faire. Donc, même si la version GTN server-side, Elle rationalise un peu les appels côté réseau, c'est-à-dire que vous avez une librairie et ensuite vous avez un hit qui est envoyé depuis votre navigateur vers GTM Server Side qui ensuite est distribué vers différents third-party providers. Donc ça, ouais, ça marche, mais si tant est que la librairie ne soit pas adblockée, par exemple.

59:20 Et Giz, pas du tout pareil. Tout est au niveau du Edge. Donc, si vous voulez, sur cette partie-là, orchestration de l'analytics, vous pouvez oublier GTM. Par contre, vous pouvez continuer à utiliser GTM pour injecter des librairies JavaScript dans votre client. Ça, ça peut être utile. Il y a des choses que Edge ne va pas faire, ça, on ne le fera pas. Donc, si vous avez besoin, je ne sais pas, d'orchestrer l'insertion de librairies JavaScript dans votre client, continuez à utiliser GTM. Mais pour la collecte de données, si vous voulez avoir 100% des données, vous feriez mieux d'utiliser Edge. Et enfin, on a une dernière question d'Eric. Gardons-nous indiqué que c'est la dernière question. Niveau sécurité, ça me fait penser à Man in the Middle. Peut-on vendre cela à un Cisco ? Ciseaux, du coup. En fait, c'est aussi pour ça qu'on est partenaire avec Fastly. En fait, on est installé sur la chaîne réseau comme on installe un CDN. On n'est absolument pas incompatible d'ailleurs avec l'installation d'un CDN. Nous, on ne gère pas de cache, on gère du computing. Donc, on peut très bien, par exemple, avoir Fastly en CDN et utiliser Eji, qui est d'ailleurs installé au même endroit, pour gérer plutôt l'applicatif métier, les besoins métiers.

1:00:31 Mais donc du coup, si cette question se pose pour Oglie, elle se pose également pour le CDN, puisque le CDN, c'est un man-in-the-middle exactement de la même manière. Les load balancers sont aussi des man-in-the-middle. Les proxys HTTP que vous installez sur votre infrastructure Kubernetes, par exemple, si vous utilisez Nginx, HAPROXY, sont également des logiciels qui peuvent être considérés comme man-in-the-middle. Après, il faut bien considérer qu'on a des technologies, des dev tools, qui s'adressent à des clients qui sont des développeurs. Donc les développeurs, ils doivent installer ces solutions, les maîtriser et faire ce qu'ils veulent avec. Donc, ce n'est pas nous qui allons modifier comme par magie les requêtes et les réponses HTTP. C'est le développeur qui va décider de le faire. Et là-dessus, de la même façon où tu as un outil d'AB testing en front, c'est-à-dire que tu peux rentrer le code que tu veux exécuter. Donc, si des personnes du marketing sont assez peu rigoureuses avec leur mot de passe, etc., rien que l'outil d'AB testing, ou même on parlait de GTM, pareil, tu peux finir par exécuter du code arbitraire avec ça.

1:01:42 Bien sûr, moi j'ai même vécu dans une vie antérieure, quand on avait de la publicité en ligne et qu'à l'époque, le système anti-fraude n'était pas encore aussi évolué qu'aujourd'hui, où tu avais des bideurs, des acheteurs qui injectaient du JavaScript dans les pages et qui sniffaient les mots de passe quand il y a quelqu'un qui tape son mot de passe pour se loguer, par exemple. Donc, vous voyez, là aussi, c'est un vrai man in the middle. Et pour le coup, ça... À mon avis, c'est beaucoup plus probable que de le faire directement côté réseau sur un système en web assembly qui est extrêmement contraint. Parce que par exemple, il ne faut pas oublier que tout ce que tu vas mettre dans le local storage est accessible à n'importe quelle solution tiers. Donc après, il faut tout. Et ce n'est pas uncommon de voir des JWT dans le local storage, etc. Et on a pu voir aussi par le passé des solutions entières dont les domaines passent de main en main vers des organisations pas toujours...

1:02:47 Les jits, faire des choses. Donc, plus tu bascules aussi vers l'edge, plus tu es sûr de ce que tu charges. Je pense qu'on va clore du coup le meet-up. Merci à tous pour votre participation et votre écoute. Et à très vite pour un autre meet-up, je pense. Noémie? C'est bon pour toi? J'ai remonté. Oui, merci beaucoup. Merci à tous les trois pour vos interventions. Merci aussi pour les questions qu'on a eues dans le chat. Il y a eu une petite latence, mais on s'en est sortis. Merci encore. Et puis, en effet, à très vite pour le prochain. Alors, pas vraiment Meetup, mais Ask Me Anything, un tout nouveau format où on aura deux personnes en intervention sur des questions d'EFSEC OPS. Voilà, merci beaucoup à tout le monde. Passez une très belle journée. Merci beaucoup. Merci. À très vite. Au revoir.