L’IA branchée sur la connaissance interne ne contourne pas vos droits : elle les révèle

Il y a une question que je pose toujours avant de brancher un assistant sur les documents d’une entreprise. Elle n’est pas technique. Elle tient en une phrase : « qui, dans cette maison, n’a pas le droit de lire ce fichier ? »

La plupart du temps, personne ne sait répondre.

Je conçois depuis deux ans des assistants internes dans un cabinet d’expertise comptable. Fiscalité des particuliers, comptabilité des sociétés, commissariat aux comptes, accompagnement du contrôle fiscal. Autant de domaines où la matière est du secret professionnel, où un dossier client mal exposé n’est pas un incident de communication mais une faute. Alors quand on me parle de connecter une IA à la connaissance interne d’une organisation, je n’entends pas d’abord une question d’outil. J’entends une question de droits.

Et voilà ce que trente ans de métier m’ont appris sur ce genre de moment : la technologie ne crée presque jamais le problème qu’on lui attribue. Elle le rend visible. Les CMS n’ont pas créé le désordre éditorial, ils l’ont mis en page. Le SEO n’a pas créé les sites illisibles, il les a classés. Les assistants connectés ne créent pas les fuites internes. Ils les rendent trouvables en trois secondes, par n’importe qui, en langage courant.

Cet article est la grille que j’applique avant de connecter la première source. Six questions, un ordre d’exécution, et une liste honnête de ce que la méthode ne règle pas.

Un assistant interne n’ouvre aucune porte : il lit celles qui sont déjà ouvertes

Commençons par dissiper le malentendu qui fait perdre le plus de temps en comité de direction.

Les assistants d’entreprise sérieux fonctionnent au nom de l’utilisateur qui les interroge. Quand ChatGPT interroge les sources connectées d’une organisation via sa fonction de connaissance d’entreprise, il ne voit que ce que la personne connectée pouvait déjà ouvrir elle-même dans Drive, Slack ou SharePoint, chacun passant par sa propre autorisation. Même logique chez Microsoft : Copilot fait remonter documents, courriels et conversations selon les permissions existantes de l’utilisateur. Il ne contourne pas la sécurité, il la reflète.

Ce qui devrait rassurer. Et qui, en pratique, terrifie.

Parce que « ce que l’utilisateur pouvait déjà ouvrir » recouvre, dans la plupart des organisations, un empilement de dix ans de partages accordés à la va-vite. Un dossier partagé à toute l’entreprise pour dépanner un collègue un vendredi soir. Un groupe « tous sauf externes » collé par défaut sur un espace qui contenait trois documents anodins, et qui en contient trois mille aujourd’hui. Un héritage de permissions cassé sur un sous-dossier, il y a quatre ans, par quelqu’un qui a quitté la maison depuis. Des accès conservés après un changement de poste, parce que les retirer aurait demandé un ticket que personne n’a ouvert.

Une analyse relayée par la presse spécialisée estime qu’environ 16 % des données critiques d’un environnement Microsoft 365 moyen sont surpartagées. Prenez ce chiffre pour ce qu’il est — un ordre de grandeur, pas une mesure de votre maison. Il dit quand même quelque chose d’utile : le problème n’est pas marginal, et il est antérieur à l’IA.

C’est exactement pour cela que je refuse de traiter ces projets comme des projets d’IA. Ce sont des projets de droits, de propriété des contenus et de cycle de vie documentaire, que l’assistant a simplement rendus impossibles à repousser. J’ai déjà défendu cette idée sous un autre angle : l’IA ne bloque presque jamais sur les outils, elle bloque sur l’organisation. La connexion à la connaissance interne en est la démonstration la plus brutale.

Les six questions à trancher avant de brancher l’IA sur la connaissance interne

Voici la grille. Elle tient sur une page, elle se remplit en atelier avec les métiers, et elle produit une décision écrite. Pas un document de conformité : un arbitrage.

Une remarque sur la sixième ligne, parce qu’on l’expédie toujours trop vite. Un assistant capable de rédiger une note de synthèse à partir de dossiers clients peut techniquement produire un conseil engageant. Il ne doit pas. Dans les systèmes que je conçois, les agents métier préparent, structurent et sécurisent le travail du collaborateur — ils ne rendent jamais seuls un avis professionnel qui engage la responsabilité du cabinet. Cette frontière ne se code pas dans un moteur de permissions. Elle s’écrit, elle se rappelle, et elle se vérifie en relecture.

Capacité technique, configuration des droits, règle d’usage : trois choses différentes. Les confondre, c’est le début de tous les ennuis.

Le piège technique : l’index qui cesse d’hériter des droits

C’est le point le plus mal compris de tout le sujet, et celui qui produit les mauvaises surprises les plus coûteuses. Il mérite qu’on entre un peu dans la mécanique.

Interroger les droits, ou en garder une photo

Pour qu’un assistant réponde à partir de vos documents, il faut que ceux-ci soient indexés : découpés, transformés, rangés dans une base de recherche. La question décisive est de savoir ce qui arrive aux droits pendant ce voyage.

Deux architectures s’opposent. Dans la première, le système interroge la source à chaque requête : il demande, au moment où vous posez la question, ce que vous avez le droit de lire. Dans la seconde, il a recopié les listes de contrôle d’accès dans son index au moment de l’ingestion, et il travaille sur cette photographie.

La seconde est plus rapide. Elle est aussi celle qui dérive. Les praticiens de la sécurité des systèmes de recherche augmentée sont explicites : les droits doivent être hérités de la source, pas dupliqués dans l’index, faute de quoi ils se désynchronisent silencieusement — une mutation interne, un départ, un dossier reclassé, et l’index continue de raisonner sur un monde qui n’existe plus.

Filtrer avant, jamais après

Deuxième subtilité, plus discrète encore. Un système peut chercher dans tout, puis retirer de la réponse ce que vous n’aviez pas le droit de voir. Ou bien restreindre le champ de recherche avant même de chercher.

La différence a l’air cosmétique. Elle ne l’est pas. Dans le premier cas, le contenu interdit est entré dans le contexte du modèle avant d’être filtré ; il a influencé la formulation, il peut transparaître dans une reformulation, une synthèse, un raisonnement. Les recommandations convergent sur ce point : le filtrage doit intervenir avant la récupération, pas après. Ce que le modèle n’a jamais lu ne peut pas fuir.

Vous n’avez pas besoin d’être ingénieur pour poser ces deux questions. Vous avez besoin de les poser avant la signature, pas après le premier incident.

Citations et journalisation : rendre les réponses contestables

On présente souvent les citations comme un confort de lecture. C’est une erreur d’appréciation.

Une réponse citée est une réponse qu’on peut attaquer. Le collaborateur remonte au document d’origine, constate qu’il date de 2023, qu’il a été remplacé par une note plus récente, et corrige. Sans citation, la même réponse arrive lisse, fluide, autoritaire — et fausse. La fluidité d’un modèle de langage est un excellent vernis pour une donnée périmée.

Une réponse sans source n’est pas une réponse, c’est une affirmation. Dans un contexte professionnel engageant, la différence entre les deux vaut une carrière.

Les citations produisent d’ailleurs un effet secondaire que je n’avais pas anticipé : elles réhabilitent le document d’origine. Les collaborateurs découvrent des notes internes qu’ils ignoraient, et surtout ils repèrent celles qui n’auraient jamais dû rester en ligne. L’assistant devient un révélateur de dette documentaire. C’est inconfortable et c’est très sain. Dans un environnement où tout le monde peut répondre vite, ceux qui savent expliquer d’où vient la réponse gagnent la confiance.

La journalisation, elle, répond à une autre question : que s’est-il passé ? Sans journal exploitable — qui a demandé quoi, à quel moment, quels documents ont réellement été mobilisés — vous ne pouvez ni instruire un incident, ni démontrer une diligence, ni corriger un usage dérivant. Vous êtes réduit à croire sur parole un système que vous ne pouvez pas interroger. Et si des données personnelles circulent dans ces échanges, l’organisation en reste responsable au sens du règlement européen, quel que soit le fournisseur du modèle. La CNIL est constante là-dessus.

La révocation, ce délai que personne ne mesure

Posez la question suivante dans votre organisation, aujourd’hui : quand on retire à quelqu’un l’accès à un espace, au bout de combien de temps l’assistant cesse-t-il de lui en restituer le contenu ?

Dans la quasi-totalité des cas, la réponse est un silence gêné. Puis un « je vais vérifier » qui ne revient jamais.

Or ce délai existe. Les plateformes qui synchronisent identités et droits par lots, parfois selon des cycles quotidiens, ouvrent une fenêtre pendant laquelle un accès retiré reste actif côté assistant. Les spécialistes de l’entitlement recommandent de traiter la révocation comme un événement prioritaire, propagé en minutes et non au rythme des mises à jour de contenu.

Il y a une asymétrie qu’il faut avoir en tête. Un humain sur-habilité n’exploite presque jamais ses droits : il ne sait même pas qu’il les a. Un agent, lui, exploite systématiquement tout ce qui lui est ouvert, à la vitesse de la machine, sans intention et sans scrupule. La sur-permission dormante devient une sur-permission agissante. C’est précisément le sujet que j’ai creusé en parlant de gouvernance des agents et de qui décide quoi : la question n’est plus de savoir ce que le système peut faire, mais ce qu’il a le droit de faire, et qui l’a décidé.

Ma méthode, dans l’ordre où je l’applique

Voilà comment je procède concrètement. L’ordre compte autant que le contenu.

1. Choisir un cas d’usage étroit et une seule source. Pas « l’assistant du cabinet ». Une question métier précise, un espace documentaire identifié, une population de test réduite. Le périmètre se gagne, il ne se donne pas.
2. Cartographier les droits avant de connecter. Qui accède à cet espace, par quel groupe, depuis quand, et pourquoi. C’est l’étape que tout le monde veut sauter et c’est celle qui produit toute la valeur. Elle révèle presque toujours au moins un accès que personne n’assume.
3. Nettoyer avant d’indexer. Retirer les partages ouverts à tous, réparer les héritages cassés, supprimer les liens de partage sans expiration, archiver ce qui est mort. Indexer un espace sale revient à photocopier le désordre.
4. Exclure explicitement les zones sensibles. Ressources humaines, juridique, données de santé, dossiers en contentieux. Non parce que l’assistant les traiterait mal, mais parce que le coût d’une erreur y est sans commune mesure. On les rouvrira plus tard, ou jamais.
5. Tester par l’attaque, pas par la démonstration. C’est le passage que je ne négocie plus. On donne l’assistant à trois personnes de niveaux d’habilitation différents et on leur demande d’obtenir ce qu’elles ne devraient pas voir. En langage naturel, sans ruse technique. Les questions détournées trouvent en dix minutes ce qu’un audit de droits met trois semaines à repérer.
6. Écrire les règles d’usage avec les métiers, pas pour eux. Ce que l’assistant prépare, ce qu’il ne signe pas, ce qui repasse obligatoirement par un humain nommé. Une page, en français, affichée là où les gens travaillent.
7. Mesurer la révocation avant d’ouvrir largement. Retirer un accès test, chronométrer. Si le délai se compte en jours, l’ouverture attend.

Sept étapes, dont une seule est technique. Ce n’est pas un hasard.

Ce que cette méthode coûte, et ce qu’elle ne règle pas

Je serais malhonnête en présentant cette grille comme une solution propre et sans contrepartie. Elle a un prix, et elle laisse des angles morts.

Elle ralentit. Beaucoup. Entre la cartographie des droits et le nettoyage, il se passe des semaines pendant lesquelles il n’y a rien à montrer. C’est difficile à tenir face à une direction qui a vu une démonstration spectaculaire en conférence et qui attend la même chose pour le mois suivant. J’ai appris à annoncer ce délai dès le départ, en expliquant ce qu’on achète avec.

Elle déplace un travail sur des gens qui ne l’ont pas demandé. Le nettoyage des droits retombe sur des équipes informatiques déjà chargées, ou sur des responsables métier qui découvrent qu’ils sont propriétaires d’espaces dont ils ignoraient l’existence. Présenter cela comme un effet secondaire indolore de l’IA serait mensonger. C’est un coût réel, et il doit être arbitré comme tel.

Elle ne traite pas la sortie. Ma grille sécurise ce qui entre dans l’assistant. Elle ne dit rien de ce que le collaborateur fait de la réponse : la coller dans un courriel externe, l’intégrer à une présentation client, la transmettre à un tiers. Aucun moteur de permissions ne suit une information une fois qu’elle est affichée à l’écran. Ce périmètre relève de la formation et de la culture interne, pas de la configuration.

Elle vieillit. Un audit de droits est vrai le jour où il est fait. Six mois plus tard, de nouveaux partages ont été accordés, de nouveaux espaces créés, de nouveaux collaborateurs arrivés. Sans revue périodique, la grille devient un souvenir rassurant. J’ai pris l’habitude de reprogrammer la revue au moment même de la mise en production, sinon elle n’a jamais lieu.

Et elle ne dit rien du contenu lui-même. Un document parfaitement autorisé peut être faux, obsolète, contredit par une note plus récente. Les droits d’accès protègent la confidentialité, jamais l’exactitude. Ce sont deux chantiers distincts, et le second est encore devant nous.

Le vrai livrable n’est pas l’assistant

Je repense souvent à ce que ces projets produisent réellement.

Une organisation qui traverse sérieusement cette grille finit par savoir où sont ses documents, qui en est responsable, qui peut les lire et pourquoi. Elle a nettoyé des partages ouverts depuis huit ans. Elle a identifié des espaces sans propriétaire. Elle a écrit noir sur blanc ce qu’un outil n’a pas le droit de faire, ce qui suppose d’avoir décidé ce qu’un humain doit continuer d’assumer.

Tout cela avait de la valeur bien avant l’IA. Personne ne l’a jamais financé. Il aura fallu l’envie de brancher un assistant pour que le sujet devienne prioritaire — et c’est peut-être le service le plus concret que cette technologie rende aux entreprises cette année.

Alors ne commencez pas par choisir un outil. Commencez par la question du début, celle qui met tout le monde mal à l’aise pendant dix secondes : dans cette maison, qui n’a pas le droit de lire ce fichier ? Si vous ne savez pas y répondre, vous n’avez pas un problème d’IA. Vous avez un problème que l’IA va simplement rendre public.

Connecter l’IA à sa connaissance interne, c’est accepter un audit de ses droits d’accès en accéléré. Vous avez traversé ce chantier dans votre organisation, ou vous êtes en train de le préparer ? Racontez-moi ce que vous y avez découvert — c’est souvent là que les histoires deviennent intéressantes.

Suivez-moi sur LinkedIn

Références principales

Les faits et analyses cités dans cet article proviennent des sources suivantes :

• OpenAI — documentation Company Knowledge : connexion aux sources internes, citations vers les documents d’origine, administration des accès.
• VentureBeat : lancement de la connaissance d’entreprise dans ChatGPT et périmètre des connecteurs.
• Petri : l’oversharing comme défaillance de gestion des permissions, et l’ordre de grandeur des données surpartagées.
• Microsoft Tech Community : dispositifs de réduction du surpartage avant déploiement d’un assistant.
• Truto et Kiteworks : contrôle d’accès au niveau du document et filtrage avant récupération.
• Pebblous : héritage des droits par les agents, dérive des index et fenêtre de révocation.
• CNIL : questions-réponses sur l’utilisation d’un système d’IA générative en entreprise.