Vos agents d’IA ont besoin de fiches de poste, pas de meilleures instructions

Demandez à une entreprise ce qu’une nouvelle analyste des comptes fournisseurs est autorisée à faire, et vous obtiendrez une réponse précise. Elle travaille dans ces systèmes, avec ces fournisseurs, et toute dépense dépassant un plafond d’approbation — disons 10 000 $ — doit être soumise à son responsable pour signature. Elle est en période d’essai pendant ses premiers mois. Tout cela figure généralement dans un tableau de délégation des pouvoirs que l’audit interne vérifie chaque année.

Demandez à la même entreprise ce que son nouvel agent de traitement des factures est autorisé à faire, et vous recevrez souvent une capture d’écran d’une instruction.

Cet écart me préoccupe davantage que n’importe quel résultat de test comparatif de modèles. Nous recrutons une main-d’œuvre numérique sans le système de gestion que nous avons mis un siècle à bâtir pour les personnes : personne ne consigne ses pouvoirs, personne ne met son jugement à l’épreuve avant sa prise de fonction et personne ne s’est exercé à le désactiver.

Pourquoi une instruction ne suffit pas

Une instruction décrit l’intention. Elle indique à quoi sert l’agent. Elle précise rarement ce que l’agent ne doit jamais faire, où se situent ses limites, ou quand il doit s’arrêter et laisser une personne prendre la décision.

Et même lorsqu’une instruction précise ces éléments, rien ne les fait respecter. Dire à un agent de ne pas accorder de remboursements supérieurs à 500 $ revient à formuler une demande à un système probabiliste. Aucun auditeur n’accepterait comme mesure de contrôle applicable à une personne qu’« on a gentiment demandé à l’analyste » de s’y conformer ; je ne vois donc pas pourquoi nous l’acceptons pour un logiciel.

Les spécialistes de la sécurité ont déjà un nom pour ce résultat. Le Top 10 de l’OWASP pour les applications LLM répertorie l’autonomie excessive parmi les principaux risques, qui découle de fonctionnalités trop étendues, de permissions excessives ou d’une autonomie trop grande. En clair, c’est comme confier à un employé les clés de tout dès son premier jour. Les recommandations de l’OWASP ressemblent à la liste de contrôle d’un bon responsable : ne donner à l’agent que les outils dont il a besoin, limiter ses permissions, exiger l’approbation d’une personne pour les actions à fort impact et appliquer les autorisations dans les systèmes en aval, au lieu de faire confiance au modèle pour contrôler lui-même ses actions.

Je soulignerais ce dernier point. Les droits accordés doivent être définis là où l’action a lieu : dans l’identité de service propre à l’agent, ses permissions liées aux outils et le plafond de dépenses imposé au niveau de la passerelle API. Faire fonctionner des agents avec un compte de service partagé, c’est comme faire porter le même badge à cinq personnes. En cas de problème, le journal d’audit indique que le compte de service en est responsable, et il ne vous reste qu’à deviner quel agent a agi.

Les annulations révèlent un problème de gestion

Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici à la fin de 2027, en raison de la hausse des coûts, de la valeur commerciale incertaine et de contrôles des risques insuffisants.

L’engouement et l’immaturité des produits expliquent en partie la situation. Mais essayez de lire les trois causes comme le ferait un directeur des opérations (COO). Les coûts s’envolent quand personne n’a fixé de budget. La valeur reste incertaine quand personne n’a consigné les résultats attendus du travail. Les contrôles des risques sont insuffisants quand il n’y a ni limites, ni examens, ni responsable clairement désigné. Gartner ne présente pas les choses ainsi ; c’est mon interprétation. C’est ce qui arrive aussi quand on laisse des personnes agir sans système de gestion, et le problème est bien antérieur à l’IA.

Les cadres de référence mettent en évidence la même lacune. Le Cadre de gestion des risques liés à l’IA du NIST considère « Gouverner » comme la fonction qui traverse « Cartographier », « Mesurer » et « Gérer », et son Profil de l’IA générative étend cette approche aux systèmes génératifs. Mais les cadres de référence ne peuvent pas vous fournir les mécanismes opérationnels — les autorisations, les tests et les examens — dont une équipe se sert concrètement un mardi. Sans eux, la gouvernance reste un PDF sur un lecteur partagé.

Appliquer aux agents les outils de gestion traditionnels

Commencez par la fiche de poste, qui devient, pour un agent, une délégation de pouvoirs. Avant qu’un agent intervienne dans un système en production, quelqu’un devrait pouvoir rédiger une page précisant ce qu’il peut faire, ce qu’il ne doit jamais faire, ses seuils d’approbation, la personne qui en est responsable et celle qui peut élargir ses limites. Dans la matrice RACI, la personne tenue responsable est un être humain. Si vous ne pouvez pas rédiger cette page, le poste n’est pas prêt à être pourvu — et vous diriez la même chose d’un poste destiné à une personne.

Deux règles traditionnelles de délégation des pouvoirs s’appliquent directement. On ne peut pas déléguer des pouvoirs dont on ne dispose pas : un sous-agent ne devrait donc jamais recevoir des pouvoirs plus étendus que l’agent qui l’a créé. La séparation des tâches s’applique également. Qu’un agent puisse à la fois créer un fournisseur et le payer constituerait la même constatation d’audit que s’il s’agissait d’une personne.

Vient ensuite le test de recrutement. Nous évaluons généralement les agents comme nous évaluerions une calculatrice, en vérifiant si la réponse est juste. Pour évaluer un travailleur, il faudrait vérifier s’il a respecté les limites de ses pouvoirs, demandé une approbation lorsqu’il le devait, transmis le problème à un niveau supérieur lorsque la situation dépassait le cadre de sa mission et s’est arrêté quand il le fallait.

Dans le cadre de mes propres recherches, je construis un test de référence composé de 50 scénarios portant précisément sur ces défaillances : dépasser les seuils d’approbation, agir à partir de données obsolètes, suivre des instructions injectées qui élargissent le champ d’action, conserver des accès après un changement de rôle. Jusqu’à présent, je ne l’ai exécuté que sur des agents scriptés, afin de vérifier que les scénarios se comportent comme prévu ; je n’ai donc aucun résultat de modèle à présenter. Ce qui m’a surpris en les rédigeant, c’est à quel point ces scénarios sont ordinaires. Ce sont les façons habituelles dont des employés s’écartent de leur mission, transposées au logiciel. La plupart des classements publics évaluent encore l’accomplissement des tâches, et très peu vérifient si l’agent a respecté les pouvoirs qui lui ont été accordés.

La période d’essai et la promotion se transposent assez directement. Avec les personnes, on commence par leur confier un périmètre restreint, qu’on élargit à mesure qu’elles font preuve de discernement. Les agents peuvent gagner la même latitude en démontrant qu’ils respectent les limites, savent faire remonter les problèmes et s’arrêtent correctement. Ce bilan peut tout aussi bien justifier une réduction des autorisations accordées.

Les agents présentent une difficulté supplémentaire. Lorsqu’un fournisseur met à niveau le modèle sous-jacent, c’est, dans les faits, comme si une nouvelle recrue portait l’ancien badge. Je traiterais cela comme un changement nécessitant une nouvelle évaluation avant de reconduire les autorisations.

Il faut répéter la procédure de révocation avant d’en avoir besoin. Si vous deviez arrêter cet agent et lui retirer ses accès au cours de la prochaine heure, le pourriez-vous ? Qui a le pouvoir de prendre cette décision à 2 heures du matin ? Quelles seraient les conséquences en aval, et quels engagements en cours quelqu’un devrait-il défaire manuellement ? Si personne n’a répété cette procédure, vous espérez simplement que le dispositif d’arrêt d’urgence fonctionnera.

Vous pouvez tenir un employé pour responsable. Vous ne pouvez tenir un agent responsable de rien, et c’est là que la comparaison cesse de fonctionner. C’est aussi pourquoi les autorisations doivent être appliquées par les systèmes et pourquoi chaque agent doit avoir une personne nommément désignée pour en assumer la responsabilité. Dans tous les cas, quelqu’un devra rendre des comptes. Il s’agit généralement de la personne qui a donné son approbation, qu’elle ait su ou non qu’elle le faisait.

Ce que demandera l’examen de l’incident

Certains de ces agents finiront par faire quelque chose qu’ils ne devraient pas faire. Le moment venu, l’examen post-incident posera les questions qu’il pose déjà au sujet des personnes. Qu’avait-il le droit de faire, et où cela est-il consigné ? Qui a approuvé l’élargissement de ses accès ? Combien de temps a-t-il fallu pour l’arrêter ? Qui en était responsable ?

Si les réponses honnêtes sont « une consigne », « personne ne s’en souvient », « des heures » et « ce n’est pas clair », un meilleur modèle ne vous aurait pas sauvé.

Où se situe finalement l’avantage

Les modèles deviennent des ressources louées, remplacées et mises à niveau au gré du calendrier des fournisseurs. Deux entreprises peuvent utiliser le même modèle et se retrouver dans des situations très différentes. L’une dispose d’agents dotés de budgets, de limites et de responsables, ainsi que d’une piste d’audit pour chaque action ayant des conséquences, tandis que l’autre a un projet pilote coûteux qui finira dans les statistiques d’annulation de quelqu’un.

La différence tient au système de gestion qui entoure le modèle. Celui-ci se construit lentement, surtout grâce à des personnes qui ont déjà dirigé des organisations.

Si votre agent le plus récent dépassait son autorité demain, quelqu’un dans votre entreprise s’en apercevrait-il ? Et pourriez-vous montrer par écrit à un auditeur où se situait la limite ?