Le marché des outils pour construire un RAG est saturé, et c’est un problème en soi. Chaque semaine apporte un nouveau framework, une nouvelle base vectorielle, un nouveau tutoriel qui affirme détenir la bonne architecture. Face à ce bruit, beaucoup d’équipes perdent des semaines à comparer des outils au lieu de construire un système. La décision est présentée comme décisive ; elle l’est rarement.
Un stack RAG se décompose en deux couches qui n’ont pas les mêmes enjeux. La première, le framework d’orchestration, gère le découpage des documents, l’indexation et l’enchaînement des appels au modèle. La seconde, la base vectorielle, stocke les embeddings et exécute la recherche de similarité. On peut changer la première en quelques jours ; changer la seconde coûte plus cher, parce qu’elle contient les données.
Cet article passe les principales options au crible de critères concrets : le coût, la complexité d’exploitation, et le risque de dépendance. Vous y trouverez un comparatif honnête, sans classement flatteur, et une conclusion qui peut surprendre : le choix du framework est moins important que la qualité des données et la rigueur de l’évaluation.
Le framework d’orchestration compte moins que vous ne le croyez
LangChain, LlamaIndex, Haystack : ces trois noms reviennent partout, et ils se ressemblent plus qu’ils ne diffèrent. Tous trois découpent des documents, génèrent des embeddings, interrogent une base vectorielle et composent un prompt. Ce sont des boîtes à outils, pas des architectures, et les différences se jouent surtout dans la philosophie d’assemblage et la maturité des composants.
LangChain est le plus répandu, donc le mieux documenté, mais son abstraction pèse quand on sort des cas standards. LlamaIndex est plus centré sur la donnée et l’indexation, ce qui convient aux systèmes très documentaires. Haystack est le plus sobre et le plus proche d’une vraie chaîne de production, avec une séparation nette entre composants et pipeline. Aucun des trois n’est intrinsèquement meilleur : c’est votre cas d’usage qui départage.
La vérité à retenir est dérangeante pour qui cherche le bon outil : pour un premier RAG, un script Python d’une centaine de lignes qui appelle directement l’API d’un modèle et une base vectorielle suffit souvent. Le framework apporte de la structure quand le système grossit, pas au début.
La base vectorielle, le vrai choix structurant
La base vectorielle est le choix qui engage, parce que c’est là que vivent les données et que se joue la latence de recherche. Les critères qui comptent sont simples : la taille prévisible de l’index, le volume de requêtes, la nécessité d’un filtrage par métadonnées, et la compétence de l’équipe à l’exploiter. Ces critères éliminent la plupart des options avant même de comparer les performances.
Le filtrage par métadonnées mérite une attention particulière. Un RAG d’entreprise ne cherche presque jamais dans tout l’index : il cherche dans les documents d’un client, d’un pays, d’une période. Si la base vectorielle ne sait pas filtrer efficacement avant la recherche de similarité, elle force à charger des passages inutiles et dégrade à la fois la latence et la justesse. C’est un critère plus discriminant que les benchmarks de vitesse pure.
Toutes les bases sérieuses renvoient des résultats en quelques millisecondes sur des index de quelques centaines de milliers de passages. La différence se joue ailleurs : dans la facilité à faire évoluer le schéma, à sauvegarder, à surveiller.
Les options de bases vectorielles, sans classement marketing
Plutôt qu’un classement, voici une grille honnête fondée sur la maturité d’exploitation. pgvector, l’extension de PostgreSQL, est le choix le plus rationnel pour une équipe qui possède déjà Postgres : une seule base, une seule sauvegarde, un seul modèle de données. Ses performances sont suffisantes jusqu’à quelques millions de passages, ce qui couvre la grande majorité des cas réels.
Qdrant et Weaviate occupent une place intermédiaire : des bases dédiées, plus rapides sur de gros volumes et avec un filtrage plus riche, mais qu’il faut héberger et exploiter soi-même. Elles conviennent quand le volume et la latence deviennent réellement contraignants, pas avant. Pinecone et les services managés équivalents retirent la charge d’exploitation mais ajoutent un coût récurrent et une dépendance à un fournisseur, ce qui se justifie quand l’équipe est petite et le produit déjà en production.
Milvus et les solutions de très grande échelle ne concernent que les index de plusieurs dizaines de millions de passages, une situation rare. Le conseil est donc simple : commencez par ce que vous savez déjà exploiter, et ne migrez que lorsque les chiffres, mesurés, l’exigent.
Le débat managé contre auto-hébergé
Le choix entre service managé et auto-hébergé est un choix de compétence autant qu’un choix de coût. Un service managé facture la tranquillité : pas de mise à jour, pas de sauvegarde à surveiller, pas de panne à diagnostiquer la nuit. Un auto-hébergé facture le temps d’une personne qui sait l’exploiter, ou le risque d’en confier la charge à quelqu’un qui ne sait pas.
Pour une PME, la réponse honnête est souvent l’auto-hébergé sur une technologie déjà connue, comme pgvector sur un Postgres existant. Le coût marginal est faible, la dépendance est nulle, et la charge d’exploitation reste dans les compétences de l’équipe. Le managé se justifie quand l’équipe n’a personne pour administrer une base, ou quand les garanties de disponibilité deviennent contractuelles, par exemple pour un produit vendu à de grands comptes.
La règle de décision est la même que partout : on n’achète pas de la technologie, on achète un risque en moins. Si le risque d’exploiter est déjà couvert par vos compétences, ne le rachetez pas à un fournisseur.
Ce qui compte réellement : la donnée et l’évaluation
Quel que soit le stack, deux choses dominent le résultat final, et aucune n’est un choix d’outil. La première, c’est la qualité des sources, traitée dans un article dédié de ce blog : des documents propres, datés, dédupliqués et bien structurés. La seconde, c’est l’évaluation : un jeu de questions de référence qui mesure si le système répond juste, et qu’on exécute à chaque changement.
Ces deux éléments expliquent pourquoi tant d’équipes obtiennent de bons résultats avec des stacks modestes, et d’autres des résultats médiocres avec des stacks à la pointe. La différence n’est pas dans l’outil, elle est dans la discipline. On peut construire un RAG performant avec pgvector et un script Python, et un RAG médiocre avec la pile la plus sophistiquée du marché.
C’est une bonne nouvelle pour qui hésite : le coût d’un mauvais choix de stack est limité tant qu’on garde la donnée propre et l’évaluation en place. On peut changer de framework ou de base sans perdre ces deux acquis.
L’accompagnement Agenticiel pour choisir sans se tromper
Choisir un stack RAG est une décision qui engage la donnée, et il est utile de la prendre avec des gens qui en ont déjà construit plusieurs. Agenticiel aide les PME et les éditeurs à retenir la pile la plus simple qui couvre leur cas réel, ni plus ni moins, et à la mettre en production avec l’évaluation qui va avec.
Nous partons de votre situation réelle : volumes, contraintes, compétences existantes, exigences de disponibilité. Nous en déduisons une architecture sobre, souvent plus simple que ce que le marché suggère, et nous la construisons avec vous, données et évaluation comprises. Le travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar, qui échange avec vous dans votre langue et sur vos horaires. La sous-traitance de développement rend ce chantier accessible à des budgets de PME, sans renoncer à la rigueur de production.
Notre approche consiste à choisir le stack le plus simple qui tient la charge, puis à investir là où le résultat se joue vraiment : dans la donnée et dans la mesure.