L’année dernière, un client m’a demandé de mettre en place une veille technique automatisée. Le besoin était simple en apparence : surveiller une trentaine de flux RSS, filtrer le bruit, classer les articles par thème, résumer les pertinents, envoyer un mail chaque matin. Le genre de tâche qu’on confie volontiers à un stagiaire, sauf qu’il n’y avait pas de stagiaire.

J’ai commencé par regarder ce qui existait. Les outils SaaS de veille faisaient le job, mais mal : filtres rigides, pas de classification par thème métier, résumés génériques. Les scripts maison s’accumulaient vite, et personne ne savait ce qui tournait ni pourquoi ça avait raté hier. Et puis il y avait les agents autonomes, OpenClaw, Hermes Agent, et toute la vague qui promet de déléguer le travail à un LLM qui décide, agit, apprend. J’ai regardé, j’ai lu les incidents sécurité documentés chez Cisco, et j’ai vu un agent qui, en théorie, pouvait envoyer un mail à un client sans que personne ne l’ait validé, simplement parce que le LLM avait jugé que c’était la bonne action.

Ce n’est pas un problème de réglage, c’est un problème de philosophie. Un agent qui décide seul de ses actions n’est pas un outil que je peux auditer, rejouer ou interrompre avec confiance : c’est une boîte noire qui consomme des tokens à chaque boucle, dont les décisions ne sont pas reproductibles, et dont la surface d’attaque s’élargit à chaque skill qu’on lui ajoute. Pour un usage personnel ou expérimental, je comprends l’attrait, mais pour un pipeline métier planifié qui tourne toutes les heures, qui envoie des mails et qui touche des données clients, c’est un non-sens.

Alors j’ai construit autre chose, mais pas un agent autonome. Un agent supervisé : un worker planifié qui exécute un plan déterministe, où le LLM intervient seulement aux endroits où il est utile (classer, résumer, rédiger un brouillon), et où tout le reste, le fetch, la déduplication, le routage, l’envoi, est du code explicite, traçable et rejouable.

Ce texte explique pourquoi j’ai fait ce choix, quels enjeux il résout et ce que ça change concrètement. C’est le premier d’une série de trois : le deuxième comparera les approches (plateforme tout-en-un, framework, sur-mesure), et le troisième détaillera l’implémentation.

Définition d’un “agent supervisé”

Le terme “agent supervisé” est volontairement en tension avec l’expression consacrée “agent autonome”. Dans l’industrie, un agent autonome désigne un système piloté par un LLM qui, à chaque itération, décide de la prochaine action, sélectionne un outil, interprète le résultat, recommence. La boucle est au centre, le code est à la marge. Un agent supervisé renverse le rapport : le code est au centre, le LLM est à la marge, et il n’y a pas de boucle.

Concrètement, un agent supervisé est un worker planifié qui s’exécute sans intervention humaine sur un déclencheur (un cron, un événement, un lancement manuel), mais qui suit un plan déterministe écrit en code, pas un plan improvisé par un modèle. Le LLM est invoqué uniquement à des points d’extension explicites (extraction, résumé, classification), avec un schéma de sortie strict qui borne ce qu’il peut retourner. Chaque exécution est tracée : les entrées, les sorties et les décisions sont horodatées et auditées. Un humain peut interrompre, rejouer et auditer n’importe quelle exécution. “Autonome” ici signifie “tourne sans surveillance selon un calendrier”, pas “décide seul de ses actions à l’exécution”.

Cette définition repose sur quatre piliers qui guident le reste de la série et que je réutiliserai dans les articles suivants.

Le déterminisme : le pipeline est une séquence explicite de Steps, et l’ordre d’exécution ne dépend pas d’un modèle. Le LLM produit un contenu à l’intérieur d’un Step, il ne choisit pas le Step suivant.

Le contrôle : un humain peut interrompre une exécution en cours, la relancer, la rejouer, examiner chaque étape. Les actions à risque (envoyer un mail, répondre à un client) sont encadrées par des règles explicites, pas par un jugement probabiliste.

L’auditabilité : chaque run trace et persiste ses entrées, ses sorties et ses métadonnées. Une décision prise il y a trois mois peut être retrouvée, comprise et, si besoin, corrigée.

L’efficacité token : comme les appels LLM sont ciblés et non conversationnels, la consommation de tokens est prévisible et bornée. Chaque point d’extension peut utiliser le modèle le mieux adapté à sa tâche, un modèle bon marché pour classifier, un modèle plus solide pour synthétiser, plutôt qu’un seul modèle pour tout.

Un pipeline d’agent supervisé ressemble à ça :

flowchart LR
    A[fetch] --> B[dedupe]
    B --> C[classify<br/>LLM Step]
    C --> D[summarize<br/>LLM Step]
    D --> E[deliver]

Les Steps marqués “LLM Step” invoquent un LLM avec un schéma de sortie strict et des limites de consommation. Les autres Steps sont du code déterministe : fetch HTTP, déduplication, envoi de mail, écriture en base. Le LLM n’a jamais la parole sur le flow, seulement sur le contenu d’un Step précis. C’est cette asymétrie qui change tout le reste : le contrôle revient au code, l’intelligence au modèle, et la frontière entre les deux est lisible dans le pipeline lui-même.

Les enjeux que l’autonomie ne résout pas

L’argument pour l’autonomie est séduisant parce qu’il déplace la charge : on n’écrit plus de logique, on la délègue au modèle. En pratique, ce déplacement ne fait pas disparaître les enjeux, il les rend opaques. Quatre d’entre eux reviennent systématiquement dès qu’un agent full-LLM touche un processus métier planifié.

Le coût

Un agent autonome fonctionne en boucle : le modèle est appelé, il choisit une action, il exécute l’action, il renvoie le résultat au modèle, qui choisit la suivante. Chaque itération consomme des tokens d’entrée et de sortie, et la longueur du contexte grossit à chaque tour. La consommation n’est pas bornée par construction : elle dépend du nombre d’itérations, de la verbosité du modèle, des aller-retours nécessaires pour atteindre un état terminal. Sur un cron qui tourne toutes les heures, la facture devient un paramètre non maîtrisé du système, pas un coût prévisible.

Un agent supervisé, à l’inverse, appelle le LLM à des points d’extension fixes, avec un prompt borné et un schéma de sortie strict. La consommation se calcule par Step, se budgète par run, et se cappe par des limites explicites. Le même pipeline exécuté aujourd’hui et dans six mois consomme le même ordre de grandeur de tokens, parce que la structure ne change pas. Ce n’est pas une optimisation, c’est une propriété architecturale.

La sécurité

C’est le point où l’écart devient qualitatif, pas quantitatif. Un agent autonome donne au LLM le contrôle des actions, donc la capacité d’agir sur le monde réel : appeler des API, écrire en base, envoyer des messages, exécuter du code. Sa surface d’attaque s’élargit à chaque skill qu’on lui ajoute, parce que chaque skill est une nouvelle capacité potentiellement détournable.

Les incidents documentés ne sont pas théoriques. La recherche publiée par Cisco sur la sécurité d’OpenClaw a mis en évidence des vecteurs de prompt injection et d’exfiltration de données via des skills tiers. Un mainteneur du projet a lui-même déclaré que l’outil était trop dangereux pour un utilisateur qui ne sait pas lancer une ligne de commande. Le gouvernement chinois a interdit OpenClaw aux banques, entreprises d’État et agences en mars 2026. Aucun de ces signaux ne relève de l’anecdote : ils pointent tous vers la même cause, à savoir qu’un agent qui décide seul de ses actions est, par construction, un agent qu’on ne peut pas contraindre a priori.

Un agent supervisé sépare radicalement la décision de l’action. Le LLM produit un contenu (une catégorie, un résumé, un brouillon), et ce contenu passe par une couche déterministe avant de déclencher quoi que ce soit. Les actions à risque sont protégées par des règles humaines, pas par un jugement de modèle. On peut ajouter un garde-fou sans modifier le prompt, parce que le garde-fou vit dans le code, pas dans l’instruction. L’attaque par prompt injection ne disparaît pas, mais son rayon d’action se réduit : le modèle peut bien produire n’importe quoi, le code autour décide de ce qui se passe ensuite.

La confiance

Un agent full-LLM est difficile à auditer parce que son comportement émerge de l’interaction entre un prompt, un modèle, un contexte et une série de décisions probabilistes. Deux runs identiques peuvent produire deux résultats différents. Quand quelque chose se passe mal, la question “pourquoi a-t-il fait ça ?” n’a pas de réponse déterministe, seulement une explication probabiliste reconstruite après coup.

Un agent supervisé produit, à chaque exécution, une trace horodatée qui enregistre l’entrée, la sortie et les métadonnées de chaque Step. Les runs sont rejouables : on peut reprendre une exécution échouée, examiner le Step fautif, corriger, relancer. Les LLM Steps sont marqués comme tels dans la trace, avec leur modèle, leurs tokens et leur latence, ce qui rend la part probabiliste visible et localisée plutôt que diffuse. La confiance ne repose pas sur une intuition de fiabilité, elle repose sur la capacité à retrouver, comprendre et corriger.

La conformité

Pour un processus métier qui touche des données clients, des décisions automatisées ou des communications externes, la reproductibilité n’est pas un confort, c’est une exigence réglementaire. Un audit peut demander, pour une décision prise à une date donnée, de retracer les entrées, le raisonnement et la sortie. Avec un agent full-LLM, la décision d’origine n’est pas reproductible : le modèle a évolué, le contexte a changé, et la même entrée ne donnerait pas nécessairement la même sortie. Le run est un événement unique, non rejouable.

Le déterminisme d’un agent supervisé rend la reproductibilité possible, parce que la structure du pipeline ne change pas entre deux exécutions et que chaque Step est conçu pour être idempotent. Pour un auditeur, la trace d’un run est un dossier : entrées horodatées, Steps ordonnés, sorties persistées, décisions localisées. La part LLM reste probabiliste, mais elle est circonscrite, identifiée et bornée, et son impact sur la décision finale est mécaniquement auditable.

argentic-mw comme incarnation

La plateforme que je construis, argentic-mw, est une incarnation de cette philosophie. Elle ne l’invente pas, elle l’applique à trois agents métier concrets qui partagent un Socle commun. Le propos n’est pas de détailler l’implémentation ici, c’est l’objet du troisième article, mais de montrer comment les quatre piliers se matérialisent dans un système réel plutôt que dans un manifeste abstrait.

Trois agents composent le périmètre actuel. Le Watch Agent fait de la veille : il récupère des flux RSS et Atom, déduplique les nouveaux articles, les classe par thème, les résume et les délivre par mail avec persistance. Le Web Stats Agent collecte des statistiques depuis Plausible et Google Search Console, agrège, compare à des sites de référence, recommande des améliorations, suggère de nouvelles références, et délivre à son tour. Le Zendesk Tickets Agent récupère les nouveaux tickets, classe chaque ticket, détermine un mode de réponse par une rule table, route vers le support ou l’avant-vente, et soit envoie une réponse automatique, soit produit un brouillon pour validation humaine.

Les trois partagent le même Socle, qui exécute le pipeline comme une simple boucle sur une liste de Steps. C’est volontairement trivial : pas de framework d’orchestration, pas de moteur de workflow, pas de graphe implicite. La lisibilité du Socle est la condition du déterminisme, parce qu’un exécutant qu’on ne comprend pas ne peut pas être audité.

Le déterminisme se lit dans le pipeline de chaque agent : l’ordre des Steps est fixé par le code, le LLM ne choisit jamais l’étape suivante. Dans le Zendesk Agent, la décision de répondre automatiquement ou de produire un brouillon n’est jamais prise par le LLM : il classifie le ticket, et une rule table éditée par un humain associe chaque catégorie à un mode de réponse. Ajouter un nouveau cas de réponse automatique, c’est ajouter une ligne dans une table et un fichier de template, pas modifier un prompt. La précision vient de la classification, qui est là où le langage naturel demande à être compris ; la décision vient de la règle, qui est là où le déterminisme est exigé.

Le contrôle se matérialise par les garde-fous qui entourent les actions à risque. La réponse automatique au client est l’action la plus dangereuse du système, donc la plus gardée : un double-signal (regex et catégorie LLM), un kill switch global, des plafonds de débit par run et par agent, un seuil de confiance en dessous duquel on bascule en brouillon, un journal d’audit, une déduplication. Chacun de ces garde-fous vit dans le code, pas dans l’instruction, et aucun ne dépend de la bonne volonté du modèle.

L’auditabilité vient du tracing par Step et du cache de replay. Chaque Step trace son entrée, sa sortie et ses métadonnées ; les LLM Steps ajoutent un bloc d’usage avec le modèle, les tokens et la latence. Les runs sont rejouables parce que chaque Step est conçu idempotent et que le cache permet de sauter les Steps déjà exécutés sans doublon d’effet de bord.

L’efficacité token vient de ce que chaque LLM Step a sa propre configuration : un modèle, des limites de consommation, un prompt éditable sans redéploiement. La classification des tickets utilise un modèle bon marché, la rédaction du brouillon un modèle plus solide, la comparaison de statistiques un modèle intermédiaire. La plateforme ne paie pas un modèle coûteux pour une tâche triviale, et ne sous-équipe pas une tâche difficile avec un modèle économique. Le choix du modèle est local au Step, pas global à la plateforme.

Le scheduler, enfin, est conçu en actif-passif avec élection de leader via Postgres : plusieurs instances tournent, une seule est active, et le passage de relais se fait automatiquement à l’expiration du bail. Les workers sont stateless, tout l’état vit en base, et la capacité s’ajoute en ajoutant un worker sur un nouveau nœud. C’est de l’ingénierie de plateforme classique, pas de l’IA, et c’est précisément le propos.

Ce que ce n’est pas

Le propos serait incomplet sans dire ce qu’il n’est pas, parce que la frontière entre prise de position et dogme est facile à franchir.

Ce n’est pas une critique de l’IA générative. Le LLM est central dans un agent supervisé, et il fait des choses que le code déterministe ne sait pas faire : comprendre un ticket écrit en langage naturel, résumer un article, rédiger un brouillon de réponse, comparer des séries de statistiques et proposer une interprétation. La question n’est pas de savoir si le LLM est utile, il l’est ! La question est de savoir où il intervient dans le système, et c’est là que le choix se joue. Un LLM à sa place, contraint par un schéma de sortie et entouré de code, est un composant fiable. Un LLM partout, en charge du flow et des actions, est un composant dont on perd la maîtrise.

Ce n’est pas un rejet de l’autonomie en général. L’autonomie a des cas d’usage légitimes, et je ne prétends pas qu’ils disparaissent. La recherche ouverte, l’exploration d’un espace de solutions, l’agent personnel qui apprend les préférences d’un utilisateur, le prototypage rapide où l’on accepte le non-déterminisme pour aller vite, sont des contextes où la boucle LLM-driven a du sens. OpenClaw et Hermes Agent répondent à ces usages, et ils ont leur public. Mon propos porte sur une autre classe de besoins : des pipelines métier planifiés, qui tournent en production, qui touchent des données et des clients, et pour lesquels l’audit, le contrôle et le coût borné ne sont pas optionnels. Le critère de choix n’est pas “autonome ou pas”, c’est “quelles sont les conséquences d’une décision erronée, et qui les assume”.

Ce n’est pas non plus une solution universelle. argentic-mw répond à une famille de besoins, pas à tous. Les agents supervisés excellent sur des pipelines linéaires à Steps ordonnés, où les points d’extension LLM sont identifiables à l’avance et où les actions à risque sont nommées. Ils supposent qu’on sait décrire le processus, qu’on accepte de l’écrire en code, et qu’on veut le maîtriser. Pour des workflows où la structure émerge à l’exécution, où les actions possibles ne sont pas énumérables à l’avance, ou où la valeur est précisément dans l’adaptation, le modèle supervisé est un mauvais fit, et ce n’est pas un défaut qu’il faudrait corriger, c’est une délimitation.

Conclusion

Le déterminisme n’est pas un renoncement, c’est un choix de maîtrise. Renoncer à ce que le LLM décide seul du flow, c’est accepter de l’écrire en code, et c’est précisément ce qui rend le système auditable, rejouable, borné et défendable. Le LLM conserve toute sa place, mais à sa place : produire du contenu à l’intérieur d’un Step, pas décider de l’enchaînement. Cette asymétrie est le propos, et elle se décline en quatre propriétés concrètes, le déterminisme, le contrôle, l’auditabilité et l’efficacité token, qui ne sont pas des slogans mais des propriétés vérifiables sur une trace.

Ce texte est le premier d’une série de trois. Le deuxième comparera les approches : faut-il adopter une plateforme full-LLM tout-en-un comme OpenClaw, construire sur un framework comme LangGraph ou Dify, ou bâtir un socle sur-mesure ? J’y proposerai un cadre de décision à six critères, pour que la réponse dépende du contexte plutôt que d’un parti pris (voir Quand choisir une plateforme LLM tout-en-un, quand construire sur-mesure). Le troisième refermera la boucle sur l’implémentation : comment argentic-mw exécute concrètement ses trois agents, du Socle commun aux pipelines métier, avec le détail des Steps, des garde-fous et du scheduler (voir Du manifeste au code : comment argentic-mw exécute ses agents).