IA sur documents confidentiels : les 4 fuites de données à éviter

Publié le 13 juillet 2026 · BinAIskIT

Brancher un modèle de langage sur les documents de l'entreprise est devenu trivial. Le faire sans exposer les documents, beaucoup moins. Voici les quatre façons dont une organisation fait fuiter ses données sensibles en déployant une IA documentaire — et la parade pour chacune.

1. Le collaborateur qui colle un document dans un chat public

C'est la fuite la plus banale, et de loin la plus fréquente. Un juriste colle un projet de contrat dans une interface grand public pour en obtenir un résumé ; un contrôleur de gestion y dépose un fichier de paie pour lui demander une analyse. Le document quitte l'entreprise, sans journal, sans contrôle, sans que personne ne l'apprenne.

Aucune politique interne n'a jamais empêché cela durablement, pour une raison simple : l'outil interdit est utile, et l'alternative autorisée n'existe pas. Tant que vous n'offrez rien, l'interdiction ne fait que déplacer l'usage vers le téléphone personnel.

La parade n'est donc pas réglementaire mais fonctionnelle : fournir un assistant interne, au moins aussi confortable que l'outil public, branché sur les documents auxquels la personne a déjà droit. On ne combat pas l'usage, on le canalise.

2. Le RAG hébergé hors d'Europe

Deuxième fuite, plus discrète : la brique de RAG (Retrieval-Augmented Generation, la technique qui va chercher vos documents pour nourrir la réponse du modèle) est achetée en SaaS, et l'index — donc le contenu de vos documents, découpé en fragments — part chez un hébergeur étranger.

Le point souvent mal compris : dans une architecture RAG, ce ne sont pas seulement les questions qui transitent, c'est le texte de vos documents. L'index vectoriel contient les fragments en clair, ou de quoi les reconstituer. Un index hébergé hors d'Europe est, en pratique, une copie de votre fonds documentaire hébergée hors d'Europe.

La parade : séparer la question « où vit l'index » de la question « quel modèle génère la réponse ». On peut parfaitement conserver l'index sur une infrastructure souveraine, en France, et n'envoyer au modèle que le strict fragment nécessaire — voire faire tourner un modèle ouvert sur la même infrastructure pour les corpus les plus sensibles. Ce découplage est la clé de la conformité, et il conditionne aussi votre liberté de changer de modèle plus tard.

3. L'index qui ignore les droits d'accès

C'est la fuite la plus dangereuse, parce qu'elle est interne et qu'elle ne déclenche aucune alerte. Vous indexez « les documents de l'entreprise ». L'assistant répond à tout le monde, à partir de tout. Un stagiaire demande « quelles sont les augmentations prévues cette année ? » et obtient une réponse construite à partir d'un document du comité de direction qu'il n'aurait jamais pu ouvrir.

Techniquement, rien n'a été piraté. Les droits existaient bien dans SharePoint ou dans le partage réseau — mais l'index les a aplatis. Le RAG a court-circuité vingt ans de gouvernance des habilitations.

La parade : le filtrage par droits doit intervenir avant la génération, pas après. Chaque fragment indexé porte les habilitations du document dont il provient, et la recherche est exécutée dans le périmètre de l'utilisateur qui pose la question. C'est un sujet suffisamment structurant pour que nous lui ayons consacré un article entier : RAG et gestion des droits : faire respecter les habilitations existantes.

4. Les traces conservées par le fournisseur

Dernière fuite, la plus silencieuse : les journaux. Selon les conditions contractuelles, un fournisseur de modèle peut conserver les requêtes pendant plusieurs semaines à des fins de sécurité ou d'abus. Or une requête RAG contient les extraits de vos documents. Vos documents se retrouvent donc dans des journaux que vous ne maîtrisez pas.

La parade tient en trois vérifications contractuelles, à faire avant tout déploiement : la durée de conservation des requêtes, l'exclusion explicite de l'entraînement des modèles sur vos données, et la localisation des traitements. Ces trois lignes se négocient ; encore faut-il savoir les demander.

La checklist avant de brancher une IA sur vos documents

1. Où vivra l'index, physiquement, et sous quelle juridiction ?
2. Les fragments indexés portent-ils les droits d'accès du document d'origine ?
3. La recherche s'exécute-t-elle dans le périmètre de l'utilisateur qui interroge ?
4. Les réponses citent-elles leurs sources, avec un lien vers le document d'origine ?
5. Que conserve le fournisseur du modèle, et pendant combien de temps ?
6. Pouvez-vous changer de modèle sans reconstruire toute la chaîne ?
7. Quelle trace gardez-vous de qui a demandé quoi, et de ce qui a été répondu ?

Si vous ne pouvez pas répondre à ces sept questions, le déploiement est prématuré. Aucune de ces réponses ne demande des mois de chantier : elles demandent d'avoir choisi une architecture avant d'avoir choisi un outil.

Pour aller plus loin sur la mise en production d'une application IA (sécurité des clés, supervision, coûts) : pourquoi tant de POC IA ne passent jamais en production.