En collaboration avec Botanik

Une question qui présuppose deux mondes séparés

Poser la question « SEO ou GEO » revient à accepter une prémisse implicite : il existerait deux disciplines distinctes, avec leurs propres règles, leurs propres métriques et leurs propres experts.

• D'un côté, l'optimisation pour Google et les moteurs traditionnels, avec son objectif de clic.
• De l'autre, l'optimisation pour les moteurs génératifs comme ChatGPT ou Perplexity, avec son objectif de citation.

Cette distinction avait du sens il y a encore un an, quand AI Overviews s'affichait comme un module à part dans une page de résultats par ailleurs classique, et que les chatbots IA fonctionnaient en dehors de l'écosystème Google.

Mais cette frontière est en train de s'effacer à toute vitesse, et pas seulement dans le discours marketing des professionnels. Lors de Google I/O 2026, le vocabulaire employé par Google pour décrire son propre moteur a changé de nature. Liz Reid, VP Search chez Google, a décrit Google Search non plus comme un index du web, mais comme une couche cognitive et computationnelle.

Pour le dire autrement, le moteur ne renvoie plus simplement des résultats, mais absorbe la question, la décompose en sous-requêtes traitées en parallèle (c’est le principe du query fan-out), et produit une réponse composite qui peut prendre la forme d'un texte, d'un tableau, d'une image interactive ou d'une mini-application générée à la volée.

Dans ce contexte, demander si l'on fait du SEO ou du GEO sur une page donnée devient une question presque anachronique, puisque la page de résultats elle-même n'est plus une liste, mais une interface qui mélange en permanence liens organiques, synthèses génératives et modules agentiques.

Une convergence technique déjà révélatrice

Le signe le plus concret de cette fusion se trouve dans les critères que les deux moteurs utilisent désormais pour juger un contenu.

Le SEO et le GEO s'appuient sur les mêmes fondamentaux d'expérience, d'expertise, d'autorité et de confiance (E-E-A-T) pour évaluer la crédibilité d'une page, que l'évaluateur soit un robot d'indexation classique ou un modèle de langage. Un contenu générique, pénalisé par Google depuis des années, est tout simplement ignoré par les IA génératives, pour des raisons différentes mais avec le même résultat. Les données structurées au format Schema.org aident autant Googlebot à comprendre une page que les LLM à en extraire les bons éléments. Et les backlinks de qualité renforcent à la fois l'autorité perçue par Google et l'autorité d'entité reconnue par les IA.

Cette convergence des critères ni un hasard ni une coïncidence. Elle traduit une dynamique de fond : les deux types de moteurs cherchent en réalité à résoudre le même problème, celui d'identifier des sources fiables et de bien comprendre de quoi parle un contenu, qui il représente, et dans quel contexte il s'inscrit.

Une fois qu'on accepte cette lecture, la question « SEO ou GEO » perd peu à peu de sa pertinence. La vraie compétence à développer n'est ni purement technique au sens du SEO classique, ni purement éditoriale au sens du GEO, mais une maîtrise des entités et des données structurées qui fonctionne comme un langage commun aux deux systèmes.

C'est précisément le terrain sur lequel travaillent des acteurs spécialisés comme l’agence SEO Botanik, dont l'approche consiste justement à structurer l'information à la source plutôt qu'à dupliquer les efforts entre deux stratégies parallèles. Botanik illustre parfaitement une tendance qui s'annonce comme la norme à venir : ne plus distinguer deux chantiers, mais en piloter un seul, pensé pour être lu aussi bien par un robot d'indexation que par un modèle génératif.

Le faux clivage des métriques

L'un des arguments les plus souvent avancés pour justifier la séparation entre SEO et GEO concerne les métriques. Le SEO se mesurerait en position Google, en trafic organique et en taux de clic, alors que le GEO se mesurerait en taux de citation dans les réponses des IA, en « share of model » et en « sentiment de marque ». Cette distinction semble solide aujourd'hui, mais elle repose sur une hypothèse fragile : celle que le clic restera la monnaie d'échange dominante de l'écosystème Google.

Or les annonces faites durant le Google I/O 2026 vont précisément dans la direction inverse. Les agents d'information autonomes évoqués lors de la conférence tournent désormais en arrière-plan sans action explicite de l'internaute, la recherche prend un tour de plus en plus agentique, et certains modules génèrent des interfaces ou des actions directement dans la page de résultats.

Dans ce contexte, le clic lui-même devient une métrique de second ordre. Ce qui compte de plus en plus, c'est d'être identifié comme la source de confiance que le système, quel qu'il soit, choisit de mobiliser pour répondre à une intention. Cette logique d'intention plutôt que de mot-clé est déjà au cœur du fonctionnement de l'AI Mode de Google, qui découpe une requête en plusieurs sous-thèmes pour explorer le web de façon plus approfondie qu'une recherche classique. Le SEO traditionnel, centré sur le positionnement d'un mot-clé précis, et le GEO, qui se concentre sur la formulation de réponses citables, finissent par converger vers un même objectif : être reconnu comme une référence fiable sur un sujet, indépendamment du canal par lequel cette reconnaissance se traduit.

Pourquoi cette convergence ne sonne pas la fin du travail éditorial

Il serait tentant de conclure que, puisque les deux disciplines fusionnent, il suffira bientôt de produire un contenu « neutre » qui plaira automatiquement à tous les systèmes. C'est sans doute l'erreur fondamentale à ne pas connaître. La convergence technique entre SEO et GEO ne signifie pas un nivellement vers le bas des exigences éditoriales, elle invite plutôt à penser différemment : en se rapprochant, les deux systèmes sont simultanément plus exigeants sur les mêmes critères. Un contenu vague, rédigé pour remplir un calendrier sans répondre à une vraie question, aura de moins en moins sa place, que ce soit dans les résultats classiques ou dans les réponses génératives. Une page claire, signée, structurée autour d'une expérience concrète et appuyée sur des preuves vérifiables a au contraire toutes les chances de résister à la fois à la baisse des clics et à l'invisibilité dans les synthèses IA.

Cela déplace le centre du débat. La question qui mérite d'être posée aujourd'hui n'est plus de savoir s’il faut faire du SEO ou du GEO, ni même vraiment comment combiner les deux, mais plutôt de se poser s’interroger: le contenu est-il construit pour être compris comme une entité claire, par n'importe quel système d'interprétation, qu'il s'agisse d'un robot d'indexation de 2024 ou d'un agent conversationnel de 2027 ?

Anticiper plutôt que choisir un camp

Dans deux ans, il est fort probable que personne ne parle plus de « stratégie GEO » comme d'un sujet isolé, de la même façon que personne ne parle plus aujourd'hui de « stratégie mobile » comme d'un chantier distinct du reste du marketing digital. Le mobile a fini par devenir une dimension transversale de toute présence en ligne, pas une discipline isolée.

Le GEO va très probablement suivre la même trajectoire. Ce n’est pas une parenthèse technologique à intégrer en plus du SEO, mais une étape de maturation qui va finir par se fondre dans une discipline unique, centrée sur la structuration de l'information et la construction d'une autorité d'entité reconnaissable par n'importe quel système de recherche, génératif ou pas.

Continuer à se demander s'il faut choisir entre SEO et GEO en 2026, c'est se poser une question qui regarde déjà vers le passé. La question utile, celle qui prépare réellement l'avenir d'une stratégie de contenu, porte sur la solidité et la clarté des fondations informationnelles que l'on construit aujourd'hui, peu importe le nom qu'on leur donnera demain.

L’article "GEO vs SEO : faut-il choisir ou combiner les deux ?" a été publié sur le site Abondance.

Le problème que l'OKF cherche à résoudre

Dans la plupart des organisations, la connaissance dont ont besoin les modèles est fragmentée entre des dizaines de systèmes incompatibles : catalogues de métadonnées avec leurs propres API, wikis internes, commentaires dans le code, documentation dans des drives partagés, et savoirs tacites dans la tête de quelques experts seniors.

Quand un agent doit répondre à une question comme "comment calculer nos utilisateurs actifs hebdomadaires depuis notre flux d'événements ?", il doit assembler la réponse depuis des plateformes mutuellement incompatibles. Chaque éditeur de catalogue réinvente les mêmes modèles de données, et la connaissance reste prisonnière de la surface qui l'a créée.

Le résultat : chaque équipe qui construit un agent résout le même problème d'assemblage de contexte depuis zéro, de manière bespoke, sans interopérabilité possible.

Ce qu'est concrètement l'OKF

L'Open Knowledge Format entend répondre à ce problème avec une approche délibérément minimaliste. Un bundle OKF est un répertoire de fichiers Markdown. Chaque fichier représente un concept : une table de base de données, une métrique métier, un runbook, une procédure, une API dépréciée. Le chemin du fichier correspond à l'identité du concept.

Chaque fichier commence par un bloc YAML avec un petit ensemble de champs structurés : type, title, description, resource, tags, timestamp. Seul le champ type est obligatoire. Tout le reste, y compris la structure du corps en Markdown, est laissé à la discrétion du producteur.

Voici à quoi ressemble un document OKF minimal, tel que fourni dans la spécification officielle de Google :

---

type: BigQuery Table

title: Orders

description: One row per completed customer order.

resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders

tags: [sales, revenue]

timestamp: 2026-05-28T14:30:00Z

---

# Schema

| Column     | Type   | Description                         |

|------------|--------|-------------------------------------|

| order_id   | STRING | Globally unique order identifier.   |

| customer_id| STRING | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

Les concepts se lient entre eux via des liens Markdown standard, transformant le répertoire en un graphe de relations. Les bundles peuvent aussi inclure des fichiers index.md pour la navigation hiérarchique, et des fichiers log.md pour l'historique chronologique des modifications.

Ce que Google insiste à souligner : pas de schéma de compression complexe, pas de nouveau runtime, pas de SDK obligatoire. Le bundle OKF est simple "du Markdown, des fichiers et du YAML frontmatter". Il peut être versionné dans Git, hébergé sur n'importe quel dépôt, rendu lisible sur GitHub, indexé par n'importe quel outil de recherche.

Les trois principes de conception

Google articule le design autour de trois axes.

1. Minimalisme : l'OKF n'impose qu'une seule chose à chaque document ; un champ type. Ce que sont les types, quels autres champs inclure, quelle structure adopter dans le corps : tout cela reste à la discrétion du producteur. La spécification définit la surface d'interopérabilité, pas le modèle de contenu.
2. Indépendance producteur/consommateur : un bundle rédigé à la main par un humain peut être utilisé par un agent IA. Un bundle généré par un pipeline d'export de métadonnées peut être parcouru dans un visualiseur. Un bundle synthétisé par un LLM peut être interrogé par un autre. Le format est le contrat ; les outils aux deux extrémités sont indépendamment interchangeables.
3. Un format, pas une plateforme : l'OKF n'est lié à aucun cloud, aucune base de données, aucun fournisseur de modèles, aucun framework d'agents. Il ne requerra jamais de compte propriétaire ni de SDK pour lire, écrire ou servir des bundles. Google publie la spécification en open source explicitement parce que la valeur d'un format de connaissance vient du nombre de parties qui l'adoptent, non de qui en est propriétaire.

La filiation avec le "LLM-Wiki pattern"

L'OKF formalise explicitement un pattern qui avait émergé dans la communauté des développeurs d'agents, théorisé notamment par Andrej Karpathy dans un gist publié sur GitHub. L'idée fondamentale est la suivante : plutôt que d'envoyer des agents chercher les mêmes documents pour les mêmes faits en boucle, on leur donne une bibliothèque Markdown partagée qui grandit en utilité au fil du temps.

Karpathy le formule ainsi : les LLM ne s'ennuient pas, n'oublient pas de mettre à jour une référence croisée, et peuvent modifier quinze fichiers en un seul passage. La bureaucratie de maintenance qui pousse les humains à abandonner leurs wikis personnels est précisément ce pour quoi les LLM sont bons.

Ce pattern apparaît sous des formes variées : des vaults Obsidian connectés à des agents de code, les conventions de fichiers AGENTS.md ou CLAUDE.md, des dépôts de index.md et log.md que les agents consultent avant tout travail réel. Chaque instance est faite sur mesure. L'OKF apporte la couche de standardisation qui permet à ces wikis de coopérer entre eux.

Ce que Google livre avec la spécification

Au-delà de la spec elle-même, Google publie plusieurs éléments concrets pour amorcer l'écosystème :

• Un agent d'enrichissement qui parcourt un dataset BigQuery, génère un document OKF pour chaque table et vue, puis effectue un second passage LLM qui enrichit chaque concept avec des citations, des schémas et des chemins de jointure.
• Un visualisateur HTML statique qui transforme n'importe quel bundle OKF en une vue graphique interactive dans un fichier HTML auto-contenu, sans backend, sans installation, sans que les données quittent la page.
• Trois bundles d'exemples prêts à parcourir, basés sur des datasets publics BigQuery (GA4 e-commerce, Stack Overflow, Bitcoin), produits par l'agent de référence et engagés dans le dépôt comme exemples vivants d'OKF conforme.

Google a également mis à jour son Knowledge Catalog pour ingérer l'OKF et le servir à ses agents, ce qui ancre le format dans un usage production réel dès son lancement.

Les implications pour le SEO et la visibilité des agents

Marie Haynes, consultante SEO reconnue, formule une observation centrale sur ce que représente ce changement de paradigme : nous passons d'un travail consistant à être trouvé par les moteurs de recherche à un travail consistant à rendre la connaissance d'une entreprise exploitable par les agents pour accomplir des tâches.

Cette évolution est profonde. Jusqu'ici, le GEO (Generative Engine Optimization) consistait à optimiser du contenu pour qu'il soit cité par les modèles génératifs dans leurs réponses. Avec l'OKF, la question est différente : comment structurer la connaissance d'une organisation pour qu'un agent puisse s'en emparer, naviguer dedans, et agir avec elle ?

Marie Haynes souligne que construire un bundle OKF de qualité pour une entreprise demandera un travail de fond : comprendre en profondeur les concepts sur lesquels une organisation a de la connaissance, documenter ses processus, cartographier les relations entre ses données. Ce n'est pas simplement convertir des pages web en Markdown. C'est construire le cerveau structuré d'une organisation.

Elle note également une opportunité commerciale émergente : la possibilité de vendre des bundles OKF de connaissance experte. Un avocat, un comptable, un consultant SEO pourrait vendre un bundle de ses processus propriétaires, que d'autres organisations pourraient intégrer directement dans leur propre système de connaissance pour le rendre accessible à leurs agents.

Premiers retours pratiques

Haynes documente ses premiers essais de création d'un bundle OKF à partir de ses propres évaluations de chutes de trafic. Elle a utilisé un outil pour extraire les concepts clés de plusieurs documents et les stocker en fichiers Markdown distincts, puis les a visualisés sous forme de graphe, où chaque noeud représente un concept et les arêtes expriment les relations entre eux. Elle a ensuite interrogé ce bundle via Gemini 2.0 Flash.

Elle précise que son test portait seulement sur trois documents d'entraînement, et que le système sera largement amélioré. Mais le principe est validé : on peut construire dès aujourd'hui une base de connaissance OKF fonctionnelle avec des outils accessibles.

Des outils de conversion de pages web en bundles OKF existent déjà, comme celui développé par Suganthan Mohanadasan. Mais Haynes insiste sur le fait que la vraie valeur réside dans la création d'un OKF sur mesure, pas dans la simple transposition mécanique de contenu existant.

Un standard ouvert pensé pour évoluer

Google présente explicitement l'OKF v0.1 comme un point de départ, non comme un standard achevé. La spécification tient en une seule page. Le format évoluera à mesure que producteurs et consommateurs émergeront, et que la communauté apprendra collectivement quelles représentations de la connaissance les agents ont réellement besoin en pratique.

La publication en open source dès le premier jour est un choix délibéré : la valeur d'un format de connaissance vient du nombre de parties qui l'adoptent. Les prochaines étapes que Google encourage : lire la spécification, écrire des producteurs pour différentes sources de données, écrire des consommateurs (visualisateurs, index de recherche, agents), tester l'implémentation de référence sur ses propres données, et contribuer au dépôt GitHub.

L’article "Open Knowledge Format : Google pose les bases d’un nouveau standard pour les agents IA" a été publié sur le site Abondance.

Deux éditeurs faussement accusés de pratiques douteuses

L'affaire part d'un problème bien concret. Pour certaines requêtes de recherche, les AI Overviews de Google avaient associé deux entreprises d'édition basées à Munich à des arnaques, des pièges à abonnement et des pratiques commerciales douteuses.

Selon le tribunal, l'IA avait mélangé des informations concernant d'autres sociétés, réellement malhonnêtes cette fois, avec celles des plaignants, et avait établi des liens qui n'apparaissaient dans aucune des sources citées.

Les deux éditeurs avaient envoyé une mise en demeure à Google, qui n'y avait pas répondu de manière satisfaisante. L'affaire a donc fini devant le tribunal régional de Munich, sous le numéro de dossier 26 O 869/26.

Pourquoi les AI Overviews ne sont pas de simples résultats de recherche

Le cœur du raisonnement du tribunal tient à une distinction technique, mais déterminante. Un moteur de recherche classique se contente de pointer vers des sites web extérieurs : il rend des contenus tiers accessibles, mais ne les réécrit pas. Les AI Overviews fonctionnent différemment puisque l'IA reformule et évalue les résultats « avec ses propres mots et selon sa propre structure », selon les termes du jugement.

Dans le cas examiné, le résumé généré par l'IA s'ouvrait par exemple sur des affirmations péremptoires du type « oui, telle entreprise est connue pour ses pratiques commerciales douteuses », avant de développer une structure construite par l'IA elle-même : un résumé, des signaux d'alerte sur l'arnaque supposée, puis des conseils aux utilisateurs.

Le tribunal a également constaté que les AI Overviews formulait des affirmations qui n'apparaissaient même pas dans les résultats de recherche sous-jacents. Aucune des sources citées n'établissait de lien entre les plaignants et les sociétés douteuses mentionnées par l'IA. Pour les juges, il s'agit là des « propres déclarations » de Google.

Pourquoi la jurisprudence existante ne protège pas Google

Google s'appuyait sur une jurisprudence établie par la Cour fédérale de justice allemande (BGH), qui accorde aux moteurs de recherche classiques et aux fonctions d'autocomplétion une responsabilité limitée. Le raisonnement de la BGH repose sur l'idée que les opérateurs de moteurs de recherche ne sont responsables qu'en tant qu'auteurs indirects, puisqu'ils se contentent de rendre trouvable un contenu produit par des tiers. Leur imposer une obligation de vérification systématique menacerait le fonctionnement même de la recherche en ligne.

Le tribunal de Munich a estimé que cette logique ne s'applique pas aux AI Overviews. Contrairement à un moteur de recherche traditionnel, l'IA génère des « déclarations indépendantes, nouvelles et substantielles » en évaluant et combinant le contenu de plusieurs sites tiers. Et seul Google est en mesure de vérifier ces déclarations, ne serait-ce qu'en comparant les sites web sources avec les affirmations qu'il en tire.

Les juges ont aussi relevé que l'AI Overview n'est « absolument pas indispensable » pour utiliser internet. Les résultats de recherche classiques permettent déjà aux utilisateurs de trier l'information ; l'AI Overview n'est qu'une fonctionnalité supplémentaire.

L'argument de la vérification par l'utilisateur rejeté par les juges

Lors de l'audience, Google a fait valoir que les utilisateurs pouvaient vérifier eux-mêmes les sources liées pour s'assurer de l'exactitude du résumé généré par l'IA. L'entreprise a également avancé que le public savait généralement que les contenus générés par IA ne devaient pas être pris pour argent comptant.

Le tribunal a balayé cet argument. La simple possibilité de réfuter une affirmation par des recherches complémentaires ne dispense pas, selon les juges, de la responsabilité liée à cette affirmation. L'AI Overview était « compréhensible en lui-même » et constituait « une déclaration autonome, dont le contenu pouvait être compris de manière indépendante, sans aucune référence à d'autres interprétations possibles ou à un contenu peu fiable ».

Les juges se sont appuyés sur des études montrant que les utilisateurs cliquent très rarement sur les sources affichées dans les AI Overviews, ce qui renforce leur raisonnement. Ils ont également établi un parallèle avec le droit de la presse, où les éditeurs sont responsables des chapeaux d'articles compréhensibles par eux-mêmes, même si le lecteur ne lit jamais l'article complet derrière.

Enfin, le tribunal a pointé un vide juridique préoccupant. Si Google n'était responsable que des violations manifestes, les victimes n'auraient aucun recours réel face aux fausses affirmations de l'IA. Les sites tiers ayant servi de sources n'avaient eux-mêmes jamais formulé les déclarations en question : impossible donc de les poursuivre, et sous l'ancien régime juridique, impossible également de poursuivre efficacement Google. Cette situation a empêché Google d'invoquer les protections accordées aux hébergeurs par le Digital Services Act, ou de se retrancher derrière la procédure classique de notification et retrait applicable aux moteurs de recherche.

Une protection de la liberté d'expression réduite pour l'IA

Le tribunal a également abordé la question de la liberté d'expression appliquée aux contenus générés par IA, avec une conclusion défavorable à Google. Selon les juges, une opinion produite par une intelligence artificielle n'est « pas l'expression d'une conviction acquise par celui qui s'exprime, mais le résultat d'un algorithme ».

Proposer un outil de recherche assisté par IA relève « avant tout d'une expression de l'activité commerciale de Google », et tout au plus « secondairement d'un intérêt à pouvoir exprimer librement une opinion ou des convictions ». Dans la balance entre les droits des plaignants et les intérêts de Google, l'entreprise a donc dû s'incliner, d'autant que les affirmations contestées reposaient sur des faits inexacts. L'IA avait associé les plaignants à des sociétés qui, selon des déclarations sous serment, n'avaient absolument aucun lien avec eux.

Google condamné sur la quasi-totalité des points

Le tribunal a tranché en faveur des plaignants sur la majorité des demandes. Il a interdit à Google de diffuser des affirmations évoquant des arnaques, des liens avec des sociétés douteuses, des pièges à abonnement, des appels téléphoniques fictifs ou un manque de disponibilité. Seules deux demandes mineures ont été rejetées.

Le risque de répétition de l'infraction a été jugé persistant, même si les textes litigieux précis n'étaient plus affichés au moment du jugement. Google n'avait pas formulé de déclaration de cessation assortie d'une clause pénale, et rien n'empêchait les algorithmes de générer à nouveau les mêmes affirmations à l'avenir. Google doit prendre en charge 80 % des frais de justice, les plaignants se partageant les 10 % restants chacun. Selon le tribunal, la portée de cette décision pourrait dépasser les frontières allemandes.

Une précision technique qui change la donne juridique

Le jugement de Munich dépasse largement le cadre de cette seule affaire. Une analyse réalisée par la startup spécialisée en IA Oumi pour le New York Times a montré que les AI Overviews de Google, fonctionnant avec le modèle Gemini 3, répondaient correctement 91 % du temps. Un taux suffisant pour un usage quotidien classique, mais qui représente tout de même, à l'échelle de Google, des millions de réponses erronées chaque heure.

L'analyse d'Oumi a également révélé que 56 % des réponses correctes de Gemini 3 ne pouvaient pas être confirmées par les sources que Google citait lui-même. L'IA fournit donc des réponses dont l'utilisateur ne peut pas retracer l'origine exacte.

C'est précisément ce problème que le tribunal munichois a tranché : l'IA formule ses propres affirmations, qui n'apparaissent dans aucune source citée, et l'opérateur doit en répondre devant la justice. Reste à savoir si ce raisonnement résistera à un appel. Google a confirmé son intention de contester la décision, estimant que l'affaire porte sur « des erreurs spécifiques et limitées, et non sur la manière fondamentale dont les AI Overviews affichent le contenu du web ».

Si le raisonnement du tribunal venait à s'imposer au-delà de l'Allemagne, les conséquences pourraient toucher non seulement Google, mais l'ensemble des fournisseurs d'IA dont les systèmes reformulent du contenu issu du web, à commencer par ChatGPT, Claude ou Perplexity.

L’article "Un tribunal allemand juge Google responsable des erreurs de ses AI Overviews" a été publié sur le site Abondance.

Article sponsorisé

Une génération qui tourne le dos à ses modèles

En mai 2026, Eric Schmidt, ancien patron de Google, a été copieusement hué lors d'un discours de remise de diplômes à l'université d'Arizona. La raison : ses propos sur l'intelligence artificielle face à un public de jeunes diplômés sur le point d'entrer sur un marché du travail qu'ils jugent hostile. Cette anxiété généralisée met en exergue une vraie question, à laquelle il vaut mieux répondre par des choix de formation précis que par l'évitement. C'est dans cet esprit qu'une formation marketing certifiante en accord avec son temps prend tout son sens. Il ne s'agit plus d'apprendre à produire, mais à orchestrer !

Eric Schmidt a lui-même reconnu cette peur, évoquant des emplois qui s'évaporent et une génération héritant d'un futur qu'elle n'a pas choisi. Cet épisode n'est pas isolé : une enquête montre qu'environ 10 % des nouveaux étudiants ont déjà changé de filière à cause de l'IA, les filières tech étant les plus délaissées.

Ce qui ne se monnaye plus

Rédiger un article de blog générique, décliner un post LinkedIn standard ou construire une campagne publicitaire sans angle particulier. Voilà autant de tâches que l'IA générative est en mesure d’exécuter en quelques secondes, à un niveau de qualité suffisant pour la majorité des usages courants.

Un employeur qui paierait encore un salaire entier pour ce type de production basique se trompe de calcul. Pour autant, la compétence rédactionnelle pure, longtemps au cœur des métiers du marketing de contenu, n'a pas disparu. Elle a simplement cessé d’être le critère qui justifie une embauche ou une reconversion réussie.

Ce que les entreprises sont prêtes à payer

Actuellement, quatre compétences tirent leur épingle du jeu :

• Le cadrage stratégique : définir l'angle, l'objectif business et le positionnement avant toute production est précisément ce que l'IA ne peut pas faire à la place d'un humain qui connaît parfaitement le contexte de l'entreprise.
• La distribution : savoir où et comment diffuser un contenu pour qu'il atteigne sa cible, alors que produire du contenu coûte de moins en moins cher, mais que l'attention reste rare.
• La lecture des données : interpréter des résultats de campagne, des données SEO ou des retours utilisateurs pour ajuster une stratégie ; une compétence analytique que l'automatisation ne remplace pas, mais accentue.
• Enfin, le pilotage des outils : savoir formuler les bonnes instructions, contrôler la qualité des sorties IA et orchestrer plusieurs outils entre eux est maintenant compétence à part entière, distincte de la simple utilisation passive.

Une peur pas totalement infondée, mais mal ciblée

Les craintes des jeunes diplômés sont loin d’être irrationnelles. En effet, les entreprises réduisent certains postes juniors et présentent parfois l'IA comme un substitut commode à l'embauche d'exécutants.

Le problème n'est donc pas la technologie en elle-même, mais la manière dont elle redéfinit ce qu'un profil débutant doit apporter. Le risque touche principalement les tâches répétitives et standardisées qu’il est possible de confier à la machine. Le jugement métier, la créativité stratégique ou la capacité à arbitrer entre plusieurs options restent aujourd’hui des domaines à l’abri de l’automatisation. Une reconversion réussie doit donc viser ce second registre en priorité.

L’impact du contexte actuel sur la reconversion professionnelle

Ce qu’on pouvait qualifier de « parcours de formation pertinent » il y a trois ans n’est plus d’actualité aujourd’hui. Pour aborder cette transition avec succès, le professionnel doit désormais intégrer l’usage des outils IA comme un prérequis, et non plus comme une simple option.

Il doit par ailleurs se concentrer sur la stratégie et l’analyse plutôt que sur la seule production, et se préparer à des missions de pilotage plutôt que d’exécution. Choisir un cursus qui ignore ces mutations, c’est prendre le risque de se reconvertir pour un métier qui n’existera peut-être plus dans quelques années, pour ne pas dire dans quelques mois. D’où l’importance de se tourner vers une école pleinement inscrite dans son époque, qui apportent les compétences qui comptent vraiment !

L’article "La reconversion à l’ère de l’IA générative : les nouvelles compétences attendues des entreprises" a été publié sur le site Abondance.

Le consultant SEO Daniel Roch a relayé cette mise à jour sur LinkedIn, en rappelant qu'elle vient confirmer les résultats d'un test qu'il avait mené sur le sujet, ainsi que les réserves qu'il exprimait depuis plusieurs mois sur le fichier llms.txt.

Que dit exactement la documentation de Google

Dans la section consacrée aux idées reçues sur l'optimisation pour l'IA générative, Google liste plusieurs pratiques que les éditeurs de sites peuvent ignorer sans crainte pour leur visibilité. La première concerne directement le sujet : les fichiers llms.txt et les autres formats spéciaux. Google précise qu'il n'est pas nécessaire de créer de nouveaux fichiers lisibles par machine, de fichiers texte pour IA, de balisages ou de contenu en Markdown pour apparaître dans Google Search, y compris dans ses fonctionnalités d'IA générative comme les AI Overviews ou l'AI Mode, car Google Search lui-même ne les utilise pas.

La firme de Mountain View ajoute une précision importante : le moteur peut tout à fait découvrir, explorer et indexer toutes sortes de fichiers en plus du HTML sur un site. Mais cela ne signifie pas que ces fichiers bénéficient d'un traitement particulier. Autrement dit, qu'un fichier llms.txt existe sur un site ou non ne change rien à la façon dont Google traite ce site.

Google va même plus loin en précisant que créer et maintenir ce type de fichier reste tout à fait possible, notamment pour d'autres services ou systèmes qui s'appuient sur ce format. Cela ne nuira ni n'aidera la visibilité ou le positionnement dans Google Search, puisque Google l'ignore tout simplement.

Pourquoi ce sujet fait débat depuis plusieurs mois

Le fichier llms.txt a été proposé comme une sorte d'équivalent au robots.txt, mais destiné aux modèles de langage plutôt qu'aux robots d'indexation classiques. L'idée consistait à fournir aux IA un résumé structuré du contenu d'un site, dans un format simplifié et lisible par les machines, pour faciliter la citation ou la compréhension du site par les outils d'intelligence artificielle.

Ce format a rapidement été présenté par certains acteurs du GEO comme une nouvelle brique incontournable de l'optimisation pour les IA. Mais, dans le même temps, certains experts ont appelé à la prudence sur ce point, en s'appuyant sur des constations et des tests maisons.

Les limites structurelles du format pointées par les experts

Le premier argument avancé par Daniel Roch est l'absence de standard reconnu. Le fichier llms.txt n'a jamais été officiellement adopté par les grands acteurs du marché de l'IA générative, ce qui en fait une initiative communautaire plutôt qu'une norme établie.

Le deuxième argument porte sur la structure même du fichier. Son format est très permissif, ce qui signifie que son contenu peut varier considérablement d'un site à l'autre. Cette absence de cadre strict empêche de considérer le fichier comme fiable ou exhaustif. Un fichier llms.txt peut donc très facilement se révéler incomplet, devenir obsolète au fil du temps, ou être manipulé pour orienter artificiellement la perception d'un site par une IA.

Le troisième argument concerne les capacités déjà existantes des IA pour récupérer de l'information. Les modèles disposent d'autres moyens techniques pour explorer et comprendre le contenu d'un site, ce qui rend un fichier de synthèse dédié moins indispensable qu'on ne le présente parfois.

Enfin, le quatrième argument touche à la nature même des requêtes adressées aux IA. Pour une grande partie des questions posées, l'intelligence artificielle cherche une réponse précise et localisée dans le contenu, pas une vision d'ensemble du site fournie par un fichier global. Un llms.txt, par construction, ne peut offrir qu'une vue générale, ce qui correspond rarement à ce que l'IA va réellement chercher pour répondre à une requête spécifique.

Ce que Google recommande à la place

Au-delà du cas du llms.txt, la documentation de Google liste d'autres pratiques GEO considérées comme inutiles pour son propre moteur.

• Le découpage du contenu en petits fragments, connu sous le nom de chunking, n'est pas nécessaire. Les systèmes de Google sont en effet capables de comprendre plusieurs sujets traités sur une même page et d'en extraire la partie pertinente pour chaque utilisateur.
• La longueur idéale d'une page n'existe pas dans l'absolu, et le bon réflexe reste d'écrire pour son audience plutôt que pour un système d'IA.
• Réécrire du contenu spécifiquement pour les IA n'est pas non plus utile selon Google, qui indique que ses systèmes comprennent les synonymes et le sens général d'une recherche, sans nécessiter une correspondance exacte de mots-clés.
• Les mentions artificielles d'une marque à travers le web sont également écartées, Google misant sur ses systèmes de détection de contenu de qualité et de lutte contre le spam.
• Enfin, les données structurées ne sont pas requises spécifiquement pour l'IA générative, même si leur usage reste recommandé dans une stratégie SEO globale, notamment pour l'éligibilité aux résultats enrichis.

Google recentre ainsi le débat sur les fondamentaux déjà connus du SEO : une structure technique claire, un contenu non générique apportant un point de vue ou une expertise réelle, et une expérience de page satisfaisante pour les visiteurs. Pour le moteur, optimiser pour la recherche générative reste avant tout une question de SEO, et non une discipline distincte nécessitant de nouveaux formats ou de nouvelles balises.

L’article "Google confirme qu’il ignore le fichier llms.txt et clôt le débat" a été publié sur le site Abondance.

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

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

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

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

 Accéder à l’édition complète

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

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

Par Lou Pichard, directeur SEO chez Eskimoz Bordeaux

À découvrir dans cet article :

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

Ce qu'on a aimé :

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

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

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

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

À découvrir dans cet article :

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

Ce qu'on a aimé :

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

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

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

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

À découvrir dans cet article :

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

Ce qu'on a aimé :

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

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

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

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

À découvrir dans cet article :

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

Ce qu'on a aimé :

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

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

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

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

À découvrir dans cet article :

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

Ce qu'on a aimé :

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

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

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

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

Un retour aux sources vingt ans après

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

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

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

Premier principe : choisir l'optimisme

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

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

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

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

Deuxième principe : se tourner vers les sujets difficiles

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

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

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

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

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

Troisième principe : suivre sa passion

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

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

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

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

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

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

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

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

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

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

Des ajouts en masse signalés partout

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

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

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

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

Aucune option de suppression disponible pour l'instant

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

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

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

Ce qu’on vous avait déjà montré, et que Google confirme

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.