Commencer par une seule tâche et un résultat réversible
Choisissez un travail précis que l’agent pourrait accomplir, par exemple préparer un brouillon de réponse à partir d’une foire aux questions. Écrivez son point de départ, le résultat attendu et la personne qui doit approuver ce résultat. Pour un premier essai, évitez l’envoi automatique, les paiements, la suppression de fichiers et les décisions qui touchent les droits d’une personne. Un bon scénario permet d’annuler facilement une erreur et de comparer le résultat à une méthode actuelle connue. Créez ensuite un espace d’essai séparé. Utilisez une boîte courriel fictive, un dossier contenant des documents inventés et un compte sans accès aux données de production. Ajoutez un message ambigu, une pièce jointe vide, un fichier périmé et une demande qui dépasse le mandat. L’agent doit pouvoir produire un brouillon, indiquer la source consultée et s’arrêter lorsque l’information manque. Cette petite scène donne un objectif mesurable avant même de discuter de permissions techniques.
Dresser la liste des ressources avant celle des outils
Faites une ligne par ressource réelle : boîte de réception, calendrier, répertoire partagé, base de clients, outil de facturation, clavardage d’équipe et service d’envoi. N’écrivez pas seulement le nom du logiciel. Précisez le dossier, le type de message ou la collection de données visée. Un accès à « Drive » peut signifier un seul dossier de procédures ou l’ensemble des fichiers de l’organisation; ces deux autorisations n’ont pas du tout la même portée. Ajoutez pour chaque ligne le propriétaire, la sensibilité et la durée d’accès nécessaire. Notez aussi les chemins indirects. Une boîte courriel peut ouvrir des pièces jointes; un calendrier contient des invités; un outil de soutien donne parfois accès aux coordonnées et à l’historique d’un client. Demandez à l’équipe qui administre le système de confirmer la portée réelle du connecteur. La description commerciale d’une intégration ne suffit pas à prouver les champs que l’agent peut lire ni les actions qu’il peut déclencher.
Construire une matrice avec quatre actions distinctes
Créez un tableau avec les ressources en lignes et quatre colonnes : lire, modifier, envoyer et supprimer. Remplissez chaque case avec « permis », « approbation requise » ou « interdit ». Pour l’agent qui prépare des réponses, la lecture du dossier de procédures peut être permise, la création d’un brouillon peut demander une approbation et l’envoi comme la suppression peuvent rester interdits. Ajoutez une cinquième colonne pour la preuve attendue : journal, lien vers la source, identité de l’approbateur ou copie du brouillon. Ne regroupez pas écrire et envoyer. Modifier un document interne n’équivaut pas à publier une réponse au nom de l’organisation. Ne regroupez pas non plus lire et télécharger : un connecteur peut consulter un fichier à la demande tout en empêchant une copie permanente. Si une case demeure difficile à classer, réduisez la portée. Accordez un dossier plutôt qu’un disque complet, un brouillon plutôt qu’un envoi et une période d’essai plutôt qu’un accès continu. La matrice doit décrire le réglage réel, pas l’intention générale de l’équipe.
Tester les refus autant que les actions permises
Connectez l’agent uniquement à l’environnement fictif, puis préparez huit essais. Deux doivent vérifier les lectures autorisées, deux les brouillons permis et quatre les limites : tenter d’ouvrir un dossier voisin, d’envoyer sans approbation, de supprimer une pièce et d’utiliser une information absente. Pour chaque essai, notez la demande, l’action attendue, l’action observée, le compte utilisé et la trace produite. Un refus clair est un résultat réussi lorsqu’il correspond à la matrice. Vérifiez aussi le comportement après une erreur humaine. Refusez un brouillon, changez le rôle d’un compte et déplacez un document hors du dossier autorisé. L’agent doit voir les nouvelles limites sans conserver un ancien accès dans une session, un cache ou une copie. Examinez les journaux avec la personne responsable du système : ils devraient montrer quelle identité a demandé l’action, quelle ressource a été touchée et si une approbation a été donnée. Un écran qui affiche « accès refusé » ne prouve pas à lui seul que rien n’a été copié ailleurs.
Faire un exercice de révocation avant le projet pilote
Avant de brancher de vraies données, retirez toutes les permissions de l’agent comme si un incident venait d’être signalé. Chronométrez le temps nécessaire pour désactiver le compte, couper les jetons d’accès, bloquer les connecteurs et retrouver les actions récentes. Vérifiez qu’une conversation déjà ouverte ne peut plus consulter les ressources. Confirmez aussi qui peut exécuter cette révocation le soir ou la fin de semaine. Si la procédure dépend d’une seule personne, le projet n’est pas encore prêt. Réactivez ensuite seulement les cases approuvées dans la matrice et rejouez les huit essais. Conservez la version du tableau, la date, les comptes testés et les écarts observés. Pendant le projet pilote, commencez avec un faible volume et exigez une approbation humaine pour toute action externe. Refaites le test après l’ajout d’un outil, un changement de modèle ou une mise à jour du connecteur. Une carte des accès n’élimine pas toutes les erreurs; elle rend toutefois les pouvoirs de l’agent visibles, vérifiables et assez précis pour être retirés rapidement.
