Une entreprise peut acheter un modèle d’IA performant et construire malgré tout un mauvais système si l’agent interne voit trop de choses. L’erreur ne vient pas toujours du modèle, mais de la conception des accès : l’agent finit par lire des dossiers entiers, d’anciens messages et des données inutiles pour accomplir une tâche précise. Le risque n’est pas seulement la fuite d’informations. Cela rend aussi les réponses plus difficiles à auditer, plus faciles à contaminer et plus coûteuses à gouverner.
La vraie question n’est pas de savoir si l’agent est intelligent, mais ce que vous lui laissez regarder et pendant combien de temps.
Ma thèse est simple : un agent IA interne doit avoir moins d’accès qu’une personne, mais un accès mieux défini. Moins, par principe de moindre privilège. Mieux défini, parce que si l’accès est lié à une tâche précise, l’entreprise gagne en contrôle sans rendre l’agent inutile. La guidance d’OpenAI pour les entreprises dit quelque chose de proche : la gouvernance doit être pensée dès le départ, avec la sécurité, le juridique et les opérations, et non ajoutée après le lancement. (openai.com)
L’accès doit suivre la tâche, pas l’organigramme
Prenons un agent qui aide les commerciaux à préparer une proposition. Il n’a pas besoin de toute l’histoire de l’entreprise ; il lui faut seulement le client concerné, les prix approuvés, les conditions en vigueur et, éventuellement, un résumé récent du compte. S’il peut aussi lire des e-mails personnels, des archives juridiques ou des discussions internes sans rapport, le problème ne se limite pas à la confidentialité. Il devient aussi plus probable qu’il mélange les signaux, s’appuie sur un contexte obsolète ou cite une information qui n’aurait jamais dû sortir.
Il est utile de distinguer trois couches :
- Identité : qui est l’agent et au nom de qui il agit.
- Autorisations : quelles sources il peut interroger.
- Session : combien de temps dure cet accès et ce qui est consigné.
Beaucoup d’entreprises parlent de “donner accès à l’IA” comme s’il s’agissait d’un interrupteur. En réalité, c’est plutôt comme remettre un dossier préparé pour une réunion précise, puis le récupérer à la fin.
Cette approche rejoint la guidance d’OpenAI : les organisations qui passent à l’échelle ne se contentent pas d’utiliser l’IA, elles redessinent leurs workflows et alignent la gouvernance sur la vitesse. (openai.com)
Les données utiles sont rarement toutes les données
Un agent n’a pas besoin de tout savoir pour être utile. Dans bien des cas, il a besoin de moins que ce que l’équipe imagine. Exemple composite : une société de services voulait qu’un agent résume les incidents pour les opérations. Le premier réflexe a été de le connecter à tout l’ERP, à l’historique des tickets et à toute la documentation interne. Le résultat était prévisible : des synthèses longues, des références inutiles et une incertitude permanente sur ce qui avait été vu.
Quand le périmètre a été réduit aux incidents ouverts, au catalogue de services approuvé, aux SLA (accords de niveau de service) et à un résumé quotidien des changements, l’agent est devenu plus fiable. Pas parce qu’il était “plus intelligent”, mais parce que le contexte était plus propre. Moins de bruit, moins de risque, moins de relecture humaine.
Ce schéma compte parce qu’un accès trop large est souvent “payé” par de la supervision manuelle. Et cela ne passe pas à l’échelle. Un modèle d’accès lié au cas d’usage permet de mesurer bien plus clairement trois éléments : la précision, les incidents de sécurité et le temps de relecture. Si l’entreprise ne peut pas observer ces trois signaux, elle laisse probablement entrer trop de données par la porte de service.
Le point inconfortable : il faut parfois dire non
La discussion difficile arrive quand le métier veut que l’agent soit “plus utile” en lui donnant plus de données. C’est une demande compréhensible, mais en IA d’entreprise, plus de contexte n’est pas toujours synonyme de meilleur résultat. Parfois, cela veut dire plus d’exposition, plus de confusion et plus de dépendance aux exceptions.
La décision inconfortable consiste à refuser l’accès même lorsqu’un utilisateur le demande. Non pas parce que les personnes ne sont pas fiables, mais parce que le système ne peut pas reposer sur la mémoire humaine ni sur la bonne volonté. Si un agent accède à la paie, aux contrats ou aux dossiers sans raison opérationnelle claire, la conception est déjà mauvaise.
OpenAI insiste aussi sur le fait que les gains durables reposent sur des workflows hybrides qui protègent le jugement humain ; l’objectif n’est pas d’automatiser partout, mais de garder la revue humaine là où elle compte vraiment. (openai.com)
Ce qu’il faut vérifier avant de le laisser entrer
Avant de déployer un agent interne, demandez des réponses claires à cinq questions :
- Quelle tâche précise résout-il ?
- Quelles sources lui sont réellement nécessaires ?
- Que ne doit-il pas voir, même si ce serait “utile” ?
- Combien de temps dure son accès et qui peut le révoquer ?
- Quelle trace d’audit laisse-t-il pour contrôle ?
Si l’une de ces réponses est floue, l’agent n’est pas prêt. Et si l’équipe ne peut pas révoquer l’accès rapidement, il n’est pas prêt non plus. La révocation n’est pas un détail administratif ; c’est une condition de contrôle. Les journaux comptent tout autant : il faut pouvoir reconstituer ce que l’agent a vu, pas seulement ce qu’il a répondu.
Il vaut aussi la peine de définir des signaux d’exploitation simples : nombre de sources consultées par tâche, part des réponses corrigées par un humain, incidents liés à une surexposition des données et délai moyen de retrait des permissions quand les conditions changent.
Trois actions pour cette semaine
- Listez les trois tâches où un agent pourrait aider, puis notez les données inutiles pour chacune.
- Vérifiez si l’accès peut être révoqué rapidement, sans processus manuel trop lent.
- Posez à l’équipe une question simple : quelle preuve faudrait-il pour expliquer cette décision dans un mois ?
Un agent interne n’est pas utile parce qu’il voit plus. Il est utile parce qu’il voit exactement ce qu’il faut. Chez Codefuente, c’est souvent par là que nous commençons : quelles données il peut voir, celles qu’il ne doit pas voir, et comment la frontière est appliquée. Bien réglée, cette question rend tout le reste beaucoup plus simple.