Ce que change l'IA dans le processus de design

La promesse des agents IA dans le développement produit n'est pas uniquement une question de vitesse. L'accélération est réelle, mais construire vite un mauvais produit ne sert à rien. Ce qui change réellement, c'est la capacité à itérer plus tôt, plus souvent et sur des artefacts plus concrets.

Figma s'inscrit dans cette logique en s'ouvrant aux workflows agentiques via son serveur MCP. L'idée : permettre à des agents comme Cursor, Claude Code ou Codex d'interagir directement avec le canvas de Figma (c’est-à-dire l’espace de travail), d'y lire des composants, d'y écrire des frames, de manipuler des variables. Le tout sans que le designer ait à effectuer le travail de copier-coller entre deux environnements.

MCP, agents et skills : de quoi parle-t-on exactement ?

Avant d'entrer dans les workflows, trois concepts méritent d'être compris clairement.

• Un agent, c'est un système logiciel qui utilise l'IA pour atteindre des objectifs et accomplir des tâches. Dans le développement produit, un agent peut planifier un projet, écrire du code, interpréter des visuels ou orchestrer d'autres agents. Cursor, Codex et Claude Code en sont des exemples courants.
• MCP signifie Model Context Protocol. C'est un standard ouvert qui définit comment les agents communiquent avec d'autres logiciels, comme Figma. Un serveur MCP permet à un agent de récupérer du contexte depuis des sources externes pour prendre de meilleures décisions. Le serveur MCP de Figma permet concrètement de :
• Traduire du code en designs Figma
• Créer et modifier des éléments sur le canvas
• Retransformer ces designs en code

Ce pont bidirectionnel entre design et code est ce qui rend le workflow agentique avec Figma utile.

• Un skill, enfin, c'est un fichier texte contenant un ensemble d'instructions qu'un agent peut apprendre et réutiliser pour accomplir une tâche spécifique. Toute tâche répétitive qu'on reprompt régulièrement à son agent est un bon candidat pour devenir un skill. Les skills liés à ces workflows sont disponibles sur la page Figma Community et peuvent être installés en copiant leur lien GitHub dans l'agent.

Il existe aussi un skill particulier, /figma-use, aussi appelé « write to canvas ». Il permet à un agent de créer et de modifier un fichier Figma réel en utilisant les composants, variables et styles existants du projet.

Workflow 1 : importer un prototype codé dans Figma

Quand l'utiliser : quand un prototype fonctionnel existe en code et qu'on veut le ramener dans Figma pour le réviser, itérer ou partager.

Beaucoup d'équipes commencent aujourd'hui à designer directement dans le code, souvent dans un « prototype playground » : un environnement bac à sable avec du vrai code et des écrans issus de l'application de production, mais sans risque d'affecter le code de production ni les designs finaux. Ce workflow s'applique à cette situation, mais aussi à n'importe quel prototypage en code.

Étape 1 : importer le prototype dans Figma

Le skill /prototype-to-figma prend en charge l'import. Il capture un prototype qui tourne en local et place chaque écran unique sur le canvas Figma sous forme de frames connectées au design system.

Pour l'utiliser, il suffit de taper /prototype-to-figma dans l'agent (par exemple Cursor) et de lui indiquer l'URL localhost du prototype. Chaque étape du flux du prototype apparaît sur le canvas comme une frame de design, avec les composants et styles du design system existant. Le skill génère aussi une page de résumé et une page de styles pour avoir le contexte de ce qui a été capturé et pourquoi.

Étape 2 : réviser et affiner sur le canvas

Une fois les écrans dans Figma, on peut voir l'ensemble du flux d'un seul regard et l'évaluer globalement. Un prototype généré par IA est un bon point de départ pour valider une idée, mais il nécessite souvent un travail de design avant d'être prêt pour un retour ou une passation.

Quelques points à examiner lors de la révision :

• Les éléments d'UI redondants : par exemple, si un écran a à la fois un indicateur d'étapes et une barre de progression, l'un des deux est probablement superflu.
• Les opportunités d'utiliser des composants du design system : remplacer des éléments ad hoc par de vrais composants (cartes, boutons, primitives de layout) rapproche le design des standards de production.
• La hiérarchie visuelle : illustrations, typographie et espacement peuvent créer une composition plus intentionnelle.
• La structure du layout : ajouter de l'auto layout aux frames donne un aperçu plus précis de l'espacement.

Itérer directement sur le canvas, surtout en co-design avec un collègue, est souvent plus rapide que de repromper l'agent pour faire les mêmes changements dans le code.

Étape 3 : partager ou mettre à jour le prototype

Une fois le design affiné, deux options s'offrent à vous : partager pour recueillir des retours (le design est prêt pour les parties prenantes), ou demander à l'agent de mettre à jour le prototype directement en utilisant le design Figma comme source de vérité.

Workflow 2 : synchroniser le design system entre code et Figma

Quand l'utiliser : quand on veut que les outils agentiques génèrent du code qui référence de vrais composants et tokens du design system.

Les design systems permettent aux équipes de créer des expériences cohérentes et qui passent à l'échelle. Mais quand le design se fait dans le code, lors d'un hack week, d'une expérimentation rapide ou d'un sprint IA, ces changements peuvent se retrouver isolés dans la codebase, déconnectés du design system dans Figma.

Ce workflow montre comment ramener un design codé (avec ses variables) sur le canvas, l'évaluer, l'affiner, et repousser les tokens mis à jour vers le code.

Les skills /figma-generate-design et /figma-generate-library utilisés ici sont pré-installés avec le serveur MCP de Figma.

Étape 1 : importer le design et les variables dans Figma

Si une nouvelle direction de design a été construite en code (par exemple, un dark mode utilisant les variables de couleur du design system existant), les skills pré-installés permettent de la capturer dans Figma. Un prompt appelant /figma-generate-design et /figma-generate-library va :

• Placer les écrans sur le canvas Figma (par exemple, les modes clair et sombre côte à côte)
• Créer une nouvelle collection de variables dans le panneau des variables qui reflète les tokens utilisés dans le code

On peut alors évaluer le design d'un seul coup d'oeil et vérifier comment il se tient sur plusieurs écrans, ce qui est difficile à faire quand le design n'existe que dans un environnement local qui tourne.

Étape 2 : évaluer et affiner les variables

Avec les écrans et les variables sur le canvas, on peut repérer les problèmes difficiles à détecter dans le code seul. Points courants à surveiller :

• L'intensité des couleurs : les couleurs d'accent qui fonctionnent bien en mode clair peuvent paraître saturées ou "néon" en mode sombre. Envisager de passer à une teinte différente de la palette.
• Le contraste du texte : les textes à faible contraste, notamment les labels secondaires comme les dates ou légendes, peuvent ne pas répondre aux standards d'accessibilité. Si l'équipe vise WCAG AAA, ces valeurs méritent une vérification attentive.

Pour effectuer des ajustements, on ouvre le panneau des variables et on met à jour les tokens directement. Les modifications se reflètent en temps réel sur tous les composants et références de styles du canvas, ce qui donne une vue globale de l'impact des décisions de tokens sur l'ensemble du design.

Voir les variables et leurs effets simultanément plutôt que de modifier une valeur dans le code et rafraîchir un navigateur accélère considérablement l'itération.

Étape 3 : repousser les tokens affinés vers le code

Une fois les variables stabilisées, on peut demander à l'agent de mettre à jour le design system dans la codebase avec les tokens affinés. Figma devient la source de vérité pour les décisions de design, et le code reste synchronisé.

Workflow 3 : explorer de nouvelles directions directement depuis le canvas

Quand l'utiliser : quand on veut rapidement explorer ou itérer sur des designs existants sans quitter Figma.

Pour beaucoup d'équipes, Figma est la source de vérité. Les designs existent déjà sur le canvas. Le défi n'est pas de partir de zéro, c'est de savoir comment avancer. Quand la recherche utilisateur fait remonter un problème sur un écran existant, la partie la plus difficile de l'itération est souvent de faire ce premier pas.

Ce workflow montre comment utiliser un agent pour générer une direction de départ avec les vrais composants de l'équipe, afin de pouvoir réagir à quelque chose de concret et l'affiner sur le canvas.

Étape 1 : définir le problème

On part d'un énoncé de problème clair, ancré dans la recherche ou les retours utilisateurs. Plus le prompt est précis, plus la sortie de l'agent sera utile.

Par exemple : un tableau de bord de revenus clients où l'état de renouvellement s'affiche comme un simple label texte en fin de chaque ligne. La recherche montre que les utilisateurs le ratent. Le problème à résoudre est de rendre l'état de renouvellement plus visible et plus facile à actionner.

Il existe souvent plusieurs approches valides : codage couleur, regroupement des lignes par statut, introduction d'une nouvelle hiérarchie visuelle. Voir des directions sur le canvas est ce qui fait avancer la conversation.

Étape 2 : générer une direction de départ avec l'agent

Dans l'agent, on lance le skill /figma-use. On inclut le contexte pertinent dans le prompt : insights de recherche utilisateur, problème précis, contraintes éventuelles, puis on demande à l'agent d'explorer une approche avec les composants existants.

L'agent produit une itération brute directement sur le canvas, construite avec les composants de production. L'objectif à ce stade n'est pas un design fini, c'est un point de départ concret sur lequel on peut réagir et affiner.

Étape 3 : affiner sur le canvas

On revoit ce que l'agent a produit et on s'en sert comme point de départ. Quelques éléments à évaluer :

• Est-ce que la solution change le principe organisateur du layout ? Grouper ou prioriser l'information différemment peut faire en sorte que les données critiques soient vues en premier, plutôt qu'après un balayage visuel.
• Est-ce que les bons composants sont utilisés ? L'agent doit piocher dans le design system. Si ce n'est pas le cas, on ajuste le prompt ou on remplace les composants manuellement.
• Qu'est-ce qui fonctionne, qu'est-ce qui ne fonctionne pas ? On réagit à ce qui est visible. L'agent dépasse le syndrome de la page blanche ; le designer et son équipe apportent le jugement de design.

Itérer directement sur le canvas plutôt que de prompter en boucle permet de passer rapidement de la discussion abstraite aux décisions concrètes et visibles.

Ce que ça change vraiment

Dans les trois workflows, le même schéma se répète : que le point de départ soit du code ou le canvas, l'agent prend en charge le travail d'assemblage mécanique. Le designer concentre son temps sur ce qui demande un oeil de designer.

Le serveur MCP de Figma peut être connecté de deux façons :

• via un serveur MCP distant (recommandé), qui se connecte directement à l'endpoint hébergé par Figma à https://mcp.figma.com/mcp,
• ou via un serveur MCP desktop qui tourne localement via l'application Figma, principalement pensé pour des cas d'usage spécifiques en entreprise.

L’article "Figma + agents IA : trois workflows concrets pour concevoir et coder sans friction" a été publié sur le site Abondance.

Un panier qui travaille pendant que vous dormez

L'idée de base paraît simple, mais elle change assez radicalement ce qu'on attend d'un panier en ligne. Aujourd'hui, ajouter un article à un panier, c'est surtout ne pas l'oublier. Avec Universal Cart, dévoilé dans le cadre du Google I/O 26, c'est le point de départ d'un suivi actif.

Dès qu'un produit est ajouté, le système se met en route en arrière-plan. Il cherche des promotions, surveille les baisses de prix, consulte l'historique tarifaire du produit et envoie une alerte si un article épuisé revient en stock. Toutes ces vérifications que l'on faisait soi-même, souvent en ouvrant cinq onglets en parallèle, sont désormais automatisées.

Ce qui rend la proposition intéressante, c'est la portabilité du panier. Il ne vit pas dans un coin isolé de Google Shopping. Vous pouvez ajouter un article pendant une recherche sur Google, retrouver ce même panier en regardant une vidéo YouTube, en discutant avec l'assistant Gemini ou en lisant un mail dans Gmail. Le panier vous suit, plutôt que l'inverse.

Universal Cart sera disponible aux États-Unis sur Search et l'application Gemini à partir de cet été. YouTube et Gmail seront intégrés dans un second temps.

La compatibilité des produits, gérée à votre place

C'est l'une des fonctionnalités les plus concrètes présentées par Google, et elle illustre bien l'ambition du projet.

Imaginez que vous montez votre premier PC sur mesure. Vous ajoutez un processeur chez un vendeur, une carte mère chez un autre, de la RAM chez un troisième. Le problème, c'est que certains composants peuvent simplement ne pas fonctionner ensemble. Sans expertise technique, difficile de s'en rendre compte avant d'avoir tout commandé et tout reçu.

Universal Cart peut détecter ce type d'incompatibilité directement dans le panier et suggérer des alternatives adaptées, avant même que vous n'ayez confirmé vos achats. Google parle d'un « raisonnement intelligent » pour anticiper ce genre de problème. Le système s'appuie sur les modèles Gemini et sur le Shopping Graph, la base de données produits de Google qui recense plus de 60 milliards de références.

Le panier est aussi connecté à Google Wallet, ce qui lui permet de connaître vos cartes bancaires et les avantages qu'elles offrent. Si l'une d'elles donne droit à des points de fidélité ou à une réduction chez un marchand partenaire, le système vous le signale sans que vous ayez à vous en souvenir.

Universal Commerce Protocol : une seule langue pour tout un secteur

Pour que tout cela fonctionne à grande échelle, il fallait résoudre un problème technique fondamental : comment faire communiquer des dizaines de marchands, de plateformes et d'agents IA entre eux, alors que chacun parle sa propre langue technique ?

C'est l'objet du Universal Commerce Protocol, ou UCP. Il s'agit d'un standard ouvert que Google a développé en collaboration avec plusieurs grandes entreprises, dont Amazon, Meta, Microsoft, Salesforce et Stripe, qui ont rejoint le comité technique du projet. L'UCP donne à tous les acteurs du commerce en ligne un vocabulaire commun pour gérer chaque étape d'une transaction, de la recherche de produit jusqu'au suivi de livraison ou au traitement des retours.

Concrètement, ce protocole est ce qui permet de passer en caisse depuis Universal Cart sans être redirigé vers le site du marchand. Pour les enseignes compatibles comme Nike, Sephora, Target, Walmart, Wayfair ou les boutiques Shopify comme Fenty et Steve Madden, l'achat peut être finalisé directement dans l'interface Google via Google Pay, en quelques clics. Le marchand reste « marchand de référence » pour la transaction, ce qui a son importance en termes de gestion des retours et du service client.

L'UCP va aussi s'étendre à de nouveaux secteurs : la réservation d'hôtels et la livraison de repas à domicile seront prochainement intégrés. Géographiquement, le déploiement s'élargira au Canada, en Australie puis au Royaume-Uni.

Aucune date n'est annoncée pour la France à ce stade.

Laisser une IA payer à votre place… avec des garde-fous

C'est sans doute le volet le plus ambitieux, et le plus sensible, de cette annonce. Google veut permettre à un agent IA d'effectuer des achats de façon totalement autonome, en votre nom. Pour répondre à la question légitime que cela soulève, la firme a créé l'Agent Payments Protocol, ou AP2.

Le principe repose sur un système de règles que l’internaute définit lui-même : les marques autorisées, les types de produits concernés, le budget maximum par article. L'agent ne peut effectuer un achat que si toutes ces conditions sont remplies simultanément. Il n'a aucune latitude pour en sortir.

Sur le plan technique, AP2 crée une trace numérique permanente et infalsifiable de chaque transaction, partagée entre vous, le marchand et le service de paiement. Si un retour est nécessaire, vous et le marchand consultez exactement le même document, ce qui évite tout désaccord sur les conditions de l'achat. Google utilise des technologies de protection de la vie privée et des mandats numériques inviolables pour garantir que l'agent agit toujours en votre nom.

L'intégration d'AP2 démarrera dans les prochains mois, en commençant par Gemini Spark, le nouvel assistant propulsé par Gemini 3.5, le modèle conçu par Google pour l'ère agentique.

L’article "Google Universal Cart : le panier intelligent qui surveille vos achats à votre place" a été publié sur le site Abondance.

Chrome Lighthouse intègre la détection du llms.txt

Google a récemment publié une documentation sur les nouveaux audits « Agentic Browsing » de Chrome Lighthouse. Ces audits sont conçus pour évaluer dans quelle mesure un site est structuré pour les agents IA et les systèmes de lecture automatique. On y trouve des critères déjà connus des SEO, comme la stabilité visuelle (CLS), la construction de l'arbre d'accessibilité (A11y tree), ou encore la structure sémantique des pages.

Mais un point attire particulièrement l'attention : Lighthouse vérifie désormais « la présence d'un résumé lisible par les machines à la racine du domaine », autrement dit, l'existence d'un fichier llms.txt.

Ce fichier, inspiré du robots.txt, est un format encore non standardisé qui permet aux propriétaires de sites de fournir aux grands modèles de langage un résumé structuré de leur contenu. Pendant des mois, Google a évité de prendre position dessus, renvoyant les SEO à leurs pratiques habituelles.

Un message contradictoire en moins d'une semaine

Le timing pose question. Il y a moins d'une semaine, Google publiait de la documentation expliquant aux SEO qu'ils n'avaient pas besoin de s'occuper de fichiers supplémentaires ou de balisage spécifique pour être visibles dans les résultats de recherche IA. Et pourtant, dans la foulée, la documentation Chrome mentionnait explicitement l'audit du llms.txt comme critère d'évaluation de la « préparation IA » d'un site.

C'est dans ce contexte que la spécialiste SEO Lily Ray a interpellé John Mueller sur Bluesky, en pointant l'ironie de la situation : Google utilise lui-même des fichiers llms.txt et des pages en markdown sur ses propres propriétés, tout en affirmant que ces éléments ne sont pas nécessaires pour performer en recherche.

La réponse de John Mueller : découverte contre fonctionnalité

John Mueller a répondu en posant une distinction qu'il juge fondamentale : celle entre la « découverte » et la « fonctionnalité ».

• La découverte, c'est le périmètre du SEO classique : être trouvé par un moteur de recherche.
• La fonctionnalité, c'est autre chose : une fois qu'un utilisateur ou un agent a trouvé la page, l'aider à accomplir ce qu'il est venu faire.

Dans cette logique, les fichiers llms.txt et les versions markdown de la documentation sur developers.google.com ne sont pas là pour améliorer le référencement. Ils sont là parce que le codage assisté par IA est devenu très populaire, et que ces systèmes sont plus efficaces lorsqu'ils peuvent lire et parser facilement de la documentation de référence. Donner à ces outils un contexte clair et une version simplifiée des pages leur permet de produire un code plus pertinent. John Mueller reconnaît lui-même qu'il s'agit d'une « béquille temporaire », les LLM sachant très bien lire du HTML, mais qui peut permettre d'économiser quelques tokens.

Il est explicite sur le périmètre de cette logique : elle s'applique aux sites de documentation technique, pas au reste. Autrement dit, créer une version markdown des caractéristiques d'une chaussure ne générera pas plus de ventes.

Ce que ça dit de l'évolution du SEO technique

La clarification de John Mueller ne clôt pas complètement le débat. Si llms.txt n'a pas de pertinence SEO au sens strict, son intégration dans les audits Lighthouse signale que Google pense de plus en plus à la lisibilité des sites pour les agents, au-delà du crawl traditionnel.

Les critères qui émergent dans ces audits, comme l'accessibilité sémantique, la stabilité du layout ou la présence de métadonnées structurées, sont en réalité des signaux que les SEO techniques connaissent bien. Mais leur importance dans un contexte d'IA agentique leur donne potentiellement un nouveau poids.

Des experts comme Crystal Carter, John-Henry Scherck ou Joost de Valk commencent d'ailleurs à reconsidérer publiquement leur position sur le llms.txt. Ce revirement progressif chez des praticiens sérieux est lui-même un signal. Mais la position de John Mueller apporte un cadre utile : pour les sites de documentation technique, l'effort peut se justifier. Pour les autres, les priorités SEO habituelles restent largement devant.

L’article "Le fichier llms.txt ne sert à rien, mais Lighthouse le vérifie quand même" a été publié sur le site Abondance.

Google déploie une nouvelle Core Update 2026

Après la Core Update de mars 2026, voici venu la deuxième Core Update de 2026.

Voici ce que dit Google dans sa communication :

"Today we released the May 2026 core update to Google Search. This is a regular update designed to better surface relevant, satisfying content for searchers from all types of sites. The rollout may take up to 2 weeks to complete."

Comme pour la mise à jour de mars 2026, le déploiement de cette update va durer 2 semaines !

Retrouvez toutes les dernières updates de Google sur notre page dédiée.

Doit-on s'inquiéter ?

Non, il s'agit d'une mise à jour classique chez Google dont le but n'est pas de pénaliser les sites, mais de valoriser le meilleur contenu. Autrement dit, si vous constatez une baisse, c'est que d'autres contenus sont désormais jugés plus pertinents que le vôtre.

Au-delà des Core et des Spam Updates, rappelons que Google lance des milliers de mises à jour par an pour répondre aux attentes de ses utilisateurs. Il y a quelques mois, John Mueller avait évoqué le chiffre de 4 700 mises à jour annuelles, issues de plus de 700 000 tests.

Quoi faire pendant une mise à jour majeur de l'algo de Google ?

Ne faites rien de spécial ! Au lieu de céder à la panique, surveillez votre trafic dans la Google Search Console et attendez la fin de la mise à jour (2 semaines dans ce cas) avant d'effectuer des modifications majeures sur votre site internet.

Voici trois ressources à lire pour comprendre le concept de "Core Update" :

• « Ne paniquez pas ! » : comment appréhender les annonces Google ?
• Google Updates : comprendre les mises à jour Google
• Algorithmes Google : Définitions, Historique et Fonctionnement [Guide 2025]

Rendez-vous dans 2 semaines pour faire le bilan !

L’article "Google Core Update de mai 2026 : le grand retour !" a été publié sur le site Abondance.

Une étude inédite de Minddex vient de bousculer les certitudes du SEO sur YouTube. Sur 55 631 citations analysées, les modèles d'IA comme ChatGPT, Perplexity ou Gemini ne fonctionnent pas du tout comme l'algorithme YouTube. Les vues ne comptent pas. Les abonnés non plus. Ce qui compte, c'est ce que dit la vidéo.

Ce que Minddex a mesuré, et ce que ça signifie

Minddex est une plateforme spécialisée dans la visibilité IA, également connue sous le terme GEO (Generative Engine Optimization). En mai 2026, l’équipe de Minddex a publié une étude sur la façon dont YouTube apparaît dans les réponses des grands modèles de langage. Elle fait suite à une étude équivalente sur Reddit, que nous avons relayé fin avril.

Le corpus est considérable : 57 871 citations YouTube brutes, dont 55 631 ont pu être enrichies et analysées, soit 96,1 % du total. Ces citations sont extraites de 33 706 réponses LLM uniques, produites par ChatGPT, Perplexity et Gemini, sur 526 projets clients B2B et B2C couvrant de nombreux secteurs. Au total, 22 180 vidéos uniques et plus de 12 000 chaînes distinctes sont représentées.

L'objectif était le suivant : comprendre ce qui détermine, concrètement, qu'une vidéo YouTube se retrouve citée dans une réponse d'IA. Les hypothèses habituelles (vues, abonnés, taille de chaîne) ont été testées statistiquement. Les résultats contredisent presque systématiquement les intuitions issues du SEO classique.

L'audience humaine ne prédit pas la visibilité LLM

C'est probablement le résultat le plus contre-intuitif de l'étude. Minddex a calculé la corrélation entre les métriques d'audience (nombre de vues, nombre d'abonnés de la chaîne) et le nombre de citations LLM reçues par une vidéo. Les coefficients de Spearman obtenus sont respectivement de +0,088 pour les vues et +0,019 pour les abonnés. Les deux sont bien en dessous du seuil de pertinence pratique fixé à 0,10.

Traduction : une vidéo à 50 vues a autant de chances d'être citée par ChatGPT qu'une vidéo à 50 millions de vues, si son contenu répond précisément à la question posée. La médiane constatée est d'une seule citation par vidéo, et ce dans tous les segments d'audience sans exception.

Ce que les LLM lisent, ce sont les transcripts, pas les compteurs. Ils évaluent la pertinence sémantique du contenu au regard de la requête de l'utilisateur. La popularité humaine n'entre pas dans cette logique.

Ce résultat a une implication directe pour les marques qui ont longtemps pensé que leur visibilité IA dépendait de leur performance sur la plateforme. Ce n'est pas le cas. Les deux systèmes fonctionnent selon des logiques distinctes.

Les chaînes de marque ne captent quasiment rien

Un autre chiffre frappe dans cette étude : 97,6 % des citations LLM pointent vers des contenus produits par des tiers. Les créateurs indépendants arrivent en tête avec 36 % des citations, suivis des médias et de la presse (32 %) et des particuliers (30 %). Les chaînes officielles de marque ne captent que 2,4 % des citations.

L'écart avec Reddit est saisissant. Sur ce dernier, la répartition tiers/marque était de 78 % contre 22 %. Sur YouTube, elle est de 97,6 % contre 2,4 %. Le ratio est presque binaire.

Conclusion pratique : publier sur sa propre chaîne YouTube est un complément, pas un levier principal pour l'AI Search. Pour exister dans les réponses des LLM, il faut apparaître dans des vidéos tierces : celles des créateurs, des journalistes spécialisés, des utilisateurs qui parlent de vos produits ou de votre secteur. Le travail de relations presse, de placement et de seeding auprès des créateurs devient une composante structurante de la stratégie GEO, et non plus une option périphérique.

Le format qui fonctionne : entre 5 et 15 minutes

L'étude apporte aussi une réponse précise à la question du format. 41,9 % des citations LLM vont à des vidéos d'une durée comprise entre 5 et 15 minutes. C'est environ deux fois leur poids réel dans le catalogue YouTube (où les vidéos de 5 à 10 minutes représentent environ 19 % des mises en ligne selon Statista 2025).

À l'opposé, les Shorts (moins de 60 secondes) ne captent que 3,6 % des citations, alors qu'ils représentent 36 % des uploads quotidiens sur la plateforme. La sous-représentation est d'un facteur 10.

La règle est simple : les Shorts servent la viralité Discovery, selon une logique proche de TikTok. Le format moyen-long, entre 5 et 15 minutes, sert l'AI Search. Une vidéo courte n'offre pas assez de contenu textuel pour que les LLM puissent en extraire une réponse substantielle à une requête précise. Une vidéo de 8 minutes, bien structurée, qui traite un sujet en profondeur, offre un transcript exploitable. C'est ce que les modèles recherchent.

Pour les équipes qui ont bâti leur stratégie de contenu autour des Shorts en 2025-2026, c'est une donnée à intégrer rapidement : ce format capitalise pour la découverte algorithmique, pas pour la visibilité dans les réponses IA.

La longue traîne YouTube est accessible

L'étude apporte aussi une bonne nouvelle pour les petites chaînes. 71 % des citations LLM vont à des chaînes de moins de 100 000 abonnés. La tranche dominante est celle des chaînes entre 10 000 et 100 000 abonnés, qui concentre 33,2 % des citations. Mieux encore : les très petites chaînes de moins de 1 000 abonnés pèsent 11,5 % du total.

À l'inverse, les très grandes chaînes (plus d'un million d'abonnés) ne représentent que 6 % des citations. Certes, les chaînes dépassant 100 000 abonnés restent proportionnellement surreprésentées par rapport à leur poids dans le catalogue global (elles constituent environ 1 % des chaînes YouTube mais récoltent 29 % des citations LLM, soit une surreprésentation d'un facteur 30). Mais l'accès aux citations LLM ne leur est pas réservé. Une chaîne récente, modeste, qui produit du contenu précis et pertinent, peut être citée autant qu'une chaîne établie.

C'est une différence notable avec le SEO YouTube classique, où la taille de la chaîne et le nombre de vues créent des effets de levier puissants. Dans l'AI Search, la pertinence du contenu nivelle en partie ces écarts.

L'effet evergreen est plus fort sur YouTube que sur Reddit

La dimension temporelle de l'étude révèle un troisième enseignement important. 65 % des vidéos citées par les LLM ont plus d'un an au moment de la citation. Sur Reddit, ce chiffre était de 44 %. L'effet evergreen est donc sensiblement plus prononcé sur YouTube.

L'analyse de la distribution par âge des vidéos citées montre que les tranches les plus représentées sont 1 à 3 ans (33,6 %) et plus de 3 ans (31,5 %). Les contenus très récents (moins d'une semaine) sont quasi absents. Les vidéos de moins de trois mois ne représentent ensemble que 6,8 % des citations.

Minddex en déduit qu'il faut entre 12 et 36 mois à une vidéo pour entrer dans le pool des contenus repris par les LLM. L'horizon stratégique est donc de 1 à 3 ans, pas trimestriel. Cela remet en cause les logiques de pilotage par les KPIs à court terme, fréquentes dans les équipes qui mesurent la performance de chaque vidéo dans les semaines suivant sa publication.

Produire du contenu pérenne, sur des sujets stables et récurrents dans sa thématique, est une décision qui se paie sur le long terme. Le taux de vues à J+30 n'est pas le bon indicateur pour anticiper la visibilité dans l'AI Search à 24 mois.

Ce que ça change dans la pratique

L'étude de Minddex dessine assez nettement le fossé entre la logique SEO YouTube historique et ce que demande désormais l'AI Search. Les deux ne s'opposent pas frontalement, mais leur logique respective est suffisamment différente pour justifier une stratégie distincte.

Optimiser un titre et une miniature, viser la viralité, accumuler des abonnés et poster des Shorts pour le reach : tout cela reste pertinent pour l'algorithme YouTube. Ça ne pilote pas la visibilité dans ChatGPT ou Perplexity.

Ce qui y pilote la visibilité, c'est le contenu parlé dans la vidéo, sa précision, sa clarté, sa capacité à répondre à une question que les utilisateurs posent aux LLM. C'est aussi la présence dans des contenus tiers, chez des créateurs ou des médias dont les vidéos traitent de votre secteur, de votre marque, ou des sujets sur lesquels vous voulez exister dans l'AI Search.

La bonne nouvelle pour les acteurs qui ne disposent pas de moyens importants : le ticket d'entrée n'est pas de disposer d’une grosse chaîne. C'est un contenu bien ciblé, bien structuré, et suffisamment ancien pour avoir été indexé et intégré dans les données d'entraînement ou les sources consultées en temps réel par les modèles.

L’article "YouTube dans les LLM : l’étude qui bouscule les certitudes" a été publié sur le site Abondance.

IA Mode : un milliard d'utilisateurs en un an

Avant d'entrer dans le détail des annonces, un chiffre donne la mesure de ce qui s'est passé en un an : le mode IA de Google Search dépasse désormais le milliard d'utilisateurs mensuels, avec un volume de requêtes qui a plus que doublé chaque trimestre depuis son lancement.

Le dernier trimestre a même enregistré un nombre de recherches record, tous canaux confondus. Ce n'est donc pas un pivot expérimental que Google présente à son I/O 2026, mais la confirmation d'un usage massif et en pleine expansion. Rappelons toutefois que pour le moment, ce fameux mode n’est toujours pas disponible en France.

Gemini 3.5 Flash devient le modèle par défaut du mode IA

La première annonce concrète concerne le moteur qui fait tourner tout ça. Google intègre Gemini 3.5 Flash comme modèle de référence de l’AI Mode pour tous les utilisateurs dans le monde dès aujourd'hui.

Ce modèle de nouvelle génération est conçu pour les usages agentiques et le code, avec des performances de pointe maintenues dans la durée. C'est ce moteur qui alimente l'ensemble des nouvelles fonctionnalités annoncées.

La boîte de recherche repensée pour la première fois en 25 ans

C'est l'un des symboles forts de ces annonces : la boîte de recherche Google, quasiment inchangée depuis 1998, est entièrement redessinée avec l'IA. Cette nouvelle interface intelligente s'élargit dynamiquement pour laisser la place à des questions longues et détaillées. Elle propose des suggestions qui vont bien au-delà de l'autocomplétion classique, en anticipant l'intention de l'utilisateur plutôt qu'en se contentant de compléter des mots.

Elle accepte également plusieurs types d'entrées simultanément : texte, images, fichiers, vidéos ou onglets ouverts dans Chrome. Le déploiement commence aujourd'hui dans tous les pays et toutes les langues où le mode IA est actif.

Par ailleurs, la continuité des échanges avec Search est améliorée : il est désormais possible de poser une question de suivi directement depuis une AI Overview, puis de basculer naturellement vers une conversation approfondie en mode IA, en conservant tout le contexte de la session. Cette fluidité est disponible sur desktop et mobile dès aujourd'hui, partout dans le monde.

Les agents d'information : Search qui travaille en arrière-plan

C'est peut-être la nouveauté la plus structurante annoncée. Google introduit des agents d'information qui fonctionnent en continu, 24h/24, sans que l'utilisateur n'ait besoin d'effectuer de nouvelles recherches. Le principe : l'utilisateur décrit précisément ce qu'il cherche à surveiller, et l'agent scrute l'ensemble du web (blogs, médias, réseaux sociaux) ainsi que les données en temps réel de Google (finance, shopping, sport) pour détecter tout changement pertinent.

Lorsqu'une information correspond aux critères définis, l'agent envoie une synthèse intelligente avec la possibilité d'agir directement. Exemple concret : une personne à la recherche d'un appartement peut décrire tous ses critères une seule fois, et l'agent lui envoie une alerte dès qu'une annonce correspondante apparaît. Ou encore, un fan de sneakers peut être notifié dès qu'un athlète annonce une nouvelle collaboration.

Ces agents d'information seront lancés en priorité pour les abonnés Google AI Pro et Ultra, à l'été 2026.

Des réservations et des appels téléphoniques gérés par Search

Google étend également les capacités agentiques à la réservation. L'utilisateur peut décrire ce qu'il recherche, par exemple une salle de karaoké privée pour six personnes un vendredi soir avec service de restauration tardive, et Search agrège les disponibilités et les tarifs en temps réel, avec des liens directs vers les prestataires pour finaliser la réservation.

Pour certaines catégories (services à domicile, soins, animalerie), Google Search peut même passer des appels téléphoniques aux entreprises à la place de l'utilisateur. Ces fonctionnalités seront disponibles aux États-Unis à l'été 2026.

Une interface générée à la volée selon la question posée

Grâce à la technologie Google Antigravity associée à Gemini 3.5 Flash, Search peut désormais construire des réponses sous des formats visuels entièrement personnalisés, générés en temps réel en fonction de la nature de la question. Selon les besoins, il peut assembler des visuels interactifs, des tableaux, des graphiques ou des simulations. Ces interfaces adaptatives seront disponibles gratuitement pour tous les utilisateurs dans les prochains mois.

Au-delà des questions ponctuelles, Google pousse plus loin avec la création de dashboards et de mini-applications sur mesure. L'utilisateur peut demander à Search de construire un suivi personnalisé pour une tâche récurrente, comme la planification d'un déménagement ou d'un mariage.

Ces expériences s'appuient sur des données en direct, critiques, cartes et données météo locales, et sont conçues pour être consultées régulièrement. L'exemple mis en avant est un tracker de fitness complet, généré à la demande, mis à jour en continu. Cette fonctionnalité sera d'abord réservée aux abonnés Google AI Pro et Ultra aux États-Unis.

L'intelligence personnelle s'ouvre à (quasiment) tout le monde

Jusqu'ici limitée, la fonctionnalité Personal Intelligence est désormais accessible dans près de 200 pays et territoires, en 98 langues, sans abonnement. Elle permet de connecter des applications personnelles comme Gmail et Google Photos (et bientôt Google Calendar) directement à Search, pour que celui-ci puisse personnaliser ses réponses en tenant compte du contexte de l'utilisateur.

Google insiste sur l'architecture de confidentialité : l'utilisateur garde le contrôle total sur les connexions activées et peut les révoquer à tout moment.

L’article "Google Search se réinvente : agents IA, box intelligente et temps réel" a été publié sur le site Abondance.

Un serveur MCP pour piloter le SEO Spider depuis une IA

C'est la nouveauté phare de cette version. Screaming Frog introduit un serveur MCP (Model Context Protocol) qui permet de connecter le SEO Spider à des assistants IA comme Claude ou LM Studio. Concrètement, il devient possible de lancer des crawls, d'analyser les données, d'exporter des rapports et de manipuler les résultats directement depuis une interface de chat, en langage naturel.

Les cas d'usage couvrent un spectre large :

• Résumer un crawl en quelques mots, visualiser les données sous une forme personnalisée,
• Combiner des exports,
• Exécuter le pipeline d'analyse complet
• Installer des scripts pour produire des visuels interactifs.

Screaming Frog donne l'exemple d'une analyse de maillage interne réalisée avec l'intégration Ahrefs et rendue sous forme de graphique via l'IA.

L'intégration avec Claude Cowork est également mentionnée comme un axe prometteur, notamment pour automatiser des tâches répétitives sur des fichiers et des workflows quotidiens.

Il faut noter que toutes les fonctionnalités du SEO Spider ne sont pas encore supportées dans le MCP. Screaming Frog prévoit d'étendre les capacités en fonction des retours utilisateurs.

La comparaison automatique de crawls

Jusqu'ici, comparer deux crawls demandait une manipulation manuelle. La version 24.0 introduit une option « Auto Compare Crawls » disponible dans les tâches de crawl planifiées et les crawls en ligne de commande (CLI). Activée, elle compare automatiquement les deux derniers crawls d'un projet et génère un rapport de différences.

Ce rapport liste tous les changements survenus entre les deux crawls : pages ajoutées ou supprimées, évolution des problèmes SEO détectés, variations sur les balises, les codes de réponse, etc.

Les changements visibles directement dans les notifications email

Les notifications de fin de crawl existaient déjà, mais leur contenu s'enrichit dans cette version. L'email inclut désormais un tableau récapitulatif de tous les problèmes détectés lors du crawl.

Si la comparaison automatique est activée, l'email affiche en plus un tableau de comparaison qui met en évidence les évolutions entre les deux derniers crawls : pages indexables devenues non indexables, balises title disparues, pics de pages en erreur, etc. L'idée est de permettre une surveillance continue du site sans avoir à ouvrir le logiciel à chaque fois.

L'envoi d'exports en pièces jointes par email

Toujours dans la logique d'automatisation, il est maintenant possible de configurer l'envoi automatique d'exports en pièces jointes à la fin d'un crawl. Cette option se paramètre dans la section « Notifications » d'une tâche planifiée.

Le principe est simple : on choisit un destinataire, on sélectionne le rapport souhaité (liens cassés, résumé des problèmes, etc.) et l'export arrive automatiquement dans sa boîte mail après chaque crawl. Les fichiers sont envoyés compressés. Si la pièce jointe dépasse la limite de l'hébergeur mail, l'email signale l'erreur au destinataire.

La détection des liens non crawlables

Le SEO Spider peut désormais identifier des types de liens présents dans le HTML mais qui ne respectent pas les bonnes pratiques de liens telles que définies par Google. Ces liens sont qualifiés de non crawlables dans l'interface.

Ils apparaissent dans l'onglet Links via le nouveau filtre « Pages With Uncrawlable Internal Outlinks », ainsi que dans une nouvelle colonne « Link Crawlability » dans l'onglet Outlinks. Un export en masse est disponible via Bulk Export > Links > Pages With Uncrawlable Internal Outlinks.

Pour que cette détection fonctionne, l'option « Store » doit être activée dans Config > Spider > Crawl.

Une précision importante de Screaming Frog : leurs recherches indiquent que Google tente en réalité de crawler tout ce qui ressemble à un lien dans le HTML, y compris ces formats non conventionnels. Ces liens sont donc souvent « crawlables » en pratique. Ils restent néanmoins déconseillés, car ils ne sont pas traités de la même façon qu'un lien HTML standard pour la transmission des signaux de lien.

Les statistiques d'utilisation

Une petite nouveauté légère, mais amusante : il est maintenant possible de consulter ses propres statistiques d'utilisation du logiciel via Help > Usage Stats. On y trouve le temps passé à crawler, le nombre de crawls lancés, etc.

Ces données sont stockées localement sur la machine. Screaming Frog reconnaît eux-mêmes que l'utilité pratique est limitée, mais que ça peut donner une idée concrète de la valeur tirée de l'outil au quotidien.

Les autres améliorations de la version 24.0

La mise à jour embarque également une série de changements plus ciblés :

• Nouvelles versions Linux Arm64 : deux nouveaux packages sont disponibles pour les architectures Arm, sous Ubuntu et Fedora.
• Liens syntaxiquement invalides : une nouvelle option « Crawl Invalid Links » sous Config > Spider > Crawl permet de traiter et signaler les URLs malformées (comme hppts://example.com). Ces URLs apparaissent généralement sous Response Codes > No Response.
• Ignorer les exports vides : dans les paramètres de sortie des crawls planifiés et dans Bulk Export > Multi Export, il est désormais possible de ne pas exporter les rapports qui ne contiennent aucune donnée. Ils n'apparaîtront pas non plus en pièce jointe dans les emails.
• Métriques Ahrefs par pays : un onglet Options fait son apparition dans l'intégration Ahrefs, avec des filtres pour ajuster les données par pays et par type de volume (mensuel ou moyen).
• Clusters de contenu filtrables : dans le graphe des clusters de contenu, il est maintenant possible de cliquer sur les légendes pour afficher ou masquer des catégories.
• Validation des modèles IA en temps réel : lorsqu'un modèle est spécifié dans une intégration IA, le SEO Spider vérifie désormais s'il existe bien dans la liste des modèles disponibles du fournisseur. Si ce n'est pas le cas, une alerte est affichée et il est possible d'en choisir un actif. Une nécessité, compte tenu de la vitesse à laquelle les modèles IA sont dépréciés ou renommés.
• Prompt système global pour les intégrations IA : dans l'onglet "Advanced" de chaque intégration IA, il est possible de définir un prompt système pour encadrer le comportement du modèle (rôle, contraintes, personnalité, etc.) de façon cohérente sur toutes les interactions.
• Affichage des tokens consommés : la consommation de tokens est maintenant visible dans le dialogue « Account Information » pour chaque fournisseur IA connecté.
• Intégration Ollama : l'intégration Ollama supporte désormais la génération d'images et dispose d'un paramètre « Request Timeout » réglable dans l'onglet avancé.
• Retour au nom "Data Studio" : Screaming Frog a rebaptisé « Looker Studio » en « Data Studio » dans ses rapports automatisés, conformément aux derniers changements de nom opérés par Google.
• Mise à jour vers Java 25 : le SEO Spider tourne désormais sur Java 25.

Vous souhaitez confier l'audit SEO de votre site à des experts ?

1. 1Site web
2. 2Nombre d’URL
3. 3Votre besoin
4. 4Vos spécificités
5. 5Vos coordonnées
6. 6Estimation

Site web

Répondez à 4 questions rapides. Vous obtiendrez une estimation d’un audit SEO sur-mesure.

Renseignez l’URL de votre site web

Suivant

Nombre d’URL

Indiquez l’ordre de grandeur des pages de votre site (indexées ou à analyser). Cela nous aide à dimensionner l’audit.

Nombre d’URL

1 à 1 000 pages 1 000 à 10 000 pages 10 000 à 100 000 pages Plus de 100 000 pages

PrécédentSuivant

Votre besoin

L’analyse technique & l’indexation sont incluses. Ajoutez les axes que vous souhaitez approfondir.

Vos priorités

Audit complet
Sélectionne tous les axes (Contenu, Maillage interne, Netlinking, Optimisation IA) Contenu
qualité, E-E-A-T, cannibalisation Maillage interne
silos, profondeur, pages clés Netlinking
profils, ancres, risques Optimisation IA
IA Overviews, assistants

PrécédentSuivant

Vos spécificités

Précisez d’éventuelles particularités de votre site. Ces éléments peuvent influencer la conduite de l’audit (facultatif).

Spécificités

E-commerce Google Actu Google Discover Multilingue / multi-pays

PrécédentSuivant

Vos coordonnées

Pour obtenir une estimation du coût de votre audit, merci de renseigner vos coordonnées ci-dessous.

Entreprise

Prénom Nom

Téléphone E-mail

Votre site (ne pas remplir)

Précédent Envoyer

Vos informations servent uniquement à vous recontacter et à établir un devis personnalisé. Elles ne sont ni revendues ni utilisées à des fins publicitaires. Vous pouvez exercer vos droits (accès, rectification, suppression) à tout moment. En savoir plus dans notre politique de confidentialité.

Merci, votre demande a bien été envoyée.

Un consultant vous recontacte très prochainement pour affiner votre projet.

Estimation de votre audit

€ HT

Votre sélection

Inclus : audit technique & indexation, synthèse priorisée, plan d’actions classé par impact/effort, restitution 60 min et recommandation sur un Notion personnalisé.

Réserver un créneau Modifier ma simulation Recommencer la simulation

---

L’expertise Abondance c’est :

+2 000 audits Réalisés pour des PME, ETI et grands comptes.

15+ ans d’expérience Consultants seniors & ambassadeurs Abondance.

Méthode éprouvée Feuille de route priorisée, actions concrètes.

L’article "Screaming Frog SEO Spider 24.0 : intégration de l’IA et automatisation accrue" a été publié sur le site Abondance.

Depuis octobre 2023, Google a achevé la bascule vers le mobile first indexing pour la quasi-totalité du web. Ce que voit Googlebot Smartphone sur la version mobile de votre site est ce qui sert à indexer et à classer vos pages, y compris pour un internaute sur ordinateur. La transition n’est plus à venir : elle est terminée. La vraie question n’est donc plus « quand » mais « qu’est-ce que Google voit réellement quand il crawle votre site en mobile ». Et la réponse, sur beaucoup de sites, réserve des surprises. Le mobile first indexing, le standard d’indexation de Google Ce que Google indexe vraiment aujourd’hui Le mobile first indexing signifie que Google utilise la version mobile de vos pages, explorée avec l’agent Googlebot Smartphone, comme source principale pour l’indexation et le classement. Le contenu, les balises, les liens internes, les données structurées pris en compte sont ceux de la version mobile. La version desktop n’est plus la référence : elle devient secondaire. Concrètement, si un bloc de texte, un lien ou une image existe sur votre version desktop mais disparaît sur mobile, Google ne le voit pas. Il ne l’indexe pas. Il ne le classe pas. Cette nuance change tout : un site qui semble complet sur grand écran peut être amputé aux yeux de Google s’il a été allégé pour le mobile. Une transition terminée, pas une menace future Google a officialisé l’achèvement de la bascule en octobre 2023, après près de sept ans de déploiement progressif amorcé en 2016. Depuis juillet 2024, la règle est encore plus stricte : un site dont le contenu n’est pas accessible du tout sur mobile n’est tout simplement plus indexable. Le mobile first indexing est ainsi devenu le mode de fonctionnement unique du crawl Google. Il faut donc arrêter de présenter le sujet comme une évolution à anticiper. C’est le présent. Les sites encore pénalisés ne le sont pas parce qu’ils n’ont pas « migré », mais parce que leur version mobile est incomplète, lente ou mal explorée. Google impose, on dispose : la règle est posée, le terrain de jeu reste le vôtre. Googlebot Smartphone : qui crawle votre site L’exploration se fait avec Googlebot Smartphone, un agent qui simule un appareil mobile récent. C’est lui qui découvre, rend et évalue vos pages. Le crawl avec l’agent desktop n’a pas totalement disparu : Google continue de l’utiliser ponctuellement pour vérifier certaines relations entre versions. Mais l’index, lui, se construit sur ce que voit l’agent smartphone. Cette mécanique a une conséquence directe : tout ce qui bloque ou dégrade le rendu mobile (ressources non chargées, scripts lourds, contenu masqué derrière une interaction) dégrade votre indexation. La version mobile n’est plus une vitrine secondaire ; c’est le cœur de votre SEO. Vérifier si votre site est concerné et l’auditer Le rapport d’inspection d’URL dans Search Console La première vérification est gratuite et prend deux minutes. Dans la Google Search Console, l’outil d’inspection d’URL indique, pour chaque page, l’agent utilisateur d’exploration : « Googlebot Smartphone » confirme que la page est traitée en mobile first indexing. C’est le cas de la quasi-totalité des sites aujourd’hui. L’inspection d’URL va plus loin que ce simple statut. La fonction « Tester l’URL en direct » puis « Voir la page explorée » affiche le HTML rendu et la capture d’écran tels que Googlebot les obtient. C’est l’outil de vérité : si un contenu manque dans ce rendu, il manque dans l’index. Comparez ce rendu mobile à votre page desktop ; chaque écart est un signal d’alerte. Auditer la parité avec une lecture mobile réelle Au-delà de Search Console, l’audit consiste à regarder votre site comme le fait Googlebot. Ouvrez vos pages clés dans un navigateur en mode mobile (les outils de développement de Chrome simulent un appareil et un user-agent mobile). Désactivez le JavaScript pour voir le HTML brut, puis réactivez-le pour voir le rendu final. Comparez systématiquement avec la version desktop. Cette démarche relève d’un audit technique SEO structuré : on identifie les écarts, on les hiérarchise par impact, on corrige en priorité ce qui pèse le plus. Notre méthode d’audit SEO en 7 étapes intègre cette vérification de parité mobile comme un point de contrôle à part entière. Plus de datas, moins de blabla : on mesure l’écart avant de décider quoi corriger. La parité de contenu desktop / mobile, le point critique Le même contenu sur les deux versions C’est la recommandation centrale de Google : la version mobile doit contenir le même contenu principal que la version desktop. Texte, titres, images, vidéos, liens : si la version desktop le porte, la version mobile doit le porter aussi. Un site responsive bien construit respecte cette parité par défaut, puisqu’il sert le même HTML à tous les appareils. Le problème survient sur les sites qui allègent volontairement le mobile : moins de texte, moins de blocs, navigation simplifiée à l’extrême. Chaque élément supprimé sur mobile est un élément retiré de l’index. Un paragraphe riche en mots-clés présent uniquement sur desktop ne pèse plus rien dans le classement. Données structurées, balises meta et images La parité ne concerne pas que le texte visible. Les données structurées (Schema.org) doivent être présentes à l’identique sur la version mobile, avec des URL pointant vers les bonnes ressources mobiles. Les balises meta robots doivent être rigoureusement identiques : une balise noindex ou nofollow présente seulement sur mobile, souvent par erreur de configuration, suffit à désindexer une page entière. Les images suivent la même logique. Mêmes attributs alt, formats supportés, qualité suffisante, URL stables : Googlebot Smartphone doit pouvoir charger et comprendre vos visuels comme sur desktop. Un site qui sert des miniatures dégradées ou des images en lazy-load mal configuré sur mobile prive Google de signaux utiles, notamment pour Google Images. Contenu masqué derrière une interaction Sur mobile, les accordéons, onglets et blocs dépliables sont parfaitement acceptés par Google : le contenu présent dans le HTML est indexé même s’il est visuellement replié. La règle Brioude est simple : masquer pour la lisibilité, oui ; masquer en empêchant le chargement, non. La limite est claire : Google ne charge pas le contenu qui exige une action de l’utilisateur pour apparaître (un clic qui déclenche une requête, un défilement qui charge la suite via JavaScript sans le contenu dans le HTML initial). Si le contenu principal d’une page n’existe dans le code qu’après une interaction, Googlebot ne le verra pas. Le contenu stratégique doit être présent dans le HTML rendu, point. Les points de contrôle techniques à vérifier Ressources accessibles et exploration autorisée Googlebot Smartphone doit pouvoir accéder à toutes les ressources nécessaires au rendu : fichiers CSS, JavaScript, images, polices. Un fichier robots.txt qui bloque ces ressources empêche Google de rendre correctement la page mobile. Vérifiez que votre robots.txt est identique pour les deux versions et qu’il ne bloque aucune ressource de rendu. Sur les sites à URL distinctes (un domaine ou sous-domaine mobile séparé), les contrôles se multiplient : balises rel= »canonical » et rel= »alternate » cohérentes, redirections correctes, équivalence stricte du contenu. Le responsive design reste la configuration recommandée par Google, justement parce qu’il élimine ces sources d’erreur : une seule URL, un seul HTML, aucune divergence possible. Capacité serveur et fréquence de crawl Le passage au mobile first indexing peut modifier la fréquence et le volume d’exploration. Un serveur sous-dimensionné qui répond lentement ou renvoie des erreurs sous la charge de Googlebot voit son crawl ralenti, donc son indexation dégradée. La performance serveur n’est pas un détail technique isolé : c’est une condition d’indexation. Vérifiez aussi la cohérence des codes de réponse entre versions. Une page qui renvoie un code 200 sur desktop mais une erreur 404 ou 500 sur mobile envoie un signal contradictoire à Google. Les erreurs ne doivent jamais être spécifiques à la version mobile. Publicités et interstitiels intrusifs Google pénalise les interstitiels intrusifs sur mobile : pop-ups qui couvrent le contenu principal dès l’arrivée sur la page, bandeaux disproportionnés, fenêtres qui gênent la lecture. Une publicité trop envahissante dégrade l’expérience mobile et peut peser sur le classement. La densité publicitaire doit rester raisonnable et conforme aux standards de qualité. Les erreurs fréquentes qui plombent l’indexation mobile Alléger le contenu mobile « pour la performance » L’erreur la plus répandue : supprimer du texte et des blocs sur mobile au nom de la rapidité. Le raisonnement paraît logique, le résultat est contre-productif. Google indexe ce qu’il voit sur mobile ; un contenu allégé est un contenu désindexé. La bonne approche n’est pas de retirer du contenu, mais de mieux le structurer (accordéons, hiérarchie claire) tout en le gardant dans le HTML. Balises et métadonnées divergentes Balise title différente entre mobile et desktop, meta description absente sur mobile, balise robots noindex héritée d’un thème mal configuré, données structurées présentes seulement sur desktop : ces divergences sont invisibles à l’œil nu et catastrophiques pour le SEO. Elles se détectent uniquement en comparant méthodiquement les deux versions, balise par balise. Liens internes appauvris sur mobile Un menu mobile simplifié à l’extrême, des liens contextuels supprimés pour gagner de la place, un maillage interne réduit : Google évalue la structure de liens sur la version mobile. Si vos pages profondes ne sont reliées que depuis la version desktop, elles perdent en visibilité. Le maillage interne doit être aussi solide sur mobile que sur desktop. Confondre indexation mobile et simple rapidité Un site rapide n’est pas automatiquement bien indexé en mobile first. La vitesse compte, mais elle ne remplace pas la parité de contenu, l’accessibilité des ressources ou la cohérence des balises. Un site ultra-rapide avec un contenu mobile amputé restera mal classé. L’indexation mobile first est d’abord une question de ce que Google voit, ensuite une question de vitesse. Le lien avec les Core Web Vitals mesurés sur mobile Le mobile first indexing et les Core Web Vitals sont deux sujets distincts mais complémentaires. Le premier détermine ce que Google indexe ; les seconds mesurent la qualité de l’expérience sur les pages indexées. Et ces métriques sont évaluées en priorité sur l’expérience mobile. Trois indicateurs composent les Core Web Vitals en 2026. Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible ; le seuil « bon » est inférieur à 2,5 secondes. L’INP (Interaction to Next Paint), qui a remplacé le FID en mars 2024, mesure la réactivité de la page à chaque interaction ; le seuil « bon » est inférieur à 200 millisecondes. Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle ; le seuil « bon » est inférieur à 0,1. Selon le Web Almanac (2025), seules 62 % des pages mobiles atteignent un bon score LCP et 43 % des sites échouent encore au seuil INP. Sur mobile, ces métriques sont plus difficiles à tenir que sur desktop : connexion variable, processeur plus modeste, écran plus contraint. Une fois la parité de contenu assurée, optimiser vos Core Web Vitals sur mobile devient le levier suivant pour transformer une bonne indexation en bon classement. La méthode Brioude pour préparer votre site 1. Diagnostiquer ce que voit Googlebot Smartphone Avant toute correction, on établit un constat factuel. Inspection d’URL dans Search Console, rendu mobile comparé au desktop, lecture du HTML avec et sans JavaScript. L’objectif : lister précisément chaque écart de contenu, de balise et de ressource entre les deux versions. Pas d’intuition, des datas. 2. Restaurer la parité de contenu On corrige en priorité les écarts qui touchent le contenu stratégique : texte amputé, liens manquants, données structurées absentes, balises divergentes. Chaque élément remis sur la version mobile est un signal rendu à Google. La parité n’est pas un objectif esthétique, c’est la condition de base de l’indexation. 3. Sécuriser l’exploration et le rendu On vérifie que Googlebot Smartphone accède à toutes les ressources, que le robots.txt ne bloque rien d’utile, que les codes de réponse sont cohérents et que le serveur tient la charge de crawl. Sur un site à URL distinctes, on contrôle canonical, alternate et redirections. Quand c’est pertinent, on recommande le passage au responsive pour éliminer les sources d’erreur. 4. Optimiser l’expérience mobile dans la durée Une fois l’indexation sécurisée, on travaille les Core Web Vitals mobiles et la qualité d’expérience : vitesse, stabilité, réactivité, densité publicitaire maîtrisée. C’est l’étape qui transforme une indexation propre en gain de positions concret. La science du clic alliée à l’art de la conversion. Une indexation mobile maîtrisée, des positions qui suivent Le mobile first indexing n’est pas un chantier ponctuel à cocher une fois. C’est la réalité permanente de votre SEO : chaque nouvelle page, chaque refonte, chaque évolution de design doit être pensée pour ce que voit Googlebot Smartphone. Un site dont la version mobile est complète, explorée sans obstacle et rapide donne à Google tout ce dont il a besoin pour bien le classer. Un site dont le mobile est amputé ou bridé se prive de positions sans même le savoir. La bonne nouvelle : la grille de lecture est claire. Parité de contenu, accessibilité des ressources, cohérence des balises, performance mobile. Ces quatre piliers se vérifient, se mesurent et se corrigent. Les robots vous trouvent, les prospects vous choisissent : encore faut-il que les robots voient l’intégralité de ce que vous proposez. Brioude accompagne ses clients sur toute la chaîne, du SEO mobile à l’audit technique, jusqu’à l’optimisation des Core Web Vitals. Pour vérifier ce que Google voit réellement de votre site et poser les bases d’une indexation mobile solide, échangez avec notre équipe sur notre page contact.

L’article Mobile First Indexing : comment préparer votre site est apparu en premier sur Brioude.

L’article "Goossips SEO : API d’indexation" a été publié sur le site Abondance.