Un agent IA n’est pas un acolyte des services secrets. C’est un logiciel qui décide par lui-même : il lit son environnement via des capteurs (flux de données, interfaces, requêtes utilisateur) et agit sur celui-ci via des actionneurs (API, commandes, messages) pour atteindre un objectif. Le plus difficile n’est pas d’en écrire un. Le plus difficile, c’est de comprendre qu’il n’existe pas d’agent universel, et de choisir le bon type pour le problème que vous avez devant vous.
Ce seul choix, du plus simple agent réactif à un agent orienté objectif, sépare un système qui part en production d’une démo qui s’éteint discrètement. Les chiffres le confirment. Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, en raison de problèmes tels qu’une mauvaise orchestration ou un type d’agent mal choisi. D’expérience, les projets qui finissent dans ces 40 % n’échouent presque jamais à cause du modèle. Ils échouent à cause de l’architecture. Cet article passe en revue les types d’agents que nos ingénieurs mettent en balance à chaque mission, puis montre ce qu’apporte concrètement une équipe qui a déjà tranché ces questions en production.
Qu’est-ce que le framework PEAS, et pourquoi commencer par là ?
Avant de comparer les types d’agents, il faut décrire le problème avec précision. Nous utilisons PEAS, la grille de lecture standard pour spécifier n’importe quel agent, parce qu’elle impose les questions que la plupart des équipes escamotent :
- Performance : qu’est-ce que le succès signifie réellement ici ? Maximiser le chiffre d’affaires, minimiser les erreurs, mener une tâche à son terme proprement ?
- Environnement : dans quel monde l’agent évolue-t-il ? Est-il totalement observable, déterministe, statique, discret ? Les réponses fixent la vraie difficulté du travail.
- Actionneurs (Actuators) : comment l’agent modifie-t-il le monde ? Requêtes SQL, appels de fonctions, mouvements moteurs.
- Capteurs (Sensors) : comment perçoit-il le monde ? Données d’entrée, flux de capteurs, requêtes utilisateur, fichiers de logs.
Définir le PEAS est la première étape, et la plus lourde de conséquences, et elle conduit naturellement au bon type d’agent. Sautez-la, et vous bâtissez sur du sable. Dans nos projets, c’est là qu’un ingénieur expérimenté fait la différence, bien avant qu’une ligne de code d’orchestration ne soit écrite.
Quels sont les trois types d’agents fondamentaux ?
On classe généralement les agents selon la complexité de leur architecture interne et la finesse avec laquelle ils comprennent leur monde, un parcours qui va des automates réactifs aux systèmes qui planifient et apprennent. Trois types jalonnent ce parcours. Comprendre leur mécanique, et leurs limites, est essentiel, car même les frameworks avancés sont bien moins fiables que le battage médiatique ne le laisse croire. Un benchmark récent a montré que les solutions populaires n’accomplissent correctement qu’environ 50 % des tâches sur 34 problèmes de programmation réalistes. Nombre de ces échecs proviennent d’un seul et même décalage : la puissance brute d’un LLM greffée sur une architecture d’agent inadaptée à la tâche.
L’agent réflexe simple
Le bloc de construction le plus élémentaire. Il fonctionne sur une règle « si-alors » directe : une perception déclenche une condition, la condition déclenche une action. Aucun historique, aucun modèle du monde. SI le capteur de température dépasse 22 degrés, ALORS coupe le chauffage, peu importe comment la pièce en est arrivée là.
Ses forces sont la rapidité, la simplicité, la prévisibilité et une faible consommation de calcul. Sa faiblesse : il est aveugle au contexte et au passé. Placez-le dans un environnement partiellement observable où les capteurs ne racontent pas toute l’histoire, et il est démuni. Il ne sait pas non plus travailler en vue d’un état futur. Il convient aux environnements stables, totalement observables, à causalité nette : thermostats, filtres antispam basiques, coupures de sécurité mécaniques.
L’agent réflexe fondé sur un modèle
Quand l’environnement n’est pas entièrement visible, l’agent simple se brise. L’agent fondé sur un modèle ajoute la pièce manquante : un modèle interne du monde qui enregistre ce qu’il ne peut pas voir directement. Ce modèle est une représentation de la façon dont le monde évolue dans le temps et de la manière dont les propres actions de l’agent le font bouger.
Son cycle prolonge celui de l’agent simple : percevoir, mettre à jour le modèle du monde, évaluer l’état courant au regard de ce modèle, appliquer une règle, agir. Le modèle lui permet de distinguer des perceptions identiques selon le contexte. Voyant une porte fermée, il sait s’il l’a lui-même fermée ou si elle est close depuis un moment. C’est l’apparition de l’état interne et de la mémoire, un vrai pas vers un comportement flexible dans des environnements imparfaits et fragmentaires. Un robot aspirateur qui cartographie une pièce pour ne pas nettoyer deux fois le même endroit exécute une version basique de ce principe.
L’agent orienté objectif
Les agents fondés sur un modèle réagissent encore au présent. Les agents orientés objectif utilisent leur modèle du monde pour planifier et simuler l’avenir au regard d’un objectif défini, la description d’un état souhaité (« colis emballé », « client a obtenu la bonne réponse »). L’action devient un moyen, non une fin.
Son cycle : percevoir, mettre à jour le modèle, analyser l’objectif, explorer les chemins possibles, sélectionner l’action. Il simule des séquences (« que se passe-t-il si je fais A puis B ? ») et retient le chemin qui, selon lui, s’approchera le plus de l’objectif. Cela introduit la notion d’utilité, puisque tous les chemins ne se valent pas. Il en résulte une bien plus grande flexibilité : la même architecture peut poursuivre différents objectifs par simple redéfinition, sans réécrire la moindre règle. Le coût est cependant réel, à la fois en calcul nécessaire pour explorer l’espace d’états et en rigueur requise pour définir précisément l’objectif et ses critères de succès. D’expérience, c’est exactement là que les projets complexes, souvent bâtis à partir d’équipes d’agents LLM, se heurtent à des problèmes d’orchestration et d’observabilité, les mêmes qui en maintiennent tant hors production.
Que sont les agents fondés sur l’utilité et les agents apprenants ?
Le spectre s’étend plus loin :
- Les agents fondés sur l’utilité prolongent le type orienté objectif. Lorsque plusieurs chemins atteignent l’objectif, ils ne se contentent pas d’une solution quelconque : ils notent les états finaux à l’aide d’une fonction d’utilité et choisissent le meilleur, ce qui permet de meilleures décisions en situation d’incertitude.
- Les agents apprenants ajoutent une boucle d’apprentissage à n’importe lequel des précédents : un critique qui évalue la performance au regard des retours, un élément d’apprentissage qui met à jour les règles, le modèle ou la fonction d’utilité, et un élément d’exploration qui essaie de nouvelles actions en quête de meilleurs résultats. C’est le fondement du machine learning moderne et du deep reinforcement learning.
Où ces agents fonctionnent-ils réellement ?
La théorie se retrouve dans des systèmes que les gens côtoient chaque jour :
- Réflexe simple : portes automatiques, régulateurs PID basiques, alertes du type « si l’usage CPU atteint 95 %, envoyer un e-mail ».
- Réflexe fondé sur un modèle : la plupart des PNJ de jeux vidéo (ils suivent un joueur qu’ils perdent parfois de vue), la navigation simple sensible à la localisation.
- Orienté objectif et fondé sur l’utilité : le cœur des systèmes avancés. Véhicules autonomes (objectif : aller de A à B en toute sécurité), moteurs de recommandation e-commerce (objectif : maximiser la valeur attendue de la commande) et assistants qui décomposent une requête complexe en une suite d’étapes (objectif : fournir une réponse complète). C’est dans ces constructions à base de LLM que devient visible l’écart entre le prototype et la production, celui que les benchmarks et Gartner ne cessent de pointer.
Que nos équipes IA apportent-elles face au problème des 40 % ?
Connaître les types d’agents, c’est le minimum. En faire un système de production stable, observable et maintenable relève d’une tout autre discipline, celle qui décide de quel côté des 40 % de Gartner un projet va tomber. C’est le travail que nos ingénieurs IA accomplissent au quotidien :
- Une architecture calée sur le PEAS. Nos ingénieurs ne se ruent pas sur un agent orienté objectif piloté par LLM parce que c’est à la mode. Ils cartographient d’abord votre PEAS, puis choisissent le type d’agent le plus simple qui franchit la barre, d’une simple règle réflexe à un planificateur complet fondé sur l’utilité. Le sur-dimensionnement échoue aussi sûrement que le sous-dimensionnement.
- Une orchestration qui tient sous charge. Le mode de défaillance des projets agentiques n’est que rarement un agent isolé : c’est la coordination entre eux. Nous concevons les passages de relais, les garde-fous et les mécanismes de repli qui maintiennent des workflows multi-agents cohérents lorsque le trafic réel arrive.
- De l’observabilité dès le premier jour. On ne corrige pas ce qu’on ne voit pas. Nous intégrons tracing, évaluation et monitoring sur tout le cycle de vie de l’agent, pour que le comportement reste lisible au lieu de devenir une boîte noire dès la mise en production.
- Des patterns de production appris à la dure. Retries, maîtrise des coûts, ancrage contre les hallucinations, revue humaine aux bons points de contrôle. Ce sont les patterns qui séparent une démo convaincante d’un système qu’une entreprise réglementée peut réellement exploiter, et nous les avons parce que nous les avons déjà livrés.
C’est aussi là que l’IA change la forme de l’équipe, pas celle du prestataire. Un petit groupe senior de nos ingénieurs, augmenté par des agents IA qui absorbent le volume, produit le résultat d’une équipe classique bien plus large, et plus vite, parce que les personnes dans la boucle savent déjà quelle architecture survit au contact de la production.
Comment intégrer cette capacité ?
Le chemin le plus rapide pour dépasser les 40 %, ce n’est pas une énième évaluation de framework, ce sont des personnes qui ont déjà tranché ces questions. Nous intervenons de deux façons :
- Une équipe IA dédiée qui prend en charge une construction agentique de bout en bout, du PEAS à la production en passant par l’orchestration et l’observabilité.
- Le staff augmentation, en insérant un ingénieur ML ou IA senior dans votre équipe existante pour prendre les décisions d’architecture qui gardent le projet livrable.
Choisir le bon type d’agent n’est pas un exercice académique. C’est la décision d’ingénierie qui pèse le plus sur la question de savoir si votre projet atteindra un jour la production. Si vous préférez apprendre des projets que nous avons déjà livrés plutôt que de ceux qui composent les 40 % de Gartner, c’est précisément ce que nos équipes vous offrent.
Faites appel à une équipe d’experts, augmentée par l’IA → /services/team-augmentation