Comprendre ce qu'est un agent IA, c'est bien. Comprendre comment il fonctionne, c'est ce qui vous permettra de le déployer intelligemment, de calibrer les attentes, et d'éviter les mauvaises surprises.
Cet article s'adresse à ceux qui veulent aller un cran plus loin : DSI, responsables IT, architectes SI, tech leads. Pas besoin d'être développeur pour suivre, il faut juste accepter d'ouvrir le capot.
Pour cela, nous allons passer en revue les 5 composants fondamentaux d’un agent IA, comprendre les patterns et comparer des agents simple à des systèmes multi-agents. C’est parti !
Les 5 composants fondamentaux d'un agent IA
💡Les cinq composants d'un agent IA en une ligne chacun :
- Le LLM : le moteur de raisonnement qui décide quoi faire ensuite.
- La mémoire : ce que l'agent retient, dans la session et entre les sessions.
- Les outils : les fonctions qu'il peut appeler pour agir dans le monde réel.
- Le planificateur : ce qui décompose un objectif complexe en étapes exécutables.
- Le module d'évaluation : ce qui vérifie si le résultat obtenu correspond à ce qui était attendu.
Un agent IA n'est pas un logiciel monolithique, mais plutôt un assemblage de briques, chacune avec un rôle précis. Comprendre chaque brique, c'est comprendre pourquoi l'agent fait ce qu'il fait, et pourquoi il échoue quand il échoue.
Le LLM : le moteur de raisonnement
Le LLM (Large Language Model, ou grand modèle de langage) est le cerveau de l'agent. C'est lui qui lit l'objectif, évalue la situation, choisit la prochaine action à mener et génère les instructions pour les autres composants.
Ce point mérite d'être souligné : le LLM ne produit pas seulement du texte puisqu’il raisonne aussi. Un agent se demande "qu'est-ce que je dois faire ensuite pour avancer vers l'objectif ?" à chaque itération de la boucle.
Deux limites sont importantes à avoir en tête dès le départ :
Les hallucinations : le LLM peut produire des informations incorrectes avec une apparente confiance. Dans un contexte de génération de texte, c'est gênant. Dans un contexte d'action (déclencher une relance, modifier une fiche, envoyer un email), c'est potentiellement problématique. La gouvernance de votre CRM et de votre IA commence ici.
La fenêtre de contexte : le LLM ne peut traiter qu'une quantité limitée d'informations à la fois. Sur des tâches longues ou complexes, les premières instructions peuvent "sortir" du contexte actif.
La mémoire
C'est la brique la plus sous-estimée. Et pourtant, c'est elle qui détermine si l'agent est vraiment utile dans la durée ou s'il repart de zéro à chaque session.
Il existe deux niveaux de mémoire :
La mémoire à court terme correspond au contexte de la session en cours. Tout ce que l'agent "sait" dans l'instant : l'objectif reçu, les actions déjà menées, les résultats obtenus. Elle disparaît à la fin de la session.
La mémoire à long terme persiste entre les sessions. Elle est stockée dans une base de données externe : historique des interactions, documents de référence, préférences, données métier. L'agent y accède en interrogeant la base au moment où il en a besoin.
La technologie qui rend la mémoire longue terme possible à grande échelle, est le RAG (Retrieval-Augmented Generation). Au lieu de tout charger dans le contexte (impossible au-delà d'un certain volume), l'agent récupère uniquement les informations pertinentes au moment où il en a besoin.
💡 Sans mémoire persistante, chaque session recommence à zéro. L'agent ne sait pas que vous lui avez déjà posé cette question. Il ne sait pas ce qu'il a fait hier. C'est l'équivalent d'un collaborateur qui perd toute sa mémoire chaque soir en rentrant chez lui.
Les outils
C'est la brique qui transforme l'agent en acteur. Sans outils, le LLM produit du texte. Avec des outils, il peut agir. Un outil, concrètement, est une fonction que l'agent peut appeler pour interagir avec le monde réel :
Lire ou écrire dans un CRM
Envoyer un email
Naviguer sur le web
Exécuter du code
Interroger une base de données
Appeler une API externe
Le mécanisme s'appelle tool calling ou function calling : le LLM décide qu'il a besoin d'un outil, l'appelle avec les bons paramètres, récupère le résultat, et continue son raisonnement. C'est ce qui distingue fondamentalement un agent d'un LLM seul.
Le planificateur
Pour un objectif simple ("envoie un email de confirmation à ce contact"), l'agent n'a pas besoin de planifier. Il appelle directement l'outil email et c'est fait.
Pour un objectif complexe ("identifie les dix prospects les plus chauds de ce trimestre, prépare une séquence de relance personnalisée pour chacun, et planifie les envois sur deux semaines"), c'est différent. Il faut décomposer, séquencer, parfois paralléliser.
C'est le rôle du planificateur. Il traduit un objectif de haut niveau en une liste de sous-tâches ordonnées et exécutables. Deux approches coexistent selon les architectures :
Plan-and-execute : l'agent établit un plan complet avant de commencer à agir, puis l'exécute étape par étape. Prévisible, mais rigide si la situation évolue en cours de route.
ReAct (Reasoning + Acting) : l'agent alterne en continu entre raisonnement et action, sans plan préétabli. Plus flexible, mais moins prévisible. C'est le pattern de référence aujourd'hui.
Le module d'évaluation
Une fois une action menée, quelqu'un doit vérifier si elle a atteint son objectif. C'est le module d'évaluation. Il répond à trois questions :
Le résultat obtenu correspond-il à ce qui était attendu ?
Faut-il continuer, corriger, ou s'arrêter ?
Cette situation nécessite-t-elle une validation humaine ?
ReAct est l'acronyme de Reasoning + Acting. Ce pattern a été formalisé par des chercheurs de Google en 2022. Il est aujourd'hui le standard de facto pour la plupart des agents IA déployés en production. Le principe est simple, l'agent alterne en continu entre deux modes :
Reasoning : il réfléchit à voix haute (dans son contexte interne) sur ce qu'il sait, ce qu'il doit faire, et pourquoi.
Acting : il appelle un outil, observe le résultat, et recommence.
Cette alternance continue jusqu'à ce que l'objectif soit atteint ou qu'une condition d'arrêt soit déclenchée.
Pour aller plus loin dans la compréhension du fonctionnement des agents IA avec le ReAct, je vous invite à visionner cette courte vidéo.
Exemple de boucle ReAct pas à pas
Prenons un cas concret : un agent dont l'objectif est d'analyser les performances des points de vente sur la dernière promotion de fin d'année, puis de les classer en valeur et en volume.
Étape 1 - Reasoning : "Mon objectif est de qualifier les points de vente les plus performants sur la promotion fêtes. Je dois d'abord récupérer les données de vente sur la période concernée dans le CRM."
Étape 1 - Acting : appel de l'outil CRM, extraction des données de vente par point de vente sur la période promotionnelle définie.
Étape 2 - Reasoning : "J'ai les données brutes. Certains points de vente ont des données incomplètes ou manquantes. Je dois nettoyer le jeu de données avant de pouvoir calculer des indicateurs fiables."
Étape 2 - Acting : détection et traitement des données manquantes, normalisation des formats, exclusion des points de vente sans activité sur la période.
Étape 3 - Reasoning : "Les données sont propres. Je peux maintenant calculer deux classements distincts : un en chiffre d'affaires généré, un en volume d'unités vendues. Ces deux lectures peuvent donner des résultats différents et complémentaires."
Étape 3 - Acting : calcul des indicateurs de performance par point de vente, génération des deux classements (valeur et volume), identification des points de vente dans le top 20% sur les deux axes.
Étape 4 - Reasoning : "Les classements sont prêts. Je dois maintenant produire une synthèse exploitable pour le manager : les points de vente qui performent sur les deux axes, ceux qui performent sur un seul, et les enseignements à retenir pour la prochaine opération."
Étape 4 - Acting : génération du rapport structuré, création d'une tâche assignée au responsable trade marketing avec le fichier en pièce jointe.
Étape 5 - Reasoning : "Le rapport est produit et transmis. L'objectif est atteint."
Fin de boucle.
💡 Ce qui est notable ici : l'agent ne s'est pas contenté d'extraire des données. Il a raisonné sur leur qualité, décidé de les nettoyer avant d'aller plus loin, et produit deux lectures complémentaires sans qu'on le lui ait explicitement demandé. C'est la différence entre un export CRM et un agent qui travaille.
Les limites du pattern ReAct
ReAct est puissant mais il n'est pas parfait. Voici 3 limites notables :
Le risque de boucle infinie. Si l'objectif est mal défini ou si l'agent ne trouve pas de condition d'arrêt claire, il peut continuer d'itérer indéfiniment. Il faut toujours définir un nombre maximum d'itérations.
Le coût en tokens. Chaque itération de la boucle consomme des tokens, donc du temps et de l'argent. Sur des tâches très complexes avec de nombreuses itérations, le coût peut devenir significatif.
L'imprévisibilité. Contrairement à un script, ReAct ne produit pas toujours le même chemin pour le même objectif. C'est une force (flexibilité) et une faiblesse (reproductibilité limitée)
Agent simple vs système multi-agents
Agent simple : quand ça suffit
Un agent simple est un seul agent, qui a un objectif bien délimité, sur un ensemble d'outils restreint. Il fonctionne en séquence, sans délégation. C'est le bon choix pour :
Les tâches linéaires avec un périmètre bien défini
Les situations où le risque d'erreur doit rester faible et contrôlable
Les premiers déploiements, avant d'aller vers plus de complexité
Systèmes multi-agents : quand la complexité le justifie
Dans un système multi-agents, plusieurs agents spécialisés coopèrent, coordonnés par un agent orchestrateur. Chaque agent a un rôle précis : l'un collecte des données, un autre les analyse, un troisième rédige le rapport, un quatrième l'envoie.
Les avantages des multi-agents sont :
La parallélisation : plusieurs tâches s'exécutent en même temps.
La spécialisation : chaque agent est optimisé pour son rôle.
La résilience : si un agent échoue, l'orchestrateur peut rerouter.
Voici quelques frameworks open-source qui permettent de construire ces architectures : AutoGen (Microsoft), CrewAI, LangGraph.
Alors, comment choisir entre les deux ? Si la tâche peut être découpée en sous-tâches parallèles avec des expertises différentes, le multi-agents se justifie. Sinon, un agent simple bien conçu est presque toujours préférable.
Agent IA vs pipeline classique vs RPA
C'est une question que se posent tous les DSI au moment d'évaluer l'IA agentique : est-ce vraiment différent de ce qu'on a déjà ?
Oui, et voici pourquoi.
💡RPA est l'acronyme de Robotic Process Automation, soit "automatisation robotisée des processus" en français. Une RPA est un logiciel qui imite les actions d'un humain sur un ordinateur : cliquer sur des boutons, copier-coller des données, remplir des formulaires, naviguer entre des applications.
Dimension
RPA
Pipeline classique
Agent IA
Flexibilité
Faible (règles rigides)
Faible (étapes prédéfinies)
Forte (s'adapte aux situations imprévues)
Gestion des exceptions
Nulle (bloque ou échoue)
Limitée (chemins alternatifs prédéfinis)
Forte (raisonne sur l'exception)
Capacité de raisonnement
Aucune
Aucune
Oui (LLM)
Dépendance aux règles
Totale
Totale
Partielle
Coût de maintenance
Élevé (fragile aux changements d'interface)
Modéré
Faible si bien conçu
Cas d'usage idéal
Tâches répétitives sur interfaces fixes
Traitements de données structurées
Tâches complexes avec variabilité
💡 La RPA fait ce qu'on lui dit, exactement comme on le lui dit. L'agent IA comprend ce qu'on veut, et trouve comment le faire.
Quand choisir quoi :
RPA : tâches très répétitives, interfaces stables, zéro variabilité, budget limité. Exemple : extraction automatique de données d'une facture PDF vers un ERP.
Pipeline classique : traitements de données structurées, flux prévisibles, besoin de reproductibilité. Exemple : transformation et chargement de données entre deux bases.
Agent IA : tâches complexes avec variabilité, besoin de raisonnement, exceptions fréquentes. Exemple : qualification de leads entrants avec enrichissement et routing intelligent.
Ce qu'il faut avoir en place avant de déployer un agent IA
Comprendre l'architecture ne suffit pas. Le déploiement réel exige des prérequis précis. Négliger cette étape, c'est la principale source d'échec.
Prérequis techniques
Des données structurées et accessibles. C'est le prérequis non négociable. Un agent bien conçu sur de mauvaises données produit de mauvaises actions. Avant de déployer, auditez la qualité des données que l'agent va consommer.
Des APIs exposées et documentées. L'agent a besoin d'appeler des outils. Si vos systèmes ne disposent pas d'APIs accessibles, l'agent ne peut pas agir. C'est un point de blocage fréquent dans les environnements legacy.
Un système de logging. Toutes les actions de l'agent doivent être tracées : entrée, raisonnement, action, résultat. Sans logs, impossible de superviser, d'auditer ou de corriger.
Une infrastructure capable de gérer la latence. Une boucle ReAct avec plusieurs itérations prend du temps. Sur des tâches critiques, la latence peut être un problème. Cela est donc à anticiper dans la conception.
Prérequis organisationnels
Un objectif précis. Un objectif flou produit un agent erratique. "Améliore la relation client" n'est pas un objectif pour un agent. "Relance automatiquement les leads sans activité depuis 14 jours avec un message personnalisé selon leur secteur" en est un.
Des guardrails définis. Quelles actions l'agent peut-il mener sans validation humaine ? Lesquelles nécessitent une confirmation ? Ces règles doivent être définies avant le déploiement, pas après le premier incident.
Des équipes formées à superviser. Un agent IA n'est pas un outil qu'on allume et qu'on oublie. Il doit être supervisé, ajusté, corrigé. Les équipes qui l'utilisent doivent comprendre ce qu'il fait et comment intervenir quand quelque chose ne va pas.
Comprendre la logique des agents IA change la façon dont on aborde le déploiement. C'est là que se joue la différence entre un déploiement réussi et un échec.
