Un assistant qui rédige un brouillon et un agent qui modifie un logiciel métier n’ont pas le même impact. Dans le second cas, l’IA reçoit des outils et peut déclencher des actions. Cette évolution peut éviter des manipulations répétées, à condition de définir précisément ce que le système a le droit de faire.
Commencer par une action limitée
Prenons un exemple fictif : préparer une fiche de suivi après une réunion. Le système peut extraire les décisions, proposer des tâches et présenter un aperçu. Une personne vérifie ensuite le résultat avant sa création dans l’outil de gestion. Cette étape permet de mesurer la qualité de la préparation tout en gardant une validation claire.
Passer directement à l’envoi de messages, à la modification de plusieurs dossiers ou à une série d’actions invisibles rend les erreurs plus difficiles à comprendre. Une première automatisation gagne à avoir une entrée explicite, une action bornée et un résultat vérifiable.
Donner uniquement les outils nécessaires
Un connecteur disponible ne doit pas donner accès à toutes les fonctions du service. Lire un document, créer un brouillon et supprimer un dossier sont des permissions différentes. Les autorisations doivent correspondre au rôle de l’utilisateur et au périmètre de l’agent.
Les secrets d’accès restent côté serveur. Le modèle peut proposer des paramètres, mais le serveur doit les vérifier : destination autorisée, type de contenu, taille, propriété de la ressource et droit de réaliser l’opération. Une instruction textuelle demandant au modèle d’être prudent n’est pas un contrôle d’accès.
Prévoir les contenus trompeurs
L’OWASP décrit l’injection indirecte comme la présence d’instructions malveillantes dans un contenu que le modèle consulte, par exemple une page ou un message. Pour un agent, le problème peut aller au-delà d’une réponse incorrecte si ce contenu influence une action.
Traitez donc les résultats d’outils et les documents comme des données à examiner. Limitez les actions possibles indépendamment du texte reçu. Pour les opérations sensibles, présentez à l’utilisateur la destination, les données concernées et l’effet attendu avant toute confirmation.
Gérer les erreurs sans multiplier les actions
Un service externe peut ne pas répondre alors que l’action a été effectuée. Réessayer automatiquement peut créer un doublon. Il faut distinguer un échec certain d’un résultat incertain et utiliser, lorsque le service le permet, un identifiant stable pour une même opération.
Le suivi doit également borner les tentatives, la durée et les dépenses. Si l’agent tourne en boucle ou si un connecteur devient indisponible, l’utilisateur doit voir l’état de la tâche et savoir ce qui nécessite une intervention. Un historique utile indique les opérations et leurs résultats sans conserver inutilement des données sensibles.
Évaluer le processus complet
Le profil du NIST consacré à l’IA générative invite à examiner les risques tout au long du cycle de vie. Pour un agent métier, notre grille pratique couvre la qualité du résultat, les actions refusées, les erreurs de service, la révocation d’un accès et la capacité de reprise.
Mesurez aussi le temps passé à contrôler le travail. Une automatisation n’est utile que si l’ensemble du parcours devient plus simple ou plus fiable pour la tâche choisie. Les solutions du studio et notre guide de cadrage permettent de préparer cette discussion à partir d’un usage réel, avant d’ajouter des connecteurs.
