6.7 Agents d’IA et systèmes agentiques

Vue d’ensemble et motivation

Un agent d’IA est un grand modèle de langage (LLM) enveloppé dans une boucle : on lui donne un objectif, il peut appeler des outils, il garde une certaine mémoire de ce qu’il a fait, et il décide sa propre prochaine étape jusqu’à ce que l’objectif soit atteint ou qu’il abandonne. Cette boucle est toute la différence entre un agent et les simples appels prompt-réponse du chapitre 6.3. Un seul appel répond à une question. Un agent lit son courriel, cherche dans une base de données, dépose un ticket, vérifie le résultat, et réessaie. Le modèle ne produit plus seulement du texte ; il choisit des actions dans vos systèmes.

Ce changement transforme le problème d’ingénierie. Quand un modèle écrit seulement des mots, une mauvaise sortie est une mauvaise phrase. Quand un modèle pilote des outils, une mauvaise sortie peut envoyer un mauvais message, supprimer un enregistrement, ou déplacer de l’argent. Donc un agent intelligent est mieux compris comme un planificateur non fiable assis à l’intérieur d’un système fiable, et la plupart de votre travail va dans borner ce que ce planificateur est autorisé à faire. Ce chapitre s’appuie directement sur les fondements LLM du chapitre 6.3, les préoccupations de confiance et responsabilité du chapitre 6.5, et les pratiques de plateforme du chapitre 6.6.

Pour les grandes équipes les enjeux sont autant organisationnels que techniques. Les entreprises veulent des agents câblés dans de vrais systèmes internes (billetterie, finance, enregistrements client), ce qui signifie que les agents héritent de vrais contrôles d’accès et de vraies obligations de gestion de changement. L’administration publique ajoute la responsabilité publique : une action autonome qui affecte un citoyen doit être explicable, surveillable, et auditable après coup. Le motif est puissant. Déployé sans discipline, c’est une façon rapide d’automatiser des erreurs.

Principes clés

Un agent est un modèle plus une boucle, des outils, de la mémoire, et un objectif. Le risque vit dans la boucle, pas la prose.
Bornez l’autonomie à la tâche. Donnez la plus petite quantité de liberté qui accomplit le travail.
Préférez un flux de travail fixe quand les étapes sont connues. Recourez à l’autonomie ouverte seulement quand elles ne le sont pas.
Traitez chaque outil comme une surface d’attaque et accordez-lui le moindre privilège avec lequel il peut travailler.
Placez un humain dans la boucle pour les actions conséquentes ou irréversibles, et rendez le renversement bon marché.
Évaluez sur le succès de tâche, pas sur comment la transcription se lit.
Tracez chaque exécution. Une action que vous ne pouvez pas reconstruire est une action que vous ne pouvez pas gouverner.
La conception la plus simple qui fonctionne est habituellement la bonne. Souvent ce n’est pas du tout un agent.

Recommandations

Commencer avec un flux de travail, ajouter de l’autonomie seulement où vous devez

L’erreur la plus courante est de recourir à un agent autonome quand un pipeline fixe suffirait. Si vous connaissez déjà les étapes (extraire des champs, les valider, chercher un enregistrement, rédiger une réponse), écrivez cela comme un flux de travail orchestré avec le modèle remplissant des créneaux spécifiques. L’autonomie gagne sa place quand le chemin ne peut véritablement pas être prédéterminé, par exemple la recherche ouverte ou le triage à travers de nombreux outils possibles. Bornez l’autonomie à la tâche : plafonnez le nombre d’étapes, restreignez l’ensemble d’outils à ce dont cet objectif a besoin, et fixez une condition d’arrêt claire. Une bonne règle est de donner au modèle exactement autant de liberté que le problème l’exige et pas un degré de plus.

Faire de l’usage d’outil la capacité centrale, et le rendre sûr

L’usage d’outil (aussi appelé appel de fonction) est ce qui transforme un modèle en agent. Définissez chaque outil avec un schéma précis, validez chaque argument que le modèle fournit, et appliquez le principe du moindre privilège : un agent de rapport en lecture seule obtient des identifiants en lecture seule, jamais d’accès en écriture qu’il pourrait mal utiliser. Exécutez les outils dans un bac à sable pour qu’un mauvais appel ne puisse pas atteindre au-delà de son rayon d’explosion. Préférez de nombreux outils étroits et à but unique à quelques larges, parce qu’un outil étroit est plus facile à raisonner, permissionner, et auditer. C’est la même retenue que le chapitre 6.3 exhorte pour l’usage d’outil LLM, rendue centrale.

Utiliser des motifs de raisonnement et de planification explicites

Les agents fonctionnent mieux quand leur pensée est structurée. Dans un motif de raisonnement et action (popularisé par la recherche ReAct), le modèle alterne entre raisonner sur la situation et prendre une action, puis observe le résultat avant de raisonner à nouveau. Pour les objectifs plus difficiles, faites planifier le modèle d’abord (décomposer en sous-tâches) puis exécuter, pour que vous puissiez inspecter et même approuver le plan avant qu’aucun outil ne s’exécute. Gardez ces boucles observables et interruptibles. Un plan que vous pouvez lire est un plan que vous pouvez arrêter.

Garder des humains dans la boucle pour les actions conséquentes

Décidez, par outil et par action, si le modèle peut agir seul ou doit demander d’abord. Les actions réversibles et à faible enjeu (chercher, rédiger) peuvent s’exécuter sans surveillance. Les conséquentes ou irréversibles (envoyer des communications externes, déplacer de l’argent, changer des données de production, décider du cas d’un citoyen) ont besoin d’une porte humain dans la boucle avec une vraie autorité de dire non. Concevez pour la réversibilité partout où vous le pouvez : préférez mettre en scène un changement plutôt que de le commettre, et faites de l’annulation une fonctionnalité de première classe pour qu’une action erronée coûte des minutes, pas un incident.

Traiter le modèle de sécurité comme adversarial

Les agents élargissent la surface d’attaque décrite au chapitre 4.2. La menace principale est l’injection de prompt : des instructions malveillantes cachées dans une page web, document, ou courriel que l’agent lit et obéit. Étroitement liée est le problème du député confus, où un attaquant piège un agent privilégié à mal utiliser son propre accès légitime, par exemple exfiltrer des données à travers un outil que l’agent est autorisé à appeler. Supposez que tout contenu que l’agent ingère peut être hostile. Séparez les instructions fiables des données non fiables, contraignez les outils pour qu’un agent détourné ne puisse pas atteindre des systèmes sensibles, et ne laissez jamais la sortie brute du modèle déclencher une action irréversible sans validation.

Évaluer sur le succès de tâche et tester en régression le non-déterminisme

Jugez les agents par s’ils accomplissent la tâche, pas par si la transcription sonne intelligente. Construisez un ensemble d’évaluation d’objectifs représentatifs avec des critères de succès vérifiables (le ticket a-t-il reçu la bonne priorité, le remboursement correspondait-il à la politique) et exécutez-le à chaque changement de prompt, modèle, ou outil. Parce que les agents sont non déterministes, un seul passage prouve peu : exécutez chaque cas plusieurs fois et suivez un taux de succès, pas un passage ou échec. Cela étend la discipline d’évaluation hors ligne et en ligne des chapitres 6.3 et 6.2 (ingénierie d’apprentissage automatique et MLOps) aux systèmes dont la sortie est une séquence d’actions.

Instrumenter les exécutions pour l’observabilité, le coût, et la gestion d’échec

Vous ne pouvez pas gouverner ce que vous ne pouvez pas voir. Tracez chaque exécution d’agent de bout en bout (chapitre 6.6) : l’objectif, chaque étape de raisonnement, chaque appel d’outil avec ses arguments et résultat, les jetons dépensés, et le résultat final. Cette traçabilité est votre débogueur, votre piste d’audit, et votre compteur de coût à la fois. Fixez des budgets durs sur les étapes, le temps, et la dépense, parce qu’un agent qui boucle peut brûler de la latence et de l’argent rapidement. Gérez l’échec explicitement : retentez les erreurs d’outil transitoires avec recul, mais détectez les boucles où le modèle répète une action échouante, et échouez en sécurité plutôt que de s’agiter.

Compromis : avantages et inconvénients

Choix	Avantages	Inconvénients	Le mieux quand
Flux de travail fixe (le modèle remplit des créneaux)	Prévisible, bon marché, facile à tester et auditer	Rigide ; se casse sur des chemins imprévus	Les étapes sont connues à l’avance
Agent unique autonome	Flexible ; gère des objectifs ouverts	Plus difficile à contrôler, évaluer, et borner	Le chemin ne peut pas être prédéterminé
Orchestration multi-agent	Parallélisme ; rôles spécialisés	Coût de coordination, erreurs composées, dépense plus élevée	Une tâche se décompose véritablement en parties indépendantes
Action non surveillée	Rapide, faible friction	Les erreurs s’exécutent sans vérification	Les actions sont réversibles et à faible enjeu
Porte humain dans la boucle	Sécurité, responsabilité, réversibilité	Plus lent ; exige une capacité de relecteur	Les actions sont conséquentes ou irréversibles

La tension centrale est l’autonomie contre le contrôle. Plus d’autonomie gère plus de situations mais exige plus de garde-fous, plus d’évaluation, et plus d’argent, et elle échoue de façons plus difficiles à prédire. Les conceptions multi-agent tentent les équipes avec de l’élégance, pourtant chaque agent supplémentaire ajoute une surcharge de coordination et un autre endroit pour qu’une petite erreur se compose en un mauvais résultat. Résolvez la tension en commençant avec la moindre autonomie qui résout le problème et en ajoutant de la liberté seulement quand une tâche concrète vous y force, toujours associée à un garde-fou correspondant.

Questions à discuter avec votre équipe

Cette fonctionnalité a-t-elle réellement besoin d’un agent, ou un flux de travail fixe serait-il plus sûr et moins cher ? L’autonomie est séduisante, mais la plupart des travaux ont des étapes connaissables qu’un pipeline orchestré gère avec bien moins de risque. Pour une grande équipe, choisir par défaut des agents signifie que chaque groupe prend en charge des fardeaux d’évaluation, de traçabilité, et de sécurité qu’une conception plus simple éviterait. Apportez la tâche spécifique et demandez si ses étapes peuvent être prédéterminées ; si elles le peuvent, un agent est probablement une sur-ingénierie. Réservez l’autonomie ouverte aux objectifs où le chemin varie véritablement par cas. La réponse devrait pousser la plupart des fonctionnalités vers un flux de travail et laisser un petit ensemble délibéré comme vrais agents.
Pour chaque outil que notre agent peut appeler, quelle est la pire chose qu’un agent détourné pourrait en faire, et qu’est-ce qui l’arrête ? L’injection de prompt et les attaques de député confus retournent le propre accès légitime de l’agent contre vous, donc la bonne lentille est adversariale (chapitre 4.2). Inventoriez chaque outil, sa portée de privilège, et si une instruction malveillante contrebandée à travers le contenu ingéré pourrait l’atteindre. Pour les entreprises câblant des agents dans des systèmes internes, c’est là que le moindre privilège, le bac à sable, et les portes humaines sur les actions irréversibles deviennent réels. Apportez la liste des outils et les identifiants que chacun détient. Si une action conséquente quelconque est atteignable sans validation ou vérification humaine, c’est la première chose à corriger.
Comment saurions-nous que le taux de succès d’un agent a chuté, étant donné que chaque exécution paraît plausible ? Les agents sont non déterministes, donc une transcription qui se lit bien peut quand même avoir pris la mauvaise action, et une exécution verte ne prouve rien. Demandez si vous avez un ensemble d’évaluation d’objectifs avec des résultats vérifiables, exécuté de nombreuses fois par cas pour produire un taux de succès plutôt qu’un seul passage. Pour les déploiements à haut enjeu ou publics, discutez comment les traces d’exécution vous permettent de reconstruire exactement ce qui s’est passé quand quelque chose tourne mal (chapitres 6.5 et 6.6). Si votre seul signal est les plaintes utilisateur, vous êtes déjà trop tard. La réponse devrait financer un harnais d’évaluation avant l’échelle, pas après un incident.
Lesquelles des actions de cet agent sont véritablement irréversibles, qui détient l’autorité de les approuver, et avons-nous la capacité de relecteur pour doter cette porte ? La tentation est de laisser le modèle agir sans surveillance partout, mais une porte humaine n’est réelle que si une personne nommée avec l’autorité de dire non est disponible quand l’agent demande. Pour une grande équipe, une file d’approbation que personne ne possède devient discrètement un tampon en caoutchouc, et la sécurité que vous avez conçue s’évapore sous le volume. Apportez la liste complète des actions que l’agent peut prendre, marquez chacune réversible ou irréversible, et estimez le volume quotidien de cas à faible confiance qui atterriraient sur un relecteur. Pesez la friction et le coût de dotation d’une porte contre le rayon d’explosion d’une erreur non surveillée, et préférez reconcevoir une action irréversible en une mise en scène annulable plutôt que d’ajouter un autre relecteur. Dans les contextes d’entreprise et gouvernementaux, liez chaque action conséquente à un fonctionnaire responsable et un enregistrement de gestion de changement, parce qu’une action autonome affectant un citoyen ou un client qu’aucun humain n’a approuvée est exactement l’échec qu’un audit trouvera.
Recourons-nous à une conception multi-agent parce que la tâche se décompose véritablement, ou parce que ça paraît élégant ? Diviser le travail à travers des agents spécialisés est séduisant, pourtant chaque agent supplémentaire ajoute une surcharge de coordination et un autre endroit où une petite erreur se compose en un mauvais résultat. Pour une grande organisation le coût n’est pas seulement la dépense et la latence : un système multi-agent est bien plus difficile à tracer, évaluer, et raisonner quand il échoue, donc le fardeau de gouvernance se multiplie avec chaque rôle que vous ajoutez. Apportez la tâche et montrez, concrètement, quelles parties s’exécutent indépendamment et en parallèle, puis comparez le taux de succès et coût mesurés d’une version multi-agent contre un agent unique sur le même ensemble d’évaluation. Si l’agent unique gagne ou égalise, la conception élégante est une sur-ingénierie. Pour les déploiements régulés ou publics, rappelez-vous que chaque agent dans la chaîne est un composant de plus qu’un organisme de surveillance doit pouvoir inspecter, donc de la structure ajoutée que vous ne pouvez pas justifier est une responsabilité ajoutée.
Quels sont les budgets durs sur les étapes, le temps, et la dépense d’un agent, et comment un agent qui boucle serait-il attrapé avant qu’il ne fasse monter le coût ou la latence ? Un agent qui répète une action échouante peut brûler de l’argent et du temps sans avertissement, donc l’autonomie non bornée est un risque financier autant qu’un risque de sécurité. Pour une grande équipe exploitant de nombreux agents, une seule boucle mal comportée peut faire piquer une facture cloud ou épuiser une limite de débit qui affame chaque autre charge de travail, ce qui fait des plafonds par exécution une préoccupation opérationnelle partagée plutôt que le problème d’une équipe. Apportez les budgets actuels d’étape, temps, et jeton pour chaque agent, l’alerte qui se déclenche quand une exécution les dépasse, et la détection de boucle qui échoue en sécurité plutôt que de s’agiter. Pesez des budgets serrés, qui peuvent couper une tâche légitimement difficile, contre des lâches qui laissent le coût s’emballer. Dans les contextes d’entreprise et gouvernementaux où la dépense doit être prévue et justifiée, un agent dont le coût est non borné est une ligne budgétaire que vous ne pouvez pas défendre en révision budgétaire ou audit.

Regard sectoriel

Jeune pousse. Livrez un seul agent étroit qui touche votre valeur centrale, sur un modèle hébergé, avec le plus petit ensemble d’outils qui accomplit le travail et un plafond dur sur les étapes et la dépense. Résistez à la démonstration multi-agent : votre attention d’ingénierie rare est mieux dépensée à borner l’autonomie d’un seul agent et tracer ses exécutions plutôt qu’à coordonner des rôles que vous ne pouvez pas maintenir. Gardez chaque action conséquente derrière une seule porte « brouillon, jamais envoyer » pour qu’une erreur coûte un clic à annuler, pas un incident.

Petite entreprise. Vous n’avez personne pour exécuter un harnais d’évaluation ou un bac à sable, donc préférez les agents intégrés dans des outils que vous faites déjà confiance, et n’activez que l’autonomie que vous pouvez superviser à l’œil. Traitez tout agent qui peut envoyer, payer, ou supprimer en votre nom comme quelque chose à garder désactivé jusqu’à ce qu’une personne confirme chaque action, parce qu’un mauvais message automatisé à un client vous coûte la relation. Favorisez les fournisseurs qui vous montrent ce que l’agent a fait et vous laissent désactiver l’automatisation.

Grande entreprise. Le problème est de gouverner les agents à travers de nombreuses équipes : des motifs partagés pour borner l’autonomie, des identifiants d’outil à moindre privilège, le bac à sable, des portes humain dans la boucle, et une traçabilité de bout en bout pour qu’aucun groupe ne réinvente les garde-fous. Câblez les agents dans les systèmes internes sous les mêmes contrôles d’accès qu’un humain tiendrait, conditionnez les actions irréversibles derrière des approbateurs nommés et une gestion de changement, et gérez le portefeuille avec des métriques de taux de succès, des budgets par exécution, et des tests d’injection adversariaux. Standardisez la couche de traçabilité et d’évaluation pour que le comportement de tout agent puisse être reconstruit et audité.

Gouvernement. L’approvisionnement, la transparence, et la responsabilité publique bornent chaque choix. Gardez les agents à rassembler des faits et rédiger, et réservez chaque décision qui affecte un citoyen à un humain responsable, parce que la responsabilité d’une décision de secteur public ne peut pas être déléguée à un modèle. Journalisez chaque exécution pour qu’un organisme de surveillance puisse voir quelles sources ont été consultées et ce qui a été fait, exigez que les fournisseurs divulguent les outils et limitations de l’agent, et prouvez à travers un ensemble d’évaluation adversarial que l’agent refuse d’agir au-delà de son mandat borné.

Exemples

Jeune pousse. Une jeune pousse d’analytique à cinq personnes construit un agent de triage de support. Il lit un ticket entrant, cherche dans la documentation, et soit rédige une réponse soit achemine le ticket vers un humain, et c’est tout l’ensemble d’outils. Les identifiants sont lecture seule plus une seule action « créer brouillon » qui n’envoie jamais sans qu’une personne clique sur envoyer. Chaque exécution est tracée pour que les fondateurs puissent voir pourquoi un ticket a été acheminé où il l’a été, et un ensemble d’évaluation nocturne de cinquante vrais tickets exécute l’agent cinq fois chacun pour suivre un taux de précision d’acheminement. Quand la démonstration multi-agent astucieuse d’un concurrent les tente, ils restent agent unique parce que leur tâche ne se décompose pas.

Grande entreprise. Une banque construit un agent pour aider le personnel des opérations à réconcilier les paiements échoués. Il s’intègre avec les systèmes internes sous les mêmes contrôles d’accès qu’un employé humain a, accordés à travers des identifiants de service à moindre privilège cadrés uniquement à la réconciliation. L’agent peut investiguer librement (lire les grands livres, chercher l’historique de transaction) mais toute action qui déplace de l’argent ou édite un enregistrement est mise en scène et exige un approbateur humain nommé, satisfaisant la gestion de changement. Les documents ingérés sont traités comme non fiables pour émousser l’injection de prompt, les outils s’exécutent dans un bac à sable, et chaque exécution est tracée de bout en bout pour l’audit. Un ensemble d’évaluation hors ligne conditionne chaque changement de modèle ou prompt, et des budgets par exécution plafonnent les étapes et la dépense pour qu’un agent en boucle ne puisse pas faire monter le coût ou la latence.

Gouvernement. Une agence de prestations pilote un agent pour aider les agents de dossier à assembler les faits pour une réclamation : tirer des enregistrements, vérifier les règles d’éligibilité, et rédiger un résumé. L’agence trace une ligne dure : l’agent rassemble et rédige, mais un agent de dossier humain prend et possède chaque décision qui affecte un citoyen, parce que la responsabilité des décisions de secteur public ne peut pas être déléguée à un modèle (chapitre 6.5). Chaque exécution est entièrement journalisée, montrant quelles sources ont été consultées et ce qui a été rédigé, pour qu’un organisme de surveillance puisse auditer tout cas. L’autonomie est délibérément bornée à lire-et-rédiger, les outils sont à moindre privilège et dans un bac à sable, et un ensemble d’évaluation adversarial confirme que l’agent refuse d’agir au-delà du rassemblement de faits.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Les agents livrent un retour en automatisant du travail multi-étape qui avait autrefois besoin d’une personne pour cliquer entre systèmes : triage, réconciliation, recherche, et opérations routinières. La valeur se manifeste comme du travail terminé sans un humain à chaque étape, des temps de cycle plus rapides, et du personnel libéré pour des tâches riches en jugement. Parce que les agents construisent sur des LLM et outils existants, le temps jusqu’à un prototype fonctionnel est court, ce qui est exactement pourquoi les équipes sur-construisent.

Le coût total de possession est là où les agents diffèrent des simples fonctionnalités LLM. Par-dessus le coût d’inférence vous payez pour les intégrations d’outil, la plomberie de bac à sable et de permission, le harnais d’évaluation, la pile de traçabilité et d’observabilité (chapitre 6.6), et les relecteurs humains qui dotent les portes d’approbation. Un agent en boucle ou mal borné ajoute un coût variable qui peut piquer sans avertissement, donc les budgets sur les étapes et la dépense font partie de la conception, pas une pensée après coup. Le coût de ne pas adopter est des opérations plus lentes et un labeur manuel que vos concurrents automatisent. Le coût d’adopter avec négligence est une action autonome qui envoie le mauvais message, fuit des données, ou prend une décision non responsable. Faites valoir cela auprès de la direction en associant une cible d’automatisation concrète à un plan concret pour les garde-fous, l’évaluation, et la surveillance humaine, et en étant honnête que les garde-fous sont la majeure partie du coût.

Anti-patterns et pièges

Agent quand un flux de travail suffirait. Prendre en charge le risque complet de l’autonomie pour une tâche dont les étapes étaient connaissables.
Outils et identifiants trop larges. Un seul outil « faire n’importe quoi » au lieu d’outils étroits et à moindre privilège.
Aveuglement à l’injection de prompt. Alimenter du contenu non fiable à un agent qui détient de vrais privilèges.
Aucune porte humaine sur les actions irréversibles. Laisser le modèle envoyer, payer, ou supprimer sans vérification.
Théâtre multi-agent. Diviser une tâche simple à travers des agents, payant un coût de coordination pour aucun gain.
Évaluation basée sur l’impression. Juger par comment la transcription se lit au lieu du taux de succès de tâche.
Boucles non bornées. Aucun plafond sur les étapes, le temps, ou la dépense, pour qu’un agent bloqué brûle de l’argent et de la latence.
Exécutions non tracées. Aucun enregistrement de ce que l’agent a fait, vous laissant incapable de déboguer, auditer, ou rendre compte.

Modèle de maturité

Niveau 1 (Initier) : Les agents sont prototypés au coup par coup avec un accès d’outil large et aucune borne. Le succès est jugé par les démonstrations, réactivement, après que quelque chose se casse. Il n’y a pas d’ensemble d’évaluation, pas de traçabilité, et pas de porte humaine sur les actions conséquentes.
Niveau 2 (Développer) : Certains agents ont des boucles bornées et des outils à moindre privilège, et une traçabilité de base existe, mais la pratique varie d’équipe à équipe. Un ensemble d’évaluation manuel attrape les régressions grossières dans quelques projets tandis que d’autres n’en ont aucun. L’approbation humaine garde les actions irréversibles les plus évidentes, pourtant la couverture est inégale et non documentée.
Niveau 3 (Standardiser) : Des motifs partagés gouvernent l’autonomie, les permissions d’outil, le bac à sable, et les portes humain dans la boucle, documentés et imposés à travers chaque équipe. Chaque action conséquente est conditionnée ou validée, les agents sont tracés de bout en bout, et un ensemble d’évaluation automatisé avec notation de taux de succès s’exécute à chaque changement. L’injection de prompt est traitée comme une menace permanente avec une réponse définie.
Niveau 4 (Gérer) : Le portefeuille d’agent est mesuré et contrôlé contre des références. Le taux de succès par tâche, le taux de passage de défense d’injection de prompt, le coût et le compte d’étape par exécution, la latence d’approbation humaine, et les incidents de boucle ou échec sont suivis comme métriques ; les seuils de retour en arrière et de mort sont imposés sur cette preuve plutôt que sur les plaintes. Les budgets par exécution sur les étapes, le temps, et la dépense sont surveillés, et une régression dans toute métrique déclenche une action avant l’échelle, pas après un incident.
Niveau 5 (Orchestrer) : L’autonomie est assortie au risque de tâche par politique et ajustée continuellement à mesure que les résultats arrivent. L’évaluation hors ligne et en ligne continue lie le comportement d’agent aux résultats d’affaires, et l’organisation retire, recadre, ou repermissionne routinièrement les agents à mesure que le paysage de risque change. La traçabilité, les budgets de coût, et les pistes d’audit sont uniformes à travers le portefeuille ; les défenses d’injection et de député confus sont testées adversairement ; la responsabilité pour les actions autonomes est claire et auditable.

Pistes de réflexion

Lesquelles de vos fonctionnalités LLM actuelles sont discrètement devenues des agents, et l’autonomie de chacune a-t-elle été bornée délibérément ?
Pour chaque outil d’agent, quelle est la façon la moins chère qu’un attaquant pourrait en abuser à travers du contenu injecté, et qu’est-ce qui l’arrête ?
Où avez-vous choisi des conceptions multi-agent, et pouvez-vous montrer que le coût de coordination a payé contre un agent unique ?
Quelles actions d’agent sont véritablement irréversibles, et chacune pourrait-elle être reconçue pour être réversible ou mise en scène ?
Si un agent prenait une action dangereuse demain, pourriez-vous reconstruire exactement ce qu’il a fait et qui était responsable ?

Points clés à retenir

Un agent est un LLM dans une boucle avec des outils, de la mémoire, et un objectif. Le risque vit dans la boucle et les outils, pas le texte.
Préférez un flux de travail fixe quand les étapes sont connues ; réservez l’autonomie aux objectifs véritablement ouverts et bornez-la étroitement.
L’usage d’outil est la capacité centrale. Donnez à chaque outil le moindre privilège, un schéma validé, et un bac à sable.
Conditionnez les actions conséquentes et irréversibles derrière un humain avec une vraie autorité, et concevez pour un renversement bon marché.
Traitez les agents comme adversariaux : défendez contre l’injection de prompt et l’abus de député confus (chapitre 4.2).
Évaluez sur le taux de succès de tâche à travers de nombreuses exécutions, et tracez chaque exécution pour le débogage, le contrôle de coût, et l’audit (chapitres 6.5 et 6.6).
Souvent la bonne réponse est de ne pas construire d’agent du tout.

Références et lectures complémentaires

Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models.
Timo Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools.
Anthropic, Building Effective Agents (directive d’ingénierie sur les flux de travail contre les agents).
OWASP Foundation, OWASP Top 10 for Large Language Model Applications (incluant l’injection de prompt et l’agentivité excessive).
Simon Willison, écrits sur l’injection de prompt et le « trifecta létal » pour les agents d’IA.
Norman Hardy, The Confused Deputy (l’énoncé classique du problème du député confus).
Chip Huyen, AI Engineering: Building Applications with Foundation Models.
Stuart Russell et Peter Norvig, Artificial Intelligence: A Modern Approach (agents intelligents et action rationnelle).