Le chunking : comment le LLM découpe votre contenu

Avant qu'un système RAG ne puisse rechercher et récupérer votre contenu, celui-ci doit être découpé en morceaux plus petits, appelés "chunks". Ce découpage, le chunking, détermine ce qu'une IA voit réellement de votre page au moment de répondre à une question : rarement l'article entier, presque toujours un ou quelques extraits isolés. Cette réalité surprend souvent les personnes habituées à raisonner en termes de "page" plutôt que de "passage", et c'est pourtant l'unité de base sur laquelle opèrent la plupart des systèmes RAG actuels. Comprendre ce mécanisme change profondément la façon d'écrire pour le GEO. Ce n'est pas un détail technique périphérique : c'est littéralement l'unité de travail à partir de laquelle une IA générative construit sa perception de votre contenu.

Pourquoi le contenu est découpé plutôt que traité en entier

Un LLM ne peut pas relire l'intégralité du web à chaque question posée, et même dans une architecture RAG, il n'est ni efficace ni nécessaire de traiter chaque page dans son ensemble. Les systèmes indexent donc le contenu à l'avance sous forme de blocs plus petits, souvent de quelques centaines de mots, stockés et rendus rapidement récupérables. Quand une question arrive, le système ne recherche pas "quelle page correspond le mieux", mais "quels chunks, pris individuellement, correspondent le mieux". C'est une différence essentielle avec la logique du référencement classique, qui évalue généralement une page entière. La taille de ces chunks varie selon les systèmes : certains découpages restent assez courts, de quelques phrases à un paragraphe, d'autres regroupent plusieurs paragraphes liés. Dans tous les cas, l'objectif reste le même : produire des unités suffisamment petites pour être précises, et suffisamment grandes pour rester compréhensibles.

Comment ce découpage est généralement réalisé

Dans une architecture RAG typique, le découpage s'appuie souvent sur la structure existante du document : les titres et sous-titres (balises Hn), les paragraphes, parfois une longueur maximale fixée à l'avance. Un contenu bien structuré, avec des sous-titres clairs qui annoncent le contenu de chaque section, facilite un découpage cohérent, où chaque chunk correspond à une unité de sens complète. La leçon Les balises Hn (H1, H2, H3) explique comment cette hiérarchie de titres, déjà utile pour le SEO classique, devient également un repère pour le découpage automatique du contenu par les IA. Un exemple concret : un article qui alterne de longs paragraphes sans sous-titre sur plusieurs centaines de mots offre beaucoup moins de repères pour un découpage propre qu'un article où chaque sous-titre H2 introduit une idée précise en trois ou quatre paragraphes courts.

Le problème des passages qui dépendent du contexte

Le risque principal du chunking, c'est qu'un extrait retiré de son contexte perde tout son sens. Un paragraphe qui commence par "cette méthode présente cependant une limite importante" est incompréhensible si le chunk ne contient pas l'explication de "cette méthode" évoquée juste avant, dans un autre bloc. De la même façon, un paragraphe qui utilise "il", "elle", ou "ce produit" sans jamais réintroduire le sujet dont il parle risque d'être mal interprété, ou simplement ignoré, une fois isolé de son environnement. Voici une illustration simple de ce problème. Un mauvais passage, dépendant du contexte : "Cette approche est cependant plus coûteuse. Elle reste néanmoins recommandée dans la plupart des cas." Un bon passage, autonome : "La migration vers un nouvel outil de facturation est généralement plus coûteuse à court terme qu'un maintien de l'existant, mais elle reste recommandée pour la majorité des petites entreprises en raison des gains de temps qu'elle procure sur la durée." Le second réintroduit le sujet, "la migration vers un nouvel outil de facturation", là où le premier suppose que le lecteur sait déjà de quoi "cette approche" parle. Le contenu rédigé pour un lecteur humain qui lit l'article dans l'ordre, du début à la fin, n'est pas toujours adapté à un système qui ne verra jamais qu'un fragment isolé.

Écrire des sections qui se comprennent seules

La conséquence pratique est qu'il faut écrire chaque section, chaque sous-titre, comme s'il pouvait être lu indépendamment du reste de l'article. Cela veut dire : réintroduire le sujet dont on parle même si cela crée une légère redondance avec le titre général, éviter les pronoms ambigus qui renvoient à une phrase lointaine, et faire en sorte que chaque section réponde clairement à la question posée par son propre sous-titre plutôt que de continuer une idée entamée plus haut. Cette exigence rejoint directement les principes détaillés dans la leçon Structurer un article pour le GEO, qui propose une organisation d'article pensée pour ce mode de lecture fragmentée.

Chunking et données structurées : deux mécanismes complémentaires

Le chunking se concentre sur le texte visible, mais il existe un mécanisme complémentaire pour aider les systèmes à comprendre le sens de vos pages : les données structurées Schema.org, qui décrivent explicitement la nature d'un contenu (un article, une question-réponse, un produit) dans un format lisible par les machines. La leçon Les données structurées Schema.org : comprendre explique comment ce balisage complémentaire aide les systèmes automatiques à mieux interpréter le contenu, même une fois celui-ci découpé en fragments.

Retenez l'essentiel : votre contenu ne sera presque jamais lu dans son intégralité par une IA au moment de répondre à une question. Il sera vu par fragments. Écrire des sections autonomes, capables de se suffire à elles-mêmes, est donc une des compétences les plus concrètes à développer pour le GEO. À l'inverse d'un exercice de style, ce n'est pas non plus une compétence purement technique : c'est avant tout une discipline d'écriture, proche de celle qu'on demande à un journaliste de rédiger un article dont chaque paragraphe pourrait fonctionner comme une brève indépendante.