Agents IA : de combien d'autonomie une tâche a-t-elle réellement besoin ?

Le 18 septembre 2026, à Colgate University, Barack Obama a consacré un long développement aux risques de l'IA. Un passage concerne directement les agents. Les objectifs que l'on met en avant pour justifier ces systèmes — accélérer la recherche contre le cancer, trouver de meilleures sources d'énergie — n'exigent pas, selon lui, de disposer d'IA circulant librement sur Internet.

Il rattache ce constat à ce qu'il appelle un second problème d'alignement. Le premier, le plus commenté, tient à l'écart entre ce qu'un système fait effectivement et ce qu'on attendait de lui : une consigne imprécise suffit à produire des actions que personne n'avait envisagées, sans qu'il soit nécessaire de supposer que la machine poursuive son propre objectif. Le second oppose ce dont la société a réellement besoin aux impératifs commerciaux des entreprises qui doivent justifier des capitaux considérables. Il ajoute une observation qui intéresse directement toute organisation utilisatrice : lorsqu'un système agentique est mis à l'épreuve, ce n'est pas en environnement fermé, mais au contact d'Internet et des comptes bancaires.

Le propos dépasse largement le débat technologique. Pour une organisation qui s'apprête à confier une tâche à un agent, il devient même très concret, et la question se pose dans un service de cinq personnes exactement comme à l'échelle d'une société : quelle autonomie sommes-nous prêts à abandonner à l'agent IA ?

On parle beaucoup d'agents IA. De quoi la tâche a-t-elle besoin ?

La conversation se déroule souvent de la même manière. Votre éditeur de logiciel annonce l'arrivée d'un agent dans son produit et explique ce qu'il sait faire : naviguer, consulter vos données, rédiger, envoyer, enchaîner plusieurs étapes sans nouvelle consigne. Vous vous demandez alors si le système est fiable, combien il coûte, comment l'intégrer à vos outils existants.

Ces questions sont légitimes, mais elles interviennent toutes après une décision qui n'a jamais été formulée : celle de confier davantage au système. On discute des capacités de l'agent comme si son utilisation, et surtout le degré d'autonomie à lui accorder, allaient de soi.

De quelle autonomie cette tâche précise a-t-elle besoin pour produire le bénéfice attendu ?

Écartons tout de suite une conclusion trop simple. L'agent IA n'est pas qu'un argument commercial : des équipes médicales explorent sérieusement ces systèmes, et Nature Reviews Cancer leur a consacré une revue en oncologie. Le chemin reste toutefois long. Une autre équipe a examiné 984 publications et n'en a retenu que sept suffisamment solides, dont une seule portant sur de vrais patients. À ce stade, rien ne permet donc d'affirmer que ces systèmes sont indispensables, et rien ne permet non plus de conclure qu'ils sont inutiles.

Un agent n'est pas un chatbot qui travaille plus longtemps

Le mot « agent » est désormais employé partout, alors qu'il recouvre des systèmes très différents. Avant d'évaluer une proposition, il faut donc savoir de quoi l'on parle.

Entre le chatbot classique et l'agent très autonome, plusieurs paliers existent : produire une réponse, rechercher une information, préparer une action, exécuter cette action, puis poursuivre un objectif sur plusieurs étapes avec une intervention humaine réduite. Tous ces niveaux peuvent être commercialisés sous le nom d'« agent IA ».

Chez un même éditeur, un agent IA peut ainsi rédiger un message et un autre l'envoyer. Ce qui les sépare n'est pas nécessairement la qualité du texte produit : c'est une permission supplémentaire. Tant que vous ignorez où se situe une solution sur cette échelle, vous ne savez pas vraiment ce qu'on vous propose, ni ce que vous vous apprêtez à autoriser.

Capacité, organisation, autonomie : trois questions différentes

Lorsqu'on parle d'agents, trois dimensions sont régulièrement mélangées. La capacité répond à la question : que sait faire le modèle ? L'organisation du système demande comment le travail est réparti, entre un agent unique ou plusieurs agents qui collaborent. L'autonomie pose une question distincte : jusqu'où le système peut-il aller sans demander l'avis d'une personne ?

Ces trois curseurs ne progressent pas ensemble. Un modèle très performant peut être utilisé avec très peu d'autonomie, et à l'inverse, un système relativement simple peut recevoir des permissions très larges. Confondre les trois revient à déduire d'une performance technique une autorisation d'agir, ce qui ne se déduit jamais.

Kevin Feng, David McDonald et Amy Zhang, de l'Université de Washington, proposent de mesurer l'autonomie non pas à partir de ce que la machine sait faire, mais à partir du rôle qui reste à la personne. Leur échelle comporte cinq niveaux d'autonomie croissante, chacun nommé par ce rôle. Opérateur : vous dirigez le travail et sollicitez l'agent lorsque vous en avez besoin. Collaborateur : les tâches se répartissent entre vous et lui, chacun avançant de son côté. Consultant : l'agent prend l'initiative et vous orientez son travail par vos retours. Approbateur : vous n'intervenez plus que lorsqu'il bute sur un obstacle ou qu'une action demande votre accord. Observateur : l'agent agit et vous découvrez ce qu'il a fait en consultant l'historique.

C'est là leur argument central, et il est simple : ce niveau n'est pas imposé par la puissance du modèle, il résulte d'un choix. Quelqu'un a décidé, au moment de concevoir l'outil, jusqu'où il irait sans demander l'avis d'une personne.

À quel moment une personne intervient-elle encore ?

Le passage d'un niveau à l'autre est rarement décidé lors d'une réunion formelle. Il se fait par petites étapes : on autorise d'abord l'envoi des accusés de réception parce que l'enjeu paraît faible, puis les réponses aux questions simples parce que l'équipe manque de temps, ensuite les relances puisque le reste fonctionne correctement. Chaque décision prise séparément paraît raisonnable ; mises bout à bout, elles modifient considérablement le degré de délégation accordé au système.

La question n'est alors plus seulement de savoir ce que le produit peut faire, mais quel rôle vous voulez encore conserver — c'est précisément la question autour de laquelle les cinq niveaux ci-dessus sont construits. Et cela conduit à une règle simple : un système capable d'agir seul n'a pas nécessairement besoin d'être autorisé à le faire.

Ajouter des agents n'améliore pas automatiquement le résultat

Une idée revient souvent dans les discours commerciaux : plus le système est élaboré, meilleur sera le résultat. Cette hypothèse vient d'être testée à grande échelle.

La différence tient donc moins à la difficulté de la tâche qu'à sa forme. Les auteurs ajoutent d'ailleurs une réserve importante : le seuil qu'ils identifient constitue une règle empirique de sélection, pas une règle généralisée, et sa transposition d'un domaine à un autre reste limitée.

Un point mérite d'être précisé ici, parce qu'il change ce que l'étude permet de dire. Les chercheurs ont fait varier deux choses : combien d'agents travaillent, et comment ils se répartissent le travail. Ils n'ont pas touché à ce que ces agents avaient le droit de faire — d'un test à l'autre, les mêmes outils leur restaient ouverts, un moteur de recherche, une base de documents ou un terminal selon l'épreuve. L'étude dit donc quelque chose de solide sur la répartition du travail : ajouter des agents n'améliore pas mécaniquement les résultats. En revanche, elle ne dit rien des permissions qu'il faudrait leur accorder, pour une raison simple — elle ne les a jamais fait varier. Les chiffres cités plus haut parlent de la façon dont les agents se partagent une tâche, pas de ce qu'on les autorise à faire.

La leçon reste utile : une tâche difficile ne gagne pas automatiquement à être confiée à plusieurs agents. Ce n'est pas la difficulté d'une tâche qui indique s'il faut plusieurs agents, mais sa forme. Une tâche exigeante, composée de recherches qui ne dépendent pas les unes des autres, peut être découpée et traitée en parallèle. Une tâche beaucoup plus simple, mais dont chaque étape dépend du résultat de la précédente, se dégrade au contraire quand on multiplie les intervenants.

Un dernier point, qui ne relève pas de cette étude. Dans un déploiement réel, faire dialoguer plusieurs agents multiplie les échanges entre eux. Lorsque l'outil est facturé à l'usage, cette coordination se paie, en temps de traitement comme en facture, et chaque échange supplémentaire est une occasion de plus d'introduire une erreur. L'étude citée ne mesure pas cet effet : elle attribuait au contraire le même budget de calcul à toutes les configurations comparées, précisément pour que la comparaison reste propre.

Ce qui change vraiment quand l'IA peut agir

Avec un chatbot classique, une erreur reste généralement une mauvaise réponse affichée sur un écran. Quelqu'un peut la lire, la corriger ou l'ignorer. Lorsque le système agit, la nature de l'erreur change : une réponse incorrecte devient un message envoyé, un dossier modifié, un rendez-vous annulé ou un remboursement accordé.

Prenons une phrase très courante : « l'agent a accès au CRM ». Que signifie réellement cet accès ? Peut-il consulter une fiche client, la modifier, envoyer un message depuis le CRM, accorder un geste commercial ? Ces actions sont très différentes, et pourtant elles se regroupent toutes derrière le même mot.

Avoir accès à un outil et être autorisé à l'utiliser pour agir sont deux décisions différentes.

Lire une boîte mail n'est pas envoyer un message. Consulter un calendrier n'est pas supprimer une réunion. Lorsque l'accès et l'action sont accordés en une seule décision, une partie du choix reste implicite, et personne ne l'a formulée.

De combien d'autonomie cette tâche a-t-elle besoin ?

Prenons un cas courant : le traitement d'une demande client. L'objectif métier ne change pas, mais plusieurs niveaux de délégation sont possibles. Au premier, l'agent analyse le message et prépare une réponse qu'une personne envoie. Au deuxième, il rédige et sélectionne la réponse, puis la soumet pour validation. Au troisième, il répond directement au client et met à jour son dossier. Au quatrième, il peut en outre accorder un remboursement dans certaines limites.

L'objectif reste le même d'un niveau à l'autre. Ce qui change, ce sont les décisions confiées au système et les conséquences qu'il peut produire sans intervention humaine. La question « faut-il un agent ? » devient dès lors peu utile.

À partir de quel niveau l'autonomie supplémentaire apporte-t-elle assez de valeur pour justifier les permissions et les risques qu'elle introduit ?

Pour examiner cette question, j'utilise cinq points. Il ne s'agit ni d'un référentiel ni d'une norme officielle : c'est une grille de travail proposée par Prompt & Pulse.

• Utilité : qu'apporte concrètement cette délégation et comment mesure-t-on ce bénéfice ?
• Périmètre : dans quelles limites l'agent peut-il intervenir et qu'est-ce qui en est explicitement exclu ?
• Autorisation : quelles actions peut-il exécuter seul et lesquelles nécessitent un accord préalable ?
• Supervision : quand une personne doit-elle intervenir et sera-t-elle réellement disponible à ce moment-là ?
• Traçabilité : peut-on reconstituer ce que l'agent a fait et sur quelles informations il s'est appuyé ?

Le test des dix minutes

Comment appliquer ces cinq points à une proposition concrète ? Prenez la description de la solution qu'on vous propose et accordez-vous dix minutes. L'objectif n'est pas de réduire l'autonomie par principe : une délégation importante peut parfaitement être justifiée. L'enjeu est de savoir expliquer pourquoi ce niveau est nécessaire et pourquoi le niveau immédiatement inférieur ne suffit pas.

Trois questions avant de déléguer

Avant de confier davantage à un agent, je poserais finalement trois questions. Qu'avons-nous réellement besoin que cet agent fasse ? Quelles actions doit-il pouvoir effectuer seul ? Et lorsqu'il se trompe, qui s'en aperçoit, qui répare et qui répond ?

Aucune de ces trois questions ne porte sur la performance du modèle, et c'est précisément ce qui les rend utiles. La capacité technique d'un système ne suffit jamais, à elle seule, à démontrer la nécessité de lui déléguer une action.