Un agent IA doit recevoir uniquement les actions et accès nécessaires à une tâche métier définie, avec un contrôle distinct des modifications importantes. Avant les connexions, écrivez ce qui peut être lu, préparé, modifié et ce qui exige une décision humaine. Cette frontière appartient à la spécification produit ; un prompt convaincant ne la remplace pas.
Pourquoi la décision opérationnelle change
Un système proposant une réponse et un système modifiant un dossier client posent des questions différentes. L’effet dans l’entreprise connectée compte, même avec un modèle similaire. Une démonstration réussie doit donc être suivie d’un examen des actions réellement autorisées.
Le guide OWASP sur l’Excessive Agency identifie fonctionnalités, permissions et autonomie excessives comme causes d’actions dommageables. Le cadre suivant traduit ce sujet en décision de livraison limitée. Ce n’est ni une certification, ni une garantie de sécurité, ni un remplacement de l’examen du système.
Écrire quatre catégories d’actions
Pour un agent support fictif, lire un ticket autorisé est une catégorie. Préparer une réponse en est une autre. Envoyer ou modifier le compte en constitue une troisième. Rembourser ou élargir l’accès crée d’autres conséquences. Ne donnez pas tout simplement parce que la même intégration le permet.
Définissez la permission minimale utile. Un produit préparant des réponses peut ne pas avoir besoin de les envoyer. S’il utilise quelques champs clients, recherchez un accès limité. Demandez aux développeurs de montrer la frontière réelle, pas seulement les instructions données à l’agent.
Désignez pour chaque action un responsable comprenant conditions, limites et escalade. Sans propriétaire responsable, une action convient mal à l’autonomie, même si son appel technique est facile.
Définir ce qu’approuver signifie
L’approbation doit porter sur une proposition concrète : dossier, destinataire, montant ou changement et contexte. Un bouton générique sans conséquence visible offre peu de contrôle. Présentez assez d’informations pour décider et gardez la proposition stable entre examen et exécution.
Si un agent fictif prépare un remboursement de 50 unités, montrez client, référence, raison et montant. Un changement de destination ou de montant après examen doit constituer une autre proposition. Cet exemple définit un contrôle, sans donner instruction d’effectuer une transaction financière.
Tester limites, arrêt et escalade
Utilisez des données synthétiques pour tester instructions trompeuses, compte hors périmètre et champ manquant. Le bon résultat peut être un brouillon, une clarification ou un arrêt. Réussir un test ne signifie pas toujours effectuer l’action.
Vérifiez que la connexion impose les permissions prévues. Un prompt « ne jamais supprimer » ne prouve pas l’absence de suppression. Testez les pannes intermédiaires : la proposition peut réussir tandis que l’exécution échoue. Le produit doit expliquer l’état réel sans inventer une réussite ou répéter aveuglément une action importante.
Conservez une trace compréhensible des propositions, approbations, tentatives et résultats. Ne stockez pas de contenu sensible inutile pour détailler les journaux. Convenez des accès, durées et responsabilités d’incident pour le client réel.
Élargir l’autonomie avec des preuves
Commencez par le parcours utile le plus étroit. Mesurez travail terminé, exceptions, effort de revue et propositions erronées ou bloquées. Si tout résultat exige beaucoup de correction, davantage de permissions résoudra rarement le problème. Améliorez d’abord processus ou preuves.
La grille des pilotes payés replace ces constats avec valeur client et effort de livraison. Pour les équipes B2B du Benelux et fondateurs pakistanais servant des clients internationaux, le test reste : accomplir une tâche définie de façon fiable dans une frontière convenue. Si vous construisez un jeune produit B2B ou fintech avec cette discipline, présentez parcours, preuves et prochain jalon.