Au programme de cette édition Réacteur de juin 2026 :

• SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search, par Lou Pichard
• Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA, par David Groult et Erwann Cardon
• Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites, par Indiana Aflalo
• Pourquoi vous continuez de produire du contenu… pour rien [partie 2], par Killian Le Moal
• Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline, par Sylvain Deauré

On remercie chaleureusement nos 6 auteurs et autrices pour leur réactivité et surtout la qualité des articles publiés : Indiana Aflalo, Lou Pichard, David Groult, Erwann Cardon, Killian Le Moal et Sylvain Deauré.

En bonus : comme à l’accoutumée, cette nouvelle édition accueille également notre veille de juin 2026 et une présentation des outils qui ont retenu notre attention ces dernières semaine !

 Accéder à l’édition complète

Et, si ce n’est pas encore le cas, abonnez-vous !

SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search

Par Lou Pichard, directeur SEO chez Eskimoz Bordeaux

À découvrir dans cet article :

• SFCC est partout (Adidas, Lacoste, Sandro, Maje...), mais reste l'un des CMS les moins documentés du marché. 2025 change la donne : refonte du centre d'aide et arrivée de l'agent IA AgentForce directement dans la doc.
• SFRA vs Composable Storefront : deux architectures, deux logiques SEO radicalement différentes. Sitemap, canoniques, SSR, Core Web Vitals... tout change selon le Core Model choisi.
• Les modules natifs les plus puissants de SFCC enfin expliqués clairement : URL Rules, Page Meta Tag Rules, et surtout les trois systèmes de redirection avec leur ordre de priorité (celui qui débloque des heures de débogage).
• Pas de .htaccess, pas de Schema.org natif : les vraies limites de la plateforme et comment les contourner avec du développement ciblé.
• Le virage Agentic Commerce arrive. Avec le partenariat Stripe-OpenAI, votre catalogue SFCC devra bientôt être lisible par les agents IA avant même de l'être par Google.

Ce qu'on a aimé :

Un vrai travail de démystification d'une plateforme réputée fermée et où la connaissance se transmet surtout en interne ou en agence. L'article de Lou Pichard rentre dans le détail opérationnel : ordre de priorité des modules de redirection, dépendance entre données catalogue et meta tags, méthodologie pour découper un cahier des charges SEO en trois briques (natif, configuration, développement custom). Exactement le genre de repères qu'on cherche en vain dans la documentation officielle de Salesforce. Pas de théorie creuse, mais des seuils précis et des outils actionnables. Un article sans concession, qui en fera réfléchir plus d’un !

SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search

Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA

Par David Groult, Head of SEO et Erwann Cardon, Consultant SEO Senior @NOIISE

À découvrir dans cet article :

• 8 marques, 8 secteurs, 8 logiques différentes. Autant d'exemples concrets de fiches produit qui transforment vraiment la décision d'achat.
• Le simulateur de taille ASOS analysé en détail. Comment une marque transforme l'incertitude de taille en preuve sociale personnalisée, avec un impact direct sur les retours et la marge.
• LDLC ou comment une caractéristique technique devient un levier SEO. Relier chaque spécification produit à une page de facette crée un maillage qui sert autant l'utilisateur que le crawler.
• Une grille de lecture en 5 types de gains d'information pour savoir précisément ce qui manque sur vos fiches.
• Une checklist d'audit complète pour évaluer vos fiches produit avec un regard neuf, au-delà du title et du H1.

Ce qu'on a aimé :

L'angle adopté est rare : au lieu d'une liste de bonnes pratiques génériques, l'article décortique huit cas réels et explique précisément pourquoi chaque dispositif fonctionne, sans tomber dans le name dropping superficiel. La distinction entre les différents types de gains d'information donne une grille de lecture immédiatement actionnable, et l'avertissement final sur le risque de surcharge évite l'écueil classique du « ajoutez toujours plus de contenu ».

Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA

Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites

Par Indiana Aflalo, consultante SEO/GEO et fondatrice d’IndHack

À découvrir dans cet article :

• Une victoire à 139 mentions, mais portée à 80% par seulement deux IA sur cinq. L'analyse moteur par moteur révèle des comportements radicalement différents entre Claude, Mistral, ChatGPT, Perplexity et Gemini.
• Les sept piliers d'une méthode GEO complète… avec des exemples de code à l'appui.
• Le « fan-out » expliqué à travers une architecture concrète. Un hub et dix pages alignées sur les sous-intentions que les IA génèrent en arrière-plan pour construire leurs réponses.
• L'effet « winner-takes-all » sur Mistral, observé en conditions réelles. Comment un moteur peut citer jusqu'à six URLs d'un même domaine dans une seule réponse, une fois la source identifiée comme dominante.
• Les échecs documentés sans filtre. Reddit banni, Wikidata refusé, robots.txt qui bloque les bots IA pendant 24h... Et ce qu’il faut en retenir.

Ce qu'on a aimé :

Une transparence rare sur ce qui n'a pas marché autant que sur ce qui a marché. Indiana Aflalo ne se contente pas d'annoncer une victoire, elle décortique pourquoi Claude et Mistral ont réagi alors que Gemini et Perplexity sont restés hermétiques, avec des hypothèses précises pour chaque moteur. La distinction entre ce qui se transpose à un vrai site et ce qui ne se transpose pas (le contexte artificiel du concours) donne à l'article une vraie valeur méthodologique, au-delà du simple récit de performance.

Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites

Pourquoi vous continuez de produire du contenu… pour rien [partie 2]

Par Killian Le Moal, Lead GEO-SEO Strategist & Innovation @ Peak Ace agency

À découvrir dans cet article :

• Un « stress test » en 3 questions à faire passer à ChatGPT sur vos 200 premiers mots.
• L'anatomie d'un chunk citable, avec un exemple avant/après bluffant. Deux versions de même longueur, un potentiel de citation radicalement différent.
• Les chiffres de fan-out par LLM qui changent tout. De 22,6 % chez ChatGPT à 98,7 % chez Gemini, avec des conséquences concrètes sur la façon de structurer vos pages.
• Trois « fausses bonnes idées » du GEO déconstruites avec des données… Ce qui marche vraiment et ce qui est une perte de temps.
• Une nouvelle grille de KPIs pour mesurer la visibilité dans les IA génératives, en complément du SEO classique.

Ce qu'on a aimé :

Le côté très opérationnel de cette deuxième partie : chaque concept s'accompagne d'un protocole, d'un exemple concret ou d'un chiffre sourcé, jusqu'à la checklist actionnable en fin d'article. La déconstruction des mythes GEO (llms.txt, Markdown, pages longues) tranche avec le discours ambiant et s'appuie sur des études récentes plutôt que sur des intuitions. C'est le genre d'article qu'on garde sous la main pour auditer ses propres pages.

Pourquoi vous continuez de produire du contenu… pour rien [partie 2]

Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline

Par Sylvain Deauré, Co-fondateur de 1492.vision

À découvrir dans cet article :

• Plus de 20 pipelines Discover aux logiques radicalement différentes, basés sur l'analyse de 42 millions de cartes. La vraie question n'est plus « suis-je dans Discover », mais « dans combien de pipelines suis-je visible ».
• L'effet multiplicateur du multi-pipeline. 58 % des URLs françaises apparaissent dans 2 pipelines ou plus, avec des outliers qui en atteignent 12 à 14 simultanément.
• Le modèle Ouest-France décrypté : comment un double ancrage local + national permet d'atteindre 25 pipelines distincts, un record pour un éditeur traditionnel.
• Ce qui plafonne structurellement le multi-pipeline : test produit pur, sport quotidien, lifestyle... avec les leviers concrets pour en sortir.
• Un signal émergent à surveiller : un pipeline d'intake social a été multiplié par 33 en trois mois, alimenté à 72 % par X.com.

Ce qu'on a aimé :

Le scorecard par profil d'éditeur (presse nationale, presse régionale, tech/review, sport, lifestyle, vidéo) qui distingue précisément les pipelines naturels et ceux à conquérir : c'est immédiatement actionnable, on peut se situer et identifier ses marges de progression. Les cas concrets (Le Monde, Ouest-France, Frandroid, L'Equipe, programme-tv.net) avec leurs empreintes pipelines détaillés offrent une grille de lecture qu'on ne trouve nulle part ailleurs.

Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline

Comme tous les mois, cette nouvelle édition de Reacteur s’accompagne d’une rubrique dédiée aux derniers outils à tester et les articles qui ont retenus notre attention sur le web !

L’article "L’édition de juin 2026 de Réacteur est en ligne !" a été publié sur le site Abondance.

Article sponsorisé par Sedestral

Pourquoi la technique reste le parent pauvre des stratégies SEO

Dans la grande majorité des stratégies de référencement naturel, la répartition des efforts suit un schéma prévisible : le contenu d'abord, le netlinking ensuite, et le SEO technique quand on trouve le temps. Nulle négligence ici, mais plutôt une réalité opérationnelle. Produire des articles ou acquérir des liens génère des résultats plus visibles, plus facilement attribuables, plus faciles à valoriser en interne.

L'audit technique, lui, est perçu comme un chantier : il faut crawler le site, interpréter des rapports denses, prioriser des centaines de problèmes potentiels, puis les transmettre à des développeurs qui ont d'autres priorités.

Le résultat est souvent le même, avec des erreurs qui s'accumulent. Des pages importantes ne sont pas indexées. Des balises title sont dupliquées ou absentes. Des redirections mal configurées diluent le jus de liens. Des Core Web Vitals dégradés pénalisent le positionnement sur mobile. Aucun de ces problèmes n'est spectaculaire en soi, mais leur accumulation finit par peser lourd dans la balance des classements.

C'est précisément ce terrain que Nox, l'agent IA d'audit technique de Sedestral, a été conçu pour couvrir : transformer une tâche complexe, chronophage et souvent reportée en un processus continu et automatisé.

Ce que couvre réellement un audit SEO technique complet

Avant de comprendre ce que fait l’agent IA Nox, il est utile de rappeler l'étendue du périmètre qu'un audit technique rigoureux devrait couvrir. On parle rarement d'un seul type de vérification, mais d'une série de couches imbriquées.

• La première concerne la structure HTML et les balises. Chaque page doit disposer d'une balise title unique et optimisée, d'une méta description correctement renseignée, d'une hiérarchie de titres Hn cohérente. Des erreurs à ce niveau affectent directement la façon dont Google comprend et classe le contenu.
• La deuxième touche à l'indexation. Est-ce que le fichier robots.txt bloque involontairement des sections importantes ? Le sitemap.xml est-il à jour et correctement soumis ? Les balises canoniques sont-elles bien implémentées ? Les directives noindex sont-elles utilisées à bon escient, sans exclure des pages stratégiques ? Ces questions semblent techniques, mais leurs conséquences sont directement visibles dans les classements.
• La troisième dimension est celle de la performance et des Core Web Vitals. Google utilise ces signaux comme facteur de classement depuis 2021. Un site qui charge lentement à cause d'images non compressées, de scripts bloquants ou d'un cache mal configuré perd des positions, en particulier sur mobile.
• La quatrième englobe la sécurité et l'accessibilité : validité du certificat SSL, absence d'erreurs 4xx et 5xx, accessibilité mobile, conformité des données structurées.
• Enfin, pour les sites locaux, l'audit doit aussi vérifier la cohérence des informations NAP (nom, adresse, téléphone) et la configuration Google My Business.

Réaliser ce travail manuellement, de façon exhaustive, sur un site de plusieurs centaines de pages, représente plusieurs jours de travail. Et ce travail est à recommencer régulièrement, puisqu'un site évolue en permanence.

Agent IA vs outil d'audit classique : quelle différence concrète ?

Des outils comme Screaming Frog, Semrush ou Ahrefs permettent déjà de détecter une large part de ces problèmes. Mais leur output prend, par nature, la forme d’une liste. Parfois une très longue liste. Il revient ensuite à l'utilisateur d'interpréter chaque signal, d'évaluer sa gravité, de le mettre en contexte avec les objectifs du site et de décider quoi traiter en priorité. C'est à ce stade que la plupart des audits s’avèrent incomplets : faute de temps ou d'expertise, on traite les problèmes évidents et on ignore le reste.

Un agent IA comme Nox fonctionne différemment à deux niveaux : 

• D'abord, il ne se contente pas de signaler : il évalue l'impact SEO de chaque problème et établit une liste de correctifs classés par ordre de priorité. 
• Ensuite, pour chaque erreur identifiée, il explique clairement ce qui pose un problème et indique comment le corriger, étape par étape, dans un langage accessible. On passe d'un rapport brut à un plan d'action opérationnel.

C'est la différence structurelle entre un outil qui analyse et un agent qui raisonne. Le premier vous donne des données. Le second vous dit quoi faire avec.

Comment Nox audite concrètement votre site

Le processus de Nox s'articule autour de trois grandes phases d'analyse, menées de façon systématique sur l'ensemble des pages du site.

Analyse de la structure HTML et des balises SEO

Nox commence par inspecter le code HTML de chaque page. Il détecte les erreurs de structure, vérifie la conformité des balises title et méta descriptions (présence, unicité, longueur), contrôle la hiérarchie des titres Hn et identifie les problèmes qui impactent directement la lecture du contenu par les moteurs. Il relève aussi les erreurs de redirection (chaînes de redirections, redirections vers des pages en erreur) et vérifie la configuration du robots.txt et du sitemap.xml.

Test de performance et de sécurité

Nox teste ensuite votre site comme le ferait un véritable utilisateur, en mesurant les Core Web Vitals avec précision. Il identifie les éléments qui dégradent les performances : images non optimisées, scripts bloquant le rendu, gestion du cache insuffisante, problèmes d'affichage mobile. Il vérifie également la validité du certificat SSL et détecte les risques de sécurité associés.

Vérification de l'indexation en connexion avec Google Search Console

C'est l'une des dimensions les plus différenciantes de Nox. Au-delà de la vérification statique des balises canonical, des directives noindex et de la présence du sitemap, l'agent est capable d'appeler directement l'API Google Search Console. Cela lui permet de croiser les pages découvertes lors du crawl avec les données d'indexation réelles fournies par Google : une page est-elle effectivement connue de Google ? Est-elle indexée ?

Si ce n'est pas le cas, Nox peut la soumettre automatiquement à l'indexation, sans intervention manuelle. C'est ce qui permet de gérer l'indexation non pas comme un chantier ponctuel, mais comme un processus continu : chaque nouvelle page publiée, chaque page corrigée peut être soumise au bon moment, sans attendre le prochain crawl de Google.

Cette connexion avec la Search Console couvre également le contrôle des données structurées et de l'optimisation locale, notamment la vérification des informations NAP et de la fiche Google My Business pour les sites à dimension locale.

La priorisation : ce qui distingue un rapport utile d'une liste de problèmes à régler

Un audit complet sur un site de taille moyenne peut générer plusieurs centaines d'alertes. Sans hiérarchisation, ce volume peut être contre-productif : l'équipe ne sait pas par où commencer et finit souvent par ne rien traiter.

Nox évalue l'impact de chaque problème sur le référencement et établit une liste de correctifs classés par ordre de priorité. Ce classement n'est pas arbitraire, mais repose sur la nature de l'erreur et son poids potentiel sur le positionnement. Une balise title absente sur la page d'accueil n'a pas le même impact qu'une balise alt manquante sur une image secondaire. Une page stratégique bloquée par le robots.txt n'a pas le même impact qu'une redirection 301 sur une URL secondaire.

Pour une PME sans ressources techniques dédiées, ou pour une agence qui gère un portefeuille de sites clients, cette priorisation est décisive. Elle transforme un audit en plan d'action, avec une entrée claire. A savoir, commencer par le haut de la liste.

Ce que vous gardez sous contrôle

Comme pour les autres agents de Sedestral, Nox ne court-circuite pas la décision humaine sur les corrections à apporter. Il détecte, analyse, priorise et explique. Les modifications sur le site restent à votre main ou à celle de vos développeurs.

L'exception concerne la soumission à l'indexation via l'API Search Console, qui peut être gérée de façon automatisée par l'agent IA. C'est une action technique sans risque, qui ne modifie pas le contenu du site et qui, sans automatisation, représente une tâche répétitive chronophage.

Pour tout le reste, Nox produit un rapport détaillé et actionnable, avec les explications nécessaires pour que chaque correction puisse être appliquée sans expertise technique avancée. L'objectif est de rendre le SEO technique accessible à des équipes qui n'ont pas de consultant SEO à plein temps.

Les limites à garder en tête

Un agent IA d'audit technique ne remplace pas l'analyse contextuelle d'un consultant expérimenté face à des problématiques d'architecture complexes. Sur un site e-commerce avec des milliers de pages générées dynamiquement, des configurations de facettes ou des problèmes de contenu dupliqué à grande échelle, l'arbitrage stratégique reste avant tout humain.

De même, certains problèmes d'indexation ont des causes contextuelles que seule une lecture globale du site permet d'identifier, qu’il s’agisse d’une pénalité manuelle, une cannibalisation entre pages proches sémantiquement, ou une mauvaise gestion des paramètres d'URL sur un site international.

Ces limites ne remettent pas en question l'utilité de Nox, elles en précisent le périmètre optimal, que cela soit les PME, les e-commerçants et les agences qui gèrent plusieurs sites en parallèle. Dans ces cas, l'agent libère un temps d'expertise considérable pour les décisions stratégiques, en automatisant la détection, le tri et le guidage des corrections techniques.

L’article "SEO technique : comment un agent IA peut auditer et corriger votre site à votre place" a été publié sur le site Abondance.

Un retour aux sources vingt ans après

Sundar Pichai n'a prononcé qu'un seul autre discours de ce type auparavant, en 2020, en pleine pandémie de Covid. Il l'avait alors filmé depuis son jardin pour une cérémonie virtuelle, à une époque où les diplômés ne pouvaient pas se réunir.

Cette fois, le contexte est tout autre. Il s'adresse à la promotion 2026 dans une ambiance de célébration classique, entouré pour la première fois de ses propres parents lors d'une cérémonie de ce genre. Il en profite pour les remercier publiquement, ainsi que toute sa famille présente dans le public.

Avant d'entrer dans le vif du sujet, il évacue rapidement un sujet qui revenait dans les conseils qu'on lui donnait pour préparer son discours : éviter certains jeux de mots sur son nom de famille. Il choisit de ne pas s'y attarder, estimant que ce genre de détail n'a aucune importance face à ce qu'il veut transmettre.

Premier principe : choisir l'optimisme

Le premier principe développé par Sundar Pichai consiste à choisir une lecture optimiste des situations, même quand le contexte est difficile.

Il rappelle que chaque génération a connu ses propres difficultés, et que si l'on ne choisit pas le monde dans lequel on grandit, on choisit la façon dont on l'interprète. Il illustre cette idée avec son enfance à Chennai, en Inde, marquée par des pénuries d'eau et un accès très progressif aux technologies du quotidien comme le téléphone, la télévision ou le réfrigérateur. Malgré ces contraintes, ses parents ne l'ont jamais empêché d'imaginer un avenir différent, jusqu'à envisager une carrière dans la Silicon Valley.

Quand Stanford l'accepte, son père dépense l'équivalent d'un an de salaire pour lui payer son billet d'avion, le tout premier de sa vie. Une fois en Californie, la réalité ne correspond pas tout à fait à l'image qu'il s'en faisait. Il découvre des collines plutôt brunes que vertes, ce qui lui inspire une remarque spontanée auprès de sa famille d'accueil. Sa logeuse, Jane Earl, lui répond alors qu'on préfère dire qu'elles sont dorées plutôt que brunes. Cette reformulation toute simple devient pour lui l'illustration parfaite de ce qu'il appelle l'optimisme californien.

Il applique ce même principe à un tournant important de son parcours étudiant. Arrivé à Stanford avec l'objectif de poursuivre un doctorat et de se diriger vers le monde académique, il doit finalement quitter ce programme pour des raisons pratiques et obtenir à la place un master. Plutôt que de voir cela comme un échec, il choisit d'y voir une autre forme de réussite, fidèle à la logique des collines dorées.

Deuxième principe : se tourner vers les sujets difficiles

Le deuxième principe consiste à privilégier les projets les plus ambitieux, même quand ils paraissent presque impossibles.

Sundar Pichai raconte que son parcours après Stanford n'a rien eu d'un succès immédiat. Il lui faut près d'une décennie avant de trouver véritablement sa voie, jusqu'à son entretien final chez Google en 2004, le jour même du lancement de Gmail. À l'époque, proposer un gigaoctet de stockage gratuit à tous les utilisateurs semblait être une idée presque irréaliste.

Quelques années plus tard, il se retrouve à la tête d'un petit groupe d'une dizaine de personnes chargé de repenser entièrement le navigateur web, à un moment où le web passe de simples pages statiques à des applications beaucoup plus riches. En interne, beaucoup pensent qu'un tel projet nécessiterait des centaines d'ingénieurs.

Le lancement de Chrome a lieu en 2008. Huit millions d'utilisateurs adoptent le navigateur dès les premières vingt-quatre heures, mais la croissance stagne ensuite rapidement. Un an plus tard, Chrome ne représente encore qu'environ deux pour cent de parts de marché. Steve Ballmer, alors patron de Microsoft, ironise publiquement sur ces résultats lors d'une interview. Plutôt que de se laisser décourager, l'équipe interprète cette remarque comme la preuve qu'elle dérange, et donc qu'elle est sur la bonne voie.

L'équipe se fixe alors des objectifs volontairement très ambitieux et adopte un rythme de mise à jour bien plus rapide que la concurrence, avec une nouvelle version livrée toutes les six semaines. Cette persévérance finit par porter ses fruits. Pour Sundar Pichai, s'attaquer à des sujets difficiles attire naturellement des personnes compétentes et optimistes, et même en cas d'objectifs non atteints, le résultat final reste souvent remarquable.

Troisième principe : suivre sa passion

Le troisième principe consiste, à compétences ou conditions égales, à choisir ce qui suscite un véritable enthousiasme.

Pour Sundar Pichai, ce moteur a toujours été l'accès à la technologie. Il se souvient de son arrivée à Stanford en 1993, où il découvre pour la première fois des salles entières d'ordinateurs accessibles librement, alors qu'il n'y avait quasiment pas eu accès auparavant. Il perçoit immédiatement internet, alors en pleine construction, comme un levier de progrès humain majeur, ce qui motive directement son choix de rejoindre Google puis de travailler sur des projets comme les Chromebooks et Android.

Il évoque ensuite deux souvenirs marquants liés à l'impact concret de ces technologies :

• Des femmes en zone rurale en Inde utilisant pour la première fois un smartphone Android pour apprendre un métier et garder le contact avec leurs proches,
• Et une classe à Pittsburgh où des élèves d'origines très différentes apprennent grâce aux mêmes outils qu'il a contribué à développer.

Il conseille aux diplômés de ne pas orienter leurs choix en fonction des attentes de leurs parents, de leurs amis ou de la société en général, mais plutôt de repérer les sujets qui les font parler avec enthousiasme jusque tard dans la nuit, et de s'orienter vers ces sujets.

Pourquoi la plupart des décisions ne sont pas décisives

Pour illustrer l'idée que peu de moments sont réellement déterminants, Sundar Pichai raconte une anecdote de son année d'études à Stanford. Un camarade de classe nommé Pat lui propose un mercredi matin, sur le chemin des cours, de partir improviser un voyage à Las Vegas plutôt que d'assister au cours. Sans expérience de road trip ni habitude de sécher les cours, il accepte malgré tout.

Le trajet passe par les montagnes, où il découvre la neige pour la première fois. Une fois arrivés à Las Vegas neuf heures plus tard, Pat lui apprend à jouer au blackjack. Avec cinq dollars de mise initiale, il en gagne quinze de plus avant de s'arrêter, satisfait. Le lendemain, ils reprennent la route, et personne à l'université ne remarque leur absence.

Pour Sundar Pichai, cet épisode illustre bien la différence entre les quelques décisions qui méritent vraiment réflexion, comme le choix d'un partenaire de vie, la décision de fonder une famille ou un virage de carrière majeur, et les milliers d'autres moments du quotidien, comme un premier emploi, un déménagement ou un road trip improvisé, qui donnent du relief au parcours sans pour autant en déterminer la trajectoire.

L’article "Sundar Pichai livre un discours aux diplômés de Stanford 2026 : trois règles de vie à retenir" a été publié sur le site Abondance.

Des ajouts en masse signalés partout

Le phénomène a été repéré simultanément sur le Local Search Forum et sur X à partir de la semaine du 9 juin 2026. Le spécialiste du référencement local Len Raleigh a été l'un des premiers à tirer la sonnette d'alarme : une vague massive de numéros WhatsApp incorrects venait d'être ajoutée sur des Google Business Profiles. Rhea Velgos a pour sa part indiqué avoir reçu des notifications par e-mail de Google concernant trois fiches mises à jour avec un lien de chat WhatsApp dans le champ dédié.

Google envoie bien des e-mails d'information aux propriétaires concernés, mais tous ne les ont pas forcément vus. Il est donc conseillé de vérifier directement sa fiche Google Business Profile pour s'assurer de ne pas être affecté.

Des numéros fixes ajoutés à la place de numéros WhatsApp compatibles

Le problème ne se limite pas à un simple ajout non sollicité. Dans plusieurs cas documentés, le numéro WhatsApp affiché correspond au numéro de téléphone principal de l'établissement, qui est une ligne fixe. Or, les lignes fixes ne prennent pas en charge la messagerie texte ni WhatsApp. Le numéro ajouté est donc non seulement inutilisable pour les clients qui tenteraient de contacter l'entreprise via ce canal, mais il peut aussi induire en erreur et générer une mauvaise expérience utilisateur.

Aucune option de suppression disponible pour l'instant

Ce qui aggrave la situation, c'est l'absence totale de solution côté interface : lorsque les gestionnaires tentent de retirer le numéro WhatsApp erroné depuis leur tableau de bord Google Business Profile, l'option de suppression n'est tout simplement pas disponible. Les entreprises concernées se retrouvent donc dans l'impossibilité d'agir par elles-mêmes.

Claudia Tomina, experte produit Google reconnue sur le Local Search Forum, a confirmé officiellement qu'il s'agit bien d'un bug et que Google travaille activement à le corriger. Aucun calendrier précis n'a cependant été communiqué pour la résolution du problème. En attendant un correctif, la seule chose à faire est de surveiller sa fiche et de vérifier les e-mails envoyés par Google pour rester informé de l'évolution de la situation.

L’article "Google Business Profile : des numéros WhatsApp ajoutés automatiquement et sans possibilité de suppression" a été publié sur le site Abondance.

Une part importante de vos conversions n’arrive jamais dans vos rapports. Selon les comparatifs server-side publiés en 2026 (Addingwell, Data Detective), les sites e-commerce perdent entre 30 et 40 pourcent de leurs données de conversion à cause des adblockers et des restrictions iOS, et la fourchette monte jusqu’à 30-70 pourcent quand on additionne tous les canaux. Ce signal manquant fausse vos rapports GA4, dégrade l’optimisation de vos campagnes Google Ads et Meta, et finit par coûter du média. Le tagging server-side est la réponse technique à cette érosion. Encore faut-il comprendre ce qu’il règle vraiment, ce qu’il coûte, et quand il devient pertinent. Pourquoi la collecte client-side perd du signal en 2026 Le modèle historique repose sur du JavaScript exécuté dans le navigateur du visiteur. Chaque tag (GA4, Google Ads, Meta Pixel) charge son propre script et envoie ses propres requêtes. Ce modèle fonctionne de moins en moins bien, pour trois raisons qui se cumulent. Adblockers et restrictions navigateurs Les bloqueurs de publicité ne se contentent plus de masquer des bannières. Ils interceptent les requêtes vers les domaines de tracking connus (google-analytics.com, facebook.net, doubleclick.net). Quand un visiteur utilise uBlock Origin ou un navigateur qui filtre nativement ces domaines, le tag ne se déclenche pas et l’événement disparaît. Sur certaines audiences techniques, la part de visiteurs concernés est loin d’être marginale. Le cap cookie 7 jours de Safari ITP Safari applique l’Intelligent Tracking Prevention (ITP). Concrètement, tout cookie first-party posé en JavaScript via document.cookie est supprimé après 7 jours d’inactivité. Et si le visiteur arrive sur le site via un paramètre de lien type gclid ou fbclid, ce délai tombe à 24 heures (documentation WebKit ITP, Stape, 2025). Résultat : un client qui revient au bout de dix jours est compté comme un nouvel utilisateur, les fenêtres d’attribution s’effondrent, et le calcul du retour sur investissement devient faux. Consent Mode v2 et l’enjeu DMA Depuis le 6 mars 2024, le Consent Mode v2 est obligatoire dans l’Espace économique européen au titre du Digital Markets Act (RESONEO, Google). Il introduit quatre paramètres de consentement : ad_storage, analytics_storage, ad_user_data et ad_personalization. Depuis juillet 2025, sans une implémentation correcte de ce mécanisme, le suivi des conversions Google Ads ne fonctionne plus correctement. La collecte est donc encadrée par le consentement, et la qualité de ce qui remonte dépend autant du juridique que de la technique. Une précision importante avant d’aller plus loin : le client-side ne disparaît pas. Il reste le prérequis qui alimente le serveur. Tout part de le dataLayer côté client, qui structure les événements dans le navigateur. Le server-side ne remplace pas cette brique, il la prolonge. GTM server-side : définition et architecture Le tagging server-side déplace une partie du traitement hors du navigateur, vers une infrastructure que vous contrôlez. Le principe est documenté par Google dans sa documentation officielle Google Tag Manager server-side, qui en détaille le rôle du client, du conteneur et les bénéfices en matière de contrôle des données. Le conteneur serveur et le rôle du client Un conteneur serveur GTM s’exécute sur un serveur, pas dans le navigateur. À l’intérieur de ce conteneur, un composant nommé « client » joue le rôle d’adaptateur : il reçoit les requêtes envoyées par le navigateur, les interprète, les transforme en événements et les met à disposition des tags. Le conteneur serveur dispatche ensuite ces événements vers les destinations finales (GA4, Google Ads, Meta Conversions API). Différence concrète avec le client-side La nuance est essentielle. En client-side, le navigateur envoie une requête sortante pour chaque vendor : une vers GA4, une vers Google Ads, une vers Meta, et ainsi de suite. En server-side, le navigateur n’envoie qu’une seule requête HTTP par événement vers votre conteneur serveur. C’est ce dernier qui génère ensuite les requêtes spécifiques à chaque destination (documentation officielle Google server-side). Le navigateur ne dialogue plus directement avec les plateformes publicitaires. Le flux de données étape par étape Le parcours d’un événement se lit en trois temps : Le navigateur envoie. Le dataLayer déclenche un événement, GTM web l’envoie en une requête vers votre sous-domaine de collecte. Le conteneur serveur transforme. Le client interprète la requête, reconstruit l’événement, applique vos règles (consentement, enrichissement, minimisation). Les tags transmettent. Le conteneur envoie une requête propre à chaque destination (GA4, Google Ads, Meta CAPI). Cette indirection est ce qui rend possible tout le reste : la maîtrise des cookies, le filtrage des données et la résistance aux blocages. Cookies first-party et durée de vie : le vrai gain technique C’est ici que le server-side change réellement la donne. Le sujet n’est pas l’esthétique de l’architecture, mais la persistance de l’identifiant visiteur. Contourner le cap 7 jours de Safari Le serveur pose le cookie via l’en-tête HTTP Set-Cookie, et non via document.cookie. Or, un cookie posé en HTTP depuis un sous-domaine first-party (par exemple sgtm.votresite.fr) échappe au plafond ITP de 7 jours. Il peut persister jusqu’à 400 jours (Stape, Snowplow, 2025). Le visiteur Safari qui revient au bout de trois semaines est donc reconnu, et la fenêtre d’attribution tient. Cookie posé en HTTP vs en JavaScript La règle est simple : Safari ITP cible le JavaScript, pas le HTTP. Un cookie écrit par document.cookie (donc côté navigateur) est plafonné. Un cookie écrit par l’en-tête Set-Cookie d’une réponse serveur ne l’est pas de la même façon. Le tableau ci-dessous résume la différence. Critère Cookie JavaScript (client-side) Cookie HTTP (server-side) Méthode de pose document.cookie En-tête Set-Cookie Cap Safari ITP 7 jours (24h via gclid/fbclid) Non plafonné de la même façon Durée de vie effective Quelques jours Jusqu’à 400 jours Sensible aux adblockers Oui (domaine de tracking) Réduit (domaine first-party) Domaine personnalisé et CNAME first-party Le mécanisme repose sur un sous-domaine qui partage le domaine racine de votre site. Vous créez un enregistrement CNAME (par exemple sgtm.votresite.fr) pointant vers votre conteneur serveur. Comme ce sous-domaine appartient au même domaine racine que le site, le cookie est considéré comme strictement first-party. C’est cette configuration qui rend la collecte plus exhaustive et plus fiable : moins de pertes, des identifiants qui durent, une attribution qui colle à la réalité. Plus de datas, moins de blabla. Héberger son conteneur serveur : Cloud Run, Stape ou solution managée Une bonne part de la littérature francophone est périmée sur ce point : App Engine n’est plus le standard. En 2026, le choix se joue entre une approche serverless que vous administrez et un hébergement managé. Google Cloud Run, le standard 2026 Cloud Run est l’option serverless recommandée aujourd’hui. La facturation se fait à la requête et au temps de calcul, donc elle varie avec votre trafic. En ordre de grandeur, comptez environ 45 USD par serveur et par mois, avec un minimum de 2 instances en production, soit autour de 90 USD par mois (TRKKN, Stape, Google Cloud Run pricing, 2026). Vous gardez le contrôle total de l’infrastructure, au prix d’un peu d’administration système. Solutions managées : Stape, Addingwell Si vous ne voulez pas gérer la couche serveur, les solutions managées provisionnent et maintiennent le conteneur pour vous. Stape propose un hébergement sGTM à partir de 17 à 20 USD par mois, à prix fixe et prédictible, avec un hébergement dans l’Union européenne disponible (Stape, Capterra/GetApp, 2026). Addingwell est une alternative française managée, positionnée plus haut de gamme. Dans les deux cas, vous gagnez du temps et évitez l’admin système. Le coût réel mois par mois Solution Coût indicatif Modèle Pour qui Cloud Run ~90 USD/mois (2 instances) À la requête et au calcul Équipe technique, contrôle total Stape Dès 17-20 USD/mois Prix fixe Démarrage, prédictibilité, UE Addingwell Haut de gamme Managé Accompagnement premium FR L’arbitrage est clair : Cloud Run pour le contrôle et la maîtrise des coûts à fort trafic, le managé pour aller vite sans ressource d’infrastructure. Si vous voulez monter vos équipes en compétence avant d’internaliser, une formation Google Tag Manager permet de cadrer le setup avant d’engager du budget serveur. Mettre en place GA4 server-side Voici l’ordre d’exécution concret pour faire remonter GA4 par le serveur. Créer et provisionner le conteneur Dans GTM, créez un conteneur de type Serveur (distinct de votre conteneur Web). Le provisionnement peut être automatique via Google Cloud Platform (Cloud Run ou App Engine en assistant) ou manuel sur Cloud Run via une image Docker. Configurez ensuite votre domaine personnalisé first-party (le CNAME sgtm.votresite.fr) pour que la collecte passe par votre propre sous-domaine. Configurer le client GA4 Le client GA4 est pré-installé dans le conteneur serveur. Son rôle est de capter les requêtes GA4 entrantes envoyées par votre conteneur Web (via le champ transport_url pointant vers votre domaine de collecte) et de les transformer en événements exploitables. Vérifiez que le transport_url est bien renseigné côté web, sans quoi rien n’arrive au serveur. Baliser et valider en mode preview Routez les événements via le tag GA4 server-side, puis testez. Le mode Preview du conteneur serveur affiche en temps réel les requêtes entrantes, les événements reconstruits et les tags déclenchés. Croisez-le avec les logs Cloud Run pour confirmer que les requêtes sortent bien vers GA4. Pour une implémentation propre, comptez généralement de quelques jours à deux semaines entre la mise en place et une production stable, selon la complexité de votre tagging existant et la qualité du dataLayer en amont. Google Ads et Meta CAPI via le serveur Le server-side ne sert pas qu’à GA4. C’est sur les plateformes publicitaires que le gain de signal pèse le plus, car chaque conversion récupérée nourrit l’optimisation des campagnes. Enhanced Conversions Google Ads côté serveur Le routage server-side vers Google Ads s’appuie sur les Enhanced Conversions. Les données first-party fournies par l’utilisateur (email, téléphone) sont hachées en SHA-256 côté serveur avant d’être envoyées, ce qui permet de rapprocher la conversion d’un compte Google tout en respectant la confidentialité. Envoyées depuis le serveur, ces conversions résistent mieux aux blocages côté navigateur. Meta Conversions API et déduplication Pour Meta, le serveur alimente la Conversions API (CAPI). Le point technique à ne pas rater : la déduplication. Si vous conservez le Pixel côté client en parallèle de la CAPI côté serveur, vous devez partager un même event_id entre les deux. Meta reconnaît alors qu’il s’agit du même événement et ne le compte qu’une fois. Sans cet identifiant partagé, vous risquez le double comptage et des données gonflées. Qualité du matching et données first-party En transmettant des conversions plus complètes et des paramètres de correspondance plus riches, le serveur améliore l’Event Match Quality côté Meta et la qualité du matching côté Google. Concrètement : une mesure plus juste, donc des algorithmes mieux nourris et des campagnes mieux optimisées. La science du clic alliée à l’art de la conversion prend ici un sens très opérationnel. Consent Mode v2 et minimisation des données côté serveur Un malentendu courant : le serveur dispenserait du consentement. C’est faux. Le serveur ne contourne pas le RGPD, il aide à mieux le respecter. Transmettre le signal de consentement au serveur Le signal de consentement est capté côté client par votre CMP, via les quatre paramètres du Consent Mode v2 (ad_storage, analytics_storage, ad_user_data, ad_personalization). Ce signal est transmis au conteneur serveur avec l’événement. Le conteneur respecte alors la décision du visiteur : il envoie ou bloque les données vers chaque destination en fonction du consentement reçu. Pour le détail de l’implémentation, vous pouvez valider votre setup Consent Mode en complément de cet angle serveur. Filtrer les données personnelles avant envoi C’est l’avantage de conformité propre au server-side. Comme vous contrôlez le conteneur, vous pouvez filtrer ou minimiser les données personnelles (PII) avant de les transmettre aux partenaires : supprimer un champ, tronquer une adresse IP, ne transmettre que le strict nécessaire à chaque vendor. Cette mise en conformité par la minimisation est impossible à ce niveau de finesse en pur client-side. La mécanique technique de ces clients et tags est détaillée dans le guide server-side tagging de Simo Ahava, référence sur le sujet. Mode avancé vs mode de base Deux configurations coexistent. En mode de base, aucun signal n’est envoyé tant que le visiteur n’a pas consenti : pas de consentement, pas de tag. En mode avancé, des pings anonymes sont envoyés même sans consentement, ce qui permet à Google de modéliser les conversions manquantes. Le choix entre les deux relève d’un arbitrage entre prudence juridique et complétude de la mesure, à trancher avec votre DPO. Performance et Core Web Vitals : l’effet sur le client Déplacer le traitement vers le serveur allège le navigateur. Reste à mesurer l’effet réel, sans le surestimer. Moins de JavaScript exécuté dans le navigateur En client-side, chaque vendor charge son script et émet ses requêtes depuis le navigateur. En server-side, le navigateur n’envoie qu’une seule requête par événement vers votre serveur. Le code des différents vendors n’a plus à s’exécuter côté client, ce qui réduit le poids JavaScript de la page. Impact sur le chargement des pages Moins de scripts tiers signifie moins de travail pour le thread principal et moins de connexions sortantes. Cela peut bénéficier aux Core Web Vitals, en particulier aux métriques liées à l’interactivité et au chargement. La tendance est favorable, mais l’ampleur du gain dépend directement du nombre de tags que vous retirez effectivement du conteneur Web. Les limites à connaître (latence serveur) Soyons honnêtes : le server-side ne fait pas disparaître le travail, il le déplace. Le conteneur serveur introduit une latence réseau côté serveur, et il faut le dimensionner pour absorber les pics de trafic. Le gain front est réel quand vous déportez beaucoup de tags ; il est marginal si votre setup client-side était déjà léger. Aucun chiffre universel ici : tout dépend de votre configuration de départ. Quand le server-side se justifie (et quand non) C’est la question qui manque à la plupart des contenus sur le sujet. Le server-side n’est pas un passage obligé : c’est un investissement qui doit être rentable. Les seuils où il devient rentable Le server-side se justifie quand plusieurs de ces conditions sont réunies : Trafic significatif : le volume de données récupérées devient mesurable. Budget média conséquent : chaque point de signal récupéré améliore l’optimisation, donc le ROAS. Plus vous investissez en Google Ads et Meta, plus le gain compte. Forte part de visiteurs Safari/iOS ou d’adblockers : c’est exactement la population perdue en client-side. Exigences RGPD/PII fortes : besoin de minimiser les données avant transmission. Dépendance aux conversions Google Ads et Meta : votre acquisition repose sur la fiabilité de ces signaux. Les cas où rester client-side suffit À l’inverse, l’investissement n’est pas justifié pour un petit site, un faible budget média, une audience peu exposée à Safari, ou une équipe sans ressource technique pour maintenir le conteneur. Cas fréquent et souvent ignoré : si votre setup client-side n’est pas optimisé, corrigez-le d’abord. Un dataLayer mal structuré ou un tagging incomplet ne se règlent pas en passant au serveur. On nettoie le client avant d’investir dans le serveur. Checklist de décision Critère Server-side recommandé Client-side suffit Budget média mensuel Élevé Faible Part Safari/iOS Importante Marginale Exigences PII/RGPD Fortes Standards Ressource technique Disponible Absente Setup client-side actuel Déjà propre À corriger d’abord Mis en face du média, le coût est modeste : environ 90 USD par mois sur Cloud Run, dès 17 USD sur une solution managée. Si vous dépensez plusieurs milliers d’euros par mois en acquisition, récupérer 30 à 40 pourcent de signal perdu paie ce coût sans difficulté. Les robots vous trouvent, les prospects vous choisissent : encore faut-il les compter correctement. Conclusion Le tagging server-side n’est pas un gadget technique, c’est une réponse à une érosion mesurable du signal. Cookies first-party qui durent jusqu’à 400 jours, conversions Google Ads et Meta plus complètes via Enhanced Conversions et CAPI, minimisation des données pour une meilleure conformité, allègement du navigateur : les bénéfices sont réels quand le contexte s’y prête. Mais la décision reste data-driven. Un trafic et un budget média conséquents, une forte exposition à Safari et aux adblockers, des exigences RGPD : voilà les conditions où l’investissement se rembourse. En dessous, mieux vaut consolider le client-side d’abord. Brioude allie l’expertise data, le SEO et le SEA pour transformer chaque clic en opportunité et chaque donnée en histoire à raconter. Vous vous demandez si le server-side est rentable pour votre site, ou comment fiabiliser votre collecte avant d’investir dans un conteneur serveur ? Parlons de votre projet de tracking avec nos experts.

L’article GTM Server Side : le guide complet pour bien collecter est apparu en premier sur Brioude.

Un nouveau coup de boutoir contre le scraping de SERP

Cet épisode s'inscrit dans la continuité directe de ce qu'on documentait en avril 2026 : Google ne se contente plus de bloquer les bots, il les nourrit de fausses données. Mais cette fois, le vecteur d'attaque est différent. Ce n'est plus la « soupe YouTube » qui est en jeu, c'est le mécanisme fondamental de géolocalisation des SERPs.

Jusqu'au 14 mai, il était possible pour n'importe quel outil SEO de récupérer la SERP française depuis une IP étrangère en ajoutant simplement le paramètre &gl=fr dans l'URL de requête sur google.com. C'est ce que faisait la quasi-totalité des outils du marché pour scraper à grande échelle, pour des raisons de coût et de disponibilité limitée des proxies français.

Google a récemment modifié la gestion du ciblage géographique de ses SERPs.

Le paramètre gl, utilisé pour cibler une région, n'est plus fiable.

Si votre IP est étrangère :
- vidéos YouTube/Facebook en page 5
- résultats instables dès la page 1

On en parle ci-dessous

— Monitorank (@monitorank) May 26, 2026

Ce qui a changé : &gl=fr ne suffit plus

Comme le communique Monitorank dès la détection du changement :

« Google a récemment modifié la gestion du ciblage géographique de ses SERPs. Le paramètre gl, utilisé pour cibler une région, n'est plus fiable. Si votre IP est étrangère : vidéos YouTube/Facebook en page 5, résultats instables dès la page 1. »

L'impact est immédiat et visible sur des mots-clés à très fort trafic. Fabien Barry l'illustre concrètement : un site présent en position 1 ou 2 sur la vraie SERP française peut ne plus apparaître du tout dans les résultats retournés par les outils non corrigés. Ce n'est donc pas uniquement un problème de pages profondes ou de résultats marginaux. Le top 1 peut être affecté.

Les mots-clés de référence pour tester

Monitorank a partagé une liste de requêtes permettant de vérifier par soi-même l'étendue du problème. Parmi les exemples documentés : « comparateur assurance auto », « iphone », « rachat de credit », « assurance habitation pas cher » ou encore « tenerife canaries ». Sur ces requêtes, certains sites présents en page 1 de la vraie SERP française n'apparaissent pas dans les résultats retournés par des outils ou API utilisant des proxies non français.

Comment vérifier par vous-même

La manipulation est simple à reproduire :

1. Connectez-vous à un VPN sur un pays non français.
2. Ouvrez une fenêtre de navigation privée (cookie Google vierge).
3. Effectuez une recherche sur google.com et ajoutez &gl=fr à l'URL.
4. Comparez avec les mêmes requêtes effectuées depuis une connexion française classique (sans VPN).

Les différences de classement observées reflètent exactement ce que vos outils de tracking voient en ce moment si leur infrastructure repose sur des proxies étrangers.

Monitorank et Ranxplorer : correctif déployé

Monitorank indique avoir identifié le problème rapidement après la mise à jour du 14-15 mai, avoir communiqué publiquement sur X, puis avoir travaillé plusieurs jours à la conception d'un correctif avant de le déployer et le valider à grande échelle. L'outil affirme avoir retrouvé sa puissance de scrape habituelle avec des résultats fiables. Ranxplorer et Goserp seraient également en mesure de fournir des données correctes selon les vérifications partagées par l'équipe.

Pour tous les autres outils, la prudence s'impose : en l'absence d'une communication explicite de l'éditeur sur ce sujet, les données de positionnement pour le marché français sont potentiellement non fiables depuis la mi-mai. Et comme lors des épisodes précédents, aucun tableau de bord n'affiche d'alerte : les données s'affichent normalement, qu'elles soient justes ou non.

L’article "Google casse la géolocalisation des SERPs : vos données de ranking sont-elles fiables ?" a été publié sur le site Abondance.

Sponsorisé par Linksgarden.

On ne change pas une formule qui fonctionne ! Comme à l'accoutumée, les conférences prendront la forme de webinaires, de 9h à 17h. Pas besoin de réserver votre billet de train ou de prévoir de déplacement : tout est accessible en ligne, gratuitement. La seule condition pour accéder à cette journée d'apprentissage et d'inspiration : vous inscrire !

Une édition autour du SEO, de l'IA, de l'acquisition et de l'automatisation

IA, Claude Code, refonte de site, backlinks, automatisation SEO... Les conférenciers de cette édition de juin 2026 prennent les sujets qui animent la profession à bras-le-corps pour proposer des stratégies bien concrètes, orientées résultats et performances !

Que vous soyez SEO, consultant, développeur ou que vous ayez simplement envie de mieux comprendre les mutations du web, cette SEO Garden Party est un événement à ne surtout pas manquer !

À noter que cette édition du 18 juin ne sera pas la seule de 2026. D'autres webinaires sont d'ores et déjà prévus dans l'année : en septembre et novembre ! On vous en reparle bientôt !

 

Inscrivez-vous gratuitement

Le programme de la SEO Garden Party 21e édition

Jeudi 18 juin 2026

9h30 - 10h20 : Conférence bientôt annoncée

10h30 - 11h20 : SEO, GEO, migration : Adoptez les nouveaux standards d'une refonte performante, par Nicolas Plantelin & Marina Pomi

11h30 - 12h20 : Liens Médias : Arnaque ou Jackpot ? Comment (enfin) rentabiliser vos backlinks à plus de 1000 €, par Jean Philippe Gronier

14h00 – 14h50 : Conférence bientôt annoncée

15h00 – 15h50 : Comment automatiser PROPREMENT son SEO (Claude Code, mais pas que), par Paul Vengeons

16h00 – 16h50 : Conférence bientôt annoncée, par Guillaume Pracht

Les détails du programme sont disponibles sur le site de la SEO Garden Party !

Ce webinaire 100 % gratuit sera présenté par Alain Guisado.

Infos pratiques de la SEO Garden Party 21

• Quand : jeudi 18 juin 2026
• Où : webinaire 100 % en ligne
• Prix : gratuit
• Inscription : obligatoire, l’inscription a lieu sur le site de la SEO Garden Party
• Pour qui : les professionnels du Search Marketing et du SEO

Inscrivez-vous gratuitement

Pourquoi participer ?

Chaque édition de la SEO Garden Party est l'occasion d'écouter des experts partager leurs retours terrain, leurs méthodes et leurs visions sur l'évolution du Search. L'événement est reconnu pour la qualité de ses interventions, son accessibilité et la richesse des échanges.

« La SEO Garden Party est un événement incontournable pour tous ceux qui veulent progresser en SEO. Les conférences offrent des retours d’expérience concrets et des conseils directement applicables. C’est rare de trouver un contenu aussi riche et gratuit. »
— Victor Lerat, Directeur Abondance

L’article "La SEO Garden Party est de retour le 18 juin 2026 !" a été publié sur le site Abondance.

Un changement brutal, pas progressif

Pendant sept semaines, le taux de réponses ChatGPT contenant un lien vers un site de marque oscillait entre 0,3 % et 1 %. Le 6 mai, il était à 0,5 %. Le 7 mai, il atteignait 4,1 %. 48 heures plus tard, il dépassait 7 %. Depuis, il s'est stabilisé autour de 4 à 5 %.

Ce n'est pas un déploiement progressif, mais une rupture nette, une ligne verticale dans les données. Pour illustrer concrètement la différence, avant le 7 mai une réponse ChatGPT mentionnant une marque ressemblait à ceci : « Les options courantes incluent Acme Field Service et Northwind Dispatch. » Après le 7 mai, chaque nom de marque est devenu un lien hypertexte balisé :

[Acme Field Service](https://www.acmefieldservice.com/?utm_source=chatgpt.com). 

Le tag UTM est apposé par ChatGPT, pas par les marques.

Parmi les réponses qui mentionnent une marque, la part de celles qui incluent également un lien vers son site est passée de 2 % à 29 %. ChatGPT recommande les mêmes marques qu'avant. Il a simplement arrêté de les laisser sans destination cliquable.

Les données excluent tout artefact de mesure

Qwairy a croisé les données de ChatGPT avec celles de trois autres assistants sur la même fenêtre temporelle :

Un artefact de collecte aurait affecté plusieurs sources simultanément. Ici, un seul assistant a bougé. Le paramètre utm_source=chatgpt.com, absent avant le 7 mai et présent sur chaque lien après, confirme que ce tag est injecté par l'infrastructure d'OpenAI et non par le pipeline de mesure de Qwairy.

Où atterrit ce trafic ?

La grande majorité des liens pointe vers la page d'accueil des marques : 79 % après le 7 mai, contre 59 % avant. C'est la page que la plupart des équipes marketing traitent comme une vitrine institutionnelle, rarement pensée pour convertir un visiteur arrivant froid depuis une recommandation IA.

Le changement concerne l'ensemble des types de requêtes. Même les réponses déclenchant la surface shopping de ChatGPT ont enregistré une progression d'environ 20 fois (de 0,2 % à 4,4 %). Aucun secteur n'est épargné.

Pourquoi OpenAI a fait ce choix

Le changement intervient deux jours après que GPT-5.5 Instant est devenu le modèle par défaut de ChatGPT (5 mai 2026) et l'annonce par OpenAI de nouvelles options publicitaires incluant de l'enchère au coût par clic. Qwairy identifie trois hypothèses, que Luca Fancello, CMO de Qwairy, développe ainsi :

« Il existe selon moi trois raisons qui peuvent expliquer ce soudain changement de l'interface ChatGPT. La première est un simple changement UX pour rendre l'interface plus facile à utiliser. La deuxième c'est l'importance des Ads dans le potentiel revenu de ChatGPT. On sait qu'OpenAI teste les Ads sur ChatGPT et si les clics venant de ChatGPT sont attribuables plus facilement, les équipes marketing peuvent négocier de plus gros budget. Une dernière raison dont personne ne parle concerne le produit. En ajoutant les clics OpenAI peut optimiser ses réponses selon les clics et offrir des réponses toujours plus pertinentes à ses utilisateurs. Si cette dernière option prévaut, ChatGPT apprend des meilleurs en copiant Google. » - Luca Fancello

Sur la question de la monétisation, Luca Fancello est direct : « Depuis quelques mois, ChatGPT propose à des marques de tester la publicité ChatGPT. Les équipes marketing pour utiliser du budget sur ChatGPT ont logiquement besoin de convaincre et de pouvoir tracker l'origine du trafic. L'apparition de ces liens semblent aller dans ce sens. »

Une précision importante : les liens mesurés dans l'étude se trouvent dans les réponses organiques de ChatGPT. OpenAI indique que les annonces sponsorisées sont identifiées séparément. Ce ne sont pas des publicités. Mais ils utilisent la même infrastructure d'attribution au clic qu'un système publicitaire au coût par clic.

Le paradoxe Google que ce changement résout

Avant le 7 mai, le trafic généré par ChatGPT finissait largement dans les mains de Google. Luca Fancello l'explique avec une certaine ironie : « Jusqu'à aujourd'hui le trafic ChatGPT était probablement attribué à son pire ennemi... Google. En effet, l'utilisateur/utilisatrice voyait une marque citée sur ChatGPT puis allait la taper directement dans la barre de recherche Google. Google gagnait donc probablement de l'argent grâce à ChatGPT, ce qui est assez cocasse. »

Avec le tag utm_source=chatgpt.com, OpenAI s'approprie désormais l'attribution de ce trafic. Les équipes analytics peuvent identifier et mesurer ce canal directement, sans passer par Google.

Ce que les équipes SEO et GEO doivent faire maintenant

Trois actions concrètes découlent de cette étude.

• Configurer l'attribution ChatGPT dans vos analytics. Le paramètre utm_source=chatgpt.com est déjà actif. Ajouter chatgpt.com et openai.com comme sources de référence dans vos outils de mesure ne coûte rien et permet de quantifier un canal déjà opérationnel.
• Repenser la page d'accueil comme une landing page IA. Quatre liens sur cinq atterrissent sur le domaine racine. La homepage doit désormais être capable de convertir un visiteur dont le seul contexte est une phrase rédigée par ChatGPT. Un positionnement clair et une action suivante évidente deviennent des enjeux d'acquisition IA, pas seulement de branding.
• Gagner la mention avant de viser le lien. ChatGPT ne lie que les marques qu'il cite. Si une marque n'apparaît pas dans les réponses, il n'y a rien à lier. La bataille pour la part de mention reste la priorité amont. Le lien n'est que la récompense qui suit.

L'étude de Qwairy porte sur plus de 140 000 réponses ChatGPT collectées du 1er avril au 21 mai 2026, et sur plus de 350 000 réponses au total en incluant les trois autres assistants. Les exemples de marques cités dans l'étude originale sont des reconstructions illustratives et ne correspondent pas à des données réelles.

L’article "ChatGPT multiplie par 14 ses liens vers les marques : ce que révèle une étude sur 140 000 réponses" a été publié sur le site Abondance.