Agents, harness, boucles, graphes : les quatre étages d'un agent autonome

On entend parler d'agents, puis de harness, puis de boucles, puis de graphes, souvent dans la même phrase, et on finit par croire que c'est quatre façons de dire la même chose. Ce n'est pas le cas. Ce sont quatre étages qui s'empilent, et chacun règle un problème que l'étage du dessous ne sait pas régler.

Je fais avancer taraxe.com avec ces quatre étages depuis octobre 2026. Ce guide les explique un par un, avec ce que chacun ajoute, des outils concrets, l'endroit où vous gardez la main, et ce qui casse quand on saute une marche.

La séquence en une image

En une phrase chacun :

Agent

un modèle de langage qui, pour accomplir une tâche, choisit lui-même quels outils appeler et dans quel ordre.

Harness

le programme qui fait tourner l'agent : il lui donne ses outils, son contexte, ses permissions et sa mémoire, et rattrape ses erreurs.

Boucle

ce qui relance l'agent sans qu'un humain lui écrive : une horloge, un événement, une condition.

Graphe

la liste des tâches et de leurs dépendances, avec l'état de chacune, que la boucle relit à chaque tour pour savoir quoi faire.

1. L'agent : un modèle qui agit

Un modèle seul répond à un message. Un agent, c'est un modèle à qui on a donné des outils, et qui décide lui-même de s'en servir : lire un fichier, lancer une commande, chercher sur le web, envoyer un courrier avec Cachet, poser une question avec Aval.

Il y a déjà une petite boucle à l'intérieur, et c'est elle qui fait la différence avec un chatbot :

tant que le modèle demande un outil :
    exécuter l'outil
    lui rendre le résultat
donner la réponse finale

Le modèle demande un outil, on l'exécute, on lui rend le résultat, il en demande un autre, et ainsi de suite jusqu'à ce qu'il estime avoir fini. Pour corriger un bug, il peut lire dix fichiers, lancer les tests trois fois et modifier deux lignes, sans qu'on lui dise chaque étape.

Ce qu'un agent ne sait pas faire tout seul :

• Se souvenir. Quand la conversation se termine, tout ce qu'il savait disparaît.
• Repartir. Une fois sa réponse donnée, il s'arrête et attend le message suivant.
• Agir au-delà de ses outils. Il ne peut faire que ce que les outils qu'on lui donne permettent.

Ce sont les trois étages suivants qui comblent ces manques.

2. Le harness : ce qui fait tourner l'agent

Le mot vient de l'anglais harness, le harnais. C'est tout ce qu'il y a autour du modèle : le programme qui exécute la petite boucle du dessus, qui branche les outils, et qui décide de ce que l'agent a le droit de faire.

Un bon harness s'occupe de :

• les outils : fichiers, terminal, navigateur, et les serveurs MCP qu'on y branche ;
• le contexte : ce que l'agent lit avant de commencer (dans Claude Code, le fichier CLAUDE.md), et ce qu'on résume quand la conversation devient trop longue ;
• les permissions : ce qui est permis, ce qui demande une confirmation, ce qui est interdit ;
• la mémoire : des fichiers que l'agent relit d'une session à l'autre ;
• les erreurs : un outil qui plante, un réseau qui coupe, une commande qui ne finit pas.

Claude Code est un harness. Cursor, Codex CLI et l'application ChatGPT en sont aussi, chacun à sa façon. Si vous construisez le vôtre, le Claude Agent SDK fournit la même mécanique que Claude Code, sous forme de bibliothèque.

Ce qu'on remarque vite : avec le même modèle, deux harness donnent des résultats très différents. Ce sont les outils disponibles, le contexte de départ et les garde-fous qui font une bonne partie du travail.

Les permissions se règlent à l'avance. Dans Claude Code, elles vivent dans .claude/settings.json. Par exemple, autoriser les tests, interdire de forcer un push ou de déployer en production :

{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(git checkout -b:*)"],
    "deny": ["Bash(git push --force:*)", "Bash(wrangler deploy:*)"]
  }
}

L'humain à cet étage

Quand l'agent veut faire quelque chose qui n'est pas autorisé d'avance, le harness vous demande. Dans un terminal, c'est une question à laquelle vous répondez au clavier. Ça marche tant que vous êtes devant l'écran, et seulement tant que vous y êtes.

3. La boucle : ce qui le relance

Jusqu'ici, rien ne se passe si vous n'écrivez pas. La boucle remplace votre message par un déclencheur, et l'agent repart tout seul.

Il y a trois sortes de déclencheurs :

• une horloge : toutes les heures, chaque matin à 8 h ;
• un événement : une PR mergée, un mail reçu, un webhook, un paiement ;
• une condition : un colis livré, un prix qui passe sous un seuil, une page qui change. C'est ce que fait Réveil, l'outil de taraxe qui réveille un agent quand quelque chose arrive.

Et plusieurs façons de les brancher, selon l'endroit où tourne l'agent :

• Dans Claude Code, /loop relance une consigne à intervalle régulier, dans la session ouverte. Pratique pour surveiller un déploiement pendant une heure, mais la boucle s'arrête avec la session.
• Une tâche planifiée survit aux sessions. Claude Code dans le cloud sait lancer une session sur une routine planifiée. Sur votre machine, un cron qui lance Claude Code en mode non interactif fait la même chose :

# Toutes les heures, à la minute 4
4 * * * * cd ~/mon-projet && claude -p "$(cat consigne-boucle.md)"

• Dans n8n, un nœud Schedule Trigger ou Webhook démarre le workflow, et un nœud AI Agent fait le travail.
• Sur Cloudflare, un Cron Trigger réveille un Worker ; Cloudflare Workflows ajoute des étapes qui survivent aux pannes, des pauses de plusieurs jours, et l'attente d'un événement extérieur.

Ce que la boucle change

Passer d'un agent qu'on lance à un agent qui se lance seul, ça change trois choses, et elles comptent plus que le choix de l'outil.

• Personne n'est devant l'écran. Les questions de permission du harness n'ont plus personne pour y répondre. Tout ce qui est permis doit être réglé d'avance, et le reste doit passer par un canal qui vous atteint ailleurs.
• L'agent repart de zéro à chaque tour. Il ne se souvient pas du tour précédent. Il lui faut un endroit où lire où il en est : c'est le rôle de l'étage suivant.
• La plupart des tours ne trouvent rien à faire. Une boucle horaire, c'est vingt-quatre tours par jour. Ceux qui n'ont rien à faire doivent ne rien faire, et surtout ne rien vous écrire.

4. Le graphe : ce qui lui dit quoi faire

Une boucle sans graphe relance l'agent avec la même consigne, et l'agent doit deviner à chaque fois ce qui a déjà été fait. Il refait des choses, en oublie d'autres, ou en commence trois en même temps.

Le graphe règle ça. C'est une liste de tâches, les nœuds, reliées par leurs dépendances : la page des prix attend les factures, qui attendent les tests. Chaque nœud a un état (à faire, en cours, bloqué, fini). À chaque réveil, la boucle relit le graphe, prend un nœud dont toutes les dépendances sont finies, le fait, et écrit le nouvel état :

réveil
  └─ lire l'état            (le graphe)
  └─ choisir un nœud débloqué
  └─ le faire               (l'agent, dans son harness)
  └─ écrire le nouvel état
  └─ se rendormir           (la boucle)

Le graphe vit en dehors de l'agent, dans un fichier ou une table. C'est ce qui permet à un agent sans mémoire d'avancer pendant des semaines : il oublie tout entre deux tours, mais le graphe, lui, n'oublie rien.

Deux sortes de graphes

Le mot recouvre deux choses qu'on confond souvent.

• Le graphe d'étapes décrit comment faire une tâche : étape A, puis B ou C selon le résultat, puis D. Les étapes sont connues d'avance. C'est un workflow n8n, un Cloudflare Workflow, ou un graphe LangGraph. L'agent y joue souvent le rôle d'une étape parmi d'autres.
• Le graphe de tâches décrit quoi faire : une feuille de route, avec des tâches assez ouvertes pour qu'un agent les mène de bout en bout. C'est l'agent qui le déroule, et il peut même y ajouter un nœud quand il découvre un travail qui manque.

Pour un traitement qui se répète à l'identique, une facture à classer, un formulaire à vérifier, le graphe d'étapes est plus sûr. Pour faire avancer un projet, le graphe de tâches laisse plus de place au jugement de l'agent. Le format du fichier, les états et la consigne à donner sont détaillés dans le guide Faire tourner un agent en boucle sur un graphe de tâches.

Où garder la main, étage par étage

On parle de « human-in-the-loop » comme d'une seule chose. En pratique, vous intervenez à chaque étage, et pas de la même façon.

L'étage de la boucle est celui qu'on oublie. Dès que l'agent tourne sans vous, la question de permission dans le terminal ne sert plus à rien : il lui faut un moyen de vous joindre ailleurs. C'est pour ça que j'ai fait Aval. Branché en MCP, il donne à l'agent un outil ask_human : la question arrive sur Telegram, ou par mail, avec un bouton par réponse. L'agent note la question dans le graphe, passe le nœud en « bloqué » et termine son tour. Aux tours suivants, il relit la réponse sans l'attendre.

Pour Claude Code, le branchement tient en une commande : claude mcp add --transport http aval https://www.taraxe.com/aval/mcp, puis /mcp pour vous connecter avec votre mail.

Un exemple réel : comment avance taraxe.com

Voici les quatre étages tels qu'ils tournent aujourd'hui sur ce site.

Les règles tiennent en quelques lignes : jamais plus de deux nœuds en cours à la fois, une branche et une PR par nœud, un tour sans changement ne m'écrit rien, une question sans réponse depuis deux jours fait passer à un nœud indépendant. Et l'agent ne merge jamais : le merge, c'est moi, quand j'ai relu.

Une chose que je n'avais pas prévue : quand je réponds à une question sur mon téléphone, rien ne réveille l'agent tout de suite. Avec une boucle horaire, ma réponse pouvait attendre près d'une heure avant d'être lue. Maintenant, après chaque question, l'agent se programme quelques relectures rapprochées, à quelques minutes puis à une demi-heure, avant de revenir au rythme horaire.

Par où commencer

La tentation, c'est de monter directement au dernier étage. Mieux vaut grimper une marche à la fois, et ne monter que quand l'étage actuel coince.

1. Un agent dans un harness, à la main. Vous lancez Claude Code ou Cursor, vous donnez une tâche, vous regardez. C'est là que vous apprenez ce qu'il fait bien, et ce qu'il ne faut pas le laisser faire.
2. Des permissions et une consigne écrites. Quand vous répondez toujours oui à la même question, autorisez-la. Quand vous répétez toujours la même remarque, écrivez-la dans CLAUDE.md.
3. Une boucle, quand vous vous surprenez à relancer la même consigne tous les jours. Commencez par une tâche courte et sans risque : relire les PRs ouvertes, vérifier un déploiement.
4. Un graphe, quand la boucle commence à refaire ou à oublier des choses. Un fichier de quelques nœuds suffit.
5. Un canal vers vous, dès que l'agent tourne sans que vous regardiez.

Les pièges, étage par étage

• Agent : trop d'outils. Chaque outil branché, c'est une description de plus à lire et une action de plus possible. Donnez-lui ceux dont la tâche a besoin.
• Harness : des permissions trop larges. Tout autoriser pour ne plus être dérangé, c'est accepter qu'une erreur parte en production. Interdisez explicitement ce qui ne se rattrape pas.
• Boucle : des tours qui parlent pour ne rien dire. Un « rien de neuf » par heure, et vous arrêtez de lire au bout de deux jours, y compris le jour où c'est important.
• Boucle : attendre une réponse dans le tour. Un tour bloqué sur une question empêche tout le reste d'avancer. On pose, on note, on relit au tour suivant.
• Graphe : deux écrivains. Deux boucles qui modifient le même fichier finissent par s'écraser. Un seul agent écrit l'état.
• Graphe : des nœuds trop gros. Une PR que vous n'avez pas le courage de relire reste ouverte, et tout ce qui en dépend attend.
• Partout : une question expirée prise pour un oui. Sans réponse, on ne fait rien.

Questions fréquentes