Les agents IA dans vos systèmes : ce qu'un agent peut faire seul, ce qu'une personne doit approuver, et comment démarrer sans perdre le contrôle

Un agent IA est un modèle de langage qui peut demander à votre logiciel d'exécuter des fonctions, c'est-à-dire des actions comme rechercher un paiement, mettre à jour un ticket ou émettre un remboursement. Le modèle se contente de formuler la demande. Ce sont vos systèmes qui décident de l'exécuter ou non, et c'est là que vous gardez le contrôle. Commencez par une tâche bien délimitée, où l'agent lit des données et prépare des brouillons de lui-même. Une personne nommément désignée approuve tout ce qui déplace de l'argent, modifie la fiche d'un client ou sort de l'entreprise.

Qu'est-ce qu'un agent IA, en termes simples ?

Un modèle de langage, le type d'IA sur lequel repose ChatGPT, produit du texte. Un agent est un modèle de langage relié à des fonctions de vos systèmes : ce qu'il produit peut donc être une action aussi bien qu'une réponse.

La documentation d'Anthropic sur ses modèles Claude indique : « L'utilisation d'outils (aussi appelée appel de fonctions) permet à Claude d'appeler des fonctions que vous définissez ou qu'Anthropic fournit. » Pour les fonctions que vous définissez, le modèle « renvoie un appel structuré que votre application exécute ». Il rédige la demande, et votre logiciel l'exécute ou la refuse. Toutes les sources de cet article ont été consultées le 2 novembre 2026.

Un agent répète cela en boucle. Il appelle une fonction, lit le résultat et choisit l'étape suivante jusqu'à ce que la tâche soit terminée. Un billet publié en 2024 sur le blog d'ingénierie d'Anthropic décrit les agents comme « généralement de simples LLM qui utilisent des outils en fonction des retours de leur environnement, en boucle. » LLM est l'abréviation de large language model (grand modèle de langage), et les outils sont les fonctions qu'il peut appeler.

Un agent ne peut donc faire que ce que ses fonctions permettent. La liste des fonctions est sa fiche de poste, et c'est le premier document à demander.

Pourquoi est-il important de savoir si l'agent lit des données ou les modifie ?

Parce que lire ne change rien. Si l'agent récupère les cinq derniers paiements d'un client et se trompe sur l'un d'eux, le résultat est un brouillon erroné, qu'une personne peut repérer.

Écrire modifie quelque chose en dehors du modèle : un remboursement est versé ou un e-mail parvient à un client. Certaines de ces modifications ne peuvent pas être annulées.

Le guide d'OpenAI sur la construction d'agents suggère de classer chaque fonction en risque faible, moyen ou élevé « en fonction de facteurs comme l'accès en lecture seule ou en écriture, la réversibilité, les autorisations de compte requises et l'impact financier. » La lecture ne reste à faible risque que tant que l'agent ne peut envoyer nulle part ce qu'il a lu. La section sur l'injection de prompt, une ruse qui consiste à glisser des instructions dans un e-mail ou un document, montre pourquoi.

Quelles actions l'agent peut-il effectuer seul, et lesquelles nécessitent une personne ?

Classez chaque fonction dans l'un des trois groupes :

• L'agent seul : lire des données, chercher dans des documents, étiqueter, et rédiger des brouillons qui restent dans vos systèmes jusqu'à ce que quelqu'un les utilise
• L'agent propose, une personne approuve : tout ce qui déplace de l'argent, modifie la fiche ou le statut d'un client, ou envoie un message hors de l'entreprise
• Jamais : les modifications de droits d'accès, de limites ou de coordonnées bancaires, et les décisions que votre régulateur attend d'une personne nommément désignée

Pour la plupart des fonctions, quatre questions déterminent le groupe :

• L'action peut-elle être annulée, et par qui ?
• Déplace-t-elle de l'argent ou modifie-t-elle ce que doit un client ?
• Un client, un partenaire ou un régulateur verra-t-il le résultat ?
• Une loi, une condition de votre licence ou votre propre politique impose-t-elle qu'une personne décide ?

Le guide d'OpenAI donne le même conseil pour le groupe du milieu : « Les actions sensibles, irréversibles ou à fort enjeu devraient déclencher une supervision humaine jusqu'à ce que la confiance dans la fiabilité de l'agent grandisse. » Parmi ses exemples figurent « l'annulation de commandes d'utilisateurs, l'autorisation de remboursements importants ou l'exécution de paiements. »

L'OWASP Top 10 for LLM Applications 2025, une liste de risques publiée par le projet de sécurité OWASP, comporte une entrée appelée autonomie excessive (excessive agency). Elle couvre les dommages qu'un agent peut causer quand il dispose de plus de fonctions, de droits ou de liberté que sa tâche n'en exige. L'une des mesures qu'elle cite consiste à « exiger qu'un humain approuve les actions à fort impact avant qu'elles ne soient effectuées. »

À quoi cela ressemble-t-il dans le support, l'entrée en relation, les paiements et le reporting ?

Dans chaque domaine, l'agent lit et rédige, et une personne garde les décisions. Votre propre liste dépend de vos systèmes et de ce qu'attend votre régulateur.

• Support : l'agent étiquette les tickets et rédige des réponses. Au début, une personne approuve chaque réponse, et les remboursements comme les exonérations de frais exigent toujours une approbation. L'agent ne modifie jamais l'adresse e-mail ni le numéro de téléphone d'un client, car quiconque les contrôle peut réinitialiser l'accès du client
• Entrée en relation : l'agent vérifie que les documents ne comportent pas de champs manquants et les résume pour l'analyste. Une modification de la notation de risque attend une approbation, et l'acceptation d'un client reste du ressort d'une personne
• Paiements : l'agent rapproche les lignes de relevé bancaire des factures et signale les écarts. Le déblocage d'un paiement retenu attend une approbation, et ce n'est jamais à l'agent de modifier les coordonnées bancaires d'un bénéficiaire
• Reporting : l'agent rédige le rapport mensuel avec la source de chaque chiffre. Une personne approuve tout ce qui est envoyé à un client, au conseil d'administration ou à un régulateur

Où placer l'étape d'approbation ?

Placez l'approbation dans le logiciel qui exécute la fonction, et pas seulement dans le prompt, c'est-à-dire l'ensemble des instructions que reçoit le modèle. Un modèle peut ignorer une ligne de son prompt ou se laisser convaincre de ne pas la respecter. Une fonction de remboursement qui ne s'exécute pas sans le clic d'un approbateur ne se laisse convaincre de rien.

Les recommandations de l'OWASP vont dans le même sens : « Mettez en œuvre l'autorisation dans les systèmes en aval plutôt que de compter sur un LLM pour décider si une action est autorisée ou non. »

Un écran d'approbation utile montre à l'approbateur :

• L'action, l'enregistrement qu'elle modifie et le montant
• L'enregistrement avant et après la modification
• Les éléments sur lesquels l'agent s'est appuyé, comme le ticket ou la ligne de relevé
• Un motif obligatoire chaque fois que l'approbateur refuse

Si chaque proposition est approuvée en quelques secondes, c'est que les gens ont cessé de vérifier. Le règlement européen sur l'IA (AI Act) a un nom pour cela : le biais d'automatisation. Son article sur le contrôle humain dispose que les personnes qui contrôlent un système à haut risque doivent pouvoir rester conscientes de « l'éventuelle tendance à se fier automatiquement ou excessivement aux sorties ». Revérifiez chaque semaine un échantillon d'actions approuvées.

Quels droits le compte de l'agent doit-il avoir ?

Le compte de l'agent doit autoriser les fonctions de sa liste, et rien d'autre. Donnez à chaque agent son propre compte dans chaque système qu'il touche, jamais un compte administrateur ni les identifiants d'un salarié. Définissez ces droits dans le système lui-même, là où le modèle ne peut pas les modifier. Les mots de passe et les clés restent dans votre logiciel, hors de la vue du modèle.

L'exemple de l'OWASP est un agent qui recommande des produits et qui « n'a peut-être besoin que d'un accès en lecture à une table “products” ». L'OWASP met aussi en garde contre les fonctions ouvertes, comme l'exécution de n'importe quelle commande sur un serveur, et préfère des fonctions étroites qui font chacune une seule chose.

Quand l'agent travaille pour un salarié, il doit agir « dans le contexte de cet utilisateur précis, et avec les privilèges minimaux nécessaires », selon les termes de l'OWASP. Il ne peut alors ni voir ni faire plus que cette personne.

Qu'est-ce que l'injection de prompt, et pourquoi compte-t-elle davantage pour les agents ?

L'injection de prompt (prompt injection) consiste à glisser des instructions dans un texte que l'agent lit, comme un e-mail, un ticket ou un document importé. Le modèle peut les suivre comme si elles venaient de vous. Les instructions peuvent être invisibles pour un lecteur humain, et avec un agent elles peuvent se transformer en actions. L'OWASP place l'injection de prompt en premier dans sa liste 2025 et indique qu'« on ne sait pas s'il existe des méthodes de prévention infaillibles contre l'injection de prompt. »

La fiche de l'OWASP sur l'autonomie excessive décrit un assistant qui lit une boîte mail pour résumer les e-mails entrants. Le module complémentaire qu'il utilise peut aussi envoyer des e-mails. Un e-mail piégé l'amène à chercher des informations sensibles dans la boîte de réception et à les transférer à l'attaquant.

Les correctifs de l'OWASP commencent par une fonction qui ne peut que lire les e-mails et un accès en lecture seule à la boîte mail. Une personne doit aussi « relire manuellement et cliquer sur “envoyer” pour chaque e-mail rédigé par l'extension LLM. » Comme l'injection de prompt ne peut pas être exclue, prévoyez le cas d'un agent qui a été trompé, et limitez les dégâts qu'il peut faire.

Que faut-il journaliser, et comment revenir sur une erreur ?

Journalisez chaque appel de fonction. Chaque entrée indique l'agent, la fonction et ses paramètres d'entrée, le résultat, le texte qui a conduit à l'appel, la version du modèle et du prompt, ainsi que qui l'a approuvé et quand. Une personne extérieure à l'équipe qui a construit le système doit pouvoir lire le journal et dire ce qui est arrivé à un client donné.

L'OWASP note que la journalisation et les limites de débit n'empêcheront pas l'autonomie excessive, « mais peuvent limiter l'ampleur des dommages causés ». Une limite de débit plafonne le nombre d'actions d'un même type que l'agent peut effectuer dans un temps donné, si bien qu'une série de mauvaises actions s'arrête tôt.

Avant le lancement, notez par écrit comment on annule l'effet de chaque fonction qui modifie des données, et qui s'en charge. Préférez les fonctions qui créent un élément en attente, comme un remboursement qui patiente dans une file. Un élément en attente peut être supprimé, alors qu'un paiement envoyé est difficile à récupérer. Prévoyez un interrupteur qui désactive d'un coup les fonctions de l'agent, sans nouvelle version du logiciel, et testez-le avant la mise en service.

La loi impose-t-elle qu'une personne approuve ?

Dans l'UE, le règlement européen sur l'IA (AI Act) fixe des règles de contrôle humain pour les systèmes d'IA qu'il classe à haut risque. Ces règles figurent à l'article 14, et l'annexe III énumère les usages à haut risque. La liste comprend l'évaluation de la solvabilité des personnes physiques ou l'établissement de leur note de crédit, les systèmes de détection des fraudes financières étant toutefois exclus. Elle comprend aussi l'évaluation des risques et la tarification pour les personnes physiques en matière d'assurance-vie et d'assurance maladie. L'AI Act Service Desk de la Commission européenne indique le 2 décembre 2027 comme date d'application des règles relatives aux systèmes à haut risque de l'annexe III. Cette date tient compte des modifications apportées par l'omnibus numérique sur l'IA (Digital Omnibus on AI). Ce type de date peut bouger : vérifiez donc le calendrier en vigueur avant de vous organiser en fonction.

L'article 14 dispose que les mesures de contrôle « sont proportionnées aux risques, au niveau d'autonomie et au contexte d'utilisation » du système. Les personnes chargées du contrôle doivent être en mesure « de décider, dans une situation particulière, de ne pas utiliser le système d'IA à haut risque ou d'ignorer, remplacer ou inverser d'une autre manière la sortie ». Elles doivent aussi pouvoir l'arrêter avec « un bouton d'arrêt ou une procédure similaire ».

Ces règles ne s'appliquent qu'aux systèmes à haut risque que le règlement énumère, et beaucoup d'agents du support et des opérations n'en feront pas partie. Les mêmes contrôles restent pertinents pour ces agents. Savoir si votre système relève de ces règles est une question pour vos avocats. Cet article ne constitue pas un conseil juridique et ne couvre que les règles de l'UE.

Comment démarrer sans perdre le contrôle ?

Commencez par vous demander si la tâche a vraiment besoin d'un agent. Le billet d'ingénierie d'Anthropic recommande de « trouver la solution la plus simple possible et de n'augmenter la complexité qu'en cas de besoin », et ajoute : « Cela peut vouloir dire ne pas construire de systèmes agentiques du tout. » Pour beaucoup de tâches, une seule requête au modèle ou une suite d'étapes fixe suffit. Une suite fixe se comporte aussi de façon plus prévisible qu'un agent qui choisit ses propres étapes.

Choisissez un workflow avec de nombreux dossiers par semaine, des règles claires et des erreurs peu coûteuses à corriger, comme le tri des tickets de support et la rédaction des réponses. Avancez ensuite par étapes :

• Mesurez le workflow tel qu'il fonctionne aujourd'hui : temps par dossier, part des dossiers repris et stock de dossiers en attente chaque semaine
• Faites tourner l'agent en mode fantôme (shadow mode) sur des cas réels. Il propose, les équipes travaillent comme avant, et vous comparez les deux
• Passez en mode approbation, où une personne approuve chaque action, et notez à quelle fréquence les approbateurs modifient ou refusent
• Laissez l'agent agir seul uniquement sur les types d'actions qui demandent le moins de corrections, et continuez à vérifier un échantillon chaque semaine

Convenez à l'avance des chiffres qui font passer l'agent à l'étape suivante, et de qui en décide. Le guide d'OpenAI se conclut ainsi : « Commencez petit, validez avec de vrais utilisateurs et étendez les capacités au fil du temps. » Le billet d'Anthropic recommande « des tests approfondis dans des environnements en bac à sable », c'est-à-dire une copie de vos systèmes où les erreurs ne coûtent rien.

Que vérifier avant la mise en service de l'agent ?

• Chaque fonction appartient à l'un des trois groupes et a un responsable nommément désigné de votre côté
• Quelqu'un a tenté une action interdite avec le compte de l'agent dans chaque système et a constaté son échec
• Des tickets et des documents contenant des instructions piégées sont passés par l'agent, et rien ne s'est produit en dehors de ce que les groupes autorisent
• Pour n'importe quel client, le journal montre ce que l'agent a fait et qui l'a approuvé
• Une nouvelle version du modèle n'est mise en service qu'après une nouvelle exécution des mêmes tests

À qui appartiennent le code, les prompts et les journaux ?

Ce devrait être votre entreprise, et le contrat doit le préciser. Le code n'est qu'une partie de l'agent. Les prompts, la liste des fonctions, les règles d'approbation et les cas de test déterminent son comportement. Désignez-les tous comme livrables, conservés sur un stockage que votre entreprise contrôle.

Les journaux contiennent des données clients : il leur faut donc les mêmes règles d'accès et la même durée de conservation que les enregistrements qu'ils décrivent. Si le modèle tourne chez un fournisseur externe, demandez si ce fournisseur conserve ce que l'agent lui envoie, et pendant combien de temps.

Que demander à une société qui le construirait ?

• Pouvons-nous voir chaque fonction que l'agent appellera, avec le groupe auquel chacune appartient ?
• Où les approbations sont-elles imposées : dans nos systèmes, dans votre code ou seulement dans le prompt ?
• Quel compte l'agent utilise-t-il dans chaque système, et comment avez-vous vérifié qu'il ne peut pas en faire plus ?
• Comment testez-vous la résistance à l'injection de prompt, et que se passe-t-il quand un test réussit ?
• Notre équipe conformité peut-elle lire le journal sans votre aide ?
• Comment annule-t-on chaque action, et en combien de temps pouvons-nous couper l'agent ?
• Que possédons-nous à la fin : code, prompts, définitions de fonctions, cas de test et journaux ?

Où se situe amBrain ?

amBrain utilise des agents dans son propre produit. La ligne qu'elle consacre à ce produit indique : « Notre propre produit, shyash.ai, repose sur des agents IA qui recherchent, rédigent, vérifient et mesurent à partir d'une mémoire commune des faits de l'entreprise. Une personne approuve tout ce qui est publié. »

Le seul projet client avec un modèle de langage qu'amBrain décrit publiquement est le suivant : « Nous avons mené une intégration de LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés de courtiers et de places de marché — opérations sur titres, changements d'instruments et de marges — en enregistrements structurés consommés par le système de trading. »

Cet article n'est pas une étude de cas et ne décrit aucun travail client au-delà de la ligne ci-dessus. Cette ligne ne dit rien des agents ni des approbations, et l'article n'affirme pas qu'amBrain construit des systèmes d'agents pour des clients. Les exemples tirés du support, de l'entrée en relation, des paiements et du reporting sont génériques et ne proviennent pas de travaux d'amBrain.

Les entreprises et organisations citées ici le sont d'après leurs pages publiées. L'article n'affirme aucune relation entre amBrain et l'une d'elles et ne donne ni prix ni délais d'amBrain.

amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Les questions ci-dessus valent pour toute société que vous envisagez.