Outil IA ou agent IA : pourquoi la frontière ne tient jamais
En 2016, Gwern prédisait que tout outil IA dériverait vers l'action autonome — l'approbation humaine est l'étape la plus coûteuse. Votre stack lui donne raison.
Publié le 2026-08-05
La fonctionnalité que personne n'annonce
Ouvrez le changelog de n'importe quel produit IA que vous payez. Quelque part dans l'année écoulée, il a appris à *faire* quelque chose : naviguer sur le web, ouvrir vos fichiers, envoyer l'e-mail au lieu d'en rédiger le brouillon, cliquer tout seul dans un écran. La fenêtre de chat est toujours là, mais il lui a poussé des mains.
Ce n'est ni un accident, ni un complot. C'est une prédiction qui se réalise à l'heure — formulée en 2016, avant qu'aucun de ces produits n'existe, par le chercheur pseudonyme Gwern Branwen, dans un essai intitulé "Why Tool AIs Want to Be Agent AIs".
La prédiction
En 2016, le discours rassurant sur l'IA tenait en une phrase : nous construirons des IA *outils* — des systèmes qui répondent quand on les sollicite, puis s'arrêtent — plutôt que des *agents* qui agissent seuls. Gardez un humain aux commandes, et rien ne peut vraiment mal tourner.
L'essai de Gwern démontait cet équilibre pour des raisons purement économiques. Tout ce qu'un outil sait faire, un agent construit sur la même intelligence le fait moins cher et plus vite, parce que la sortie de l'outil attend un humain. Dès que deux entreprises se font concurrence, celle qui laisse son IA agir gagne sur la vitesse et sur le coût, et l'autre suit ou perd. Personne n'a besoin de décider de retirer l'humain. Le marché retire l'humain.
D'où le titre. Les IA outils « veulent » devenir des agents non pas parce qu'un logiciel veut quoi que ce soit, mais parce que chaque acheteur, chaque éditeur et chaque pression concurrentielle poussent dans la même direction, version après version.
L'arithmétique derrière la dérive
Le mécanisme est une vieille loi de l'informatique. La loi d'Amdahl dit : accélérez 95% d'un processus, et le temps total est désormais dominé par les 5% que vous n'avez pas touchés.
Appliquez-la à votre propre semaine. Le modèle rédige le rapport en quatre minutes ; le brouillon attend ensuite quatre heures que vous sortiez de réunion pour cliquer sur approuver. Le goulot d'étranglement, ce n'est pas le modèle. C'est vous. Et chaque progrès du modèle vous en fait un un peu plus — c'est exactement pour ça que la roadmap de chaque éditeur converge vers la réduction de l'étape d'approbation.
La seconde moitié du phénomène, vous l'avez observée sur vous-même. La première semaine, vous relisez chaque brouillon d'IA ligne à ligne. La troisième, vous survolez. La sixième, vous approuvez depuis votre téléphone sans ouvrir la pièce jointe. L'humain « dans la boucle » se dégrade en silence en humain tampon-encreur — et une relecture qui dit toujours oui est un coût sans bénéfice, ce qui explique qu'elle finisse par être supprimée du design.
Regardez-la opérer dans votre propre stack
La dérive est visible dans n'importe quel produit que vous utilisez depuis un moment :
Étape — Ce qu'il fait — Ce que vous faites
Chatbot — Répond aux questions — Tout le reste
+ web & fichiers — Lit ses sources lui-même — Vérifier ce qu'il a lu
+ connecteurs — Écrit dans vos outils — Approuver chaque écriture
+ exécutions planifiées — Agit pendant que vous dormez — Lire le compte rendu
+ pilotage d'écran — Manipule l'interface — Regarder, parfois
À chaque ligne, l'IA prend une part de l'action et vous en prenez une de moins. Aucune étape n'a ressemblé à une décision. Voilà à quoi ressemble « les outils veulent devenir des agents » depuis le côté acheteur du comptoir : pas un lancement, une dérive.
Les deux mauvaises leçons
La première mauvaise leçon, c'est de refuser la dérive — tout épingler au chat, interdire aux outils d'agir. Cela ne fait que rejouer l'économie du problème avec vous dans le rôle du perdant : vous voilà en concurrence avec des entreprises qui n'ont pas refusé. Si l'autonomie ne valait rien, il n'y aurait pas de dérive à combattre. C'est sa valeur qui la rend inévitable, et c'est cette valeur que vous achetez.
La seconde mauvaise leçon, c'est de hausser les épaules et de tout laisser tourner. Le problème, c'est que la plupart des produits qui acquièrent de l'autonomie n'ont jamais été conçus pour elle. Un produit de chat qui a gagné des outils une version à la fois a une autonomie par accrétion : les permissions n'ont jamais été modélisées parce qu'un chatbot n'en avait pas besoin, la piste d'audit est un fil de messages qui défile, et l'approbation est une boîte de dialogue que tout le monde ferme d'un clic. Les freins ont été montés après coup — quand ils ont été montés.
Une autonomie conçue, pas une autonomie accumulée
Si le logiciel autour de vous va agir — et il va agir — la question à poser aux éditeurs n'est pas « est-ce autonome ? » mais « qui a conçu l'autonomie ? »
Une autonomie conçue ressemble à de l'emploi, parce que l'emploi est le plus vieux système humain pour déléguer l'action sans danger :
- Un accès délimité. Ce qu'il peut toucher se décide avant qu'il commence, par employé — ça ne se découvre pas dans un changelog.
- L'approbation comme circuit, pas comme popup. Les gestes irréversibles — envoyer, payer, supprimer — attendent une personne nommée, et tout le routinier n'attend personne.
- Une piste d'audit. Chaque action menée, listée, par employé, après coup. Pas une transcription de chat — un journal.
- Un arrêt franc. Un interrupteur qui révoque tous les accès, et un modèle de sécurité qui existait dès le premier jour plutôt qu'au quatre-centième.
C'est la même ligne de partage que harnais contre wrapper, vue du côté sécurité : la boucle est ce qui rend un logiciel capable d'agir, et le harnais autour de la boucle est là où vivent les freins. Un produit qui a fait grandir la boucle sans faire grandir le harnais vous a livré la dérive sans la conception.
Ce que ça change pour vous
L'essai de Gwern a été écrit comme un avertissement sur la superintelligence. Dix ans plus tard, il se lit comme un guide d'achat. La dérive qu'il prédisait est devenue une ligne de votre budget logiciel : chaque outil de votre stack est en train de devenir un agent, annoncé ou non, et faire comme si de rien n'était signifie seulement que l'autonomie arrivera sans gestion.
Nous avons construit OpenLabor en partant du principe que l'essai avait raison. Ici, les employés sont des agents à dessein — embauchés avec un périmètre, journalisés action par action, arrêtables en un clic — parce que l'alternative n'a jamais été « des outils qui restent des outils ». C'était des agents que personne n'a conçus.
Tous les articles du blog OpenLabor