Avant de connecter les données de l'entreprise à un assistant IA

Connecter un assistant IA aux données de l'entreprise relève d'une décision de permissions, pas d'un simple déploiement de produit. Partez du principe que tout ce que l'assistant peut lire, quiconque peut lui parler pourra potentiellement l'extraire, et que tout ce qu'il peut faire, quiconque peut influencer ses entrées pourra potentiellement le déclencher. Cinq points sont à trancher avant le début du pilote : quelles données sont autorisées, ce que l'assistant a le droit de faire, qui peut l'utiliser, ce qui est enregistré et qui porte le risque.

Une précision sur les sources. Les points issus de l'OWASP ou du NIST sont nommés comme tels et accompagnés d'un lien. Tout le reste de cette checklist relève de nos propres recommandations, et non d'une exigence de l'un ou l'autre de ces organismes.

Décider quelles données peuvent être exposées

Commencez par la classification, car chaque contrôle ultérieur en dépend. Si vous n'avez pas de schéma, une grille à trois niveaux suffit pour démarrer, et elle doit être formalisée par écrit avant que quiconque connecte une boîte mail, un partage de fichiers ou un CRM.

Deux points piègent régulièrement les équipes. D'abord, les connecteurs ingèrent généralement des dépôts ou des lecteurs entiers : un dossier dont personne ne se rappelle le partage finit donc indexé. Nettoyez les partages avant la connexion, pas après. Ensuite, les secrets présents dans les documents (clés d'API dans des pages de wiki, mots de passe dans des tickets) transforment une fonction de recherche en fuite d'identifiants.

Partir du principe que l'assistant lira du texte hostile

Considérez tout ce que l'assistant lit (e-mails entrants, pages web, documents partagés, fichiers téléversés) comme un contenu que quelqu'un d'autre a pu rédiger pour le manipuler. Nous recommandons de concevoir le déploiement de façon à ce que cela ne cause aucun dommage, plutôt que de faire du prompt système votre seul contrôle.

Concrètement :

• Donnez à l'assistant le minimum d'outils nécessaires. Commencez par un accès en lecture seule.
• Exigez une confirmation humaine pour toute action ayant des effets de bord : envoi d'e-mails, modification d'enregistrements, exécution de code, paiements.
• Tenez le contenu non fiable à distance des assistants qui ont aussi accès à des données restreintes.
• Traitez la sortie de l'assistant comme une entrée non fiable pour tout ce qui la consomme. Si un système en aval l'exécute ou l'affiche, validez-la comme vous le feriez pour une saisie utilisateur.

Pour une liste de référence des risques liés aux applications LLM, appuyez-vous sur l'OWASP Top 10 for Large Language Model Applications. La page du projet décrit l'OWASP GenAI Security Project comme une initiative open source mondiale couvrant les risques de sécurité et de sûreté de l'IA générative, y compris les LLM, les systèmes d'IA agentique et les applications pilotées par l'IA. Elle indique que le Top 10 reste un élément central et mentionne une version 2025. La page renvoie vers genai.owasp.org/llm-top-10/ pour la dernière liste. Lisez cette liste et servez-vous de ses catégories pour structurer votre modélisation des menaces, plutôt que d'inventer la vôtre.

Contrôle d'accès et journalisation

L'assistant doit agir avec les permissions de la personne qui l'interroge, pas avec un compte de service aux droits étendus. S'il utilise une identité unique partagée ayant accès à tout, un collaborateur junior pourrait être en mesure de récupérer des documents du comité de direction en formulant bien sa question. Vérifiez comment le connecteur gère les permissions par utilisateur, et testez-le avec deux comptes de niveaux hiérarchiques différents avant la mise en production.

Ensuite, décidez de ce que vous journalisez. Il vous faut au minimum de quoi reconstituer un incident :

timestamp, user id, assistant/tool name,
source documents retrieved, actions requested,
actions executed, confirmation (yes/no), result status

Définissez à l'avance la durée de conservation de ces journaux, qui peut les consulter, et si les prompts eux-mêmes contiennent des données personnelles. Les journaux de conversation constituent un magasin de données à part entière et requièrent la même classification que le contenu qu'ils renferment. Transmettez-les à l'équipe chargée de votre supervision, afin qu'un volume inhabituel de récupérations depuis un même compte soit repéré.

Passer le fournisseur en revue avant le contrat

Posez des questions directes au fournisseur et obtenez les réponses par écrit :

1. Nos prompts et nos documents servent-ils à entraîner ou à améliorer des modèles ? Cela peut-il être désactivé par contrat, et pas seulement par un paramètre ?
2. Où les données sont-elles traitées et stockées, et quels sous-traitants interviennent ?
3. Combien de temps les prompts, les sorties et les fichiers téléversés sont-ils conservés, et pouvons-nous les supprimer ?
4. Quels contrôles d'administration existent : authentification unique (SSO), accès basé sur les rôles, export des journaux d'audit, listes d'autorisation de connecteurs ?
5. Comment les incidents de sécurité sont-ils notifiés, et dans quel délai ?

Vérifiez que les réponses correspondent à la console d'administration réelle. Une page de politique et un paramètre configurable sont deux choses différentes. Si l'outil propose des plug-ins ou des connecteurs tiers, évaluez-les comme des fournisseurs distincts.

Attribuer un responsable au risque

La gouvernance a des allures de paperasse, et c'en est, mais c'est elle qui empêche les déploiements parallèles (shadow IT). Le NIST AI RMF Playbook propose des actions suggérées alignées sur les quatre fonctions de l'AI Risk Management Framework : Govern, Map, Measure et Manage. Le NIST précise que le Playbook n'est ni une checklist ni une suite d'étapes à suivre intégralement, et que ses suggestions sont facultatives. Il indique également que l'AI RMF 1.0 est en cours de mise à jour et que le Playbook suivra, aussi vérifiez la version en vigueur. Retenez ce qui convient à une entreprise de votre taille.

Nous recommandons un registre succinct de tous les outils d'IA utilisés, chacun avec un responsable, les niveaux de données qu'il peut toucher et une date de revue. Ajoutez une colonne supplémentaire : le service juridique a-t-il confirmé que des obligations issues de l'EU AI Act ou du RGPD s'appliquent à ce cas d'usage, et quelles ont été ses conclusions ? Nous n'avons pas évalué ces obligations ici, il revient donc à un conseil juridique ou à un conseiller en conformité de trancher. Si vous souhaitez être accompagné pour mettre en place le registre et le processus de revue, notre service de conseil comprend des évaluations de préparation.

Par où commencer

1. Recensez tous les assistants IA déjà utilisés, y compris les comptes gratuits que les collaborateurs ont créés eux-mêmes, et désignez un responsable pour chacun.
2. Rédigez la classification à trois niveaux ci-dessus et indiquez à quel niveau appartient chaque source de données connectée. Retirez du périmètre les sources restreintes.
3. Lancez un pilote avec un accès en lecture seule, des permissions par utilisateur et une confirmation humaine pour chaque action. Testez-le avec deux comptes de niveaux hiérarchiques différents.
4. Activez la journalisation, fixez une durée de conservation et envoyez les journaux à l'équipe qui supervise vos systèmes.
5. Envoyez les questions au fournisseur, conservez les réponses écrites avec le contrat et demandez au service juridique de confirmer si des obligations issues de l'EU AI Act ou du RGPD s'appliquent.
6. Avant un déploiement plus large, faites tester la configuration par quelqu'un qui tentera de l'attaquer. Un test d'intrusion avec des scénarios construits autour de vos connecteurs réels met en évidence ce qu'une modélisation des menaces sur le papier ne voit pas.