IA et droits d'accès en cabinet : les règles à conserver
6 minutes de lecture
Si un outil d'IA ignore les droits d'accès existants de votre cabinet, vous ne gagnez pas en productivité : vous créez un nouveau problème d'accès. Ce qui doit s'appliquer, et comment le vérifier.
Un cabinet passe des années à bâtir ses règles d'accès : qui peut ouvrir tel dossier client, qui peut voir tel modèle financier, qui perd ses accès le jour de son départ. Si vous connectez un outil d'IA sans reprendre ces règles, il peut toutes les contourner sans que personne ne s'en aperçoive. Pour un cabinet, contrôler les accès de l'IA consiste à appliquer les règles existantes à un nouvel utilisateur de vos données, plutôt qu'à concevoir un nouveau jeu de droits à partir de zéro.
Ce que veut dire le contrôle d'accès quand l'IA entre en jeu
Un outil d'IA ne devrait jamais voir plus que ce que la personne qui l'utilise a déjà le droit de voir. Si un analyste junior ne peut pas ouvrir le modèle de tarification d'un associé, un assistant qui travaille pour le compte de cet analyste ne doit pas pouvoir y puiser non plus, aussi pratique que soit une base de connaissances partagée.
Les cabinets se trompent sur ce point d'une manière précise et courante : ils connectent un outil d'IA au « savoir du cabinet » comme à un seul réservoir indifférencié, parce que constituer une bibliothèque de sources partagée semble être tout l'intérêt de relier l'IA aux données internes. Mais dès que ce réservoir n'a plus de frontières, tous les droits que le cabinet a pu définir cessent de s'appliquer, et quiconque peut utiliser l'assistant accède à tout ce qu'il contient.
Où les périmètres d'accès cèdent en pratique
Cela ressemble rarement à un piratage. Tout part en général d'une décision de configuration ordinaire.
- Un assistant partagé qui voit plus loin que chacun de ses utilisateurs. Quelqu'un configure un assistant sur « tout le drive » ou « tout l'espace de travail client », parce que restreindre son périmètre lui semblait une étape de trop. Désormais, tous ceux qui peuvent interroger l'assistant peuvent récupérer des documents auxquels on ne leur a jamais donné accès directement.
- Une intégration authentifiée une seule fois, au niveau administrateur, pour tout le monde. La connexion à l'espace documentaire du cabinet est configurée avec les identifiants d'un administrateur, et dès lors chaque utilisateur de l'outil d'IA hérite des accès de l'administrateur au lieu des siens.
- Un ancien collaborateur qui garde ses accès après son départ. Les check-lists de départ couvrent la messagerie et le CRM. Un outil d'IA connecté en permanence aux dossiers clients s'oublie facilement, et la connexion continue de fonctionner une fois la personne partie.
- Des documents clients qui glissent vers un espace général. Un document qu'un client a partagé pour une mission sert à répondre à une question sur une autre mission sans rapport, parce que rien dans l'outil n'indique à quel client il appartient.
Aucune de ces situations ne suppose une faute intentionnelle. C'est ce qui arrive quand un outil est plus simple à configurer largement que finement, et que personne ne revient sur la configuration une fois qu'elle fonctionne.
Ce qui doit s'appliquer, règle par règle
Les droits qu'un cabinet a déjà définis doivent s'appliquer de la même façon dans un outil d'IA que partout ailleurs. Voici le contrôle à faire sur tout outil avant que des données clients ne s'en approchent.
| Règle d'accès existante | Ce qui doit se passer dans l'outil d'IA |
|---|---|
| Un utilisateur ne peut ouvrir que les documents de son espace de travail | L'outil d'IA respecte ce périmètre quand il récupère des sources, au lieu de puiser dans « tous les documents connectés » |
| Les documents d'un client sont réservés à l'équipe de la mission | Les premiers jets générés pour ce client s'appuient uniquement sur les documents rattachés à cette mission |
| Un rôle dispose d'un accès en lecture seule à un système | L'accès de l'IA par cette connexion reste en lecture seule, sans élévation de droits par l'intégration |
| Les accès d'un collaborateur sont révoqués le jour de son départ | Les accès de l'outil d'IA à ses sessions, clés et sources connectées sont révoqués le même jour |
| Les actions dans les systèmes centraux sont journalisées | L'utilisation de l'IA sur ces mêmes systèmes est journalisée avec le même niveau de détail |
Si un fournisseur ne sait pas rattacher son outil à une ligne de ce tableau, considérez cet écart comme un constat à part entière, et non comme un détail à régler plus tard.
Les questions à poser avant de connecter l'IA à vos outils
Posez-les avant la mise en service d'une intégration, pas après qu'un client a demandé qui pouvait voir ses documents.
- L'outil d'IA hérite-t-il des droits de la personne qui l'utilise, ou de ceux de la personne qui a configuré la connexion ?
- Peut-on restreindre l'accès par client, par mission ou par document, ou la connexion fonctionne-t-elle en tout ou rien ?
- Quand l'accès d'une personne à un système source est révoqué, l'accès de l'outil d'IA à cette source l'est-il automatiquement, ou faut-il penser à le faire séparément ?
- Existe-t-il une trace de ce que l'outil d'IA a récupéré et à quel moment, assez détaillée pour répondre à un client qui pose une question sur ses propres documents ?
Si un fournisseur répond aux quatre avec précision, il a un vrai modèle d'accès. S'il répond « c'est flexible », il n'en a probablement pas.
Périmètres d'accès et départs de collaborateurs
Les départs méritent une section à part, car c'est là qu'une question de conception devient un risque concret. Une personne quitte le cabinet : on récupère son ordinateur, on désactive sa messagerie, on lui retire l'accès au CRM. En revanche, un assistant d'IA qu'elle avait connecté à un espace client six mois plus tôt continue souvent de tourner grâce à un jeton dont personne ne se souvient. Comme l'explique l'article Sécurité de l'IA dans les missions clients, cette connexion doit passer par la même étape de départ que tout le reste de la check-list : un responsable nommément désigné la vérifie le jour du départ, pour que personne ne la découvre au détour d'un audit de sécurité.
Le lien avec les connaissances connectées
Le contrôle d'accès est l'autre face des connaissances connectées, c'est-à-dire de la connexion des outils de votre cabinet à l'IA. Quand vous connectez des sources, les premiers jets s'améliorent parce qu'ils s'appuient sur des documents réels et à jour plutôt que sur ce que l'assistant sait déjà. C'est aussi à ce point de connexion que les périmètres d'accès continuent de s'appliquer, ou cessent discrètement de le faire. Vous devez prendre deux décisions ensemble : quoi connecter, et ce qui doit rester hors d'atteinte une fois la connexion établie. Si vous traitez la seconde après coup, un projet de productivité peut tourner à l'incident d'accès.
Hebno est conçu pour maintenir ces périmètres : les connexions héritent des droits que votre cabinet applique déjà, l'activité est journalisée avec assez de détail pour répondre à la question d'un client, et révoquer les accès d'une personne coupe sa connexion à l'IA en même temps que tout le reste. Consultez la page sécurité pour le détail complet, ou demandez une démo pour voir comment les périmètres d'accès s'appliquent à la configuration de votre cabinet.
