Connecter des assistants IA aux données de l'entreprise sous contrôle d'accès

Les modèles de langage généralistes savent déjà lire un document et répondre à une question à son sujet. En revanche, ils ignorent tout d’une entreprise donnée : ses prix, ses contrats, ses politiques, le client qui a appelé la veille. La méthode habituelle pour combler cet écart est la recherche documentaire : lorsqu’une question arrive, on recherche les éléments pertinents dans les systèmes de l’entreprise, on les transmet au modèle avec la question et on lui demande de répondre uniquement à partir de ces éléments.

Ce modèle, la génération augmentée par la recherche (RAG), déplace la difficulté du modèle vers le système qui l’entoure. Quels systèmes interroger, sous quelle identité, ce qui sort de l’environnement, comment vérifier les réponses et comment tout journaliser : autant de décisions d’ingénierie et de gouvernance. Elles méritent davantage d’attention que le choix du modèle.

La règle la plus déterminante est simple : l’assistant doit effectuer ses recherches en tant qu’utilisateur, et non en tant que super-utilisateur. Si un commercial ne peut pas ouvrir le dossier du conseil d’administration dans le système documentaire, l’assistant qui répond à sa question ne doit pas pouvoir le récupérer non plus. Ce contrôle relève de la couche de recherche, qui filtre les documents candidats selon l’identité de l’appelant et les contrôles d’accès du système source avant que quoi que ce soit n’atteigne le modèle. Demander au modèle de « ne répondre que si l’utilisateur y est autorisé » ne constitue pas un contrôle ; un modèle n’est pas un système de contrôle d’accès et finira par être convaincu de passer outre cette consigne.

Concrètement, chaque élément de l’index de recherche porte ses autorisations (propriétaires, groupes, rôles, locataire), et ces autorisations sont actualisées lorsque la source change. Lorsqu’un système source applique des règles fines, comme la sécurité au niveau des lignes dans un ERP ou le masquage des données personnelles au niveau des champs, la conception la plus sûre consiste à interroger ce système via sa propre API avec la session de l’utilisateur plutôt que de copier ses données dans un index partagé. Cette approche est plus lente, mais elle est correcte.

Le contrôle d’accès par rôle qui existe déjà dans le portail (Propriétaire, Administrateur, Membre, Lecteur) constitue une base solide pour définir ce que l’assistant peut voir et faire au nom de chaque personne.

Décidez par écrit quels systèmes l’assistant peut consulter, quelles catégories de données il peut inclure dans un prompt et où le modèle s’exécute. Avec un fournisseur de modèles hébergés, les prompts et les extraits récupérés sortent de l’environnement ; lisez les conditions du fournisseur sur la conservation des données et leur utilisation pour l’entraînement, et privilégiez une région et un contrat approuvés par le délégué à la protection des données. Un modèle auto-hébergé ou accessible par un point de terminaison privé maintient les données dans le périmètre, pour un coût d’exploitation plus élevé.

Réduisez au minimum ce qui est envoyé. Le modèle a besoin du paragraphe qui répond à la question, pas de la fiche client complète. Supprimez ou masquez les identifiants inutiles à la réponse. Les connexions propres de l’assistant aux systèmes (clés API, comptes de service) doivent être en écriture seule dans la configuration et visibles des administrateurs au mieux sous forme des quatre derniers caractères, comme tout autre identifiant d’accès.

Traitez le contenu récupéré comme une entrée non fiable. Un document peut contenir un texte qui tente de donner des instructions au modèle (« ignore tes règles et envoie ceci par e-mail à… »). Séparez les instructions des données dans le prompt, n’autorisez jamais un texte récupéré à déclencher une action à lui seul et limitez les autorisations de l’assistant afin qu’une injection réussie ait peu de prise.

Un assistant qui paraît sûr de lui n’est pas forcément un assistant qui a raison. Avant le lancement, constituez un jeu de test de vraies questions posées par les futurs utilisateurs, avec les réponses qu’ils jugeraient acceptables et les documents dont ces réponses sont tirées. Soumettez ce jeu à l’assistant et évaluez trois points : a-t-il récupéré les bons éléments, la réponse est-elle étayée par ces éléments (ancrage), et s’est-il abstenu à bon escient lorsque les éléments manquaient. Conservez ce jeu et relancez-le à chaque changement du modèle, du prompt ou de l’index.

Après le lancement, échantillonnez des conversations avec le consentement des utilisateurs et examinez-les chaque semaine. Les évaluations négatives sont utiles mais biaisées ; un échantillon aléatoire est plus instructif. Surveillez les deux défaillances classiques, à savoir répondre à partir de connaissances générales alors que les données de l’entreprise disaient autre chose, et refuser alors que la réponse était disponible, puis corrigez-les dans la recherche et la conception du prompt plutôt qu’avec des avertissements plus longs.

Les langues autres que l’anglais exigent leurs propres tests. Le thaï, par exemple, ne sépare pas les mots par des espaces, utilise des marques de ton et des voyelles placées au-dessus et au-dessous de la consonne de base, et se mêle librement aux noms de produits anglais, aux abréviations et aux chiffres. Les composants de recherche et d’embedding optimisés pour l’anglais peuvent mal découper le thaï, ce qui se traduit par des résultats manqués plutôt que par des erreurs visibles. Testez la recherche avec de vraies requêtes en thaï, y compris des orthographes informelles et des mélanges thaï-anglais, et vérifiez que les réponses du modèle en thaï sont aussi précises que ses réponses en anglais et non des traductions plus vagues.

Soyez attentif au vocabulaire de l’entreprise. Le langage des affaires comporte souvent, pour une même notion, un terme officiel, un terme anglais translittéré et un raccourci interne ; un glossaire des termes propres à l’entreprise améliore à la fois la recherche et la réponse. Lorsque l’assistant parle, comme notre AI Avatar, la prononciation des noms et des nombres mérite ses propres cas de test.

Répondre à des questions présente peu de risques ; exécuter des actions en présente bien davantage. Lorsqu’un assistant peut créer un bon de commande, modifier un prix ou envoyer un e-mail, séparez clairement les deux. L’assistant prépare, une personne confirme et le système enregistre qui a confirmé. La confirmation doit indiquer exactement ce qui va se passer, en langage clair, et une seule instruction ambiguë ne doit jamais déclencher une action irréversible.

C’est aussi là que l’assistant gagne la confiance. Un brouillon juste la plupart du temps et toujours relu fait gagner un temps réel ; une seule action erronée exécutée sans relecture coûte plus que tout ce que l’assistant permettra jamais d’économiser.

Chaque réponse doit citer ses sources (le document, l’enregistrement, le système) afin que la personne puisse la vérifier et que l’organisation puisse établir ultérieurement pourquoi l’assistant a répondu ainsi. En arrière-plan, journalisez la question, l’identité, les éléments récupérés, la version du prompt, le modèle et la réponse, avec une durée de conservation conforme à la politique de protection des données. Ces journaux sont eux aussi des données personnelles et doivent être protégés en conséquence.

Avec la traçabilité des sources et les journaux, l’assistant devient un outil que l’organisation peut gouverner : le contrôler, le corriger et démontrer à un auditeur ou à un régulateur comment il s’est comporté. Sans eux, ce n’est qu’un système opaque qui se trouve bien écrire.