Quand une IA commence à agir à notre place

Demander à une intelligence artificielle de résumer dix courriels n’est pas la même chose que lui demander d’y répondre. Dans le premier cas, elle produit un texte. Dans le second, elle peut engager une conversation réelle, modifier une relation professionnelle ou envoyer une information au mauvais destinataire. Ce passage de la réponse à l’action est au cœur des agents d’intelligence artificielle.

Du chatbot à l’agent : la frontière se déplace

Un assistant conversationnel classique répond à une demande en générant du texte, du code ou une analyse. Un agent ajoute une capacité décisive : utiliser des outils. Il peut interroger un calendrier, rechercher des documents, préparer des opérations dans un logiciel ou transmettre une requête à un service externe.

L’agent peut enchaîner plusieurs étapes. Par exemple, il trouve une invitation reçue par courriel, vérifie les disponibilités, prépare une proposition de rendez-vous puis demande la confirmation de son utilisateur. Les résultats d’une étape orientent les suivantes.

Ce fonctionnement est utile parce que les tâches de bureau ne sont pas de simples questions. Elles comportent des décisions, des actions et des conséquences. Mais il soulève aussi un problème nouveau : comment définir précisément ce que la machine a le droit de faire ?

Une instruction cachée dans un document

Imaginons qu’un agent reçoive pour mission de parcourir des courriels afin de préparer un résumé. Parmi les messages, un texte indique à l’agent de transférer des documents internes vers une autre adresse.

Ce texte n’a pas été écrit par la personne qui a donné la mission. Il appartient au contenu à analyser. Un système vulnérable pourrait néanmoins le traiter comme une instruction à exécuter.

Ce mécanisme porte le nom d’injection de prompt. Il peut se produire dans une page Web, un fichier, un courriel ou tout autre contenu dont l’agent se sert pour travailler. L’enjeu n’est pas seulement de produire une réponse incorrecte : lorsqu’un modèle dispose d’outils, une instruction trompeuse peut déclencher une action réelle.

L’OWASP distingue notamment l’injection de prompt et la question de l’autonomie excessive (excessive agency). Dans sa classification 2025 des risques pour les applications fondées sur les grands modèles de langage, elle souligne que des permissions trop larges ou des outils trop puissants peuvent amplifier les conséquences d’une erreur ou d’une manipulation.

Le problème n’est pas que l’IA ait accès aux outils

Interdire tout accès aux systèmes empêcherait précisément les usages qui rendent les agents intéressants. La question consiste plutôt à proportionner les capacités à la tâche.

Un agent chargé de résumer des fichiers n’a généralement pas besoin de pouvoir les supprimer. Un outil qui vérifie les disponibilités d’un calendrier n’a pas nécessairement à pouvoir annuler des réunions. Un assistant qui prépare des paiements peut être utile sans être autorisé à les confirmer.

Trois niveaux d’intervention peuvent guider la conception :

• Observer : consulter des données et les analyser sans les modifier.
• Préparer : créer des brouillons ou des propositions réversibles.
• Exécuter : envoyer, supprimer, publier, payer ou modifier des informations avec des effets réels.

Cette classification n’est pas un standard technique universel, mais un repère pratique pour attribuer des permissions. Une action irréversible ou sensible devrait faire l’objet de contrôles supplémentaires, indépendants du texte produit par le modèle.

L’approbation humaine ne résout pas tout

On présente souvent la validation humaine comme une réponse simple : l’agent propose, une personne approuve. Cette précaution est utile, mais uniquement si la personne comprend réellement ce qu’elle valide.

Une demande vague du type « Autoriser cette opération ? » n’informe pas suffisamment. Une bonne confirmation indique plutôt la destination, les données concernées, l’action envisagée et ses conséquences possibles.

Il faut également empêcher qu’un agent contourne le mécanisme d’approbation en appelant un autre outil disposant de droits plus étendus. Le contrôle doit être appliqué par les systèmes qui exécutent les actions, et pas seulement demandé au modèle dans une consigne.

L’enregistrement des opérations, les limites de dépenses, les droits temporaires, les environnements de test et la possibilité d’interrompre un traitement constituent d’autres moyens de réduire les risques.

Comment mesurer le travail d’un agent ?

La qualité d’une réponse écrite peut être évaluée en relisant le texte. Pour un agent, cela ne suffit plus. Il faut vérifier si la tâche a été accomplie, si les bonnes données ont été utilisées et si aucune action indésirable n’a été déclenchée.

Un système capable d’obtenir un résultat correct neuf fois sur dix peut rester inadapté à une mission qui autorise des virements, des suppressions de dossiers ou l’envoi de renseignements confidentiels. La fiabilité doit être mesurée à l’échelle du processus complet, y compris les erreurs rares et leurs conséquences.

Dans son profil de gestion des risques de l’IA générative, le NIST recommande une approche qui couvre la conception, l’évaluation, l’usage et la surveillance des systèmes. Cette logique est particulièrement importante lorsque plusieurs outils et sources de données interagissent.

De l’assistance à la délégation

Les agents IA ne deviennent pas intéressants uniquement parce qu’ils rédigent plus vite. Ils changent la forme du travail : une personne peut leur confier une succession d’étapes au lieu d’effectuer chaque manipulation.

Mais déléguer une tâche n’équivaut pas à déléguer toutes les décisions qu’elle pourrait entraîner. La conception d’un bon agent suppose donc une frontière claire entre consultation, préparation et exécution.

L’objectif raisonnable n’est ni une autonomie illimitée ni un assistant incapable d’agir. C’est un système dont les permissions, les contrôles et les traces permettent de savoir ce qu’il a fait, au nom de qui, et avec quelle autorisation.