Quels sont les types d’agents IA ?

Les types d’agents IA

Les types d’agents IA proviennent d’une même taxonomie : agents à réflexe simple, agents à réflexe fondés sur un modèle, agents orientés objectifs, agents fondés sur l’utilité et agents apprenants. Chaque nom décrit un aspect : la quantité d’informations que l’agent mémorise et la profondeur de sa planification avant d’agir. Deux autres termes, multi-agent et hiérarchique, décrivent la manière dont plusieurs agents sont reliés, et non la manière dont un agent donné prend ses décisions.

Cette liste est antérieure à tous les modèles que vous avez utilisés. Elle vient du manuel de référence de l’IA et a résisté à l’arrivée des grands modèles de langage, car elle pose la question qui détermine encore votre conception : de quelles informations cet élément a-t-il besoin avant d’agir ? Si vous cherchez encore à déterminer où s’arrête un agent et où commence un assistant conversationnel, lisez d’abord la différence entre un agent IA et le LLM qu’il utilise. Cette page commence après cette distinction.

Agents réflexes simples : une condition, une action

Un agent réflexe simple associe l’entrée courante à une action et ne conserve aucune mémoire des événements précédents. Si la température dépasse 25, activez le ventilateur. C’est tout le mécanisme.

Vous en avez presque certainement déjà exécuté un. Un webhook qui déclenche un workflow n8n, lit les données d’un formulaire et écrit une ligne dans une base de données est un agent réflexe simple. Il le reste même lorsqu’un modèle de langage intervient pour choisir une catégorie pour cette ligne. Demandez-lui ce qu’il a fait il y a une heure : il ne peut pas vous répondre, car rien n’a conservé cette information.

Ce type d’agent est plus souvent adapté qu’on ne le pense. Il est peu coûteux à exécuter et ses échecs sont faciles à comprendre : la condition a été satisfaite ou elle ne l’a pas été. Lorsque la tâche consiste réellement à « quand X arrive, faire Y », la mémoire introduit des possibilités d’erreur sans apporter de bénéfice. Un agent n8n déclenché par un webhook correspond à cette catégorie de la taxonomie, avec une interface utilisateur par-dessus.

Il échoue dès que l’action correcte dépend de l’historique. Un bot de réponse sans état de conversation se contredira dès le troisième message, car les deux premiers messages n’ont jamais fait partie de son entrée.

Agents réflexes fondés sur un modèle : conserver l’état entre les événements

Un agent réflexe fondé sur un modèle conserve une représentation interne de son environnement et la met à jour lorsque de nouvelles entrées arrivent. Ici, le terme « modèle » désigne un modèle du monde, et non un réseau neuronal. Ce terme est antérieur d’environ quarante ans à son sens actuel, ce qui le rend déroutant à la première lecture pour presque tout le monde.

Une règle de domotique qui éteint les lumières après vingt minutes sans mouvement est fondée sur un modèle. C’est obligatoire. « Aucun mouvement actuellement » et « aucun mouvement depuis 21:40 » sont la même entrée pour un agent réflexe simple. Seul l’état enregistré permet de les différencier.

Dans le cas des LLM, il s’agit de tout agent qui dispose d’un stockage mémoire : un résumé glissant de la conversation ou un simple fichier markdown que l’agent lit au début de chaque exécution. Un service de mémoire local pour un agent reprend cette idée sous forme de service. Le mécanisme ne change pas. La représentation que l’agent se fait du monde persiste après l’événement qui l’a créée.

L’état a un coût. Un fait obsolète est pire qu’une information absente, car l’agent agit dessus avec une confiance totale et sans avertissement. Toute donnée stockée doit pouvoir expirer ou être vérifiée à nouveau. Sinon, l’agent continuera à raisonner sur un serveur que vous avez décommissionné en mars.

Agents pilotés par des objectifs : planifier jusqu’à un état vérifiable

Un agent piloté par un objectif reçoit un état cible et recherche une suite d’actions qui permet de l’atteindre. Il raisonne à rebours depuis l’état final nécessaire. Le chemin n’est donc pas défini à l’avance.

Un agent de programmation est l’exemple le plus simple à exécuter vous-même. « Faire passer le test en échec » ne précise ni fichier ni étape. L’agent lit le test, établit un plan, modifie un élément, exécute le test, lit l’erreur, puis réessaie. La boucle se termine par une vérification qu’il peut réellement exécuter. C’est pourquoi cette instruction fonctionne, contrairement à « améliorer ce code ». Un objectif que l’agent peut évaluer est un objectif qu’il peut atteindre. Un objectif qu’il ne peut pas évaluer transforme la boucle en processus sans fin, avec une facture à la clé. Exécuter un agent de programmation sur votre propre VPS place cette boucle à un endroit où elle peut tourner sans monopoliser votre ordinateur portable.

Le coût se trouve dans cette ligne. Chaque étape de planification correspond à un nouvel appel au modèle qui transmet tout l’historique disponible. Une tâche en dix étapes ne coûte donc pas dix fois plus qu’une tâche en une étape, mais davantage. L’essentiel du travail d’ingénierie concerne la structure de la boucle et la condition qui l’arrête. C’est le sujet de l’ingénierie des boucles.

Agents fondés sur l’utilité : choisir entre plusieurs bonnes réponses

Un objectif est binaire. L’utilité est un score. Un agent fondé sur l’utilité se trouve face à plusieurs résultats acceptables et choisit celui qui obtient le meilleur score selon une fonction que vous avez définie.

Une tâche de sauvegarde qui doit se terminer avant le début de la journée de travail sans saturer la liaison montante relève d’un problème d’utilité. Il n’existe pas une seule bonne réponse, mais un compromis à trouver. Un routeur qui détermine quel modèle traite quelle requête en évaluant le prix par rapport à la qualité de la réponse suit le même principe.

L’algorithme n’est pas la partie la plus difficile. Le plus difficile est d’écrire une fonction d’utilité honnête. Si vous évaluez uniquement le coût, vous utilisez le modèle le moins cher pour chaque requête, y compris celle qui nécessitait le modèle le plus coûteux. Le système optimise exactement ce que vous avez mesuré. C’est un problème lorsque vous avez choisi cette mesure parce qu’elle était facile à obtenir.

Agents apprenants : le type que la plupart des utilisateurs pensent déjà avoir

Un agent apprenant modifie son propre comportement à partir du retour d’expérience de résultats passés. Il lui faut un composant qui évalue le résultat et un autre qui modifie la policy en conséquence.

Très peu de systèmes auto-hébergés répondent à cette définition. Un agent qui lit des notes qu’il a écrites la semaine dernière est un agent model-based doté d’un fichier mémoire. Ses weights sont identiques. Sa policy est identique. La retrieval n’est pas de l’apprentissage, et cette distinction est concrète : un système fondé sur la mémoire répète indéfiniment une erreur, sauf si un composant modifie la mémoire, tandis qu’un système apprenant est censé cesser de la commettre.

Si vous voulez la partie apprentissage, commencez par construire l’évaluation. Un jeu de tests noté, l’exécution de votre modification sur ce jeu et la décision de conserver ou d’abandonner cette modification forment une boucle fermée dans laquelle vous êtes le composant apprenant. C’est plus lent qu’il n’y paraît, et c’est la seule version qui fonctionne actuellement avec des composants auto-hébergés. Auto-héberger un eval harness est le point de départ.

Systèmes multi-agents et hiérarchiques : des organisations, pas des types

Il ne s’agit pas d’un sixième et d’un septième type. Ces termes décrivent la manière dont les agents sont organisés.

Un système multi-agents exécute plusieurs agents simultanément dans un environnement partagé, comme une file d’attente ou un dépôt git. Comme l’environnement est partagé, les agents peuvent y entrer en conflit. Deux agents qui modifient le même fichier constituent le cas d’échec classique. La solution consiste à utiliser un verrou ou une file de travail. Aucun prompt ne permet de résoudre ce problème.

Un système hiérarchique place un superviseur au-dessus des workers. Le superviseur divise une tâche, distribue les différentes parties, puis fusionne les résultats reçus. Cette approche est répandue parce qu’elle correspond à la manière dont les personnes répartissent le travail. Elle est coûteuse parce que le contexte du superviseur augmente avec chaque rapport qu’il lit. Un harness multi-agents montre comment cette intégration fonctionne en pratique.

Un agent qui fonctionne vaut mieux que quatre agents qui fonctionnent à peu près.

Chaque transmission peut entraîner une perte d’informations. Commencez par une seule boucle. Ne la divisez que lorsque vous pouvez nommer l’étape qui constitue le goulot d’étranglement.

Pourquoi presque tous les systèmes réels sont hybrides

Prenez un agent de déploiement que vous pourriez exécuter vous-même. Un webhook le déclenche : c’est un comportement réflexe. Il lit l’état actuel de la release : c’est une approche fondée sur un modèle. Il planifie les étapes entre la version en cours d’exécution et la version cible : c’est une approche fondée sur des objectifs. Il choisit une fenêtre de déploiement en fonction de la charge actuelle : c’est une approche fondée sur l’utilité. Il ne modifie jamais sa propre policy : ce n’est donc pas un système apprenant.

Un même système relève simultanément de quatre catégories de la taxonomie. La taxonomie est utile comme checklist de conception, et non comme étiquette à appliquer au produit final. Lorsque le système se comporte mal, la question utile est de déterminer quelle couche est en cause. Un déclencheur activé par le mauvais événement, un état devenu obsolète, une vérification d’objectif qui ne peut jamais réussir et un score qui favorise le mauvais résultat correspondent à quatre bugs différents, avec quatre corrections différentes.

Quel type convient à quel usage

• Déclencheur fixe, réponse fixe, aucun historique requis : agent à réflexe simple.
• La bonne réponse dépend de ce qui s’est produit auparavant : agent à réflexe fondé sur un modèle.
• L’état final peut être vérifié, mais le chemin n’est pas connu à l’avance : agent orienté vers un objectif.
• Plusieurs résultats acceptables, avec un véritable compromis entre eux : agent fondé sur l’utilité.
• Les résultats doivent s’améliorer au fil du temps : mettez en place une boucle d’évaluation et acceptez que le composant d’apprentissage, c’est vous.

Pouvez-vous héberger vous-même ces agents, et combien cela coûte-t-il ?

Oui, et le coût se répartit en deux postes. L’orchestration coûte peu. Une instance n8n ou une boucle d’agent en Python passe l’essentiel de son temps à attendre des appels réseau. 2 vCPU et 4 GB de RAM suffisent donc. Le modèle est le principal poste de dépense.

Si l’agent appelle une API hébergée, le serveur a besoin de très peu de ressources et la facture évolue en fonction du nombre de tokens. Pour un agent fondé sur un objectif, elle dépend donc du nombre d’étapes de planification que vous autorisez. Limitez la boucle.

Si vous exécutez le modèle sur votre propre matériel, la RAM détermine les modèles que vous pouvez réellement exécuter. Les valeurs ci-dessous correspondent aux tailles de fichiers généralement publiées pour des poids quantifiés sur 4 bits en août 2026. Elles sont accompagnées d’une estimation de la RAM totale nécessaire, car la fenêtre de contexte et le runtime ont également besoin d’espace en plus des poids.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Un modèle 8B en 4 bits représente environ 4.9 GB de poids. Une machine dotée de 10 GB de RAM peut l’exécuter sans swap. Un modèle 70B avec la même quantification représente 43 GB de poids et nécessite environ 64 GB de RAM. Notez ce que ces valeurs ne prennent pas en compte : la vitesse. Sur un VPS sans GPU, un modèle 8B en 4 bits produit quelques tokens par seconde. C’est acceptable pour un agent qui traite une file d’attente pendant la nuit, mais trop lent pour une tâche interactive. Réservez l’inférence locale aux traitements par lots et utilisez un GPU ou une API pour les parties interactives. La sélection des agents IA auto-hébergeables présente les projets qui justifient l’espace disque requis, et un parcours d’apprentissage des agents en 2026 indique quoi apprendre et dans quel ordre.

Quand la taxonomie n’est plus utile

Elle ne dit rien des outils ni des permissions. Dans les manuels, les agents perçoivent et agissent. Personne, dans l’écriture de ce chapitre, ne s’est préoccupé du risque qu’un agent détienne un token d’API de production. Un agent fondé sur des objectifs qui dispose d’un accès shell et un agent fondé sur des objectifs qui ne dispose que d’une connexion en lecture seule à une base de données figurent sur la même ligne du tableau, tout en présentant des niveaux de risque complètement différents. Déterminez ce qu’un agent peut toucher avant de décider de son niveau d’autonomie, puis lisez comment empêcher un agent IA d’accéder aux secrets avant de lui fournir un identifiant.

Elle ne dit rien non plus de ce qui se passe lorsqu’une étape échoue. Les agents réels passent la majeure partie de leur temps d’exécution à gérer des erreurs : une limite de débit ou un outil qui renvoie un résultat inattendu pour le modèle. C’est ce code qui détermine si votre système est utilisable, et aucune ligne de la taxonomie ne le décrit.

FAQ

Quels sont les cinq types d’agents IA ?

Les agents à réflexe simple, à réflexe fondé sur un modèle, fondés sur des objectifs, fondés sur l’utilité et capables d’apprendre. Ils sont classés selon la quantité d’informations dont ils disposent avant d’agir. Un agent à réflexe simple ne voit que l’entrée actuelle. Un agent fondé sur un modèle conserve l’état de son environnement. Un agent fondé sur des objectifs planifie l’atteinte d’un état cible. Un agent fondé sur l’utilité évalue plusieurs résultats acceptables et choisit celui qui obtient le meilleur score. Un agent capable d’apprendre modifie sa propre policy à partir des retours, ce que presque aucune configuration auto-hébergée ne fait réellement.

Quel type d’agent IA dois-je utiliser pour une automatisation simple ?

Un agent à réflexe simple, ce qui signifie en pratique un webhook ou une tâche planifiée qui déclenche une séquence fixe. Si la réponse correcte dépend uniquement de l’entrée qui vient d’arriver, la mémoire ajoute des modes de défaillance sans apporter de capacité supplémentaire. Passez à une architecture fondée sur un modèle dès que vous pouvez citer une décision qui doit connaître ce qui s’est produit auparavant.

Puis-je exécuter mes propres agents IA sur un VPS ?

Oui. La couche d’orchestration est légère : 2 vCPU et 4 GB de RAM suffisent pour exécuter confortablement un workflow engine ou une boucle d’agent. La vraie décision concerne l’emplacement d’exécution du modèle. Une API hébergée permet de conserver un serveur peu dimensionné et de reporter le coût sur les tokens. Un modèle local nécessite une quantité de RAM proportionnelle à son nombre de paramètres. Sans GPU, il génère quelques tokens par seconde, ce qui convient au traitement batch en file d’attente plutôt qu’à une fenêtre de chat.

Un large language model est-il un agent IA à lui seul ?

Non. Un modèle associe un texte d’entrée à un texte de sortie, puis s’arrête. Il devient un agent lorsqu’un composant l’intègre dans une boucle capable d’agir sur le monde et de lui renvoyer le résultat. Cette boucle a besoin d’outils qu’elle peut appeler et d’une condition qui lui indique quand s’arrêter. Le wrapper est l’agent. Le modèle est l’un de ses composants.

Ai-je besoin d’un système multi-agent ?

Généralement, non. Une seule boucle avec plusieurs outils suffit pour la plupart des tâches et est beaucoup plus facile à déboguer. Plusieurs agents sont utiles lorsque certaines parties d’une tâche sont réellement indépendantes et peuvent s’exécuter en parallèle, ou lorsqu’une partie nécessite un autre modèle. Le coût est la coordination : un état partagé et un superviseur dont le contexte augmente avec chaque rapport de worker qu’il lit. Ajoutez le deuxième agent lorsque vous pouvez désigner l’étape qui est lente.