Le No-Stack Stack : comment les fenêtres de contexte long simplifient l’architecture IA

Au cours des trois dernières années, construire une application d’IA capable de répondre à des questions sur vos données exigeait l’assemblage d’une infrastructure multicouche : processeurs de documents, pipelines de découpage, modèles d’embedding, bases de données vectorielles, systèmes de recherche, rerankers et logique d’orchestration pour tout relier. C’était le stack RAG — Retrieval Augmented Generation — devenu l’architecture par défaut de toute application LLM nécessitant l’accès à des données privées ou actualisées. En 2025, les déploiements RAG en entreprise avaient progressé de 280 % en glissement annuel, et environ 60 % des applications LLM en production utilisaient une forme de génération augmentée par recherche.

Puis les fenêtres de contexte se sont élargies. En 2023, la plupart des modèles plafonnaient à 4 000–8 000 tokens. Début 2025, Gemini 1.5 Pro offrait 2 millions de tokens. GPT-4.1 atteignait 1 million. Claude s’étendait à 200 000 tokens en standard, avec 1 million en bêta. Llama 4 de Meta poussait jusqu’à 10 millions de tokens. Et le modèle expérimental LTM-2-Mini de Magic démontrait une fenêtre de contexte de 100 millions de tokens — suffisant pour 10 millions de lignes de code ou environ 750 romans.

Une option architecturale radicale a émergé de cette expansion : contourner entièrement le stack de recherche. Charger vos documents directement dans le prompt. Laisser le modèle raisonner sur le texte complet.

C’est le « no-stack stack » — une architecture IA définie non par ce qu’elle inclut, mais par ce qu’elle élimine. Et pour un éventail surprenant de cas d’usage, cette approche n’est pas seulement plus simple — elle est plus performante.

Ce à quoi ressemble réellement le stack RAG

Avant d’apprécier ce que le no-stack stack élimine, il convient d’inventorier ce qu’un système RAG en production nécessite. Chaque couche introduit des décisions, des modes de défaillance, de la latence et une charge de maintenance.

La couche d’ingestion

• Analyseurs de documents — Extracteurs PDF, scrapers HTML, lecteurs de fichiers de code, chacun avec ses cas limites et modes de défaillance
• Logique de découpage — Division des documents en unités récupérables, avec des décisions sur la taille des chunks, le chevauchement et la détection des limites
• Prétraitement — Nettoyage de texte, extraction de métadonnées, déduplication, détection de langue

La couche d’embedding

• Modèle d’embedding — Sélectionné, hébergé et maintenu (ou accessible via API)
• Traitement par lots — Embedding de milliers ou millions de chunks, gestion du débit et des limites de taux
• Versionnage des modèles — Lorsque vous mettez à jour les modèles d’embedding, tous les vecteurs existants deviennent incompatibles et doivent être régénérés

La couche de stockage

• Base de données vectorielle — Déployée, configurée, mise à l’échelle, sauvegardée et surveillée (Pinecone, Weaviate, Chroma, pgvector ou autres)
• Gestion des index — Création et maintenance des index de recherche pour une récupération efficace
• Stockage des métadonnées — Conservation des informations source, horodatages et contrôles d’accès aux côtés des vecteurs

La couche de recherche

• Embedding de requête — Conversion des questions utilisateur en vecteurs au moment de la requête
• Recherche par similarité — Identification des chunks pertinents, avec réglage du top-k, du seuil de similarité et des métriques de distance
• Reranking — Seconde passe optionnelle mais souvent nécessaire pour améliorer la pertinence
• Assemblage des résultats — Combinaison des chunks récupérés en un contexte cohérent pour le LLM

La couche de synchronisation

• Détection des changements — Surveillance des documents source pour les mises à jour
• Réindexation — Découpage, embedding et stockage du contenu mis à jour
• Gestion des données obsolètes — Suppression des vecteurs pour les documents supprimés
• Garanties de cohérence — Assurer que l’index reflète l’état actuel des données source

La couche d’orchestration

• Gestion du pipeline — Coordination de tous les composants dans le bon ordre
• Gestion des erreurs — Traitement des défaillances à tout point du pipeline
• Supervision — Suivi de la latence, de la précision et de la santé du système à travers les composants
• Configuration — Gestion des paramètres à travers toutes les couches

C’est une infrastructure conséquente. La catégorie des bases de données vectorielles a attiré à elle seule plus de 800 millions de dollars d’investissement en capital-risque au cours de 2025 — Pinecone a rapporté une croissance de son chiffre d’affaires de 340 % en glissement annuel, et Weaviate a clôturé un tour de table Series C de 163 millions de dollars. L’outillage existe parce que le problème est réel. Mais pour de nombreux cas d’usage, cette machinerie résout un problème que les fenêtres de contexte plus longues ont déjà dissous.

Ce à quoi ressemble le No-Stack Stack

Supprimez tout ce qui précède. Remplacez-le par :

1. Charger les documents dans le prompt
2. Poser votre question au modèle
3. Obtenir la réponse

C’est tout. Pas d’embeddings. Pas de vecteurs. Pas de logique de recherche. Pas de synchronisation. Pas de reranking. Pas de problèmes de limites de chunks. Le modèle reçoit les documents complets et raisonne directement dessus.

L’effort d’ingénierie passe de la construction et maintenance d’infrastructure à la rédaction de prompts efficaces et à la gestion intelligente du contexte — des compétences plus accessibles à un éventail plus large de développeurs. Il n’y a pas de base de données vectorielle à provisionner, pas de modèle d’embedding à versionner, et pas de stratégie de découpage à déboguer quand les réponses reviennent incorrectes.

Les preuves : quand le contexte long surpasse la recherche

Ce n’est pas qu’une simplification théorique. Une étude de janvier 2025 publiée sur arXiv (« Long Context vs. RAG for LLMs: An Evaluation and Revisits ») a montré que le contexte long surpasse généralement RAG dans les benchmarks de questions-réponses, particulièrement pour les requêtes à forte intensité de connaissances. La recherche par chunks — l’implémentation RAG la plus courante — était systématiquement en retrait par rapport aux approches en contexte complet.

Les propres évaluations de Google pour Gemini 1.5 Pro ont démontré un taux de rappel supérieur à 99,7 % sur les tests needle-in-a-haystack jusqu’à 1 million de tokens, et ont maintenu un rappel supérieur à 99 % jusqu’à 10 millions de tokens pour la modalité texte. Ce ne sont pas des benchmarks synthétiques — ils mesurent la capacité du modèle à localiser et utiliser une information spécifique au sein de contextes massifs.

Cependant, la même recherche a constaté que RAG conserve des avantages pour les requêtes basées sur le dialogue et les questions-réponses générales, et que la recherche par résumé affiche des performances comparables au contexte long. Le choix n’est pas binaire. Il dépend du modèle, du type de tâche et des détails d’implémentation.

Cinq cas d’usage où le No-Stack Stack l’emporte

1. Analyse et synthèse de documents

Analyser un contrat juridique, résumer un article de recherche, extraire les conclusions clés d’un rapport — ces tâches exigent que le modèle comprenne la structure complète du document. Découper un contrat de 30 pages et en récupérer des fragments va à l’encontre de l’objectif. Charger le contrat entier (environ 30 000 tokens) dans la fenêtre de contexte permet au modèle de raisonner sur le texte intégral, capturant les renvois croisés, les clauses conditionnelles et les dépendances structurelles que le découpage détruit.

2. Revue et analyse de code

Examiner une pull request, analyser une base de code pour des vulnérabilités de sécurité, ou comprendre comment une fonctionnalité est implémentée à travers plusieurs fichiers. Ces tâches bénéficient de la vision du code complet en contexte plutôt que de la récupération de fonctions isolées. Une revue de code de 15 fichiers totalisant 50 000 tokens tient aisément dans n’importe quelle fenêtre de contexte moderne et produit une meilleure analyse que la récupération d’extraits, car le modèle peut tracer les dépendances entre les fichiers.

3. Analyse comparative

Comparer deux versions d’un document, évaluer des propositions concurrentes, ou analyser les différences entre des spécifications de produits. Ces tâches requièrent fondamentalement que le modèle maintienne simultanément plusieurs documents complets et raisonne à travers eux. RAG n’est pas conçu pour la comparaison — il est conçu pour la recherche. Charger les deux documents en contexte permet au modèle d’effectuer une véritable analyse comparative.

4. Traitement de réunions et communications

Analyser la transcription d’une réunion, résumer un fil d’e-mails, ou extraire les actions à mener d’une conversation. Ce sont des documents séquentiels et bornés où l’ordre et le contexte de chaque déclaration comptent. Découper la transcription d’une réunion détruit le flux conversationnel et le contexte temporel. Le contexte long le préserve, produisant des résumés qui capturent fidèlement l’arc de la discussion, la dynamique entre participants et l’évolution des décisions.

5. Gestion des connaissances personnelles

Les notes d’un développeur individuel, la documentation de projet d’une petite équipe, la collection d’articles d’un chercheur — des ensembles de données importants mais bornés. Un développeur avec 200 pages de notes personnelles dispose d’environ 100 000 tokens de texte. Cela tient aisément dans les fenêtres de contexte actuelles et ne justifie pas l’effort de déploiement et de maintenance d’un pipeline de recherche.

Quand le No-Stack Stack atteint ses limites

Le mur de l’échelle

Le no-stack stack a une limite dure : la fenêtre de contexte. Quand vos données dépassent ce que la fenêtre peut contenir, vous êtes contraint soit de tronquer (en perdant de l’information), soit d’ajouter de la recherche (en réintroduisant le stack). Pour une entreprise avec 10 000 pages de documentation, même une fenêtre de contexte de 2 millions de tokens est insuffisante. Vous avez besoin d’un moyen de filtrer vers les pages pertinentes avant de les charger en contexte.

Le plafond des coûts

À des volumes de requêtes élevés, traiter de larges contextes par requête devient coûteux. L’économie est brutale : les requêtes RAG coûtent en moyenne environ 0,00008 $ par requête, tandis que les requêtes en contexte long avoisinent 0,10 $ — rendant RAG environ 1 250 fois moins cher par requête. Un système de support client traitant des milliers de requêtes par jour contre un manuel produit ne peut pas se permettre de charger le manuel entier pour chaque requête, même si la mise en cache de prompts réduit les coûts de 50 à 90 %.

Pour donner un ordre de grandeur sur les tarifs bruts : Gemini 2.5 Pro facture 1,25 $ par million de tokens en entrée, GPT-5.2 facture 1,75 $ par million, et Claude Opus 4.5 facture 5,00 $ par million. Ces coûts se multiplient rapidement lorsqu’on traite des centaines de milliers de tokens par requête à grande échelle.

Le plancher de latence

Traiter 500 000 tokens prend du temps. Pour les applications interactives où des temps de réponse inférieurs à la seconde comptent, la latence d’ingestion d’une large fenêtre de contexte est rédhibitoire. Les pipelines RAG affichent en moyenne environ 1 seconde pour les requêtes de bout en bout, tandis que les configurations équivalentes en contexte long peuvent prendre 30 à 60 secondes sur la même charge de travail.

Le problème du « perdu au milieu »

Une recherche de Liu et al., publiée dans Transactions of the Association for Computational Linguistics en 2024, a documenté un défi persistant : les LLM performent mieux quand l’information pertinente apparaît au début ou à la fin du contexte, mais la précision chute de 10 à 20 points de pourcentage quand l’information critique se trouve au milieu de longs contextes. Bien que les modèles s’améliorent — Gemini 1.5 Pro atteint un rappel quasi parfait sur les tests à aiguille unique — le problème persiste pour la recherche multi-aiguilles et les tâches de raisonnement complexes. La capacité de contexte effective en conditions réelles tourne typiquement autour de 60–70 % des limites annoncées.

Pour les applications où trouver un fait spécifique dans un large corpus importe — conformité réglementaire, recherche d’informations médicales, recherche juridique à travers des milliers de documents — la recherche ciblée de RAG produit encore des résultats plus fiables que d’espérer que le modèle s’attardera sur la bonne section d’un contexte massif.

L’exigence de précision

Certaines applications exigent non seulement la bonne réponse, mais aussi la provenance — quel document, quelle page, quel paragraphe a fourni la réponse. L’étape de recherche de RAG fournit naturellement l’attribution des sources. Avec le contexte long, extraire des citations précises d’un input de 500 000 tokens nécessite un prompting supplémentaire et reste moins fiable.

Construire efficacement le No-Stack Stack

Pour les équipes adoptant cette approche, plusieurs pratiques améliorent la fiabilité et la qualité des résultats.

Organisation du contexte

La structure compte même sans recherche. Organisez les documents dans le contexte avec des en-têtes clairs, des marqueurs de section et des métadonnées. Le modèle navigue plus efficacement dans un contexte structuré que dans un dump de texte brut.

« `

=== DOCUMENT : Rapport financier T4 ===

Date : Janvier 2026

Type : Rapport trimestriel

[contenu du document]

=== FIN DU DOCUMENT ===

« `

Chargement sélectif

Chaque document n’a pas besoin de figurer dans chaque requête. Construisez une logique simple pour sélectionner quels documents sont pertinents pour la question en cours — pas un pipeline RAG complet, mais un filtrage léger basé sur des mots-clés, le type de document ou la récence. C’est le minimum de recherche qui vous maintient sous le plafond de contexte sans nécessiter d’infrastructure vectorielle.

Budget de contexte

Surveillez la proportion de la fenêtre de contexte que vous utilisez. Laissez de la place pour la réponse du modèle et pour tout raisonnement en chaîne de pensée. Une fenêtre de contexte remplie à 95 % ne laisse aucune marge au modèle pour réfléchir. Étant donné que la capacité effective tourne autour de 60–70 % des limites annoncées, planifiez en conséquence.

Mise en cache des prompts

Pour les requêtes répétées contre les mêmes documents, la mise en cache des prompts est essentielle. L’implémentation d’Anthropic réduit les coûts jusqu’à 90 % et la latence jusqu’à 85 % pour les longs prompts. OpenAI offre une mise en cache automatique avec 50 % d’économie, activée par défaut pour les prompts de 1 024 tokens ou plus. Google propose une configuration manuelle du cache avec une durée de vie par défaut d’une heure. Chez tous les fournisseurs, les tokens en entrée mis en cache coûtent environ 10 fois moins que les tokens en entrée réguliers. Pour des ensembles de documents stables interrogés de manière répétée, la mise en cache transforme l’économie des approches en contexte long.

Dégradation gracieuse

Concevez des systèmes capables de se replier sur la recherche quand les données dépassent la fenêtre de contexte. Commencer avec le no-stack stack ne signifie pas que vous ne pourrez jamais ajouter de recherche — mais construire d’abord avec l’approche la plus simple signifie que vous n’ajoutez de la complexité que quand le cas d’usage l’exige. Cette architecture progressive permet aux équipes de livrer plus vite et de n’ajouter d’infrastructure que lorsqu’elles heurtent un mur concret.

L’avenir hybride

L’industrie converge vers un juste milieu pragmatique. Les architectures de production les plus efficaces en 2026 utilisent la recherche pour identifier le contexte pertinent, puis alimentent ce contexte récupéré dans de longues fenêtres de contexte pour le raisonnement. Cette approche hybride capture la précision de RAG avec la profondeur de raisonnement du contexte long.

Pensez-y comme un spectre plutôt qu’un choix binaire :

• No-stack pur — Les documents tiennent en contexte, cas d’usage borné, volume de requêtes modéré
• Filtrage léger + contexte long — Un simple filtrage par mots-clés ou métadonnées restreint les documents avant chargement
• RAG hybride + contexte long — La recherche vectorielle identifie les chunks pertinents, la fenêtre de contexte long raisonne à travers eux
• Stack RAG complet — Échelle entreprise, haut volume, applications critiques en précision

Le no-stack stack n’est pas anti-ingénierie. C’est la reconnaissance que l’infrastructure superflue a des coûts — charge de maintenance, complexité de débogage, modes de défaillance et charge cognitive. Chaque composant doit mériter sa place en résolvant un problème que des approches plus simples ne peuvent pas gérer.

Conclusion

Le no-stack stack est le bon point de départ pour la plupart des applications d’IA travaillant avec des ensembles de documents bornés. Chargez les documents. Posez la question. Obtenez la réponse. N’ajoutez d’infrastructure que lorsque vous heurtez un mur — échelle, coût, latence ou précision — que l’approche simple ne peut franchir.

Les bases de connaissances à l’échelle de l’entreprise, les systèmes de production à haut volume et les applications critiques en précision ont toujours besoin d’infrastructure de recherche. Les 800 millions de dollars investis dans les entreprises de bases de données vectorielles en 2025 reflètent une demande réelle des entreprises. Mais pour le vaste nombre d’applications d’IA construites par de petites équipes, des startups et des développeurs individuels — le choix par défaut devrait être la simplicité, pas la complexité. Commencez avec le minimum de composants mobiles. N’ajoutez de la machinerie que lorsque les données ou la charge de travail vous y obligent.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Long Context vs. RAG for LLMs: An Evaluation and Revisits — arXiv (January 2025)
• Lost in the Middle: How Language Models Use Long Contexts — Liu et al., TACL 2024
• 100M Token Context Windows — Magic
• Prompt Caching with OpenAI, Anthropic, and Google Models — PromptHub
• RAG vs Long Context: Do Vector Databases Still Matter in 2026? — MarkAICode
• The Needle in the Haystack Test and How Gemini Pro Solves It — Google Cloud Blog
• Context Length Comparison: Leading AI Models in 2026 — Elvex
• RAG and Long-Context Windows: Why You Need Both — Google Cloud Community