Quels accès donner à un agent IA, et lesquels lui refuser

C'est l'objection qui arrive avant toutes les autres, et elle est saine. « Qu'est-ce qu'il pourrait faire comme dégâts ? » est la bonne question à poser à tout outil à qui l'on remet les clés des systèmes de travail.

La réponse qui suit n'est pas « n'ayez pas peur ». C'est un tri par type d'accès : ce qu'on ouvre sans arrière-pensée, ce qu'on n'ouvre qu'à moitié, ce qu'on n'ouvre jamais, et comment vérifier un produit avant de cliquer sur « autoriser ».

Le principe de départ

Il porte un nom officiel — le principe du moindre privilège — et une formulation plus simple : l'agent doit voir exactement ce que sa tâche exige, et pas un canal de plus.

Ce n'est pas de la paranoïa, c'est une façon de rendre le risque saisissable. Si l'agent voit un canal et un dossier, la question « qu'est-ce qu'il peut abîmer ? » a une réponse courte. Si on lui a donné les droits d'administrateur, il n'y a pas de réponse courte.

Un contrôle utile : formulez la tâche et regardez quel accès minimal la couvre. « Traiter les documents des clients », c'est un dossier précis et une conversation précise, pas tout le disque et toute la correspondance.

Ce qu'on ouvre sans arrière-pensée

La lecture d'endroits précis. Un canal, un dossier, un libellé dans la messagerie, un agenda, un tableau. Pas « la messagerie », mais « les e-mails portant le libellé Clients ». Pas « le Drive », mais « le dossier Projets 2026 ». Presque toutes les intégrations sérieuses savent restreindre le périmètre — si le produit ne le sait pas, c'est déjà un signal.

L'écriture là où l'erreur est réversible. Un brouillon d'e-mail, un commentaire, une tâche, une carte, une ligne dans un tableau qui garde son historique de versions. Le mot qui compte est réversible : un brouillon se supprime, un e-mail envoyé non.

Les actions de service sans destinataire. Renommer un fichier selon une règle, ranger dans des dossiers, poser une étiquette, agréger des chiffres dans un rapport. Rien de tout cela n'est visible par le client.

Ce qu'on n'ouvre qu'en lecture

Les systèmes financiers. Voir les paiements, les relevés, l'état des abonnements : oui. Initier un mouvement d'argent : non — et mieux vaut que ce soit une restriction technique plutôt qu'un réglage qu'on peut basculer par mégarde.

Les systèmes où vivent les engagements des autres. L'agenda des collègues, les tâches de l'équipe. L'agent peut voir qu'une personne est occupée et proposer autre chose. Déplacer le rendez-vous de quelqu'un, c'est décider à sa place : cela se demande à l'intéressé.

Le dépôt de code. Montrer ce qui est parti en production, quelle pull request attend une revue depuis quatre jours : utile. Écrire et fusionner du code : c'est le travail des ingénieurs et leur responsabilité.

Ce qu'on n'ouvre jamais

L'administration. Gestion des utilisateurs, des rôles, des droits. Un outil capable de s'attribuer des droits à lui-même cesse d'être limité.

Les secrets. Clés d'API, jetons, mots de passe, contenu des coffres à secrets. À part : un numéro de carte n'a rien à faire dans une conversation — s'il y apparaît, le bon comportement de l'agent est de refuser et de demander qu'on ne recommence pas, pas de « le traiter avec soin ».

La suppression irréversible. Effacer des fichiers, des e-mails, des enregistrements, vider la corbeille. Une nouvelle version à côté de l'ancienne : oui. La suppression : non.

Les canaux personnels. Messages privés, échanges sans lien avec le travail. Dans la plupart des produits, c'est une restriction de la plateforme elle-même, et c'est très bien ainsi.

L'envoi en masse sans confirmation. Un envoi ne se rattrape pas. Une erreur de segment, et l'e-mail est parti à toute la base.

Le cas des données personnelles

Ici, limiter l'accès ne suffit pas : il faut aussi limiter le volume.

Si, pour la tâche, il suffit de savoir qu'un document est arrivé et qu'il est lisible, l'agent n'a pas besoin du contenu d'un dossier médical. Si, pour répondre à un client, le numéro de commande suffit, le profil complet est de trop.

Et une règle qui mérite d'être posée à part : là où l'usage exige un consentement, son absence arrête le processus. Pas « on fait attention », mais on ne fait pas.

Ce qui doit être journalisé

Un accès sans journal, c'est de la confiance sans vérification. Le minimum à exiger :

• ce que l'agent a lu, et quand ;
• ce qu'il a modifié, avec la possibilité de consulter la version précédente ;
• ce qui est parti à l'extérieur et qui l'a validé ;
• où il s'est arrêté, et pourquoi.

Le dernier point est sous-estimé, alors que c'est le plus utile : il montre si vos limites fonctionnent, ou si l'agent les contourne parce que vous avez formulé autre chose que ce que vous aviez en tête.

Comment révoquer

Vérifiez-le avant de connecter, pas après. La réponse doit être simple : l'accès est délivré par OAuth et se révoque du côté du service, dans la rubrique des applications connectées, en deux clics et sans passer par le support.

Si la révocation d'un accès exige un e-mail au support, ce n'est pas une intégration, c'est une dépendance.

Les signaux d'alarme, dans n'importe quel produit

La liste est courte, et elle vaut aussi pour nous — passez-y tout le monde, BossForce compris :

1. On vous demande un mot de passe au lieu d'OAuth. Le mot de passe de votre messagerie confié à un service, c'est un accès à tout et pour toujours. Les intégrations sérieuses passent par OAuth avec des droits limités.
2. On ne peut pas restreindre le périmètre. Si la seule option est « accès à toute la boîte mail », vous n'avez pas le choix, donc pas le contrôle non plus.
3. Pas de journal des actions. On ne voit pas ce qui s'est passé, il n'y a donc rien à vérifier.
4. L'envoi sans confirmation par défaut. Le réglage « montre-le-moi d'abord » doit être l'état par défaut, pas une case à cocher qu'il faut aller chercher.
5. À la question sur les limites, on vous répond « le modèle est entraîné à être prudent ». La prudence n'est pas une limite. Une limite, c'est quand l'action est techniquement impossible.

La check-list avant de connecter

• quel accès minimal couvre la tâche ;
• ce qui, là-dedans, peut rester en lecture seule ;
• quelles actions sont irréversibles et si elles sont bien passées en confirmation ;
• où se trouvent les données personnelles et si l'agent a besoin de les voir ;
• comment consulter le journal ;
• comment révoquer l'accès en deux minutes.

Si les six points ont une réponse claire, la conversation sur la sécurité est close : ce qui reste est une question de paramétrage, pas de confiance.