En bref
Le RAG (Retrieval Augmented Generation) est le système qui permet à un LLM de consulter des sources externes avant de générer sa réponse. Sans RAG, le modèle répond uniquement depuis ce qu’il a mémorisé lors de son entraînement. Avec RAG, il cherche, récupère et cite des passages de documents pertinents en temps réel. Perplexity, ChatGPT Search, Google AI Overviews, Bing Copilot, tous utilisent une forme de RAG pour produire des réponses citées. Optimiser son contenu pour le RAG, c’est donc optimiser pour être sélectionné lors de l’étape de retrieval.
1. Comment fonctionne le RAG
Un système RAG suit un pipeline en quatre étapes :
- Indexation. Les documents (pages web, PDFs, bases de données) sont découpés en chunks (segments de 100 à 500 tokens) et transformés en vecteurs numériques (embeddings) qui représentent leur sens. Ces vecteurs sont stockés dans une base vectorielle.
- Retrieval. Quand un utilisateur pose une question, la requête est transformée en vecteur. Le système cherche les chunks dont le vecteur est le plus proche (« voisins sémantiques »). Il sélectionne les 3 à 10 plus pertinents.
- Augmentation. Les chunks sélectionnés sont injectés dans le contexte du LLM (« prompt »), avec la question de l’utilisateur. Le modèle reçoit donc : [question] + [passages sources].
- Génération. Le LLM produit une réponse qui s’appuie sur les passages injectés. Dans les moteurs qui affichent des citations (Perplexity, ChatGPT Search), chaque affirmation est associée à sa source.
Ce qui détermine si votre contenu est cité, c’est principalement l’étape de retrieval. Si votre chunk n’est pas sélectionné à cette étape, peu importe la qualité de votre page : elle n’existera pas dans la réponse finale.
2. Deux types de RAG à connaître
2.1 RAG web (temps réel)
Utilisé par Perplexity, ChatGPT Search, Bing Copilot et les surfaces avec retrieval actif. Le système effectue une vraie recherche web à chaque requête, crawle les pages dans les premiers résultats, chunk et évalue sémantiquement les passages en quelques secondes. La fraîcheur et l’indexabilité (robots.txt, rendu HTML) sont critiques ici.
2.2 RAG mémorisé (entraînement + index privé)
Utilisé par Claude, ChatGPT sans Search, Gemini (mode standard). Le LLM répond depuis sa mémoire paramétrique, les informations absorbées lors de l’entraînement. Ici, la visibilité dépend d’avoir été crawlé et inclus dans les données d’entraînement (Common Crawl, C4, données propriétaires). Impossible à contrôler directement, mais influencé par la popularité du site et la fréquence de crawl des bots d’entraînement.
Implication pratique : optimiser pour le RAG web (Perplexity, ChatGPT Search) donne des résultats plus rapides et mesurables qu’optimiser pour la mémoire des LLMs. C’est là que concentrer ses efforts en 2026.
3. Ce que le retrieval évalue sur votre contenu
3.1 La proximité sémantique
Le retrieval vectoriel mesure la distance cosinus entre le vecteur de la requête et le vecteur de chaque chunk. Plus un chunk est sémantiquement proche de la question, plus il a de chances d’être sélectionné.
Conséquence pratique : couvrir le vocabulaire exact de la requête dans votre contenu. Pas du keyword stuffing, mais un contenu qui utilise les mêmes termes et synonymes que les utilisateurs emploient pour chercher. Un article sur « l’optimisation des moteurs génératifs » qui n’emploie jamais le mot « GEO » ou « AEO » sera sous-optimal pour les requêtes incluant ces termes.
3.2 La densité informationnelle du chunk
Un chunk qui contient une seule information précise et complète est préféré à un chunk qui contient cinq informations vagues. Les systèmes RAG évaluent aussi la coherence interne du passage : un chunk qui saute entre trois sujets différents a un embedding diluté, moins précis sémantiquement.
3.3 L’autoportance
Un chunk injecté dans un prompt LLM est lu sans son contexte original. Si le passage dit « cette technique peut augmenter le taux de citation » sans nommer la technique, le LLM ne peut pas utiliser cette information. Chaque passage doit pouvoir être compris seul.
3.4 La précision factuelle
Les LLMs privilégient les passages qui contiennent des affirmations vérifiables : chiffres, dates, noms propres, urls, références à des standards ou normes. Une affirmation vague (« beaucoup de sites ») est moins exploitable qu’une affirmation précise (« selon l’étude Princeton GEO 2023, les contenus enrichis de citations sont 30 % plus souvent repris »).
4. Chunking : comprendre comment votre page est découpée
Les systèmes RAG découpent automatiquement les pages en chunks. Deux stratégies de chunking coexistent :
- Chunking fixe (par tokens). La page est coupée tous les N tokens (souvent 200–300), avec un overlap (chevauchement) de 20–50 tokens pour éviter de couper une phrase en plein milieu. Simple mais aveugle à la structure sémantique.
- Chunking structuré (par balises HTML / sections). La page est
découpée selon ses balises HTML (
h2,h3,p,li). Chaque section devient un chunk. Plus intelligent, et fortement favorisé par les systèmes qui lisent le HTML.
Implication pour le rédacteur : structurer son contenu en sections HTML claires (un h2 = un sujet = un chunk potentiel) favorise le chunking structuré et améliore la qualité des embeddings. Les tableaux, listes et blocs de code sont souvent traités comme des chunks autonomes, ce qui est un avantage si leur contenu est autoportant.
5. Les signaux que le RAG web ne lit pas (ou mal)
Certains éléments de page sont systématiquement ignorés ou mal traités dans le pipeline RAG web :
- Le contenu rendu uniquement en JavaScript : un SPA sans SSR retourne du HTML vide au crawler. Le chunk sera vide ou inutilisable.
- Les images sans alt text : une infographie avec des données clés mais sans texte alternatif est invisible au retrieval.
- Les vidéos embedées sans transcription : le contenu audio/vidéo n’est pas indexé par les crawlers de retrieval.
- Les PDF sans texte extractible : les PDF étant des scans ou des PDFs image ne sont pas parsables.
- Les menus de navigation : les systèmes RAG tentent de filtrer le contenu de navigation pour ne garder que le contenu éditorial, mais du contenu navédité intégré dans le body peut être capturé à tort.
6. Leviers concrets pour un contenu RAG-ready
6.1 Structurer en sections autoportantes
Chaque section h2/h3 de votre page doit pouvoir fonctionner comme un chunk indépendant (voir les principes de structure de contenu pour LLMs). Règle pratique : si vous pouviez copier ce paragraphe dans un tweet sans contexte, est-il encore compréhensible ? Sinon, ajoutez une phrase d’introduction qui nomme explicitement le sujet.
6.2 Privilégier les définitions en début de section
Les systèmes RAG fonctionnent mieux quand le sujet est annoncé en tête du chunk. Format préféré : « [Terme] est [définition complète]. Il fonctionne en [mécanisme]. Les principaux cas d’usage sont [liste]. » Ce pattern imite la structure d’une entrée encyclopédique, et les LLMs ont été entraînés sur des milliards d’entrées de ce type.
6.3 Inclure des données chiffrées sourcedées
Les passages avec des chiffres précis et des sources nommées ont un embedding plus discriminant (moins de pages web contiennent exactement ce chiffre), donc une meilleure position de retrieval sur les requêtes pertinentes. Format recommandé :
« Selon [source], [fait précis avec chiffre], mesuré en [année]. »
6.4 Ajouter un schema Article avec dateModified
Les systèmes RAG web consultent les métadonnées schema.org pour valider
la fraîcheur d’un document. Un article avec dateModified: 2026-04-22
sera préféré à un article non daté ou daté de 2021 sur les requêtes
avec intent d’actualité (type « en 2026 », « actuellement »).
6.5 Activer le rendu serveur (SSR)
Si votre site est en React, Next.js ou Vue, assurez-vous que le contenu
éditorial est rendu côté serveur et présent dans le HTML initial.
Un curl https://votre-site.fr/page/ doit retourner le texte
de la page, pas un DOM vide. C’est le test le plus simple pour vérifier
l’éligibilité RAG de votre page.
6.6 Couvrir les variantes terminologiques de votre sujet
Le retrieval sémantique ne repose pas que sur les mots exacts, mais la couverture des synonymes et acronymes améliore l’embedding global. Sur un article sur le RAG, inclure « retrieval augmented generation », « RAG », « search augmented generation », « base vectorielle », « embeddings » dans le même document améliore la proximité sémantique pour toutes ces requêtes.
7. RAG et glossaire : une combinaison puissante
Les pages glossaire sont des candidats idéaux pour le retrieval. Pourquoi ? Parce qu’elles contiennent exactement ce que le RAG cherche : une définition concise, autoportante, d’un terme précis. Une requête comme « qu’est-ce que le RAG » déclenchera quasi systématiquement le retrieval d’une page glossaire bien structurée plutôt qu’un long article.
Recommandation : créez une page glossaire dédiée pour chaque terme technique central de votre domaine. Chaque entrée glossaire devrait contenir : définition formelle, synonymes, différence avec les termes proches, et un exemple concret. Ce format est directement compatible avec le chunking structuré.
8. Mesurer l’éligibilité RAG de vos pages
Il n’existe pas d’outil « RAG score » natif. Les proxies les plus utiles :
- Test manuel Perplexity. Posez une requête très spécifique que votre page devrait couvrir. Apparaissez-vous dans les sources ? Si non, quelles sources sont citées et pourquoi sont-elles mieux structurées ?
- Audit autoportance. Prenez 5 paragraphes aléatoires de vos pages clés. Lisez chacun hors contexte. Comptez combien font sens sans le reste. Objectif : 4/5 minimum.
- Analyse HTML.
curl -s https://votre-page.fr/ | grep -c "\<p\> "donne le nombre de balises p dans le HTML initial. Si résultat = 0, la page n’est pas rendue côté serveur. - Outils tiers. Profound, Otterly et Scrunch proposent des rapports de citation qui révèlent indirectement si vos pages passent le filtrage retrieval de Perplexity et ChatGPT.
Checklist RAG-ready
- Contenu rendu côté serveur (SSR), vérifiable via curl
- Chaque section h2/h3 est autoportante (compréhensible sans contexte)
- Aucun pronom orphelin en début de section (« il », « cette méthode » sans référent nommé)
- Au moins 3 données chiffrées sourcedées dans l’article
- Termes clés et synonymes présents dans le corps du texte
- Schema Article avec datePublished + dateModified à jour
- Tableaux et listes avec titres explicites (pas « voir ci-dessous »)
- Images stratégiques avec alt text descriptif et factuel
FAQ
Le RAG est-il utilisé par tous les moteurs IA ?
Oui, avec des variantes. Perplexity et ChatGPT Search utilisent un RAG web (retrieval en temps réel depuis des sources en ligne). Les LLMs purs comme Claude ou GPT-4 sans plugin utilisent un RAG interne (retrieval depuis la mémoire paramétrique du modèle). Google AI Overviews combine les deux. Le principe de retrieval + génération est universel.
Un contenu bien structuré suffit-il à être sélectionné par le RAG ?
La structure est nécessaire mais pas suffisante. Le retrieval sélectionne d’abord par pertinence sémantique (votre contenu couvre-t-il la requête ?) puis par qualité du passage (est-il autoportant, factuel, précis ?). Un contenu parfaitement structuré mais vague ne sera pas cité.
Quelle est la taille idéale d’un passage pour le RAG ?
Les systèmes RAG découpent les documents en chunks de 100 à 500 tokens (75 à 375 mots). Viser des paragraphes de 80 à 150 mots par section, chacun répondant à une intention précise. Les sections trop longues diluent la pertinence ; les sections trop courtes manquent de contexte.
Est-ce que le RAG tient compte du PageRank ou de l’autorité du domaine ?
Pas directement dans le scoring sémantique. Mais les systèmes RAG web (Perplexity, ChatGPT Search) filtrent d’abord par les sources présentes dans un moteur de recherche sous-jacent (souvent Bing). Un domaine faible en autorité Bing sera simplement absent du candidats de retrieval, avant même l’évaluation sémantique.
Comment savoir si mon contenu est bien éligible au RAG ?
Test pratique : prenez un paragraphe de votre page, lisez-le sans contexte et demandez-vous si un LLM pourrait l’utiliser pour répondre à une question spécifique. S’il contient une affirmation complète, désà source et vérifiable, il est éligible. S’il utilise des pronoms orphelins ou des références implicites (« cette méthode » sans nommer laquelle), il ne l’est pas.