Une liste circule depuis quelques mois sur LinkedIn : « 8 architectures RAG que tout ingénieur IA doit connaître ». Le contenu est juste. Le cadrage l’est moins. Il laisse penser qu’intégrer le RAG dans une organisation revient à choisir parmi huit options techniques de valeur équivalente. Dans un vrai projet, ce n’est pas la question qui se pose en premier.
Pour une PME, une OBNL ou une institution, la vraie question est : ai-je besoin d’aller plus loin que l’architecture la plus simple ? La réponse est non, dans la majorité des cas. Mais comprendre les huit architectures permet de savoir quand le « non » devient « oui ».
Le RAG, sans le jargon
RAG veut dire « génération augmentée par la récupération ». Derrière le sigle, une idée simple : un modèle de langage comme ChatGPT ou Claude ne connaît que ce qu’il a vu pendant son entraînement. Il ignore vos contrats, vos procédures internes, votre catalogue de produits, vos comptes rendus de réunion.
Le RAG comble ce vide. Plutôt que de réentraîner un modèle, ce qui coûte cher et se justifie rarement, on lui donne accès à vos documents au moment où il répond. Quand une question arrive, le système va chercher les passages pertinents dans votre base, puis les fournit au modèle pour qu’il formule sa réponse à partir de cette matière.
C’est ce mécanisme qui transforme un assistant générique en assistant qui connaît votre organisation. Les huit architectures sont huit façons de faire cette récupération, de la plus directe à la plus élaborée. Je les présente ici dans l’ordre où la complexité s’ajoute, de la plus simple à la plus complexe.
1. Naive RAG
Le système transforme chaque document en une suite de coordonnées qui représentent son sens. Quand une question arrive, il la transforme de la même façon et récupère les passages dont les coordonnées sont les plus proches.
C’est efficace pour des questions factuelles directes : « Quelle est notre politique de remboursement ? » ou « Quels sont les horaires du service client ? ». La majorité des projets devraient commencer ici, et beaucoup n’ont jamais besoin d’autre chose.
2. HyDE (Hypothetical Document Embeddings)
HyDE répond à un défaut connu du Naive RAG : une question et sa réponse sont souvent formulées de manières très différentes. Le système génère d’abord une réponse hypothétique à la question, puis utilise cette réponse fictive pour retrouver les vrais documents.
Utile quand vos utilisateurs posent des questions courtes alors que vos documents sont rédigés en langage technique.
3. Corrective RAG
Cette architecture vérifie chaque passage récupéré avant de le transmettre au modèle, en le confrontant à une source de confiance comme une recherche web. Elle filtre ou corrige les passages douteux.
À considérer quand l’exactitude et la fraîcheur de l’information ne tolèrent aucune erreur, par exemple un tarif affiché ou une obligation réglementaire.
4. Multimodal RAG
Le système travaille au-delà du texte : images, audio, schémas. Une question écrite peut alors recevoir une réponse qui combine un paragraphe et un plan technique.
Pertinent pour les catalogues visuels, les manuels illustrés ou les dossiers qui mêlent texte et photos.
5. Graph RAG
Cette architecture ne se contente pas de retrouver des passages isolés. Elle reconstruit les relations entre les entités : quel produit dépend de quel fournisseur, quelle décision découle de quelle réunion. Le modèle raisonne mieux parce qu’il reçoit une structure et pas seulement des extraits.
À considérer quand la valeur de vos données tient à la façon dont elles sont reliées entre elles.
6. Hybrid RAG
Cette architecture combine la recherche par similarité et la recherche par graphe dans un même pipeline. On l’utilise quand une réponse exige à la fois du texte libre et des relations structurées.
C’est souvent le bon compromis pour les organisations dont les données sont riches mais encore mal reliées entre elles.
7. Adaptive RAG
Le système décide lui-même du chemin. Une question simple reçoit une récupération directe. Une question complexe est découpée en sous-questions traitées une à une. L’effort s’ajuste à la difficulté réelle.
Utile quand vos utilisateurs mélangent des demandes triviales et des demandes qui exigent un vrai raisonnement.
8. Agentic RAG
L’architecture la plus avancée. Des agents dotés de mémoire et de capacités de planification orchestrent la récupération à travers plusieurs sources, appellent des outils externes et combinent au besoin les techniques précédentes.
C’est la réponse aux flux de travail complexes, et aussi la plus difficile à construire et à maintenir dans la durée.
L’usage réel dans votre organisation
Le tableau a beau s’allonger, l’usage réel se concentre. Un assistant qui répond aux clients à partir de votre documentation, une base de connaissances interne consultable en langage naturel, un outil qui résume vos dossiers : dans ces cas, un Naive RAG bien exécuté ou un Hybrid RAG suffit presque toujours.
La sophistication n’apporte de valeur que lorsqu’un problème concret l’exige. Vos documents parlent une langue différente de celle de vos utilisateurs ? HyDE. Vous ne pouvez tolérer aucune information périmée ? Corrective RAG. Vos données ne valent que par leurs relations ? Graph ou Hybrid. Tant qu’aucun de ces problèmes ne se manifeste, ajouter de la complexité revient à payer pour une capacité que personne n’utilise.
Points de vigilance
La qualité de la récupération dépend d’abord de la qualité de vos données. Une base mal organisée, des documents en double, des versions contradictoires : aucune architecture ne corrige cela. La plupart des projets RAG échouent ici, pas sur le choix de l’architecture.
Chaque niveau de sophistication ajoute un coût et une latence. Agentic RAG peut multiplier le nombre d’appels au modèle pour une seule réponse, ce qui se ressent sur la facture et sur le temps d’attente.
Le RAG réduit les réponses inventées sans les supprimer. Un modèle peut toujours mal interpréter un passage pourtant correct. Une validation humaine reste nécessaire sur les sujets sensibles.
Enfin, plus l’architecture est complexe, plus elle demande de maintenance. Un agent qui orchestre cinq sources est un système à surveiller, pas un outil qu’on installe et qu’on oublie.
Ce que vous devriez faire maintenant
Commencez par une question. Quel problème concret voulez-vous résoudre, et pour qui ?
Vérifiez ensuite l’état de vos données. Un mois passé à nettoyer et organiser votre documentation vaut souvent plus que le choix d’une architecture avancée.
Construisez d’abord la version la plus simple qui répond au besoin. Mesurez sa qualité sur de vraies questions de vos utilisateurs. N’ajoutez de la complexité que là où les résultats sont insuffisants, et seulement là.
Conclusion
Les huit architectures ne sont pas huit options à comparer le jour où vous lancez un projet. Elles forment un escalier : on commence par la marche la plus basse et on ne monte que lorsqu’un problème précis l’impose. Confondre « connaître les huit » et « avoir besoin des huit » est l’erreur la plus coûteuse que j’observe en ce moment autour du RAG.
La technologie disponible n’a jamais été aussi puissante. Ce qui fait la différence reste la clarté du problème que vous cherchez à résoudre.
Vous souhaitez intégrer l’IA à vos données sans tomber dans la sur-ingénierie ? FD Stratégies peut vous aider à cadrer le besoin, préparer vos données et construire la solution juste pour votre organisation.
