Mise en place d'un pipeline RAG sur des données Web en temps réel (sans index obsolètes)

Un pipeline RAG en temps réel extrait les données du Web ouvert au moment de la requête, plutôt que de les lire à partir d’un index vectoriel pré-indexé. Cela garantit la fraîcheur des réponses, car les données sont récupérées au moment où l’utilisateur en fait la demande, et non plusieurs semaines auparavant, lors de votre dernière indexation. Le compromis est direct : la récupération en temps réel ajoute de la latence et un coût par requête, tandis qu'un index mis en cache est rapide mais devient obsolète. La plupart des systèmes de production que nous observons se situent dans une solution hybride intermédiaire, récupérant les données en temps réel pour les requêtes urgentes et réutilisant des segments mis en cache dans le respect d'un délai de validité (TTL).

Points à retenir

• Le système RAG classique puise ses réponses dans un index statique ; par conséquent, la date de votre dernière exploration constitue la limite maximale de l'actualité des informations.
• Live-web RAG identifie des sources à l'aide d'une API de recherche, récupère et nettoie les pages au moment de la requête, puis étaye la réponse à l'aide de références.
• Le plus difficile n'est pas la récupération. Il s'agit plutôt de déterminer s'il faut récupérer les données en temps réel ou réutiliser un bloc mis en cache, en fonction d'un délai de validité (TTL) défini par sujet.
• En 2025, Gartner prévoyait que 40 % des applications d'entreprise intégreraient des agents IA spécialisés d'ici fin 2026, contre moins de 5 % auparavant, et que ces agents auraient besoin de données à jour.
• Un code Markdown bien structuré est plus efficace que le HTML brut lors de la phase d'ingestion, car il réduit le coût de l'analyse syntaxique et élimine les éléments de navigation, les publicités et les passages standardisés avant le découpage en blocs.

Le modèle RAG classique avait du sens lorsque votre corpus consistait en une base de connaissances peu évolutive : documents, politiques, tickets. Mais dès qu’on l’applique au Web ouvert, le modèle s’effondre. Les prix changent, l'actualité évolue, les classements fluctuent, et un index vectoriel construit mardi dernier renvoie avec certitude la réalité de mardi dernier. La solution ne réside pas dans un index plus volumineux ni dans un calendrier de réindexation plus rapide. Il s'agit plutôt de déplacer la récupération des données qui évoluent réellement au moment de la requête. RAG Il s'agit de la génération augmentée par la recherche (RAG) : un modèle génère des réponses à partir des documents que vous récupérez et lui fournissez, et non pas uniquement à partir de ses paramètres d'apprentissage. Cet article présente l'architecture étape par étape, puis aborde la logique de mise à jour qui distingue le RAG en temps réel de la version classique. Pour une vue d'ensemble plus large sur la mise à disposition de données actualisées aux agents, commencez par consulter la section consacrée à Comment permettre aux agents IA d'accéder au Web en temps réel.

Pourquoi le modèle RAG classique perd-il de son efficacité lorsqu'il s'agit de données Web ?

Le modèle RAG classique devient obsolète car il fournit des réponses à partir d'un instantané. Vous effectuez une exploration, segmenter, intégrez et stockez les données ; ensuite, chaque requête interroge cette copie figée jusqu'à la prochaine exploration. Pour un corpus stable, cela convient parfaitement. Pour le Web ouvert, cependant, c'est un handicap, et la demande d'agents fournissant des données actualisées est en hausse. En 2025, Gartner prévoyait que D'ici fin 2026, 40 % des applications d'entreprise intégreraient des agents IA spécialisés dans des tâches spécifiques, contre moins de 5 % en 2025. Les agents chargés de répondre à des questions concrètes ne peuvent pas se baser sur des données obsolètes.

Le problème de l'obsolescence comporte deux aspects. Premièrement, la couverture : le Web que vous avez indexé le mois dernier ne contient pas les pages qui n'existaient pas encore, et aucune stratégie de récupération, aussi ingénieuse soit-elle, ne permet de les retrouver. Ensuite, la dérive : les pages que vous avez indexées ont changé à votre insu, et vos indexations pointent toujours vers l'ancien texte. Une nouvelle exploration à un rythme plus soutenu réduit l'écart mais ne le comble jamais, et entre-temps, elle mobilise des ressources informatiques sur des pages que personne ne consultera.

Le RAG en temps réel inverse l'ordre des opérations. Au lieu de précharger l'intégralité du contenu et d'espérer que la bonne page figure dans l'index, vous identifiez et récupérez les sources au moment même de la requête. Ainsi, l'effort ne consiste plus à « explorer en continu l'ensemble du Web », mais à « récupérer les quelques pages requises par cette requête ». Pour en savoir plus sur l'importance de l'ancrage et sur la manière dont il réduit les hallucinations, consultez notre guide sur Entraînement des modèles de langage de grande envergure (LLM) à partir de données Web en temps réel.

À quoi ressemble une architecture RAG en ligne ?

Un pipeline RAG en temps réel comporte sept étapes : compréhension de la requête, découverte des sources en temps réel, récupération et nettoyage, segmentation et intégration, extraction des k meilleurs résultats, étayage de la génération par des citations, puis mise en cache avec un délai de validité (TTL) garantissant l'actualité des données. Les six premières étapes permettent d'obtenir la réponse. La septième détermine ce que vous conservez, afin que la requête similaire suivante puisse ignorer la phase de récupération en temps réel. Chaque étape est concrète, et dans la pratique, la plupart des échecs sont dus à une étape de découverte de sources ou de récupération défaillante.

Voici le déroulement sous forme de liste d'étapes :

1. Compréhension de la requête -> reformuler la question de l'utilisateur en intention de recherche
2. Découverte de sources -> l'API de recherche renvoie des URL candidates
3. Récupération + nettoyage -> convertir chaque URL en Markdown propre
4. Segmentation + intégration -> segmenter le Markdown, intégrer les segments au moment de la requête
5. récupération des k meilleurs résultats -> classement des segments par rapport à l'intégration de la requête
6. fondement + citation -> le LLM répond en utilisant uniquement les segments récupérés, avec les liens vers les sources
7. mise en cache + TTL -> stockage des segments avec une date limite de validité pour réutilisation

Les étapes ci-dessous décrivent chacune des étapes. Aucune d'entre elles ne nécessite un index pré-construit de grande taille. Le « magasin de vecteurs » dont il est question ici est de petite taille et de courte durée, souvent limité à une seule requête ou session.

Étape 1 : compréhension de la requête

Transformez la question brute de l'utilisateur en intention de recherche avant de consulter le Web. Éliminez les mots de remplissage, développez les abréviations et extrayez les entités ainsi que la sensibilité au facteur temps. Par exemple, « Quelles sont les dernières nouvelles concernant l'acquisition de X » implique une actualité ; une question de définition, en revanche, n'en implique pas. Cette étape détermine dans quelle mesure le reste du pipeline privilégiera les données récentes par rapport aux données mises en cache. Peu coûteux à mettre en œuvre, avec un gain de qualité considérable.

Étape 2 : découverte des sources en temps réel

C'est au stade de la découverte que la plupart des pipelines échouent discrètement, car le modèle ne peut pas s'appuyer sur des pages qu'il n'a jamais trouvées. Recherche de sources Il s'agit de l'étape qui permet de transformer l'intention de recherche en un ensemble d'URL candidates, généralement via une API de recherche plutôt qu'en devinant des domaines. Un point de terminaison SERP géolocalisable est ici essentiel : les résultats pour « meilleur X près de chez moi » ou une requête de prix varient selon le pays et la ville, et vous souhaitez obtenir les sources que votre utilisateur verrait réellement. Pour une comparaison des options, consultez API de recherche sur le Web pour les agents.

C'est à cette première étape que l'API Web Render de Massive entre en action. Le point de terminaison de recherche (/recherche) récupère les résultats des pages de résultats des moteurs de recherche (SERP) des principaux moteurs et permet un ciblage géographique par pays, région ou ville. Pour les requêtes qui s'appuient sur le contenu d'un résumé généré par l'IA, en attente=ai attend jusqu'à une minute pour obtenir un aperçu de l'IA, et en attente de réponses affiche la section « Les internautes ont également demandé ». Vous obtenez ainsi une liste d'URL candidates, classées telles qu'un utilisateur réel de cette localité les verrait.

Étape 3 : récupération et nettoyage

C'est lors de la récupération des pages candidates que le RAG en temps réel se heurte aux mécanismes de défense du Web moderne, et ce dernier est hostile aux robots. En 2025, Imperva a signalé que En 2024, les robots automatisés représentaient 51 % de l'ensemble du trafic web, la première fois en dix ans que les robots ont dépassé les humains, les robots malveillants représentant 37 % du trafic. Les sites réagissent en mettant en place des mesures de blocage agressives, de sorte que les requêtes naïves provenant de centres de données sont remises en question ou reçoivent du contenu leurre.

À ce stade, deux conditions doivent être remplies. Premièrement, votre requête doit passer le filtre anti-bot de la page, sinon vous vous retrouverez sur une page d'erreur. Proxys résidentiels acheminer les requêtes via de véritables appareils grand public, de sorte que le trafic provienne d’adresses IP résidentielles plutôt que d’une plage d’adresses de centre de données signalée. L’API Web Render de Massive effectue des requêtes sur un réseau d’appareils grand public couvrant plus de 195 pays, avec environ 1,3 million d’appareils actifs par jour. Lors de nos tests, le taux de réussite des adresses IP résidentielles sur les sites protégés s'est généralement révélé bien supérieur à celui des centres de données (fourchettes approximatives : résidentiel ~85-99 % contre centre de données ~20-40 %) ; veuillez considérer ces chiffres comme une référence fournie par le fournisseur, et non comme une étude indépendante.

Deuxièmement, vous souhaitez obtenir du texte brut, et non du code HTML brut. Le point de terminaison « Browsing » (/navigateur) prend en charge format=markdown en tant que résultat de première classe, en renvoyant un code Markdown prêt pour les grands modèles de langage (LLM), débarrassé des éléments de navigation, des publicités et des passages standard. Cela est important avant le découpage en segments : le Markdown réduit considérablement le nombre de tokens par rapport au code HTML brut, ce qui diminue les coûts d'intégration et de génération et permet de conserver des segments pertinents, plutôt que remplis de liens de menu. Des professionnels ont constaté le même effet (dev.to, Outils de navigation pour les agents IA, 4e partie : Passer outre le navigateur(2026).

Étape 4 : regroupement et intégration

Divisez le code Markdown nettoyé en blocs et intégrez-les au moment de la requête. Comme le corpus se limite aux quelques pages extraites par cette requête, cette opération est rapide et peu coûteuse ; vous intégrez en effet quelques kilo-octets, et non l'intégralité du Web. Veillez à ce que les segments respectent la structure Markdown, par titre et par paragraphe, afin que chaque segment reste autonome. Les titres Markdown vous offrent des délimitations naturelles que le HTML brut ne propose pas.

Étape 5 : récupérer les k premiers éléments

Classez les segments fraîchement encodés par rapport à l'encodage de la requête et conservez les k meilleurs. Avec un corpus restreint par requête, la recherche est simple et vous pouvez vous permettre de choisir une valeur k plus élevée, puis laisser le modèle de génération effectuer le filtrage. L'objectif ici est de ne conserver que les segments qui dépassent un seuil de pertinence, afin qu'une source peu pertinente ne dilue pas la fenêtre contextuelle.

Étape 6 : étayer votre argumentation à l'aide de références

Ne fournissez au modèle que les extraits récupérés et demandez-lui de s'appuyer sur ceux-ci pour répondre, en incluant un lien vers la source pour chaque affirmation. Mise à la terre Il s'agit de la pratique consistant à limiter la réponse d'un modèle aux données extraites plutôt qu'à sa mémoire paramétrique ; c'est donc là le principe de l'ancrage : pas de fragment, pas d'affirmation. Comme chaque fragment comporte l'URL de sa source issue de l'étape 2, les références sont fournies automatiquement, et un lecteur (ou un contrôle en aval) peut vérifier la réponse en la comparant à la page en ligne. L'ancrage sur un texte récupéré à la seconde près est la raison d'être même de la mise en ligne.

Étape 7 : mise en cache avec un délai de validité (TTL)

Enregistrez les blocs que vous avez récupérés en leur attribuant une durée de validité, afin que la prochaine requête similaire puisse les réutiliser au lieu de les récupérer à nouveau. C'est ce qui rend le RAG en temps réel abordable à grande échelle. Le cache transforme la deuxième requête identique, qui nécessiterait normalement une récupération complète en temps réel, en une simple consultation, et c'est la durée de validité (TTL) qui garantit la fiabilité de cette consultation. La section suivante explique comment la configurer.

Comment éviter les index obsolètes grâce aux délais de validité (TTL) ?

Vous évitez les index obsolètes en associant un délai de validité (TTL) à chaque bloc mis en cache et en le récupérant à nouveau dès qu'il expire. A durée de conservation TTL Il s'agit d'une durée de vie (TTL) par bloc qui indique combien de temps une donnée mise en cache reste fiable avant de devoir être actualisée. La TTL est propre à chaque sujet et n'est pas globale : le cours d'une action peut être valable pendant quelques secondes, les spécifications d'un produit pendant plusieurs jours, et une définition encyclopédique pendant plusieurs semaines. Lorsqu'une requête arrive, vous consultez d'abord le cache, vous servez les segments qui sont encore dans leur délai de validité et vous déclenchez une récupération en temps réel pour tout élément expiré ou manquant. C'est le juste milieu hybride : rapide quand vous le pouvez, à jour quand vous le devez.

Définissez la durée de vie (TTL) dès la phase d'analyse de la requête. Si la phase 1 a identifié la question comme sensible à l'actualité, réduisez ou contournez la TTL et forcez une récupération en temps réel. En revanche, s'il s'agit d'une question de définition stable, un TTL long convient et vous pouvez servir la réponse à partir du cache. C'est le levier qui contrôle votre latence et votre coût : plus il y a de récupérations en temps réel, plus les réponses sont récentes et plus le coût par requête est élevé ; plus il y a d'accès au cache, plus c'est l'inverse.

L'invalidation est tout aussi importante que l'expiration. Un TTL gère la péremption liée au temps, mais certains événements exigent une invalidation immédiate : une page que vous avez citée renvoie une erreur 404, une source fiable publie un rectificatif, ou une entité connue pour être volatile (un score en direct, une actualité de dernière minute) apparaît dans la requête. Mettez en place un chemin d'invalidation explicite pour ces cas plutôt que d'attendre que le délai expire. En résumé, c'est la combinaison d'un TTL par sujet et d'une invalidation déclenchée par des événements qui distingue un pipeline web en temps réel d'un index classique qui se contente de réexplorer le site selon un calendrier cron.

Une raison supplémentaire pour laquelle le contenu en direct devrait devancer les index statiques en 2025 : le Web ouvert se ferme progressivement aux robots d'indexation de masse. Cloudflare a indiqué que le Le 1er juillet 2025, il a commencé à bloquer par défaut les robots d'indexation basés sur l'IA sur environ 20 % du Web et a lancé une place de marché fonctionnant selon un modèle de paiement à l'indexation. En conséquence, la maintenance d'un index pré-construit du Web ouvert devient chaque trimestre plus difficile et plus coûteuse. La récupération au moment de la requête sur un réseau d'appareils réels contourne le problème de l'exploration en masse, car vous récupérez quelques pages auxquelles un utilisateur réel pourrait accéder, et non l'ensemble du Web selon un calendrier prédéfini. Si vous souhaitez exposer ce pipeline aux agents en tant qu'outil accessible par appel, découvrez comment mettre en place un serveur MCP pour l'extraction de données Web.

Quand vaut-il mieux récupérer un bloc en temps réel plutôt que de réutiliser un bloc mis en cache ?

Effectuez une requête en temps réel lorsque la requête est sensible à l'actualité ou que l'entrée de cache correspondante a dépassé son délai de validité (TTL) ; réutilisez un bloc mis en cache lorsqu'il est encore récent et que la requête est stable. La décision est prise pour chaque requête, en fonction du signal de sensibilité au temps de la phase 1 et du TTL restant du bloc. C'est en appliquant correctement cette règle que vous optimisez votre budget en termes de latence et de coût ; veillez donc à l'ajuster en fonction du trafic réel, et non sur la base d'une estimation.

Une approche pratique par défaut : considérez le cache comme la voie rapide et la récupération en temps réel comme le filet de sécurité garantissant l'exactitude. Servez à partir du cache lorsque vous disposez d'un bloc dans les limites de validité (in-TTL) qui satisfait votre seuil de pertinence. Passez toutefois à une récupération en temps réel lorsque le cache ne contient pas le bloc recherché, que le bloc a expiré, que la requête vise la fraîcheur des données ou que la source mise en cache a été invalidée. Cela permet de maintenir un coût faible pour les requêtes courantes et répétitives tout en garantissant que les requêtes volatiles sont à jour.

Ajustez les seuils en tenant compte de deux types de problèmes. Les réponses obsolètes (un délai de validité de la mémoire cache trop long pour ce sujet) vous incitent à opter pour des délais de validité plus courts et davantage de requêtes en temps réel. Les pics de coût et de latence (trop de récupérations en temps réel sur des requêtes stables) vous poussent dans l'autre sens. D'après ce que nous observons sur l'ensemble des charges de travail des agents, il n'existe pas de paramètre unique correct ; le juste équilibre dépend de la composition de votre trafic et de la vitesse à laquelle vos sources évoluent réellement.

Sources

• Gartner, Gartner prévoit que 40 % des applications d'entreprise intégreront des agents IA spécialisés d'ici 2026, contre moins de 5 % en 2025, 2025. https://www.gartner.com/en/newsroom/press-releases/26/08/2025 - Gartner prévoit que 40 % des applications d'entreprise intégreront des agents IA dédiés à des tâches spécifiques d'ici 2026, contre moins de 5 % en 2025
• Imperva, Rapport 2025 sur les robots malveillants, 2025. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
• Cloudflare, Cloudflare vient de révolutionner la manière dont les robots d'indexation basés sur l'IA explorent l'Internet dans son ensemble, 2025. https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/
• dev.to, Outils de navigation pour les agents IA, 4e partie : Passer outre le navigateur, 2026. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c