RAG en entreprise : les 7 décisions d'architecture qui changent tout
Au-delà du POC : comment structurer un RAG production-ready, du chunking à l'observabilité, sans réinventer ce qui existe.
La majorité des projets RAG en entreprise échouent non pas à cause du modèle, mais à cause de décisions d'architecture prises trop tôt ou trop tard. Après plus de 30 implémentations, nous avons identifié 7 décisions structurantes qui déterminent la trajectoire du projet.
1. Stratégie de chunking : la taille et la sémantique des chunks conditionnent la précision de la recherche. Un découpage trop fin fragmente le contexte, trop large dilue la pertinence.
2. Choix du vector store : Pinecone, Qdrant, pgvector, Weaviate — chaque solution implique des compromis entre latence, coût et capacité d'évolution.
3. Modèle d'embeddings : open-source ou propriétaire, multilingue ou spécialisé — le bon choix dépend du corpus et des contraintes de souveraineté.
4. Stratégie de re-ranking : ajouter une étape de re-ranking améliore drastiquement la pertinence finale, au prix d'une latence supplémentaire.
5. Garde-fous et hallucinations : grounding, citations, scoring de confiance — comment encadrer les réponses sans rigidifier l'expérience.
6. Observabilité : tracer chaque requête, mesurer la pertinence, détecter la dérive du corpus est indispensable en production.
7. Gouvernance des sources : qui peut indexer quoi, comment gérer les ACL, comment versionner les corpus.
Ces 7 décisions, prises ensemble et tôt dans le projet, font la différence entre un POC séduisant et un système réellement adopté.
