Ce qu'il faut retenir :

• Google a ajouté automatiquement des numéros WhatsApp sur de nombreuses fiches Google Business Profile au cours de la semaine du 9 juin 2026.
• Certains numéros ajoutés sont incorrects ou correspondent à des lignes fixes incompatibles avec WhatsApp.
• Il est actuellement impossible pour les propriétaires de fiches de supprimer ces numéros.
• Google a reconnu qu'il s'agit d'un bug et travaille activement à sa correction.

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.

Que retrouve-t-on dans ce livre blanc ?

Le livre blanc décortique le fonctionnement technique des LLM, de l'extraction d'intention à la recherche web en temps réel, pour démontrer que les fondamentaux du SEO, et notamment le netlinking, restent les piliers de cette nouvelle visibilité.

Au programme :

• L'anatomie des recherches IA : les mécanismes internes des LLM, du traitement du prompt à la recherche web en temps réel via le mécanisme de fan-out
• Les algorithmes de classement RRF et MMR : pourquoi la régularité prime sur la position numéro 1, et comment l'originalité d'un contenu devient un avantage décisif
• La conception de la mention idéale : mentions explicites, STS (Strategic Text Sequencing), EEAT analysé directement dans le contenu
• La synergie netlinking et GEO : pourquoi l'acquisition de liens et de mentions sur des sites d'autorité reste le levier principal pour influencer les modèles génératifs

Loin des discours alarmistes sur la fin du référencement, ce livre blanc propose des actions concrètes pour adapter vos campagnes et construire un avantage concurrentiel durable dans un écosystème search en pleine mutation.

-> Téléchargez le livre blanc gratuitement !

L’article "SEO + GEO : un nouveau livre blanc pour comprendre les LLM et mieux les influencer" a été publié sur le site Abondance.

L'IA générative rebat les cartes des métiers du web

Pendant longtemps, le SEO technique rimait avec audits de crawl, optimisation de balises et production de contenus en volume. La data était quant à elle l'affaire de spécialistes capables d'interroger une base SQL ou de construire un dashboard sous Looker. Aujourd’hui, ces frontières ont volé en éclats !

L'irruption des modèles de langage dans les outils quotidiens (de la rédaction assistée à l'analyse sémantique automatisée, en passant par la génération de scripts ou l'interprétation de jeux de données) a remodelé ce paysage en profondeur. Les tâches à faible valeur ajoutée s'automatisent à grande vitesse.

Ce qui prend de la valeur, en revanche, c'est la capacité à piloter ces outils avec discernement : comprendre leurs limites, qualifier leurs outputs, les intégrer dans une stratégie cohérente plutôt que de les subir.

Par exemple, le métier de consultant SEO ne disparaît pas, mais entame une véritable mutation. Là où l'IA peut désormais produire un brief de contenu en quelques secondes, l'humain apporte la lecture éditoriale, la connaissance du secteur et la finesse de l'intention de recherche. On retrouve ce même déplacement dans le secteur de la data : les outils génèrent des visualisations et des synthèses, mais l'interprétation stratégique demeure fondamentalement humaine.

Les compétences émergentes à l’heure de l’IA

L'écart entre les profils disponibles et les besoins réels du marché n'a jamais été aussi concret. Dans les offres d'emploi du digital publiées depuis 2024, plusieurs compétences émergentes reviennent avec une régularité métronomique, sans toujours trouver preneur.

Le prompt engineering d'abord, comme la capacité concrète à formuler des instructions précises, itérer sur les résultats et intégrer les modèles génératifs dans des workflows existants.

Ensuite, la culture data. Il ne s’agit pas nécessairement d’avoir une maîtrise avancée du machine learning, mais d'une aisance avec les volumes de données, les biais statistiques et les métriques d'évaluation. 

Enfin, et surtout, l'esprit critique face aux outputs automatisés : savoir quand faire confiance à une suggestion générée, quand la remettre en question ou quand l’écarter.

À ces attendus techniques s'ajoute une dimension comportementale que les recruteurs mentionnent de plus en plus explicitement : une capacité d'adaptation rapide. Dans un environnement où les outils évoluent tous les trimestres, un profil qui apprend vite vaut parfois bien plus qu'un profil qui en sait déjà beaucoup, mais dont les connaissances sont en grande partie obsolètes.

Comment les écoles spécialisées réinventent leurs cursus

Former les étudiants à des métiers en cours de redéfinition est un défi pédagogique inédit. Les référentiels traditionnels, bâtis sur des blocs de compétences stables, peinent à absorber la vélocité des transformations en cours. Les écoles qui tirent leur épingle du jeu sont celles qui ont fait le choix d'une agilité assumée avec une révision régulière des contenus, une intégration rapide des outils émergents et un ancrage fort dans les pratiques professionnelles de terrain.

C'est précisément l'approche défendue par HETIC, école web Paris implantée à Montreuil, aux portes de la capitale. Spécialisée dans les métiers du web et du numérique, l’établissement propose des parcours du Bac au Bac+5 couvrant le développement web, la data et l'IA, le webmarketing, l'UX et la cybersécurité. Plusieurs des parcours débouchent sur des titres RNCP reconnus par l'État (niveau 6 pour les Bachelors, niveau 7 pour certains Mastères). Son processus d'admission, délibérément hors Parcoursup, mise sur la motivation et le potentiel plutôt que sur le seul parcours scolaire, ce qui ouvre la voie à des profils atypiques souvent très recherchés dans le secteur.

Résolument orientée pratique, la pédagogie adoptée par HETIC place les étudiants en situation professionnelle dès les premières années via des projets réels et des dispositifs de stage ou d'alternance. Ce modèle produit des profils que les recruteurs du digital identifient rapidement comme opérationnels ; un critère devenu décisif dans des équipes qui n'ont plus le luxe d'attendre une lente montée en compétences.

Ce qu'un recruteur devrait désormais attendre d’un profil junior

L'ère de l'IA invite à repenser les grilles de lecture habituelles des recruteurs. Un diplôme d'une grande école est toujours un signal de rigueur, mais il ne dit plus grand-chose sur la capacité du candidat à travailler avec des outils qui n'existaient pas il y a dix-huit mois. Ce sont d'autres indicateurs qui méritent attention :

• Un portfolio de projets concrets, qu'il s'agisse d'un audit SEO mené en conditions réelles, d'un pipeline de données construit de zéro ou d'une expérimentation menée avec un modèle génératif, est souvent bien plus révélateur qu’un programme de cours.
• La capacité à documenter sa démarche, à expliquer ses choix, à nommer ses erreurs, est également représentative d'une maturité professionnelle que les entretiens classiques ne peuvent pas toujours mettre en exergue.

Enfin, les recruteurs les plus avisés doivent prêter attention à la veille autonome du candidat : suit-il l'évolution des algorithmes Google ? A-t-il une opinion construite sur les limites des LLMs ? Connaît-il les enjeux de l'IA Act européen ? Ces signaux faibles dessinent le profil d'un professionnel capable non seulement de s'adapter, mais aussi d'anticiper ; une qualité aussi rare que précieuse !

L’article "IA générative et métiers du web : quelles compétences pour les nouveaux entrants ?" a été publié sur le site Abondance.

Sur le volume, je ne donnerai pas les chiffres absolus, mais Google Discover représente sur Minecraft.fr plus d'un million de visites par an, avec plusieurs articles qui dépassent les 50 000 clics. C'est un canal qui pèse réellement dans l'audience du site, pas un bonus marginal.

Une précision avant de commencer. Minecraft.fr n'est pas un site que je peux nourrir comme je le voudrais : le rythme idéal serait de trois ou quatre articles par jour, la réalité c'est que certaines périodes le site reste deux semaines sans publication. Je publie ce dossier comme un retour d'expérience, en espérant qu'il servira à d'autres éditeurs qui pilotent Google Discover sans manuel.

Précision importante aussi sur le statut de ce que vous allez lire. Sylvain Deauré a publié sur Abondance une analyse qui démonte une étude affirmant que tel type de titre génère +29 % de visibilité Discover. Son point central : sans stratifier par éditeur, on prend des artefacts de mix pour des effets causaux. Ce que vous allez lire ici n'est pas une loi générale pour Discover, c'est de la donnée de mon site, à prendre pour ce qu'elle vaut : un retour d'expérience pour Minecraft.fr, un site mono-thématique gaming en français, et certainement pas une formule transposable telle quelle ailleurs !

J'ai croisé cinq sources : la GSC sur 16 mois (Le Search et Google Discover, jour par jour, page par page), un crawl complet des pages remontées dans Google Discover, l'export WordPress des articles publiés sur la période, et les données de la régie publicitaire sur quatre mois. Pour préserver la confidentialité de certaines données, j'ai privilégié les indices, les ratios et les pourcentages aux valeurs absolues.

Ce qui se passe quand on regarde le Search et Google Discover ensemble

C'est le premier vrai choc en ouvrant la donnée. Sur la même période et le même domaine, les deux canaux ne racontent pas la même histoire.

Le Search se contracte progressivement à partir de l'été 2025. Discover, lui, trouve son public sur la fin 2025 et explose début 2026. Les pics éditoriaux Discover ne sont plus des accidents, ils prennent la place que le Search est en train de céder.

Quand on compare les deux périodes janvier-avril 2025 et janvier-avril 2026, l'écart est sans appel.

Le Search a perdu 38 % de ses clics. Discover en a gagné 67 %. Le total cumulé reste négatif (autour de -28 %), mais la composition du SEO du site a complètement changé.

En janvier 2025, Google Discover représentait 10 % de mon trafic SEO mensuel. En janvier 2026, 33 %. Il a triplé son poids relatif en douze mois. Sur les bons mois, il atteint maintenant un tiers du trafic SEO. Pour un site éditorial qui le traitait comme un bonus il y a un an, c'est devenu un canal que je ne peux plus ignorer.

Sur l'ensemble des 16 mois, le Search reste très majoritaire (86 %) et Discover pèse 14 % du SEO global. Mais c'est une moyenne lissée par les premiers mois où Discover était encore marginal. La trajectoire est plus parlante que la moyenne.

C'est aussi pour ça que comprendre comment fonctionne Discover devient prioritaire. Le reste de l'article s'attaque à cette question.

La fenêtre Discover : un sprint, pas un marathon

Quand on regarde le cycle de vie de chaque page individuellement, sur les 198 articles ayant fait au moins 500 clics Discover, un profil sort de manière extrêmement reproductible.

Une page Discover atteint son pic à J+1 dans la majorité des cas. À ce pic, elle fait en médiane 37 % de tout son trafic Discover futur. Le jour de la publication elle-même n'en fait que 10 %, le temps que Google la repère et la pousse dans les feeds. Ensuite c'est une décroissance en cloche, J+2 à 19 %, J+3 à 9 %, J+4 à 5 %. À J+7 il ne reste plus rien.

L'image devient encore plus parlante quand on superpose les trajectoires individuelles du top 10 sur la courbe médiane.

Toutes les pages convergent vers le même profil. Quelques-unes pèsent à J+2 plutôt qu'à J+1, l'amplitude varie, mais la forme est la même. Une publication, un pic 24 à 48 heures plus tard, une retombée nette en moins d'une semaine.

Deux chiffres viennent compléter ce constat.

Sur les pages qui ont performé, 66 % atteignent leur pic dès J+1, 94 % au plus tard à J+3. Et la durée totale d'exposition tourne autour d'une semaine et demie, avec très peu de pages qui restent visibles au-delà de deux semaines. Les rares pages qui durent plus longtemps sont des cas particuliers : revivals saisonniers, sujets qui rebondissent.

Une observation contre-intuitive vient renforcer le tout. La corrélation entre la durée de vie d'une page Discover et son volume total de clics est de 0,16. Quasi nulle. Une page qui perce fort à J+1 fera plus de clics totaux qu'une page qui tient une semaine à régime modeste.

Ce point change la façon dont on doit penser Discover. Ce n'est pas un canal qu'on alimente en continu pour un retour étalé. C'est une mécanique de pic à 72 heures, sur laquelle il faut tout jouer dès la publication.

Deux univers parallèles sur le même domaine

J'attendais de la donnée croisée Search/Discover qu'elle me confirme une intuition : les pages qui marchent en Search ne marchent pas en Discover. Ce que la data montre est encore plus extrême que je ne le pensais.

Sur 16 mois, le top 50 des pages Discover et le top 50 des pages Search n'ont strictement aucune URL en commun. Zéro. Sur le top 100 contre le top 100, il y en a une seule. Pour les URLs qui sont actives dans les deux canaux (au moins 100 clics chacun), la corrélation entre les volumes Search et Discover est de -0,04. Statistiquement, c'est zéro.

Pour donner une idée plus concrète : les pages qui font le plus de clics Discover sont presque toutes présentes en Search aussi, mais à une position moyenne en page 1 basse (autour de la 7e position) et avec un trafic Search marginal, des dizaines de fois inférieur à leur volume Discover.

Les pages qui entrent sur Discover sont des actualités fraîches : tests d'updates, annonces de mods, collaborations, sujets qui ont une fenêtre de pertinence courte. Les pages qui rentrent en Search sont l'inverse : guides evergreen, FAQ techniques, fiches mods, pages de catégorie. Deux types de contenus, deux logiques de visibilité, et aucun chevauchement réel au sommet.

Une nuance à garder en tête : une page qui perce sur Google Discover est par construction récente, elle n'a pas eu le temps de capitaliser sur le Search comme les guides evergreen qui sont indexés depuis des mois et qui cumulent du trafic au long cours. Le score Search d'une page Discover n'est donc pas comparable à celui d'une page Search à équivalence d'âge. L'absence de chevauchement reste réelle, mais elle est en partie mécanique : on compare un sprinter à des coureurs de fond qui courent depuis bien plus longtemps (mais la comparaison me paraissait tout de même intéressante à faire).

Conséquence directe : il faut arrêter de penser Google Discover comme un effet de bord du SEO. Optimiser pour Le Search ne fait pas rentrer une page sur Google Discover, et inversement. Ce sont deux algorithmes avec deux logiques.

Les pages qui rentrent sur Google Discover

J'ai crawlé l'intégralité des URLs apparues dans Discover sur 16 mois pour regarder ce que les pages performantes ont en commun. Quelques patterns nets sortent.

Les titres avec point d'interrogation affichent un CTR pondéré de 6,49 %, contre 4,39 % en moyenne (+48 %). Les formats "Top X / liste" font 5,91 % (+35 %). Sur 238 pages, seules 16 utilisent ces formats massivement sous-utilisés. L'année dans le titre ou la mention d'une version (1.21.9, 26.1) ne change rien au CTR, mais les pages qui en contiennent font deux à trois fois plus de clics médians : ce sont des sujets qui captent un volume d'audience supérieur, indépendamment du taux de clic.

Les articles de 1 200 à 1 800 mots font cinq fois plus de clics médians que ceux de 500 à 800 mots. Le CTR ne bouge presque pas (4,3 % à 4,7 %), mais le volume capturé augmente avec la longueur jusqu'à 1 500 mots, puis plafonne. Discover ne récompense pas la profondeur, les articles plus longs ont juste mécaniquement plus de chances d'être recommandés à un éventail plus large d'utilisateurs.

Les écarts entre catégories WordPress sont massifs. En prenant « News Minecraft » comme référence à 100, les catégories adossées au calendrier Mojang surperforment toutes : « Mise à jour » à 249, « Minecraft Live » à 197, « Minecraft 1.21 » à 170. À l'inverse, les catégories evergreen (Mods, Modpacks, Resource Pack, Shaders) tournent autour de 35 à 60. Quand on s'éloigne du cœur actualité Minecraft, la performance Discover s'effondre. Discover récompense les pages qui parlent d'actualité immédiate du jeu, pas les pages utiles aux joueurs en mode evergreen.

À longueur égale, les pages riches en images surperforment. Sur la tranche 800-1500 mots, passer de 6-15 images à 25 et plus multiplie la médiane de clics par 1,7. Discover affiche des cards avec image principale : plus l'article propose de visuels exploitables, plus Google peut sélectionner une image pertinente pour la carte du flux.

Dernier signal éditorial isolable : la divergence entre le H1 (qui est aussi le Title HTML SEO) et le tag og:title qu'on personnalise pour le feed Discover. Sur 267 pages crawlées, 122 (46 %) ont un og:title différent du H1.

Toutes catégories confondues, l'effet est marginal : +21 %. Mais isolé sur News Minecraft (80 pages, pilier du trafic Discover) et stratifié sur les articles de 800-1500 mots pour neutraliser le facteur de confusion qu'est la longueur, l'effet net est de +48 %. La vue brute sur News non stratifiée affiche même +77 %, mais une partie de cet écart vient de ce que les pages avec og:title personnalisé sont aussi plus longues en moyenne : le +48 % est le chiffre net. Sur les autres catégories, l'effet n'est pas significatif.

Le H1 d'un article WordPress est contraint par les bonnes pratiques SEO (descriptif, mots-clés, longueur calibrée). Or Discover affiche le og:title, pas le H1. Reformuler ce tag pour qu'il soit plus journalistique, exactement ce qu'on ferait pour une accroche de presse, augmente sensiblement le CTR de la card. Levier souvent négligé parce qu'il demande une intervention manuelle par article et qu'il n'apparaît pas dans les outils SEO classiques, c'est un des rares signaux éditoriaux qui produit un effet net après contrôle de la catégorie et de la longueur.

Trois cas d'OG title personnalisés, en pratique

Trois articles dont l'og:title a été personnalisé alors que l'og:image est restée identique au thumbnail. Les multiplicateurs ci-dessous comparent la performance de l'article à la médiane du site (1989 clics) : ils mélangent l'effet du sujet et l'effet du titre, donc ils ne mesurent pas le titre seul. L'effet isolable du titre, lui, reste le +48 % mesuré plus haut. Ces cas montrent le « comment », pas le « combien ».

Cas 1 - News Minecraft, ×11 vs médiane du site

• H1 : « 10 collaborations Minecraft improbables qu'on rêve de voir »
• og:title : « Minecraft x Tamagotchi, Durex, IKEA ... quand les blocs envahissent la vraie vie »

Listicle générique remplacé par un teaser concret avec des marques iconiques.

Cas 2 - News Minecraft, ×7,6 vs médiane du site (test récent)

• H1 : « Minecraft Java accueille enfin une liste d'amis intégrée au jeu »
• og:title : « Mojang ajoute enfin cette fonctionnalité à Minecraft après quinze ans d'attente »

Le H1 dit ce qu'est la fonctionnalité, l'og:title ne le dit pas. Ancrage émotionnel (« enfin », « quinze ans d'attente ») et attente créée : ne pas savoir devient la raison de cliquer.

Cas 3 - Modpacks, ×7 vs médiane du site

• H1 : « BigChadGuys Plus, le modpack Minecraft qui fait rimer détente et Cobblemon »
• og:title : « Ce modpack Minecraft combine Stardew Valley et Pokémon dans un univers apaisant »

Nom obscur retiré, Cobblemon (niche) remplacé par « Pokémon » + « Stardew Valley » (pop culture universelle).

Deux logiques se dégagent : soit retirer le nom propre obscur pour une référence pop culture, soit retirer la description précise pour un ancrage émotionnel. Le H1 décrit la page, l'og:title vend le clic.

Trois cas d'og:image personnalisée, en pratique

L'og:image est plus rare à personnaliser : 22 pages sur 267 (8 %). Effectifs trop faibles pour mesurer un effet propre, et là encore les multiplicateurs ci-dessous (vs médiane du site) intègrent l'effet du sujet, pas seulement celui de l'image. Trois cas hauts performeurs restent parlants pour le « comment ».

Cas 1 - News Minecraft, top 1 absolu Discover sur 16 mois (×41 vs médiane du site)

• post_thumbnail : scène composée de dix bébés animaux. Beaucoup de sujets simultanés, sujet principal pas évident en miniature.

• og:image : comparatif côte-à-côte de deux poussins avec les dates 2011 et 2026. Format meme « avant/après ».

Format meme qui se lit en moins d'une seconde, mais aussi un visuel que j'ai repris d'un meme déjà viral sur X et Reddit au moment de la publication. Je l'ai refait moi-même pour Minecraft.fr, mais le format profitait d'un effet de reconnaissance dans le feed.

Cas 2 - News Minecraft, ×7,6 vs médiane du site (test récent, image décalée)

• post_thumbnail : split-screen littéral, capture du menu Friends Minecraft accolée à un visuel d'Alex et Steve qui font un high-five. Image descriptive et thématique.

• og:image : personnage Minecraft seul, bouche démesurément ouverte façon meme « surprise / mind-blown ». Aucun lien visuel avec la fonctionnalité « liste d'amis ».

Test délibéré. L'image ne montre pas le sujet, elle arrête le scroll par incongruité dans un feed où la plupart des cards montrent littéralement leur contenu. Il faut aussi savoir que j’ai vraiment forcé pour cet article je lui ai mis en og :Ttitle : « Mojang ajoute enfin cette fonctionnalité à Minecraft après quinze ans d'attente ».

Cas 3 - Resource Pack, ×11 vs médiane du site

• post_thumbnail : personnage en posture sage avec overlay « ENDERWOMAN – PACK DE TEXTURE ».

• og:image : version féminine et sexualisée du Enderman, silhouette stylisée sans texte. Image aguicheuse, à la limite de ce qui passe sur Discover.

Le levier principal ici n'est probablement pas le retrait du branding, c'est juste très aguicheur. J'avais des doutes au moment de la mise en ligne, je voulais aller un peu plus loin, c'est passé.

Je n'ai pas encore trouvé la formule magique sur l'og:image, je teste. Mais aucun de ces trois cas ne suit le registre descriptif du post_thumbnail : meme viral, image suggestive, image décalée. Point pratique : les trois sont des images générées avec une IA (Gemini), sans problème côté Discover.

Le rythme du week-end

Discover, comme tout flux de recommandation, dépend de quand les gens scrollent leur téléphone.

Le dimanche est le meilleur jour, +41 % vs le mardi qui est le pire. Pour un site loisir comme Minecraft.fr, c'est cohérent : le dimanche, les gens ont du temps, ils sont sur leur téléphone, ils scrollent leur feed Google.

Combiné avec la mécanique de pic à J+1 vue plus haut, ça donne une règle pratique : viser une publication sur la fin de semaine pour faire coïncider le pic avec la fenêtre samedi-dimanche.

Le rythme de publication : Discover est probabiliste

J'ai croisé l'export WordPress de mes articles publiés sur 16 mois avec le trafic Discover quotidien. Le premier constat est moins flatteur que je ne l'imaginais.

Pas un seul jour de visibilité. Ils sont publiés, indexés, mais le canal ne les pousse pas. À l'autre bout, environ 5 % font des hits significatifs, et 23 % font des volumes solides sans être des hits. Le tiers central perce à petite dose.

La distribution est extrêmement déséquilibrée : la majorité des publications passent dans le vide, une petite minorité capte l'essentiel du trafic. Et le taux de percée varie nettement d'un trimestre à l'autre, entre 38 % et 61 %, sans qu'on puisse identifier un rythme éditorial qui le corrigerait. Quand l'actualité Minecraft est riche, Discover pousse plus. Quand elle est plate, il ne pousse rien, peu importe ce que vous publiez.

J'ai vérifié si publier plusieurs articles dans la même journée changeait quelque chose au comportement de chaque article individuel.

À une approximation près, non. Un article publié seul dans la journée fait à peu près le même profil de trafic Discover que les articles publiés en groupe de deux ou trois. Pic à J+1, retombée en cloche, fin de cycle vers J+5 à J+7. Les articles publiés en groupes de trois ont un pic légèrement plus tardif (J+2) et une queue un peu plus longue, probablement parce qu'ils se nourrissent mutuellement quand ils traitent du même sujet d'actualité, mais l'effet est marginal. 

L'effet inverse, en revanche, est massif et brutal. Quand je suis parti deux semaines en avril 2026, le site est resté treize jours sans publication.

Le trafic Discover s'étiole pendant trois ou quatre jours, le temps que les derniers articles publiés terminent leur cycle. Puis il s'effondre. Sur les sept jours suivants, le canal passe de 128 clics à 0 ou 1 clic par jour. Discover ne se met pas en pause poliment quand on s'arrête, il tarit complètement en moins de dix jours.

À l'échelle mensuelle, la corrélation entre volume de publications et trafic Discover est de 0,60 (Spearman). Solide, mais à interpréter avec prudence : sur les mois d'updates Minecraft, je publie plus ET le canal est plus généreux, sans qu'on puisse complètement isoler ce qui cause quoi.

Plus de publications ne garantit pas plus de Discover. Janvier 2026 a fait le meilleur score de la période avec 34 articles, alors qu'avril 2025, avec 44 articles publiés, en a généré beaucoup moins. Le contenu compte, le timing dans le cycle d'actualité compte, et la chance compte autant que la cadence.

Ce que la donnée dit en synthèse, c'est que chaque article publié est un pari avec environ 50 % de chances de percer, et environ 5 % de chances de faire un vrai hit. La seule façon de jouer contre cette probabilité, c'est de multiplier les publications. Pas pour qu'elles s'additionnent, mais pour qu'on multiplie les tickets de loterie. À l'inverse, arrêter de publier ne ralentit pas le trafic, il l'éteint. Le canal se nourrit du flux et n'a aucune mémoire patrimoniale au-delà de quelques jours.

Discover suit le calendrier Mojang, pas le mien

Quand on dit "le canal est probabiliste", il faut préciser de quoi dépend la probabilité. J'ai testé une régression linéaire sur les variables de contenu (longueur, nombre d'images, catégorie, etc.) pour voir ce qui prédit le volume de clics Discover par page. Le R² ressort à 1,7 %. Autrement dit, ce qu'on peut lire dans la page elle-même n'explique presque rien. Le reste, 98 % de la variance, dépend d'autre chose. J'ai croisé les pics Discover de la période avec le calendrier officiel des events Minecraft (Minecraft.net, Minecraft Wiki). Le résultat ne laisse pas beaucoup de place à l'interprétation.

Sur les 30 jours qui ont fait le plus de clics Discover sur 16 mois, 24 coïncident avec un évent majeur: un Minecraft LIVE (annonce officielle), un game drop (release de version), une snapshot relayée par la presse gaming, ou un event transmédia comme la sortie du film en avril 2025.

Le pic absolu de la période, le 9 janvier 2026, ne tombe pas un jour de release. Il tombe deux jours après la première snapshot 26.1, au moment où Windows Central, PC Gamer, Beebom et toute la presse gaming publient simultanément sur les nouveaux baby mobs. C'est un pic de buzz médiatique pur, pas de release, et c'est la fenêtre où n'importe quelle page Minecraft.fr publiée sur ce thème a une chance d'être propulsée par Discover.

Le multiplicateur est massif. Dans les fenêtres de quatorze jours autour des events majeurs, le trafic moyen est entre quatre et dix fois supérieur au trafic des jours "calmes" hors fenêtres. À l'inverse, les périodes de creux éditorial Mojang (juillet-août 2025, février 2026) restent à un plancher faible quoi qu'on publie. Discover n'est pas neutre vis-à-vis du sujet du site. Pour Minecraft.fr, il existe dans la mesure où Mojang nourrit le cycle d'actualité.

Cette dépendance change la lecture du constat "probabiliste". Ce n'est pas que chaque article est un pari aléatoire ; c'est que chaque article est un pari. Publier au bon moment du cycle (snapshot, annonce, release) augmente massivement les chances de percer. Publier hors fenêtre les annule presque.

C'est aussi un angle qui se transpose à d'autres niches éditoriales avec un calendrier exogène prévisible. Tech (les keynotes Apple, les drops Samsung, les sorties iOS), sport (les calendriers de saison), gaming (les game drops, les sorties d'extensions), cinéma (les sorties hebdomadaires). Si vous identifiez le calendrier qui pilote l'attention de votre audience, vous identifiez la fenêtre où Discover devient pilotable.

La reprise est asymétrique : on éteint en 7 jours, on rallume en 24 heures

Quelques semaines après la première version de cette analyse, j'ai pu observer la mécanique exactement inverse : ce qui se passe quand on recommence à publier après un long silence. Comme indiqué en début d'article, j'ai repris un rythme de publication quasi quotidien pendant deux semaines pour tester. Le résultat est plus intéressant que ce que je pensais.

Récapitulatif rapide de la fin du silence : du 22 au 27 avril, le canal s'effondre progressivement de 128 clics à 5 clics. Du 28 avril au 1er mai, il est à 0 ou 1 clic par jour, c'est-à-dire complètement éteint. Sept jours pour passer d'un trafic normal à zéro absolu.

Le redémarrage des publications, lui, est radicalement différent. Le 2 mai, première publication après le silence, le canal réagit immédiatement : on remonte à 33 clics dans la journée. En 48 heures, le canal est revenu à un niveau supérieur à la baseline historique du site, et il y est resté pendant les deux semaines suivantes.

Il ne pénalise pas le site d'avoir disparu pendant deux semaines, il ne le fait pas patienter en zone grise pour rétablir la confiance. Dès qu'un nouvel article publié rentre dans son cycle d'évaluation, le canal reprend le service comme si rien ne s'était passé. La latence de réactivation est de l'ordre de l'heure, pas du jour.

10 % des pages font la moitié du trafic

La distribution du trafic Discover par page suit une loi de Pareto sévère.

Les 10 % d'URLs les plus performantes font 48 % du trafic. Les 20 % font 66 %. Les 50 % font 92 %. La moitié restante du catalogue Discover ne ramène que 8 % des clics. Coefficient de Gini : 0,65.

Concrètement, sur 16 mois, l'article le plus performant représente à lui seul plus de 7 % de tout le trafic Discover du site. À côté, des dizaines de pages publiées font une fraction de ce volume.

C'est exactement la conséquence de ce qu'on vient de voir sur le caractère probabiliste du canal. Sortir un hit dans le mois compte plus que publier vingt articles. Mais le hit n'est pas planifiable : il dépend du sujet, du timing, de la chance. La seule chose qu'on peut faire, c'est multiplier les paris.

L’enseignement le plus inattendu : Discover paye plus, mais affiche moins

Pour cette dernière partie j'ai croisé les données GSC avec quatre mois de données régie. Pour pouvoir comparer la valeur monétaire d'un clic Discover à celle d'un clic Search, j'ai classé chaque page selon son mix de trafic sur 16 mois. Les pages dont 80 % ou plus du trafic SEO vient de Discover sont catégorisées "Pure Discover", celles dont 80 % viennent de Search sont "Pure Search", le reste est "Mixte". J'ai ensuite calculé un indice avec les pages Pure Search comme référence à 100, pour comparer les cohortes en relatif.

Le résultat va à rebours de ce qu'on entend habituellement.

À pageview égale, les pages Pure Discover génèrent un revenu inférieur de 26 % aux pages Pure Search. Si on s'arrête là, on conclut que Discover monétise moins bien.

Mais quand on regarde la densité publicitaire, on comprend pourquoi. Les pages Pure Discover affichent en médiane 2,5 fois moins de blocs publicitaires par session que les pages Pure Search. Ces dernières sont longues, scrollées en lecture, l'inventaire publicitaire est riche. Les articles d'actu Discover sont courts, lus rapidement, l'inventaire est mécaniquement plus pauvre.

Si on neutralise cet effet en ramenant le revenu au bloc publicitaire affiché, le classement s'inverse. Le clic Discover vaut plus, mais sur moins de blocs.

Le finding qui surprend le plus est la cohorte intermédiaire. Les pages Mixtes, celles qui rentrent à la fois dans Search et dans Discover, sont les plus rentables au PV : +18 % par rapport à Pure Search. Elles cumulent les deux avantages : densité pub décente parce qu'elles ont une vie evergreen, plus de visiteurs Discover de bonne qualité par bloc. Précision honnête : on parle de 15 pages observées, c'est moins solide statistiquement que les 173 pages Pure Search, à prendre avec prudence.

Implication actionnable : pour un éditeur qui veut maximiser le revenu sans tuer l'UX, le bon levier est de densifier les blocs sur les pages à fort potentiel Discover. Pas de transformer toutes les pages en pavés indigestes, mais d'aller chercher l'inventaire publicitaire qui manque sur les formats actu, là où il y a probablement de la place pour deux ou trois blocs supplémentaires sans dégrader l'expérience.

Comment je vois Discover, après ces 16 mois de data

Discover était traité jusque-là comme un trafic bonus : plaisant quand il arrivait, frustrant quand il disparaissait, jamais vraiment piloté. Les chiffres de l'année écoulée disent autre chose. Sur Minecraft.fr, il pèse maintenant un tiers du trafic SEO sur les bons mois. Il faut arrêter de l'observer et commencer à le piloter, avec ses propres KPI et son propre rythme.

Cinq choses à retenir. La fenêtre est de 72 heures : le temps qu'on s'aperçoive qu'un article a percé, il a déjà fait 80 % de son trafic. La moitié des articles ne percent jamais, et la seule parade est de multiplier les publications, pas pour un effet de levier mais pour multiplier les tickets de loterie. Arrêter de publier éteint le canal en quatre ou cinq jours, sans mémoire patrimoniale. Les pics suivent un calendrier exogène, le calendrier Mojang ici, les keynotes ou les sorties ailleurs : il faut aligner le rythme de publication dessus et accepter les périodes plates. Enfin, Discover et Le Search sont deux jeux différents, pas un effet de bord l'un de l'autre.

Un dernier point sur la valeur : le clic Discover vaut plus qu'on ne le pense, pas par session mais par bloc. Ce qui plafonne son revenu, ce n'est pas la qualité du clic, c'est l'inventaire publicitaire des pages d'actu. Un levier opérationnel à activer, sans complexité technique.

Je n'ai aucune illusion sur les limites de l'analyse : mono-site, niche très particulière, rythme éditorial pas optimal pour un canal qui demande de la régularité. Les ordres de grandeur (pic à J+1, fenêtre 72 heures, absence d'overlap Search/Discover, taux de percée autour de 50 %) me semblent transposables, les chiffres absolus non. Si vous pilotez un site éditorial avec de la donnée Discover, je suis curieux de savoir ce que vos chiffres racontent. C'est en croisant des cas qu'on aura une lecture mature de ce canal.

PS : deux choses que j'ai faites pendant que j'écrivais ce dossier

Depuis 2025, Google génère un profil par éditeur sur profile.google.com, avec un bouton « Suivi sur Google », les comptes sociaux et les derniers posts. Le 4 juin 2026, Google a officialisé la feature sous le nom « Search profiles » : profils réclamables, enrichissables (bannière, jusqu'à 8 liens, posts épinglés), reliés au Knowledge Graph, avec une section Insights en bêta adossée à la Search Console. Sylvain Deauré  a décortiqué l'annonce et ce qu'elle implique pour les éditeurs. Pour l'instant, les profils enrichis sont réclamables aux États-Unis uniquement, mais le profil auto-généré existe déjà pour les éditeurs francophones identifiés comme entité par Google. C'est le cas de Minecraft.fr : j'ai trouvé le mien grâce à l'outil de monitoring de 1492.vision. Si vous voulez creuser, son article est la meilleure synthèse disponible aujourd'hui.

Google propose aussi à l'utilisateur d'ajouter un site à ses sources préférées via google.com/preferences/source. J'ai intégré ce CTA sur Minecraft.fr récemment, à côté du « Suivez-nous » classique. L'impact mesurable sur Discover est encore incertain à mon échelle, je penche plus sur un effet SEO (préférences utilisateur) que sur du Discover pur, mais c'est gratuit à mettre en place et ça ne mange pas de pain.

L’article "Google Discover sur Minecraft.fr : 16 mois de data décortiqués" a été publié sur le site Abondance.

Un problème structurel, pas un problème d'échelle

La première erreur consiste à traiter le SEO d'un réseau comme un SEO local « en plus grand ». Multiplier les fiches Google Business Profile, reproduire les mêmes pages à 2 300 exemplaires avec le nom de la ville en seule variable : c'est la voie la plus directe vers la cannibalisation interne et les pénalités pour contenu dupliqué.

Le vrai problème est structurel. Il touche à plusieurs dimensions simultanément :

• La cannibalisation interne survient dès que plusieurs pages d’un même domaine ciblent des requêtes proches sur une même zone géographique. Pour un réseau dense comme AD, dont les garages couvrent l'ensemble du territoire national, le risque est permanent. Deux établissements à 15 kilomètres de distance peuvent alors se retrouver en concurrence directe dans les SERPs pour les mêmes requêtes locales.
• La cohérence NAP (Name, Address, Phone) est un chantier en soi. Une adresse mal renseignée, un numéro de téléphone obsolète, une variation dans la typographie du nom : chacune de ces incohérences affaiblit les signaux de confiance envoyés aux moteurs de recherche. Sur 2 300 points de vente, maintenir cette cohérence sans gouvernance centralisée relève de l'impossible.
• La gouvernance des fiches pose enfin la question de qui fait quoi. Les franchisés ont-ils la main sur leur fiche GBP ? Peuvent-ils modifier les horaires, répondre aux avis, ajouter des photos ? Et si oui, comment le réseau maintient-il une cohérence d'ensemble ? Ce n'est pas seulement une question SEO : c'est une question d'organisation.

L'architecture, vrai sujet du SEO multi-établissements

Avant même de parler de contenu ou de backlinks, l'architecture du site conditionne tout. Pour un réseau de garages, deux types de pages coexistent avec des logiques radicalement différentes : les pages établissement et les pages prestation.

Les pages établissement (ou pages locales) répondent à l'intention de proximité : « garage AD à Lyon », « réparateur auto Bordeaux ». Elles ciblent une géographie précise et doivent contenir les signaux d'ancrage local : adresse structurée en données Schema, horaires, avis, photos du point de vente, accès.

Les pages prestation, elles, répondent à une intention transactionnelle qualifiée. L'internaute sait ce dont il a besoin, il cherche à savoir où et à quel prix le faire réaliser. Ces deux logiques ne s'organisent pas de la même façon dans l'arborescence, et les confondre produit des pages hybrides qui ne satisfont pleinement ni l'une ni l'autre des intentions.

La logique de silo (c’est-à-dire organiser les contenus en thématiques étanches avec un maillage interne cohérent) prend ici tout son sens. Les pages prestation s'articulent avec les pages établissement, qui remontent vers des pages catégorie nationales, lesquelles renvoient vers les prestations. Loin d’être un simple exercice de style, ce maillage signale à Google la pertinence thématique de l'ensemble et distribue le jus de lien efficacement.

Les pages prestation comme levier de capture d'intention

C'est probablement le levier le plus sous-exploité dans les stratégies SEO des réseaux. Une fiche établissement seule, même parfaitement optimisée, capte l'internaute qui cherche « un garage près de chez moi ». Elle ne capte pas celui qui cherche « remplacement amortisseur arrière prix » ou « changement kit distribution devis ». Or ces requêtes transactionnelles sont souvent plus proches de la conversion.

Une page de prestation bien construite répond à une intention locale précise tout en s'intégrant bien à l'arborescence. Une page de prestation comme le remplacement des amortisseurs chez AD illustre bien ce mécanisme : elle répond à une intention locale précise tout en s'intégrant à une arborescence réseau.

Pour qu'une telle page soit réellement performante en SEO, elle doit satisfaire plusieurs critères. L'intention doit être clairement identifiée et la page doit y répondre sans ambiguïté : l'internaute qui arrive sur une page « remplacement amortisseurs » attend des informations sur la prestation (quand la changer, comment se déroule l'intervention, quel délai), pas un discours corporate sur l'histoire du réseau.

La structure doit également faciliter la compréhension rapide : les informations pratiques (prix indicatif, durée de l'intervention, garantie) doivent être accessibles sans effort. Les signaux de confiance, à l’image de la garantie pièces et main-d’œuvre 24 mois proposée par AD, jouent un rôle doublement important : ils répondent aux objections de l'internaute et renforcent les signaux E-E-A-T aux yeux de Google.

Les preuves, enfin : avis clients sur la prestation spécifique, photos d'intervention, labels et certifications du réseau. Un réseau de réparateurs indépendants sous enseigne commune, comme AD, dispose ici d'un avantage structurel : la caution de la marque nationale, combinée à l'ancrage local de chaque garage, produit une forme de crédibilité difficile à répliquer pour un acteur purement national ou purement local.

Cohérence et signaux de confiance à l'échelle

Le SEO local d'un réseau ne se joue pas uniquement sur le site. Il se joue aussi au sein de l'écosystème. Les fiches Google Business Profile, les données structurées, les avis ; autant de leviers qui, mal gérés à l'échelle, peuvent devenir de véritables boulets.

Les fiches GBP méritent une attention particulière. Pour un réseau comme AD, chaque fiche doit être revendiquée, vérifiée, et maintenue à jour. Le schema.org LocalBusiness, et plus précisément le type AutoRepair pour les garages, permet de structurer les informations de chaque établissement de façon lisible par les moteurs : adresse, horaires, services proposés, zone de chalandise. La cohérence entre les données structurées du site et le contenu des fiches GBP représente un important signal de confiance.

Les avis des clients constituent aussi un autre levier critique. Pour un réseau de 2 300 établissements, la politique d'encouragement aux avis et de réponse systématique doit être décidée au niveau central et mise en œuvre au niveau local. Un garage avec 200 avis positifs récents envoie des signaux très différents d'un garage sans avis, même si leurs pages de prestation sont identiques.

La couverture nationale est, elle aussi, un signal E-E-A-T sous-estimé. Un réseau présent dans toutes les régions, avec une densité suffisante pour garantir un garage à moins de 30 minutes de la plupart des Français, envoie un signal d'expertise et d'autorité que les acteurs locaux isolés ne peuvent pas contester. Encore faut-il que cette présence soit documentée et structurée dans l'architecture du site.

Ce que regarde l'internaute, ce que regarde Google

L'internaute qui cherche à faire réparer son véhicule ne cherche pas l’offre la moins onéreuse en premier. Il cherche souvent à comprendre ce qui justifie les différences de prix, ce qui est inclus dans la prestation, ce que couvre la garantie. Les requêtes de type « prix remplacement amortisseur », « combien coûte un changement de freins » ou « quelle garantie après réparation » sont des requêtes informationnelles à intention transactionnelle. Pour le dire simplement, l'internaute veut d’abord se faire une opinion avant de prendre rendez-vous.

Google a parfaitement intégré cette réalité. Les pages qui répondent clairement à ces questions, incluant des fourchettes de prix, des explications sur les critères de qualité (pièces d'origine vs pièces équivalentes, garantie, certification des techniciens), des éléments de réassurance, obtiennent de meilleures positions que les pages qui se contentent d'un formulaire de devis.

Pour un réseau comme AD, c'est une opportunité éditoriale. C’est l’occasion de produire des contenus qui aident l'internaute à comparer intelligemment, en valorisant les critères sur lesquels le réseau est réellement compétitif (couverture, garantie, expertise) plutôt qu'en cherchant à gagner sur le seul critère du prix.

Ce que les réseaux multi-établissements peuvent retenir

Les enseignements du SEO local automobile sont largement transposables à d'autres secteurs : franchises de restauration, réseaux de santé, retail brick-and-mortar. Quelques principes structurants méritent d'être retenus :

• Distinguer dès l'architecture les pages établissement et les pages prestation, avec des logiques de contenu et d'optimisation distinctes pour chacune.
• Traiter la cohérence NAP comme un chantier de gouvernance, pas comme une tâche SEO ponctuelle.
• Valoriser les pages prestation comme des leviers de capture d'intention transactionnelle, pas seulement comme des déclinaisons des pages établissement.
• Utiliser les signaux de confiance du réseau (garantie, présence nationale, certifications) comme des arguments E-E-A-T, pas seulement comme des arguments commerciaux.·      Et surtout : résister à la tentation de l'échelle pour l'échelle. 2 300 pages locales de piètre qualité font moins de SEO qu'une architecture bien pensée avec des pages de prestation soignées et des fiches GBP correctement maintenues.

L’article "Référencement local et secteur automobile : comment un réseau comme AD tire parti du SEO pour ses 2 300 garages ?" a été publié sur le site Abondance.

« Tailor Your Feed » est la première fois qu’un utilisateur peut façonner son feed Discover en écrivant, en langage naturel, ce qu’il veut voir. Nous l’avons suivi depuis sa première apparition dans Search Labs¹ (US) jusqu’au pipeline² qui l’alimente. Dix points clés :

1. Une couche de contrôle explicite. Votre prompt est transformé en actions SEE_MORE / SEE_LESS, appliquées après un rafraîchissement du feed.
2. Vraisemblablement un LLM³ sous le capot. Un thread de conversation persistant, et votre prompt transformé en instructions appliquées à votre feed (en temps réel et dans la durée).
3. Le changement de nom. « Tailor Your Feed » est devenu « Add topics to your feed » au printemps 2026, avec une entrée de type chat.
4. Le pipeline back-end. historicalnaturallanguagetuningcontent.f⁴, le jumeau « historique » de naturallanguagetuningcontent.f.
5. Deux façons de choisir le contenu. L’expansion par entités⁵ / intérêts (la majorité) vs un fan-out⁶ par query intent⁷ (la minorité), ce dernier étant le mécanisme GEO⁸ à l’intérieur de Discover.
6. Une attribution visible. Le label « You asked to see », le tag « resulting from natural language tuning », et un historique des prompts dans My Activity.
7. Des sites de niche et de petits créateurs mis en avant. Créateurs de recettes vegan, Mississippi Today, un post LinkedIn, des blogs de niche sur l’immobilier japonais et, à titre d’illustration du comportement du retrieval⁹, des éditeurs hors des grands médias habituels (VentureBeat remonté sur un prompt « sites de niche », sans être un petit site).
8. Un contournement de la popularité. Ce pipeline porte surtout du contenu qui n’avait quasiment jamais circulé dans Discover auparavant, à l’inverse des pipelines classiques qui re-servent des articles déjà populaires.
9. Ce que ça change pour les éditeurs. Le pouvoir de sélection passe à l’utilisateur, ouvrant une troisième voie de visibilité pour les petits sites de niche.
10. Encore EN-only, encore naissant. Search Labs US uniquement (FR ≈ 0 %), adoption encore timide. La suite.

Méthodologie

Cet article combine deux flux d’observation :

• Un suivi terrain de la fonctionnalité dans l’app Google depuis décembre 2025 : états de l’UI, réponses serveur, tags d’attribution, et comportement du feed après chaque « Refresh / Update your feed ». Capturé sur nos appareils de test, comptes Search Labs US (anglais).
• Une lecture fine du feed lui-même : chaque carte peut être rattachée au pipeline qui l’a sélectionnée. En isolant les cartes servies par historicalnaturallanguagetuningcontent.f, on décrit le comportement de ce pipeline par rapport au reste du feed, à partir des données de suivi 1492.vision.

Trois précisions de formulation, volontaires :

• On décrit des résultats de distribution¹⁰, si un article avait déjà circulé dans Discover auparavant, pas des chiffres d’audience bruts. Quand on dit qu’une carte « n’a pas de distribution Discover antérieure », cela signifie qu’on ne trouve aucune trace de diffusion préalable dans notre base de suivi Discover.
• Aucun identifiant de compte n’apparaît dans cet article. Les exemples sont présentés sous la forme prompt → résultat, anonymisés.

Les mécanismes internes ci-dessous sont notre interprétation des données observées et de la recherche publique. Lorsqu’une date est inférée plutôt qu’ancrée, on le signale.

1) Ce qu’est « Tailor Your Feed » : une couche de contrôle explicite

Pendant des années, la personnalisation de Discover était implicite : Google inférait vos intérêts à partir des clics, du temps de lecture, des follows. « Tailor Your Feed » ajoute l’inverse, une couche explicite où vous écrivez simplement ce que vous voulez.

L’entrée actuelle en haut du feed : « What do you want to see? » avec un champ « Add topics to your feed ».

La fonctionnalité ouvre un panneau de type chat. On peut choisir un modèle proposé ou écrire librement.

La carte d’introduction « Tailor your feed » d’origine : « Say what you want in your own words », avec un bouton « Try now ».

Prompts suggérés : « Start showing me women’s basketball », « Keep me updated on country music », « Show me more of Cara Nicole’s videos », avec un champ libre « Ask for the kind of content you want ».

Ces suggestions correspondent à quatre intentions que les réponses serveur exposent : SEE_MORE, KEEP_UPDATED, CREATOR_MORE et SEE_LESS. Ce que vous écrivez est interprété en une (ou plusieurs) de ces actions, puis appliqué au feed une fois validé avec « Refresh / Update your feed ».

La fonctionnalité a été déployée via Search Labs, aux États-Unis uniquement.

L’entrée Search Labs : « Make your Discover feed truly yours by saying what you want to see. » Bêta, US uniquement.

Les itérations suivantes ont transformé le champ libre en modèles de départ explicites : « Show me content from… », « I want videos about… », « Keep me updated… ». Les mêmes verbes, désormais sous forme de chips.

Le panneau « What do you want to see? » avec ses modèles de départ : « Show me content from… », « I want videos about… », « Keep me updated… ».

2) Sous le capot : vraisemblablement un LLM qui transforme les prompts en actions

Le déroulé est simple : prompt → interprétation → réponse lisible + un résultat actionnable. Vous tapez un prompt, l’assistant répond en langage clair et propose des changements concrets, et un tap sur « Update your feed » les valide.

Une réponse représentative, observée dans les échanges de données pour le prompt « show me more content on seroundtable.com », ressemble à ceci :

{
  "feature": "Discover • Tailor your feed",
  "locale": "en-US",
  "thread_key": "chat_thread_key_082fa565-234a-451c-9318-1e9af8b9d734",
  "user_prompt": "show me more content on seroundtable.com",
  "assistant_text": "I can show you more content from Search Engine Roundtable (SERoundtable.com) related to your interests. Refresh your feed to apply these changes.",
  "result": {
    "status": "UNDERSTOOD_AND_ACTIONABLE",
    "actions": ["SEE_MORE"],
    "show_call_to_action": true,
    "count": 1
  },
  "ui_state_code": 2
}

Le prompt in-app qui a produit la réponse ci-dessus : « show me more content on seroundtable.com », et la réponse de l’assistant se terminant sur « Refresh your feed ».

Trois éléments ressortent :

• Un thread persistant. Le thread_key est stable d’un échange à l’autre, votre réglage est une conversation, pas un coup unique. Le même thread est de nouveau référencé quand, plus tard, une carte est rattachée à l’un de vos prompts passés.
• Des actions, pas des sujets. La réponse renvoie actions: ["SEE_MORE"]. Demandez à retirer un sujet et vous obtenez ["SEE_LESS"] ; un prompt nuancé peut renvoyer les deux, par ex. « new country music releases… but no celebrity gossip » donne ["SEE_MORE", "SEE_LESS"].
• Injection de contexte local. Les réponses sont interprétées avec votre contexte (locale, langue, localisation). Un « keep me updated about NBA » générique est revenu avec « Updates on the Brooklyn Nets », une équipe locale injectée depuis le contexte.

« keep me updated about nba » → l’assistant propose scores, actu équipes/joueurs, et « Updates on the Brooklyn Nets », une entité injectée localement.

Côté Google, votre phrase est transformée en un jeu d’instructions qui alimente l’étape de retrieval, avec une voie « offline » (appliquée dans la durée) et une voie en temps réel. C’est, à notre lecture, le glissement architectural que la fonctionnalité incarne : des vecteurs d’intérêts inférés vers un profil en langage naturel que vous écrivez vous-même.

3) Une chronologie sur six mois (décembre 2025 → juin 2026)

Nous avons documenté le déploiement au fil de l’eau. Dates ancrées sur des captures in-app et les changelogs de la fonctionnalité ; quelques-unes sont approximatives (signalées par « ~ »).

Décembre 2025 : première apparition (Search Labs, US). La fonctionnalité apparaît avec tout ce qui est décrit plus haut : le panneau de chat, la réponse JSON, le thread persistant, les quatre intentions, l’injection de contexte local. Première impression : l’effet est subtil, après plusieurs rafraîchissements, on voit quelques cartes dans le thème, mais rien de spectaculaire. (note de terrain, exemple)

« I need a break from negative news. Show me more feel-good stories, but keep the local and breaking news. » L’assistant liste les types de contenus positifs à attendre, puis propose « Refresh your feed ».

Autre exemple précoce : « can you show me https://dev.to/ on my feed » → l’assistant propose des articles de programmation, des tutoriels web et de l’actu software.

~13 janvier 2026 : le tag d’attribution. Google commence à marquer les cartes « resulting from natural language tuning » après un rafraîchissement et l’arbitrage SEE_MORE/SEE_LESS, permettant, pour la première fois, de savoir quelles cartes un prompt a réellement modifiées. Un historique des prompts apparaît aussi dans My Activity. (note de terrain)

« ‘Tailor your feed’ preferences in Discover. View and manage your prompts. » Une surface My Activity dédiée (ici, vide).

~février 2026 : le tuning « historique », et ce que fait vraiment SEE_LESS. Un second tag apparaît, « historical natural language tuning », pour les cartes influencées par un prompt passé. En testant « fewer X posts », on a vu Google remplacer les cartes X (Twitter) par des vidéos YouTube, et, notable, demander à retirer un sujet ne le retire pas vraiment : on obtient SEE_LESS, mais le sujet n’est pas supprimé du feed. (note de terrain)

~février 2026 : le test « niche ». À la demande de « plus de sites de niche / petits sites », le feed est revenu, au premier rafraîchissement, avec 2 cartes sur 10 modifiées par le prompt (c’est un snapshot ponctuel, pas une moyenne), faisant émerger VentureBeat et Mississippi Today, le tout premier résultat étant piloté par la demande. (note de terrain)

~février 2026 : le test « entité ». À la demande de « plus d’articles d’un créateur précis », Google a compris les sujets liés à ce créateur (entités), a rafraîchi, et a fait remonter un post LinkedIn de celui-ci, tagué « natural language tuning content ». (note de terrain)

~avril 2026 : le rebrand + le label « You asked to see ». « Tailor your feed » devient « Add topics to your feed » avec une UI de chat, et un label visible « You asked to see » marque désormais les cartes servies par le pipeline. (rebrand, label)

Une carte labellisée « You asked to see » : un listicle de figures historiques d’AOL.

« You asked to see » sur un article politique du Guardian.

« You asked to see » sur des cartes Search Engine Roundtable, l’éditeur demandé plus tôt remonte explicitement.

22 mai 2026 : les query intents (le fan-out). On confirme qu’au-delà de l’expansion par entités, certaines cartes du pipeline portent un query intent stocké, le prompt décomposé en requêtes de retrieval spécifiques, sur le même schéma que le « fan-out » GEO. (Plus de détails en section 5.) (note de terrain)

« You asked to see » s’applique aussi à la vidéo : une carte YouTube Crunchyroll/One Piece remontée par un prompt.

Juin 2026 : état actuel. L’entrée affiche « Add topics to your feed », et la fonctionnalité fait désormais remonter de petits créateurs bien en dehors des grands éditeurs (section 6).

4) Le pipeline derrière : historicalnaturallanguagetuningcontent.f

Chaque carte Discover peut être rattachée au pipeline qui l’a sélectionnée. « Tailor Your Feed » correspond à un couple dédié :

• naturallanguagetuningcontent.f, du contenu basé sur vos préférences en langage naturel courantes.
• historicalnaturallanguagetuningcontent.f, du contenu basé sur des prompts passés qui continuent d’influencer le feed (le tag « historical » de la chronologie).

Le pipeline récupère le contenu de deux façons distinctes :

• Mode A : expansion par entités / intérêts (la majorité). D’après le comportement observé, le prompt est mappé vers des entités et des sujets, et le feed s’étend autour d’eux. C’est pourquoi demander un éditeur fait remonter des sources et des sujets liés, pas seulement cet éditeur, la même logique que le bouton Follow. La plupart des cartes fonctionnent ainsi, en s’étendant autour de vos sujets plutôt qu’en reprenant les mots exacts que vous avez tapés.
• Mode B : fan-out par query intent (la minorité). Pour une fraction des cartes, le prompt est décomposé en query intents explicites, des requêtes de retrieval en langage naturel qui récupèrent l’article. C’est le mécanisme de « fan-out » GEO, et c’est l’objet de la section 5.

Un comportement à souligner : dans nos données de suivi, Google met ces cartes en avant avec prudence, en moyenne moins que les autres pipelines, et il les retire plus souvent que n’importe quel autre, cohérent avec un retrieval qui matche parfois de façon approximative (on verra un faux positif concret en section 5). C’est, par conception, un pipeline ciblé, pas un pipeline de distribution de masse : ses cartes ne montrent quasiment aucune croissance dans le temps, la plus faible de tous les pipelines. Il sert ce qui a été demandé, à l’utilisateur qui l’a demandé. Il ne fait pas boule de neige.

5) Query intent : le « fan-out » GEO à l’intérieur de Discover

C’est le mécanisme le plus intéressant. Pour une partie des cartes, le prompt est décomposé en un query intent précis qui a matché l’article, le prompt transformé en requêtes de retrieval spécifiques, en langage naturel. C’est l’analogue fonctionnel du fan-out décrit pour le Generative Engine Optimization : un prompt unique est décomposé en sous-requêtes qui récupèrent du contenu par pertinence sémantique, sans prérequis de popularité.

La décomposition est visible. Un prompt sur le SEO devient un jeu de requêtes informationnelles :

Et ces query intents récupèrent ensuite de vrais articles. Voici des paires query intent → URL anonymisées que nous avons observées (les formulations sont les query intents internes exacts) :

Notre analyseur regroupe ces query intents en clusters :

Clusters de query intents observés dans le pipeline : « learning Google algorithms », « AI content machine learning SEO », « buying Japanese property guide », « healthy cooking techniques », « anime recommendations 2026 »…

Les mêmes clusters, avec le nombre d’articles par intent.

Le détail d’un cluster montre à la fois la force et la limite du fan-out :

Le cluster « buying Japanese property guide » : japantoday.com (acheter un logement au Japon) et maigomika.com (Japon rural) sont des matchs de niche parfaits, mais rockpapershotgun.com (emplacements de maisons dans le jeu Forza Horizon 6) est un faux positif, un article de jeu vidéo attrapé par recoupement de mots de surface. Ce type de match approximatif explique pourquoi Google classe ce pipeline avec autant de prudence (section 4).

Pourquoi c’est important pour le SEO : le query intent révèle le vocabulaire exact que Google utilise pour mapper un prompt vers votre contenu. Ce sont des requêtes informationnelles en langage naturel, pas des mots-clés bruts. Aligner titres, H1 et introductions sur ces formulations est l’équivalent, côté Discover, de l’optimisation pour le fan-out IA.

6) Sites de niche et petits créateurs : le contournement de la popularité

Les pipelines Discover classiques re-servent surtout du contenu déjà populaire, des articles qui ont déjà largement circulé et généré de l’engagement. « Tailor Your Feed » fonctionne autrement : les cartes que nous observons montrent un retrieval qui va chercher du contenu pertinent sémantiquement indépendamment du fait qu’il ait déjà circulé dans Discover ou non.

Les données 1492.vision le confirment. Sur historicalnaturallanguagetuningcontent.f, une majorité des cartes pointent vers des articles sans distribution Discover antérieure détectable dans notre base, du contenu qui n’avait jamais (ou quasiment jamais) été servi dans le feed auparavant. C’est, de loin, la part la plus élevée de tous les pipelines : les pipelines de news classiques montrent le profil inverse, où presque chaque carte a un long historique de diffusion. Une minorité des cartes du pipeline fait exception, des articles grand public (une dépêche Reuters, par exemple) déjà largement diffusés et simplement re-surfacés ici.

L’illustration la plus claire est un prompt de recettes. Demander des recettes vegan a fait remonter, non pas les grands éditeurs culinaires, mais de petits créateurs indépendants :

« Show me content from recipes vegan » → l’assistant propose des dîners de semaine végétaux, des ragoûts vegan, du tofu riche en protéines, de la pâtisserie vegan… puis « Update your feed ».

Le résultat : une recette « Sweet Potato Tacos » d’une créatrice indépendante, et « 72 Vegan BBQ Recipes » d’un petit blog vegan, chacune labellisée « You asked to see », avec un widget de notation (« How would you rate this suggestion? »).

Sur l’ensemble de notre suivi, le même schéma se répète : un blog de jardinage de niche (buzzyseeds.com) pour un prompt sur le semis ; Mississippi Today pour un prompt « sites de niche » (avec VentureBeat remonté sur le même prompt, à titre d’illustration du comportement du retrieval) ; un post LinkedIn pour un prompt créateur ; des blogs de niche sur l’immobilier japonais (japantoday.com, maigomika.com) pour un prompt immobilier. La plupart ne sont pas des gagnants habituels à fort volume de Discover.

Le point à retenir, formulé avec soin : la fonctionnalité fait remonter des articles qui n’avaient quasiment jamais circulé dans Discover auparavant. Le retrieval semble piloté par la pertinence vis-à-vis du prompt, pas par la popularité préalable : ce qui fonctionne comme un filtre de popularité dans les pipelines classiques est, ici, contourné.

7) Ce que ça change pour les éditeurs

C’est la partie qui compte le plus pour l’avenir, et c’est un vrai changement dans la façon de gagner en visibilité sur Discover.

Le pouvoir de sélection passe à l’utilisateur. Dans le feed classique, Google décide de ce que vous voyez à partir de signaux inférés. Ici, c’est l’utilisateur qui écrit le prompt (« montre-moi plus de X », « moins de Y »), et Google le transforme en entités, intérêts et query intents qui pilotent le retrieval. La demande devient explicite.

Conséquence : les sites de niche peuvent émerger sans historique Discover. Parce que le retrieval semble aller chercher la pertinence plutôt que la popularité préalable, un petit site peut être servi dès qu’un utilisateur demande son sujet, même s’il n’avait jamais vraiment circulé dans Discover auparavant (section 6). C’est nouveau.

C’est une troisième voie de visibilité. Jusqu’ici, un site de niche ne perçait dans Discover que de deux façons : par une affinité implicite forte (Google infère, à partir d’un engagement répété, que vous adorez un sujet, et un pipeline de re-surface continue de vous servir ce site de niche), ou par un follow explicite. « Tailor Your Feed » ajoute une troisième voie, initiée par l’utilisateur, qui ne dépend ni de l’un ni de l’autre.

Les leviers concrets pour les éditeurs :

• Optimiser pour les entités/sujets (le Mode A dominant). Être sans ambiguïté au sujet de ce que les utilisateurs vont nommer. Un focus thématique clair → une association d’entités plus nette → vous êtes dans l’ensemble d’expansion quand quelqu’un demande votre sujet.
• Optimiser pour le vocabulaire des query intents (le Mode B, fan-out). Formuler titres, H1 et introductions pour matcher les requêtes informationnelles en langage naturel en lesquelles un prompt se décompose (le pendant Discover du GEO). La section 5 montre les formulations exactes utilisées par Google.

Ce que ce n’est pas. Les éditeurs doivent être lucides :

• Pas un canal de masse. Le pipeline ne montre quasiment aucune croissance, et Google met ses cartes en avant avec prudence. Il sert l’utilisateur qui a demandé ; il ne diffuse pas largement.
• Pas déclenchable par l’éditeur. Seul l’utilisateur peut l’activer. Vous pouvez être prêt pour le retrieval, mais vous ne pouvez pas l’activer pour votre propre site.
• Limité géographiquement et en adoption. C’est EN-only (Search Labs, US ; ≈ 0 % dans les feeds français), et l’adoption est encore timide ; la surface My Activity était vide dans nos tests. L’impact futur dépend (a) d’un déploiement général et (b) du fait que les utilisateurs adoptent réellement le réglage par prompt à grande échelle.

La lecture stratégique : si « Add topics to your feed » sort de Search Labs et que les utilisateurs l’adoptent, le retrieval piloté par la demande et indifférent à la popularité sur lequel il repose est structurellement favorable aux sites petits, focalisés et bien décrits, ceux que les pipelines classiques, dominés par la popularité, récompensent rarement.

Et ensuite ?

Un instantané, pas un point final. Ce que nous surveillons :

• Le déploiement français (et UE). Aujourd’hui la fonctionnalité est EN-only. Selon son indépendance vis-à-vis des features AIO¹¹, AI Mode¹², cette fonctionnalité peut arriver plus ou moins rapidement en France.
• L’adoption. Un mécanisme puissant sans utilisateurs ne change rien. La surface My Activity vide suggère que le réglage par prompt reste un comportement de niche. L’adoption de masse est la variable qui décide si cela compte pour les éditeurs.
• Le couple current / historical. naturallanguagetuningcontent.f (en direct) et historicalnaturallanguagetuningcontent.f (persistant) suggèrent que le réglage est censé durer dans le temps, une instruction permanente, pas un coup unique.
• La convergence avec le retrieval génératif. Un pipeline naissant generativeretrieval.f, repéré récemment dans nos données de suivi, laisse penser que le retrieval piloté par LLM dépasse cette seule fonctionnalité (à confirmer).

La vue d’ensemble : Discover passe d’une personnalisation observée (Google infère) vers une personnalisation déclarée (vous lui dites), et le retrieval qui sert l’intention déclarée ne se verrouille pas sur la popularité. C’est l’ouverture structurelle pour les éditeurs de niche, si, et seulement si, la fonctionnalité se déploie largement et que les utilisateurs l’adoptent.

Suivi terrain : app Google, comptes Search Labs (US/anglais), décembre 2025 – juin 2026. Comportement du pipeline dérivé d’une observation fine du feed Discover via les données de suivi 1492.vision. « Distribution » désigne ici le fait qu’un article ait déjà circulé dans Discover, tel qu’observé dans notre base de suivi, pas des chiffres d’audience privés. Les mécanismes internes sont notre interprétation des données observées et de la recherche publique ; les dates inférées sont signalées comme approximatives.

Damien Andell & Sylvain Deauré, 1492.vision, juin 2026.

1. Programme bêta de Google qui permet de tester des fonctionnalités expérimentales dans Search et Discover, avant un éventuel déploiement plus large.
   ︎
2. Dans Discover, un pipeline est un circuit de sélection qui choisit et sert les cartes. Chaque carte peut être rattachée à l’identifiant du pipeline qui l’a produite, c’est ce que nous exploitons dans nos données 1492.vision.
   ︎
3. Large Language Model : modèle de langage de grande taille. Nous le supposons ici, sans preuve directe du modèle utilisé, à partir du comportement conversationnel et des réponses structurées observées.
   ︎
4. Le suffixe .f dans des identifiants comme historicalnaturallanguagetuningcontent.f est un marqueur interne que nous observons dans les métadonnées des cartes Discover ; il permet de distinguer les circuits de sélection.
   ︎
5. Au sens du Knowledge Graph de Google : Entité nommée ; personne, sujet, organisation ou concept identifié et lié à d’autres, distinct du sens courant du mot « entité » (entreprise, structure juridique).
   ︎
6. Mécanisme par lequel un prompt unique est décomposé en plusieurs sous-requêtes de retrieval, chacune visant un angle différent du sujet.
   ︎
7. Requête informationnelle en langage naturel, dérivée du prompt utilisateur, qui a servi à récupérer un article précis. Observable dans nos données comme métadonnée attachée à certaines cartes du pipeline.
   ︎
8. Generative Engine Optimization : discipline d’optimisation visant à rendre un contenu visible et cité dans les réponses des moteurs génératifs (AI Overviews, ChatGPT, etc.), notamment via le fan-out de requêtes.
   ︎
9. Étape par laquelle Google récupère et sélectionne les contenus à afficher dans le feed, à partir de signaux d’intérêt, d’entités ou de requêtes.
   ︎
10. Dans cet article, le fait qu’un article ait déjà circulé dans Discover, tel qu’observé dans notre base de suivi 1492.vision, pas un chiffre d’audience ni une métrique Search Console.
    ︎
11. AI Overviews : réponses génératives affichées en tête de certains résultats Google Search.
    ︎
12. AI Mode : interface conversationnelle de Google Search, distincte des AI Overviews.
    ︎

L’article "« Tailor Your Feed » : le fan-out Discover qui fait émerger les sites de niche" a été publié sur le site Abondance.

L’article "Goossips SEO : Fichier LLMs.txt" a été publié sur le site Abondance.

Pourquoi gérer un blog SEO est une charge sous-estimée

Derrière l'idée de « tenir un blog », il y a en réalité une multitude de tâches qui n'ont rien d'anodines : définir les thématiques pertinentes pour son secteur, identifier les mots-clés sur lesquels se positionner, évaluer le volume et la concurrence, rédiger un brief, produire un contenu suffisamment long et structuré, l'optimiser sur le plan sémantique, créer des liens internes cohérents, sélectionner ou générer des visuels, puis programmer et publier. Le même rituel recommence toutes les semaines ou tous les mois, selon la cadence visée.

Pour une PME ou un e-commerçant sans équipe SEO intégrée, cette charge peut facilement représenter plusieurs heures par article, et plusieurs abonnements à des outils distincts : un pour la recherche de mots-clés, un pour l'audit sémantique, un pour la rédaction assistée, un pour le suivi des positions. C'est aussi un sujet d'expertise qui ne s'improvise pas. L’issue est malheureusement souvent la même : beaucoup de blogs démarrent avec enthousiasme, mais peu parviennent à tenir dans la durée.

Qu'est-ce qu'un agent IA de blog et pourquoi c’est différent de ChatGPT ?

Levons d’abord une confusion particulièrement fréquente. Un outil comme ChatGPT est tout à fait capable de produire un texte sur n'importe quel sujet, raisonnablement bien rédigé, à condition de lui fournir un brief détaillé. Mais ce même ChatGPT n’est pas en mesure de chercher par lui-même ce que font vos concurrents sur Google, ne construit pas de stratégie de mots-clés à partir de vos données réelles, ne programme pas un calendrier éditorial et ne publie pas l'article sur votre CMS.

Un agent IA spécialisé comme Alya de Sedestral fonctionne différemment. Ce dernier est conçu pour enchaîner des tâches de façon autonome. Là où ChatGPT est une intelligence artificielle généraliste, Sedestral orchestre des agents SEO autonomes dédiés à une seule mission : le référencement naturel. Les agents chaînent automatiquement l'analyse concurrentielle, l'idéation, la rédaction et la publication en workflows complets. Non seulement, chaque article produit est rédigé dans les règles de l’art, mais il est aussi calibré pour se positionner.

Le principe de spécialisation est un point fondamental. Alya est uniquement dédié au blog SEO. Elle n'est pas distraite par d'autres cas d'usage, n'a pas besoin qu'on lui explique ce qu'est une balise titre ou une intention de recherche. Son analyse des SERPs est systématique et son output est directement connecté à votre CMS. C'est précisément ce qui distingue un agent d'un assistant généraliste.

Les 6 étapes du processus de l’agent Alya

L’agent IA Alya rend votre blog 100 % autonome. L’agent IA spécialisé élabore la stratégie, planifie, rédige et publie. Mais, pas de panique, vous gardez le contrôle. Voici comment le processus se déroule concrètement.

1. Vous décrivez votre activité

Tout commence par vous. Vous décrivez votre métier, vos produits et vos clients à Alya. Cette dernière s'en sert alors pour comprendre votre marché et ne produire que du contenu pertinent pour votre audience. C'est cette première étape qui ancre toute la production dans votre réalité sectorielle, plutôt que dans un contenu générique.

2. Alya calcule votre stratégie de mots-clés

Alya analyse ensuite votre site, vos concurrents et les recherches de vos clients potentiels pour identifier tous les mots-clés sur lesquels vous devez vous positionner. En somme, elle ne travaille pas à l'aveugle, mais s'appuie sur ce que cherchent réellement vos clients et sur ce quoi vos concurrents ont déjà réussi à se positionner.

3. Vous validez la stratégie

Alya vous présente les mots-clés et sujets qu'elle recommande, selon les informations qu’elle est parvenue à collecter et analyser. Vous validez, ajustez ou retirez ce qui ne vous convient pas avant qu'elle ne commence à rédiger. C'est le principal point de contrôle humain du processus. Rien n'est lancé sans votre accord !

4. Alya programme le calendrier éditorial

Une fois la stratégie validée par vos soins, Alya planifie les publications dans un calendrier éditorial cohérent, à la fréquence que vous choisissez. La régularité, souvent le premier obstacle rencontré par les équipes qui gèrent leur blog « quand elles ont du temps », est ainsi automatisée.

5. Alya rédige les contenus

C'est l'étape la plus différenciante sur le plan technique. Contrairement à un simple générateur de texte, Alya visite réellement les pages en tête de la SERP pour le mot-clé ciblé. Elle en extrait les termes les plus fréquents, analyse leur positionnement dans la page (début, milieu ou fin), et identifie les balises HTML concernées (H1, balise title, paragraphes, etc.). L'objectif est de construire un brief basé sur des probabilités mathématiques, en réinjectant ces fréquences d'apparition pour que Google puisse identifier que l'article couvre la même intention de recherche que les pages déjà positionnées. Alya ajoute également un sommaire, des images et une FAQ. Il est possible de relire et modifier avant de valider.

6. Alya publie sur votre site

Une fois l'article prêt, Alya le publie directement sur votre blog en un clic, sans aucune intervention technique de votre part. La connexion est native avec WordPress, PrestaShop, Shopify, Wix et Webflow.

Ce que l'utilisateur garde sous contrôle

La crainte souvent exprimée face à l'automatisation éditoriale est celle de perdre la main : publier des contenus qui ne ressemblent pas à sa marque, sur des sujets qu'on n'aurait pas choisis, avec un ton inadapté à son audience.

Le workflow d'Alya est spécifiquement conçu pour éviter cet écueil. La validation de la stratégie de mots-clés (étape 3) vous permet d'écarter les sujets qui ne correspondent pas à votre positionnement. Avant la rédaction, vous pouvez définir vos consignes ainsi que le ton et le style souhaités. Une fois l'article généré, vous pouvez le personnaliser entièrement dans l'éditeur avant de le publier. La publication finale reste donc soumise à votre relecture. Alya automatise sans déposséder : c'est elle qui effectue le travail de fond et c'est vous qui décidez de ce qui est publié.

Ce que ça change concrètement

Les résultats les plus probants viennent des utilisateurs eux-mêmes. Par exemple, Bet-Thermique, un bureau d'études thermiques spécialisé dans les études réglementaires RE2020, avait un site avec peu de visiteurs et un contenu insuffisant.

Après avoir adopté Sedestral, les articles ont enregistré presque 3 000 vues dès le premier mois, contre 500 vues pour l'ensemble des articles présents sur le site depuis plusieurs années. Sur six mois, Bet-Thermique a enregistré une augmentation de +483 % des clics et +90 % de mots-clés référencés.

Ce type de progression illustre ce que produit une publication régulière et calibrée sur les bons mots-clés : une présence accrue dans les SERP, un trafic qualifié en croissance, et une surface sémantique qui s'élargit progressivement. Des résultats qu'il aurait fallu plusieurs mois de travail manuel pour atteindre.

Par ailleurs, Sedestral propose une tarification transparente et flexible qui permet à toutes les entreprises, quelle que soit leur taille, d'accéder à ces outils, ce qui représente une alternative réelle à la combinaison de plusieurs abonnements distincts ou au recours à une agence.

Les limites à garder en tête

Honnêteté éditoriale oblige, il convient de préciser qu’un agent IA de contenu n'est pas adapté à tous les formats ni à tous les cas d'usage.

Les contenus qui nécessitent une expertise métier très pointue et non documentée sur le web restent difficiles à automatiser sans un apport humain significatif. Un article technique rédigé par un spécialiste qui partage une connaissance exclusive ou issue d'une expérience terrain n'a, par définition, pas d'équivalent dans les SERPs.

Les prises de position éditoriales fortes, les tribunes, les contenus d'opinion tranchés et les analyses critiques supposent une voix singulière que l'automatisation ne peut pas restituer. Ce type de contenu est aussi souvent ce qui construit l'autorité perçue d'un site sur son secteur.

Enfin, les secteurs très réglementés (médical, juridique, financier) demandent également une validation humaine rigoureuse avant toute publication, quel que soit l'outil utilisé.

Dans tous les autres cas, et ils sont nombreux, un agent IA comme Alya remplace avantageusement des heures de travail répétitif par un processus piloté, vérifiable et régulier !

L’article "Comment un agent IA gère votre blog de A à Z : le cas Alya de Sedestral" a été publié sur le site Abondance.

Ce qu'il faut retenir :

• Google publie un nouveau document officiel consacré à l'évaluation des outils et conseils SEO tiers, en insistant sur le fait qu'il n'en cautionne aucun.
• Les outils tiers n'ont pas accès aux données de ranking internes de Google et ne peuvent garantir aucun résultat.
• Google met en garde contre les prestataires qui se réclament d'une approbation officielle de Google Search.
• Le document mis à jour intègre pour la première fois des conseils sur l'optimisation pour les expériences IA (AEO/GEO), avec un renvoi vers la documentation officielle sur le sujet.

Un nouveau document pour encadrer l'usage des outils tiers

Google a publié une nouvelle page d'aide intitulée Google Search's guidance on using third-party SEO tools, services, and advice. Ce document liste les grandes catégories d'outils et de services concernés :

• Génération de sitemaps,
• Directives d'indexation,
• Production de contenu "optimisé SEO",
• Audits de contenu existant,
• Et outils promettant des améliorations dans les formats IA (désignés sous les termes AEO ou GEO).

Le message central est clair : Google ne valide aucun outil tiers. La firme de Mountain View rappelle explicitement que "les outils tiers n'ont pas accès à nos données de ranking internes" et qu'ils "ne peuvent garantir aucune performance". Toute affirmation contraire doit être considérée comme un signal d'alarme.

Le seul outil recommandé par Google reste Google Search Console, présenté comme la source d'information directe et fiable sur les performances d'un site dans la recherche.

Des mises à jour dans le guide "Avez-vous besoin d'un SEO ?"

L'ancien document d'aide destiné aux propriétaires de sites qui envisagent de recruter un prestataire SEO a lui aussi été revu.

Plusieurs ajouts notables :

Google précise désormais que si un prestataire utilise des outils tiers, ceux-ci ne bénéficient d'aucune forme d'approbation de la part de Google Search. Le document insiste sur la vigilance face aux outils qui se prétendraient "acceptés" ou "approuvés" par Google.

Sur la question des audits SEO, Google recommande de ne donner qu'un accès en lecture à la Search Console dans un premier temps, jamais un accès en écriture. Un bon audit doit fournir des estimations réalistes d'amélioration et une évaluation de la charge de travail impliquée. Toute garantie de positionnement en première position doit, selon Google, conduire à chercher un autre prestataire.

Enfin, Google invite les propriétaires de sites à vérifier systématiquement les recommandations de leurs prestataires en les confrontant à la documentation officielle, et à se poser trois questions concrètes : les recommandations s'appuient-elles sur des sources Google officielles ? Les conseils sur l'AEO/GEO sont-ils alignés avec les guidelines officiels de Google sur l'IA générative ? Les outils utilisés sont-ils cohérents avec les recommandations de Google ?

L'optimisation pour l'IA générative intégrée à la documentation

C'est l'un des ajouts les plus significatifs de cette mise à jour : Google intègre pour la première fois des références à l'optimisation pour les expériences IA génératives (AEO, GEO) dans sa documentation destinée aux propriétaires de sites. Le document renvoie vers une page d'aide dédiée à ce sujet, publiée récemment. C'est un signal que Google considère désormais ce segment comme suffisamment mature ; et suffisamment porteur de risques de désinformation, pour mériter un cadrage officiel.

L’article "Google publie un guide officiel sur les outils SEO tiers et met à jour sa documentation" a été publié sur le site Abondance.

En septembre 2025, nous avions expliqué comment suivre Abondance sur Discover via le bouton « Suivre sur Google » et la page profile.google.com. En mai 2026, nous avions publié l’analyse des 54 éditeurs américains disposant de fonctionnalités enrichies (bannière, liens configurables, publications épinglées, ordre des onglets personnalisable) sans communication officielle de Google à l’époque.

L’annonce du 4 juin valide cette lecture : il s’agissait bien d’un programme pilote, pas d’un gadget. Google parle maintenant de « Search profiles », d’un espace dédié pour mettre en avant articles, vidéos et posts sociaux, ainsi que d’un lien explicite avec le knowledge panel. Les éditeurs éligibles peuvent réclamer un profil auto-généré ou en créer un ; le suivi depuis le profil alimente Discover.

Chez 1492.vision, notre monitoring couvre près de 47 000 profils Discover dans 7 langues. La cohorte des 54 domaines US analysée en détail était avant l'annonce officielle le seul groupe avec accès persistant aux fonctions enrichies que nous avions cartographiées, mais l’infrastructure sous-jacente existe déjà pour des milliers d’éditeurs, y compris francophones, sous forme de profils auto-générés.

Les chiffres qui structurent l’accès

Éligibilité à la réclamation (au moins un compte sur une plateforme majeure) :

Autres contraintes documentées : résidence / disponibilité États-Unis uniquement pour l’instant ; âge minimum 18 ans ; un profil Search par compte Google (une autre identité = un autre compte Google).

Ce que permet un profil réclamé :

• Bannière (cover) : format carré en affichage, résolution recommandée 1080 × 1350 px minimum ;
• Jusqu’à 8 liens web (sections, live, météo, app, don…) ;
• Jusqu’à 8 publications épinglées issues des plateformes liées ;
• Handle profile.google.com/@… calqué sur le compte social le plus suivi parmi ceux connectés ;
• Insights (bêta) : clics, impressions, top contenus, pays : alimentés par une propriété Search Console générée pour le profil.

Rappel de notre analyse des 54 (détail dans l’article Abondance) : 41 bannières en ligne sur 54, 31 éditeurs avec au moins un lien configuré (65 liens au total), 13 avec un post épinglé actif, et seulement 3 liens instrumentés en UTM. Le paradoxe tient : la fonctionnalité est là, l’usage reste inégal, surtout chez les plus gros médias nationaux.

Éditable tout de suite vs validé par Google

Google distingue deux régimes :

• Immédiat : ordre des plateformes sociales, image de couverture, épinglage, liens web, retrait d’un compte erroné ;
• Soumis à validation : nom, bio, ajout d’une nouvelle plateforme non détectée automatiquement.

Conséquence pratique : si un réseau social n’apparaît pas sur votre profil auto-généré, la réclamation ouvre la possibilité de demander l’ajout d’un compte manquant. Le handle, lui, suit la logique de la plus grosse audience sociale liée, pas forcément votre préférence éditoriale.

Entités et Knowledge Graph

Sous le capot, le profil reste une surface Discover adossée au Knowledge Graph : réclamation possible depuis le knowledge panel (« View Search Profile »), enrichissement réciproque (avatar, contenus récents, lien direct). Pour Google, c’est un verrou de plus sur l’identité éditoriale (auteurs, marques, E-E-A-T) dans un écosystème où l’agrégation multi-plateformes devient critique. Le rôle des entités et du Knowledge Graph comme ossature des systèmes Google est confirmé, si besoin était.

« Pas directement » : ce que dit Google et ce qu’il faut en déduire

La FAQ officielle est explicite : « La création d’un Search profile n’affecte pas directement le classement de votre contenu sur Google Search. En revanche, si quelqu’un vous suit depuis votre profil, il peut voir davantage de votre contenu sur Discover. » 
Traduction opérationnelle : le Follow est un abonnement Discover (effet direct sur le flux pour les abonnés, comme les tests le démontraient) ; le ranking Search classique n’est pas promis, et le « pas directement » laisse la porte aux effets indirects (signaux d’engagement, fraîcheur d’audience), que ce soit sur Search ou sur Discover.
On se souvient de Navboost dans le contexte du Search, qui (indirectement) récompense les contenus les plus cliqués sur la serp. Des mécanismes similaires, quoique plus complexes et nuancés, sont à l’œuvre sur Discover.

Vers un Publisher Center 2.0 ? Intention Google, impact éditeurs

Nous l’avions évoqué dès notre première analyse Substack : cette page pourrait devenir un hub éditeur dans l’écosystème Google, non pas pour héberger du contenu (tout est tiré des plateformes liées), mais pour fédérer l’audience, redistribuer des clics et compenser une partie de la pression des résumés IA et de la personnalisation agressive sur Discover.

Rétention. Le Follow formalise une relation directe éditeur lecteur dans Google, comparable à une newsletter Discover : moins de dépendance au hasard algorithmique du flux.

Personnalisation. Plus de sources suivies = fil plus stable pour ces éditeurs ; Google consolide des signaux d’affinité explicites (opt-in) en plus des signaux implicites. Cela va d’ailleurs de pair avec les nouvelles fonctions de Discover « Tailor your feed », qui ouvrent très nettement la porte à une personnalisation explicite des flux.

Analytics. La section Insights, même en bêta et soumise aux seuils, ouvre une brèche : visibilité sur performances Search et Discover au niveau du profil, avec pont Search Console.

Presse locale. La composition du pilote (environ la moitié des 54 = TV locales + presse régionale) colle aux discours publics de Google sur le journalisme de proximité : le produit n’est pas pensé uniquement pour les mastodontes nationaux.

Publisher Center ? Pas de rebranding officiel, mais la fonction est proche : identité, liens, mise en avant, mesure, sans repasser par une interface obsolète. L’officialisation du 4 juin transforme une observation de terrain en feuille de route produit.

États-Unis seulement, mais préparez-vous dès maintenant

Search profiles réclamables : US uniquement. Aucun profil enrichi hors marché anglophone US dans notre monitoring à ce jour, conforme à l'annonce Google, mais on surveille. En revanche, votre profil auto-généré existe probablement déjà si Google vous a identifié comme entité : logo, bio (souvent Wikipedia), réseaux issus du graphe.

De nouveaux éditeurs US ont déjà pu créer leur profile, par exemple "Inspired taste":

Checklist avant l’ouverture FR :

1. Vérifier votre page profile.google.com (ou demander l’URL à @1492_vision si elle n’est pas encore visible dans Discover).
2. Auditer la cohérence des comptes sociaux déclarés.
3. Préparer une bannière carrée pro (la barre visuelle du pilote est haute).
4. Définir 3 à 5 liens prioritaires + convention UTM
5. Rédiger une bio « About » : sur les profils réclamés du pilote, 38 des 54 l’avaient réécrite : c’est votre pitch sur une page Google.

Quand l’éligibilité s’étendra, les éditeurs US auront déjà pris l’habitude ; les retardataires repartiront avec un désavantage d’usage, pas seulement d’accès.

Conclusion

Google officialise ce que nous monitorions depuis août 2025 : des profils éditeurs, un Follow Discover, et, pour une poignée d’élus US, une couche enrichie qui ressemble à un mini-site dans le flux. L’annonce du 4 juin ne change pas la donne pour les éditeurs francophones aujourd’hui, mais elle confirme la direction : entités consolidées, audience capturable, personnalisation explicite, analytics en renfort.

Nous continuons de suivre l’évolution des 47 000 profils monitorés.
L’analyse détaillée de la cohorte des 54 reste sur Abondance ; la version longue avec visuels est sur 1492.vision/research/discover-publisher-profiles-fr.

Sylvain Deauré & Damien Andell - 1492.vision

Comment s’abonner à Abondance sur Discover ?

1. Rendez-vous sur le profil Google d’Abondance.
2. Cliquez sur « + Suivre sur Google », sous le logo.
3. C’est tout : vos articles Abondance remontent plus souvent dans votre flux Discover personnel.

(Voir le guide complet.)

L’article "Vers un Publisher Center 2.0 ? Google officialise les profils étendus" a été publié sur le site Abondance.