Comment limiter les permissions d'un agent IA avant d'automatiser les tâches récurrentes

La différence pratique entre un assistant conversationnel et un agent apparaît lorsque la tâche continue après la réponse. Un système génératif peut préparer un résumé ou un brouillon ; un agent peut, en plus, consulter des outils, décider des étapes suivantes et exécuter des actions dans les permissions accordées. Le risque change de produire une réponse incorrecte à modifier quelque chose de réel.

L'étiquette « agent » ne garantit pas un niveau concret d'autonomie. Certaines fonctions ne préparent que des résultats pour révision ; d'autres opèrent avec des applications, des fichiers ou des services connectés. Il convient d'évaluer les actions que le système peut réaliser, pas le nom commercial ni la promesse d'automatisation.

Cela aide aussi à décider quand ne pas utiliser un agent. Si une tâche est ponctuelle, ses étapes sont prévisibles et il suffit de recevoir un brouillon, un outil génératif conventionnel peut être plus simple. Un agent est plus pertinent lorsque le flux exige un suivi, plusieurs étapes ou réagir aux changements, mais cette utilité dépend de la capacité à limiter ses effets.

Avant d'activer une intégration, écrivez ce que l'agent doit lire, ce qu'il peut modifier et quel résultat il doit livrer. Il ne suffit pas d'énumérer les applications : dans un même service, il peut exister des permissions de lecture, d'édition, d'envoi ou d'administration. Séparez l'accès aux données de l'autorisation d'agir.

L'aide de Meta pour Muse sur Mac illustre pourquoi cette distinction compte. Elle décrit les permissions macOS pour accéder au disque, automatiser les applications et afficher des notifications ; elle permet aussi de configurer les applications locales comme désactivées, en lecture seule ou avec capacité d'interaction. Pour accéder à certains fichiers, la permission de disque peut couvrir un ensemble large, bien que la tâche demandée soit concrète. Cette ampleur doit faire partie de l'évaluation, pas rester cachée derrière la commodité du flux.

Une révision initiale utile peut être brève et spécifique :

• Données : identifiez les dossiers, boîtes mail, dépôts ou projets que l'agent doit consulter.
• Actions : distinguez lire, créer, éditer, supprimer, envoyer, publier et acheter.
• Connexions : supprimez les intégrations qui n'interviennent pas dans le flux choisi.
• Propriété : confirmez qui peut accorder et révoquer chaque permission.

Perplexity décrit Teammates comme des agents qui peuvent se connecter à des outils comme Slack, GitHub et Gmail et hériter des permissions associées à ces outils et projets. Pour un dépôt GitHub, le guide cité dans la couverture indique qu'on peut sélectionner à lesquels donner accès. Accorder l'accès à un outil ne définit pas à lui seul quelle tâche est sûre : l'ampleur de l'espace connecté et les opérations autorisées comptent aussi.

Divisez le travail en deux groupes : actions réversibles à faible impact et actions avec conséquences externes ou difficiles à annuler. Lire, classer et préparer un brouillon sont de bons candidats à automatiser d'abord ; envoyer un message, changer des permissions, publier ou supprimer mérite un contrôle plus strict. L'approbation doit se situer avant la conséquence, pas après la réception d'un résumé.

L'aide de Meta indique que Muse demande confirmation avant des actions importantes, comme envoyer un e-mail ou faire un achat, et que les fichiers supprimés vont à la corbeille. C'est une caractéristique décrite pour ce produit, pas une règle générale pour tous les agents. Dans n'importe quel outil, vérifiez quelles actions exigent confirmation et lesquelles peuvent s'exécuter directement ; une option de supervision n'équivaut pas nécessairement à une barrière technique.

Une politique simple peut ordonner l'autonomie par étapes : d'abord permettre la lecture et les propositions ; ensuite, des changements réversibles dans un environnement de test ; enfin, des actions externes seulement avec approbation explicite. N'augmentez pas les permissions par commodité avant de vérifier que le système s'arrête quand il manque d'informations, détecte des résultats inattendus et clarifie ce qu'il entend faire.

Pour chaque flux, notez par écrit trois limites : ce qu'il peut faire sans demander, ce qui exige approbation et ce qui est interdit. Ajoutez qui peut approuver et comment arrêter une exécution. Si le produit ne permet pas d'exprimer une limite techniquement, compensez en réduisant l'accès ou en gardant cette étape sous intervention humaine ; une instruction en langage naturel peut ne pas remplacer un contrôle de permissions du système.

Un agent persistant peut réutiliser des fichiers, des instructions et des résultats antérieurs pour continuer une tâche. Cette continuité économise des explications, mais peut aussi traîner des informations obsolètes ou une interprétation erronée. La mémoire doit avoir un but et un périmètre, comme l'accès à un dossier ou à un compte.

Perplexity présente Teammates comme des agents qui peuvent s'appuyer sur des projets, des fichiers, des compétences et la mémoire de Computer, et recevoir des commentaires applicables aux tâches ultérieures. Avant d'utiliser une fonction de ce type, décidez quel contexte doit être maintenu entre les exécutions, qui peut l'éditer et comment il est corrigé. Ne sauvegardez pas comme instruction permanente une préférence provisoire ni ne transformez un résultat généré par l'agent en source de vérité sans révision.

Muse peut lire des informations stockées localement dans des applications Mac que l'utilisateur autorise. L'aide de Meta indique que l'utilisateur peut ajuster l'accès à ces applications dans les paramètres et le retirer ensuite. Révisez le contexte par application, et pas seulement la permission générale : un agent qui résume des messages n'a pas nécessairement besoin de permission pour envoyer des messages ou modifier des notes.

Pour réduire les dérives dans les tâches prolongées, délimitez l'objectif et la date de validité des instructions. Demandez à l'agent de signaler les données qu'il ne peut pas vérifier, de s'arrêter face à des instructions contradictoires et de distinguer les faits des suppositions. Si le flux change, re-vérifiez les fichiers, les permissions et le contexte : la mémoire utile pour un projet peut être inappropriée pour un autre.

La supervision doit permettre de répondre à des questions concrètes : quelles informations l'agent a consultées, quelles étapes il a tentées, ce qu'il a changé et ce qui reste en suspens. Un résumé final ne suffit pas toujours ; pour réviser une erreur, il faut des registres associés à la tâche et un moyen de distinguer une proposition d'une action effectivement réalisée. La traçabilité sert à détecter et corriger les impacts, pas seulement à expliquer le résultat.

Meta indique que Muse peut avertir quand une tâche se termine, que les actions importantes exigent confirmation et que l'utilisateur peut révoquer les permissions depuis les paramètres macOS. Perplexity, selon les informations sur Teammates, permet de réviser le travail, de prendre le contrôle du bureau ou de modifier les instructions pendant que l'agent est actif. Ce sont des contrôles distincts : la révision rétrospective, l'interruption pendant l'exécution et la révocation des permissions ne sont pas interchangeables.

Une routine de révision peut se centrer sur ce qui change le risque :

• Vérifiez les changements dans les fichiers, tickets ou dépôts avant de les incorporer au travail partagé.
• Révisez les messages et publications avant qu'ils n'atteignent des tiers.
• Confirmez que les tâches incomplètes restent marquées comme en attente, pas comme terminées.
• Révoquez les connexions qui ne sont plus nécessaires et vérifiez que la tâche s'est arrêtée.

Maintenez un canal pour signaler les erreurs et conservez les instructions de la tâche avec le résultat. Si l'agent n'offre pas de registres suffisamment clairs, limitez son usage aux tâches de lecture ou de préparation. L'autonomie doit correspondre à la capacité réelle d'auditer et d'arrêter le système.

Commencez avec un flux à faible impact, un petit ensemble de données et une seule intégration. Définissez à l'avance le résultat attendu et un critère de succès vérifiable ; par exemple, que l'agent classe des éléments sans les supprimer ni répondre à leur place. Pendant les premières exécutions, comparez le résultat avec une révision manuelle et observez où il se trompe ou a besoin de clarifications.

Après ce test, élargissez une seule dimension à la fois : plus de données, un nouvel outil ou une action supplémentaire. Si plusieurs sont ajoutées en même temps, il sera plus difficile d'identifier quelle permission ou étape a provoqué un problème. L'expansion progressive transforme la supervision en une décision basée sur le flux concret, pas sur une confiance générale dans la catégorie de produit.

Enfin, incorporez les coûts et les limites d'utilisation dans la décision. La couverture du lancement de Teammates décrit une relation avec les crédits de Perplexity Computer et explique que les tâches peuvent être mises en pause quand les crédits nécessaires s'épuisent. C'est un détail spécifique à ce service ; dans d'autres produits, il faut revoir leurs propres quotas, conditions de reprise et options de dépense supplémentaire avant de planifier un travail continu.

Le critère d'adoption est opérationnel : déléguiez seulement les tâches dont les données, permissions, points d'approbation, mémoire et registres vous permettent de gérer. Si vous ne pouvez pas répondre qui a autorisé une action ou comment l'arrêter, maintenez le flux en mode proposition. Un agent utile n'est pas celui qui agit le plus, mais celui qui résout un travail borné sans dépasser l'autorité qui lui a été accordée.