Mise en place d'un pipeline RAG à partir de 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, au lieu 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 clair : 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 adoptent une approche hybride : ils effectuent une récupération en temps réel pour les requêtes urgentes et réutilisent des blocs mis en cache dans le respect d’un délai de validité (TTL) garantissant la fraîcheur des données.

Points clés à retenir

• Le système RAG classique fournit des réponses à partir d'un index statique ; par conséquent, la date de votre dernière exploration constitue la limite maximale de fraîcheur des informations.
• Live-web RAG identifie des sources à l'aide de la Web Search API, 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 des données en temps réel ou réutiliser un bloc mis en cache, en fonction d'un délai de validité (TTL) propre à chaque sujet.
• En 2025, Gartner prévoyait que 40 % des applications d'entreprise intégreraient des agents IA dédiés à des tâches spécifiques 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 performant que le code HTML brut lors de l'étape d'ingestion, car il réduit le coût de l'analyse syntaxique et supprime les éléments de navigation, les publicités et les passages standardisés avant le découpage en blocs.

Le RAG classique avait du sens lorsque votre corpus était une base de connaissances peu évolutive : documents, politiques, tickets. Mais dès que vous l'orientez vers le Web ouvert, le modèle ne tient plus la route. Les prix changent, des informations sont publiées, les classements évoluent, 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 « live-web » 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 rubrique consacrée à Comment permettre aux agents IA d'accéder au Web en temps réel.

Pourquoi la méthode RAG classique perd-elle 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, découpez le contenu en segments, intégrez les données et les stockez ; ensuite, chaque requête interroge cette copie figée jusqu’à la prochaine exploration. Pour un corpus stable, cela convient parfaitement. Pour le Web ouvert, en revanche, cela constitue un handicap, et la demande d’agents fournissant des données actualisées ne cesse de croître. En 2025, Gartner prévoyait que D'ici fin 2026, 40 % des applications d'entreprise intégreraient des agents IA dédiés à des tâches spécifiques, contre moins de 5 % en 2025. Les agents chargés de répondre à de vraies questions 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 à l'époque ; aucune technique de récupération, aussi ingénieuse soit-elle, ne permet donc de les retrouver. Ensuite, la dérive : les pages que vous avez indexées ont été modifiées à votre insu, et vos représentations pointent toujours vers l’ancien contenu. Effectuer une nouvelle exploration à une fréquence plus élevée réduit l’écart, mais ne le comble jamais, et entre-temps, cela mobilise des ressources informatiques pour des pages que personne ne consultera.

Le RAG en temps réel inverse cet ordre. 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. Par conséquent, la charge passe de « l’exploration continue de l’ensemble du Web » à « la récupération des quelques pages nécessaires à 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 Ancrage des modèles de langage de grande envergure (LLM) à l'aide 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 les éléments à conserver, afin que la prochaine requête similaire puisse ignorer l’étape de récupération en temps réel. Chaque étape est bien définie, et dans la pratique, la plupart des échecs sont dus à une défaillance au niveau de la découverte des sources ou de la récupération.

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 des sources -> l’API de recherche renvoie des URL candidates
3. Récupération + nettoyage -> convertir chaque URL en Markdown propre
4. Découpage + intégration -> diviser 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’encodage de la requête
6. Justification + citation -> le modèle de langage de grande capacité (LLM) fournit des réponses 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é en vue de leur réutilisation

Les étapes ci-dessous décrivent chacune de ces é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 éléments superflus propres au langage conversationnel, développez les abréviations et extrayez les entités ainsi que le caractère urgent. 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 processus privilégiera les données récentes par rapport aux données mises en cache. Peu coûteuse à mettre en œuvre, elle apporte 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. Identification des sources Il s'agit de l'étape qui consiste à convertir 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 Web Search API pour les agents.

Il s'agit de la première étape au cours de laquelle le module Web Render API de Massive intervient. Le point de terminaison « Search » (/search) 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, awaiting=ai attend jusqu'à une minute pour obtenir un aperçu de l'IA, et awaiting=answers récupère les résultats de la rubrique « Les internautes demandent aussi ». Vous obtenez ainsi un ensemble d'URL candidates, classées telles qu'un véritable utilisateur 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 indiqué que En 2024, les robots automatisés représentaient 51 % de l'ensemble du trafic Web, c'était la première fois en dix ans que les robots dépassaient les humains, les robots malveillants représentant 37 %. 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 la couche 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. La solution Web Render API 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 adresses de centres de données (fourchettes approximatives : résidentielles ~85-99 % contre centres 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 » (/browser) prend en charge format=markdown sous forme de sortie 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 blocs : 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 blocs 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 : se passer du 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. Le corpus se limitant 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 code HTML brut ne fournit pas.

Étape 5 : récupérer les k premiers résultats

Classez les segments fraîchement intégrés par rapport à l'intégration de la requête et conservez les k premiers. 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 formuler sa réponse à partir de ceux-ci, en indiquant 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 informations extraites plutôt qu'à sa mémoire paramétrique ; tel est donc 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 citations 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é à l’instant même 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 récupérant à nouveau les données en temps réel dès que ce délai expire. A durée de validité TTL Il s'agit d'une durée de validité (TTL) par bloc qui indique pendant combien de temps une donnée mise en cache reste fiable avant de devoir être actualisée. La TTL est spécifique à chaque sujet et n'est pas globale : le cours d'une action peut être valable pendant quelques secondes, les caractéristiques 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 dont la durée de vie n’est pas encore écoulée, 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 lorsque cela est possible, à jour lorsque cela est nécessaire.

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 parfaitement et vous pouvez servir la réponse à partir du cache. C’est le levier qui contrôle votre latence et votre coût : davantage de récupérations en temps réel signifient des réponses plus récentes et un coût par requête plus élevé, tandis que davantage d’accès au cache ont l’effet inverse.

L'invalidation est tout aussi importante que l'expiration. Un TTL gère la perte de validité 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 processus d’invalidation explicite pour ces cas plutôt que d’attendre la fin du délai. 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 d’effectuer une nouvelle exploration selon un calendrier cron.

Une raison supplémentaire pour laquelle le contenu en direct devrait devancer un index statique en 2025 : le Web ouvert se ferme progressivement aux robots d'exploration 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 le principe du paiement à l'exploration. 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 via 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’intégralité du Web selon un calendrier prédéfini. Si vous souhaitez mettre ce pipeline à la disposition des agents sous forme d’outil accessible par appel, découvrez comment mettre en place un MCP Server pour l'extraction de données Web.

Dans quels cas 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 TTL ; réutilisez un bloc mis en cache lorsqu'il est encore à jour et que la requête est stable. Cette 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 optimiserez 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 dont le délai de validité (TTL) n’est pas dépassé et 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 à obtenir des données récentes 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 fournissent des données à jour.

Ajustez les seuils en surveillant deux types de défaillance. Les réponses obsolètes (un délai de validité de cache (TTL) trop long pour ce sujet) vous incitent à opter pour des TTL plus courts et davantage de récupérations 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étrage unique idéal ; 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 dédiés à des tâches spécifiques 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 bots malveillants, 2025. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
• Cloudflare, Cloudflare vient de modifier 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 : se passer du navigateur, 2026. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c