L'analyse Agentic AI
L’IA générative est morte. Vive l’Agentic AI… peut-être.

De nombreux vendeurs de logiciels, encouragés par des valorisations de marché pas entièrement raisonnables, misent tout sur l’engouement autour de l’intelligence artificielle. D’ordinaire, je ne suis pas dans le business des prédictions, mais je prophétise qu’en 2025, agentic artificial intelligence sera un mot à la mode majeur. Comme c’est souvent le cas avec les mots à la mode technologiques, on peut s’attendre à de bribes de véritable nouveauté diluées dans un océan d’attentes gonflées.
Commençons par clarifier un peu ce qui est en jeu. Pour simplifier1, les LLM (grands modèles de langage) sont, fondamentalement, des modèles de complétion de texte. Ils prennent du texte brut en entrée et génèrent du texte brut en sortie. Comme ces modèles sont astucieusement pré-entraînés sur d’énormes quantités de contenus web, ils peuvent être utilisés pour une grande variété de tâches (par exemple, traduction, résumé, génération d’idées, etc.). Les LLM ont, en fait, rendu obsolète l’ensemble du domaine antérieur du NLP (traitement automatique du langage naturel).
Compte tenu des performances actuelles et du rapport qualité-prix des LLM, il est évident que cette technologie a le potentiel d’apporter beaucoup de valeur ajoutée à toute entreprise employant des cols blancs. Les détails sont cependant moins évidents. Ici, l’agentic AI (ou, plus précisément, ses fournisseurs) propose de combler le fossé entre les capacités brutes des LLM et leurs environnements informatiques.
Concernant les détails, Erik Pounds2 (Nvidia) a proposé en octobre 2024 la définition suivante pour l’agentic AI qui, je crois, capture parfaitement ce que l’on entend généralement par ce nouveau mot à la mode :
L’agentic AI utilise un processus en quatre étapes pour résoudre les problèmes : Perceive : les agents IA collectent et traitent des données provenant de diverses sources […]; Reason : un grand modèle de langage agit en tant qu’organisateur. Cette étape utilise des techniques telles que la génération augmentée par récupération (RAG) […]; Act : en s’intégrant à des outils et logiciels externes via des interfaces de programmation d’applications, l’agentic AI peut rapidement exécuter des tâches […]; Learn : l’agentic AI s’améliore continuellement grâce à un mécanisme de rétroaction, ou « data flywheel » […]
La grande vision de l’agentic AI est qu’elle ouvre la voie à un « employé entièrement digital » (terme que j’emploie, pas Pounds’) fonctionnellement équivalent à un travailleur de cols blancs. Avec, à peu près, environ un milliard de cols blancs dans le monde, il n’est pas trop difficile de comprendre pourquoi les marchés semblent perdre la tête face à cette perspective.
À y regarder de plus près, nous voyons qu’il existe deux obstacles fondamentaux, nettement distincts, que l’agentic AI tente de surmonter : l’instrumentation et l’apprentissage.
Instrumentation : Le premier obstacle, le plus évident, est que le LLM ne peut pas être exploité dans le vide. Les LLM sont des logiciels et, par conséquent, il faut une forme de plomberie IT. Cette plomberie garantit que le LLM peut récupérer les informations pertinentes de son environnement et émettre des commandes — destinées à compléter ce qui est attendu du LLM. Pour les départements IT — généralement déjà noyés sous des années de retard accumulé — concevoir cette plomberie constitue un défi à part entière. Cependant, les LLM eux-mêmes pourraient alléger ce défi.
Learning : Aussi étrange que cela puisse paraître, les LLM, pour la plupart, n’apprennent jamais rien après leur création. Voici notre deuxième obstacle. Tout ce que le LLM sait, c’est soit des informations publiques (d’où une partie du pré-entraînement) soit ce qui figure dans l’invite. Il y a presque3 aucun intermédiaire. Après chaque complétion, le LLM est réinitialisé à son état d’origine. Cependant, si la base de connaissances soutenant l’invite pouvait être mise à jour par le LLM lui-même, cet obstacle pourrait également être conceptuellement atténué.
Si l’agentic AI parvenait à résoudre ces deux obstacles — sans recourir à des LLM au-delà de ceux dont nous disposons actuellement — elle ouvrirait effectivement la voie aux cols blancs digitaux génériques. C’est toutefois une proposition très audacieuse et, malgré l’enthousiasme du marché, relever les obstacles mentionnés pourrait nécessiter des efforts considérables.
Sur le front de l’instrumentation, la proposition d’avoir un digital agent interagissant directement avec l’écran et le clavier — comme le ferait un humain — est attrayante, surtout parce qu’elle contourne apparemment entièrement les défis de la plomberie IT mentionnés précédemment. Cependant, c’est aussi la méthode la plus excessivement sur-ingénierée pour résoudre ce problème. Pour percevoir l’interface graphique, des dizaines (des centaines ?) de captures d’écran devront être acheminées vers le LLM même pour l’interaction la plus simple. Pour agir, des dizaines (des centaines ?) de commandes — par exemple, des commandes de souris — devront également être émises.
Bien que je ne doute pas qu’un tel exploit soit déjà possible avec les LLM actuels, je remets en question la praticité et la maintenabilité de cette approche. Bien que le traitement des images elles-mêmes représente une surcharge considérable en ressources informatiques, ce n’est pas le véritable frein (étant donné que les progrès du matériel informatique rendront probablement, avec le temps, cette surcharge bien inférieure au coût d’un employé à temps plein).
Le cœur du problème est le suivant : détailler sans équivoque (via des invites) chaque aspect minuscule de l’interaction avec les applications d’entreprise nécessaires pour réaliser une tâche représente un effort considérable. Cet effort requiert, au minimum, de bonnes compétences en informatique — voire un état d’esprit IT bien développé. Je doute fortement que cette tâche puisse être accomplie par quelqu’un d’autre incapable de programmer — ou incapable de devenir un programmeur débutant en quelques mois. De plus, comme le paysage IT de toute entreprise de taille conséquente change constamment, l’adéquation des invites devra être surveillée. En outre, les invites elles-mêmes devront être mises à jour régulièrement. Ainsi, cet effort sera permanent.
L’agentic AI va-t-elle réellement atténuer le besoin en talents digitaux humains — c’est-à-dire le problème du retard IT — sachant qu’elle s’accompagne de ses propres exigences considérables en talents digitaux humains ? Je ne pense pas. Cela nous ramène au point de départ : si des talents digitaux humains doivent être mobilisés, utilisons-les pour aborder directement la plomberie IT elle-même.
En exposant les données brutes pertinentes (généralement de nature relationnelle) au LLM (au lieu de tout acheminer via l’interface graphique), on peut s’attendre à une simplification des invites de plusieurs ordres de grandeur. On peut prévoir que des requêtes SQL de 5 lignes remplaceront des invites de 5 pages. De plus, l’opérateur humain pourrait même être assisté par le LLM pour rédiger ces requêtes SQL.
Naturellement, jongler avec des requêtes SQL — possiblement exécutées sur plusieurs bases de données hétérogènes — nécessite une instrumentation. Pourtant, ce type d’instrumentation est bien plus simple que celui envisagé par l’agentic AI. Il est si simple qu’en fait, de nombreux départements IT déploieront probablement des outils qu’ils auront conçus eux-mêmes à cet effet — comme ils le font régulièrement pour de petits utilitaires.
Avec le temps, les vendeurs de logiciels eux-mêmes ajusteront probablement leurs produits pour faciliter ce type de plomberie pilotée par le LLM, bien qu’il ne soit pas entièrement clair sous quelle forme cela se présentera (la multiplication des APIs est une option, les interfaces textuelles en sont une autre).
Sur le plan de l’apprentissage, je suis sceptique. L’agentic AI est présentée comme une étape vers l’intelligence artificielle générale, s’attaquant à l’une des limitations les plus fondamentales des LLM : le manque de véritables capacités d’apprentissage. Pourtant, la solution proposée par Pounds — un « data flywheel » alimenté par la génération augmentée par récupération (RAG) — n’est rien d’autre qu’une astuce simple superposée à une technologie par ailleurs impressionnante (le LLM lui-même).
Il est concevable que le LLM émette des commandes pour enrichir et mettre à jour progressivement son propre « data flywheel ». Il est également concevable que le LLM puisse générer son propre jeu de données pour fine-tuning en fusionnant des tentatives N-shot en des tentatives 1-shot, puis en émettant une commande pour déclencher une phase de fine-tuning.
Cependant, il n’est pas clair que les LLM — tels qu’ils existent actuellement — représentent une voie viable pour un tel exploit. Je suspecte fortement que maintenir un flywheel sain au fil du temps s’avérera difficile, et que cette maintenance — en supposant qu’elle fonctionne du tout — nécessitera une quantité considérable d’intelligence technique très humaine.
Ici, nous abordons une limitation fondamentale du paradigme des LLM tel qu’il existe actuellement. Il n’est pas certain que cette limitation puisse être levée simplement en ajoutant des éléments au-dessus des LLM. Mon intuition est que pour surmonter cette limitation, il faudra repenser les LLM eux-mêmes. Cela pourrait être un changement relativement mineur, comme l’a été la chaîne de pensée, ou nécessiter une refonte complète du tout4.
Dans l’ensemble, bien que je reste enthousiaste à propos des LLM, je ne suis pas convaincu que l’engouement autour de leur produit dérivé, l’agentic AI, soit justifié. Je n’ai aucun doute que les entreprises déploieront des « agents » pour mécaniser diverses tâches — tout comme ma propre entreprise, Lokad, le fait depuis deux ans. Cependant, si quelque chose, ce processus nous a rendus encore plus dépendants d’une main-d’œuvre talentueuse et tech-savvy workforce. De plus, en regardant ces initiatives, les éléments « agentic » étaient toujours les plus banals. Nous avons eu des difficultés, et échoué par moments, à mettre en production des éléments alimentés par les LLM, mais l’aspect « agentic » était, au mieux, une préoccupation très lointaine.
-
Les LLM actuels opèrent sur des tokens, et non sur des caractères Unicode, bien que cette contrainte puisse être levée à l’avenir. Les LLM peuvent également traiter des images d’entrée, si ces images sont linéarisées (intégrées) dans l’espace latent de la fenêtre de contexte. ↩︎
-
Les lecteurs curieux sont invités à consulter le matériel source sur https://blogs.nvidia.com/blog/what-is-agentic-ai ↩︎
-
Le fine-tuning est le processus qui consiste à prendre un modèle pré-entraîné et à poursuivre son entraînement sur un jeu de données spécialisé ou pour une tâche spécifique, adaptant ainsi le modèle en fonction d’informations privées. Le fine-tuning, cependant, repose sur la disponibilité d’un corpus de haute qualité, c’est-à-dire des contributions manuelles d’experts. ↩︎
-
Le modèle o1 lancé par OpenAI en décembre 2024 élève la technique de chain-of-thought au rang de citoyen de première classe, permettant ainsi au LLM de débuter par un monologue intérieur évoquant l’invite avant de se lancer dans la production de la complétion finale. Cette variation relativement modeste sur les LLM existants apporte néanmoins des améliorations substantielles pour certaines catégories de tâches, telles que les mathématiques et la programmation. ↩︎