Coup de gueule aléatoire sur l'état actuel des agents IA :
Certains ne les appellent pas agents, mais les « agents de workflow » aux flux déterministes sont omniprésents et fonctionnels. N'importe qui peut créer des agents de workflow simples, même en utilisant des outils no-code comme Zapier et n8n. Les agents de workflow complexes exigent une réflexion bien plus approfondie pour être développés de manière fiable et efficace. Un workflow complexe, conçu pour un cas d'usage courant et pertinent, avec des intégrations intégrées, peut constituer une activité autonome et un excellent modèle de commercialisation pour s'étendre ultérieurement à d'autres workflows ou à des tâches plus autonomes.
Les agents plus dynamiques/autonomes commencent à être fonctionnels et utiles pour la recherche (surtout s'ils sont basés sur le web) et le développement. Leur fiabilité diminue cependant dès lors qu'on ajoute davantage de sources de données (par exemple, des API). Les agents en lecture seule sont rassurants et faciles à tester, mais laisser des agents autonomes agir (écrire) est source d'inquiétude. (À ce propos, il serait intéressant que des outils comme un CRM permettent de créer une copie d'un environnement de développement et d'exécuter des expériences d'automatisation, avec la possibilité de revenir à la version précédente ou de les réintégrer.)
Les agents dynamiques fonctionnent bien lorsqu'ils peuvent (1) élaborer et suivre un plan efficace, (2) exécuter correctement les tâches, et (3) trouver le contexte approprié pour chaque étape (planification et exécution). Enfin, ils doivent (4) analyser leur fonctionnement (avec ou sans intervention humaine) afin d'ajuster le plan et d'améliorer l'exécution des tâches ayant échoué ou peu performantes.
planification des tâches : capacités de raisonnement de llm Ces méthodes fonctionnent bien pour les listes de tâches simples ne nécessitant aucun contexte privé (comme une recherche approfondie, une simple série de recherches web avec synthèse). Cependant, pour la recherche sur un grand nombre d'entités, cette approche est moins efficace car la gestion des listes de tâches est relativement basique. Les outils d'IA basés sur des tableurs sont plus performants pour la recherche sur de nombreuses entités, car la gestion des tâches est déléguée au tableur ; le passage de longues listes de tâches entre les invites n'est pas adapté. La gestion des tâches dans les agents de programmation fonctionne avec des problèmes simples, un code simple ou lors d'un démarrage à zéro. Dès qu'il s'agit de projets préexistants plus complexes, leur fiabilité diminue. Les développeurs améliorent cette fiabilité en documentant le fonctionnement et l'organisation de leur code (fichiers .md), ce qui permet à l'agent de construire des listes de tâches plus pertinentes. Un code complexe exige davantage de documentation et, à terme, l'extraction dynamique du seul contexte pertinent de cette documentation. De nombreuses personnes et entreprises ont des opinions bien arrêtées, mais non documentées, sur l'ordre, l'approche et les outils appropriés pour mener à bien un projet. Il est donc nécessaire de développer des méthodes permettant de documenter ces pratiques en amont et de manière flexible. Une autre raison pour laquelle les agents de recherche basés sur le codage et le Web fonctionnent bien est qu'ils utilisent tous le même ensemble d'outils, il n'est donc pas nécessaire d'« apprendre » à utiliser ces outils (nous y reviendrons plus tard).
Exécution des tâches : les tâches consistent généralement en des appels d’API (nécessitant une authentification et une compréhension de l’utilisation de l’API et de la structure des données sous-jacentes, qui peut être unique, comme dans un CRM ou une base de données avec des tables/colonnes personnalisées), en un raisonnement LLM (par exemple, la synthèse), en une combinaison de ces éléments, voire en des agents de workflow*. Un agent de recherche effectue simplement une recherche web et une synthèse en boucle. Les agents de codage effectuent des opérations CRUD sur votre base de code, et peuvent également effectuer une recherche web pour trouver des API d’apprentissage. L’authentification et l’accès API de base semblent résolus (les MCP sont bien adaptés à ce contexte), mais j’aimerais en savoir plus sur le contexte spécifique à l’outil (interroger l’utilisateur, mais aussi analyser la connexion initiale, explorer les données existantes pour comprendre comment l’outil est utilisé, comment les données sont structurées et pour quels scénarios/projets nous utilisons l’outil). Les erreurs, les réflexions et les retours d’information doivent se transformer en enseignements structurés, réintégrés dans le contexte de manière pertinente. Les mêmes outils peuvent être utilisés à des fins différentes et de différentes manières au sein des organisations, et nous devons documenter ces utilisations pour une exécution optimale des tâches.
Contexte : imaginez être un nouvel employé dans une entreprise. Vous apprenez beaucoup pendant la formation d'intégration (et plus celle-ci est réussie, plus vous serez efficace dès le départ), puis vient l'apprentissage sur le terrain, qui se divise en apprentissage par l'expérience de l'entreprise (« voici comment nous procédons ») et en apprentissage par sa propre expérience – la première étant plus fréquente dans les grandes entreprises. La gestion du contexte est similaire. Il existe différents niveaux de contexte : métadonnées (utilisateur/entreprise), contexte spécifique au projet/département, à la tâche, à l'outil, etc. Nous sommes passés de simples invites système à des stratégies hybrides RAG (vecteur, mot-clé, graphique), mais au-delà des données/du contexte, nous avons besoin d'indications sur quand et comment les récupérer. On observe des versions préliminaires de ces informations aujourd'hui, mais il y a encore beaucoup de marge d'amélioration. Il ne s'agit pas seulement d'un problème technique, mais aussi d'un enjeu commercial : il faut créer un document d'intégration qui couvre tous les scénarios possibles. À mesure que les projets se complexifient, il faut redoubler de réflexion pour bien filtrer le contexte afin que seules les informations pertinentes soient incluses dans les invites, tout en minimisant le contexte non pertinent.
Réflexion : nous disposons d’outils de surveillance des agents qui couvrent les coûts LLM/API et l’observation, mais l’attribution de succès/échec reste un défi. Un avantage des agents programmés réside dans leur capacité à détecter les échecs de manière déterministe (grâce aux tests du code). Pour de nombreuses autres tâches, nous cherchons encore la meilleure façon de recueillir les retours humains afin d’améliorer les résultats futurs. À ma connaissance, la réflexion actuelle repose sur une intervention humaine : les retours sont principalement transmis aux développeurs pour améliorer l’agent. Le véritable tournant se produira lorsque nous parviendrons à transformer cette réflexion en un outil d’auto-amélioration, permettant à l’agent de tirer des enseignements des échecs de génération et d’exécution de listes de tâches pour faire mieux la prochaine fois. En clair, la réflexion doit se transformer en un contexte bien structuré, intégrable aux invites uniquement lorsque cela est pertinent. Ceci permettra d’affiner certains aspects de l’agent, puis de créer des environnements d’apprentissage par renforcement pour agents. Nous en sommes encore aux prémices.
J'ai évoqué précédemment le transfert de tâches aux agents de workflow, ce qui prend tout son sens lorsque votre agent gagnerait à se passer d'agents de workflow comme outils (plutôt que de devoir analyser une liste de tâches connue à chaque fois), ou lorsque votre système est suffisamment complexe pour que des agents spécialisés, disposant d'un contexte et d'outils spécifiques, soient plus performants. C'est également le cas si vous utilisez des agents développés par d'autres (j'observe notamment l'utilisation d'API en langage naturel pour faciliter la collaboration entre agents).
Si nous disposions des modèles actuels avec une fenêtre de contenu infinie (sans dégradation de la qualité), une puissance de calcul infinie, un stockage infini, un accès via navigateur et un système de paiement, une seule boucle LLM suffirait probablement à accomplir beaucoup de choses. Le but de ce point apparemment inutile (rien n'est infini) est de montrer que l'orchestration des agents consiste en grande partie à gérer les limitations en concevant des moyens de décharger le travail du LLM grâce à la structure et au code.
Les agents en production se présentent sous différentes formes : outils internes, produits autonomes combinant divers outils, ou encore intégrés comme fonctionnalité à un outil principal. Ils peuvent être génériques ou spécialisés. Les agents de chat, vocaux et d'arrière-plan constituent les interfaces utilisateur les plus courantes pour déclencher des flux d'actions.
Qu'est-ce que j'oublie d'autre ?