Webinar sur le Traçage Server-Site

Bonjour à toutes et bonjour à tous, bienvenue à ce webinar organisé par Digital Inkers, By Equancy et Didomi. Nous avons le plaisir de se retrouver aujourd'hui pour échanger sur un sujet passionnant qui est le Tracking Server Site. Pendant la première partie de ce webinar, nos intervenants reviendront sur les concepts, les méthodes et l'impact du Tracking Server Site sur la chaîne de gestion du consentement et nous consacrerons le dernier quart d'heure à répondre à vos questions pour que vous puissiez, enfin les questions que vous pouvez poser dans l'onglet questions en bas à droite de votre écran. Nous allons démarrer la session, je vais laisser nos deux spécialistes du sujet Laurent Werner, solution consultance chez Didomi et Quentin Bérard, stratégique expert digital analyst chez Digital Inker se présenter maintenant. Merci à tous les deux d'être avec nous ce matin. pour nous parler de ce sujet. Bonjour tout le monde et merci de m'avoir invité. Mon nom c'est Laurent Werner, je travaille chez Didomi en tant que consultant en solution. Vous allez le voir un petit peu plus tard, mais l'idée c'est que j'ai une bonne compréhension de ce qu'on est capable de faire Didomi, ce qui se trouve un petit peu sur le marché d'un point de vue solution, best practice, entre autres server side. Et du coup avec tout ça, ça me permet d'aider non seulement mes collègues chez Didomi, mais aussi les partenaires, nos prospects, les clients. à travailler sur des solutions, server side et un peu sur la partie projet également. Merci Laurent et moi Quentin Bérard, je suis stratégique expert digitaliste chez Digital Linkers et je m'occupe spécialement des sujets de collecte, donc de la partie tracking et je suis assez spécialisé sur la partie tracking server side et je suis ravi d'animer ce webinaire avec Dithomy. Avant de commencer, on va faire la traditionnelle présentation des entreprises. Je vais commencer avec Digital Linkers. Digital Linkers, historiquement, on est une agence d'experts en data avec des métiers orientés de la collecte jusqu'à l'analyse de données et du CRO, avec également des analytics engineers. On a une grosse actualité que vous avez peut-être vue ces dernières semaines. On vient d'être acheté par E-Prency. On est très content d'intégrer un beaucoup plus gros groupe qui est spécialisé dans la transformation data. digital, l'IA, et qui va nous aider à développer notre activité. On est ravis de les rejoindre et c'est une belle occasion pour commencer notre collaboration. Du coup, Laurent, je te laisse la main pour Didomi. Merci. Et du coup, Didomi, on est sur le marché depuis 2016. On a été créé par trois fondateurs, Romain, Jawad et Raphaël. Romain et Jawad viennent déjà du monde de l'entreprenariat. Ils ont déjà monté une entreprise qu'ils avaient revendue à Mediamat dans le passé. Donc on a une très bonne compréhension de ce monde d'entreprenariat, on a déjà une très bonne connaissance du monde du consentement, vu qu'on a été créé en même temps que le RGPD, et on commence maintenant à s'étendre bien entendu à l'international, avec tous les différents frameworks, consentements, privacy laws, etc. qu'on trouve sur le marché. Donc on travaille de plus en plus avec des partenaires, et entre autres avec Digital Linkers, pour justement mettre en place ces nouvelles stratégies, ces nouvelles technologies, ces nouvelles architectures. mises en place par nos clients et prospects communs. Et on en vient donc au prochain slide. C'est ce qu'on fait ensemble avec Digital Linkers. On va donc mettre en place toutes ces solutions. Alors, pas que ServerSite. ServerSite, c'est le sujet d'aujourd'hui. On a quand même fait d'autres implémentations ensemble. On va avoir des clients en commun. On a la Redwood, par exemple. On a Wonderbox, etc. Donc, on en a plusieurs de disponibles. Et donc, avec Quentin, l'idée, c'est que très souvent, On va rajouter la vision partenariat dans nos engagements de prospection, de clientèle, une fois qu'on va voir que les projets sont un petit peu trop avancés, peut-être pour Didomi d'un point de vue d'implémentation, et qu'on a besoin par exemple d'une vue d'expert ou d'un petit peu de main d'oeuvre pour faire entre autres avec le server-side tout ce qui est migration, configuration, etc. On est très content de vous être partenaires avec Avedi Domain depuis quelques années déjà, puisqu'on partage les mêmes valeurs et on pense qu'on avance bien ensemble sur les différents clients avec lesquels on a pu collaborer. Pour vous donner un peu le plan général de ce qu'on va raconter, je vais vous présenter un petit peu ce que c'est le server-side de manière générale, le tracking. C'est un peu un mot-valise, comme il y en a beaucoup dans notre métier, et un mot à la mode qui désigne plusieurs réalités. Je vais essayer de vous expliquer un peu ça, je vous demande de vous accrocher parce que je suis plutôt technique, donc de temps en temps je risque de dévier sur des choses qui sont un peu ardues à comprendre. Et dans un second temps, on essaiera d'aborder le sujet des bénéfices plus business, avant que je laisse la main à Laurent qui nous parle de la privacy dans le contexte server-side, et à la fin on vous parlera de comment ça se passe finalement un projet de déploiement server-side, et quelles sont les choses à prendre en compte avant de se lancer. Donc avant de parler même de c'est quoi le server-side, la question à se poser c'est le pourquoi. Et aujourd'hui l'écosystème digital est en mutation, Ce n'est pas une mutation qui est récente, c'est une mutation qui date de quelque temps déjà. Et le premier élément qui a changé et qui continue de changer à travers le monde, c'est l'environnement réglementaire. Évidemment, en tant que Français et sur ce marché-là, on est très touchés parce qu'on a probablement une des réglementations les plus restrictives au niveau du dépôt de cookies. Vous voyez régulièrement des manières de consentement sur l'ensemble des sites que vous pouvez visiter. Et cet environnement réglementaire restrictif, Il nous oblige à avoir un rapport à la donnée qui est différent. C'est-à-dire qu'auparavant, quand on faisait de l'analytics, on faisait du média, on ne se posait pas la question de j'allais perdre X% de ma donnée. Maintenant, quand je suis sur un site français, j'ai tendance à me dire, je vais perdre 40% à 30% de ma donnée de base sur les gens que je vais collecter. Donc, ça donne un rapport très différent à ce que vous allez collecter et dans votre façon d'exploiter également. Parallèlement à ça, on va avoir des restrictions navigateurs qui sont apparues. Les restrictions navigateurs, alors... On entend beaucoup parler de Chrome ces derniers temps, parce qu'il y a la fin des cookies tiers, etc., qu'ils ont finalement repoussé. C'est un sujet qui prend beaucoup de poids sur les réseaux et sur LinkedIn. Mais finalement, les vrais instigateurs de ces restrictions de navigateurs, c'est Apple, et ça fait un moment qu'ils ont lancé ça. Et aujourd'hui, ça fait plus de 5-6 ans que Safari va apporter d'énormes restrictions à ce qu'on peut faire en termes de maintien des informations via des cookies. Et ça affecte énormément les mécanismes. client-side historique. Et ça fait longtemps que les acteurs de la tech ont commencé à mettre en place des réactions à ça via des changements dans leur façon de traquer les interactions. Et à côté de ça, et finalement qui est une corollaire, c'est qu'on a des exigences utilisateurs qui sont à la hausse. Donc des exigences vis-à-vis du contrôle de leurs données. Les gens sont conscients que leurs données est importante et qu'ils ne doivent pas la laisser partir comme vers n'importe quel acteur etc. Donc c'est quelque chose qui est assez présent et qui est présent notamment par l'utilisation de plus en plus de date blockers. Et il y a également une exigence pour les utilisateurs d'avoir une expérience qui soit positive et cette expérience positive passe de plus en plus par la performance, et quand je parle de performance je parle de webperf, et la capacité à des écosystèmes digitaux d'aller vite. Donc face à tous ces nouveaux enjeux, on a un modèle client-side qui est en train de trouver ses limites. Là sur ce type de slide, je vous préviens d'avance, retenez surtout ce qui se passe à droite. C'est le plus important. Et le client-side aujourd'hui, ça désigne la façon historique de faire du tracking qui va reposer essentiellement sur du JavaScript. Donc typiquement, c'est ce que vous appelez les tags et ce qui vous permet d'envoyer des requêtes vers vos différents partenaires. Ça s'appuie sur un triptyque, librairies JavaScript qui vont être injectées sur les sites, requêtes qui partent vers les différents partenaires depuis le navigateur d'utilisateur et des cookies qui sont déposées pour maintenir l'identité d'utilisateur dans le temps. C'est là que les cookie-firsts et leurs limitations deviennent importants, et notamment le sujet Safari dont je parlais précédemment, parce qu'un cookie-first qui auparavant pouvait durer 13 mois, dans un contexte Safari, ne va durer que 7 jours, ce qui forcément va affecter la façon de monitorer les personnes, de monitorer les fenêtres d'attribution, et d'être en mesure de consolider une même personne à l'échelle de plusieurs visites. Pour résumer un peu ça, au niveau des navigateurs, on va avoir... En gros, deux approches. On va avoir l'approche Safari et Firefox, et d'autres navigateurs comme Brave par exemple, qui va être extrêmement mieux disant sur la partie privacy. Ça fait un moment que les cookies tiers sont bloqués sur ces navigateurs-là, ça fait un moment que les cookies first deviennent de plus en plus limités, et ça fait un moment que les acteurs de la tech développent des contournements pour essayer de prolonger cette durée de vie de cookie. Parallèlement à ça, on a Chrome, qui a fait la une récemment, mais qui repose encore énormément sur ses cookies tiers, qui ne limite pas les cookies first, etc. On a vraiment des approches très différentes en fonction des navigateurs, et dans le choix que vous allez faire du server-side, il faut aussi se poser la question de votre mix de navigateurs et des gens qui visitent vos sites. Si vous avez énormément de gens qui viennent de Safari, la question du server-side devient de plus en plus importante. Sachant qu'à terme, à mon avis et de l'avis du marché, Chrome risque de s'aligner sur ce type de restrictions parce que c'est ce que les utilisateurs veulent et la tendance vers la privacy est de plus en plus importante pour les navigateurs. Je vais essayer de vous donner une petite vision de ce que c'est le client-side versus le server-side, les serveurs-tous-serveurs, etc. On a différentes manières de traquer les choses aujourd'hui. Ça va rentrer un petit peu dans la technique, et j'en suis désolé d'avance, je vous ai mis des petits schémas quand même pour expliquer, mais c'est important de comprendre ces différences pour comprendre en quoi le server-side apporte aujourd'hui une amélioration sur à la fois la technique et la façon d'envoyer les informations, mais également une amélioration au niveau de la gouvernance et divers bénéfices dont je parlerai après. La première approche est l'approche historique, c'est ce qu'on appelle le tracking client-side, l'approche traditionnelle. Donc c'est de ce dont je parle initialement, vous avez un tag qui s'exécute sur votre navigateur, qui va envoyer des informations à un partenaire et qui va déposer des cookies. Donc je parle d'un tag et c'est probablement une erreur, on devrait parler de 15 à 30 tags. En général quand vous avez votre écosystème digital, ça ne va pas être juste un tag Google Analytics ou un tag Piano Analytics, ça va être... un tag Google, un tag Piano, un tag Snapchat, un tag je ne sais quoi, qui vont tous faire exactement le même fonctionnement et tous déposer une librairie JavaScript sur votre site, tous faire des appels vers différents serveurs et tous déposer des cookies. Donc tout ça, c'est un modèle, comme je l'ai dit, qui s'essouffle et qui est hyper JavaScript dépendant et qui va faire dégrader les performances de votre site parce que vous allez avoir énormément de choses qui se passent dessus et une logique complexe qui est portée par le navigateur de votre utilisateur qui va en souffrir forcément. A côté de ça, on a le tracking server-side. C'est le sujet principal de ce webinaire et c'est probablement la méthode la plus déployée aujourd'hui dans les nouvelles méthodes de tracking. J'aime bien appeler ça la méthode proxification parce que pour moi, c'est plus visuel. Le tracking server-side repose avant tout sur l'utilisation d'un serveur intermédiaire qui vous appartient. Ce serveur intermédiaire va vous permettre de dispatcher l'information que vous allez collecter de manière unique vers les différents partenaires que vous allez avoir. Au lieu d'avoir les 15 tags dont je parlais qui sont injectés côté client, vous n'allez plus en avoir qu'un seul qui va se charger de l'ensemble de votre collecte et qui va vous permettre ensuite de dispatcher vers votre Facebook, vers votre Google Analytics, votre Piano et j'en sais rien, tous vos partenaires. La différence, c'est que vous allez créer un coût. C'est-à-dire que vous avez ce serveur au milieu qui n'existait pas auparavant et ce serveur, il va falloir s'en occuper. Vous pouvez vous en occuper vous-même, vous pouvez déléguer l'occupation à des partenaires externes. mais dans tous les cas, ça crée une nouvelle expertise que vous allez devoir maîtriser au milieu. Et enfin, on va avoir ce qu'on appelle le tracking server-to-server. J'aime bien en parler parce que c'est une idée qui me plaît énormément. Le tracking server-to-server, l'idée, c'est de ne même pas passer par le navigateur d'utilisateur. C'est un luxe que tous les sites ne peuvent pas se permettre parce que c'est quelque chose qui demande des allers-retours serveurs très réguliers entre le site et le navigateur d'utilisateur. on a besoin d'avoir un site qui est fort en interaction pour pouvoir se permettre du déploiement de serveurs. Historiquement, ça servait énormément pour traquer les achats de manière plus fine. Aujourd'hui, le tracking serveur-tour-serveur peut être déployé de manière beaucoup plus at scale sur des écosystèmes qui sont typiquement des sites de réservation, s'y prêtent très bien. Si en revanche, vous avez un site édito, le serveur-tour-serveur, c'est très difficile à mettre en place parce que tout se passe sur le navigateur de client. Il n'y a pas d'interaction serveur. à chaque fois que vous cliquez sur un bouton, que vous faites un scroll par exemple. Donc difficile de mettre en place ce type de tracking. Et ça demande une maîtrise technique qui est beaucoup plus élevée. Pour vous donner un peu plus de vision, je vais repasser sur les différents cas, le client-side, donc l'approche traditionnelle. Je parle du principe que vous utilisez maintenant des tag managers parce que c'est devenu assez répandu, mais l'idée est la même si vous n'en utilisez pas. Tout se passe côté client, les différentes librairies s'exécutent côté client, c'est envoyé depuis le navigateur de vos utilisateurs. vers les serveurs de vos différents partenaires. Votre tag Facebook s'exécute, il envoie un paquet de choses vers les serveurs de Facebook depuis le navigateur. Le server site tracking, donc la proxification, là, on part du principe qu'on va avoir un simple point de collecte qui est côté client et qui va se servir pour l'ensemble des partenaires qu'on a. Donc ça permet d'économiser énormément de bonnes passantes et d'économiser énormément de JavaScript, etc. Et ça vous permet d'avoir un seul point de collecte rationalisé. et de maîtriser complètement l'information que vous allez envoyer à vos différents partenaires. Et c'est au niveau du serveur que vous maîtrisez vous, que vous allez faire ce dispatch vers les différents partenaires que vous avez. Pour vous donner une idée de ce que ça peut représenter avec des partenaires réels, et c'est très indicatif évidemment, ça s'adapte à vos écosystèmes respectifs, on va avoir par exemple un Google Tag Manager qui va être déployé côté client, qui va nous permettre de... d'injecter un client qui va lui transmettre toutes les informations à notre serveur et c'est dans notre serveur qu'on fera un dispatch vers nos différents partenaires. J'ai également mis un tag ABT-steam et ça pourrait être un tag Houghton Square ou d'autres technos qui continue d'être injecté depuis le site directement parce que tout n'est pas compatible server-side. Ça c'est important de le comprendre aussi, il y a certains tags et certaines technologies qui ne se prêtent pas à la technologie server-side et qui devront continuer à être injectés directement sur le navigateur d'utilisateur. Et c'est généralement des technologies qui demandent d'écouter énormément ce qui se passe sur le site. Content Square par exemple, il va y avoir des hitmaps qui vont demander énormément d'aller-retour avec le réseau et qui demandent forcément d'avoir un tag qui continue à être déployé côté client. Et enfin, on a le server-to-server, qui est l'approche très moderne et compliquée encore une fois à mettre en place pour beaucoup de sites, qui est de dire, je n'ai pas de point de collecte sur mon site directement. Ma collecte part uniquement de mes interactions serveur et de typiquement à chaque fois que j'interroge une API de mon côté pour un site de réservation, à chaque fois que je mets à jour mon panier, il y a un appel qui va partir, je peux l'exploiter pour envoyer des informations. Et en gros, c'est cette vision qu'il faut avoir pour le serveur tout serveur. Plus d'interactions côté client, tout se passe côté serveur. C'est encore une fois très rarement quelque chose qui est mis en place à 100% et on a souvent des dispositifs hybrides. Et de manière générale, vous pouvez considérer que les trois alternatives que j'ai montrées ne sont pas mutuellement exclusives et que tout peut être géré de façon hybride en fonction des partenaires que vous avez. Parlons maintenant des bénéfices. Il faut distinguer pour moi deux catégories de bénéfices. Les bénéfices que j'appelle principaux et directs, et ensuite les bénéfices secondaires. Les bénéfices principaux, tous les gens d'industrie retombent à chaque fois à peu près sur les mêmes trois piliers. Je ne vais pas faire mon intéressant en rajouter un quatrième ou en enlever un. On a en gros la gouvernance, la performance, au sens web performance encore une fois, et la qualité de la donnée. Pour la gouvernance, tout vient du fait d'avoir un point de collecte unique. Le point de collecte unique nous offre un luxe exceptionnel, c'est de pouvoir rationaliser totalement notre collecte et de choisir exactement les informations qu'on va envoyer à nos différents partenaires. Contrairement à ce qui se passait avant, où concrètement je pouvais injecter mon tag Facebook sur mon site et mon tag Facebook par défaut si je ne lui dis pas... ne prend pas d'initiative, lui il va aller chercher de l'info à droite à gauche sur mon site sans que je maîtrise forcément quelle information il va aller chercher. Et l'information qu'il va aller chercher, ce ne sera probablement pas la même que mon tag TikTok, qui aura été cherché sensiblement la même chose, mais un peu de façon différente. Ce qui crée de l'incohérence aussi dans la donnée qu'on récupère et qui crée aussi des points de fuite inconnus sur la donnée qui est envoyée. Et ça, ce qui est très problématique, et je pense que les gens du domi sont sensibles. C'est très compliqué de maîtriser ce qu'un partenaire fait en JavaScript et du jour au lendemain, il peut faire évoluer sa librairie et récoter de la donnée personnelle sans faire exprès alors que vous avez fait tout ce qu'il fallait de votre côté pour pas que ça arrive. Donc le server-side permet vraiment d'améliorer cet aspect-là. Le deuxième, c'est la performance. La performance, l'équation, elle est très simple. Je repars du principe où vous aviez 15 partenaires avant. Ça voulait dire 15 tags. Ça voulait dire potentiellement plein de transformations, exécutation de navigateurs de votre utilisateur pour envoyer un objet produit d'une certaine façon pour Facebook, d'une autre façon pour votre Google Analytics, etc. Et de nombreux appels qui sont faits vers des serveurs extérieurs. Tout ça, ça a un coût en termes de webperf, ça coûte des millisecondes. Et des millisecondes, ça veut dire de l'expérience utilisateur dégradée et ça veut dire potentiellement un référencement dégradé. Aujourd'hui, si vous êtes très sensible à la perf, le server-side, ça apporte vraiment une plus-value intéressante. Donc, vous devez... Bien évidemment, mettre en confrontation avec les coûts que ça représente. Mais en tout cas, c'est une vraie solution pour limiter ce qui se passe sur votre site. Donc côté server-side, on a une seule librairie, des transformations qui sont toutes effectuées sur votre serveur, donc qui ne vont pas coûter au navigateur votre utilisateur. Et en seule apparence, le serveur, c'est celui qui est fait vers le vôtre, qui est ensuite dispatché sans que ça impacte votre utilisateur. Et le dernier point qui est important, c'est la data quality. La Data Quality intervient à plusieurs niveaux. C'est à la fois, les déploiements SavantSite permettent en gros de pouvoir enrichir l'information qu'on va avoir et qu'on va envoyer à nos partenaires de manière dynamique via le serveur qu'on va mettre en place. Et généralement, les cas d'usage les plus fréquents, c'est j'enrichis ma donnée que je collecte sur mon site avec des informations CRM via des clés de matching que je peux utiliser. Je peux également enrichir mes données de conversion avec des données de marge pour mes... améliorer mon bidding côté médias. Je peux faire plein de cas d'usage comme ça qui sont très intéressants à faire côté serveur. Et je pense que vous avez vu plein de choses sur les réseaux qui peuvent vous donner plein d'idées sur comment exploiter la technologie server-side dans cet aspect-là. Et aujourd'hui, ça apporte une agilité qui était très difficile d'avoir en client-side. Je pense également aux transformations et au nettoyage. La cohérence de données entre les différents partenaires, c'est un truc qui est très important et qui est très dur à maintenir quand on est dans du client-side. Dans du server-side, les outils généralement qui se situent à ce niveau-là, type un gtm server-side, un TDA Mainstream ou un Command-Ors Act, permettent de faire beaucoup de transformations et de normaliser la donnée qu'on partage au partenariat. Et ensuite, après, c'est les bénéfices. directs, on a les bénéfices que j'appelle indirects, qui sont plus des conséquences et des petites plus-values qu'on doit prendre en compte. La première, elle n'est pas si petite que ça, vous allez me dire, mais moi je préfère toujours la temporiser un peu parce que j'ai peur de ce jeu du chat et de la souris. La première, c'est l'accomptement ITP. Donc ITP, c'est ce dont je vous parlais au départ sur les initiatives de Safari pour limiter le tracking cross-site et pour éviter que les cookies et les différents storage... local storage, session storage, soit utilisée à des fins de suivi marketing non voulu par les utilisateurs. Donc ça se manifeste par un ensemble d'initiatives qui durent depuis cinq ans, qui ont été progressives et d'une espèce de jeu du chat et de la souris entre les contournements et ce que faisait Apple pour petit à petit dégrader le fonctionnement des cookies et qui fait qu'aujourd'hui comme je disais tout à l'heure, on a par défaut des cookies Analytics qui vont être limités à 7 jours. et des cookies médias qui nous sont parfois limités à un jour. Ce qui limite forcément les fenêtres d'attribution et votre vision de ce qu'est un utilisateur. Aujourd'hui, certains déploiements server-side, et c'est important là aussi de dire certains et pas tous, vont permettre de faire un contournement de ça et de maintenir le cookie beaucoup plus longtemps dans le temps que sur les navigateurs Safari. Ça demande l'utilisation de beaucoup de techniques, et ça je vous inviterais à lire la partie de gauche, mais notamment du Reader's Proxy, etc., que permettent de faire Santa Partner. Moi je pense à... On a l'habitude de bosser avec HeadingWell, il permet de le faire assez facilement sans trop se prendre la tête. Mais c'est en tout cas des contournements qui aujourd'hui permettent de récupérer une durée de vie utilisateur qui est intéressante côté Safari et qui était perdue depuis un moment. Également, et ça c'est un sujet qui va toucher particulièrement Didomi, le server-side permet de faire énormément de choses masquées. Et c'est important de dire que ce n'est pas parce qu'il te permet de le faire qu'il faut le faire. Et là, en l'occurrence, ce n'est même pas il ne faut pas le faire, c'est il ne faut absolument pas le faire. C'est de ne pas passer le consentement des utilisateurs et de ne pas le prendre en compte pour envoyer les informations à vos partenaires. Dans l'absolu, ce qui se passe pour votre utilisateur, c'est qu'il va avoir une enquête qui part vers votre serveur, mais derrière, il ne sait pas si votre serveur a pris en compte son consentement ou pas. Dans l'absolu, si l'utilisateur a dit non, Moi, je pourrais choisir de quand même des camps. C'est mon tas qui va vers méta. Mais ce n'est pas ce que nous, on a envie de mettre en valeur et ce n'est pas ce que Didomi a envie de mettre en valeur non plus. Nous, on veut que cette technologie server-side, elle soit vue comme un élément de facilitateur technique pour gérer ce consentement de manière normalisée et intelligente et également une opportunité pour offrir des preuves de consentement aux utilisateurs et pour les rassurer sur ce qu'on fait de leurs données. Parce que ça doit être vu comme ça, le server-side, c'est une façon de... pas faire fuir la donnée, d'avoir un meilleur contrôle sur ce qu'on envoie et sur les infos qu'on envoie à propos d'un utilisateur. Il ne faut pas le voir comme une façon de contourner une réglementation, ce qui serait par ailleurs illégal. Et le deuxième point qui est plus controversé, et moi j'ai un côté chevalier blanc là-dessus, mais qui n'est pas forcément partagé par tout le monde, c'est le sujet des adblockers. Aujourd'hui, avec certains déploiements server-side, il est possible de contourner les adblockers des utilisateurs. J'ai tendance à penser que si un utilisateur utilise un adblocker, il y a... peut-être une vocation à respecter son choix et après chercher à le contourner. Je comprends aussi que la donnée est importante et que vous pouvez vouloir la récupérer quand même. En tout cas, ce sont des questions qu'il faut se poser quand on fait un déploiement en server-side et ce sont des choses qui sont possibles à faire à voir comment ça peut être amené aux différents utilisateurs. Avant de passer à la suite, quelques limites, parce que je ne suis pas là pour vous dire que c'est la panacée, que le server-side c'est... ça résout tous vos problèmes et que c'est exceptionnel. Non, le server-side, ça a des limites. Au-delà de ce que je disais précédemment sur les partenaires, c'est-à-dire que tous les partenaires ne sont pas compatibles avec le server-side d'aujourd'hui, et on ne peut pas envisager, c'est rare de pouvoir envisager un déploiement à 100% server-side, il y a également des nouveaux coûts qui apparaissent. C'est-à-dire que vous avez un serveur intermédiaire qui n'existait pas auparavant, et c'est encore plus vrai pour du server-to-server, et ce qui va engendrer forcément des coûts. Il y a des coûts de maintenance, il y a des choses qui vont varier en fonction du trafic. Typiquement, si vous avez un site à gros trafic, ça va nécessairement augmenter le prix du serveur que vous avez au milieu et qui va gérer l'ensemble de vos requêtes. C'est quelque chose à prendre en compte quand on part sur un déploiement Server-Send. Il y a également une maintenance qui est plus complexe parce qu'on rentre dans un nouveau métier. Il y a des outils et des partenaires qui permettent de déléguer cette maintenance-là. Mais si vous souhaitiez de la gérer vous-même, parce que c'est une possibilité, c'est un métier à gérer, c'est des équipes qui étaient sollicitées pour d'autres sujets qui vont être sollicitées pour du tracking maintenant. Et encore une fois, c'est une expertise qui ne s'acquiert pas par magie. Et il y a une vraie nouvelle expertise, et c'est ça davantage de mon point de vue que je le dis, et c'est également quelque chose qui demande une montée en cours. compétences, c'est du nouveau vocabulaire, c'est des choses qui sont différentes à comprendre, des dynamiques côté serveur qui sont un peu différentes, des notions de header, de requête qui n'existaient pas forcément dans nos métiers, et qui demandent, même si c'est pas nécessaire d'absolument tout comprendre en tant que client, mais qui demandent d'avoir ce petit vernis pour au moins comprendre les enjeux et quelles sont potentiellement les limitations d'un déploiement. Je te laisse la main loin pour peut-être parler de la partie privacy. Merci. On va continuer du coup. On va passer sur le prochain slide. En fait, je vais beaucoup valider ce que Quentin vous a déjà dit auparavant, mais en rajoutant cette dimension consentement, on vient de voir qu'il y a des traitements de données qui sont faits côté server side. Donc, il dit traitement de données, normalement, on dit consentement. Donc, ce consentement, il faut toujours le collecter. Et cette collecte de consentement, comme on l'a dit, il faut vraiment la respecter tout le long du parcours. Non seulement il faut la collecter, il faut la garder en cas d'audit, et il faut pouvoir la transmettre aux parties qui sont utilisées. On parlait justement que ce soit des tag managers, que ce soit des serveurs tiers, que ce soit d'autres technologies. Donc en fait, c'est un petit peu la légitimité de Didomi dans le server-side, c'est qu'à partir du moment où on va faire des choses dans une espèce de boîte noire, à partir du moment où ça va être opaque, on va vouloir amener la dimension server-side sur une manière de consentement, on va devoir instruire... le client, l'utilisateur sur ce qu'on fait. Sur la première dimension de la bannière, on va lui dire qu'on utilise du server-side, on fait ce type de traitement de données. Sur la deuxième partie de la bannière et la troisième qui ont toutes les préférences, tous les traitements de données, tous les vendeurs, on va devoir justement mentionner ce qu'on fait pour avoir cette transparence. Il faut quand même un petit peu rassurer l'utilisateur, il faut pouvoir lui dire ce qui se passe côté server-side, il faut légitimiser. légitimiser l'utilisation du server-side tout en les rassurant. On a déjà cette pratique, nous l'IDOMI, je prends un petit peu de temps pour parler de ça, grâce au cross-device, on va associer un consentement à un ID, et en fait, le fait de synchroniser des consentements grâce à un ID faisait déjà un petit peu d'opacité pour l'utilisateur. Donc on a plusieurs méthodes qui ont été mises en place, entre autres l'utilisation verbale dans la bannière. On peut avoir des bannières de réassurance, de rappel pour dire qu'est-ce qui se passe à l'utilisateur, etc. Donc ça va être vraiment le server-side, ça va être cette nouvelle dimension un petit peu opaque où on veut que le consentement soit amené du client jusqu'au server-side. Avant de sauter tête baissée dans comment est-ce qu'on transmet ce consentement, qu'est-ce qu'on fait, de nouveau, j'aimerais valider notre vision d'un point de vue consentement sur les enjeux client-side. avec justement la petite pincée de sel consentement privacy. Donc on a bien la disparition ou la fin en tout cas des cookies tiers. C'est un problème pour le consentement. On faisait beaucoup de cross-domaine grâce à ça. On se reposait sur des cookies tiers justement pour passer le consentement grâce à un sous-domaine d'un domaine à un autre. On ne peut plus faire ça. L'impact, 5 à 10% de taux d'opt-in minimum, j'ai envie de dire, parce que justement ça permettait de synchroniser beaucoup les taux de consentement. Donc ça va être le premier impact, ça va être un taux de consentement qui descend. Si votre taux de consentement descend, on en vient à une utilisation moindre du server-side. Si on n'a que 60% de gens qui disent oui au traitement de données dans le server-side, on n'avait que 60% de l'audience qui partira server-side. Donc l'enjeu ici, ça va vraiment être de pouvoir maximiser tout ce genre de choses. Pareil, le consentement avec Safari, un consentement qui avant durait 12 mois, 6 mois en France par exemple, ne va durer que quelques jours. De nouveau, on va constamment redemander un consentement à l'utilisateur. Ça peut devenir embêtant, l'utilisateur peut être frustré, il peut refuser directement au bout d'un moment. De nouveau, perte complète des consentements. On en vient dans les années 2020 à avoir des taux de consentement qui étaient à 80-90%, qui étaient très élevés. Et puis là, on voit une baisse significante qui continue de descendre avec des taux de consentement qui vont avoisiner les 70-60%, certains acteurs même qui n'ont pas forcément tous les... les outils qu'on a vont descendre même plus bas que 50%. On va avoir une utilisation des consentements par des tiers de plus en plus. On parle justement dans un des slides de Quentin, on voyait l'enrichissement par une CDP ou par un CRM ou un outil tiers. Donc ce consentement, non seulement il va partir dans du server-side, mais il va partir dans d'autres technologies, donc il y a beaucoup de gestion et de complexification qui vont se faire. On va avoir de la diversification également de ce consentement avec les frameworks. On a l'IAB version 2.2, le Google Consent Mode V2, le GPC qui est récupérer le consentement dans un navigateur, le GPP, l'équivalent de l'IAB pour les États-Unis, etc. Donc ça devient très complexe, on va dire, le consentement. Rajouter le server-side, on peut... vraiment commencer à avoir des problèmes de compréhension et l'augmentation des adblockers. Quentin l'a dit, les adblockers vont diminuer les ads, tout ce qui est JavaScript sur le site web. Le problème, c'est que Didomi a besoin de charger un JavaScript pour montrer quelque chose qu'il a inside, et donc on est bloqué. Là, on a quand même des chiffres, on a plus d'un milliard de personnes qui utilisent des adblockers. Potentiellement, c'est des gens qui ne vont pas avoir une manière de consentement. On ne collecte pas de consentement, on ne traite pas la donnée. Donc ça va... être un petit peu tous ces problèmes, tous ces enjeux qu'on va avoir d'un point de vue consentement et qui vont potentiellement avoir un impact direct ou indirect avec le server-side. Donc, qu'est-ce qu'on voit en 2025 ? Le server-side, ça va vous permettre de refaire du cross-domain. Quentin l'a justement énoncé, on va avoir un ID server-side qui va être persistant dans Safari, dans d'autres navigateurs. On va pouvoir donc se reposer dessus. On va pouvoir utiliser ce fameux cross-device que je vous disais plus tôt. On associe un ID à un consentement et on peut très bien prendre cet ID server-side par exemple pour se dire, ben voilà, on associe le consentement server-side à l'utilisateur et donc on le renouvelle tous les six jours, par exemple, parce qu'il est resynchronisé quand l'utilisateur revient. Pareil, on parle de Safari, le consentement qui expire au bout d'un moment, ben pareil, on associe le consentement server-side, donc l'ID server-side au consentement et on le régénère, on le refait à chaque fois que l'utilisateur revient, donc on repousse. sa durée de vie, toujours d'un point de vue légal. D'un point de vue légal, le consentement dure 6 mois, on peut le faire sur 6 mois, et au bout de 6 mois, par exemple, on fait en sorte que le consentement expire bel et bien, et on remet par exemple une fenêtre de consentement, et on resynchronise le consentement à ce moment-là avec l'ID server-side. Donc, bienvenue, je n'essaie pas de vous dire, on fait des petites choses cachées, on fait des choses opaques, comme Quentin le disait, ça peut très vite devenir le Far West et le Western dans le server-side, là c'est vraiment, on suit toute la partie privacy. Tout ce qui est complexification des frameworks, ça ne va pas avoir un impact direct avec le server-side. Par contre, ce qui va être sympa, c'est que tous ces frameworks, il y a un espèce de tampon, il y a une espèce de signature, il y a un consentement qui est généré spécifiquement pour des partenaires et ça va être un moyen intéressant de le basculer, par exemple, server-side, ou de le basculer directement à des serveurs. Par exemple, on peut voir avec Google ConsentMode V2, très simple. on peut envoyer directement le consentement à Google Analytics et, comme le disait Quentin, Google Analytics peut activer tout d'un coup la partie server-side. Donc nous, par défaut, on va pouvoir déjà s'interfacer avec un GTM server-side très facilement. On va avoir tout ce qui est IAB, etc. Pareil, on pourrait très bien imaginer de passer le consentement IAB server-side pour que, côté server-side, on puisse réutiliser cette information, l'enrichir et, pourquoi pas, l'envoyer à des tiers. Et enfin, c'est plus ou moins ce que je viens de dire, mais... la capture du consentement dans des architectures server-side ou server-to-server, il ne faut pas oublier ce que j'ai dit plus tôt, tout ce qu'on va faire d'un point de vue consentement, il va falloir l'horodater, il va falloir garder en mémoire que cette bannière a été montrée à tel utilisateur à telle heure, qu'on a bien mentionné le server-side, le server-to-server, qu'on a bien ses acteurs, qu'on a bien ses préférences qui sont utilisées, ses traitements de données, donc il faut vraiment avoir quand même une CMP qui est un petit peu server-side ready, on ne peut pas aller directement avec une CMP... faites maison directement dans une architecture serveur side il va y avoir des petites modifications des petites choses à faire quand même pour ramener tout ça et donc c'est là où on aimerait quand même insister parce que comme l'a dit Quentin je suis un peu du même bord on va dire chevalier blanc en disant que ben voilà pour l'adblock pour des gens qui refusent le consentement etc un refus de consentement nous on va le redater on va le voir dans le prochain slide on va voir comment ce consentement se propage dans le client-side et dans le server-side, mais on va vraiment s'assurer, nous, d'Idomi, que non seulement il est propagé correctement, mais qu'en plus, on a une preuve de consentement qui puisse prouver à n'importe quel moment aux autorités, mais aussi au client lui-même s'il fait une demande. Alors, ce n'est pas tous les jours que Mme Micheline va venir vous demander si le server-side est bien respecté. Cependant, si elle le demande, il faut quand même pouvoir lui expliquer. Sur la bannière 1, 2, 3, 4, on a bien mentionné le server-side et vous avez bien cliqué à 10h59 depuis... votre navigateur Safari pour dire que vous acceptez le consentement pour une durée de 6 mois. Donc ça va être ce genre de choses que nous on va vous ramener, entre autres avec ce module de version Endproof. Je mentionnais... La propagation du consentement. Alors de nouveau, je vais essayer de valider ce que Quentin vous a dit. Donc j'ai repris ces diagrammes. On voit plusieurs choses. Donc déjà, complètement à gauche, on va voir le consentement d'Idomi. Une personne qui voit une fenêtre et qui la refuse. J'ai spécifiquement mis la redoute. C'est un petit spoiler, on va vous parler de la redoute qui a mis en place le server side. Donc en gros, une personne refuse la CMP, la redoute. Qu'est-ce qui se passe ? Notre CMP est sur un client side. Donc il y a un JavaScript d'Idomi qui se lance. le consentement va être montré, on va l'envoyer directement au tag manager client-side. Et, comme le disait Quentin, c'est très rare qu'on soit dans des architectures où il y ait vraiment tout qui soit basculé du côté server-side, à moins, comme il disait, d'avoir vraiment très peu d'enjeux d'un point de vue analytique, etc., ou très peu de choses qui chargent sur le front. Beaucoup de gens, médias, advertisers, etc., vont avoir des besoins en JavaScript sur le client-side. Donc... besoin d'un consentement client-side et donc le tag manager client-side a son effet. C'est pour ça que nous, on va déjà envoyer le consentement dans le tag manager client-side. Ce consentement ensuite, on va utiliser soit les frameworks, comme on vous a dit un peu plus tôt, par exemple Google Analytics, qui va automatiquement l'envoyer au tag manager server-side, soit on va utiliser par exemple une requête HTTP, une balise JSON HTTP pour avoir le tag manager qui l'envoie à son server-side tag manager. Et donc... propager le consentement server-side et pouvoir activer ou désactiver les différents acteurs. Et c'est là où le travail de Quentin prend tout son sens, parce qu'il va falloir migrer ces tags, il va falloir comprendre le consentement client-side, il va falloir le recomprendre sur le server-side, il va falloir s'assurer de sa bonne propagation. L'idée, ce n'est pas de refuser la bannière client-side, mais d'avoir tout d'un coup les médias server-side qui s'activent. Donc, ça va être toute cette chaîne de consentement. qui va être basculé et qui va venir. On peut voir ici aussi, je me suis un petit peu amusé, c'est le même graphique, le même diagramme, mais avec un choix granulaire, on va activer, désactiver ou accepter certaines parties. Et donc, ça va être des choses qui vont se refléter directement server-side à chaque fois. Donc de nouveau, vous avez tout ce qui est versionning, l'épreuve de consentement, on s'assure de la bonne propagation. Et derrière, vous avez Quentin, Digital Linker, Sequency qui s'assureront que toute l'implémentation est bien faite. Il faudra bien entendu maintenir tout ça. Didomi va vous aider à maintenir les vendeurs qui font du server-side, leur traitement de données, etc. Par contre, s'il y a un nouveau tag, un nouveau pixel, un nouveau cookie, un nouveau serveur média ou analytique qui vient, il faudra le configurer. C'est un peu ce travail récurrent de maintenance qu'il faudra prendre en compte dans la mise en place non seulement d'une CMP server-side, mais d'un server-side. Merci vraiment, c'est une bonne transition pour parler du déploiement et de comment ça se passe quand on veut commencer un projet server-side. Le déploiement, on va retomber finalement sur plus ou moins les mêmes étapes à chaque fois et la première est vraiment la plus clé et celle qui va probablement déterminer vos choix et l'ensemble de ce que vous allez faire derrière en termes de déploiement. Cette première étape, c'est l'inventaire des partenaires, c'est de comprendre avec qui vous travaillez, quelle est leur compatibilité server-side quelle est la faisabilité de la migration vers du server-side. Et c'est le premier panorama de vos partenaires, au-delà du fait de vous permettre de faire un bilan, parce que c'est intéressant, je vous assure, de faire l'exercice de regarder l'ensemble des tags qui sont injectés sur vos sites pour savoir si un peu tout est encore nécessaire. Et ça permet de justement se projeter, OK, j'ai 30% de mes tags qui ont besoin de rester côté client, j'en ai 70% que je peux faire passer côté server-side. Du coup, ça a vraiment un intérêt de passer sur une archi server-side first et de vraiment embrasser ce choix. Derrière, une fois qu'on a fait cet inventaire de partenaires, l'étape suivante, c'est choisir une approche technique. Encore une fois, la question, ce n'est pas tellement d'avoir une approche totalement fixe, c'est de se dire quel niveau d'hybridation je veux dans mon installation et aussi quel type de hosting je veux avoir pour mon serveur intermédiaire. Il y a des choses, j'ai parlé d'Anigwell, mais il y a du Steep, il y a d'autres acteurs qui font ça. des partenaires qui permettent de complètement déléguer la partie serveur par exemple et de ne pas s'occuper de ça parce que vous estimez que ce n'est pas votre métier ou que vous n'avez pas forcément les ressources pour le faire. Vous pouvez aussi le gérer vous-même. C'est typiquement des archis Cloud Run, des archis AWS, etc. que vous pouvez gérer vous-même. Et vous pouvez aussi passer par des acteurs dont c'est le métier complètement, type Tidium ou Commander's Act, qui vont avoir des briques server-side qui sont totalement embarquées pour eux, qui font à la fois la partie TMS et à la fois la partie hosting. Donc ça, c'est une partie très importante aussi et qui va dépendre à la fois des partenaires, à la fois de votre budget, de votre maturité sur ces thématiques de serveurs, etc. La suite, c'est assez simple, c'est la migration de la configuration. Le but étant de reproduire ce que vous aviez côté client et de le faire côté serveur dans votre TMS server side. Généralement, il y a peut-être des sacrifices à faire, des approches un peu différentes à avoir et des nouvelles logiques à avoir aussi sur des tracking server side. Ça repose beaucoup sur des tokens. C'est important de comprendre ces nouvelles mécaniques et c'est pour ça que c'est important de se faire accompagner pour faire ces migrations-là. Derrière, la partie importante, c'est aussi de configurer votre CMP. Donc, c'est ça. Quand je parle de configuration d'ACMP, ce n'est pas tant l'ACMP en elle-même que les conditionnements qui en découlent. Ça veut dire la chaîne dont parlait Laurent, à faire passer et à bien conditionner ses tags en fonction de ça. Le fonctionnement, finalement, n'est pas très différent de ce qu'on fait côté client. On exploite une chaîne de consentement qui est soit par finalité, soit par vendeur, dont on va se servir pour bloquer les différents connecteurs qu'on va avoir avec nos partenaires. Derrière, ce qu'on choisit de faire en général, c'est une phase de double run sur ces configurations server-side et client-side qui nous permet un peu de comparer les chiffres. et de voir là où on pourrait avoir des trous dans la raquette, où ça pourrait être amélioré. Et derrière, classique, une resaténuration avec ces configurations server-side qui sont en place. Et ça, c'est ce type de chantier qu'on a pu mettre en place avec Didomi, notamment sur la partie CMP, sur la Redoute, la Redoute que vous connaissez très certainement, qui a un écosystème média très développé et qui a une vraie maturité sur ces sujets-là. On a bossé avec Tilium, server-side, là-dessus. Il y a aussi un peu de JTM Server, ça, sur certains aspects. Il y a eu plein, plein de sujets intéressants sur ce client. Je ne suis pas intervenu directement tout au long de la mission pour être franc avec vous, mais j'ai fait toute la partie du début, c'était hyper intéressant, et beaucoup de réflexions au niveau des différents partenaires médias, et ça a vraiment orienté la façon dont on a réfléchi l'architecture. Et voilà, et DidoMe a été aussi une partie importante à prendre en compte pour faciliter la gestion du consentement. et l'envoi des informations aux différents partenaires. Je pense qu'on a fait le point. Un rapide point, pour juste enrichir dessus, on parle de la redoute spécifiquement, il y avait dans ton diagramme une partie un petit peu enrichissement CDP, par exemple. C'est un petit peu peut-être même l'ouverture, parce qu'il y a beaucoup d'acteurs, potentiellement vous, qui avaient mis en place des CDP, des CAM, qui souhaitent activer de la donnée, l'enrichir. Le server-side, c'est une très bonne transition, c'est un très bon pont, en fait, pour justement... utiliser ces outils, comment enrichir la donnée et comment la rendre disponible. Que ce soit, préférablement avec un consentement et avec Didomi, mais en tout cas via le server-side, avoir Quentin qui vous aide justement à avoir toutes ces informations et les enrichir avant l'envoi. Donc maximiser quand même le ROI sur vos server-side et sur votre CDP, sur tous ces systèmes tiers. Exactement, je valide totalement ton propos là-dessus. Et ouais, il y a beaucoup de cas d'usages très intéressants en server-side. Et il faut... Il faut réfléchir à ces cas d'usage pour justifier le passage. Et vraiment, ça apporte notamment côté média de vrais bénéfices qui sont intéressants. Je ne sais pas si on a des questions. Alors Charlotte, je te vois parler, mais je ne t'entends pas. Désolée. Je pense que ça va mieux. C'est parfait. Pour l'instant, on n'a pas de questions, mais je voudrais savoir combien de temps ça prend de mettre en place une stratégie comme ça ? Le server size, ça va énormément dépendre de votre écosystème existant et de la largeur et de la taille et du nombre de partenaires que vous allez avoir. Un projet server-side, comme je le disais, il y a une phase de double run qui demande pas mal de temps et qui fait que ce n'est pas anodin à faire. Généralement, on compte en plusieurs mois pour passer sur un écosystème server-side qui n'est pas plusieurs mois de travail nécessairement, mais qui sont plusieurs mois d'observation pour bien s'assurer qu'on ne perd pas de données. Parce que l'essentiel d'un passage server-side, c'est de récolter davantage de données, mais aussi de ne pas avoir d'effet de bord qui viendrait qu'on perd pour x ou y raisons. une partie de la donnée qu'on avait auparavant. Donc c'est par ce côté très safe de ce type de déploiement qu'on prend du temps, mais c'est des projets généralement un peu d'envergure. Et dès lors qu'il y a une partie infra qui est gérée chez le client directement, ça peut prendre encore plus de temps. Si cette infra est déléguée à des partenaires externes, ça peut être plus facile à mettre en place et ça peut être plus facilement activable. Donc tout dépend des choix d'archives qui sont faits au départ. Tout dépend du nombre de partenaires que vous avez. Et il y a une phase incompressible pour moi de double run et de vérification de la qualité de la donnée que vous récoltez. Ok. J'ai une question de Franck qui demande quelles sont les limitations financières et comment évaluer le ROI ? Alors, c'est une très bonne question et c'est une question compliquée à répondre malheureusement. Sur les limitations financières, c'est les coûts. Concrètement, on va avoir des coûts d'infra qui n'existaient pas avant. On a un serveur à gérer. Un serveur à gérer, ce n'était pas quelque chose qu'on faisait auparavant. Avant, c'est chaque tag qui allait interroger le serveur de son partenaire directement. C'est chaque tech qui faisait tout le boulot d'envoyer l'information au partenaire. Là, c'est nous qui prenons cette charge de lead, qui prenons cette charge de load balancing potentiellement et de toute cette gestion serveur qu'auparavant on n'avait pas. Donc, ces coûts, ils peuvent soit être pris en interne, parce que si on a de la ressource pour gérer ces serveurs-là, soit être pris en externe, encore une fois, dans la délégation. Dans tous les cas, ils doivent être mis en rapport avec les gains côté médias. Et là, effectivement, c'est des choses intéressantes à analyser, mais pas toujours très simples. Sur du CAPI, par exemple, sur du Facebook, Il y a des choses très visibles dans l'interface qui vous montrent tout de suite l'incrément de conversion que vous allez avoir et l'incrément de qualité de données que vous allez avoir. Sur du Google Ads, c'est plus dur à vérifier. Il faut faire du double run, il faut comparer les résultats que vous aviez avant et après, sur des périodes exactes, etc. C'est plus dur à prouver. Ça, c'est des aspects purement marketing, mais vous avez aussi des aspects perf, et ça, c'est pour nous, de toute façon, difficile à quantifier. Mais si vous avez des indicateurs de web perf que vous souhaitez, vraiment amélioré et que le server-side est un moyen de gagner des milliseconds et de gagner de la vitesse de chargement et potentiellement des positions dans Google, c'est aussi quelque chose à prendre en compte dans le calcul du ROI sur ce type de déploiement. Tout ça pour conclure, en gros c'est très compliqué à évaluer, mais c'est des choses qu'on essaie de faire le plus possible avec les différents outils qu'on déploie, et c'est un peu dépendant des partenaires avec les Gaia Longos, et encore une fois... Facebook facilite énormément le travail, ce n'est pas le cas de tous les parties. Rajoutons juste la dimension consentement, vous allez voir également, normalement, une hausse du consentement. Avec Didomi, entre autres, les analytiques pourront vous permettre de voir votre consentement pour Safari spécifiquement. Donc, en fait, vous allez pouvoir créer un delta pour vous dire, tiens, au mois de mai, on avait, je dis n'importe quoi, 70% d'opt-in pour Safari. Tout d'un coup, grâce au server side et au prolongement du consentement, etc., on bascule à 82%. ça vous fait 12% de consentement en plus. Le ROI est facilement calculable, avec ce que Quentin vous a dit, c'est tout d'un coup, avec tous les métriques d'advertising, etc., de publicité, on va pouvoir vraiment voir le gain, le ROI qui sera fait. Merci pour cette réponse. Et j'ai une autre question de Sarah, plutôt sur le cas La Redoute. Est-ce que la solution server-side de La Redoute est in-house ou est-ce que c'est celle de Thillium ? Alors, pour le coup, c'est un peu des deux. Concrètement, il y a une grosse partie du déploiement serveur 7 qui est géré via Tilium. Pour certains cas d'usage, c'est un déploiement S2-S5 côté la redoute sur la plupart des points de tracking. C'est-à-dire que c'est les serveurs de la redoute qui envoient directement les infos à Tilium, qui va les dispatcher vers les partenaires. Et c'est le cas pour notamment les alliés de planier, toutes les interactions e-commerce, parce qu'un site e-commerce, il prête très bien. En revanche, il y a également des choses qui sont faites côté Google, parce que Google est un peu fermé dans son écosystème aujourd'hui, qui exploitent GTM Serverside. Donc, il va avoir, et ce GTM Serverside-là tourne sur l'infra de la redoute. Donc, il y a un écosystème qui est complexe, c'est la redoute, qui est hybride, et qui se sert à la fois d'une infrastructure déléguée côté Thelium, parce que c'est leur métier de fournir cette infrastructure en plus de leur outil, mais aussi une infra qui gère Inhouse pour la partie... SGTM dont ils se servent pour notamment améliorer la qualité de leur bidding sur Google Ads. Ok, merci, c'est très clair. Écoutez, je pense qu'on peut clore ce webinaire maintenant. Si vous avez des questions, Laurent et Quentin se tiennent à votre disposition pour continuer à échanger sur le sujet. Et n'hésitez pas à suivre Digital Linkers et Didomi sur LinkedIn pour eux. vous tenir au courant de nos prochains événements. Merci beaucoup à tous les deux pour ce webinaire. Merci à tous. Merci. À très bientôt. Bonne journée. A bientôt, au revoir. Au revoir.

Nous allons démarrer la session, je vais laisser nos deux spécialistes du sujet Laurent Werner, solution consultance chez Didomi et Quentin Bérard, stratégique expert digital analyst chez Digital Inker se présenter maintenant. Merci à tous les deux d'être avec nous ce matin. pour nous parler de ce sujet.

Bonjour tout le monde et merci de m'avoir invité. Mon nom c'est Laurent Werner, je travaille chez Didomi en tant que consultant en solution. Vous allez le voir un petit peu plus tard, mais l'idée c'est que j'ai une bonne compréhension de ce qu'on est capable de faire Didomi, ce qui se trouve un petit peu sur le marché d'un point de vue solution, best practice, entre autres server side. Et du coup avec tout ça, ça me permet d'aider non seulement mes collègues chez Didomi, mais aussi les partenaires, nos prospects, les clients.

à travailler sur des solutions, server side et un peu sur la partie projet également. Merci Laurent et moi Quentin Bérard, je suis stratégique expert digitaliste chez Digital Linkers et je m'occupe spécialement des sujets de collecte, donc de la partie tracking et je suis assez spécialisé sur la partie tracking server side et je suis ravi d'animer ce webinaire avec Dithomy. Avant de commencer, on va faire la traditionnelle présentation des entreprises. Je vais commencer avec Digital Linkers.

Digital Linkers, historiquement, on est une agence d'experts en data avec des métiers orientés de la collecte jusqu'à l'analyse de données et du CRO, avec également des analytics engineers. On a une grosse actualité que vous avez peut-être vue ces dernières semaines. On vient d'être acheté par E-Prency. On est très content d'intégrer un beaucoup plus gros groupe qui est spécialisé dans la transformation data.

digital, l'IA, et qui va nous aider à développer notre activité. On est ravis de les rejoindre et c'est une belle occasion pour commencer notre collaboration. Du coup, Laurent, je te laisse la main pour Didomi.

Merci. Et du coup, Didomi, on est sur le marché depuis 2016. On a été créé par trois fondateurs, Romain, Jawad et Raphaël. Romain et Jawad viennent déjà du monde de l'entreprenariat. Ils ont déjà monté une entreprise qu'ils avaient revendue à Mediamat dans le passé.

Donc on a une très bonne compréhension de ce monde d'entreprenariat, on a déjà une très bonne connaissance du monde du consentement, vu qu'on a été créé en même temps que le RGPD, et on commence maintenant à s'étendre bien entendu à l'international, avec tous les différents frameworks, consentements, privacy laws, etc. qu'on trouve sur le marché. Donc on travaille de plus en plus avec des partenaires, et entre autres avec Digital Linkers, pour justement mettre en place ces nouvelles stratégies, ces nouvelles technologies, ces nouvelles architectures. mises en place par nos clients et prospects communs.

Et on en vient donc au prochain slide. C'est ce qu'on fait ensemble avec Digital Linkers. On va donc mettre en place toutes ces solutions. Alors, pas que ServerSite. ServerSite, c'est le sujet d'aujourd'hui.

On a quand même fait d'autres implémentations ensemble. On va avoir des clients en commun. On a la Redwood, par exemple. On a Wonderbox, etc. Donc, on en a plusieurs de disponibles.

Et donc, avec Quentin, l'idée, c'est que très souvent, On va rajouter la vision partenariat dans nos engagements de prospection, de clientèle, une fois qu'on va voir que les projets sont un petit peu trop avancés, peut-être pour Didomi d'un point de vue d'implémentation, et qu'on a besoin par exemple d'une vue d'expert ou d'un petit peu de main d'oeuvre pour faire entre autres avec le server-side tout ce qui est migration, configuration, etc. On est très content de vous être partenaires avec Avedi Domain depuis quelques années déjà, puisqu'on partage les mêmes valeurs et on pense qu'on avance bien ensemble sur les différents clients avec lesquels on a pu collaborer. Pour vous donner un peu le plan général de ce qu'on va raconter, je vais vous présenter un petit peu ce que c'est le server-side de manière générale, le tracking. C'est un peu un mot-valise, comme il y en a beaucoup dans notre métier, et un mot à la mode qui désigne plusieurs réalités.

Je vais essayer de vous expliquer un peu ça, je vous demande de vous accrocher parce que je suis plutôt technique, donc de temps en temps je risque de dévier sur des choses qui sont un peu ardues à comprendre. Et dans un second temps, on essaiera d'aborder le sujet des bénéfices plus business, avant que je laisse la main à Laurent qui nous parle de la privacy dans le contexte server-side, et à la fin on vous parlera de comment ça se passe finalement un projet de déploiement server-side, et quelles sont les choses à prendre en compte avant de se lancer. Donc avant de parler même de c'est quoi le server-side, la question à se poser c'est le pourquoi.

Et aujourd'hui l'écosystème digital est en mutation, Ce n'est pas une mutation qui est récente, c'est une mutation qui date de quelque temps déjà. Et le premier élément qui a changé et qui continue de changer à travers le monde, c'est l'environnement réglementaire. Évidemment, en tant que Français et sur ce marché-là, on est très touchés parce qu'on a probablement une des réglementations les plus restrictives au niveau du dépôt de cookies.

Vous voyez régulièrement des manières de consentement sur l'ensemble des sites que vous pouvez visiter. Et cet environnement réglementaire restrictif, Il nous oblige à avoir un rapport à la donnée qui est différent. C'est-à-dire qu'auparavant, quand on faisait de l'analytics, on faisait du média, on ne se posait pas la question de j'allais perdre X% de ma donnée. Maintenant, quand je suis sur un site français, j'ai tendance à me dire, je vais perdre 40% à 30% de ma donnée de base sur les gens que je vais collecter.

Donc, ça donne un rapport très différent à ce que vous allez collecter et dans votre façon d'exploiter également. Parallèlement à ça, on va avoir des restrictions navigateurs qui sont apparues. Les restrictions navigateurs, alors...

On entend beaucoup parler de Chrome ces derniers temps, parce qu'il y a la fin des cookies tiers, etc., qu'ils ont finalement repoussé. C'est un sujet qui prend beaucoup de poids sur les réseaux et sur LinkedIn. Mais finalement, les vrais instigateurs de ces restrictions de navigateurs, c'est Apple, et ça fait un moment qu'ils ont lancé ça.

Et aujourd'hui, ça fait plus de 5-6 ans que Safari va apporter d'énormes restrictions à ce qu'on peut faire en termes de maintien des informations via des cookies. Et ça affecte énormément les mécanismes. client-side historique.

Et ça fait longtemps que les acteurs de la tech ont commencé à mettre en place des réactions à ça via des changements dans leur façon de traquer les interactions. Et à côté de ça, et finalement qui est une corollaire, c'est qu'on a des exigences utilisateurs qui sont à la hausse. Donc des exigences vis-à-vis du contrôle de leurs données.

Les gens sont conscients que leurs données est importante et qu'ils ne doivent pas la laisser partir comme vers n'importe quel acteur etc. Donc c'est quelque chose qui est assez présent et qui est présent notamment par l'utilisation de plus en plus de date blockers. Et il y a également une exigence pour les utilisateurs d'avoir une expérience qui soit positive et cette expérience positive passe de plus en plus par la performance, et quand je parle de performance je parle de webperf, et la capacité à des écosystèmes digitaux d'aller vite.

Donc face à tous ces nouveaux enjeux, on a un modèle client-side qui est en train de trouver ses limites. Là sur ce type de slide, je vous préviens d'avance, retenez surtout ce qui se passe à droite. C'est le plus important. Et le client-side aujourd'hui, ça désigne la façon historique de faire du tracking qui va reposer essentiellement sur du JavaScript.

Donc typiquement, c'est ce que vous appelez les tags et ce qui vous permet d'envoyer des requêtes vers vos différents partenaires. Ça s'appuie sur un triptyque, librairies JavaScript qui vont être injectées sur les sites, requêtes qui partent vers les différents partenaires depuis le navigateur d'utilisateur et des cookies qui sont déposées pour maintenir l'identité d'utilisateur dans le temps. C'est là que les cookie-firsts et leurs limitations deviennent importants, et notamment le sujet Safari dont je parlais précédemment, parce qu'un cookie-first qui auparavant pouvait durer 13 mois, dans un contexte Safari, ne va durer que 7 jours, ce qui forcément va affecter la façon de monitorer les personnes, de monitorer les fenêtres d'attribution, et d'être en mesure de consolider une même personne à l'échelle de plusieurs visites. Pour résumer un peu ça, au niveau des navigateurs, on va avoir... En gros, deux approches.

On va avoir l'approche Safari et Firefox, et d'autres navigateurs comme Brave par exemple, qui va être extrêmement mieux disant sur la partie privacy. Ça fait un moment que les cookies tiers sont bloqués sur ces navigateurs-là, ça fait un moment que les cookies first deviennent de plus en plus limités, et ça fait un moment que les acteurs de la tech développent des contournements pour essayer de prolonger cette durée de vie de cookie. Parallèlement à ça, on a Chrome, qui a fait la une récemment, mais qui repose encore énormément sur ses cookies tiers, qui ne limite pas les cookies first, etc. On a vraiment des approches très différentes en fonction des navigateurs, et dans le choix que vous allez faire du server-side, il faut aussi se poser la question de votre mix de navigateurs et des gens qui visitent vos sites. Si vous avez énormément de gens qui viennent de Safari, la question du server-side devient de plus en plus importante.

Sachant qu'à terme, à mon avis et de l'avis du marché, Chrome risque de s'aligner sur ce type de restrictions parce que c'est ce que les utilisateurs veulent et la tendance vers la privacy est de plus en plus importante pour les navigateurs. Je vais essayer de vous donner une petite vision de ce que c'est le client-side versus le server-side, les serveurs-tous-serveurs, etc. On a différentes manières de traquer les choses aujourd'hui. Ça va rentrer un petit peu dans la technique, et j'en suis désolé d'avance, je vous ai mis des petits schémas quand même pour expliquer, mais c'est important de comprendre ces différences pour comprendre en quoi le server-side apporte aujourd'hui une amélioration sur à la fois la technique et la façon d'envoyer les informations, mais également une amélioration au niveau de la gouvernance et divers bénéfices dont je parlerai après. La première approche est l'approche historique, c'est ce qu'on appelle le tracking client-side, l'approche traditionnelle.

Donc c'est de ce dont je parle initialement, vous avez un tag qui s'exécute sur votre navigateur, qui va envoyer des informations à un partenaire et qui va déposer des cookies. Donc je parle d'un tag et c'est probablement une erreur, on devrait parler de 15 à 30 tags. En général quand vous avez votre écosystème digital, ça ne va pas être juste un tag Google Analytics ou un tag Piano Analytics, ça va être...

un tag Google, un tag Piano, un tag Snapchat, un tag je ne sais quoi, qui vont tous faire exactement le même fonctionnement et tous déposer une librairie JavaScript sur votre site, tous faire des appels vers différents serveurs et tous déposer des cookies. Donc tout ça, c'est un modèle, comme je l'ai dit, qui s'essouffle et qui est hyper JavaScript dépendant et qui va faire dégrader les performances de votre site parce que vous allez avoir énormément de choses qui se passent dessus et une logique complexe qui est portée par le navigateur de votre utilisateur qui va en souffrir forcément. A côté de ça, on a le tracking server-side. C'est le sujet principal de ce webinaire et c'est probablement la méthode la plus déployée aujourd'hui dans les nouvelles méthodes de tracking. J'aime bien appeler ça la méthode proxification parce que pour moi, c'est plus visuel.

Le tracking server-side repose avant tout sur l'utilisation d'un serveur intermédiaire qui vous appartient. Ce serveur intermédiaire va vous permettre de dispatcher l'information que vous allez collecter de manière unique vers les différents partenaires que vous allez avoir. Au lieu d'avoir les 15 tags dont je parlais qui sont injectés côté client, vous n'allez plus en avoir qu'un seul qui va se charger de l'ensemble de votre collecte et qui va vous permettre ensuite de dispatcher vers votre Facebook, vers votre Google Analytics, votre Piano et j'en sais rien, tous vos partenaires. La différence, c'est que vous allez créer un coût. C'est-à-dire que vous avez ce serveur au milieu qui n'existait pas auparavant et ce serveur, il va falloir s'en occuper.

Vous pouvez vous en occuper vous-même, vous pouvez déléguer l'occupation à des partenaires externes. mais dans tous les cas, ça crée une nouvelle expertise que vous allez devoir maîtriser au milieu. Et enfin, on va avoir ce qu'on appelle le tracking server-to-server.

J'aime bien en parler parce que c'est une idée qui me plaît énormément. Le tracking server-to-server, l'idée, c'est de ne même pas passer par le navigateur d'utilisateur. C'est un luxe que tous les sites ne peuvent pas se permettre parce que c'est quelque chose qui demande des allers-retours serveurs très réguliers entre le site et le navigateur d'utilisateur.

on a besoin d'avoir un site qui est fort en interaction pour pouvoir se permettre du déploiement de serveurs. Historiquement, ça servait énormément pour traquer les achats de manière plus fine. Aujourd'hui, le tracking serveur-tour-serveur peut être déployé de manière beaucoup plus at scale sur des écosystèmes qui sont typiquement des sites de réservation, s'y prêtent très bien.

Si en revanche, vous avez un site édito, le serveur-tour-serveur, c'est très difficile à mettre en place parce que tout se passe sur le navigateur de client. Il n'y a pas d'interaction serveur. à chaque fois que vous cliquez sur un bouton, que vous faites un scroll par exemple.

Donc difficile de mettre en place ce type de tracking. Et ça demande une maîtrise technique qui est beaucoup plus élevée. Pour vous donner un peu plus de vision, je vais repasser sur les différents cas, le client-side, donc l'approche traditionnelle. Je parle du principe que vous utilisez maintenant des tag managers parce que c'est devenu assez répandu, mais l'idée est la même si vous n'en utilisez pas. Tout se passe côté client, les différentes librairies s'exécutent côté client, c'est envoyé depuis le navigateur de vos utilisateurs.

vers les serveurs de vos différents partenaires. Votre tag Facebook s'exécute, il envoie un paquet de choses vers les serveurs de Facebook depuis le navigateur. Le server site tracking, donc la proxification, là, on part du principe qu'on va avoir un simple point de collecte qui est côté client et qui va se servir pour l'ensemble des partenaires qu'on a. Donc ça permet d'économiser énormément de bonnes passantes et d'économiser énormément de JavaScript, etc.

Et ça vous permet d'avoir un seul point de collecte rationalisé. et de maîtriser complètement l'information que vous allez envoyer à vos différents partenaires. Et c'est au niveau du serveur que vous maîtrisez vous, que vous allez faire ce dispatch vers les différents partenaires que vous avez. Pour vous donner une idée de ce que ça peut représenter avec des partenaires réels, et c'est très indicatif évidemment, ça s'adapte à vos écosystèmes respectifs, on va avoir par exemple un Google Tag Manager qui va être déployé côté client, qui va nous permettre de...

d'injecter un client qui va lui transmettre toutes les informations à notre serveur et c'est dans notre serveur qu'on fera un dispatch vers nos différents partenaires. J'ai également mis un tag ABT-steam et ça pourrait être un tag Houghton Square ou d'autres technos qui continue d'être injecté depuis le site directement parce que tout n'est pas compatible server-side. Ça c'est important de le comprendre aussi, il y a certains tags et certaines technologies qui ne se prêtent pas à la technologie server-side et qui devront continuer à être injectés directement sur le navigateur d'utilisateur. Et c'est généralement des technologies qui demandent d'écouter énormément ce qui se passe sur le site.

Content Square par exemple, il va y avoir des hitmaps qui vont demander énormément d'aller-retour avec le réseau et qui demandent forcément d'avoir un tag qui continue à être déployé côté client. Et enfin, on a le server-to-server, qui est l'approche très moderne et compliquée encore une fois à mettre en place pour beaucoup de sites, qui est de dire, je n'ai pas de point de collecte sur mon site directement. Ma collecte part uniquement de mes interactions serveur et de typiquement à chaque fois que j'interroge une API de mon côté pour un site de réservation, à chaque fois que je mets à jour mon panier, il y a un appel qui va partir, je peux l'exploiter pour envoyer des informations. Et en gros, c'est cette vision qu'il faut avoir pour le serveur tout serveur.

Plus d'interactions côté client, tout se passe côté serveur. C'est encore une fois très rarement quelque chose qui est mis en place à 100% et on a souvent des dispositifs hybrides. Et de manière générale, vous pouvez considérer que les trois alternatives que j'ai montrées ne sont pas mutuellement exclusives et que tout peut être géré de façon hybride en fonction des partenaires que vous avez. Parlons maintenant des bénéfices. Il faut distinguer pour moi deux catégories de bénéfices.

Les bénéfices que j'appelle principaux et directs, et ensuite les bénéfices secondaires. Les bénéfices principaux, tous les gens d'industrie retombent à chaque fois à peu près sur les mêmes trois piliers. Je ne vais pas faire mon intéressant en rajouter un quatrième ou en enlever un.

On a en gros la gouvernance, la performance, au sens web performance encore une fois, et la qualité de la donnée. Pour la gouvernance, tout vient du fait d'avoir un point de collecte unique. Le point de collecte unique nous offre un luxe exceptionnel, c'est de pouvoir rationaliser totalement notre collecte et de choisir exactement les informations qu'on va envoyer à nos différents partenaires.

Contrairement à ce qui se passait avant, où concrètement je pouvais injecter mon tag Facebook sur mon site et mon tag Facebook par défaut si je ne lui dis pas... ne prend pas d'initiative, lui il va aller chercher de l'info à droite à gauche sur mon site sans que je maîtrise forcément quelle information il va aller chercher. Et l'information qu'il va aller chercher, ce ne sera probablement pas la même que mon tag TikTok, qui aura été cherché sensiblement la même chose, mais un peu de façon différente.

Ce qui crée de l'incohérence aussi dans la donnée qu'on récupère et qui crée aussi des points de fuite inconnus sur la donnée qui est envoyée. Et ça, ce qui est très problématique, et je pense que les gens du domi sont sensibles. C'est très compliqué de maîtriser ce qu'un partenaire fait en JavaScript et du jour au lendemain, il peut faire évoluer sa librairie et récoter de la donnée personnelle sans faire exprès alors que vous avez fait tout ce qu'il fallait de votre côté pour pas que ça arrive.

Donc le server-side permet vraiment d'améliorer cet aspect-là. Le deuxième, c'est la performance. La performance, l'équation, elle est très simple.

Je repars du principe où vous aviez 15 partenaires avant. Ça voulait dire 15 tags. Ça voulait dire potentiellement plein de transformations, exécutation de navigateurs de votre utilisateur pour envoyer un objet produit d'une certaine façon pour Facebook, d'une autre façon pour votre Google Analytics, etc.

Et de nombreux appels qui sont faits vers des serveurs extérieurs. Tout ça, ça a un coût en termes de webperf, ça coûte des millisecondes. Et des millisecondes, ça veut dire de l'expérience utilisateur dégradée et ça veut dire potentiellement un référencement dégradé.

Aujourd'hui, si vous êtes très sensible à la perf, le server-side, ça apporte vraiment une plus-value intéressante. Donc, vous devez... Bien évidemment, mettre en confrontation avec les coûts que ça représente. Mais en tout cas, c'est une vraie solution pour limiter ce qui se passe sur votre site. Donc côté server-side, on a une seule librairie, des transformations qui sont toutes effectuées sur votre serveur, donc qui ne vont pas coûter au navigateur votre utilisateur.

Et en seule apparence, le serveur, c'est celui qui est fait vers le vôtre, qui est ensuite dispatché sans que ça impacte votre utilisateur. Et le dernier point qui est important, c'est la data quality. La Data Quality intervient à plusieurs niveaux. C'est à la fois, les déploiements SavantSite permettent en gros de pouvoir enrichir l'information qu'on va avoir et qu'on va envoyer à nos partenaires de manière dynamique via le serveur qu'on va mettre en place.

Et généralement, les cas d'usage les plus fréquents, c'est j'enrichis ma donnée que je collecte sur mon site avec des informations CRM via des clés de matching que je peux utiliser. Je peux également enrichir mes données de conversion avec des données de marge pour mes... améliorer mon bidding côté médias. Je peux faire plein de cas d'usage comme ça qui sont très intéressants à faire côté serveur. Et je pense que vous avez vu plein de choses sur les réseaux qui peuvent vous donner plein d'idées sur comment exploiter la technologie server-side dans cet aspect-là.

Et aujourd'hui, ça apporte une agilité qui était très difficile d'avoir en client-side. Je pense également aux transformations et au nettoyage. La cohérence de données entre les différents partenaires, c'est un truc qui est très important et qui est très dur à maintenir quand on est dans du client-side.

Dans du server-side, les outils généralement qui se situent à ce niveau-là, type un gtm server-side, un TDA Mainstream ou un Command-Ors Act, permettent de faire beaucoup de transformations et de normaliser la donnée qu'on partage au partenariat. Et ensuite, après, c'est les bénéfices. directs, on a les bénéfices que j'appelle indirects, qui sont plus des conséquences et des petites plus-values qu'on doit prendre en compte. La première, elle n'est pas si petite que ça, vous allez me dire, mais moi je préfère toujours la temporiser un peu parce que j'ai peur de ce jeu du chat et de la souris.

La première, c'est l'accomptement ITP. Donc ITP, c'est ce dont je vous parlais au départ sur les initiatives de Safari pour limiter le tracking cross-site et pour éviter que les cookies et les différents storage... local storage, session storage, soit utilisée à des fins de suivi marketing non voulu par les utilisateurs.

Donc ça se manifeste par un ensemble d'initiatives qui durent depuis cinq ans, qui ont été progressives et d'une espèce de jeu du chat et de la souris entre les contournements et ce que faisait Apple pour petit à petit dégrader le fonctionnement des cookies et qui fait qu'aujourd'hui comme je disais tout à l'heure, on a par défaut des cookies Analytics qui vont être limités à 7 jours. et des cookies médias qui nous sont parfois limités à un jour. Ce qui limite forcément les fenêtres d'attribution et votre vision de ce qu'est un utilisateur.

Aujourd'hui, certains déploiements server-side, et c'est important là aussi de dire certains et pas tous, vont permettre de faire un contournement de ça et de maintenir le cookie beaucoup plus longtemps dans le temps que sur les navigateurs Safari. Ça demande l'utilisation de beaucoup de techniques, et ça je vous inviterais à lire la partie de gauche, mais notamment du Reader's Proxy, etc., que permettent de faire Santa Partner. Moi je pense à...

On a l'habitude de bosser avec HeadingWell, il permet de le faire assez facilement sans trop se prendre la tête. Mais c'est en tout cas des contournements qui aujourd'hui permettent de récupérer une durée de vie utilisateur qui est intéressante côté Safari et qui était perdue depuis un moment. Également, et ça c'est un sujet qui va toucher particulièrement Didomi, le server-side permet de faire énormément de choses masquées. Et c'est important de dire que ce n'est pas parce qu'il te permet de le faire qu'il faut le faire.

Et là, en l'occurrence, ce n'est même pas il ne faut pas le faire, c'est il ne faut absolument pas le faire. C'est de ne pas passer le consentement des utilisateurs et de ne pas le prendre en compte pour envoyer les informations à vos partenaires. Dans l'absolu, ce qui se passe pour votre utilisateur, c'est qu'il va avoir une enquête qui part vers votre serveur, mais derrière, il ne sait pas si votre serveur a pris en compte son consentement ou pas.

Dans l'absolu, si l'utilisateur a dit non, Moi, je pourrais choisir de quand même des camps. C'est mon tas qui va vers méta. Mais ce n'est pas ce que nous, on a envie de mettre en valeur et ce n'est pas ce que Didomi a envie de mettre en valeur non plus.

Nous, on veut que cette technologie server-side, elle soit vue comme un élément de facilitateur technique pour gérer ce consentement de manière normalisée et intelligente et également une opportunité pour offrir des preuves de consentement aux utilisateurs et pour les rassurer sur ce qu'on fait de leurs données. Parce que ça doit être vu comme ça, le server-side, c'est une façon de... pas faire fuir la donnée, d'avoir un meilleur contrôle sur ce qu'on envoie et sur les infos qu'on envoie à propos d'un utilisateur.

Il ne faut pas le voir comme une façon de contourner une réglementation, ce qui serait par ailleurs illégal. Et le deuxième point qui est plus controversé, et moi j'ai un côté chevalier blanc là-dessus, mais qui n'est pas forcément partagé par tout le monde, c'est le sujet des adblockers. Aujourd'hui, avec certains déploiements server-side, il est possible de contourner les adblockers des utilisateurs.

J'ai tendance à penser que si un utilisateur utilise un adblocker, il y a... peut-être une vocation à respecter son choix et après chercher à le contourner. Je comprends aussi que la donnée est importante et que vous pouvez vouloir la récupérer quand même. En tout cas, ce sont des questions qu'il faut se poser quand on fait un déploiement en server-side et ce sont des choses qui sont possibles à faire à voir comment ça peut être amené aux différents utilisateurs. Avant de passer à la suite, quelques limites, parce que je ne suis pas là pour vous dire que c'est la panacée, que le server-side c'est...

ça résout tous vos problèmes et que c'est exceptionnel. Non, le server-side, ça a des limites. Au-delà de ce que je disais précédemment sur les partenaires, c'est-à-dire que tous les partenaires ne sont pas compatibles avec le server-side d'aujourd'hui, et on ne peut pas envisager, c'est rare de pouvoir envisager un déploiement à 100% server-side, il y a également des nouveaux coûts qui apparaissent.

C'est-à-dire que vous avez un serveur intermédiaire qui n'existait pas auparavant, et c'est encore plus vrai pour du server-to-server, et ce qui va engendrer forcément des coûts. Il y a des coûts de maintenance, il y a des choses qui vont varier en fonction du trafic. Typiquement, si vous avez un site à gros trafic, ça va nécessairement augmenter le prix du serveur que vous avez au milieu et qui va gérer l'ensemble de vos requêtes.

C'est quelque chose à prendre en compte quand on part sur un déploiement Server-Send. Il y a également une maintenance qui est plus complexe parce qu'on rentre dans un nouveau métier. Il y a des outils et des partenaires qui permettent de déléguer cette maintenance-là.

Mais si vous souhaitiez de la gérer vous-même, parce que c'est une possibilité, c'est un métier à gérer, c'est des équipes qui étaient sollicitées pour d'autres sujets qui vont être sollicitées pour du tracking maintenant. Et encore une fois, c'est une expertise qui ne s'acquiert pas par magie. Et il y a une vraie nouvelle expertise, et c'est ça davantage de mon point de vue que je le dis, et c'est également quelque chose qui demande une montée en cours.

compétences, c'est du nouveau vocabulaire, c'est des choses qui sont différentes à comprendre, des dynamiques côté serveur qui sont un peu différentes, des notions de header, de requête qui n'existaient pas forcément dans nos métiers, et qui demandent, même si c'est pas nécessaire d'absolument tout comprendre en tant que client, mais qui demandent d'avoir ce petit vernis pour au moins comprendre les enjeux et quelles sont potentiellement les limitations d'un déploiement. Je te laisse la main loin pour peut-être parler de la partie privacy. Merci. On va continuer du coup. On va passer sur le prochain slide.

En fait, je vais beaucoup valider ce que Quentin vous a déjà dit auparavant, mais en rajoutant cette dimension consentement, on vient de voir qu'il y a des traitements de données qui sont faits côté server side. Donc, il dit traitement de données, normalement, on dit consentement. Donc, ce consentement, il faut toujours le collecter. Et cette collecte de consentement, comme on l'a dit, il faut vraiment la respecter tout le long du parcours. Non seulement il faut la collecter, il faut la garder en cas d'audit, et il faut pouvoir la transmettre aux parties qui sont utilisées.

On parlait justement que ce soit des tag managers, que ce soit des serveurs tiers, que ce soit d'autres technologies. Donc en fait, c'est un petit peu la légitimité de Didomi dans le server-side, c'est qu'à partir du moment où on va faire des choses dans une espèce de boîte noire, à partir du moment où ça va être opaque, on va vouloir amener la dimension server-side sur une manière de consentement, on va devoir instruire... le client, l'utilisateur sur ce qu'on fait.

Sur la première dimension de la bannière, on va lui dire qu'on utilise du server-side, on fait ce type de traitement de données. Sur la deuxième partie de la bannière et la troisième qui ont toutes les préférences, tous les traitements de données, tous les vendeurs, on va devoir justement mentionner ce qu'on fait pour avoir cette transparence. Il faut quand même un petit peu rassurer l'utilisateur, il faut pouvoir lui dire ce qui se passe côté server-side, il faut légitimiser.

légitimiser l'utilisation du server-side tout en les rassurant. On a déjà cette pratique, nous l'IDOMI, je prends un petit peu de temps pour parler de ça, grâce au cross-device, on va associer un consentement à un ID, et en fait, le fait de synchroniser des consentements grâce à un ID faisait déjà un petit peu d'opacité pour l'utilisateur. Donc on a plusieurs méthodes qui ont été mises en place, entre autres l'utilisation verbale dans la bannière.

On peut avoir des bannières de réassurance, de rappel pour dire qu'est-ce qui se passe à l'utilisateur, etc. Donc ça va être vraiment le server-side, ça va être cette nouvelle dimension un petit peu opaque où on veut que le consentement soit amené du client jusqu'au server-side. Avant de sauter tête baissée dans comment est-ce qu'on transmet ce consentement, qu'est-ce qu'on fait, de nouveau, j'aimerais valider notre vision d'un point de vue consentement sur les enjeux client-side. avec justement la petite pincée de sel consentement privacy. Donc on a bien la disparition ou la fin en tout cas des cookies tiers.

C'est un problème pour le consentement. On faisait beaucoup de cross-domaine grâce à ça. On se reposait sur des cookies tiers justement pour passer le consentement grâce à un sous-domaine d'un domaine à un autre.

On ne peut plus faire ça. L'impact, 5 à 10% de taux d'opt-in minimum, j'ai envie de dire, parce que justement ça permettait de synchroniser beaucoup les taux de consentement. Donc ça va être le premier impact, ça va être un taux de consentement qui descend. Si votre taux de consentement descend, on en vient à une utilisation moindre du server-side. Si on n'a que 60% de gens qui disent oui au traitement de données dans le server-side, on n'avait que 60% de l'audience qui partira server-side.

Donc l'enjeu ici, ça va vraiment être de pouvoir maximiser tout ce genre de choses. Pareil, le consentement avec Safari, un consentement qui avant durait 12 mois, 6 mois en France par exemple, ne va durer que quelques jours. De nouveau, on va constamment redemander un consentement à l'utilisateur.

Ça peut devenir embêtant, l'utilisateur peut être frustré, il peut refuser directement au bout d'un moment. De nouveau, perte complète des consentements. On en vient dans les années 2020 à avoir des taux de consentement qui étaient à 80-90%, qui étaient très élevés. Et puis là, on voit une baisse significante qui continue de descendre avec des taux de consentement qui vont avoisiner les 70-60%, certains acteurs même qui n'ont pas forcément tous les... les outils qu'on a vont descendre même plus bas que 50%.

On va avoir une utilisation des consentements par des tiers de plus en plus. On parle justement dans un des slides de Quentin, on voyait l'enrichissement par une CDP ou par un CRM ou un outil tiers. Donc ce consentement, non seulement il va partir dans du server-side, mais il va partir dans d'autres technologies, donc il y a beaucoup de gestion et de complexification qui vont se faire. On va avoir de la diversification également de ce consentement avec les frameworks. On a l'IAB version 2.2, le Google Consent Mode V2, le GPC qui est récupérer le consentement dans un navigateur, le GPP, l'équivalent de l'IAB pour les États-Unis, etc.

Donc ça devient très complexe, on va dire, le consentement. Rajouter le server-side, on peut... vraiment commencer à avoir des problèmes de compréhension et l'augmentation des adblockers.

Quentin l'a dit, les adblockers vont diminuer les ads, tout ce qui est JavaScript sur le site web. Le problème, c'est que Didomi a besoin de charger un JavaScript pour montrer quelque chose qu'il a inside, et donc on est bloqué. Là, on a quand même des chiffres, on a plus d'un milliard de personnes qui utilisent des adblockers. Potentiellement, c'est des gens qui ne vont pas avoir une manière de consentement. On ne collecte pas de consentement, on ne traite pas la donnée.

Donc ça va... être un petit peu tous ces problèmes, tous ces enjeux qu'on va avoir d'un point de vue consentement et qui vont potentiellement avoir un impact direct ou indirect avec le server-side. Donc, qu'est-ce qu'on voit en 2025 ?

Le server-side, ça va vous permettre de refaire du cross-domain. Quentin l'a justement énoncé, on va avoir un ID server-side qui va être persistant dans Safari, dans d'autres navigateurs. On va pouvoir donc se reposer dessus. On va pouvoir utiliser ce fameux cross-device que je vous disais plus tôt. On associe un ID à un consentement et on peut très bien prendre cet ID server-side par exemple pour se dire, ben voilà, on associe le consentement server-side à l'utilisateur et donc on le renouvelle tous les six jours, par exemple, parce qu'il est resynchronisé quand l'utilisateur revient.

Pareil, on parle de Safari, le consentement qui expire au bout d'un moment, ben pareil, on associe le consentement server-side, donc l'ID server-side au consentement et on le régénère, on le refait à chaque fois que l'utilisateur revient, donc on repousse. sa durée de vie, toujours d'un point de vue légal. D'un point de vue légal, le consentement dure 6 mois, on peut le faire sur 6 mois, et au bout de 6 mois, par exemple, on fait en sorte que le consentement expire bel et bien, et on remet par exemple une fenêtre de consentement, et on resynchronise le consentement à ce moment-là avec l'ID server-side.

Donc, bienvenue, je n'essaie pas de vous dire, on fait des petites choses cachées, on fait des choses opaques, comme Quentin le disait, ça peut très vite devenir le Far West et le Western dans le server-side, là c'est vraiment, on suit toute la partie privacy. Tout ce qui est complexification des frameworks, ça ne va pas avoir un impact direct avec le server-side. Par contre, ce qui va être sympa, c'est que tous ces frameworks, il y a un espèce de tampon, il y a une espèce de signature, il y a un consentement qui est généré spécifiquement pour des partenaires et ça va être un moyen intéressant de le basculer, par exemple, server-side, ou de le basculer directement à des serveurs. Par exemple, on peut voir avec Google ConsentMode V2, très simple. on peut envoyer directement le consentement à Google Analytics et, comme le disait Quentin, Google Analytics peut activer tout d'un coup la partie server-side.

Donc nous, par défaut, on va pouvoir déjà s'interfacer avec un GTM server-side très facilement. On va avoir tout ce qui est IAB, etc. Pareil, on pourrait très bien imaginer de passer le consentement IAB server-side pour que, côté server-side, on puisse réutiliser cette information, l'enrichir et, pourquoi pas, l'envoyer à des tiers. Et enfin, c'est plus ou moins ce que je viens de dire, mais...

la capture du consentement dans des architectures server-side ou server-to-server, il ne faut pas oublier ce que j'ai dit plus tôt, tout ce qu'on va faire d'un point de vue consentement, il va falloir l'horodater, il va falloir garder en mémoire que cette bannière a été montrée à tel utilisateur à telle heure, qu'on a bien mentionné le server-side, le server-to-server, qu'on a bien ses acteurs, qu'on a bien ses préférences qui sont utilisées, ses traitements de données, donc il faut vraiment avoir quand même une CMP qui est un petit peu server-side ready, on ne peut pas aller directement avec une CMP... faites maison directement dans une architecture serveur side il va y avoir des petites modifications des petites choses à faire quand même pour ramener tout ça et donc c'est là où on aimerait quand même insister parce que comme l'a dit Quentin je suis un peu du même bord on va dire chevalier blanc en disant que ben voilà pour l'adblock pour des gens qui refusent le consentement etc un refus de consentement nous on va le redater on va le voir dans le prochain slide on va voir comment ce consentement se propage dans le client-side et dans le server-side, mais on va vraiment s'assurer, nous, d'Idomi, que non seulement il est propagé correctement, mais qu'en plus, on a une preuve de consentement qui puisse prouver à n'importe quel moment aux autorités, mais aussi au client lui-même s'il fait une demande. Alors, ce n'est pas tous les jours que Mme Micheline va venir vous demander si le server-side est bien respecté. Cependant, si elle le demande, il faut quand même pouvoir lui expliquer. Sur la bannière 1, 2, 3, 4, on a bien mentionné le server-side et vous avez bien cliqué à 10h59 depuis...

votre navigateur Safari pour dire que vous acceptez le consentement pour une durée de 6 mois. Donc ça va être ce genre de choses que nous on va vous ramener, entre autres avec ce module de version Endproof. Je mentionnais... La propagation du consentement. Alors de nouveau, je vais essayer de valider ce que Quentin vous a dit.

Donc j'ai repris ces diagrammes. On voit plusieurs choses. Donc déjà, complètement à gauche, on va voir le consentement d'Idomi.

Une personne qui voit une fenêtre et qui la refuse. J'ai spécifiquement mis la redoute. C'est un petit spoiler, on va vous parler de la redoute qui a mis en place le server side. Donc en gros, une personne refuse la CMP, la redoute.

Qu'est-ce qui se passe ? Notre CMP est sur un client side. Donc il y a un JavaScript d'Idomi qui se lance.

le consentement va être montré, on va l'envoyer directement au tag manager client-side. Et, comme le disait Quentin, c'est très rare qu'on soit dans des architectures où il y ait vraiment tout qui soit basculé du côté server-side, à moins, comme il disait, d'avoir vraiment très peu d'enjeux d'un point de vue analytique, etc., ou très peu de choses qui chargent sur le front. Beaucoup de gens, médias, advertisers, etc., vont avoir des besoins en JavaScript sur le client-side.

Donc... besoin d'un consentement client-side et donc le tag manager client-side a son effet. C'est pour ça que nous, on va déjà envoyer le consentement dans le tag manager client-side. Ce consentement ensuite, on va utiliser soit les frameworks, comme on vous a dit un peu plus tôt, par exemple Google Analytics, qui va automatiquement l'envoyer au tag manager server-side, soit on va utiliser par exemple une requête HTTP, une balise JSON HTTP pour avoir le tag manager qui l'envoie à son server-side tag manager. Et donc...

propager le consentement server-side et pouvoir activer ou désactiver les différents acteurs. Et c'est là où le travail de Quentin prend tout son sens, parce qu'il va falloir migrer ces tags, il va falloir comprendre le consentement client-side, il va falloir le recomprendre sur le server-side, il va falloir s'assurer de sa bonne propagation. L'idée, ce n'est pas de refuser la bannière client-side, mais d'avoir tout d'un coup les médias server-side qui s'activent. Donc, ça va être toute cette chaîne de consentement. qui va être basculé et qui va venir.

On peut voir ici aussi, je me suis un petit peu amusé, c'est le même graphique, le même diagramme, mais avec un choix granulaire, on va activer, désactiver ou accepter certaines parties. Et donc, ça va être des choses qui vont se refléter directement server-side à chaque fois. Donc de nouveau, vous avez tout ce qui est versionning, l'épreuve de consentement, on s'assure de la bonne propagation.

Et derrière, vous avez Quentin, Digital Linker, Sequency qui s'assureront que toute l'implémentation est bien faite. Il faudra bien entendu maintenir tout ça. Didomi va vous aider à maintenir les vendeurs qui font du server-side, leur traitement de données, etc. Par contre, s'il y a un nouveau tag, un nouveau pixel, un nouveau cookie, un nouveau serveur média ou analytique qui vient, il faudra le configurer. C'est un peu ce travail récurrent de maintenance qu'il faudra prendre en compte dans la mise en place non seulement d'une CMP server-side, mais d'un server-side.

Merci vraiment, c'est une bonne transition pour parler du déploiement et de comment ça se passe quand on veut commencer un projet server-side. Le déploiement, on va retomber finalement sur plus ou moins les mêmes étapes à chaque fois et la première est vraiment la plus clé et celle qui va probablement déterminer vos choix et l'ensemble de ce que vous allez faire derrière en termes de déploiement. Cette première étape, c'est l'inventaire des partenaires, c'est de comprendre avec qui vous travaillez, quelle est leur compatibilité server-side quelle est la faisabilité de la migration vers du server-side.

Et c'est le premier panorama de vos partenaires, au-delà du fait de vous permettre de faire un bilan, parce que c'est intéressant, je vous assure, de faire l'exercice de regarder l'ensemble des tags qui sont injectés sur vos sites pour savoir si un peu tout est encore nécessaire. Et ça permet de justement se projeter, OK, j'ai 30% de mes tags qui ont besoin de rester côté client, j'en ai 70% que je peux faire passer côté server-side. Du coup, ça a vraiment un intérêt de passer sur une archi server-side first et de vraiment embrasser ce choix.

Derrière, une fois qu'on a fait cet inventaire de partenaires, l'étape suivante, c'est choisir une approche technique. Encore une fois, la question, ce n'est pas tellement d'avoir une approche totalement fixe, c'est de se dire quel niveau d'hybridation je veux dans mon installation et aussi quel type de hosting je veux avoir pour mon serveur intermédiaire. Il y a des choses, j'ai parlé d'Anigwell, mais il y a du Steep, il y a d'autres acteurs qui font ça.

des partenaires qui permettent de complètement déléguer la partie serveur par exemple et de ne pas s'occuper de ça parce que vous estimez que ce n'est pas votre métier ou que vous n'avez pas forcément les ressources pour le faire. Vous pouvez aussi le gérer vous-même. C'est typiquement des archis Cloud Run, des archis AWS, etc. que vous pouvez gérer vous-même.

Et vous pouvez aussi passer par des acteurs dont c'est le métier complètement, type Tidium ou Commander's Act, qui vont avoir des briques server-side qui sont totalement embarquées pour eux, qui font à la fois la partie TMS et à la fois la partie hosting. Donc ça, c'est une partie très importante aussi et qui va dépendre à la fois des partenaires, à la fois de votre budget, de votre maturité sur ces thématiques de serveurs, etc. La suite, c'est assez simple, c'est la migration de la configuration. Le but étant de reproduire ce que vous aviez côté client et de le faire côté serveur dans votre TMS server side.

Généralement, il y a peut-être des sacrifices à faire, des approches un peu différentes à avoir et des nouvelles logiques à avoir aussi sur des tracking server side. Ça repose beaucoup sur des tokens. C'est important de comprendre ces nouvelles mécaniques et c'est pour ça que c'est important de se faire accompagner pour faire ces migrations-là.

Derrière, la partie importante, c'est aussi de configurer votre CMP. Donc, c'est ça. Quand je parle de configuration d'ACMP, ce n'est pas tant l'ACMP en elle-même que les conditionnements qui en découlent.

Ça veut dire la chaîne dont parlait Laurent, à faire passer et à bien conditionner ses tags en fonction de ça. Le fonctionnement, finalement, n'est pas très différent de ce qu'on fait côté client. On exploite une chaîne de consentement qui est soit par finalité, soit par vendeur, dont on va se servir pour bloquer les différents connecteurs qu'on va avoir avec nos partenaires.

Derrière, ce qu'on choisit de faire en général, c'est une phase de double run sur ces configurations server-side et client-side qui nous permet un peu de comparer les chiffres. et de voir là où on pourrait avoir des trous dans la raquette, où ça pourrait être amélioré. Et derrière, classique, une resaténuration avec ces configurations server-side qui sont en place. Et ça, c'est ce type de chantier qu'on a pu mettre en place avec Didomi, notamment sur la partie CMP, sur la Redoute, la Redoute que vous connaissez très certainement, qui a un écosystème média très développé et qui a une vraie maturité sur ces sujets-là. On a bossé avec Tilium, server-side, là-dessus.

Il y a aussi un peu de JTM Server, ça, sur certains aspects. Il y a eu plein, plein de sujets intéressants sur ce client. Je ne suis pas intervenu directement tout au long de la mission pour être franc avec vous, mais j'ai fait toute la partie du début, c'était hyper intéressant, et beaucoup de réflexions au niveau des différents partenaires médias, et ça a vraiment orienté la façon dont on a réfléchi l'architecture. Et voilà, et DidoMe a été aussi une partie importante à prendre en compte pour faciliter la gestion du consentement.

et l'envoi des informations aux différents partenaires. Je pense qu'on a fait le point. Un rapide point, pour juste enrichir dessus, on parle de la redoute spécifiquement, il y avait dans ton diagramme une partie un petit peu enrichissement CDP, par exemple. C'est un petit peu peut-être même l'ouverture, parce qu'il y a beaucoup d'acteurs, potentiellement vous, qui avaient mis en place des CDP, des CAM, qui souhaitent activer de la donnée, l'enrichir.

Le server-side, c'est une très bonne transition, c'est un très bon pont, en fait, pour justement... utiliser ces outils, comment enrichir la donnée et comment la rendre disponible. Que ce soit, préférablement avec un consentement et avec Didomi, mais en tout cas via le server-side, avoir Quentin qui vous aide justement à avoir toutes ces informations et les enrichir avant l'envoi. Donc maximiser quand même le ROI sur vos server-side et sur votre CDP, sur tous ces systèmes tiers.

Exactement, je valide totalement ton propos là-dessus. Et ouais, il y a beaucoup de cas d'usages très intéressants en server-side. Et il faut...

Il faut réfléchir à ces cas d'usage pour justifier le passage. Et vraiment, ça apporte notamment côté média de vrais bénéfices qui sont intéressants. Je ne sais pas si on a des questions. Alors Charlotte, je te vois parler, mais je ne t'entends pas.

Désolée. Je pense que ça va mieux. C'est parfait.

Pour l'instant, on n'a pas de questions, mais je voudrais savoir combien de temps ça prend de mettre en place une stratégie comme ça ? Le server size, ça va énormément dépendre de votre écosystème existant et de la largeur et de la taille et du nombre de partenaires que vous allez avoir. Un projet server-side, comme je le disais, il y a une phase de double run qui demande pas mal de temps et qui fait que ce n'est pas anodin à faire.

Généralement, on compte en plusieurs mois pour passer sur un écosystème server-side qui n'est pas plusieurs mois de travail nécessairement, mais qui sont plusieurs mois d'observation pour bien s'assurer qu'on ne perd pas de données. Parce que l'essentiel d'un passage server-side, c'est de récolter davantage de données, mais aussi de ne pas avoir d'effet de bord qui viendrait qu'on perd pour x ou y raisons. une partie de la donnée qu'on avait auparavant. Donc c'est par ce côté très safe de ce type de déploiement qu'on prend du temps, mais c'est des projets généralement un peu d'envergure. Et dès lors qu'il y a une partie infra qui est gérée chez le client directement, ça peut prendre encore plus de temps.

Si cette infra est déléguée à des partenaires externes, ça peut être plus facile à mettre en place et ça peut être plus facilement activable. Donc tout dépend des choix d'archives qui sont faits au départ. Tout dépend du nombre de partenaires que vous avez.

Et il y a une phase incompressible pour moi de double run et de vérification de la qualité de la donnée que vous récoltez. Ok. J'ai une question de Franck qui demande quelles sont les limitations financières et comment évaluer le ROI ? Alors, c'est une très bonne question et c'est une question compliquée à répondre malheureusement.

Sur les limitations financières, c'est les coûts. Concrètement, on va avoir des coûts d'infra qui n'existaient pas avant. On a un serveur à gérer.

Un serveur à gérer, ce n'était pas quelque chose qu'on faisait auparavant. Avant, c'est chaque tag qui allait interroger le serveur de son partenaire directement. C'est chaque tech qui faisait tout le boulot d'envoyer l'information au partenaire.

Là, c'est nous qui prenons cette charge de lead, qui prenons cette charge de load balancing potentiellement et de toute cette gestion serveur qu'auparavant on n'avait pas. Donc, ces coûts, ils peuvent soit être pris en interne, parce que si on a de la ressource pour gérer ces serveurs-là, soit être pris en externe, encore une fois, dans la délégation. Dans tous les cas, ils doivent être mis en rapport avec les gains côté médias. Et là, effectivement, c'est des choses intéressantes à analyser, mais pas toujours très simples. Sur du CAPI, par exemple, sur du Facebook, Il y a des choses très visibles dans l'interface qui vous montrent tout de suite l'incrément de conversion que vous allez avoir et l'incrément de qualité de données que vous allez avoir.

Sur du Google Ads, c'est plus dur à vérifier. Il faut faire du double run, il faut comparer les résultats que vous aviez avant et après, sur des périodes exactes, etc. C'est plus dur à prouver.

Ça, c'est des aspects purement marketing, mais vous avez aussi des aspects perf, et ça, c'est pour nous, de toute façon, difficile à quantifier. Mais si vous avez des indicateurs de web perf que vous souhaitez, vraiment amélioré et que le server-side est un moyen de gagner des milliseconds et de gagner de la vitesse de chargement et potentiellement des positions dans Google, c'est aussi quelque chose à prendre en compte dans le calcul du ROI sur ce type de déploiement. Tout ça pour conclure, en gros c'est très compliqué à évaluer, mais c'est des choses qu'on essaie de faire le plus possible avec les différents outils qu'on déploie, et c'est un peu dépendant des partenaires avec les Gaia Longos, et encore une fois... Facebook facilite énormément le travail, ce n'est pas le cas de tous les parties.

Rajoutons juste la dimension consentement, vous allez voir également, normalement, une hausse du consentement. Avec Didomi, entre autres, les analytiques pourront vous permettre de voir votre consentement pour Safari spécifiquement. Donc, en fait, vous allez pouvoir créer un delta pour vous dire, tiens, au mois de mai, on avait, je dis n'importe quoi, 70% d'opt-in pour Safari.

Tout d'un coup, grâce au server side et au prolongement du consentement, etc., on bascule à 82%. ça vous fait 12% de consentement en plus. Le ROI est facilement calculable, avec ce que Quentin vous a dit, c'est tout d'un coup, avec tous les métriques d'advertising, etc., de publicité, on va pouvoir vraiment voir le gain, le ROI qui sera fait.

Merci pour cette réponse. Et j'ai une autre question de Sarah, plutôt sur le cas La Redoute. Est-ce que la solution server-side de La Redoute est in-house ou est-ce que c'est celle de Thillium ? Alors, pour le coup, c'est un peu des deux. Concrètement, il y a une grosse partie du déploiement serveur 7 qui est géré via Tilium.

Pour certains cas d'usage, c'est un déploiement S2-S5 côté la redoute sur la plupart des points de tracking. C'est-à-dire que c'est les serveurs de la redoute qui envoient directement les infos à Tilium, qui va les dispatcher vers les partenaires. Et c'est le cas pour notamment les alliés de planier, toutes les interactions e-commerce, parce qu'un site e-commerce, il prête très bien. En revanche, il y a également des choses qui sont faites côté Google, parce que Google est un peu fermé dans son écosystème aujourd'hui, qui exploitent GTM Serverside.

Donc, il va avoir, et ce GTM Serverside-là tourne sur l'infra de la redoute. Donc, il y a un écosystème qui est complexe, c'est la redoute, qui est hybride, et qui se sert à la fois d'une infrastructure déléguée côté Thelium, parce que c'est leur métier de fournir cette infrastructure en plus de leur outil, mais aussi une infra qui gère Inhouse pour la partie... SGTM dont ils se servent pour notamment améliorer la qualité de leur bidding sur Google Ads. Ok, merci, c'est très clair.

Écoutez, je pense qu'on peut clore ce webinaire maintenant. Si vous avez des questions, Laurent et Quentin se tiennent à votre disposition pour continuer à échanger sur le sujet. Et n'hésitez pas à suivre Digital Linkers et Didomi sur LinkedIn pour eux. vous tenir au courant de nos prochains événements. Merci beaucoup à tous les deux pour ce webinaire.

Merci à tous. Merci. À très bientôt. Bonne journée.

A bientôt, au revoir. Au revoir.

Transcript for:Webinar sur le Traçage Server-Site

Transcript for:
Webinar sur le Traçage Server-Site