Modèles hybrides RAG + SQL : réconcilier les données textuelles et structurées
Une architecture pratique pour combiner recherche vectorielle et requêtes SQL sans perdre traçabilité, permissions ni contrôle métier.
Les premiers projets RAG en entreprise ont souvent été construits autour d'une idée simple: indexer des documents, retrouver les passages pertinents, puis demander au modèle de répondre avec contexte. Cette approche fonctionne bien pour des politiques internes, des bases de connaissance ou des contrats. Elle devient moins robuste quand la question mélange du texte et des données structurées: chiffre d'affaires, stocks, tickets, transactions, niveaux de service, droits d'accès ou historiques client.
Un modèle hybride RAG + SQL répond à ce problème. Il ne cherche pas à forcer toutes les données dans une base vectorielle. Il sépare les sources selon leur nature: les documents restent dans un index de recherche, les données relationnelles restent dans leurs bases contrôlées, et une couche d'orchestration décide quel outil interroger. Le gain n'est pas seulement technique. Il touche la fiabilité, l'auditabilité et la sécurité des réponses.
1. Pourquoi le RAG seul atteint vite ses limites
La recherche vectorielle est efficace pour retrouver des passages sémantiquement proches. Elle est beaucoup moins adaptée aux questions qui exigent un calcul exact: totaliser des ventes, filtrer par date, croiser une région et un statut, compter des incidents, appliquer une règle de droits ou respecter une jointure métier. Transformer une table SQL en fragments textuels peut dépanner, mais cela dégrade souvent la précision.
Le RAG seul pose aussi un problème de fraîcheur. Une base documentaire est souvent réindexée par lots; une base transactionnelle change en continu. Si l'assistant répond sur des indicateurs opérationnels, il doit interroger le système de référence ou une réplique gouvernée, pas une approximation textuelle.
2. Le rôle critique du routeur
Le routeur est le composant qui décide si une question relève du texte, du SQL ou des deux. Une demande comme "quelles clauses limitent la résiliation ?" peut passer par le RAG. Une demande comme "combien de contrats expirent dans 90 jours ?" relève du SQL. Une demande comme "quels contrats stratégiques expirent bientôt et quelles clauses posent problème ?" nécessite les deux.
Ce routeur ne doit pas être une simple instruction de prompt. Pour les cas sensibles, il doit s'appuyer sur des schémas autorisés, des fonctions contrôlées, des exemples de requêtes, des règles de permissions et un journal d'exécution. L'objectif est d'éviter que le modèle improvise des jointures, expose des colonnes sensibles ou produise une requête impossible à auditer.
3. Sécuriser les accès avant de générer la réponse
Dans un assistant hybride, les droits d'accès sont plus complexes que dans un chatbot documentaire. L'utilisateur peut avoir le droit de lire une procédure, mais pas les données client détaillées. Il peut accéder à des agrégats, mais pas aux lignes individuelles. Il peut consulter une région, mais pas une autre.
La bonne architecture applique les contrôles avant la récupération. Les ACL documentaires filtrent les passages accessibles. Les requêtes SQL sont générées ou sélectionnées dans un périmètre autorisé. Les logs conservent la question, les sources consultées, les requêtes exécutées et la réponse produite. Sans cette chaîne, la traçabilité devient fragile.
4. Fusionner sans masquer l'incertitude
La fusion des résultats est le moment où beaucoup d'assistants deviennent trop confiants. Un document peut expliquer une règle générale tandis que SQL donne une valeur chiffrée. Si les deux se contredisent, le système doit le signaler. Si la requête SQL porte sur un périmètre incomplet, la réponse doit l'indiquer. Si un document n'est pas récent, sa date doit apparaître.
Un bon assistant hybride cite donc ses sources textuelles, décrit les filtres SQL utilisés et distingue les faits calculés des interprétations générées. Cette discipline donne à l'utilisateur une réponse actionnable sans lui faire croire que le modèle possède une vérité globale.
5. Où commencer
Le meilleur point de départ n'est pas un assistant universel. C'est un domaine où les documents et les données tabulaires se complètent: support client, finance, achats, conformité, contrats, supply chain ou reporting ESG. Il faut choisir quelques questions représentatives, cartographier les sources, définir les droits et mesurer la précision sur un jeu de tests.
La métrique clé n'est pas seulement la satisfaction utilisateur. Il faut suivre le taux de routage correct, les requêtes SQL valides, les réponses sourcées, les refus appropriés et les erreurs de périmètre. Le modèle hybride devient alors un système observable, pas une boîte noire conversationnelle.
Conclusion
RAG + SQL n'est pas une sophistication d'architecte. C'est souvent la condition pour rendre un assistant IA utile dans les métiers où les décisions reposent à la fois sur des textes et sur des chiffres. La valeur vient de la séparation des responsabilités: au modèle la compréhension et la synthèse; aux systèmes de données la vérité structurée; à l'orchestration la sécurité, le routage et la traçabilité.
