Context rot, RAG et contexte long : comment concevoir des systèmes LLM en 2026

L'année où les fenêtres de 2 M de tokens ont cessé de compter

Pendant environ six mois, fin 2024 et début 2025, un argument familier a fait le tour des canaux Slack d'ingénierie : le RAG est obsolète, il suffit de tout coller dans le prompt.

Le raisonnement paraissait propre. Anthropic a livré Claude Sonnet avec une fenêtre de contexte de 1 M de tokens. Google a poussé Gemini 2.5 et 2.5 Pro à 2 M de tokens. Meta a annoncé Llama 4 Scout avec une limite théorique de 10 M de tokens. Si votre base de connaissances tient dans un seul prompt, pourquoi s'embêter avec des magasins de vecteurs, des pipelines d'embeddings et des stratégies de chunking ?

Puis, en juillet 2025, Chroma Research a publié « Context Rot: How Increasing Input Tokens Impacts LLM Performance » par Kelly Hong, Anton Troynikov et Jeff Huber. L'article décrit des expériences soignées sur 18 modèles de pointe et montre quelque chose que les pages marketing taisent : les longues fenêtres de contexte se dégradent de manière non évidente bien avant d'atteindre leur limite. Une fenêtre de 200 K tokens peut afficher une perte de précision sérieuse à 50 K tokens d'entrée. Une fenêtre de 1 M de tokens ne raisonne pas de façon fiable sur 1 M de tokens.

Ce résultat a recadré la conversation sur l'architecture. Le RAG n'est pas obsolète. Le contexte long n'est pas gratuit. La question intéressante n'est plus « lequel gagne », mais « quel pattern correspond à cette forme de données, à ce budget de latence et à cette exigence de fraîcheur ».

Cet article propose la réponse au niveau architectural : quand votre système doit-il faire de la récupération, quand doit-il tout déverser, et quand doit-il faire les deux.

---

Ce que l'article de Chroma a réellement montré

Il vaut la peine de lire attentivement l'article de Chroma, parce que le titre (« le context rot existe ») sous-estime ce qui s'y trouve réellement. L'équipe a exécuté des versions étendues des benchmarks needle-in-a-haystack (NIAH) sur GPT-4.1, la famille Claude 4 (y compris Opus 4 et Sonnet 4), Gemini 2.5 et Qwen3. Leur kit de réplication open source sur GitHub permet de reproduire les expériences.

Trois constats se détachent.

Constat 1 : les performances se dégradent de façon non uniforme à mesure que la longueur d'entrée augmente. C'est le résultat central. Les modèles ne se dégradent pas lentement et de façon prévisible à un taux linéaire quand l'entrée s'allonge. Ils tombent de falaises. Certains modèles s'en tirent bien à 32 K et s'effondrent à 64 K. D'autres tiennent jusqu'à ce qu'ils ne tiennent plus. La taille de la fenêtre de contexte documentée n'est que faiblement corrélée à la qualité avec laquelle le modèle utilise effectivement ce contexte.

Constat 2 : la similarité sémantique entraîne la dégradation plus que la longueur. Lorsque l'« aiguille » est sémantiquement distincte de la « botte de foin » environnante, les modèles la trouvent sans peine. Quand les distracteurs sont sémantiquement proches de la réponse, la précision chute brutalement, et la chute s'aggrave avec la longueur. Autrement dit : plus il est difficile de distinguer la réponse du bruit, plus le contexte long s'effondre vite. Cela rejoint un résultat distinct de Liu et al. (2024), « Lost in the Middle: How Language Models Use Long Contexts » dans TACL, qui montrait une courbe de performance en U où le milieu des contextes longs est systématiquement sous-pondéré.

Constat 3 (le plus surprenant) : le texte structuré et cohérent dégrade l'attention PLUS que le texte mélangé. Voilà le résultat qui devrait changer la façon de penser des ingénieurs. L'intuition était qu'un document de 100 K tokens propre et bien organisé est plus facile à raisonner pour un modèle qu'un pavé fouillis de 100 K tokens. Les données disent l'inverse, ou du moins, pas toujours. Un texte cohérent semble diffuser l'attention plus largement sur une longue séquence, tandis qu'un texte mélangé crée des signaux locaux plus distincts auxquels le modèle peut s'accrocher. L'implication : donner à un modèle un PDF bien rangé et bien formaté n'est pas automatiquement plus sûr que de lui donner un ensemble récupéré désordonné.

Le benchmark Sequential-NIAH (arXiv 2504.04713) prolonge cela en testant si les modèles peuvent enchaîner plusieurs récupérations depuis différentes parties d'un long contexte. La chute est encore plus marquée pour le raisonnement multi-étapes à distance.

Hamel Husain a bien résumé l'implication pratique dans ses notes sur le context rot : la posture d'ingénierie ne devrait pas être « tout faire rentrer », mais « donner au modèle le contexte le plus petit et le plus pertinent qui réponde à la question ».

---

Pourquoi le contexte long échoue : le mécanisme

Le mécanisme compte parce qu'il prédit quelles charges de travail vont échouer.

L'attention transformer standard applique un softmax sur toutes les paires de tokens. À mesure que la longueur de séquence N augmente, les poids d'attention se répartissent sur davantage de positions. Même avec des encodages positionnels relatifs comme RoPE (rotary position embeddings) ou ALiBi, le dénominateur du softmax grossit et le poids par position sur un token donné rétrécit. À 1 M de tokens, le « bon » token doit rivaliser avec 999 999 autres pour un budget d'attention fini.

Les encodages de position aident, mais ils ne sont pas magiques. RoPE a une courbe de dégradation connue lorsqu'on extrapole bien au-delà de la longueur d'entraînement. Des modèles entraînés sur des séquences allant jusqu'à 32 K tokens, déployés à 1 M de tokens, font une extrapolation que les mathématiques sous-jacentes ne soutiennent pas complètement. Des astuces comme YaRN, l'interpolation de position et le scaling NTK-aware étendent la plage utilisable, mais aucune ne produit un modèle qui utilise 1 M de tokens aussi efficacement qu'il utilise 32 K.

Il y a aussi un problème de données d'entraînement. Même quand un modèle s'entraîne sur de longues séquences, les exemples qui exigent un raisonnement transversal sur 800 K tokens sont rares. Les modèles apprennent à utiliser les parties du contexte que les données d'entraînement leur ont appris à utiliser.

Le context rot n'est pas un bug que la prochaine sortie corrigera. C'est une propriété de l'architecture et de la distribution d'entraînement. Les futurs modèles repousseront les limites plus loin, mais le pattern de base persistera un moment.

---

Là où le RAG l'emporte encore

Étant donné le context rot, la génération augmentée par récupération n'est pas une infrastructure héritée. Voici les cas où elle continue de gagner en 2026.

Corpus multi-documents à l'échelle. Si votre base de connaissances compte 50 000 documents totalisant 500 M de tokens, elle ne tient dans aucune fenêtre de contexte. La récupération est la seule architecture viable.

Fraîcheur et récence. Les magasins de vecteurs se mettent à jour de façon incrémentale. Un prompt en contexte long exige de reconstruire le prompt à chaque changement de contenu. Pour des documents qui se mettent à jour toutes les heures (actualités, catalogues, tickets de support, dépôts de code), la récupération gère le changement à moindre coût.

Coût. Le coût d'inférence évolue à peu près linéairement avec les tokens d'entrée. Envoyer 200 K tokens coûte 200 fois plus que 1 K tokens. Si 95 % de vos requêtes peuvent recevoir une réponse à partir de 5 K tokens pertinents, la récupération vous offre une réduction de coût d'un facteur 40 sans perte de précision.

Citation et traçabilité. La récupération vous fournit une liste structurée de documents sources que vous pouvez afficher, relier et classer. Les sorties en contexte long sont plus difficiles à ancrer dans des sources précises sans un dispositif supplémentaire d'extraction de citations.

Contrôle d'accès et multi-tenance. Si votre corpus a une visibilité par utilisateur, par tenant ou par rôle, vous ne pouvez pas tout déverser. La récupération filtre selon la politique d'accès avant que le modèle ne voie les données. Non négociable pour les produits B2B.

Raisonnement multi-corpus. Quand la réponse combine un message Slack, une page Notion, un ticket Linear et une PR GitHub, la récupération est le pont.

Si votre produit coche l'une de ces cases, le RAG n'est pas optionnel. La question devient comment rendre la récupération bonne, pas s'il faut la faire.

---

Là où le contexte long l'emporte

Le contexte long a des charges de travail pour lesquelles il est la bonne réponse.

Raisonnement approfondi sur un seul document. Lire un contrat juridique de 100 pages et répondre à des questions qui traversent les clauses. Analyser un article de recherche. Résumer une conférence de résultats. Quand la bonne réponse relie deux paragraphes distants de 80 pages, la récupération rompt souvent ce lien. Le contexte long le préserve.

Compréhension de code à l'intérieur d'un dépôt. Beaucoup de tâches de raisonnement sur du code ont besoin simultanément des imports, des types, des définitions et des sites d'appel. Découper par fichier perd les relations inter-fichiers. Mettre le dépôt entier dans le contexte (quand il rentre) préserve la structure.

Continuité conversationnelle. Les sessions d'agents longue durée bénéficient d'un historique complet dans le contexte. La récupération sur l'historique conversationnel est fragile : on a souvent besoin des 50 derniers tours, pas des 50 tours les plus sémantiquement similaires.

Raisonnement exploratoire quand on ne connaît pas la requête. Si vous ne savez pas quoi demander à un document avant d'avoir commencé à raisonner dessus, la récupération est difficile à utiliser. Vous ne pouvez pas écrire la requête à l'avance. Le contexte long laisse le modèle parcourir la matière.

Renvois croisés dans une unité cohérente. Un chapitre de manuel, un article de recherche, un mémoire juridique : ce sont des entités logiquement unifiées. Découper puis réassembler perd souvent la structure argumentative.

Heuristique grossière : si vos données forment un seul document logique et qu'il rentre, le contexte long est l'architecture la plus propre.

---

Le pattern hybride qui fonctionne vraiment

Le standard 2026 pour les systèmes LLM sérieux n'est ni le RAG pur ni le contexte long pur. C'est un hybride : récupérer un ensemble de tokens substantiel mais borné, puis raisonner dessus en contexte long.

Voici le flux canonique :

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Pourquoi cela fonctionne : chaque étape gère le mode d'échec de l'autre. La récupération réduit un corpus trop gros pour toute fenêtre de contexte à un ensemble gérable. Le raisonnement en contexte long sur l'ensemble récupéré restaure le raisonnement multi-documents et multi-chunks que le RAG pur casse souvent quand il n'envoie que les 5 meilleurs chunks.

La décision d'ingénierie clé est la taille de l'ensemble récupéré. Envoyez trop peu de tokens et vous perdez le bénéfice du contexte long (autant faire du RAG top-5 classique). Envoyez-en trop et vous déclenchez le context rot. Les données de Chroma suggèrent que le plafond sûr est bien en dessous de la limite documentée du modèle, souvent par un facteur de 4 à 10. Un modèle à fenêtre de 200 K tient en général solidement jusqu'à 40 K à 80 K. Un modèle à fenêtre de 1 M peut souvent gérer 150 K à 300 K avec un rot minimal.

C'est le pattern d'architecture vers lequel la plupart des équipes livrant des fonctionnalités LLM à l'échelle ont convergé fin 2025. Ce n'est pas glamour, mais ça marche.

---

Régler l'hybride : chiffres et heuristiques

Mettons des chiffres sur les boutons. Ce ne sont pas des vérités universelles ; ce sont des points de départ qui fonctionnent en production pour beaucoup d'équipes.

Taille de chunk. 500 à 1 500 tokens par chunk pour la plupart des textes en prose. 200 à 500 pour le code (par fonction ou par bloc logique). 1 500 à 3 000 pour les textes juridiques ou académiques où le contexte à l'intérieur d'un chunk compte. Chevauchez les chunks de 10 à 20 %.

Récupération top-k. Tirez plus que ce que vous enverrez. Récupérez les 50 à 200 premiers, puis rerankez. Le reranker (un cross-encoder, souvent un petit modèle spécialisé comme Cohere Rerank ou un reranker BGE fine-tuné) coûte plus par paire que le modèle d'embedding mais est nettement plus précis sur la pertinence fine.

Ratio rerank/contexte. Après reranking, gardez les 20 à 100 meilleurs chunks pour l'étape de contexte long. Le nombre exact dépend de la taille des chunks et de votre budget de contexte sûr.

Récupération hybride. Combinez récupération dense (vecteurs) et éparse (BM25, SPLADE) avec une fusion de rangs réciproques. Le dense pur rate les requêtes à correspondance exacte (SKU, codes d'erreur, noms propres). Le sparse pur rate les paraphrases. L'hybride attrape les deux.

Budget de contexte sûr. Testez votre modèle. Construisez un petit jeu d'évaluation de questions dont la réponse exige un raisonnement sur plusieurs chunks à différentes longueurs de contexte. Mesurez la précision à 16 K, 32 K, 64 K, 128 K, 256 K tokens de contexte rempli. Choisissez la plus grande taille où la précision reste acceptable. C'est votre budget sûr. Restez 20 % en dessous en production pour garder une marge.

Contournez complètement la récupération. « Résume le document que je viens de téléverser » est une tâche mono-document. Détectez ces requêtes avec un petit classifieur et sautez la récupération ; cela économise de la latence et évite de faire remonter du bruit non pertinent.

Couche de résumé. Pour un très long historique (conversations sur plusieurs mois, grandes bases de code), interposez une étape de résumé qui compresse les éléments plus anciens avant l'assemblage. Les résumés coûtent aussi des tokens, alors testez si cela aide.

Voici un tableau comparatif qui capture les compromis :

---

Anti-patterns que les ingénieurs continuent de livrer

Quelques pièges reviennent assez souvent pour mériter d'être signalés.

« Il suffit de tout déverser dans le contexte. » Tentant après chaque sortie qui double la fenêtre. Les données de Chroma disent que cela se dégrade silencieusement. Vous passerez les vérifications ponctuelles et échouerez en production sur les requêtes qui exigent un raisonnement transversal. Faites toujours une évaluation à votre taille de contexte cible avant de livrer.

« Toujours utiliser le RAG. » Le RAG réflexe sur toutes les charges de travail rate les cas mono-document. Mettre un PDF de 50 pages dans un index vectoriel, puis récupérer les 5 meilleurs chunks, produit habituellement une moins bonne réponse que de donner le PDF entier au modèle. Heuristique : si un document unique tient dans votre budget de contexte sûr et que la requête porte sur ce document, sautez la récupération.

« Ignorer le nombre de tokens de l'ensemble récupéré. » Les équipes règlent top-k sur « tout ce qui rentre » et découvrent trois mois plus tard que leur prompt moyen fait 350 K tokens et que la précision s'est discrètement dégradée. Suivez la taille du contexte assemblé comme une métrique de premier ordre. Configurez des alertes.

« Faire confiance à la fenêtre documentée. » Une fenêtre de 1 M de tokens ne signifie pas que le modèle utilise 1 M de tokens aussi bien. La limite documentée est ce que vous pouvez techniquement envoyer. La limite utilisable est celle où le modèle tient encore votre barre de qualité. Ce sont des chiffres différents, souvent d'un ordre de grandeur.

« Sauter les évaluations parce que le modèle est bon maintenant. » Les mises à niveau des modèles de pointe changent le choix d'architecture optimal. Une charge de travail qui exigeait du RAG sur GPT-4-32K peut très bien fonctionner en contexte long avec Gemini 2.5 Pro. Réévaluez quand les modèles changent.

---

Ce que le matériel de 2026 change

Les fenêtres plus larges déplacent certaines décisions. Préciser lesquelles compte.

Llama 4 Scout à 10 M de tokens. Si le contexte utilisable n'est ne serait-ce que la moitié de la limite documentée, des corpus entiers de taille moyenne tiennent dans un seul prompt. Les assistants monolocataires sur une base de connaissances interne de 1 M de tokens peuvent sauter la récupération. L'économie compte toutefois : 5 M de tokens d'entrée sur un modèle de pointe coûtent cher par requête.

Gemini 2.5 / 3 Pro à 2 M de tokens. Une fenêtre de 2 M avec mise en cache de prompt change le calcul pour des workflows qui interrogent à répétition le même grand ensemble de documents. Mettez en cache 1,5 M de tokens de contexte d'arrière-plan, ne payez que la requête marginale, et le coût par requête commence à rivaliser avec la récupération.

Claude Sonnet 1M. Utile pour les charges agentiques où l'état de session grossit. Les agents conversationnels qui devaient résumer ou faire du RAG sur leur propre historique peuvent désormais garder plus d'historique brut en contexte.

Mise en cache de prompts chez les fournisseurs. Anthropic, Google et OpenAI prennent tous en charge la mise en cache d'entrée. Les architectures de contexte long deviennent beaucoup moins chères pour les requêtes répétées sur du contenu stable. L'avantage de coût du RAG rétrécit quand le cache entre en jeu, sans pour autant disparaître.

Ce qui n'a pas changé : le context rot. Aucune de ces sorties n'inclut de données de benchmark montrant que des fenêtres plus larges résolvent le problème du rot. Des fenêtres plus grandes relèvent le plafond, mais la même forme de dégradation persiste. Vous devez toujours mesurer votre budget sûr. Vous avez toujours besoin de récupération pour les charges fraîches, multi-tenant et multi-sources. L'hybride reste le bon réglage par défaut.

---

Un cadre de décision que vous pouvez réellement appliquer

Voici un flux que vous pouvez appliquer à toute nouvelle fonctionnalité LLM. Parcourez-le de haut en bas.

Étape 1 : quelle est la taille de votre corpus ?

• Moins de 100 K tokens au total : sautez la récupération, utilisez directement le contexte long.
• 100 K à 1 M de tokens : dépend de la fraîcheur (passez à l'étape 2).
• Plus de 1 M de tokens : la récupération est obligatoire.

Étape 2 : à quel point les données doivent-elles être fraîches ?

• Mises à jour à l'heure ou plus rapides : récupération. Les prompts en contexte long sont trop coûteux à reconstruire.
• Mises à jour quotidiennes à hebdomadaires : les deux patterns fonctionnent.
• Statique ou rarement mis à jour : le contexte long avec mise en cache de prompt est bon marché et propre.

Étape 3 : quelle est la forme de la requête ?

• Raisonnement profond sur un seul document : penchez pour le contexte long.
• Synthèse multi-documents : penchez pour l'hybride.
• Recherche ou récupération de fait : penchez pour le RAG classique (top-k, petit contexte).
• Exploratoire ou ouvert : penchez pour le contexte long si l'ensemble de documents est borné ; sinon hybride.

Étape 4 : avez-vous besoin de citation ou de contrôle d'accès ?

• Oui à l'une ou l'autre : la récupération est obligatoire (RAG classique ou hybride). Les architectures uniquement en contexte long sont très difficiles à équiper après coup de citations et de filtrage par utilisateur.

Étape 5 : quel est votre budget de latence ?

• Moins d'une seconde : RAG classique (petit contexte, rapide).
• 1 à 5 secondes : l'hybride est faisable.
• Plus de 5 secondes : n'importe quel pattern fonctionne.

Étape 6 : quel est votre plancher de précision sur les requêtes longues ?

• Précision élevée sur un raisonnement multi-étapes au-delà de 50 K tokens : hybride avec reranker.
• Au mieux possible : le RAG classique fait l'affaire.

Parcourez ces six étapes et vous atterrirez sur l'une des trois architectures : RAG top-k classique, contexte long pur ou hybride. La plupart des systèmes en production pour des charges sérieuses atterrissent sur l'hybride. Pas parce que l'hybride est universellement meilleur, mais parce que les charges réelles ont en général au moins une contrainte (données multi-tenant, fraîcheur, coût, citation) qui casse le contexte long pur, et au moins une (raisonnement mono-doc, requêtes transversales, exploration) qui casse le RAG top-k pur.

L'article de Chroma a changé le discours. Il a rendu le débat contexte long contre RAG un peu gênant rétrospectivement. Ce ne sont pas des concurrents ; ce sont deux des trois composants d'une pile LLM qui fonctionne, et le troisième (le reranking) est ce qui rend l'hybride stable.

---

Questions fréquemment posées

La fenêtre de contexte de 2 M de Gemini a-t-elle tué le RAG ?

Non. La fenêtre de 2 M de tokens est réelle, mais l'article « Context Rot » de Chroma a démontré que les performances se dégradent bien avant que la fenêtre ne soit remplie. Les budgets de contexte sûr en pratique pour les modèles à fenêtre de 2 M se situent typiquement entre 150 K et 400 K tokens pour les charges de haute précision, ce qui est bien moins que la limite affichée. Le RAG (ou le pattern hybride récupérer-puis-raisonner) reste la bonne architecture pour les corpus volumineux, multi-documents, frais ou multi-tenants.

Qu'est-ce que le context rot, en termes simples ?

Le context rot est le constat selon lequel les LLM utilisent le contexte long moins bien que ne le suggèrent les supports marketing. À mesure que vous ajoutez des tokens, la précision sur les tâches de récupération et de raisonnement se dégrade de façon non linéaire. Cela empire plus vite quand le texte distracteur est sémantiquement proche de la réponse, et même un texte d'entrée cohérent et bien structuré peut nuire à l'attention davantage qu'un texte mélangé. Le résultat : remplir une fenêtre de 1 M de tokens ne vous donne pas une réponse de qualité 1 M de tokens.

Quelle doit être la taille de mon ensemble récupéré avant que le context rot ne s'installe ?

Testez votre modèle précis. Un point de départ grossier : restez entre 20 et 40 % de la fenêtre de contexte documentée pour les charges de haute précision. Pour un modèle à fenêtre de 200 K, cela fait 40 K à 80 K tokens de récupération. Pour un modèle à fenêtre de 1 M, 200 K à 400 K. Construisez un petit jeu d'évaluation de questions à raisonnement multi-sauts et mesurez la précision à différentes tailles de contexte. Choisissez la plus grande taille où la précision reste dans votre fourchette de qualité.

La mise en cache de prompts change-t-elle le calcul ?

Oui, de façon significative. La mise en cache de prompts (disponible chez Anthropic, Google et OpenAI) rend le coût marginal des requêtes en contexte long sur du contenu stable bien moins cher. Si vous pouvez mettre en cache un grand ensemble de documents d'arrière-plan et ne payer que la différence par requête, le contexte long devient économiquement compétitif avec la récupération pour des corpus relativement statiques. La mise en cache, cependant, ne corrige pas le context rot : un contexte long mis en cache reste un contexte long, avec la même dégradation de précision.

Faut-il utiliser un reranker avant d'envoyer en contexte long ?

Pour la plupart des systèmes hybrides en production, oui. Un reranker (modèle cross-encoder qui note les paires requête-document) sur vos 50 à 200 meilleurs chunks récupérés améliore considérablement la pertinence de ce que vous passez à l'étape de contexte long. Sauter le rerank revient souvent à entasser plus de tokens pour compenser une moindre précision, ce qui vous pousse vers la zone de rot. Le rerank est l'une des améliorations les plus à fort levier que vous puissiez apporter à un pipeline hybride.

---

En conclusion

Ce qui est séduisant à chaque nouvelle sortie de modèle avec une fenêtre plus grande, c'est la promesse implicite : « arrêtez d'ingénier, contentez-vous de tout déverser ». L'article de Chroma a mis des chiffres durs sur la raison pour laquelle cette promesse n'a pas été tenue, et les mathématiques sous-jacentes (dilution du softmax, extrapolation des encodages de position, distribution d'entraînement) suggèrent qu'elle ne sera pas tenue proprement même quand les fenêtres de contexte atteindront 100 M de tokens.

Ce qui nous reste, c'est la réponse ennuyeuse et productive. Construisez de la récupération. Réglez-la. Ajoutez un reranker. Choisissez un budget de contexte sûr en mesurant, pas en faisant confiance à la fiche technique. Envoyez au modèle l'ensemble de tokens le plus petit et le plus pertinent qui contient effectivement la réponse. Laissez-le raisonner dessus. Citez les sources.

C'est moins excitant que « l'AGI est là, collez juste votre base de code », mais cela livre des fonctionnalités qui fonctionnent en production. Les équipes qui construisent discrètement de bons produits LLM en 2026 sont celles qui ont traité le récit du contexte long avec scepticisme, et le récit du RAG avec le même scepticisme, et qui ont fini avec des pipelines hybrides qui gèrent les charges qu'elles ont réellement.

Les décisions d'architecture durent plus longtemps que les sorties de modèles. Prenez-les correctement et la prochaine mise à niveau de modèle sera une amélioration gratuite plutôt qu'une réécriture forcée.