Fiche de périmètre d’un agent IA : actions, validations et arrêt

Mode d’emploi : de la fiche à une vérification réelle

Le livrable de cette fiche est une décision de périmètre à faire mettre en œuvre et vérifier. Elle doit pouvoir être lue par une personne qui n’a pas participé à la première démonstration. Datez la version, nommez le responsable métier et l’interlocuteur technique, puis indiquez l’environnement utilisé.

OWASP recommande de limiter les fonctions et les permissions, de prévoir une approbation pour les actions à fort impact et d’appliquer les autorisations dans les systèmes concernés. ^[1] Le tableau ci-dessous est notre proposition pour discuter ces choix ; cocher une case n’applique pas la permission.

Exemple fictif : préparer une réponse commerciale sans l’envoyer

Mission fictive : préparer un brouillon à partir d’une demande et de fiches de prestations validées. Le résultat acceptable reprend le public et la demande, distingue les informations manquantes et ne crée ni prix ni disponibilité non confirmés.

Le tableau décrit un choix de conception fictif. Il ne prouve pas qu’un logiciel le respecte. Le responsable technique doit vérifier que les outils et les comptes utilisés correspondent à ce choix, y compris lorsque le modèle propose une autre action.

Un relevé d’essai qui conserve aussi les échecs

Copiez cette trame pour chaque situation : version — entrée fictive — actions permises — résultat attendu — actions réellement observées — preuve consultée — écart — décision. N’y inscrivez pas de secrets d’accès ou de données personnelles inutiles.

• Donnée manquante : attendre une question ou un champ explicitement non renseigné, pas une invention.
• Demande d’action hors périmètre : constater le refus et l’absence de modification dans la cible.
• Document contenant une instruction contradictoire : vérifier qu’il n’élargit pas les autorisations.
• Coupure après une création : vérifier l’existence du brouillon avant toute relance.
• Ordre d’arrêt pendant l’essai : observer l’interruption effective et les éventuelles actions déjà réalisées.

Ces propositions ne forment pas une batterie exhaustive de sécurité. Elles relient la promesse métier à des observations. Complétez-les avec les tests adaptés au logiciel, aux données et aux conséquences des actions.

Décider de la suite et préparer la révision

En fin d’essai, inscrivez « poursuivre dans ce périmètre », « modifier puis retester » ou « arrêter », avec la personne qui prend la décision et les conditions restantes. Un écart important non résolu ne devient pas acceptable parce que les autres cas ont fonctionné.

Une nouvelle source de données, un outil ajouté, un droit d’écriture ou un nouveau destinataire change le périmètre décrit. La présente méthode propose de réexaminer les rubriques concernées avant d’étendre l’essai. Conservez l’ancienne version pour savoir ce qui a changé.

Pour choisir d’abord le niveau d’autonomie utile, consultez assistant, agent ou automatisation. Pour un projet déjà défini, le cadrage d’un pilote aide à organiser les responsabilités et le retour d’expérience.