Tous les billets --- Scholia -- Ce qui pourrait...

La stupidité de l'"IA agentique"

2026-01-18 12:56:30.260724-05:00

Intelligence artificielle Agents intelligents Alexia Schneider

La stupidité du langage commercial des grandes entreprises du numérique me laisse de plus en plus bouche bée¹. Les médias reprennent avec une rhétorique abrutissante le langage creux de la publicité. Mais ce qui m'étonne encore plus, c'est la rapidité avec laquelle la communauté de recherche récupère ce langage et ses expressions et les met au centre de ses discours et ses intérêts.

J'ai déjà eu l'occasion de parler de la vacuité de l'expression "intelligence artificielle". Or on peut dire la même chose d'autres expressions et notamment l'idée d'"agent IA" ou d'"IA agentique".

Tout d'abord, que serait l'"IA agentique"?

Prenons la définition qu'essaye de nous faire passer un des grands acteurs commerciaux, IBM:

Contrairement aux modèles IA traditionnels, qui fonctionnent selon des contraintes prédéfinies et nécessitent une intervention humaine, l'IA agentique fait preuve d'autonomie, d'un comportement orienté objectif et d'adaptabilité. Le terme « agentique » fait référence à l'agentivité (pouvoir d'action) de ces modèles, c'est-à-dire à leur capacité à agir de manière indépendante et ciblée (Lu ici)

Un peu d'analyse de cette citation. Tout d'abord, il faut souligner la rhétorique du progrès linéaire: la technologie se développe toujours, elle devient de plus en plus puissante. On vend ce rêve de la progression sans fin. Les modèles d'IA "traditionnels" d'un côté, et la nouvelle révolution de l'autre (il y en a une tous les jours). Cette idée de progrès est évidemment nécessaire pour le marketing, qui essaye chaque jour de nous vendre un nouveau gadget. Toute réflexion devient impossible : puisque le progrès consiste à aller toujours vers le mieux, on doit seulement acheter le dernier produit. On ne peut pas se questionner sur ses besoins pour décider quelle serait la meilleure approche à adopter ; on doit juste acheter le dernier outil et cliquer.

Pour le reste, la définition ne dit pas grand-chose et relève de la tautologie : l'IA agentique peut agir. Si on continue à lire le texte d'IBM, on trouve quelques informations en plus:

Un modèle d'IA générative comme ChatGPT d'OpenAI peut produire du texte, des images ou du code, mais un système d'IA agentique peut utiliser ce contenu généré pour effectuer des tâches complexes de manière autonome, en faisant appel à des outils externes.

Donc, l'IA agentique utiliserait des outils externes. Voilà sa capacité d'"action".

Mais concrètement, qu'est-ce que cela signifie?

Techniquement, les "agents IA" sont des systèmes si possible encore plus stupides que le langage commercial qui veut nous les vendre. Ce sont juste des piles de prompts en langage naturel à partir desquels on essaie ensuite de deviner des intentions de l'utilisateurice et de les transformer en un choix d'outil approprié.

Faisons un exemple. Admettons d'avoir devant nous un '"agent IA". Son interface première est toujours un LLM. Cela signifie que notre seule manière d'interagir avec l'application sera la langue naturelle (un prompt, donc, ou un message vocal qu'un autre modèle transformera en texte). Admettons d'écrire le prompt suivant: "Je veux aller à Florence". Nous savons qu'un LLM est un modèle de langue capable de deviner les tokens les plus probables après d'autres tokens. Le comportement normal du LLM sera donc de deviner quels sont les mots les plus probables qui viennent après les mots "Je veux aller à Florence". Par exemple, le modèle pourrait répondre "Quelle bonne idée! Florence est une très belle ville!". Mais cette réponse ne correspond pas du tout à ce que nous attendions.

Or, première remarque: qu'est-ce que nous attendions au juste? Est-ce que nous le savons? Que signifie cette phrase "Je veux aller à Florence"? Est-ce l'expression d'un besoin précis? Nous reviendrons sur ce point.

Un « agent IA » ajoute des prompts avant le prompt de l'utilisateur ou de l'utilisatrice, en essayant d'orienter autrement la réponse du LLM. Attention: cette démarche n'a rien de technique. Il s'agit vraiment juste de faire en sorte que l'application qui utilise le LLM ajoute des bouts de texte cachés au prompt. Mon prompt "Je veux aller à Florence" sera donc précédé par une série d'instructions (qui peut être très longue) en langage naturel. Avec ces instructions, on espère orienter la réponse du LLM pour être ensuite capable de l'utiliser. Ces instructions peuvent dire qu'il faut analyser le prompt, trouver l'intention, analyser s'il y a des dates et les mettre dans un format standard, etc. Souvent, on essayera de faire en sorte que le modèle réponde avec du texte structuré: par exemple en json. Or, le problème de tout cela est que la réponse du LLM n'a rien d'expert. Elle est probabiliste. Les instructions ne sont donc pas respectées, mais elles sont juste une série de mots dont on espère qu'ils auront une influence sur le comportement du LLM. Concrètement, il ne s'agit pas du tout d'instructions, juste de mots, juste du bavardage qui essaye d'orienter la réponse qui restera toujours, cependant, ce qu'elle est: du bavardage probabiliste. Dans les instructions, on essaye notamment de limiter le texte inutile et les bruits, en disant, par exemple "Ne répète pas le prompt, donne seulement les informations structurées demandées..." etc. Mais ces "consignes" ne sont pas nécessairement respectées, car elles ne sont pas des règles pour le LLM, juste un prompt de plus.

On en arrive donc à une réponse du LLM. Au lieu de donner cette réponse à l'utilisateur, on essaye de la traiter avec un algorithme. Dans ce cas, admettons d'avoir "enrichi" le prompt initial avec des instructions qui essayent d'orienter la réponse pour avoir des données structurées sur le type de demande de l'utilisateurice. On aura une réponse du type:

L'utilisatrice ou l'utilisateur me demande d'organiser un voyage. On peut représenter sa demande comme suit: 'type': 'voyage', 'destination': 'Florence', 'depart': None, 'transport': None, date: None

Il est possible que, dans nos instructions, nous eussions demandé juste les données structurées, mais très fréquemment, il y aura des bruits, comme dans cet exemple, la première phrase.

Maintenant, il faudra traiter cette réponse avec un algorithme qui essaye d'abord de trouver dans ce texte les données structurées et ensuite de les traiter. Opération "sale" (aucune élégance informatique n'est possible, parce qu'on est face à un modèle ambigu et approximatif) et au succès incertain, car justement, on n'a aucune idée de ce que le LLM nous répondra. Ici peut donc commencer une partie "experte" de notre application, à savoir: nous donnons des règles et nous pouvons créer un algorithme qui les applique. Par exemple, on va parser les données et dire que si le type de demande est un voyage, il faut la date, le point d'arrivée, le point de départ et le moyen de transport. Si ces informations sont vides, alors nous pouvons envoyer une demande à l'utilisateur. Par exemple, "Pourrais-tu spécifier la {information manquante}". Et la réponse de l'utilisateur sera accompagnée d'un autre prompt qui demande de reproduire les données structurées avec les informations manquantes. Une fois que toutes les informations nécessaires seront disponibles, notre algorithme pourra envoyer une requête sur une plateforme de voyage et obtenir, par exemple, un devis.

Dans ce processus, nous déléguons au LLM et à l'application dans son ensemble une série de choix. On peut résumer les effets en 3 points:

1. Les "actions" réalisées par l'application ne sont jamais "expertes, parce que leur enchaînement dépend toujours de la réponse probabiliste du LLM. Un agent n'a jamais un comportement déterministe. Brancher un système expert (à savoir un système qui applique des règles précises) à un système probabiliste ne rend pas expert le système probabiliste. Le comportement dans son ensemble reste probabiliste. On pourrait dire que deterministe+probabiliste = probabiliste. Cela est très problématique dans des cas où on cherche des informations objectives. Si on veut une réponse précise, si nous voulons, par exemple, être sûrs que nous choisissons le voyage le moins cher dans une liste, l'approche de ces applications ne garantit jamais le succès, car son comportement dépendra toujours de la réponse probabiliste et donc pas déterminée, du LLM. Ce premier point implique qu'utiliser une application de ce type pour un usage qui demande une réponse exacte constitue une aberration épistémologique.
2. La structuration de nos demandes est faite par le LLM. Ces applications nous habituent de plus en plus à ne pas préciser nos demandes, jusqu'au point de ne pas trop savoir ce que nous voulons. C'est la radicalisation du système consumériste où le besoin est créé par l'entreprise qui vend le produit. Là, on est à son paroxysme, car on n'a même plus la nécessité d'exprimer le besoin, c'est le LLM qui transforme une idée vague en besoin. Que voulais-je quand j'ai dit vouloir aller à Florence? Exprimer un intérêt général pour un voyage en Toscane? Avoir plus d'information sur l'histoire du berceau de la Renaissance? Réfléchir sur différentes possibilités de vacances? Savoir quelle est la distance entre Florence et Montréal? Savoir s'il est possible d'aller à Florence en voilier depuis Montréal? Peu importe. Ces applications nous invitent à ne pas nous poser la question. L'application orientera notre idée vague pour la transformer en une action.
3. L'ensemble de choix que l'application fait est opaque et est comme "le meilleur". L'application a "réfléchi" à notre place. Or, évidemment, cette "réflexion" incarne les valeurs de l'application. Si l'entreprise qui la produit a un partenariat avec une plateforme qui vend des voyages, notre demande sera orientée vers l'achat d'un service de cette plateforme. Mais même s'il n'y avait pas une volonté commerciale (difficile, étant donné que ce sont des entreprises commerciales qui proposent ces outils, mais soit), les choix représenteraient une vision particulière. Au lieu de choisir par nous-mêmes les moyens qui nous semblent les plus pertinents, par exemple, pour comparer des billets d'avion, nous déléguons l'application.

Ce sont des applications techniquement très "bêtes", car elles sont incapables de faire ce que normalement une machine sait faire très bien, à savoir appliquer des règles précises. Or, dans notre vie quotidienne, nous avons parfois besoin d'approches probabilistes, mais d'autres fois, nous avons besoin d'appliquer des règles. Dans notre cas: si je voulais choisir des avions pour Florence, j'aurais dû d'abord bien préciser ma demande. Je veux des avions, qui partent de Montréal, le 21 janvier 2026; je préfère avoir peu de correspondances, je préfère, si possible, voyager avec une compagnie particulière; je préfère utiliser une plateforme (que j'aime bien pour peu importe quelle raison). Une fois que ces besoins auront été spécifiés, je n'aurai plus rien à faire de la langue naturelle. J'aurai besoin plutôt d'une série de données structurées, par exemple sous forme de tableau, avec des dates, des prix, des compagnies; cela me permettra de sélectionner, filtrer, naviguer dans les données et ensuite faire mon choix.

Souvent, la langue naturelle est le pire moyen de traiter une question: parce qu'elle est par nature ambiguë et approximative et dans certaines occasions, nous cherchons des informations précises. Un vol "cher", par exemple: le concept est ambigu. "Plus ou moins cher", c'est encore ambigu. Alors qu'une fonction mathématique comme < est claire et donne un résultat sûr. Ces applications sont bêtes parce qu'elles essayent de tout faire fonctionner avec une approche unique, même quand cette approche n'a aucun sens par rapport au besoin.

Ces applications, par ailleurs, n'ont absolument rien de révolutionnaire et ne changent fondamentalement rien à ce qu'IBM appelle "les modèles traditionnels". Il s'agit juste d'empiler des prompts et ensuite de les renvoyer à des algorithmes d'une simplicité extrême et assez peu élégants, car ils essayent de trouver, dans les réponses approximatives du LLM, quelque chose d'exploitable (c'est la fête des regex...). Le niveau de technique n'est pas en train de monter, mais au contraire de péricliter. Au lieu de développer des systèmes de plus en plus complexes, nous sommes en train de tout réduire à un bavardage approximatif.

Tout cela sans compter le coût computationnel absurde que cette approche comporte. Au lieu de consulter un csv avec des données bien structurées et voir des réponses précises et objectives à une demande bien spécifiée, nous faisons tourner des modèles immenses pour essayer de deviner de quelle manière orienter une demande floue, si possible pour en tirer un profit maximal.

Voilà les révolutions qu'on nous vend. Et nous les achetons avec enthousiasme.