Meta a récemment dévoilé la famille Llama 4 de grands modèles de langage (LLM) — Scout, Maverick et une préversion de Behemoth —, Scout offrant une fenêtre de contexte de 10 millions de jetons. Peu après, sur X, LinkedIn et d’autres forums, les commentaires affirmant que la génération augmentée par récupération (RAG) allait devenir obsolète se sont multipliés, laissant entendre qu’une fenêtre de contexte aussi étendue pourrait rendre la RAG inutile. Nous pensons toutefois que la RAG restera un modèle de conception fondamental de l’IA générative, compte tenu des subtilités propres aux fenêtres de contexte, de l’évolution constante des données d’entreprise, de la répartition des données entre différents systèmes de stockage, des enjeux réglementaires, des performances des modèles et de son intérêt pour les applications d’IA à l’échelle de l’entreprise.
Le RAG est une architecture essentielle pour les entreprises
Malgré la prouesse de Llama 4, qui prend en charge des fenêtres de contexte de 10 millions de jetons, la RAG reste un composant essentiel des applications d’IA en entreprise. Les entreprises exploitent souvent des ensembles de données dynamiques et en constante évolution, stockés dans des systèmes distribués. La RAG permet aux modèles de récupérer et d’intégrer en temps réel les informations les plus récentes et les plus pertinentes issues de ces vastes référentiels de données, garantissant ainsi des résultats d’IA à la fois précis et adaptés au contexte propre à chaque organisation, équipe ou utilisateur. La récupération en temps réel est indispensable aux applications qui nécessitent des connaissances à jour, telles que le service client, l’analyse de marché et les bases de connaissances.
S’appuyer uniquement sur de grandes fenêtres de contexte sans récupération externe peut s’avérer à la fois inefficace et constituer un risque pour la sécurité. Lorsque des données sont continuellement transmises à un modèle, il devient plus difficile de contrôler qui peut y accéder, de vérifier si elles sont stockées de manière sécurisée et de déterminer comment elles pourraient être exposées par inadvertance dans les journaux ou les sorties du modèle. À mesure que le volume de données augmente, les menaces internes, les invites malveillantes et les fuites accidentelles deviennent plus probables, et les organisations risquent d’enfreindre les exigences en matière de confidentialité ou de conformité si des informations confidentielles sont mal gérées.
En adoptant la génération augmentée par récupération (RAG), les entreprises peuvent extraire uniquement les données les plus pertinentes pour chaque requête, conformément aux contraintes réglementaires régionales et sectorielles, qui exigent souvent une sélection de données étroitement corrélées. Cette approche réduit la surface d’attaque tout en garantissant l’application cohérente de politiques telles que les contrôles d’accès fondés sur les rôles, le chiffrement des données en transit et des mécanismes d’audit détaillés. Cette récupération sélective permet non seulement de réduire la charge de calcul, mais aussi de renforcer la sécurité en limitant l’exposition des ressources sensibles au strict nécessaire au moment de l’inférence.
“Lorsque des données sont continuellement injectées dans un modèle, il devient plus difficile de contrôler qui peut y accéder, de s’assurer qu’elles sont stockées de manière sécurisée et d’éviter qu’elles ne soient exposées par inadvertance dans des journaux ou des résultats générés par le modèle.”
Fenêtres de contexte et implications
Dans les LLM, la fenêtre de contexte désigne le nombre maximal de jetons que le modèle peut traiter dans une seule entrée. L’élargissement de cette fenêtre permet au modèle de prendre simultanément en compte davantage d’informations, ce qui se traduit par des conversations plus détaillées, des analyses plus approfondies et une personnalisation accrue. À titre de comparaison, un texte brut composé de 100 000 jetons représente environ 325 Ko ; une fenêtre de contexte de 10 millions de jetons correspondrait à environ 32 Mo de données textuelles. Cette capacité permet à Llama 4 Scout de traiter de grandes quantités d’informations en une seule requête.
Si une fenêtre contextuelle étendue permet de traiter davantage de données à la fois, elle pose également des défis en matière de performances, de précision et d’efficacité du modèle. Le traitement de millions de jetons exige d’importantes ressources de calcul, ce qui entraîne une latence accrue et des coûts d’exploitation plus élevés. À mesure que la longueur du contexte augmente, les modèles peuvent avoir du mal à maintenir leur attention et la pertinence sur l’ensemble de l’entrée, ce qui risque d’affecter la qualité des résultats générés par l’IA. À ce sujet, Andriy Burkov, docteur et auteur reconnu comme expert en IA, a écrit sur X : « La fenêtre contextuelle annoncée de 10 millions de jetons est virtuelle, car aucun modèle n’a été entraîné sur des invites dépassant 256 000 jetons. Cela signifie que si vous lui envoyez plus de 256 000 jetons, vous obtiendrez la plupart du temps un résultat de mauvaise qualité. »
Si les fenêtres de contexte plus étendues offrent de nouvelles possibilités, il est essentiel de trouver un équilibre entre les performances et l’utilisation des ressources. Le scénario optimal consiste à fournir toutes les informations pertinentes, sans inclure celles qui ne sont pas nécessaires. En effet, certaines études semblent indiquer que, comme chez les humains, fournir trop d’informations à un LLM nuit à sa capacité à repérer les éléments importants et à se concentrer. Pour les personnes intéressées, le livre blanc « Lost in the Middle: How Language Models Use Long Contexts », approfondit ce sujet.
Considérations relatives à l’infrastructure pour le déploiement de modèles d’IA avancés
De nombreuses entreprises trouvent difficile de connecter de manière sécurisée des centaines, voire des milliers, de référentiels de données largement dispersés pour la RAG, sans compromettre les performances ni la sécurité des données en transit. La consolidation d’emplacements de stockage sur site, hybrides et multicloud nécessite une infrastructure d’interconnexion mondiale hautes performances, telle que celle fournie par F5 Distributed Cloud Services. En veillant à ce que seuls les points de terminaison LLM autorisés puissent accéder aux données au moyen d’un WAF intégré et de contrôles basés sur des politiques, les entreprises réduisent considérablement les risques et la charge liés à la gestion de plusieurs passerelles ou VPN.
En proposant une approche unifiée de la mise en réseau et de la sécurité, F5 Distributed Cloud Network Connect simplifie les déploiements de RAG, permettant aux organisations de connecter facilement des sources de données distribuées afin d’obtenir des résultats générés par les LLM plus précis et plus rapidement. De plus, grâce à F5 AI Gateway, les organisations peuvent se protéger contre les attaques par injection de prompts susceptibles de compromettre les périmètres de sécurité des données, afin de garantir une approche de défense en profondeur lors de l’inférence.
Le déploiement de modèles tels que Llama 4 Scout, avec sa fenêtre contextuelle étendue, nécessite une infrastructure robuste et efficace. Des proxys hautes performances capables de gérer un débit de données considérable sont indispensables pour maintenir une faible latence et garantir un fonctionnement fluide. F5 BIG-IP Next for Kubernetes déployé sur des DPU NVIDIA BlueField-3 constitue une solution particulièrement adaptée dans ce contexte, en offrant une gestion du trafic et une sécurité hautes performances conçues pour les infrastructures d’IA à l’échelle du cloud et les usines d’IA.
En déchargeant les tâches gourmandes en données sur les DPU, les ressources CPU sont libérées pour les processus applicatifs principaux, ce qui améliore l’efficacité globale du système. Grâce à la prise en charge de l’architecture mutualisée, plusieurs charges de travail d’IA peuvent s’exécuter de manière sécurisée et efficace au sein d’une même infrastructure, ce qui répond parfaitement aux besoins des clouds d’IA, des hyperscalers et des fournisseurs de services. Ces capacités sont indispensables aux usines d’IA qui souhaitent exploiter des modèles dotés de fenêtres de contexte étendues tout en maintenant des performances et une sécurité optimales.
Un autre point important à prendre en compte est que les fenêtres de contexte étendues et très variables peuvent entraîner d’importantes fluctuations de la consommation des ressources. Il devient donc d’autant plus essentiel de répartir intelligemment les requêtes entrantes en fonction de la capacité de calcul disponible. Les solutions avancées et adaptatives d’équilibrage de charge permettent de distribuer ces requêtes volumineuses entre plusieurs clusters ou régions, afin de limiter les goulets d’étranglement et de préserver les performances globales des déploiements d’IA complexes, même si elles ne réduisent pas directement les coûts de calcul.
Le RAG est toujours là pour durer
Le RAG est toujours aussi pertinent aujourd’hui, pour des raisons qui vont au-delà de l’augmentation de la taille des fenêtres de contexte. L’un de ses principaux avantages réside dans sa capacité à personnaliser la récupération des données en fonction des droits d’accès de l’utilisateur. Il permet également d’intégrer des informations récentes sans avoir à réentraîner ni à affiner le modèle. Cet aspect devient particulièrement important au regard du volume considérable des données d’entreprise, qui se chiffre souvent en téraoctets, voire en pétaoctets, et que les entreprises peuvent chercher à intégrer aux modèles d’IA.
Les innovations impressionnantes visant à augmenter la taille des fenêtres de contexte, comme la fenêtre de contexte de 10 millions de jetons de Llama 4 Scout, représentent une avancée majeure pour les LLM, mais le contexte doit toujours être utilisé de manière réfléchie. Les fenêtres de contexte étendues augmentent les coûts et la latence et peuvent même, dans certains cas, réduire la qualité de la réponse finale. Il est tout aussi important de disposer d’une infrastructure robuste et de contrôles de sécurité solides pour garantir des performances élevées à mesure que les organisations déploient leurs applications d’IA à grande échelle.
L’engagement de F5 en faveur de l’IA ne s’arrête pas là : découvrez comment F5 sécurise et déploie les applications d’IA partout.
À propos de l’auteur

Hunter Smit est directeur principal du marketing produit pour les solutions et la stratégie chez F5. Il dirige le marketing des solutions pour l’ensemble du portefeuille de F5, notamment dans les domaines de l’infrastructure d’IA et de la sécurité des applications, et pilote l’entrée de F5 sur le marché émergent de la fourniture de données pour l’IA. Hunter est membre du conseil consultatif de l’École de commerce de l’université Whitworth et a enseigné le marketing produit en tant que chargé de cours vacataire. Il est titulaire d’un MBA et d’un Bachelor of Business Administration en management de l’université Whitworth.
Autres articles de Hunter SmitArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.