Les 5 couches d'un agent IA : ce que tout manager doit savoir

« La plupart des gens pensent encore qu’un agent IA, c’est juste ChatGPT avec un bon prompt. » C’est par cette phrase que commence l’article de Sunil Ramlochan « The AI Agent Stack Is Not a Prompt. It’s a Production System », et l’auteur qualifie aussitôt cette croyance de « mythe rassurant ». La vérité utile, selon lui, est ailleurs : un véritable agent ressemble davantage à un petit système d’exploitation pour le travail. Il possède un cerveau, des mains, une mémoire, des règles, des logs, des plans de reprise et quelqu’un qui répond quand l’agent fait n’importe quoi.

La thèse de l’article tient en une ligne : un agent, c’est tout un stack. Et c’est l’architecture autour qui lui donne sa fiabilité, alors que le modèle ou un prompt bien tourné n’est qu’un ingrédient parmi d’autres. La perspective est technique, alors examinons-la sous un autre angle – qu’est-ce qui, dans ce stack, concerne réellement le manager qui n’écrit pas de code mais décide de lancer ou non un agent en production.

Commençons par lever la confusion principale, celle-là même que l’auteur combat. Un « agent » fonctionne de manière fondamentalement différente d’une interface de chat : un prompt donne une question et une réponse. Un agent reçoit un objectif et travaille en boucle : il comprend la tâche, décide quoi faire ensuite, choisit un outil, l’utilise, examine le résultat, interprète ce qui s’est passé, et continue, s’arrête ou fait appel à un humain. L’article renvoie honnêtement au guide d’OpenAI sur la construction d’agents, où l’agent est défini comme un système composé de modèles, d’outils, d’instructions et de contraintes. C’est cette boucle qui distingue l’agent de l’automatisation classique : l’agent ne répond pas par une seule réplique, il mène la tâche à son terme.

L’auteur décompose ce « petit ordinateur de travail » en cinq couches. Parcourons-les avec les yeux d’un manager.

Couche 1 : le modèle – le cerveau, mais pas tout le corps

Le modèle, c’est la partie qui raisonne, planifie et rédige. Il capte toute l’attention parce qu’il a l’air magique : plus le modèle est puissant, meilleurs sont les raisonnements, moins les erreurs sont flagrantes. Mais l’auteur est clair : en production, le modèle n’est souvent pas la partie la plus complexe.

Un modèle puissant échouera quand même s’il accède aux mauvais outils, s’il ne peut pas récupérer le contexte nécessaire, s’il se souvient de données obsolètes, s’il n’a pas de limites de droits, si ses décisions ne peuvent pas être vérifiées dans les logs, ou s’il a été chargé d’une tâche qu’un simple algorithme aurait dû traiter. La comparaison de l’article est juste : le modèle, c’est le chef cuisinier d’un restaurant. Même un excellent chef a besoin de produits frais, d’une cuisine en état de marche, de commandes, de contrôles sanitaires et d’un gérant qui arrête tout si quelque chose tourne mal.

Pour le manager, deux conclusions s’imposent. La première concerne le budget : derrière le mot « agent » se cache un flux d’appels au modèle, dont chacun a un coût, et ça ne ressemble pas du tout à un abonnement fixe. La seconde concerne les attentes : n’espérez pas qu’un modèle plus cher compensera une architecture faible. « Prenez le meilleur modèle que vous puissiez justifier », écrit l’auteur, mais ne comptez pas sur lui pour combler les failles de votre processus.

Couche 2 : les outils – les mains de l’agent et son risque principal

Les outils, c’est ce avec quoi l’agent agit dans le monde réel : recherche, API, bases de données, e-mail, calendriers, exécution de code, fichiers, systèmes de paiement, applications métier internes. C’est ici, écrit l’auteur, que l’agent cesse d’être un générateur de texte et devient un exécutant. Et c’est ici que le « rayon de souffle » augmente brutalement. C’est exactement la transition qui, il y a trois ans, a conduit à la tendance BYOA – Bring Your Own Agent : dès que l’outil accède à des systèmes réels, les questions organisationnelles dépassent les questions techniques.

Une mauvaise réponse, c’est un type d’erreur. Des données parasites écrites en base, un e-mail envoyé par erreur, un remboursement traité deux fois, un fichier qui fuite – c’est une tout autre catégorie. C’est pourquoi les limites des outils sont si importantes. L’auteur propose une liste de questions que quiconque envisage de donner à un agent l’accès à des systèmes réels devrait noter : à quels outils l’agent a-t-il accès, quelles actions sont en lecture seule, lesquelles nécessitent une validation, l’agent peut-il écrire dans les systèmes de production, les appels sont-ils logés, peut-on annuler une erreur, une entrée malveillante peut-elle tromper l’agent et lui faire détourner un outil.

L’idée clé de cette couche : de nombreux échecs d’agents sont causés précisément par une interaction fragile avec les outils – le raisonnement du modèle n’y est presque pour rien. Dès que l’agent obtient le droit d’agir, il a besoin d’une discipline d’ingénierie, et un prompt soigné ne suffit plus. Le principe pratique de l’auteur : traiter les outils comme des API de production – droits minimaux, schémas stricts, étapes de confirmation, prudence avec les opérations d’écriture.

Ce qui est intéressant, c’est que tout cela – outils, droits, schémas de confirmation – ressemble à une discussion sur l’architecture. Mais sous l’architecture se cache quelque chose de plus simple : la capacité de formuler clairement ce que l’agent doit faire, dans quel contexte et avec quelles contraintes. Sans cette formulation, même un agent bien conçu se met à « deviner » – et c’est alors que les outils deviennent dangereux.

Couche 3 : la mémoire et son cycle de vie

« La mémoire, ça semble simple. Que l’agent retienne ce qui est utile. Facile, non ? Pas tout à fait », écrit l’auteur. La mémoire se décline en quatre types : à court terme (ce qui se passe dans la tâche en cours), de session (ce qui s’est passé dans la conversation en cours), sémantique à long terme (les connaissances réutilisées dans le temps) et transactionnelle (l’état qui doit être exact : commandes, statuts, droits, validations). La mémoire à court terme, c’est essentiellement la fenêtre de contexte du modèle, avec ses limites bien connues : les prompts longs perdent l’information au milieu, et l’agent hérite de cette particularité.

C’est l’une des couches les plus difficiles, parce que la mémoire fonctionne ici comme un jugement permanent : que retenir, que oublier, à qui c’est visible, comment empêcher le contexte d’un utilisateur de fuiter dans la session d’un autre, comment ne pas laisser des données obsolètes empoisonner les décisions futures. L’auteur illustre le risque de façon parlante : un agent commercial qui se souvient de la politique de remise du trimestre précédent ; un agent médical qui mélange les notes de deux patients ; un agent financier qui retient une validation mais pas la condition à laquelle elle était rattachée. La conclusion tient en une phrase : la mémoire d’un agent fonctionne comme une base de données avec des conséquences – la considérer comme un bloc-notes est dangereux.

Pour le manager, cela se traduit par une question gênante à poser à tout prestataire ou fournisseur : qu’est-ce que votre agent retient exactement entre les interactions, et qui garantit qu’il ne confondra pas mes clients ? Le conseil de l’auteur : donner à la mémoire un cycle de vie – origine des données, date de péremption, droits d’accès, règles de suppression et séparation de la mémoire utilisateur, session, métier et système.

Couche 4 : le runtime – quand la « réflexion » devient une boucle

Au cœur du stack se trouve le runtime de l’agent, cette fameuse boucle : comprendre l’objectif, décider quoi faire ensuite, choisir un outil, l’utiliser, évaluer le résultat, interpréter et continuer, s’arrêter ou demander de l’aide. L’auteur relie ce pattern à l’approche ReAct (reasoning and acting) et souligne une chose simple : l’agent mène la tâche à son terme ; une seule réplique ne suffit pas.

Et c’est précisément là que tout casse. La boucle peut tourner à l’infini. Un outil peut renvoyer des données erronées. Le modèle peut mal interpréter un résultat. Une répétition peut accidentellement exécuter la même action deux fois. C’est pourquoi le runtime, c’est de la gestion d’exécution, et la formule « le LLM réfléchit, tout simplement » ne décrit pas la moitié du travail. Le conseil le plus important de tout l’article pour un manager est caché ici : ne concevez pas votre agent comme un seul long prompt. Concevez-le comme un processus de travail avec un état, des points de contrôle, des conditions d’arrêt et une vérification humaine là où c’est nécessaire.

C’est là que le cadre bascule. « Décrire un processus avec un état et des points de contrôle » – c’est exactement le travail qu’un manager fait quand il construit une procédure ou assigne une tâche à son équipe. La boucle de l’agent ressemble étrangement à la façon dont un collaborateur humain travaille : il reçoit une tâche, esquisse les étapes, fait quelque chose, regarde le résultat, s’ajuste. La différence, c’est que le collaborateur a du bon sens et la peur de se tromper, tandis que l’agent n’a que les limites que vous y avez inscrites à l’avance.

Couche 5 : observabilité, sécurité et gouvernance

La dernière couche enveloppe tout le stack, et l’auteur la qualifie de frontière entre la démo et un système auquel on peut faire confiance. C’est la couche qui permet à l’équipe de répondre : qu’a fait l’agent, pourquoi de cette façon, quel outil a-t-il appelé, qu’a renvoyé l’outil, combien a coûté l’exécution, a-t-il respecté les règles, a-t-il inventé, a-t-il révélé des données privées, a-t-il bouclé, un humain a-t-il validé l’étape risquée. Sans cette couche, écrit l’auteur, le débogage des agents devient du folklore – l’équipe débat de ce qui s’est passé au lieu de regarder.

Mais ensuite vient la distinction la plus importante, et elle est purement managériale. « L’observabilité vous dit ce qui s’est passé. La gouvernance décide ce qui est autorisé à se produire. » Un tableau de bord montrera que l’agent s’apprête à faire quelque chose de risqué. La gouvernance détermine qui peut l’arrêter, dans quelle condition et qui est propriétaire de cette décision. L’auteur renvoie directement à la classification des risques du OWASP Top 10 pour les LLM (où le prompt injection est cité comme menace majeure) et au NIST AI Risk Management Framework comme références.

Voici l’essentiel pour vous. Quand les fournisseurs dessinent un avenir où « les agents gèrent des processus complexes », une question disparaît discrètement : qui est responsable si l’agent se trompe. Cette couche répond honnêtement – aux points critiques, c’est un humain. Le conseil de l’auteur : ne pas s’arrêter aux logs – définir des règles d’escalade, des processus de validation, des pistes d’audit, des contrôles de politiques, des limites de budget et des conditions d’arrêt d’urgence.

Le point le plus faible : les coutures entre les couches

Ici l’article prend un virage facile à manquer, et c’est dommage. L’auteur écrit que le plus difficile dans le stack d’un agent n’est peut-être pas une couche en particulier – mais le tissu conjonctif entre elles. Le runtime choisit un outil, l’outil modifie l’état métier, la couche mémoire sauvegarde le résultat, le modèle l’interprète, la couche d’observabilité loge la décision, la couche de sécurité décide si l’étape suivante est autorisée. Si un seul de ces relais est décrit de manière floue, tout le système devient fragile.

Et là, l’auteur nomme une vérité peu romanesque : la fiabilité vient de choses « ennuyeuses » en ingénierie – machines à états finis, clés d’idempotence, retentatives avec protection, limites, périmètres de droits, tests, jeux d’évaluation, logs d’audit, chemins de rollback et points de contrôle avec intervention humaine. Un agent peut paraître intelligent, mais en production, c’est la discipline de conception qui garantit la fiabilité, et l’intelligence du modèle ne la garantit pas à elle seule.

Pour le manager, cette image de relais entre couches est étrangement familière. Dilution des responsabilités, perte de contexte lors des transmissions, coûts de coordination croissants – ce sont les problèmes de n’importe quelle équipe réelle où une tâche passe de main en main. C’est pourquoi la décision « un agent ou plusieurs » doit se prendre, selon l’auteur et le guide d’OpenAI, comme on décide d’embaucher ou non : commencer par un seul, en tirer le maximum et ne complexifier la structure que lorsqu’il ne suffit plus. C’est la même logique qui sous-tend le rapport de Google Cloud sur le nouveau rôle du manager comme superviseur d’une équipe d’agents – sauf que le fournisseur dessine cinq agents autonomes dès aujourd’hui, tandis que les ingénieurs conseillent honnêtement de commencer par un seul et des coutures bien décrites.

Que faire de tout cela en pratique, en tant que manager

L’auteur conclut son article par cette formule : « Les agents ne sont pas de la magie. C’est de l’autonomie gérée » et propose une checklist : avant de lancer un agent, poser une question plus profonde que « est-ce que ça marche ». La bonne question : « peut-on faire confiance à cet agent quand il a de vrais utilisateurs, de vraies données, de vrais outils, de vrais coûts et de vraies conséquences ». Une démo survit avec un prompt réussi. La production exige une architecture, des tests, des droits, une discipline de mémoire, de l’observabilité, de la protection et un responsable clairement identifié.

Traduisons cela en étapes pour un manager qui n’écrit pas de code, mais veut comprendre s’il a une tâche pour un agent et s’il est prêt.

D’abord, trouvez un candidat. Passez en revue votre semaine et listez les processus qui se répètent, qui comportent plusieurs étapes et contiennent des embranchements « ça dépend de la situation ». Pas les demandes ponctuelles comme un brouillon d’e-mail ou un résumé de réunion – pour cela, un agent n’est pas nécessaire, un simple prompt suffit. Ce sont les processus qui comptent : traitement des demandes entrantes, rapport régulier à partir de plusieurs sources, tri initial de CV. C’est le critère de Benedict Evans : l’IA automatise bien les tâches et mal les jugements, donc un agent se justifie là où le processus laisse une place au jugement. Un exemple concret de cette transition : l’analyse de données agentique, où la différence entre un chat et un agent devient évidente sur trois vrais fichiers de manager.

Ensuite, décrivez le processus précisément comme un workflow en plusieurs étapes – c’est exactement ce que préconise l’article. Un seul long prompt ne fonctionne pas ici. Décomposez la tâche en étapes, associez à chacune une action concrète et l’outil nécessaire, décrivez les cas atypiques et marquez obligatoirement les étapes où la décision doit revenir à un humain. Si vous ne pouvez pas décrire clairement le processus avec des mots, aucun agent ne l’exécutera. C’est le test de maturité, et vous pouvez le faire dès maintenant, dans un simple chat.

Voici un prompt qui transforme votre procédure de travail en brouillon de workflow pour un futur agent – selon la même logique des cinq couches décrite par l’auteur. L’exemple utilise un processus de support type – le traitement des demandes du matin ; remplacez-le par le vôtre :

Un bon résultat marque les remboursements et les litiges de paiement comme arrêt obligatoire avec transmission à un humain – si le modèle ne l’a pas fait, la tâche est formulée de manière trop vague.

Une fois le brouillon prêt, soumettez-le à un second modèle pour vérification – qu’il trouve les failles avant que vous ne transmettiez la tâche aux développeurs. Ci-dessous, à titre d’exemple, un brouillon déjà un peu « peigné » du même processus de support ; insérez le vôtre à la place :

Un bon revieweur s’arrêtera d’abord sur l’étape 4 : un remboursement de moins de 50 euros traité par l’agent seul, sans point de contrôle – une action monétaire sans signature humaine, c’est la faille principale de ce brouillon.

Remarquez : ces deux étapes se font dans un simple chat, avant même qu’il soit question de développer un véritable agent. L’erreur la plus coûteuse, c’est de commander un agent complexe pour un processus que vous n’avez pas su décrire clairement vous-même.

En résumé

« L’autonomie gérée » – voilà le nom exact de ce qu’un manager déploie réellement : plus l’agent reçoit de liberté, plus il a besoin de structure autour de lui, et concevoir cette structure – y compris décider où l’autonomie est acceptable et où la signature humaine reste nécessaire – est par nature un travail de management. La responsabilité ne vous quitte pas, elle se déplace de l’exécution vers la conception des points de contrôle.

Et la compétence fondamentale sous tout cela reste la même – que ce soit pour un simple prompt ou pour un agent. C’est la capacité de formuler précisément ce que vous voulez, sur quelles données et avec quelles contraintes – en somme, les mêmes 5 éléments d’un bon prompt, appliqués à un processus entier. Sans cette compétence, ni le prompt ni l’agent ne fonctionnent. C’est par là qu’il faut commencer.

Articles connexes

Managers et IA : les plus assidus – mais pas pour manager

Pourquoi les pilotes IA en usine meurent entre la démo et l'atelier

40 cas GigaChat de Sber : ce que dit vraiment notre benchmark

Comment déployer l'IA dans l'industrie : plan d'action en 5 étapes pour les dirigeants