Agents pour IA générative (LLM) – Rapport
Technique
1. Origine et motivations des agents LLM
Les Large Language Models (LLM) comme GPT-3 ou GPT-4 ont démontré des capacités remarquables de
compréhension et de génération de texte, mais ils présentent aussi des limitations qui ont motivé
l’apparition des agents LLM. Tout d’abord, un LLM classique n’a pas de mémoire persistante : chaque
requête est traitée de façon indépendante, le modèle ne se « souvient » pas de ce qui a été dit
auparavant. Cela complique les interactions longues où il faut conserver du contexte. Ensuite, un LLM
standard ne peut pas interagir avec le monde extérieur par lui-même : il ne peut ni naviguer sur
Internet, ni exécuter du code, ni effectuer de calculs précis – ce qui le rend incapable d’accéder à de
l’information à jour ou d’agir autrement qu’en produisant du texte. Par ailleurs, les LLM ont tendance à
halluciner du contenu (informations inexactes présentées avec assurance) et manquent de fiabilité sur
des tâches nécessitant un raisonnement complexe ou des étapes multiples à planifier. Enfin, ils
fonctionnent typiquement de manière synchrone et séquentielle (une question après l’autre), ce qui
n’exploite pas le potentiel de parallélisation pour des problèmes complexes.
Ces limitations ont conduit les chercheurs et ingénieurs à développer des agents LLM, c’est-à-dire des
systèmes qui entourent le LLM principal de divers mécanismes et outils pour le rendre plus autonome
et plus apte à orchestrer des tâches complexes. L’idée est de transformer un LLM « passif » (qui
répond uniquement à une requête) en un agent proactif capable de prendre des initiatives pour
atteindre un objectif donné. Concrètement, un agent LLM va pouvoir découper un problème en soustâches, planifier une séquence d’actions, appeler des outils externes (moteur de recherche, API,
calculatrice…) et adapter sa stratégie en fonction du résultat de chaque action, le tout de façon
itérative. Par exemple, au lieu de simplement répondre à une question complexe, un agent peut
successivement chercher des informations en ligne, extraire des données, effectuer un calcul, puis
formuler une réponse construite. Cette capacité d’orchestration est le cœur de la motivation des agents
LLM. En résumé, les agents ont été inventés pour dépasser les limitations des LLM bruts en leur
donnant de la mémoire (stockage de connaissances intermédiaires), un moyen d’agir sur leur
environnement, et la faculté de raisonner sur plusieurs étapes afin de s’attaquer à des tâches
complexes de manière autonome.
2. Rôles et usages des agents LLM
Un agent LLM sert avant tout à automatiser des tâches qui auraient autrement requis de multiples
interventions humaines ou des interactions successives avec un LLM classique. Grâce à leur capacité de
planification et d’action, ces agents peuvent remplir le rôle d’assistants intelligents dans de nombreux
contextes : ils prennent des décisions, exécutent des actions et enchaînent différentes opérations pour
atteindre un objectif.
• Automatisation de tâches complexes : Un agent LLM peut piloter l’exécution de procédures
impliquant plusieurs étapes. Par exemple, un agent pourrait gérer automatiquement un flux de
travail complet : collecte d’informations, analyse, puis génération d’un rapport. Là où un LLM
1
classique donnerait une réponse ponctuelle, l’agent est capable de s’occuper de tout le processus
en plusieurs étapes, sans supervision constante.
• Prise de décision autonome : Parce qu’il sait raisonner via le modèle de langage, l’agent peut
choisir la meilleure action à chaque instant. On lui fournit un objectif (par ex. « mettre à jour la
base de données clients en utilisant les derniers fichiers Excel »), et il décide quelles étapes suivre,
quelles données extraire, comment les transformer, etc. Il agit comme un système décisionnel
intelligent, allégeant la charge humaine pour les décisions routinières ou techniques.
• Outils augmentés et accès à des systèmes externes : L’un des intérêts majeurs des agents
LLM est leur capacité à intégrer des outils. Grâce à des mécanismes comme l’appel de fonctions
(function calling) ou des connecteurs, un agent peut interroger une base de connaissances,
appeler une API tierce, effectuer des calculs ou contrôler des logiciels. Par exemple, un agent
peut se connecter au système interne d’une entreprise pour récupérer des données, puis utiliser
une API de service externe pour les traiter. Cette interaction avec des systèmes externes étend
considérablement le champ d’action du LLM au-delà de la simple conversation textuelle.
• Interactions conversationnelles riches : Dans le cas d’assistants virtuels ou de chatbots
avancés, les agents LLM permettent de maintenir un dialogue contextualisé sur la durée.
Contrairement à un chatbot basique qui oublie le début de la conversation, un agent peut
stocker et rappeler des éléments d’historique (via une mémoire à long terme) afin de converser
de manière cohérente et personnalisée. Il peut aussi adapter son style ou ses actions en
fonction des préférences de l’utilisateur, puisqu’il garde en mémoire les interactions passées.
• Coordination multi-systèmes : Certains agents servent de courroie de transmission entre
plusieurs systèmes d’IA ou logiciels. Par exemple, un agent peut orchestrer une série de modèles
spécialisés : un modèle de vision par ordinateur pour analyser une image, puis un modèle
linguistique pour décrire l’image, puis un autre pour traduire la description. L’agent devient alors
le chef d’orchestre qui coordonne différentes compétences pour accomplir une tâche complexe
(voir l’exemple de HuggingGPT plus loin).
En somme, les agents LLM sont utilisés pour automatiser et orchestrer des tâches complexes de bout en
bout, en exploitant la puissance des LLM dans des applications concrètes : assistants personnels
intelligents, bots de service client capables de résoudre des problèmes, systèmes d’analyse de données
automatiques, agents de recherche documentaire, outils de productivité qui interagissent avec votre
agenda et vos emails, etc. Toutes ces applications bénéficient de la capacité des agents à comprendre
des instructions naturelles, à décomposer le travail et à agir de manière autonome pour atteindre le
résultat désiré.
3. Architectures logicielles des agents LLM
Plusieurs architectures logicielles ont émergé pour structurer le fonctionnement des agents à base de
LLM. Bien qu’il y ait de nombreuses variantes, on peut les comprendre en examinant quelques grands
paradigmes d’architecture :
• Boucle perception-réflexion-action : Au cœur de la plupart des agents LLM se trouve une
boucle itérative où l’agent perçoit son environnement (entrée utilisateur, nouvelle information),
réfléchit à l’aide du LLM (raisonnement, élaboration d’un plan) puis agit en exécutant une action
(appeler un outil, fournir une réponse partielle, etc.). Ce cycle se répète jusqu’à ce que l’agent ait
atteint son objectif ou épuisé les étapes prévues. C’est une abstraction de haut niveau, parfois
2
appelée boucle OODA (Observe–Orient–Decide–Act). Par exemple, un agent confronté à une
question complexe va : 1) observer la question, 2) analyser ce qui est demandé et planifier une
recherche, 3) agir en effectuant la recherche via un outil, 4) observer le résultat de la recherche,
5) réévaluer s’il a assez d’information ou s’il doit agir à nouveau, et ainsi de suite.
• Architecture mono-agent : Dans le cas le plus simple, un seul agent LLM est responsable de
toutes les tâches. On parle d’architecture monolithique : le même agent génère le plan, appelle
les outils, effectue toutes les actions séquentiellement. Ce modèle est adapté à des scénarios
pas trop complexes. Cependant, un seul agent généraliste peut atteindre ses limites lorsque
la variété des actions et des connaissances nécessaires augmente. En effet, si on dote un unique
LLM d’un très grand nombre d’outils ou de responsabilités, il peut avoir du mal à choisir la bonne
action (bruit dans le prompt, confusion entre outils) et voir ses performances baisser. Des
retours d’expérience ont montré qu’avec trop de fonctions disponibles et trop de contexte,
l’agent unique peut se mélanger les pinceaux ou produire plus d’erreurs.
• Architecture multi-agents : Pour pallier ces limites, on peut opter pour une architecture
mettant en scène plusieurs agents spécialisés qui collaborent. Chaque agent peut être
spécialisé dans un rôle ou un domaine particulier, et un mécanisme de coordination est chargé
de les faire travailler ensemble. Par analogie, au lieu d’un seul LLM « couteau-suisse » qui fait
tout, on a une équipe de LLM, chacun expert dans sa tâche. Les interactions multi-agents
peuvent prendre différentes formes :
• Orchestrateur centralisé : on introduit un agent spécial, souvent appelé agent orchestrateur ou
manager, qui reçoit l’objectif global et décide quel sous-agent doit intervenir à chaque étape. Par
exemple, un orchestrateur peut d’abord solliciter l’agent « Recherche web », puis passer le
résultat à un agent « Analyse de données », puis enfin demander à un agent « Rédaction » de
produire un rapport final. L’orchestrateur joue le rôle du chef de projet qui affecte les tâches aux
bonnes entités. Ce schéma reflète ce que certaines entreprises appliquent : un agent maître qui
sait quelles compétences possèdent les autres et les invoque en conséquence.
• Collaboration émergente : alternativement, on peut laisser plusieurs agents communiquer entre
eux de façon plus horizontale pour se coordonner. Par exemple, deux agents (l’un jouant le rôle
d’un utilisateur demandant des choses, l’autre le rôle d’un assistant qui répond) peuvent
converser pour affiner une solution – c’est la base de l’approche AutoGPT à l’origine, où GPT-4 «
discute avec lui-même » en quelque sorte. On peut avoir aussi des agents pairs, chacun ayant
une perspective (par ex. un agent « critique » et un agent « créatif » s’échangent des arguments).
Ce type d’architecture cherche à imiter des échanges de groupe où les idées de l’un alimentent
la réflexion de l’autre. Il n’y a pas nécessairement de chef désigné, ou bien le chef émerge
implicitement de la dynamique.
Dans les deux cas, un défi est de gérer la communication : les agents échangent généralement des
messages en langage naturel (protocole commun) pour se transmettre des informations ou des
demandes. On définit souvent un format de message pour que les interactions soient structurées.
• Exemple d’orchestration par rôles : Imaginons un assistant financier multi-agents. Plutôt qu’un
seul agent qui va tout faire (lire des données, calculer, rédiger une synthèse), on peut avoir : un
agent Lecteur qui extrait les données pertinentes (parsing de fichiers, SQL, etc.), un agent
Analyste qui effectue les calculs ou l’analyse statistique, un agent Rédacteur qui génère le
rapport final en langage naturel, et un agent Orchestrateur qui pilote le processus. L’agent
Orchestrateur reçoit la requête de départ (par ex. « produire le bilan financier du dernier trimestre
») et décompose : d’abord le Lecteur pour collecter les chiffres, puis l’Analyste pour les ratios et
tendances, et enfin le Rédacteur pour la formulation du bilan. Chaque agent a son outil ou
3
compétence spécifique, ce qui rend l’ensemble plus gérable et potentiellement plus
performant. C’est cette philosophie de séparation des préoccupations qu’adoptent des frameworks
multi-agents comme CrewAI (voir section 4), où l’on crée une « crew » d’agents aux rôles définis
(chercheur, écrivain, validateur, etc.) qui collaborent.
• Mémoire et état interne : Un aspect crucial de l’architecture est la gestion de la mémoire de
l’agent. Comme indiqué, les LLM ont une fenêtre contextuelle limitée. Pour permettre à un agent
de conserver des informations sur le long terme (au-delà de ce que la fenêtre du modèle peut
contenir), on intègre souvent des composantes de stockage. Par exemple, un agent peut utiliser
une base de données vectorielle pour stocker sous forme d’embeddings les faits découverts ou
décisions prises au fil de son exécution. Auto-GPT a popularisé cette idée en utilisant un cache
local ou un vecteur via Pinecone pour se rappeler des informations d’une itération sur l’autre. De
même, la notion de « mémoire à long terme » apparaît dans plusieurs frameworks : l’agent peut,
entre deux sessions ou deux étapes, requêter sa base de connaissances interne pour retrouver
ce qu’il a appris précédemment. Il existe aussi des mécanismes de mémoire épisodique (retenir
les derniers échanges) et de mémoire sémantique (retenir des faits structurés). En résumé,
l’architecture prévoit souvent un module dédié à la mémoire qui vient compléter le LLM.
• Intégration d’outils (plugins) : L’architecture logicielle d’un agent LLM inclut généralement un
moyen standardisé de brancher des outils externes. Un outil peut être une fonction Python,
une API web, une base de données, un calculateur, etc. La technique du function calling
introduite par OpenAI est un bon exemple : on définit un schéma de fonction (nom, paramètres)
et le LLM peut choisir de l’appeler en fournissant les arguments nécessaires. Des frameworks
comme LangChain ont, eux, une interface où chaque outil est un objet avec une méthode à
appeler et une description textuelle. L’agent, en phase de raisonnement, va émettre une action
du type « Utiliser l’outil X avec tel paramètre », le système exécute la fonction correspondante, puis
réintroduit le résultat dans le contexte du LLM. Ce couplage outillage est un pilier de
l’architecture : il faut concevoir comment les outils sont enregistrés, appelés, quels retours sont
fournis au modèle, comment gérer les erreurs (tool fails), etc. Certains frameworks avancés
comme Semantic Kernel parlent de skills ou plugins pour désigner ces fonctions que l’agent
peut utiliser. L’architecture inclut donc un répertoire d’outils et la logique pour s’en servir.
• Boucles d’itération et surveillance : Enfin, un agent peut avoir besoin d’une logique de
contrôle externe pour éviter les boucles infinies ou les dérives. Par exemple, on définit un
nombre maximum d’itérations à effectuer, ou des conditions d’arrêt (objectif atteint, information
trouvée). Certaines architectures prévoient un superviseur (qui peut être l’orchestrateur ou un
composant séparé) chargé de surveiller la cohérence des actions de l’agent, d’appliquer des
garde-fous (filtrage de contenu inapproprié, validation des réponses avant envoi, etc.). L’OpenAI
Agents SDK inclut par exemple la notion de guardrails pour valider les entrées/sorties et
s’assurer du respect de certaines contraintes. De même, dans un contexte multi-agents, il faut
gérer la synchronisation entre agents, éviter qu’ils ne se bloquent mutuellement ou qu’ils ne
s’emballent dans des conversations stériles. L’architecture logicielle doit donc prévoir des
mécanismes de contrôle du flot d’exécution (par ex., un orchestrateur ne lance pas la prochaine
étape tant que l’agent actuel n’a pas produit un résultat valable).
En résumé, l’architecture d’un agent LLM peut aller d’un simple loop itératif sur un seul LLM + outils,
jusqu’à un système multi-agents coordonné avec mémoire partagée et orchestrateur. Plus le
problème à résoudre est complexe, plus on aura intérêt à structurer l’agent en plusieurs modules
(mémoire, outils, agents spécialisés…). Des travaux récents, comme celui de Microsoft avec AutoGen,
montrent comment une architecture multi-agent asynchrone peut améliorer l’efficacité : au lieu d’un seul
agent en boucle, plusieurs agents communiquent de façon événementielle et peuvent même travailler
4
en parallèle sur certaines tâches, accélérant le processus. Quelle que soit l’architecture, l’objectif reste le
même : permettre au système global d’affronter des problèmes hors de portée d’un LLM seul en combinant
plusieurs capacités de manière orchestrée et persistante.
4. Panorama des frameworks d’agents LLM (au 22 mai 2025)
Au vu de l’engouement pour les agents LLM, de nombreux frameworks open-source ont vu le jour pour
faciliter leur développement. Ci-dessous, nous présentons une liste (aussi exhaustive que possible à la
date de rédaction) des principales bibliothèques et plateformes utilisées pour construire des agents
autonomes, ainsi que leurs caractéristiques saillantes.
LangChain et LangGraph
• LangChain – C’est l’un des frameworks pionniers et les plus populaires pour bâtir des
applications pilotées par LLM. LangChain fournit une panoplie de composants modulaires en
Python (et JavaScript) afin de gérer le prompt engineering, la mémoire, les connexions à des
données externes, et surtout la logique de chaînes et d’agents outillés. Il propose des
abstractions haut niveau pour créer des chaînes de raisonnement et appeler des outils de
manière flexible. Par exemple, avec LangChain on peut construire un agent qui interagit avec
une base de connaissances, effectue des recherches web, ou utilise une calculatrice, le tout en
orchestrant les appels au LLM et aux outils nécessaires. LangChain adresse ainsi les difficultés
liées à la conservation du contexte sur de longues sessions, à l’incorporation d’informations
externes et à la coordination de tâches multi-étapes – des défis classiques lorsqu’on utilise un
LLM brut. Techniquement, LangChain s’intègre avec de multiples fournisseurs de LLM (OpenAI,
HuggingFace, etc.) et offre différents backends de mémoire (mémoire courte, cache de
conversation, vecteurs pour mémoire longue, etc.). Il vient aussi avec une bibliothèque d’outils
intégrés (recherche web, requêtes SQL, lecture de documents…) qu’on peut utiliser tels quels ou
étendre facilement. Parmi ses points forts on compte : sa flexibilité pour concevoir des
comportements complexes, la facilité d’intégration d’outils et données externes, une
communauté très active qui fournit régulièrement de nouveaux modules, et une documentation
abondante. De nombreux projets d’agents customisés ont initialement été construits sur
LangChain du fait de cette richesse de l’écosystème.
• LangGraph – Il s’agit d’une extension de LangChain orientée vers la création d’applications multiacteurs et à état (stateful). Là où LangChain de base fonctionne plutôt de manière linéaire
(enchaînement d’appels), LangGraph introduit une représentation graphique (DAG) des
interactions d’agents. On peut modéliser les étapes de décision d’un agent ou de plusieurs
agents comme un graphe dirigé acyclique, avec des nœuds représentant des actions ou des
échanges, et des dépendances claires entre eux. Cette approche permet, par exemple,
d’exécuter en parallèle plusieurs sous-tâches indépendantes, d’implémenter des branchements
conditionnels (si tel résultat, suivre tel chemin sinon tel autre), ou de rejouer facilement certaines
branches en cas d’erreur (retries). LangGraph apporte ainsi des capacités de contrôle de flux
déterministe et complexe qui complètent l’approche plus séquentielle de LangChain. En
pratique, LangGraph est construit au-dessus de LangChain, ce qui signifie qu’il réutilise tous les
connecteurs et outils de celui-ci, mais ajoute une couche pour organiser les appels d’agents sous
forme de graphes de tâches. C’est particulièrement utile pour des applications exigeantes où l’on
doit garantir un certain ordre (ou parallélisme) dans l’exécution des actions et où l’on veut
bénéficier d’auditabilité (ex. suivre chaque nœud du graphe pour comprendre les décisions de
l’agent). L’outil est plus récent mais reflète une tendance à rendre les agents plus prévisibles et
industriels dans leur orchestration.
5
Auto-GPT et BabyAGI
• Auto-GPT – Ce projet, apparu en mars 2023, a grandement contribué à populariser la notion
d’agent LLM autonome. Auto-GPT se présente comme un script Python open-source capable de
piloter GPT-4 (ou GPT-3.5) de manière autonome pour accomplir un objectif fourni en langage
naturel. Concrètement, Auto-GPT prend une instruction utilisateur de haut niveau (par ex. «
trouve des idées de business et crée un plan ») et va tenter de l’exécuter en découpant la tâche en
sous-tâches, en les réalisant une par une et en bouclant jusqu’à ce que l’objectif soit atteint ou
abandonné. Il utilise le LLM pour générer des « pensées » et des « décisions d’action », et peut
recourir à des outils comme la navigation Internet, la lecture de fichiers, l’écriture de code, etc.
dans ce but. Techniquement, Auto-GPT a été l’un des premiers exemples d’application combinant
GPT-4 avec une boucle d’itération automatique. Il maintient une liste d’objectifs/tâches, une
mémoire (il supportait des plugins de mémoire de long terme type Pinecone), et fonctionne sans
supervision humaine directe une fois lancé. Auto-GPT a démontré qu’un LLM pouvait accomplir
des tâches relativement complexes de manière autonome, tout en mettant en lumière les défis
de cette approche (tendance à diverger ou à procrastiner sur des tâches inutiles si l’objectif est
flou, nécessité de paramétrer finement les prompts pour guider le comportement, etc.). Il reste
une référence historique et a engendré de nombreux dérivés ou forks.
• BabyAGI – Né peu après Auto-GPT, BabyAGI est un exemple minimaliste d’agent autonome
focalisé sur la gestion d’une liste de tâches de manière dynamique. Initialement proposé sous la
forme d’un script d’environ 140 lignes de code, BabyAGI illustre bien le concept de base : on
fournit un objectif, l’agent génère une tâche initiale à accomplir, puis il entre dans une boucle où
il exécute la tâche courante, en tire des résultats, crée de nouvelles tâches en fonction de ces
résultats, les ajoute à sa liste et ainsi de suite jusqu’à ce qu’il n’y ait plus de tâches ou que
l’objectif soit atteint. Cet agent utilise généralement un LLM pour penser/réfléchir et pour
générer du texte, combiné à un vecteur de mémoire (par exemple, BabyAGI peut stocker en
embeddings les résultats intermédiaires afin de s’y référer plus tard). Il s’appuie souvent sur la
bibliothèque LangChain pour les abstractions de haut niveau et l’intégration d’outils. Malgré sa
simplicité, BabyAGI démontre la capacité d’un agent à prioriser et générer des tâches au vol :
par exemple, donné un objectif « faire une étude de marché sur tel produit », il va créer les
tâches « chercher concurrents », « analyser prix », « rédiger synthèse », et ajuster en cours de
route si un résultat de recherche amène une nouvelle question. En somme, BabyAGI incarne la
notion de planificateur autonome itératif. Il a inspiré de nombreux projets plus complets, tout en
restant un bon didacticiel de par sa concision. (Le nom « AGI » est ambitieux, mais BabyAGI ne
prétend pas être une intelligence générale, c’était surtout un nom accrocheur pour l’idée d’un
agent GPT auto-bouclé.)
AgentVerse
• AgentVerse – AgentVerse est un framework open-source conçu spécifiquement pour créer et
expérimenter des environnements à plusieurs agents LLM. Il fournit deux modes principaux :
un mode task-solving où plusieurs agents collaborent pour résoudre une tâche donnée, et un
mode simulation où les agents interagissent entre eux dans un environnement (par exemple
pour simuler des comportements humains dans un monde virtuel). L’objectif affiché
d’AgentVerse est de faciliter la mise en place de groupes d’agents et d’observer l’émergence de
comportements collectifs. Par inspiration des dynamiques de groupe humaines, AgentVerse
permet de configurer des agents avec des rôles, des personnalités ou des objectifs individuels,
puis de voir comment, via la communication, ils peuvent accomplir un but commun plus
efficacement qu’un seul agent isolé. Les auteurs du framework ont montré que des groupes
d’agents bien orchestrés peuvent surpasser un agent unique sur certaines tâches complexes,
6
notamment grâce à la spécialisation et à l’échange d’informations. AgentVerse s’accompagne
d’une documentation et d’outils pour visualiser les interactions multi-agents, et se positionne
comme un banc d’essai pour la recherche sur la coopération entre agents (y compris l’apparition
possible de comportements sociaux désirables ou indésirables). En pratique, utiliser AgentVerse
revient à instancier plusieurs agents LLM (par ex. via des API OpenAI ou autres modèles) et
définir un scénario de communication (règles du tour de parole, conditions de terminaison, etc.).
Le framework se charge de passer les messages entre agents et de conserver l’historique
commun. C’est donc un bon outil pour qui veut explorer la dimension multi-agent en IA
générative sans tout recoder à la main.
CrewAI
• CrewAI – CrewAI est un framework qui adopte une métaphore organisationnelle : on y crée une
« crew » d’agents, c’est-à-dire une équipe dans laquelle chaque agent a un rôle spécifique et
collaborera à la résolution du problème. Par exemple, on peut définir une équipe avec un agent
Rédacteur, un agent Relecteur, un agent Chercheur, etc., et CrewAI va faciliter leurs interactions.
Le point fort de CrewAI est de proposer une orchestration haut niveau par rôles, proche du
fonctionnement d’une équipe humaine sur un projet. L’utilisateur définit les agents et leurs rôles
(avec pour chacun éventuellement un LLM différent ou un prompt différent adapté à sa
fonction), puis lance la résolution de tâche. Deux modes de coordination existent : un mode
auto-organisé où les agents décident entre eux de la répartition du travail, et un mode scripté
(CrewAI Flows) où l’on spécifie le scénario d’interaction (par ex. ordre des interventions, critères
de passage de relai). Cette flexibilité permet d’utiliser CrewAI aussi bien pour de la créativité
ouverte (laisser les agents brainstormer et s’auto-corriger mutuellement) que pour des
processus maîtrisés en entreprise (suivre un workflow déterminé avec validation). CrewAI
intègre également des notions de mémoire partagée de l’équipe et des modules pour surveiller
ou contraindre le déroulement (utile en contexte entreprise pour des raisons de conformité). En
2025, CrewAI a gagné en popularité avec plus de 30 000 étoiles GitHub, témoignant de l’intérêt
pour les systèmes multi-agents collaboratifs. En résumé, CrewAI apporte une approche
structurée et prête à l’emploi pour ceux qui veulent mettre en scène plusieurs agents aux
compétences complémentaires travaillant de concert, tout en laissant le choix entre une
coordination émergente ou contrôlée.
Microsoft Semantic Kernel (SK)
• Semantic Kernel (SK) – Semantic Kernel est un framework open-source proposé par Microsoft
qui vise à intégrer les capacités des LLM dans des applications traditionnelles, en particulier dans
un contexte d’entreprise. Contrairement à d’autres frameworks centrés sur les agents, SK se
présente plutôt comme un cadre de développement où l’IA est traitée comme un ensemble de
« skills » (compétences) qu’on peut appeler depuis son application classique. Autrement dit, SK
n’est pas un orchestrateur d’agent prêt à l’emploi mais une librairie permettant de construire
son propre orchestrateur en code, en combinant fonctions IA et fonctions classiques. Il
supporte plusieurs langages (C#, Python, Java), ce qui le rend adapté aux stacks existantes des
entreprises. Dans SK, on définit des plugins ou skills qui peuvent être : soit des compétences
s’appuyant sur un LLM (par exemple « résumer un texte », où le prompt de résumé est encapsulé
comme une fonction callable), soit des compétences purement codées (par exemple « envoyer
un email »). Le Planner de SK peut alors, à partir d’une requête complexe, composer
automatiquement un plan faisant intervenir plusieurs skills dans le bon ordre pour atteindre
l’objectif. Par exemple, si on demande « Trouve les ventes moyennes par région cette année et envoie
un rapport par email », SK pourrait planifier : appeler le skill base de données, puis le skill analyse,
puis le skill génération de texte, puis le skill envoi email. L’intérêt est que tout cela s’intègre dans
une application entreprise avec les sécurités et l’infrastructure existante (identité, logs, etc.). SK
7
offre aussi des connecteurs vers des services Azure, des stockages de mémoire variés et la prise
en compte de politiques de sécurité et de confidentialité (crucial en contexte pro). En somme,
Semantic Kernel se distingue en rapprochant le monde de l’IA de celui du développement
logiciel classique – il convient bien aux équipes de dev qui veulent incorporer un agent LLM
dans une application sans abandonner leurs paradigmes de code habituels.
Microsoft AutoGen (AG2)
• AutoGen / AG2 – AutoGen est un framework né des travaux de Microsoft Research, pensé dès le
départ pour exploiter la synergie de plusieurs agents LLM en conversation. Rebaptisé AG2
dans sa version la plus récente, il propose une approche où l’on considère que tout est une
conversation : plutôt que d’avoir une seule boucle LLM qui fait tout, on crée plusieurs agents
spécialisés qui se parlent pour résoudre le problème. Typiquement, on trouve dans AutoGen
des agents prédéfinis comme : un agent Assistant principal (incarnant l’exécuteur de la tâche
demandée), un agent Utilisateur factice (qui pose le problème et peut juger des réponses,
simulant l’utilisateur humain), voire d’autres comme un agent Dev (chargé de générer ou
d’exécuter du code si besoin) ou un agent Critique (chargé d’analyser la solution proposée et de
relever les erreurs). Ces agents échangent des messages de manière asynchrone et AutoGen
fournit l’infrastructure pour gérer ces échanges de façon robuste (file d’événements, callbacks,
etc.). L’avantage de cette approche est de pouvoir travailler en parallèle sur certaines parties :
par exemple, pendant que l’agent Assistant réfléchit, un agent Dev pourrait déjà commencer à
tester du code en tâche de fond. AutoGen insiste sur cette architecture event-driven et
concurrente qui le différencie d’une simple boucle synchrone classique. De plus, il permet
l’intervention humaine dans la boucle facilement : un développeur peut choisir de reprendre
la main à une étape, de corriger le cours de la conversation, puis de laisser les agents continuer.
AG2 a montré son efficacité dans des scénarios tels que la résolution collaborative de problèmes
de code (un agent qui code, un agent qui teste, un agent qui critique le résultat). En résumé,
Microsoft AutoGen/AG2 apporte une infrastructure haut niveau pour le multi-agent
conversationnel, avec un accent sur la flexibilité (on peut configurer ses propres types d’agents)
et la scalabilité (asynchrone, distribué). Il « cadre tout comme une conversation » pour reprendre
les termes de sa documentation, ce qui est une manière élégante de représenter n’importe quel
workflow complexe sous forme d’échanges structurés entre entités spécialisées.
OpenAI Agents SDK
• OpenAI Agents SDK – En 2025, OpenAI a introduit sa propre bibliothèque pour construire des
agents, cherchant à standardiser les pratiques autour de ses modèles. L’Agents SDK d’OpenAI
(disponible en Python) est pensé pour être léger, minimaliste mais performant. Il se concentre
sur quelques abstractions clés : la notion d’Agent (un LLM avec un ensemble d’instructions et
éventuellement des outils autorisés), les Tools (fonctions Python utilisables par l’agent, générées
automatiquement en schémas de fonction que le LLM peut appeler), et les Handoffs (la capacité
pour un agent de déléguer à un autre agent). En coulisse, le SDK gère la boucle d’agent classique
(appels du modèle, exécution des outils, itération jusqu’à complétion) de manière transparente
pour le développeur. Quelques points forts de cette librairie : elle intègre nativement des
guardrails (vérifications et filtrage des entrées/sorties, pour éviter que l’agent produise du
contenu indésirable ou utilise mal un outil), et propose des schémas standardisés pour définir
les fonctions-outils avec validation via Pydantic (ce qui réduit les risques d’erreurs de format).
Étant « officielle », cette SDK offre la garantie d’une intégration optimale avec les modèles
OpenAI et leurs nouveautés. Par exemple, le mécanisme de function calling y est première
classe (un outil = une fonction utilisable via l’API OpenAI, avec son schéma JSON
automatiquement transmis). L’OpenAI Agents SDK a été lancé publiquement en mars 2025 et a
très vite gagné du terrain, accumulant des milliers d’utilisateurs et de stars GitHub. On le voit de
8
plus en plus comme un socle standard pour déployer des agents en production lorsqu’on utilise
les modèles OpenAI, en raison de sa simplicité (peu de concepts à apprendre) et de son
orientation production-ready (surveillance, compatibilité future assurée par OpenAI).
Google Agent Development Kit (ADK)
• Google ADK – Annoncé lors de la conférence Google I/O 2025, l’Agent Development Kit de
Google est une réponse aux frameworks d’agent existants, avec une emphase sur
l’orchestration de workflow complexe et l’intégration à l’écosystème Google Cloud. ADK se
présente comme un framework modulaire et flexible pour développer et déployer des systèmes
d’agents, qui offre plusieurs modèles d’agents prêts à l’emploi : séquentiel, boucle, parallèle.
Cela signifie qu’un développeur peut facilement configurer un agent qui suit un enchaînement
d’étapes fixe, ou un agent qui va boucler sur une tâche jusqu’à satisfaction, ou encore une
équipe d’agents opérant en parallèle, selon les besoins du cas d’usage. L’ADK brille
particulièrement par son intégration aux outils Google : il prend en charge nativement les
descriptions OpenAPI pour que l’agent puisse appeler des services web (internes ou externes)
en se basant simplement sur le spec de l’API – l’agent comprend quelles fonctions sont
disponibles et avec quels paramètres via ces descriptions. De plus, il s’intègre à Google Cloud
Platform (GCP) pour le déploiement, avec par exemple un support direct de Vertex AI et des
options de déployer les agents sous forme de Cloud Run ou autres. Un aspect novateur est la
mise en avant de protocoles d’interaction standardisés : Google ADK implémente le protocole
Agent-to-Agent (A2A) qui vise à uniformiser la communication entre agents, potentiellement de
différentes organisations ou origines, ainsi que le Model Context Protocol (MCP) pour
standardiser l’échange de contexte avec les modèles. En interne, Google a indiqué utiliser ADK
pour ses propres agents (notamment ceux liés à son modèle Gemini prochain), ce qui démontre
la robustesse et l’échelle entreprise du framework. En somme, ADK se destine aux cas
d’usages industriels où l’on a besoin d’une forte maîtrise du workflow agent (avec des étapes
bien définies, éventuellement multiples agents), tout en profitant de l’écosystème cloud Google
pour la fiabilité, la sécurité (authentification aux API, etc.) et la scalabilité.
Hugging Face SmolAgents
• SmolAgents – Cette initiative de Hugging Face adopte une approche très différente des autres
frameworks : plutôt que de complexifier l’architecture de l’agent, SmolAgents la simplifie à
l’extrême en faisant reposer l’intelligence de l’agent sur la génération de code Python. L’idée est
que l’agent utilise le LLM pour produire du code qu’il exécute ensuite pour accomplir sa tâche. En
quelque sorte, l’agent raisonne en Python plutôt qu’en langage naturel uniquement 1 . Par
exemple, si l’agent doit résoudre un problème, il va générer un bout de code Python qui réalise
la solution (en pouvant importer n’importe quelle bibliothèque nécessaire), exécuter ce code,
observer le résultat, et ainsi de suite dans une boucle réflexive 2 . Cette approche rend l’agent
très flexible car en théorie il peut utiliser toute la logithèque Python (accès à des centaines de
librairies de calcul, d’APIs, etc.) simplement en les important dans le code qu’il génère.
SmolAgents est un framework très léger (environ 1000 lignes de code seulement) qui met en
place cette boucle de génération et d’exécution de code 3 . Il fournit des fonctions pour
sandboxer l’exécution (via Docker, etc.) afin de ne pas risquer d’effets de bord incontrôlés quand
l’agent exécute du code arbitraire 4 . C’est particulièrement adapté pour le prototypage rapide
ou la recherche : par exemple, tester si un LLM peut résoudre un puzzle logique en écrivant un
script. Cela donne une grande liberté au LLM agent (« maximum freedom in solving problems »
selon la description) au prix d’une moindre structure : contrairement à d’autres frameworks, il n’y
a pas de plan prédéfini ni de séquence outillée fixe, l’agent fait ce qu’il veut en Python.
SmolAgents a aussi une intégration avec le Hub de Hugging Face pour partager des agents
scripts et réutiliser des solutions. En résumé, SmolAgents propose un paradigme original d’agent
9
codeur exécutant, minimaliste mais puissant, surtout utile pour l’expérimentation et les cas où
l’on veut exploiter la capacité du LLM à écrire du code pour contourner ses limites (par exemple
faire des calculs ou utiliser des librairies spécialisées qu’il ne pourrait émuler en pur langage
naturel).
LlamaIndex
• LlamaIndex – Connu initialement sous le nom de GPT Index, LlamaIndex s’est imposé comme
un outil de choix pour tout ce qui est RAG (Retrieval-Augmented Generation). Ce framework
open-source n’est pas un orchestrateur d’agents généralistes, mais il s’intègre souvent dans des
agents pour leur fournir la capacité à ingérer et interroger des données personnalisées.
LlamaIndex permet de construire facilement des index sur des documents texte, des bases de
données, etc., puis de formuler des requêtes en langage naturel qui seront transformées en
recherches sur ces index, le résultat étant ensuite passé à un LLM pour générer une réponse
finale. En d’autres termes, LlamaIndex est un spécialiste de la connexion LLM-données. On peut
le voir comme un toolkit que l’agent utilise quand il a besoin d’informations précises non
présentes dans sa connaissance entraînée. Par exemple, un assistant juridique pourrait utiliser
LlamaIndex pour retrouver dans une base de contrats la clause pertinente à citer. Il supporte de
nombreux types d’index (vecteur pour la similarité sémantique, tables SQL, graphes) et sait
orchestrer la requête de façon intelligente : il dispose de Query Engines capables de sélectionner
la bonne source de données ou la bonne méthode d’index en fonction de la question posée.
LlamaIndex est souvent utilisé en combinaison avec LangChain (les deux sont compatibles et
complémentaires). Sa force est de simplifier tout le travail de pré-traitement des documents
(chunking, création des embeddings, stockage…) et de mise à disposition pour un agent. Au lieu
de coder soi-même la lecture de PDF, la vectorisation, la recherche de similarité, on utilise
LlamaIndex qui offre des abstractions prêtes. Ce framework excelle donc pour les agents de
question-réponse sur base documentaire ou les chatbots spécifiques à une connaissance
(intranet d’entreprise, documentation technique privée, etc.), où il est crucial que l’agent pioche
dans les sources vérifiées plutôt que d’halluciner. En résumé, LlamaIndex n’est pas un « cerveau »
d’agent mais un appendice mémoire externe intelligent, souvent intégré dans des solutions
complètes pour assurer la fiabilité des réponses.
Pydantic-AI
• Pydantic AI – Issu de l’écosystème Python et plus particulièrement de l’initiative de l’auteur de
Pydantic (la librairie de validation de données bien connue), Pydantic-AI apporte une approche
orientée schéma et typage aux sorties des LLM. L’idée de base est que dans une application
sérieuse, on sait quel format de donnée on attend de l’agent (par exemple une liste d’objets avec
certains champs), et Pydantic-AI va faire en sorte que l’agent produise exactement ce format,
sans erreur de parsing. Pour ce faire, on définit un modèle de données Pydantic (classes Python
avec types) correspondant à la tâche, puis la bibliothèque pilote le LLM pour qu’il respecte ce
format et valide la sortie. On est donc dans un paradigme de « schema-driven agents ». Par
exemple, si on attend qu’un agent fournisse une recommandation sous forme de JSON avec
champ item (str), price (float), etc., Pydantic-AI peut générer un prompt avec des balises
spéciales, utiliser des techniques de few-shot, puis parser automatiquement la réponse du LLM
en instance Pydantic, en rejetant la réponse si elle ne correspond pas au schéma (pour
éventuellement re-itérer). Cela assure une fiabilité importante dans les cas d’usage où la forme
de la réponse compte autant que le fond (par ex. alimenter directement une base de données ou
une API avec la sortie de l’agent nécessite un format strict). Pydantic-AI se positionne donc
comme un outil pour robustifier les agents en production, réduisant le besoin de posttraitement complexe ou de GPT dédié à la correction de format. En outre, la librairie supporte
plusieurs modèles (OpenAI, Anthropic, etc.) et s’intègre avec des outils de monitoring (Logfire)
10
pour suivre les outputs. Pydantic-AI peut être vu comme un complément à d’autres frameworks :
par exemple, on peut l’utiliser avec l’OpenAI Agents SDK ou LangChain pour valider les réponses
finales. Ce n’est pas tant un orchestrateur qu’une couche de validation/fiabilisation pour
s’assurer que l’agent respecte un contrat d’interface. Dans un contexte industriel où les erreurs
de format ou les hallucinations peuvent coûter cher, ce genre d’outil apporte une assurance
bienvenue.
Agno
• Agno – Anciennement appelé Phidata, Agno est un framework qui cible des besoins un peu
différents : la performance à grande échelle et le support natif de la multi-modalité. Agno
s’est fait remarquer en revendiquant une empreinte extrêmement légère et rapide :
l’initialisation d’un agent se compte en microsecondes, et la consommation mémoire serait 50
fois moindre que celle d’un agent équivalent sous LangChain/LangGraph. Cet atout en fait une
option de choix pour déployer des très grands nombres d’agents en parallèle. Par exemple, si
l’on voulait simuler des milliers d’agents (pour un jeu en ligne massivement multi-agent ou pour
tester des interactions sociales), Agno serait plus indiqué qu’un framework lourd. Il permettrait
d’avoir une concurrence massive d’agents sans exploser les ressources, ce que ne
supporteraient pas aisément d’autres solutions orientées davantage sur des agents isolés ou
peu nombreux. Côté fonctionnalités, Agno a la particularité de gérer par design plusieurs
modalités : texte, image, audio, etc. Un agent Agno peut ainsi recevoir des images en entrée ou
en produire en sortie s’il est branché à des modèles adéquats, sans bricolage additionnel – le
framework unifie ces traitements et permet à l’agent de planifier des actions multimodales
facilement. De plus, pour simplifier le déploiement, Agno peut générer automatiquement une
API (FastAPI) exposant les agents : en quelques lignes on peut déployer un agent en service
web. Le positionnement d’Agno est ainsi d’offrir une alternative « low-overhead » aux gros
frameworks, tout en ne sacrifiant pas la flexibilité. Il mise sur l’efficience (d’où son nom
évoquant l’agnosticisme vis-à-vis de la charge). En pratique, cela peut convenir pour des
applications embarquées, ou des scénarios de simulation de milliers d’agents (recherche en
économie artificielle, tests de policies, etc.), ou simplement pour des développeurs rebutés par la
complexité de LangChain souhaitant quelque chose de plus simple et rapide. Agno est plus
récent sur la scène, mais il témoigne d’une préoccupation grandissante pour la scalabilité des
agents à l’avenir.
SuperAGI
• SuperAGI – SuperAGI est un framework open-source né de la volonté de fournir une plateforme
« développeur first » pour créer des agents autonomes complets, de l’expérimentation au
déploiement. Il s’inscrit dans la lignée d’Auto-GPT mais en poussant plus loin l’aspect ingénierie
logicielle et intégration d’outils tiers. Avec SuperAGI, on peut développer un agent, le tester en
local puis le déployer en environnement cloud (Docker, etc.) relativement aisément. L’accent est
mis sur la gestion du cycle de vie de l’agent : SuperAGI propose par exemple la capacité de faire
tourner plusieurs agents en parallèle (avec isolation), de conserver leurs logs d’exécution pour
audit, et d’intégrer des mécanismes d’apprentissage itératif (les agents peuvent stocker des
informations en mémoire pour améliorer leurs performances sur la durée). Un point fort est la
multitude d’intégrations prêtes à l’emploi : SuperAGI fournit des connecteurs vers Slack, vers
Zapier (ce qui ouvre l’accès à des centaines d’applications), vers des outils comme Notion, Google
Drive, GitHub, etc.. On peut donc rapidement doter un agent de nombreuses capacités d’action
dans le monde réel (envoyer des messages, créer des tickets, lire des données en ligne…). C’est
un choix intéressant pour construire des agents d’entreprise ou assistants personnels augmentés.
Côté architecture, SuperAGI supporte la notion de concurrence (plusieurs agents ou plusieurs
actions concurrentes), et inclut un système de mémoire persistante (base de données) pour
11
que les agents conservent un état entre sessions. En revanche, il n’offre pas (du moins dans les
versions initiales) d’interface no-code ou de flows visuels – tout se configure en YAML/JSON ou en
code Python, ce qui le destine plutôt à des utilisateurs techniques. Son approche est d’ailleurs
très DevOps-friendly, avec support de GitHub Codespaces, de conteneurisation standard, etc.. En
somme, SuperAGI se veut une solution clé en main pour déployer des agents autonomes en
production, dotée des connecteurs et de l’infrastructure nécessaire pour passer de la démo à
l’application réelle. On peut le voir comme un cadre plus opérationnel là où d’autres frameworks
sont davantage des boîtes à outils modulaires.
(À noter : il existe encore d’autres frameworks et outils en périphérie – on pourrait citer par exemple DSPy
(Dynamic Sequence Planning) de Stanford qui explore les prompts auto-optimisés, Compositional AI pour
intégrer des centaines d’API facilement, ou des projets comme Camel ou Voyager orientés recherche – mais la
liste ci-dessus couvre les acteurs principaux connus à la date donnée.)
5. Applications pratiques des agents LLM
Les agents LLM trouvent des applications dans de nombreux secteurs industriels, en automatisant des
tâches complexes jusque-là difficiles à déléguer aux machines. Voici quelques cas d’usage réels
notables :
• Automatisation de flux de travail : Dans l’entreprise, des agents peuvent orchestrer des
enchaînements de tâches comme la collecte de données, leur analyse puis la génération de
rapports. Par exemple, un agent peut extraire des chiffres depuis différentes sources, les
consolider et produire un compte-rendu quotidien automatiquement. Ces assistants de workflow
réduisent l’intervention humaine sur des tâches répétitives et accélèrent les processus. On voit
émerger des intégrations d’agents LLM dans des outils de RPA (Robotic Process Automation) pour
rendre les automatisations plus adaptatives : l’agent peut décider de la suite du flux en fonction
des données rencontrées, là où un script RPA classique aurait bloqué. Cela permet d’automatiser
des processus métiers de bout en bout, y compris en gérant les exceptions de manière
intelligente.
• Service client intelligent : Des agents conversationnels avancés sont déployés pour améliorer
le support client. Grâce aux LLM, ils comprennent des requêtes variées et y répondent de façon
naturelle, allant au-delà des chatbots à scripts fixes. Ils peuvent résoudre en autonomie les
questions fréquentes (suivi de commande, dépannage basique, conseils produits…), tout en
détectant quand un cas dépasse leurs compétences pour transférer la conversation à un
opérateur humain avec un résumé du contexte. Ces agents sont souvent couplés à des bases de
connaissances internes de l’entreprise (par ex. via LlamaIndex) pour fournir des réponses fiables.
Le gain est double : disponibilité 24/7 et réponse instantanée pour le client, et réduction de la
charge routinière pour les centres d’appel. Des sociétés ont rapporté une baisse significative du
volume de tickets grâce à des agents LLM bien entraînés, tout en maintenant un haut taux de
satisfaction client.
• Assistants personnels et productivité : Dans la lignée des assistants vocaux (Siri, Alexa) mais
en beaucoup plus puissant, les agents LLM servent d’assistants personnels numériques pour les
professionnels. Par exemple, un agent connecté à votre agenda et à vos emails peut prendre des
initiatives comme proposer des créneaux de rendez-vous, rédiger un brouillon de réponse email,
prioriser votre liste de tâches quotidienne, voire effectuer des réservations (train, hôtel) selon
vos préférences. Ces agents comprennent le langage naturel (« Réserve un resto italien près
de l’adresse de la réunion de demain midi ») et effectuent les démarches nécessaires via les
outils en ligne. Ils peuvent aussi fournir un soutien à la décision : résumer des documents
12
longs, extraire les points d’action d’une réunion enregistrée, etc. Grâce à leur capacité
d’apprentissage (ils retiennent vos corrections ou choix passés), ils se personnalisent à
l’utilisateur. Des entreprises testent par exemple des agents secrétaires pour leurs cadres, qui
filtrent et pré-digestent l’information afin de faire gagner du temps. On peut également citer le
grand public avec des apps qui utilisent GPT-4 pour coacher l’utilisateur (forme physique,
finances personnelles, etc.) en automatisant la collecte d’infos et en fournissant des plans
d’action.
• RPA intelligent et automatisation industrielle : Dans le domaine de l’automatisation de
processus (RPA), l’apport des agents LLM est de rendre ces processus moins « rigides ». Un bot
RPA traditionnel exécute bêtement des instructions (remplir tel formulaire, copier coller tel
champ), ce qui échoue dès qu’il y a la moindre variation non prévue. Un agent LLM, lui, peut
s’adapter – parce qu’il comprend en partie ce qu’il fait. Par exemple, pour traiter des e-mails
entrants, un agent peut les lire en langage naturel, classer l’intention (demande de
remboursement, nouvelle commande, plainte…), extraire les données pertinentes puis
déclencher les bonnes actions dans le système (créer un ticket de support, enregistrer la
commande…). S’il tombe sur un cas ambigu, il peut solliciter une clarification (auprès du client ou
d’un opérateur). Ainsi, on obtient des automatisations plus robustes aux aléas du contenu non
structuré. Dans l’industrie, on expérimente des agents pour la supervision d’atelier : un agent
LLM reçoit les logs machines en continu et peut converser avec un technicien en langage naturel
tout en lui fournissant les données clés ou les alertes issues des systèmes (une sorte d’agent
cockpit intelligent). D’autres exemples incluent des agents gérant automatiquement des mises à
jour de bases de données, le provisioning de ressources IT en lisant des demandes en langage
naturel, etc., ce qui fluidifie beaucoup les opérations.
• Recherche scientifique et analytique : La masse d’informations scientifiques et de données à
analyser est telle que des agents LLM commencent à être utilisés comme aides chercheurs. Par
exemple, un agent peut prendre en entrée une question scientifique précise, fouiller à travers
des centaines de publications (via des outils d’API à des bibliothèques numériques), extraire les
résultats pertinents et fournir un rapport synthétique citant les sources. Des chercheurs en
biologie utilisent des agents pour automatiser la revue de littérature sur un sujet donné, ce qui
leur fait gagner un temps immense en pré-analyse. En finance ou en intelligence économique,
on voit des agents passer au crible des flux d’actualités ou de rapports, extraire les faits saillants
et les mettre en perspective (un peu comme un analyste junior le ferait). Couplés avec des
capacités de calcul (par ex. via Python), les agents peuvent aussi réaliser des analyses de
données exploratoires : on leur donne un jeu de données et une question (« trouve les
corrélations notables et fais un résumé »), ils vont tester plusieurs approches et rendre compte.
Bien sûr, l’humain valide derrière, mais cela accélère l’exploration. On peut imaginer à terme
des agents spécialisés par domaine scientifique, qui collabore avec un chercheur humain en
prenant en charge toutes les tâches pénibles (recherches biblio, agrégation de données) pour le
laisser se concentrer sur l’interprétation et la stratégie.
• Développement logiciel assisté : Un cas d’usage émergent et très prometteur est celui
d’agents pour la programmation. On connaît déjà GitHub Copilot qui, intégré à un IDE,
suggère du code. Les agents LLM vont plus loin : ils peuvent être chargés de tâches entières de
développement. Par exemple, l’agent Devin de la société Cognition Labs est présenté comme un
« AI software engineer » capable de planifier et d’exécuter des tâches de codage complexes
nécessitant des milliers de décisions, tout en maintenant une compréhension du contexte global
du projet. Concrètement, Devin peut lire la spécification d’une fonctionnalité, écrire le code
correspondant, l’exécuter et le tester, détecter les bugs et les corriger, en boucle, et finalement
proposer la modification au dépôt de code. Il utilise pour cela un environnement outillé : accès à
13
un terminal, à un éditeur de code, à un navigateur web – c’est-à-dire tous les outils qu’un
développeur humain utiliserait – au sein d’un bac à sable sécurisé. Devin peut également
collaborer activement avec l’humain pendant le processus, en fournissant des comptesrendus sur ce qu’il fait et en sollicitant des validations ou des préférences lorsque nécessaire. On
voit ici un agent qui orchestre GPT-4 avec des capacités techniques réelles pour accomplir une tâche
de programmation de A à Z. De tels agents pourraient radicalement transformer le
développement logiciel en prenant en charge la réalisation de modules entiers ou la
maintenance de code existant (ex. corriger automatiquement des issues GitHub). D’autres
expérimentations incluent des agents qui programment des scripts d’automatisation en
écoutant les besoins d’un utilisateur (projet GPT-Engineer), ou qui apprennent à améliorer un
code base en itérant (un agent qui relit et optimise le code en continu). Si ces outils tiennent
leurs promesses, ils pourraient augmenter considérablement la productivité des équipes de
développement et abaisser la barrière de la programmation pour non-experts.
6. Exemples notables d’agents LLM
Plusieurs agents spécifiques ont retenu l’attention du public et des professionnels par leurs capacités
ou le concept qu’ils démontrent. En voici quelques-uns :
• Auto-GPT : C’est l’agent autonome qui a fait sensation au printemps 2023. Son code open-source
a été largement repris et expérimenté par des utilisateurs cherchant à « donner une mission » à
GPT-4. Par exemple, Auto-GPT a été testé sur des missions comme « améliorer ma présence en
ligne » ou « trouver des idées de produit et les prototyper ». Il suivait alors une boucle où GPT-4, se
parlant à lui-même, générait des plans, utilisait des outils (recherche web, lecture de fichier, etc.),
et ajustait sa stratégie. Auto-GPT a montré de façon tangible ce que pouvait (et ne pouvait pas
encore) faire un agent LLM grand public. De nombreux utilisateurs ont été impressionnés par le
fait qu’il parvienne à accomplir des sous-tâches utiles de manière autonome. D’autres ont noté
ses limites : sans guidage, il pouvait tourner en rond ou produire des résultats superficiels. Quoi
qu’il en soit, il a amorcé une véritable tendance des “GPT autonomes”, et son nom est souvent
utilisé génériquement pour désigner toute expérimentation d’LLM se comportant en agent autoitératif.
• BabyAGI : Plus conceptuel, BabyAGI a été important pour la communauté tech car il a fourni une
base simple pour expérimenter. De nombreux tutoriels ont fleuri autour de BabyAGI afin
d’expliquer comment fonctionnent la génération de tâches et la priorisation automatique. Des
variantes ont été créées (par ex. BabyCat pour des tâches plus créatives, etc.). BabyAGI reste un
agent d’apprentissage, sans compétence spécialisée en soi, mais il a inspiré l’architecture de
multiples projets subséquents. On peut dire qu’il a servi de « preuve de concept » minimale pour
l’idée d’une AGI itérative pilotée par LLM, ce qui est en soi un concept fondateur pour
beaucoup de développements actuels. Même si BabyAGI n’est pas utilisé en production, ses
idées vivent au travers d’autres agents.
• Devin (Cognition) : Présenté par la startup Cognition Labs en 2024, Devin se veut le premier
agent LLM réellement performant dans un contexte de développement logiciel. Les
démonstrations publiées montrent Devin en train de réaliser des tâches comme apprendre à
utiliser une nouvelle librairie graphique et produire du code utilisant cette librairie, ou contribuer
à un vrai projet open-source en corrigeant un bug complexe. Techniquement, Devin se distingue
par ses capacités en planification à long terme et en mémoire contextuelle : il peut garder en
tête le plan général du logiciel pendant qu’il code, et se rappeler d’éléments précédemment vus
dès que pertinent. De plus, il utilise de vrais outils de dev (il peut lancer une suite de tests
14
unitaires et interpréter leurs résultats, naviguer sur StackOverflow si besoin, etc.), ce qui en fait
un agent ancré dans la réalité du développement. Lors de son lancement, Devin a suscité des
réactions mitigées : fascination devant les tâches réussies, scepticisme sur sa généralisation. Il
n’en reste pas moins un exemple emblématique d’agent spécialisé très avancé, qui préfigure
potentiellement l’assistant développeur du futur. Des éditeurs comme Microsoft (avec GitHub
Copilot X) ou Amazon (CodeWhisperer) explorent aussi la voie de l’agent de dev capable d’agir
sur le code, et pas seulement de suggérer du code.
• HuggingGPT (alias Jarvis) : HuggingGPT est le surnom d’une expérimentation présentée par
Microsoft Research qui a marqué les esprits sur la combinaison de modèles d’IA. L’idée directrice
est d’utiliser un LLM (en l’occurrence GPT-4/ChatGPT) comme contrôleur universel pour
orchestrer une multitude de modèles spécialisés disponibles sur Hugging Face 5 . Dans la
démonstration surnommée Jarvis, l’agent reçoit une requête complexe pouvant impliquer du
texte, de l’image, du son, etc., et va décomposer la tâche : par exemple, si l’utilisateur dit «
Décris-moi cette image puis traduis la description en français », l’agent Jarvis va identifier qu’il lui
faut un modèle de vision pour décrire l’image, puis un modèle de traduction, qu’il va aller
chercher sur Hugging Face (parmi les modèles publiés) en lisant leurs descriptions, les exécuter
l’un après l’autre, et enfin composer la réponse finale 5 . Tout cela est planifié par le LLM luimême, qui comprend la demande et sait quelles capacités externes invoquer. HuggingGPT
illustre une architecture agentielle modulaire où le LLM est le cerveau qui sait parler à
différents modules experts via une simple interface langage (il formate des prompts pour
chaque modèle outil). Les résultats ont montré qu’une telle approche pouvait résoudre des
tâches multimodales complexes en obtenant des performances impressionnantes en vision,
langage et audio, alors même que le LLM seul ne sait pas traiter d’images ou de son 5 .
HuggingGPT ouvre la voie à des agents généraux qui fédèrent les modèles open-source
disponibles : plutôt que d’attendre un modèle monolithique omnipotent, on peut avoir un agent
qui sait utiliser les bonnes ressources de la communauté ML en fonction du besoin. Depuis, on
voit des prototypes d’agents qui, sur le même principe, orchestrent par exemple des APIs (Plugin
GPT chez OpenAI, qui fait office d’agent orchestrateur entre plugins). C’est un axe de
développement prometteur pour atteindre une forme d’intelligence artificielle générale
distribuée, en combinant les forces de multiples systèmes.
• Voyager : Dans le registre de la recherche, Voyager est un agent LLM incarné dans
l’environnement du jeu Minecraft, révélé en 2023, qui mérite d’être mentionné car il démontre
l’apprentissage en continu d’un agent. Voyager utilise GPT-4 non pas pour converser avec un
humain, mais pour générer du code Python qu’il exécute dans Minecraft afin d’y accomplir
des tâches (se déplacer, construire des objets, etc.). Surtout, Voyager est doté d’un mécanisme de
« skill library » : à chaque fois qu’il découvre comment faire quelque chose d’utile (par exemple
crafter un outil, ou naviguer sur l’eau), il stocke le code correspondant dans sa bibliothèque de
compétences, indexé de manière à pouvoir le réutiliser plus tard dans une situation similaire 6
7 . Il suit un curriculum automatique qui l’incite à explorer toujours plus loin et à apprendre de
nouvelles choses sans intervention humaine. Cette approche lui a permis d’atteindre en
autonomie des performances bien supérieures aux agents basés sur l’apprentissage par
renforcement traditionnels dans Minecraft 8 . On a là un exemple d’agent LLM qui s’améliore
en continu, accumulant du savoir-faire au fil du temps et devenant de plus en plus compétent.
Voyager préfigure des agents capables de se gérer eux-mêmes sur le long terme : on pourrait
imaginer des agents similaires dans des domaines réels, qui apprennent jour après jour de leurs
interactions et construisent leur propre base de connaissances opérationnelles. Pour l’heure,
Voyager reste confiné à Minecraft, mais des idées similaires (agents codeurs-solveurs apprenant
de leur propre code) sont explorées dans la robotique notamment.
15
7. Exemples de code en Python pour agents LLM
Pour mieux comprendre concrètement le fonctionnement des agents LLM, examinons quelques extraits
de code simplifiés utilisant différentes librairies. Ces exemples illustrent comment un agent peut utiliser
des outils, appeler des APIs ou planifier des actions de façon autonome. (Les commentaires dans le
code expliquent chaque étape ; on assume que les clés API nécessaires sont configurées si besoin.)
Exemple 1 : Assistant de recherche web
Dans cet exemple, on utilise la librairie LangChain pour créer un agent capable d’effectuer une
recherche sur le web afin de répondre à une question de l’utilisateur. On définit un outil personnalisé
RechercheWeb (ici simulé) que l’agent pourra appeler lorsqu’il a besoin d’informations externes :
from langchain.agents import initialize_agent, Tool
from langchain.llms import OpenAI
# Définir une fonction outil pour la recherche web (simulée pour cet exemple)
def web_search(query: str) -> str:
# Ici on simulerait un appel à une API de moteur de recherche ou un
scraping web.
# Par exemple, on pourrait interroger l'API de Wikipedia ou Google Custom
Search.
return f"Résultats de recherche simulés pour '{query}'"
# Créer l'outil de recherche web pour l'agent
search_tool = Tool(
name="RechercheWeb",
func=web_search,
description="Effectue une recherche web pour trouver des informations
pertinentes."
)
# Initialiser le modèle de langage (ex: GPT-3.5 ou GPT-4 via OpenAI API) et
l'agent avec l'outil défini
llm = OpenAI(temperature=0) # suppose qu'une clé API OpenAI est déjà
configurée dans l'environnement
agent = initialize_agent([search_tool], llm, agent="zero-shot-reactdescription", verbose=True)
# Poser une question à l'agent nécessitant une recherche externe
question = "Quelle est la capitale de la France et combien d'habitants y
vivent ?"
response = agent.run(question)
print(response)
Explication : Ici, initialize_agent crée un agent selon le paradigme ReAct (Reason + Act) à partir
du LLM fourni et de la liste d’outils disponibles. Lorsque nous exécutons agent.run(question) ,
l’agent va analyser la question « Quelle est la capitale de la France et combien d'habitants y vivent ? ». Le
16
LLM va raisonner en se disant qu’il faut d’abord trouver la capitale (Paris) puis la population, et constater
qu’il a besoin de rechercher ces informations. Il va alors produire quelque chose comme : Action :
RechercheWeb, avec la requête « capitale France population ». Notre fonction web_search simule la
réponse en texte (dans un cas réel, elle contacterait une API web et retournerait un extrait de résultats).
L’agent récupère cette réponse, la passe en entrée du LLM à nouveau, qui peut alors formuler la
réponse finale en combinant les informations trouvées. Par exemple, l’agent pourrait répondre : « La
capitale de la France est Paris, qui compte environ 2,1 millions d’habitants intra-muros. ».
Cet exemple montre comment un agent peut intégrer une recherche web dans son processus pour
compléter ses connaissances, le tout de façon transparente pour l’utilisateur (qui n’a posé qu’une
question naturelle). Le verbose=True permet de voir les étapes de réflexion de l’agent (traces du prompt
ReAct) lors de l’exécution, utile pour débugger la manière dont l’agent décide d’utiliser l’outil.
Exemple 2 : Interaction avec une API externe
Considérons maintenant un agent qui doit interroger une API météo pour répondre à l’utilisateur. On
pourrait ici démontrer le mécanisme de function calling de l’API OpenAI, mais pour la simplicité on reste
avec LangChain et un outil personnalisé. Nous définissons un outil MeteoAPI qui, donné le nom d’une
ville, retourne la météo actuelle (dans un vrai scénario, il ferait une requête HTTP à un service météo tel
que OpenWeatherMap). L’agent utilisera cet outil pour obtenir la réponse :
from langchain.agents import initialize_agent, Tool
from langchain.llms import OpenAI
import requests
# Définir une fonction outil pour obtenir la météo d'une ville (appel API
simulé)
def get_weather(city: str) -> str:
# Normalement, on appellerait une vraie API météo ici, par ex :
# response = requests.get(f"https://api.meteo.com/current?city={city}
&key=...")
# puis parser le JSON.
# On simule une réponse formatée :
return f"Météo à {city} : 15°C, ciel ensoleillé."
# Créer l'outil météo pour l'agent
weather_tool = Tool(
name="MeteoAPI",
func=get_weather,
description="Donne la météo actuelle pour une ville donnée."
)
# Initialiser l'agent avec l'outil défini
llm = OpenAI(temperature=0)
agent = initialize_agent([weather_tool], llm, agent="zero-shot-reactdescription", verbose=False)
# Poser une question qui nécessite d'appeler l'API météo
question = "Peux-tu me dire le temps qu'il fait actuellement à Paris ?"
17
reponse = agent.run(question)
print(reponse)
Explication : Ici, lorsque l’agent traite la question, il détecte qu’il s’agit de météo et comprend (via le
prompt ReAct interne) qu’il dispose de l’outil MeteoAPI pour y répondre. Il va donc appeler
get_weather("Paris") . Notre implémentation renvoie une chaîne simulant la météo. Le LLM prend
ce texte et génère la phrase finale pour l’utilisateur, par exemple : « À Paris, il fait actuellement 15°C et le
ciel est ensoleillé. ».
Cet exemple illustre l’intégration d’une API tierce dans un agent. En pratique, on aurait mis un appel
réel via requests.get dans get_weather et on aurait peut-être formaté proprement la réponse.
Ce qui compte, c’est que l’agent sait quand et comment utiliser l’API. Grâce à la description fournie pour
l’outil, le LLM comprend son usage. Ce genre de schéma se généralise à toute API : par exemple, on
pourrait avoir un outil EncyclopedieAPI pour interroger une encyclopédie en ligne, un outil BDD
pour faire des requêtes en base de données, etc., et l’agent choisira l’outil approprié en fonction de la
question ou de l’étape courante de son plan.
(Note : OpenAI propose un mécanisme équivalent sans passer par LangChain, en définissant une fonction
get_weather comme une fonction disponible dans l’appel à l’API chat. Le modèle GPT-4 peut alors tout
seul décider d’appeler la fonction et incorporer son résultat avant de répondre. Dans le contexte de ce rapport,
nous avons choisi LangChain pour la concision du code, mais les principes sont analogues.)
Exemple 3 : Agent planificateur multi-étapes (type BabyAGI)
Pour illustrer le fonctionnement d’un agent planificateur capable d’enchaîner plusieurs actions de
manière autonome, examinons un pseudo-code inspiré de BabyAGI. Cet agent reçoit un objectif général
et génère lui-même les tâches successives pour atteindre cet objectif, en s’adaptant aux résultats
obtenus au fur et à mesure :
import openai
# (Pseudo-code) Fonction utilitaire pour appeler un LLM OpenAI avec un prompt
donné
def appeler_llm(prompt: str) -> str:
reponse = openai.ChatCompletion.create(
model="gpt-4-0613",
messages=[{"role": "user", "content": prompt}]
)
return reponse["choices"][0]["message"]["content"]
# Objectif global de l'agent
objectif = "Rédiger un résumé des effets du changement climatique sur la
production viticole mondiale."
# Initialiser la liste des tâches avec une première tâche découlant de
l'objectif
taches = ["Collecter des données récentes sur la production viticole et le
climat"]
# Boucle d'exécution autonome de l'agent planificateur
18
while taches:
tache_actuelle = taches.pop(0)
# 1. Exécution de la tâche actuelle à l'aide du LLM (par ex., effectuer
une recherche ou une analyse)
prompt_exec = f"Exécute la tâche suivante : {tache_actuelle}. Donne le
résultat en détail."
result = appeler_llm(prompt_exec)
# (On supposerait ici que l'agent utilise éventuellement des outils de
recherche web, etc., via son prompt)
# 2. Analyse du résultat et génération de nouvelles tâches en découlant
prompt_new = (
f"En te basant sur l'objectif '{objectif}' et les résultats
obtenus : {result} \n"
f"Propose les prochaines tâches à effectuer pour atteindre l'objectif (liste
bullet point)."
)
nouvelles_taches_txt = appeler_llm(prompt_new)
# 3. Parser la réponse du LLM pour extraire la liste de nouvelles tâches
(chaque tiret devient un élément)
nouvelles_taches = [ligne.strip("- ") for ligne in
nouvelles_taches_txt.split("\n") if ligne.startswith("-")]
taches.extend(nouvelles_taches)
# 4. (Optionnel) Prioritiser la liste des tâches restantes (pseudo-code)
# taches = prioriser_par_pertinence(taches, objectif)
# Boucle jusqu'à ce qu'il n'y ait plus de tâches ou qu'on juge l'objectif
atteint
Explication : Cet agent commence avec un objectif (ici, résumer l’effet du climat sur la viticulture
mondiale) et en déduit une première tâche évidente : collecter des données. Il exécute cette tâche en
demandant au LLM de le faire (dans la pratique, le LLM pourrait utiliser son entraînement ou un outil
pour chercher des infos). Supposons qu’il obtienne en résultat des statistiques par région. Ensuite,
l’agent demande au LLM de générer les prochaines tâches à partir de ce qui a été appris : peut-être «
Analyser l’impact en Europe », « Analyser l’impact en Amérique », « Comparer les tendances entre continents ».
Ces nouvelles tâches sont ajoutées à la liste. L’agent reprend la boucle avec la première nouvelle tâche,
et ainsi de suite. Finalement, on peut imaginer qu’une tâche générée sera « Écrire le résumé final », qui,
exécutée, produira le rapport souhaité.
Cet exemple, inspiré du fonctionnement de BabyAGI, montre un agent qui s’auto-organise : il génère et
adapte son plan en temps réel. Il n’y a pas de condition d’arrêt explicite dans ce pseudo-code, mais on
pourrait en ajouter (par exemple, arrêter après un certain nombre d’itérations ou lorsque la tâche «
produire le résumé » a été exécutée). On voit également que toute la logique repose sur des appels
successifs au LLM avec des prompts appropriés : l’agent n’a pas de boucle interne sophistiquée, il utilise
l’IA elle-même pour décider des tâches (c’est la notion de « let the model think itself »). C’est puissant,
mais cela requiert de bien concevoir ces prompts pour éviter que l’agent ne parte dans des directions
non pertinentes.
19
En pratique, des implémentations plus robustes utilisent des vecteurs de mémoire pour stocker chaque
résultat result de tâche et permettre au LLM d’y faire référence lors de la création des nouvelles
tâches (éviter les redites par exemple). On peut également demander au LLM de prioriser les tâches (ce
qu’on a laissé en option en étape 4). L’important à noter est la simplicité du squelette : une boucle,
deux appels LLM (exécution, puis planification) et une gestion de liste. C’est ce qui a permis à beaucoup
de développeurs de comprendre et d’adapter ce genre d’agent à divers objectifs.
En conclusion, les agents LLM représentent une évolution majeure dans l’utilisation des modèles de
langage, en les transformant d’outils passifs de conversation en acteurs autonomes capables de
percevoir, décider et agir. Leurs applications sont vastes – de l’automatisation industrielle à l’assistance
personnelle – et les progrès réalisés entre 2023 et 2025 laissent entrevoir que ces agents deviendront
des composantes centrales des projets d’IA avancés. Les exemples de code ci-dessus illustrent
comment, avec quelques bibliothèques bien choisies, on peut déjà prototyper de tels agents. Les
frameworks comme ceux présentés (LangChain, AutoGPT, AgentVerse, etc.) offrent des bases solides
pour construire des solutions sur mesure, tandis que les avancées en cours (intégration plus fine des
outils, protocoles multi-agents, sécurité renforcée) continueront de fiabiliser et d’enrichir ces agents.
L’ère des agents LLM ne fait que commencer, mais elle a été amorcée pour répondre à un besoin clair :
orchestrer l’intelligence artificielle de manière à ce qu’elle fasse réellement des choses utiles dans le
monde réel, de façon autonome et collaborative. Les entreprises, à travers des POC et déploiements,
explorent activement cette voie pour gagner en efficacité et en innovation dans leurs processus. Nous
pouvons donc nous attendre à ce que les agents LLM s’installent durablement comme un nouveau
paradigme de l’IA appliquée.
Références : Les informations de ce rapport s’appuient sur la documentation des frameworks cités, des
articles de recherche (par ex. sur HuggingGPT 5 ou Voyager 6 7 ) et des analyses de la communauté
(blogs techniques, Medium, etc.) publiés en 2023-2025. Toutes les sources utilisées sont indiquées sous
forme de citations numérotées tout au long du texte.
1
2
3
4
Top 10 Open-Source AI Agent Frameworks of May 2025 | APIpie
https://apipie.ai/docs/blog/top-10-opensource-ai-agent-frameworks-may-2025
5
[2303.17580] HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face
https://arxiv.org/abs/2303.17580
6
7
8
Voyager | An Open-Ended Embodied Agent with Large Language Models
https://voyager.minedojo.org/
20