RAG sur un SI .NET existant : trois décisions qui changent tout

La plupart des tutoriels RAG partent d’un notebook vide et d’une base fraîche : Postgres tout neuf, documents propres déjà découpés, aucune contrainte d’accès à respecter. Un client sous SI Microsoft part d’un autre point : un SQL Server de quinze ans, une application en production, des habilitations déjà en place et un audit de sécurité qui ne pardonne pas les raccourcis. Dans ce contexte, la vraie question n’est pas quel grand modèle de langage choisir. C’est où et comment brancher la récupération d’information sans casser ce qui tient déjà.

Trois décisions changent tout quand on intègre un RAG dans un contexte .NET / SQL Server.

Le stockage vectoriel n’a pas besoin de sortir de l’existant

Le réflexe le plus courant consiste à provisionner une base vectorielle dédiée, souvent hors du périmètre applicatif existant. Ce choix duplique un problème déjà résolu ailleurs dans le SI : qui a le droit de voir quel document. Un index vectoriel directement dans SQL Server, ou un service comme Azure AI Search positionné à côté de la base existante, permet de réutiliser les règles d’accès déjà en place plutôt que d’en recréer une copie divergente. La question à se poser en premier n’est pas la performance du moteur de similarité, c’est l’endroit où vit déjà la source de vérité des habilitations.

Le découpage suit la structure métier, pas une fenêtre de tokens

La plupart des guides RAG découpent les documents en morceaux de taille fixe, calibrés sur le nombre de tokens accepté par le modèle. Ce découpage générique ignore la structure du document. Une clause contractuelle coupée en deux, une section de rapport tronquée au milieu d’un tableau : le modèle reçoit un fragment incomplet et répond à côté, même avec le meilleur LLM du marché. Le découpage doit suivre la structure métier déjà connue : les clauses d’un contrat, les sections d’un rapport, les paragraphes d’une procédure. C’est souvent la partie la moins visible du travail, et celle qui détermine le plus la qualité des réponses.

L’orchestration reste dans la couche service .NET

Le troisième réflexe à éviter : sortir la logique de récupération dans un microservice Python séparé, greffé à côté de l’application existante. Cette architecture semble neutre techniquement, mais elle recrée en silence un second système d’autorisation, avec ses propres règles, souvent moins auditées que celles de l’application principale. Avec Semantic Kernel, l’orchestration reste dans la couche service .NET déjà en place : mêmes vérifications d’accès, même journalisation, même cycle de déploiement que le reste de l’application. Le RAG devient une capacité de plus dans un système déjà gouverné, pas un projet parallèle avec ses propres règles.

Ce que je ne referais pas

Traiter le RAG comme un projet à part : sa propre base, ses propres droits d’accès, découplé du reste du système d’information. Ce montage fonctionne très bien en démonstration. Il devient un problème de sécurité et de maintenance dès qu’il touche à la production, au moment où plus personne ne se souvient exactement qui a accès à quoi.

Le RAG ne demande pas de reconstruire l’existant. Il demande de le respecter : réutiliser les habilitations en place, respecter la structure métier des documents, garder l’orchestration dans la couche qui est déjà auditée. C’est une question d’architecture avant d’être une question de modèle.