2026¶

Sécuriser un RAG : injection, fuites de données, RBAC

Sécuriser un RAG, c'est plus simple qu'un audit de sécurité classique, et plus difficile qu'on le croit

Un RAG en production, c'est trois composants qui s'enchaînent : un retriever qui cherche dans vos documents, un contexte injecté dans un prompt, un LLM qui génère une réponse. Chacun de ces trois maillons est un vecteur d'attaque distinct. Ignorer l'un des trois, et votre système est vulnérable, même si les deux autres sont parfaitement sécurisés.

La bonne nouvelle : la moitié des garde-fous ne coûtent rien. La mauvaise : l'autre moitié demande une vraie refonte architecturale si vous n'y avez pas pensé dès le début.

LLM-as-a-judge : quand l'utiliser, avec le coût réel en €

Ce qu'est un LLM-as-a-judge, en une phrase citable

Un LLM-as-a-judge, c'est un second modèle de langage qui évalue la sortie d'un premier modèle selon une grille de critères explicites : pertinence, fidélité aux sources, complétude, ton. Il produit un score et une justification. C'est tout.

Ce mécanisme est utile. Mais il est cher, lent, et biaisé si on l'applique sans discernement. La question n'est pas "est-ce que je dois utiliser un juge LLM" mais "à quel endroit de mon pipeline, à quelle fréquence, avec quel modèle".

La règle que j'applique sur mes missions : les tests déterministes d'abord, le juge LLM en dernier recours, jamais dans la boucle de développement rapide.

Tester un LLM avec des tests unitaires : regex, longueur, entités

Avant de payer un juge LLM, testez comme un développeur

Avant de sortir un LLM-as-judge à 0,60 $ du million de tokens, 80 % des régressions d'un système LLM se détectent avec des assertions gratuites et instantanées : format de sortie incorrect, réponse trop courte, entité attendue absente, JSON invalide, mot interdit présent. Ces vérifications ne nécessitent pas d'IA pour évaluer de l'IA. Elles se codent en 10 lignes de Python et se branchent sur n'importe quelle pipeline CI/CD avec pytest.

C'est l'approche que j'applique systématiquement avant de mettre en place un évaluateur sémantique sur mes missions. Cet article couvre les assertions qui attrapent le plus de bugs, comment les organiser en suite pytest, et à quel moment il faut effectivement passer à l'étage supérieur.

Construire un dataset d'évaluation RAG en 30 minutes

Un dataset imparfait bat l'absence totale de mesure

Pas besoin de semaines d'annotation ou d'un expert métier disponible dès la première heure. En 30 minutes, vous pouvez générer un dataset de départ exploitable directement depuis vos chunks, mesurer le recall@k, et lancer un premier cycle d'amélioration.

Ce dataset sera imparfait. C'est normal et c'est acceptable. L'objectif n'est pas la perfection : c'est d'avoir une mesure reproductible plutôt que le vide. Un recall@5 de 0.71 mesuré sur 50 questions synthétiques vous dit déjà infiniment plus que "ça marche à peu près en démo".

La méthode que je décris ici se déroule en quatre étapes : générer les questions depuis vos chunks, calculer le recall@k, itérer sur le retrieval (hill climbing), et intégrer les retours "pas pertinent" comme hard negatives pour le reranker. Pour les métriques de génération (faithfulness, answer relevancy, context recall) et le choix entre RAGAS, DeepEval et TruLens, voir Évaluer un RAG en production : métriques et RAGAS.