Modèle de maturité des agents : supervision humaine, ingénierie de support, orchestration.
Cinq niveaux de maturité des agents testés en production : supervision humaine, ingénierie de support, orchestration multi-agents et les problèmes encore non résolus.
Sources: Agentic Architectures — Article 15: The Maturity Model Revisited
Un modèle de maturité des agents est facile à dessiner, mais difficile à mettre en pratique. Sur le papier, il semble simple : une échelle qui commence avec des outils de base et se termine par des systèmes de production capables d’améliorer eux-mêmes. Les frameworks ont toujours l’air ordonnés avant que quiconque ne tente de les exécuter sous charge. Une fois que du code réel est implémenté, le même modèle prend une autre signification. Ce n’était pas faux, mais connaître quelque chose en théorie et le mettre en œuvre en production relèvent de types de connaissances différents. Une carte ne peut pas vous indiquer comment se passe la situation à trois heures du matin, lorsque le disjoncteur ne veut pas se fermer et que c’est à votre tour d’être de garde.
Ce texte offre un aperçu de ce modèle une fois que les couches qui le composent ont été réellement mises en place : comment les différents niveaux correspondent aux travaux d’ingénierie, quels principes n’ont pas résisté à la mise en production, à quoi ressemble une architecture de référence en couches, et ce qui reste à résoudre. Le code est ici minimal. L’objectif est de prendre du recul pour voir l’ensemble de la stack.
Cinq niveaux, chacun reposant sur le précédent
Le modèle de maturité décrit cinq niveaux de capacités des agents. Chaque niveau représente bien plus qu’une version améliorée de celui du dessous, car il dépend également de tout ce qui se trouve en dessous. Il est impossible de sauter des étapes. Un agent ne peut pas être véritablement autonome sans une infrastructure d’évaluation, et il ne peut pas s’améliorer sans mémoire. Les niveaux s’additionnent.
Voici comment les sujets liés à l’ingénierie correspondent à ces niveaux :
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
La forme importe plus que la correspondance. Le niveau 5, l’amélioration continue, ne comporte pas de composant dédié, car ce n’est pas quelque chose que l’on construit directement. Il apparaît lorsque la mémoire et l’évaluation fonctionnent ensemble, et même alors ce domaine n’est pas encore pleinement développé. La partie supérieure du modèle reste en partie une aspiration. L’amélioration continue peut être approximée aujourd’hui, mais elle ne peut pas être pleinement atteinte.
Cela n’était pas évident lorsque le modèle a été esquissé pour la première fois. Le niveau 5 ressemblait à une destination que l’on atteint en assemblant les bons éléments. En pratique, il se comporte plutôt comme un horizon qui s’éloigne à mesure que l’on s’en approche.
Croyances corrigées par la production, de l’intervention humaine à l’orchestration
C’est la partie qu’un document de cadre ne peut jamais capturer, car elle ne provient que de la construction concrète. Plusieurs hypothèses initiales se sont révélées fausses ou du moins incomplètes.
La mémoire a été gravement sous-estimée. Dans le premier schéma, la mémoire n’était qu’un élément parmi d’autres, une fonction qui permettait aux agents de se sentir plus continus. En la développant, on a découvert qu’il s’agissait en réalité d’une infrastructure, avec tout ce que ce terme implique : conception de schémas, qualité des récupérations, politiques de dégradation et isolation des utilisateurs. Une leçon encore plus dérangeante a suivi : même les infrastructures que nous savons construire ne constituent pas vraiment l’abstraction appropriée. Les équipes adaptent des bases de données conçues pour d’autres utilisations, car il n’existe rien de spécifiquement conçu à cet effet. La mémoire était le sujet le plus sous-estimé dans le modèle initial.
L’objectif est la prévisibilité, et l’autonomie est secondaire. C’est le changement le plus fondamental. Au début, les progrès étaient mesurés par la capacité d’un agent à fonctionner sans intervention humaine, de sorte que chaque élément d’indépendance supplémentaire semblait représenter un progrès. Cependant, un agent qui agit seul mais de manière imprévisible cause simplement des dommages plus tôt. La fiabilité sous supervision s’est avérée plus importante que l’indépendance brute dans tous les déploiements sérieux. Une défaillance illustrative a concerné un agent qui a créé de manière autonome des dizaines de tickets dupliqués. Ce dont ont besoin les systèmes de production, c’est d’une autonomie adaptée : encadrée, auditable et prévisible, avec des humains responsables des décisions dont le coût justifie une attention humaine. Un lecteur a un jour soutenu que l’orchestration devrait viser la prévisibilité plutôt que l’autonomie, et il a fallu beaucoup de temps pour admettre ce point.
La sécurité est une caractéristique de chaque couche. Le plan initial traitait la sécurité comme un sujet abordé vers la fin, quelque chose ajouté une fois que le système fonctionnait. L’injection de commandes corrige cela. Ses cibles se trouvent ailleurs : le point où les outils sont appelés, le chemin par lequel les mémoires sont écrites, la manière dont les objectifs sont révisés, ainsi que le trafic entre les agents. Chaque composant possède une dimension de sécurité. L’authentification à la frontière des outils, l’isolation en mémoire et les contrôles sur la révision des objectifs relèvent tous de la sécurité, répartis dans tout le système et non regroupés dans une seule catégorie.
La boucle a une priorité supérieure à la requête. Cette leçon a été présentée en dernier et aurait été plus utile en premier. Une grande partie de l’énergie dédiée à ce domaine va vers l’ingénierie des requêtes et la recherche de formulations magiques. Mais un agent n’est pas une requête : c’est une boucle qui poursuit un objectif à travers de nombreuses étapes, et une requête parfaite insérée dans une boucle défectueuse ne produit qu’un agent éloquent qui n’arrive jamais à destination. Une fois que l’on pense en termes de boucles, de nombreux problèmes qui semblaient être des limites du modèle se révèlent en fait être des échecs dans la conception de la boucle.
La présence d’un être humain dans le processus n’est pas un défaut qu’il faut éliminer par la technique. Il est tentant de penser que l’intervention humaine n’est qu’un soutien temporaire à supprimer à mesure que la technologie se développe. Les meilleurs systèmes d’agents de production ne sont pas ceux qui sont les plus autonomes. Ils placent le jugement humain exactement là où il est nécessaire, et nulle part ailleurs. La supervision humaine n’est pas une étape à laquelle on passe ; c’est une caractéristique délibérée et permanente de tout système dont les erreurs entraînent des coûts réels.
Le stack en une image
En combinant tout ce qui précède, un système d’agents mature ressemble à ceci :
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Les couches verticales forment le chemin de la requête. Une tâche entre par l’intermédiaire d’une supervision humaine, est façonnée par des objectifs et des boucles, coordonnée entre les différents agents, affinée par le mécanisme de gestion et enfin exécutée à l’aide du modèle. Les problématiques qui concernent l’ensemble du système atteignent chaque couche. La mémoire fournit à la fois les boucles et le mécanisme de gestion. La sécurité protège les limites de l’outil ainsi que la révision des objectifs. Le coût régule le routage du modèle à chaque étape. Le déploiement englobe tout cela.
La vue niveau par niveau cache à quel point ces éléments sont étroitement liés. Un changement dans l’un a des répercussions sur les autres. On ne peut pas optimiser le coût sans comprendre les boucles, car une exécution coûteuse est souvent le résultat d’une boucle qui ne se termine pas. Les mesures de sécurité nécessitent également une bonne compréhension de la mémoire, car une entrée corrompue continue d’avoir des effets négatifs longtemps après avoir été enregistrée. Il faut considérer ces couches comme un tissu interconnecté et non comme un ensemble de modules séparés.
Ce que personne n’a encore résolu
Ce pourrait être la section la plus utile, car tout ce qui a été décrit précédemment concerne ce qui peut être construit, tandis que celle-ci décrit ce qui ne peut pas l’être pour l’instant. Une carte honnête des limites vaut plus qu’une carte parfaitement polie.
Il n’existe pas de mémoire native aux agents. La mémoire actuelle est composée de bases de données et de systèmes vectoriels conçus à d’autres fins. Un véritable système native aux agents, capable de suivre le temps, de récupérer des informations par association, d’oublier délibérément et de laisser l’agent décider de ce qu’il faut enregistrer, est, selon certaines estimations, encore à quelques années de distance. Ce qui existe fonctionne, mais ce n’est pas ce dont on a besoin.
Les agents ne peuvent pas déterminer avec fiabilité quand leurs connaissances sont applicables. Il s’agit de la forme plus profonde du problème de la mémoire obsolète. Un agent peut récupérer une procédure pertinente et l’appliquer avec confiance dans un cas où elle ne convient pas, car il est difficile d’établir où une connaissance cesse d’être valable, et encore plus difficile de le vérifier lorsque quelque chose est récupéré. Une procédure qui fonctionne dans une juridiction peut être mal appliquée dans une autre, sans que ni l’agent ni, souvent, l’utilisateur ne s’en aperçoivent. C’est une limitation fondamentale et non simplement un défaut d’ingénierie.
L’auto-évaluation est peu fiable. La logique d’escalade ainsi que l’évaluation de la confiance dépendent toutes deux du fait que l’agent puisse évaluer avec précision son propre degré de certitude. Parfois, il y parvient, mais parfois il se trompe tout en donnant l’impression d’être sûr, ce qui est le cas le plus dangereux car cela annule toutes les mesures de sécurité basées sur la capacité de l’agent à reconnaître ses limites. Aucune solution fiable n’existe encore pour une auto-évaluation calibrée.
Les outils d’assistance ne sont pas transférables entre modèles. Chaque outil est adapté au comportement d’un modèle spécifique. En changeant de modèle, il faut réajuster les prompts, les seuils de détection de boucles et les critères de vérification. En principe, cela ne devrait pas être nécessaire, mais personne n’a encore créé d’abstraction d’outil capable de fonctionner sans ajustement après un changement de modèle. Une mise à niveau de modèle reste donc un projet et non une simple modification de configuration.
Il n’existe pas de véritable apprentissage continu. La mémoire procédurale simule l’apprentissage : les approches réussies sont stockées et réutilisées. Cependant, les poids ne changent pas et l’agent ne développe pas de nouvelles capacités à partir de son expérience. Il crée une bibliothèque de solutions passées auxquelles il se réfère. Un agent qui s’améliore réellement dans une catégorie de problèmes grâce à son expérience n’est pas encore possible dans les systèmes de production actuels.
Le coût est imprévisible en situation marginale. Des outils de gestion des coûts existent et fonctionnent, mais la partie extrême de la distribution est difficile à maîtriser. Une petite proportion d’exécutions, celles qui tombent dans des boucles pathologiques ou des cas limites complexes, consomme encore des ressources disproportionnées de manières difficiles à prévoir. Il est possible de limiter ces dépenses, mais on ne peut pas toujours les anticiper.
Rien de tout cela ne constitue une raison de reculer. Ce sont les limites de la carte actuelle, et connaître leur emplacement est ce qui distingue l’ingénierie de la simple espérance.
Où commencer : maîtriser l’ingénierie avant l’orchestration des agents
Si vous développez un système d’agents, ne traitez pas ces éléments comme une séquence de construction. Ils sont regroupés par concept, et non par ordre d’assemblage. Si vous suivez cet ordre, vous créerez de la mémoire avant même d’avoir un outil pour l’utiliser, ainsi que des mécanismes d’évaluation avant même d’avoir quoi évaluer.
Commencez par le niveau de maturité atteint par votre système.
- Un agent de base chargé d’appeler des outils et qui est peu fiable devrait commencer par l’ingénierie des outils, car c’est là que résident la plupart des problèmes de fiabilité.
- Un agent unique solide qui a atteint ses limites est prêt pour l’orchestration de plusieurs agents.
- Un système destiné à la production nécessite une évaluation, des mesures de sécurité et des travaux de déploiement, rien de tout cela n’étant optionnel, et il est judicieux de les effectuer dans cet ordre approximatif.
- La gestion de la mémoire s’avère utile une fois que vous disposez d’un agent fonctionnel, évalué et sécurisé, et que vous constatez que les mêmes tâches se répètent à chaque exécution. L’ajouter plus tôt serait prématuré.
- L’optimisation des coûts devient urgente lorsque l’utilisation passe de volumes de test à des volumes de production, bien qu’elle doive déjà guider la conception dès le premier jour.
- Les boucles axées sur des objectifs et les schémas impliquant un intervenant humain sont présents dans tous les aspects. Vous les rencontrerez à chaque étape, il est donc préférable de s’y informer tôt, même si vous les adoptez progressivement.
Les outils sont interchangeables, les idées ne le sont pas
Les exemples présentés dans cette discussion ont été développés à l’aide d’AWS Bedrock, LangGraph et LangChain. Il s’agissait de choix pratiques, motivés par le fait que c’était la stack utilisée en production, mais ce ne sont pas les seuls choix possibles. La plupart des éléments importants ne dépendent pas d’eux. L’authentification doit être gérée au niveau de l’outil, quel que soit le cloud. Dans n’importe quel framework, la boucle de traitement est plus importante que le prompt. Les niveaux de mémoire, les schémas de coordination entre plusieurs agents, les catégories d’attaques ainsi que la matrice reliant la réversibilité aux coûts liés à la supervision humaine peuvent tous être adaptés à d’autres stacks.
C’est aussi pour cette raison qu’une alternative locale avec Ollama et Docker est utile. Elle permet de faire fonctionner ces schémas sans frais liés au cloud, et démontre que les concepts sont séparables de leur implémentation. Si une architecture mémoire fonctionne avec un modèle local et un stockage vectoriel local, alors ce design ne doit rien à Bedrock dès le départ. Ce qu’il a capturé, c’est le problème fondamental, qui se présente de la même manière sur n’importe quelle plateforme. Il en va de même pour les schémas d’orchestration : remplacer LangGraph par un autre framework modifie la syntaxe des boucles, mais pas les modes de défaillance auxquels il doit faire face. Il en va de même pour les outils d’évaluation, qui peuvent être utilisés avec n’importe quel modèle derrière eux.
Ce que l’écriture de ce texte a révélé
Expliquer un sujet de manière claire et ordonnée à quelqu’un qui n’était pas présent lors de votre apprentissage révèle les lacunes dans votre propre compréhension. De nombreux sujets semblent maîtrisés jusqu’au moment où on tente de les mettre par écrit.
La réalité de ce domaine est qu’il est à la fois passionnant et immature. Des choses sont désormais possibles qui ne l’étaient pas il y a deux ans, et il est facile de se tromper soi-même, car une expression fluide donne l’impression de plus de compétence qu’en réalité. L’écart entre un agent qui fonctionne bien en démonstration et un agent qui fonctionne de manière fiable en production est énorme, et la majeure partie du travail d’ingénierie difficile réside dans cet écart.
Si un message mérite d’être envoyé en retour, c’est que le travail vraiment intéressant ne consiste pas à rendre les agents plus puissants. Les modèles sont déjà puissants et continuent d’évoluer selon un rythme que l’on ne contrôle pas. Le travail intéressant réside plutôt à rendre ces modèles puissants fiables, prévisibles, sûrs et suffisamment abordables pour être utilisés dans des décisions réelles. Il s’agit d’ingénierie et non de magie : des mécanismes, des boucles, de la mémoire, des méthodes d’évaluation et toute l’infrastructure peu glamour qui transforme un modèle capable en quelque chose sur lequel on peut compter.
L’intelligence provient du modèle. L’architecture, c’est ce qu’il faut construire soi-même.
Lectures complémentaires
- Notes pratiques : Architectures agentes, Article 12 : Sommes-nous prêts pour An : Guide détaillé des Notes pratiques : Architectures agentes, Article 12 : Sommes-nous prêts pour An, incluant des contrats, des vérifications et des emplacements de code prêts à l’emploi pour les équipes utilisant ce modèle.
- L’humain dans la boucle pour les agents IA : Portes d’approbation, escalade, traces d’audit : Lorsqu’un agent a besoin de l’approbation humaine, quatre modèles (portes d’approbation, escalade, éditions collaboratives, échantillonnage), possibilité de pause et de reprise avec LangGraph, délais d’expiration, journaux d’audit et pièges à éviter.