Un RAG mal segmenté peut révéler à l’utilisateur A des documents de l’utilisateur B. Un document piégé peut tenter de détourner l’assistant. Une IA locale exposée sans auth devient un service public involontaire. Ce guide liste menaces, cas concrets et parades. Ressource régionale utile : CSIRT Hauts-de-France. IAHDF n’est pas un prestataire SSI.
Menaces principales
Fuite transversale : recherche documentaire sans filtre de droits. Injection via document : instructions cachées dans un PDF. Injection via prompt utilisateur. Empoisonnement de base. Exposition réseau sans authentification. Journaux trop verbeux. Modèle qui reformule des secrets présents dans le contexte. Ces menaces se combinent : un service local exposé plus un corpus mal segmenté est un scénario classique, pas une hypothèse exotique.
À Lille, une équipe a indexé un partage entier « pour aller vite » et découvert des fuites entre services. Geste : nommer trois menaces prioritaires pour votre cas avant d’écrire une ligne de code. Piège : croire que le local efface le besoin de contrôles — voir aussi local/cloud. Le lieu d’hébergement n’est pas un niveau de maîtrise.
Cas concrets
Stagiaire qui interroge le bot et obtient un élément RH via un extrait mal filtré. Fournisseur qui envoie un PDF avec une consigne du type « ignore previous instructions ». Serveur d’interface locale ouvert sur Internet « le temps du test ». Logs qui enregistrent des prompts complets contenant des données personnelles. À Amiens, un « lab » oublié est resté accessible plus longtemps que prévu. Ces cas servent de scénarios de tabletop, pas de folklore.
Geste : rejouer deux comptes de droits différents avec des documents marqueurs avant tout élargissement. Piège : considérer les incidents comme des erreurs humaines isolées plutôt que des défauts de conception. Reliez chaque cas à une ligne de la checklist plus bas. Si vous ne pouvez pas citer un propriétaire incident, vous n’êtes pas prêts pour la production.
Parades concrètes
Filtrer la recherche par identité et rôles. Séparer les corpus. Inspecter les documents sensibles avant indexation. Limiter les outils — pas d’exécution de code risquée sans bac à sable. Authentification forte, chiffrement en transit, pas d’exposition publique inutile. Revue des prompts système. Jeux de tests adverses. Politique de journaux. Mises à jour suivies. Aucune parade n’est parfaite ; l’objectif est de réduire le risque et de détecter.
À Roubaix, une PME a séparé physiquement un espace commercial et un espace RH. Geste : un test d’injection documentaire dans le calendrier de release. Piège : accumuler des outils de monitoring sans corriger l’absence de filtre de droits au retrieve. Formez aussi les contributeurs du corpus : un PDF marketing externe mérite plus de méfiance qu’une procédure interne contrôlée. Croisez avec RAG ou fine-tuning pour ne pas complexifier inutilement.
Droits d’accès : le cœur
Si votre GED a des droits, le RAG doit les respecter au moment du retrieve, pas « à peu près ». Dupliquer les fichiers dans un espace unique sans métadonnées de droit est une régression de sécurité. Documentez le mapping identité → corpus visibles. Testez-le comme vous testeriez un partage de fichiers classique. À Valenciennes, l’oubli de ce mapping a transformé un assistant utile en incident de gouvernance.
Geste : procédure écrite « ajout d’une source documentaire » avec validation SSI ou équivalent. Piège : laisser n’importe qui connecter un nouveau dossier parce que « l’IA sera plus intelligente ». Plus de documents sans droits, c’est plus de surface. Articulez avec données personnelles dès que des contenus nominatifs existent. Un schéma PowerPoint ne prouve rien : seuls les tests à deux comptes prouvent.
| Contrôle | Fait ? | Preuve |
|---|---|---|
| Auth utilisateurs | SSO / comptes | |
| Filtre ACL au retrieve | Test deux utilisateurs | |
| Pas d’exposition Internet inutile | Scan / archi | |
| Tests d’injection document | Jeux de PDF | |
| Logs sans données excessives | Revue échantillon | |
| Responsable incident nommé | Procédure |
S’appuyer sur les ressources régionales
En cas d’incident ou pour élever le niveau, les structures peuvent se tourner vers les canaux de signalement et d’accompagnement cyber disponibles en région, notamment le CSIRT Hauts-de-France, en plus de leurs prestataires SSI. IAHDF facilite la culture, pas la réponse incident. Geste : ajouter les contacts utiles dans votre procédure d’une page avant le go-live. À Arras, une collectivité a intégré ce réflexe dans la même fiche que les autres incidents SI.
Piège : attendre l’incident pour chercher qui appeler. Autre piège : croire qu’un atelier IAHDF remplace un prestataire SSI. La prévention locale — droits, auth, tests — reste votre premier rempart. Partagez des méthodes anonymisées avec des pairs via la communauté, jamais des détails exploitables d’un incident en cours.
Méthode avant go-live
Modéliser les utilisateurs, les menaces, les contrôles, les tests, puis go ou no-go. Pas de mise en production « on verra plus tard pour les droits ». À Lens, un no-go assumé a évité une ouverture aux agents trop tôt. Geste : checklist cochée et signée, même de façon légère. Piège : la démo direction qui force un go malgré des trous connus. Un go sous conditions écrites vaut mieux qu’un silence.
Si vous avez déjà un RAG en production « soft », faites un arrêt sur image : cartographiez corpus, utilisateurs, filtres réels, surface réseau, journaux. Corrigez les trous critiques avant toute nouvelle source. À Dunkerque, cette pause a révélé qu’aucun filtre n’était réellement actif. Traitez l’ignorance du mécanisme de droits comme un incident de gouvernance.
Exemples Hauts-de-France
PME à Douai : deux espaces RAG séparés (commercial / RH). Collectivité à Saint-Quentin : corpus public d’abord ; corpus interne seulement après audit des droits. Association à Beauvais : souvent trop tôt pour un RAG multi-utilisateurs ; commencer par un assistant sans base, ou une base publique. ESN à Lille : tests adverses dans le pipeline avant livraison client.
À Compiègne, une interface locale a été restreinte au réseau interne après une revue d’exposition. À Boulogne, une structure a réduit le contenu des journaux après échantillonnage. Geste commun : responsable nommé. Piège commun : multiplier les connecteurs documentaires pour impressionner, sans augmenter les contrôles.
Culture sécurité pour les métiers
Les contrôles techniques ne tiennent pas si les métiers collent des secrets dans les questions ou importent des PDF douteux. Formez court, avec exemples locaux. À Amiens, un atelier de quarante-cinq minutes a plus réduit les comportements risqués qu’un long document non lu. Geste : trois interdits affichés près des postes pilotes. Piège : culpabiliser les utilisateurs sans leur donner d’alternative cadrée. La sécurité du RAG est aussi un sujet de données et de management. À Roubaix, l’alternative cadrée était un canal cloud borné pour les brouillons non sensibles, ce qui a évité le hotspot personnel. Sans alternative, l’interdit seul nourrit le contournement.
Construire des tests adverses légers
Sans prétendre au red team professionnel, vous pouvez constituer un petit jeu : PDF avec consignes parasites, questions visant un document marqueur interdit, prompts demandant d’ignorer les règles, comptes de droits différents. À Lille, ce jeu a bloqué une mise en prod. Geste : trois tests minimum avant chaque ajout de source. Piège : ne tester qu’avec le compte administrateur — vous ne verrez jamais la fuite du compte faible.
À Douai, les tests ont été intégrés au même pipeline que les questions dorées métier de RAG. Documentez les résultats. Si un test échoue, traitez-le comme un bug bloquant, pas comme une curiosité. La légèreté du dispositif n’autorise pas la légèreté du suivi. Faites évoluer le jeu quand de nouveaux connecteurs arrivent.
Réduire le périmètre plutôt qu’ajouter des contrôles cosmétiques
Quand les contrôles sont difficiles, réduisez d’abord ce qui est indexé et qui peut interroger. Un corpus public pour agents formés bat un corpus total mal filtré. À Beauvais, le périmètre réduit a permis un go-live utile sans incident. Geste : liste blanche de sources. Piège : compenser l’absence de droits par un bandeau « usage responsable » — le bandeau ne filtre pas les extraits. La proportionnalité est une parade, pas une excuse.
Reliez la réduction de périmètre à votre doctrine local/cloud : parfois le bon choix est de ne pas faire de RAG multi-utilisateurs tout de suite. Assumer un non-projet est une décision de sécurité mature. Revenez plus tard avec des ACL réelles plutôt que d’empiler des outils de supervision sur une base poreuse. À Compiègne, ce non-projet temporaire a été présenté positivement au comité : « nous protégeons d’abord, nous élargissons ensuite ». Cette formulation évite le récit d’échec et garde une feuille de route crédible.
Pour aller plus loin
RAG/FT · RGPD · tutoriel sécuriser Open WebUI s’il est dans votre catalogue · Agenda · Inscription.
Questions fréquentes
Mon RAG peut-il fuiter des infos ?
Oui, s’il récupère des extraits auxquels l’utilisateur n’aurait pas dû avoir accès, ou s’il expose un contexte trop large dans la réponse ou les journaux. La fuite n’est pas une fatalité : elle est en général le résultat d’une architecture qui a oublié les droits au moment de la recherche documentaire. Testez avec deux comptes de droits différents et des documents marqueurs. Si le compte faible voit le marqueur du compte fort, vous avez un incident de conception — corrigez avant tout élargissement. Ajoutez une revue humaine périodique des réponses sur des questions sensibles. La confiance se prouve par des tests, pas par un schéma PowerPoint.
Qu’est-ce qu’une injection de prompt dans un document ?
C’est une tentative d’insérer, dans un fichier indexé, des instructions destinées à détourner l’assistant — par exemple pour ignorer des règles ou exfiltrer un contexte. Les modèles peuvent être influencés par du texte qui ressemble à des consignes. Les parades combinent inspection des documents, séparation des rôles (instructions système versus contenu), limitations d’outils, et tests adverses. Aucune parade n’est parfaite ; l’objectif est de réduire le risque et de détecter. Formez aussi les contributeurs du corpus : un PDF marketing externe doit être traité avec plus de méfiance qu’une procédure interne contrôlée. Documentez les tests dans le dossier projet.
Open WebUI en local est-il sûr par défaut ?
« Par défaut » est une expression dangereuse. Tout dépend de votre configuration : authentification, exposition réseau, comptes, mises à jour, volumes, politiques. Un service ouvert sur toutes les interfaces sans mot de passe fort n’est pas un lab, c’est une invitation. Suivez les guides de durcissement à jour, limitez l’accès au réseau interne nécessaire, journalisez, et appliquez les correctifs. Faites relire l’architecture par quelqu’un qui a l’habitude des services exposés. Le local vous donne le contrôle ; il ne vous dispense pas de l’exercer. Relisez aussi le choix local/cloud si le local était motivé par la seule « sécurité perçue ».
Que faire en cas d’incident ?
Couper l’accès, préserver les journaux utiles, évaluer le périmètre (quels documents, quels utilisateurs), informer selon vos obligations, corriger la cause, communiquer en interne avec sobriété. Appuyez-vous sur votre prestataire SSI et, selon les cas, sur les dispositifs régionaux de type CSIRT Hauts-de-France. Documentez la chronologie. Après incident, renforcez les tests qui auraient dû capturer le problème. IAHDF peut aider à la culture préventive via des ateliers, mais n’est pas une cellule de crise. Préparez la procédure avant d’en avoir besoin — une page claire suffit pour démarrer. Entraînez-la une fois à blanc.
Par où commencer si on a déjà un RAG en prod « soft » ?
Faites un arrêt sur image : cartographiez corpus, utilisateurs, filtres de droits réels, surface réseau, journaux. Lancez les tests deux comptes et documents marqueurs. Corrigez les trous critiques avant toute nouvelle source documentaire. Nommez un responsable. Planifiez une revue trimestrielle. Si vous découvrez que personne ne sait comment les droits sont appliqués, traitez-le comme un incident de gouvernance. Mieux vaut ralentir clairement que d’accélérer aveuglément. Croisez avec données et méthode RAG/FT pour réaligner le besoin métier et le risque. Écrivez le plan de remédiation avec dates.