Chunking : ce que c’est, et ce que Google dit d’ignorer

Le chunking traverse une année étrange. Une vague de conseils SEO le présente comme la clé de la visibilité dans l’IA. Les recommandations officielles de Google le classent désormais parmi les tactiques à ignorer. Les deux camps utilisent le même mot pour désigner des choses différentes, et c’est exactement comme ça qu’un vrai concept d’ingénierie s’est transformé en tactique de contenu fragile.

Cette page remet les choses en ordre : ce que le chunking signifie réellement dans la recherche par IA, ce que Google a dit et voulu dire, quelles affirmations résistent à une vérification des faits, et ce qu’il faut faire de vos pages à la place.

Ce qu’il faut retenir

• Le chunking est une étape technique du pipeline RAG, côté moteur, et non un réglage que l’auteur d’une page peut activer : Google le liste explicitement parmi les tactiques à ignorer dans son guide d’optimisation pour l’IA générative, mis à jour le 29 juin 2026.
• Aucune taille de chunk précise (passages de 100 à 300 mots, blocs de 500 tokens) n’est reliée par une étude publiée à un gain de citation IA : chaque chiffre provient d’un contexte différent (configuration RAG, featured snippets de Google, seuils de lisibilité), pas d’une mesure de recherche IA.
• En France, le seul concurrent direct sur ce sujet (Abondance.com, août 2025) présente le chunking comme un débat d’experts non tranché, sans jamais citer la position officielle de Google ni la déclaration de Danny Sullivan de janvier 2026 : cet article est l’un des premiers en français à intégrer les deux.
• Même le chunking automatique échappe à votre contrôle, jusque dans le navigateur : le DocumentChunker de Chrome peut découper vos pages en passages d’environ 200 mots, sans vous demander votre avis.
• Ce qui reste utile n’est pas un format de découpage mais une discipline d’écriture : réponse en premier, sections autonomes, une idée par passage ; les mêmes principes qui faisaient un bon rédacteur avant l’IA.

Ce que le chunking signifie vraiment (trois notions différentes)

Le chunking (ou découpage de contenu) recouvre trois notions différentes selon qui en parle, et la plupart des mauvais conseils viennent d’une confusion entre les trois.

Dans l’ingénierie de la recherche par IA, le chunking est une étape de pipeline : un système de génération augmentée par récupération (RAG) découpe les documents en chunks, convertit chaque chunk en embedding, puis récupère les chunks les plus pertinents quand une requête arrive. C’est le système qui fait le découpage. L’auteur du document n’a pas voix au chapitre.

En UX et en psychologie, le chunking concerne la mémoire de travail humaine. Le Nielsen Norman Group le définit comme le fait de découper le contenu en petites unités distinctes pour que les utilisateurs puissent le traiter, en s’appuyant sur les travaux de George Miller (1956), selon qui la plupart des gens retiennent environ sept chunks en mémoire à court terme. C’est ce sens qui domine la majorité des résultats Google pour ce terme, et il n’a rien à voir avec la recherche par IA.

Il existe ensuite un troisième sens : le chunking à des fins d’AEO et de GEO, la version tactique. « Découpez votre contenu en morceaux adaptés à l’IA et les moteurs vous repéreront. » Cette version emprunte le vocabulaire du premier sens et la crédibilité du deuxième, et c’est celle que Google demande désormais explicitement aux éditeurs d’ignorer.

Cet article traite du premier et du troisième sens : ce que le chunking fait vraiment dans la recherche par IA, et pourquoi la version tactique ne survit pas à l’épreuve des faits.

Comment le chunking fonctionne vraiment dans la recherche par IA

Quand un moteur de recherche IA traite votre page, le découpage se fait du côté du moteur, pas du vôtre. Ce découpage côté moteur est le sens originel du chunking en IA : le pipeline récupère votre contenu, le découpe en chunks, convertit chaque chunk en embeddings vectoriels et les stocke dans un index. Au moment de la requête, le système récupère les chunks qui correspondent le mieux à la question, souvent après avoir éclaté la requête en plusieurs sous-requêtes. Nous détaillons tout le processus de récupération dans notre analyse du fonctionnement de la recherche IA.

Les manettes de l’ingénieur, pas les vôtres

Ce qui compte dans ce débat : la stratégie de chunking est un réglage d’ingénierie, pas une propriété de votre page. La documentation d’Amazon Bedrock montre à quoi ça ressemble concrètement. Un développeur qui construit une base de connaissances choisit entre chunking à taille fixe, chunking sémantique, chunking hiérarchique, ou pas de chunking du tout, puis ajuste le nombre de tokens et les pourcentages de recouvrement (ou « chevauchement »). Par défaut, Bedrock découpe le texte en chunks d’environ 300 tokens en respectant les limites de phrase. Ce sont les manettes de l’ingénieur. Vous n’y touchez jamais.

Le même constat vaut côté navigateur, le plus souvent sans que vous le sachiez. Le chercheur Dan Petrovic a analysé le code source de Chrome et documenté un composant nommé DocumentChunker (third_party/blink/renderer/modules/content_extraction/document_chunker.h), qui découpe automatiquement chaque page en passages sémantiques d’environ 200 mots pour les modèles embarqués du navigateur. Ce découpage se base sur la structure HTML, tourne côté navigateur, et ne demande votre avis à aucun moment.

Les recherches sur le chunking RAG traitent la question de la même façon : comme un compromis système pour le responsable du pipeline. Une analyse systématique des stratégies de chunking (Bennani et Moslonka, prépublication, janvier 2026) a fait varier la méthode de découpage, la taille des chunks et le recouvrement sur une configuration RAG standard, et a constaté que le recouvrement des chunks n’apportait aucun bénéfice mesurable tout en augmentant le coût d’indexation. Le point notable tient au public visé : des ingénieurs qui déploient des systèmes de récupération. Rien dans ce papier ne suggère que les auteurs de documents devraient écrire différemment.

Il n’existe pas de chunk universel

Voici la nuance à retenir. Les ingénieurs choisissent parmi de nombreuses stratégies de découpage : taille fixe, fenêtre glissante, récursif, sémantique, tardif (late chunking). Certaines tiennent compte de la structure du document : le chunking sensible à la structure et au HTML découpe au niveau des titres et des sections, le chunking sémantique repère les changements de sujet. Une page bien organisée peut donc mieux interagir avec certains pipelines. Mais quelle stratégie un moteur donné utilise, à quelle taille, avec quel recouvrement : tout cela vous est invisible et varie d’un moteur à l’autre. Il n’y a pas de chunk universel, donc rien de stable à optimiser.

L’astuce que Google vient de vous dire d’ignorer

Google l’a écrit noir sur blanc. Son guide d’optimisation pour les fonctionnalités d’IA générative, mis à jour le 29 juin 2026, liste le « chunking de contenu » parmi les tactiques que les éditeurs peuvent ignorer : « Il n’y a aucune obligation de découper votre contenu en tout petits morceaux pour que l’IA le comprenne mieux. Les systèmes de Google sont capables de saisir les nuances entre plusieurs sujets sur une page et d’afficher la partie pertinente aux utilisateurs. » Si vos pages sont longues et couvrent plusieurs sujets, ce n’est pas un défaut à corriger.

Le chunking figure dans cette liste de tactiques à ignorer, aux côtés des fichiers llms.txt, de la réécriture spécifique à l’IA, et de l’accent excessif sur les données structurées. Le même guide, déjà examiné dans notre test du balisage schema pour la recherche IA, s’applique ici : Google indique que des tactiques comme le chunking, les fichiers texte IA superflus et les schémas spécifiques à l’IA générative ne sont pas nécessaires ; les fondamentaux classiques du SEO restent d’actualité.

Ce n’était pas une simple retouche de documentation isolée. Sur le podcast Search Off the Record de janvier 2026, Danny Sullivan, de Google, a abordé les conseils de « découpage en petits morceaux » en des termes inhabituellement directs : « Donc on ne veut pas que vous fassiez ça. J’en ai parlé avec des ingénieurs. On ne veut pas que vous fassiez ça. Vraiment pas. » Selon le compte-rendu de Search Engine Land, il a ajouté que Google ne veut pas que les éditeurs produisent une version de leur contenu pour le LLM et une autre pour le web, et que les systèmes de classement s’améliorent en continu pour récompenser un contenu écrit pour des humains.

En France, le débat existe déjà, et il ignore la position de Google

La question divise aussi le SEO francophone, mais sur la base d’éléments différents. Le site Abondance, référence du SEO français, a publié en août 2025 un article présentant le chunking comme une pratique qui « divise les experts du search ». Côté sceptiques : Nikki Pilkington, pour qui ce que le GEO appelle chunking n’est que le SEO classique sous un nouveau nom ; Despina Gavoyannis, qui rappelle qu’on ne contrôle pas la façon dont Google, ChatGPT ou Perplexity découpent un contenu ; Dan Petrovic, qui cite justement le DocumentChunker de Chrome comme preuve que ce découpage échappe à l’auteur. Côté partisans : Philippe Yonnet, fondateur d’Aposition et l’une des voix les plus respectées du SEO français, pour qui des chunks autonomes de 150 à 300 mots maximisent les chances d’être repris par des systèmes RAG comme Perplexity ou Bing Copilot ; Aishwarya Srinivasan, qui ajoute qu’un mauvais découpage donne des résultats non pertinents.

L’argument de Philippe Yonnet mérite d’être pris au sérieux, pas balayé : il a raison de dire que des passages autonomes et bien construits aident un système RAG à récupérer votre contenu. Mais l’article d’Abondance ne cite à aucun moment une position officielle de Google sur le sujet, et il précède de plusieurs mois la déclaration de Danny Sullivan et le guide Google que nous venons de citer. La réponse qui tient la route face à Yonnet reste celle du reste de cet article : aucun moteur ne publie ses réglages de chunk, donc « aider un système RAG à récupérer votre contenu » ne débouche encore sur aucune consigne d’écriture concrète. Et le DocumentChunker de Chrome, cité dans le même article par Dan Petrovic, illustre parfaitement ce point : même le découpage automatique côté navigateur échappe à l’auteur.

D’où vient donc cette tactique ? L’origine la plus probable passe par les tutoriels RAG. À mesure que le chunking s’imposait comme concept d’ingénierie IA, son vocabulaire a migré vers les conseils SEO, où « le pipeline découpe les documents en chunks » est devenu « vous devriez découper votre page en chunks ». Les prestations de restructuration facturées ont fait le reste, transformant un détail d’implémentation interne en livrable payant. Une chronique de Léa Pétralie, responsable de Black Pepper chez l’agence française CyberCité, l’illustre bien : elle raconte avoir d’abord rejeté le chunking à cause de pratiques commerciales qu’elle jugeait abusives, des agences facturant plus cher un contenu prétendument « compatible GEO », avant de s’y rallier sur le plan sémantique. Qu’on partage sa conclusion finale ou non, son objection de départ décrit très fidèlement la dynamique qui nous intéresse ici : un réglage technique interne devenu prestation facturable.

Pour être clairs sur notre position, puisque geotoolbox vend des outils de mesure de visibilité dans l’IA : vérifier comment les systèmes d’IA traitent réellement vos pages reste un vrai travail. Restructurer des pages pour respecter des specs de chunk qu’aucun moteur ne publie relève, à nos yeux, d’une taxe sur la confusion.

Les chiffres de taille de chunk que personne ne peut relier à l’IA

Les conseils sur le chunking s’accompagnent souvent de chiffres étrangement précis. Extraits d'un guide SEO largement partagé et de ses équivalents :

• Limitez les passages à 100-300 mots
• Visez des chunks de 500 tokens
• Construisez des chunks « macro » de 300-800 mots et des chunks « micro » de 100-200 mots
• Placez un titre tous les 200-300 mots
• Les moteurs extraient des passages de 40-60 mots

Essayez de relier l’un de ces chiffres à une étude sur la recherche IA, et vous n’y arriverez pas. Nous n’avons trouvé aucune preuve publiée reliant ces chiffres précis à des gains de citation IA. Ce qu’on trouve à la place, c’est du recyclage : des chiffres réels sortis de leur contexte. Les comptages de tokens sont des valeurs par défaut de documentation RAG, des réglages d’un système que l’éditeur ne fait pas tourner. Le chiffre de 40-60 mots vient d’études sur les featured snippets qui mesuraient ce que Google affiche dans un encadré, pas ce qu’un système d’IA préfère récupérer. La règle de fréquence des titres reprend le seuil de lisibilité qu’un plugin SEO très populaire signale depuis des années.

En France, cette confusion prend un visage précis. Plusieurs articles francophones sur le chunking, notamment sur neper.fr et frenchweb.fr, citent « l’étude de Princeton de 2024 » comme preuve d’un gain de visibilité IA de 27 à 41 %, avec parfois une réplication à environ 15 % attribuée à la consultante Marie Haynes. L’étude existe bel et bien : c’est le papier « GEO: Generative Engine Optimization » (Aggarwal, Murahari, Rajpurohit, Kalyan, Narasimhan, Deshpande : Princeton, Georgia Tech, IIT Delhi, présenté à KDD 2024, arXiv:2311.09735), et son chiffre réel avoisine bien les 40 %. Mais l’intervention testée n’est pas le chunking : ce sont l’ajout de statistiques, de citations et de sources. Le papier ne teste ni le découpage en passages courts, ni le raccourcissement du contenu. Le chiffre est réel ; son attribution au chunking ne l’est pas.

Même le seul benchmark bien documenté du domaine va dans le sens contraire. NVIDIA a testé des stratégies de chunking sur cinq jeux de données et a trouvé que le chunking au niveau de la page entière, qui traite toute la page comme unité de récupération, obtenait la précision de réponse moyenne la plus élevée (0,648) de tous les réglages testés. C’est un benchmark pour des ingénieurs qui déploient des systèmes RAG internes ; les éditeurs web ne sont pas son public, et les réglages de NVIDIA varient selon le corpus et le type de requête. Mais notez ce que ça implique : dans le mieux documenté des tests disponibles, ce sont les gros chunks qui gagnent. Le conseil de micro-fragmentation est contredit par le type de preuve même qu’il aime invoquer.

Et sous tout ça se cache la tokenisation. L’expérience de Mark Williams-Cook sur un schéma invalide a montré que des assistants IA lisent sans problème du JSON-LD délibérément corrompu : les LLM exploitent le texte visible, même dans un balisage cassé. Difficile, dès lors, d’affirmer que le schéma détermine directement les citations IA. Ça ne veut pas dire que les moteurs n’analysent jamais les données structurées. Sa remarque de fond est exactement ce dont ce débat a besoin : « Soyez intransigeants sur le niveau de preuve exigé. »

D’après notre expérience du suivi des pages citées par les moteurs IA chez geotoolbox (une observation tirée de nos données de suivi, pas une étude contrôlée), les pages qui gagnent ne sont pas celles qui atteignent un objectif de nombre de mots. Ce sont celles où le passage récupéré, quel que soit le point de coupe, contient une réponse complète, précise et sourcée. Miser sur les chiffres, c’est optimiser le mauvais niveau.

Ce que les preuves confirment vraiment

La lecture honnête n’est pas « le chunking est bidon ». La récupération est bien réelle, et les réponses IA s’appuient souvent sur des informations précises tirées de pages, de sections ou de passages récupérés. La question est de savoir quelles affirmations à ce sujet tiennent la route : voici le débat sur le chunking classé par niveau de preuve.

Remarquez que les lignes « confirmées » décrivent le comportement du moteur et les propriétés de l’écriture, tandis que tout ce qui est rejeté décrit des tentatives de contrôler le moteur. C’est le fil conducteur de tout ce sujet.

Ça résout aussi la contradiction apparente qui sème la confusion : Google qui dit « ne découpez pas » et des systèmes d’IA qui récupèrent bel et bien des passages sont deux affirmations vraies en même temps. Le moteur découpe. Vous ne pouvez pas le faire à sa place. Ce que vous pouvez faire, c’est écrire des passages qui tiennent la route, peu importe où tombe la lame.

Une précision supplémentaire, parce qu’elle piège même les lecteurs attentifs : des équipes en entreprise ajustent réellement le chunking pour leurs propres bases de connaissances internes, et des fournisseurs publient des recommandations à ce sujet. Ces conseils s’adressent aux responsables du pipeline : une entreprise qui héberge son propre RAG interne, par exemple avec Mistral et OVHcloud, possède réellement ses réglages de chunking. Le web public, lui, relève du pipeline de quelqu’un d’autre, les réglages varient d’un moteur à l’autre, et aucun d’eux ne publie ses manettes.

Ce qui survit : une structure utile, sans l’astuce

Une fois écarté le folklore des tailles de chunk, il reste une courte liste d’habitudes structurelles qui tiennent la route :

• Des ouvertures qui répondent d’abord, où la première phrase sous un titre répond à ce titre
• Des sections autonomes qui gardent leur sens une fois sorties de la page
• Des titres qui décrivent ce que la section dit vraiment
• Une idée par passage
• Des tableaux et des listes numérotées là où les faits sont réellement comparatifs ou séquentiels, parce que comparaisons et enchaînements survivent mieux à l’extraction sous forme de structure que sous forme de prose

Voici la différence en un avant-après. Avant : « Comme on l’a vu plus haut, le même problème touche les documents plus longs. » Après : « Le chunking à taille fixe échoue aussi pour les contrats longs, parce que les limites de clause s’alignent rarement sur les fenêtres de tokens. » La première phrase meurt dès qu’un pipeline la sort de la page ; la seconde tient bon partout où elle atterrit.

Ces habitudes survivent pour une raison précise : ce sont des propriétés de l’écriture, pas des réglages visant le chunker d’un moteur en particulier. Un passage autonome fonctionne, que le pipeline découpe à 300 tokens ou traite la page entière, parce qu’aucun point de coupe ne laisse le lecteur, humain ou modèle, avec un fragment qui dépend d’un texte qu’il ne peut pas voir.

C’est d’ailleurs pour ça que c’était déjà un bon conseil avant l’existence de la recherche IA. Les rédacteurs en chef poussent la structure réponse-en-premier depuis des décennies, parce que les lecteurs parcourent le texte en diagonale.

Résultat : vous n’avez pas besoin d’un processus de chunking. Vous avez besoin de savoir-faire rédactionnel, et nous l’avons déjà couvert en détail : notre guide sur l’écriture de passages que les LLM citent traite le travail au niveau de la phrase, et le guide de restructuration réponse-en-premier explique comment reprendre des pages existantes section par section.

En toute franchise : personne n’a publié de données avant-après sur des projets de restructuration, donc quiconque affirme qu’un reformatage garantit un gain de citations avance sans preuve.

Mesurer plutôt que deviner

Le débat sur le chunking est en réalité le symptôme d’une habitude plus large : adopter des tactiques dont on ne peut pas observer l’effet. Vous ne verrez jamais où un moteur a coupé votre page. Vous pouvez voir s’il la cite.

Suivez les citations sur un ensemble de pages avant et après une réécriture, en comparant à des pages laissées telles quelles. Gardez cette réserve en tête : ce sont des données d’observation, et le terrain bouge sous vos pieds à mesure que les moteurs évoluent, donc traitez tout mouvement comme un signal plutôt que comme une preuve. Ça reste mieux que d’optimiser un niveau qu’on ne peut pas du tout observer. Et être cité sans obtenir de clics pose son propre problème de mesure, qu’on couvre dans notre guide sur le suivi de la visibilité IA.

C’est la vérification à faire avant tout projet de restructuration. Le Content Analyzer de geotoolbox attribue à vos pages une note de citabilité et de lisibilité par l’IA, construite sur les signaux qui survivent au tableau de preuves de cet article : capsules réponse-en-premier, sections autonomes, données sourcées, vrais tableaux. Corrigez les pages avec un défaut mesurable plutôt que de tout reformater selon des specs relevant du folklore. Si le débat sur le chunking refait surface sur le Slack de votre équipe, un audit de vos propres pages citées et non citées y met fin plus vite qu’un énième avis.

Foire aux questions

Est-ce que les recommandations de Google s’appliquent aussi à ChatGPT et Perplexity ?

Le guide de Google reflète la position de Google, y compris pour les AI Overviews et le Mode IA (AI Mode), qui arrivent en France par vagues depuis fin juin 2026, avec une généralisation attendue autour du 23 septembre 2026. Aucun autre moteur n’a publié de recommandation équivalente. L’argument de mécanisme se généralise quand même : ChatGPT et Perplexity font tourner leurs propres pipelines de récupération avec leurs propres réglages de chunking non publiés, donc il n’existe toujours pas de spec sur laquelle caler votre rédaction. Ce qui diffère d’un moteur à l’autre, c’est quelles pages ils récupèrent et citent, pas votre capacité à contrôler leurs points de coupe.

Est-ce que Google pénalise le contenu chunké ?

Non. Le guide de Google dit que le chunking est inutile, pas nuisible, et des sections courtes ne posent pas de problème de classement. Le vrai dommage est ailleurs : des pages découpées en fragments pour satisfaire un extracteur imaginaire se lisent moins bien pour des humains, et l’avertissement de Danny Sullivan visait précisément le fait de publier un appât pour machines plutôt que d’écrire pour des gens.

Dois-je réécrire mes pages existantes pour corriger leur chunking ?

Pas comme un projet de chunking. Aucune donnée avant-après n’existe sur le re-découpage de pages ; la preuve publiée la plus proche, l’étude de référence sur le GEO, a testé l’ajout d’éléments comme des statistiques, des citations et des sources, plutôt qu’un reformatage de l’existant. Partez de la mesure : protégez les pages qui gagnent déjà des citations IA, puis corrigez celles où la réponse à la question du titre est vraiment enterrée. Une réponse enterrée est un vrai défaut ; une section de 400 mots n’est pas un défaut en soi.

Qu’est-ce que le chunking sémantique ?

Une technique de pipeline qui découpe les documents aux frontières de sujet détectées par embeddings, plutôt qu’à des comptages de tokens fixes. Amazon Bedrock le propose en option configurable, avec des tailles de buffer et des seuils de rupture fixés par qui construit la base de connaissances. Comme toute stratégie de chunking, ça tourne côté moteur ; vous n’avez aucun moyen d’y soumettre vos pages.

Qu’est-ce que le context chunking ?

Une famille de techniques de pipeline de récupération qui évitent aux chunks d’arriver orphelins : les chunkers sémantiques peuvent vectoriser chaque phrase avec un buffer de ses voisines, et les configurations hiérarchiques récupèrent un petit chunk enfant tout en donnant au modèle sa section parente plus large. Amazon Bedrock documente les deux. Dans les deux cas, la configuration revient à qui construit le pipeline ; un rédacteur n’y touche jamais.

Sources

• Google : Optimiser votre site pour les fonctionnalités d’IA générative de la recherche Google
• Search Engine Land : Google ne veut pas que vous créiez des morceaux de contenu tout petits
• Abondance : Chunking et SEO, la pratique qui divise les experts du Search
• IBM (fr-fr) : Qu’est-ce que le chunking agentique ?
• numerique.gouv.fr (Etalab/DINUM) : améliorer les performances des RAG, aperçu des techniques de chunking augmenté
• Dejan.ai : analyse technique du DocumentChunker de Chrome
• Ahrefs : le "chunk optimization" en SEO est surestimé
• Chris Green : comment la structure du contenu compte pour la recherche IA
• NVIDIA : trouver la meilleure stratégie de chunking pour des réponses IA précises
• Documentation AWS Bedrock : comment fonctionne le chunking de contenu pour les bases de connaissances
• Mark Williams-Cook : schema, LLM et le faible niveau de preuve exigé en GEO
• Bennani & Moslonka : analyse systématique des stratégies de chunking pour un question-réponse fiable (prépublication arXiv)
• Nielsen Norman Group : comment le chunking aide le traitement du contenu