Cet article fait partie de notre dossier « Avant de laisser une IA agir sur vos données d'entreprise », dont le point de départ est ce qu'on confie à un assistant qui agit, et ce qu'on ne lui confie pas. Première question de la grille : avec quels droits l'IA agit-elle ?
Quand on connecte un assistant à sa messagerie, à son logiciel de facturation ou à sa boutique, l'écran de connexion propose en général d'accorder « l'accès ». Ce clic décide de tout le reste : ce que l'outil peut lire, ce qu'il peut modifier, ce qu'il peut dépenser. Le référentiel de l'OWASP sur les applications d'IA range le problème dans une catégorie précise, l'« agentivité excessive », et en donne trois causes : trop de fonctions, trop de permissions, trop d'autonomie. Les trois réglages ci-dessous traitent les deux premières. La troisième fait l'objet du volet suivant.
Un compte dédié, pas le vôtre
Le réflexe le plus courant est de connecter l'assistant avec son propre compte de dirigeant, parce que c'est celui qui est ouvert. C'est aussi celui qui a le plus de droits : accès à toute la messagerie, administration de la fiche Google, droits de remboursement sur la boutique.
Nous recommandons un compte séparé pour l'IA, ou au minimum une connexion qui n'hérite que des droits nécessaires. Trois avantages concrets :
- On sait qui a fait quoi. Dans l'historique de la boutique ou du CRM, une action de l'IA ne se confond pas avec une action humaine.
- On peut couper sans se couper. Révoquer le compte de l'IA ne bloque personne dans l'équipe.
- Les droits se règlent séparément. Le compte de l'assistant peut lire les commandes sans pouvoir rembourser, publier un brouillon sans pouvoir le mettre en ligne.
L'OWASP formule la même idée sous une autre forme : faire agir l'outil dans le contexte de l'utilisateur concerné, avec la portée la plus réduite possible, plutôt qu'avec un accès général.
Lecture seule par défaut
Beaucoup d'usages utiles n'ont besoin d'aucun droit d'écriture. Résumer les e-mails de la journée, lister les factures en retard, repérer les avis Google sans réponse, préparer un tableau des ventes : tout cela se fait en lecture. L'OWASP donne précisément cet exemple : un outil qui résume des e-mails n'a pas besoin de pouvoir en envoyer ni en supprimer.
Notre méthode est de démarrer chaque intégration en lecture seule, puis d'ouvrir un droit d'écriture à la fois, quand l'usage le justifie et que le contrôle est en place. On ouvre plus facilement un droit qu'on ne répare une action mal faite.
| Outil connecté | Droit utile au départ | Droit à ouvrir plus tard, avec contrôle | Droit à ne pas donner |
|---|---|---|---|
| Messagerie | Lire, rédiger des brouillons | Envoyer, après validation | Supprimer, transférer automatiquement |
| Facturation | Lire factures et relances | Préparer une relance | Émettre un avoir ou un remboursement sans validation |
| Boutique en ligne | Lire commandes et catalogue | Proposer une fiche produit en brouillon | Modifier les prix publiés, gérer les accès |
| Fiche Google | Lire les avis | Rédiger une réponse à valider | Modifier horaires et coordonnées sans relecture |
Ce tableau est une base de discussion, pas une règle universelle : une entreprise qui reçoit cent e-mails par jour n'arbitre pas comme celle qui en reçoit dix. L'important est que la décision soit prise, et notée.
