Les 3 systèmes d'agents IA que tout développeur doit comprendre
Les échecs des agents
La plupart des systèmes d'agents n'échouent pas parce que le modèle est trop faible
Ils échouent parce que le système autour du modèle n'a jamais été conçu en tant que système
Les outils ne sont pas fiables
L'état disparaît entre les exécutions
L'agent réessaie sans rien apprendre
Le flux de travail bifurque d'une manière que personne ne peut inspecter
Puis chaque échec est imputé au modèle
C'est un mauvais diagnostic
Il existe trois couches d'ingénierie distinctes derrière un agent sérieux :
- le harnais donne au modèle un espace de travail
- la boucle donne au travail un cycle de rétroaction
- le graphe donne au processus un chemin explicite
Elles se chevauchent
Elles peuvent se contenir les unes les autres
Mais elles résolvent des problèmes différents
Un modèle décide Un harnais lui permet d'agir Une boucle lui fait prouver le résultat Un graphe contrôle ce qui est autorisé à se produire ensuite
La version en 30 secondes
L'ingénierie du harnais construit l'environnement d'exécution autour du modèle
Outils, mémoire, fichiers, autorisations, sandbox, routage, points de contrôle, traces et approbations humaines vivent ici
L'ingénierie de la boucle conçoit le travail répété et la rétroaction
L'agent produit quelque chose, le vérifie par rapport à des preuves, reçoit un signal d'échec utile et réessaie sous une règle bornée
L'ingénierie du graphe rend le flux de contrôle explicite
Elle définit les nœuds, les branches, les jonctions, le travail parallèle, les cycles autorisés, les transitions d'état et les chemins de sortie
La façon la plus simple de se souvenir de la différence est :
1HARNAIS = ENVIRONNEMENT2BOUCLE = RÉTROACTION3GRAPHE = FLUX
Cette distinction compte dès qu'un agent quitte une démo et commence à toucher à de vrais fichiers, API, clients, argent ou code de production
Pourquoi les gens les mélangent constamment
Les trois couches se situent autour du même modèle
Les trois affectent la fiabilité
Les trois peuvent inclure quelque chose qui ressemble à une boucle
Et dans un petit prototype, les trois sont généralement enfouies dans un seul script
Cela les fait paraître interchangeables
Elles ne le sont pas
Prenons un agent basique utilisant des outils
1demander au modèle2recevoir un appel d'outil3exécuter l'outil4retourner l'observation5demander à nouveau au modèle6s'arrêter quand terminé
Ce petit cycle fait partie de l'exécution
Mais les définitions des outils, le système de fichiers et le magasin d'état appartiennent au harnais
La politique de test et de nouvelle tentative est une décision de conception de boucle
Le choix entre chercheur, relecteur et éditeur est une décision de conception de graphe
Un seul logiciel peut contenir les trois couches à la fois
L'architecture la plus propre commence par les nommer séparément
Couche 1 : Ingénierie du harnais
Un modèle brut peut transformer une entrée en sortie
Il ne peut pas maintenir indépendamment l'état du projet, exécuter une suite de tests, inspecter un navigateur, écrire des fichiers en toute sécurité, appliquer des permissions ou reprendre demain là où il s'est arrêté aujourd'hui
Le harnais fournit ces capacités
La définition la plus simple est :
Le modèle est l'intelligence Le harnais est la machinerie qui rend cette intelligence utile
Supprimez le modèle de votre diagramme d'architecture
Tout ce qui reste visible fait probablement partie du harnais
C'est le passage en production que Boris Cherny souligne sans cesse avec Claude Code : hooks, exécutions planifiées, arbres de travail isolés, agents personnalisés et exécution parallèle ne sont pas des astuces de prompt
Ce sont des primitives de harnais
https://x.com/bcherny/status/2038454336355999749
Ce qui appartient à un harnais sérieux
Contexte
- instructions système
- connaissances récupérées
- état de la conversation
- politiques de tâche
- compétences et procédures opérationnelles
Surfaces d'action
- API
- contrôle du navigateur
- shell et exécution de code
- bases de données
- outils MCP
- agents spécialisés
Persistance
- fichiers
- points de contrôle
- état de session
- journaux de progression
- historique git
- mémoire à long terme
Contrôle d'exécution
- timeouts
- limites de nouvelles tentatives
- budgets de tokens et de coûts
- routage de modèle
- transferts
- portes d'approbation
Sécurité
- environnements isolés
- permissions au moindre privilège
- listes d'autorisation
- gestion des secrets
- autorisation humaine
Observabilité
- traces
- entrées et sorties des outils
- transitions d'état
- coûts et latence
- résultats d'évaluation
Où l'ingénierie du harnais montre sa valeur
Le travail sur le harnais devient critique lorsque les tâches durent plus longtemps qu'une fenêtre de contexte
Un agent de codage qui travaille pendant des heures ne peut pas se fier uniquement à l'historique de la conversation
Il a besoin d'artefacts durables qu'une autre session peut comprendre
Une configuration utile pourrait inclure :
- un initialiseur qui inspecte l'espace de travail
- un fichier de progression qui explique ce qui est fait et ce qui reste
- des commits git qui préservent les états de travail
- des points de contrôle avant les actions risquées
- des outils de vérification qui produisent des preuves claires
Ce n'est pas un meilleur prompt
C'est un meilleur environnement de travail
Commencez par l'ingénierie du harnais lorsque l'agent :
- ne peut pas accéder à la bonne capacité
- perd sa progression entre les sessions
- a des permissions trop larges
- se comporte différemment selon les environnements
- ne peut pas être mis en pause, inspecté ou repris
- produit des échecs que personne ne peut reconstruire
Couche 2 : Ingénierie de la boucle
Chaque agent utilisant des outils a déjà une petite boucle interne
1modèle -> action -> observation -> modèle
L'ingénierie de la boucle commence lorsque vous concevez intentionnellement les cycles autour de ce comportement
Le but n'est pas de faire répéter l'agent indéfiniment
Le but est de transformer une tentative unique en un processus géré
La boucle de vérification
La boucle externe la plus utile est simple
1CONSTRUIRE2 ↓3VÉRIFIER PAR RAPPORT À DES PREUVES4 ↓5RÉUSSI ? ── oui ──> STOP6 │7 non8 ↓9RETOURNER UN RETOUR SPÉCIFIQUE10 ↓11RÉESSAYER AVEC UNE LIMITE
La vérification peut être déterministe :
- les tests passent
- le schéma valide
- les liens résolvent
- les chiffres concordent
- les fichiers compilent
Ou elle peut nécessiter un relecteur :
- l'argument est complet
- le ton correspond au public
- les preuves soutiennent la conclusion
- le changement est correctement cadré
La règle est la même
Ne bouclez pas sur la confiance
Bouclez sur les preuves
"L'agent dit qu'il a terminé" n'est pas une preuve
"Les tests passent, les sources résolvent et le relecteur a approuvé la différence" est une preuve
L'avantage vient de la construction du cycle une fois et de laisser le système l'exécuter pour vous
Les tâches planifiées de Claude sont la version produit visible du même changement : définir un travail récurrent une fois et laisser le système le relancer sans un autre prompt manuel
La planification n'est que le déclencheur
Les vérifications, les retours et la condition de sortie sont ce qui transforme la tâche récurrente en une boucle d'ingénierie
https://x.com/claudeai/status/2026720870631354429
L'anatomie d'une boucle utile
Chaque boucle de production a besoin de sept éléments
1. Déclencheur
Ce qui démarre un autre cycle : une requête, un planning, un webhook, un test échoué, un nouveau document ou un résultat d'évaluateur
2. Objectif
Un état mesurable à atteindre, pas "continuer à améliorer"
3. État
Ce que la prochaine tentative doit savoir sans rejouer tout l'historique
4. Politique d'action
Ce que l'agent peut modifier, appeler, déléguer ou dépenser
5. Preuve
Tests, citations, différences, métriques, schémas ou revue humaine
6. Retour
Une explication concise de ce qui a échoué et de ce qui doit changer
7. Règle d'arrêt
Succès, nombre maximum de tentatives, épuisement du budget, timeout, erreur irrécupérable ou escalade humaine
Les boucles peuvent s'empiler
La boucle de l'agent effectue le travail
La boucle de vérification vérifie le travail
Une boucle d'événements réveille le système lorsque de nouveaux travaux arrivent
Une boucle d'amélioration étudie les traces de production et modifie le harnais lui-même
1BOUCLE D'ÉVÉNEMENTS2└── BOUCLE DE VÉRIFICATION3 └── BOUCLE DE L'AGENT45BOUCLE D'AMÉLIORATION PAR LES TRACES6└── met à jour les prompts, outils, politiques et évaluateurs
C'est pourquoi l'ingénierie de la boucle est plus vaste que l'ingénierie de prompt
Un prompt définit ce qui devrait se passer pendant un appel de modèle
Une boucle définit ce que le système fait après cet appel
Le coût est évident
Chaque nouvelle tentative, évaluateur et relecteur ajoute de la latence et des dépenses
Ajoutez une boucle lorsque le coût attendu de l'échec est supérieur au coût de la vérification
Couche 3 : Ingénierie du graphe
L'ingénierie du graphe pose une question différente
Pas "comment l'agent devrait-il fonctionner"
Mais "qu'est-ce qui est autorisé à s'exécuter ensuite"
Le travail devient des nœuds
Les transitions autorisées deviennent des arêtes
L'état se déplace à travers le graphe
Cette structure peut représenter :
- des séquences fixes
- des branches conditionnelles
- un déploiement parallèle
- des jonctions
- des cycles bornés
- des chemins de récupération
- des interruptions humaines
Ce que les ingénieurs de graphe décident réellement
Limites des nœuds
Quel travail appartient à du code normal, un appel LLM, un agent spécialisé ou une étape de révision humaine
Schéma d'état
Ce que chaque nœud peut lire ou mettre à jour et comment les résultats parallèles sont fusionnés
Conditions de routage
Quelles preuves font avancer le travail, reculer, bifurquer ou escalader
Concurrence
Ce qui peut s'exécuter en parallèle et ce qui doit attendre une jonction
Cycles et sorties
Où les nouvelles tentatives sont autorisées, combien de tentatives sont permises et ce qui rend le cycle sûr
Durabilité
Où l'exécution est sauvegardée et comment elle reprend après une interruption
Quand un graphe vaut la peine d'être formalisé
Utilisez un graphe lorsque le processus contient des branches significatives, des spécialistes parallèles, des approbations, des chemins de récupération ou des transferts avec état
Ne commencez pas par un graphe simplement parce que le flux de travail comporte plusieurs étapes
Si un seul agent capable avec trois outils peut résoudre la tâche, un graphe peut ajouter de la structure sans ajouter de valeur
Il existe un autre mode d'échec
Les équipes formalisent le flux de travail avant de comprendre le travail
Le résultat est un beau diagramme qui encode les mauvaises hypothèses
Commencez par un harnais simple
Étudiez les traces réelles
Formalisez les chemins qui restent stables
La prochaine étape après les boucles est de rendre la topologie d'exécution explicite
OpenAI a intégré la même idée dans Agent Builder : un canevas de flux de travail visible pour l'exécution multi-agents avec des garde-fous et des évaluations autour du graphe
https://x.com/OpenAIDevs/status/1975269388195631492
Comment les trois couches fonctionnent dans un système réel
Imaginez un agent de recherche et de publication qui produit un briefing sectoriel factuel
Le harnais fournit :
- des outils de navigation et de recherche
- un stockage de sources
- un espace de travail d'écriture
- une vérification des citations
- des permissions et des règles d'approbation
- des points de contrôle et des traces
Le graphe contrôle le chemin :
1RECHERCHE2 ↓3BROUILLON4 ↓5VÉRIFICATION DES FAITS ── échec ──> RECHERCHE6 │7 réussite8 ↓9REVUE ÉDITORIALE ── échec ──> BROUILLON10 │11 réussite12 ↓13APPROBATION HUMAINE14 ↓15PUBLIER
Les boucles vivent à l'intérieur de ce chemin
Le nœud de recherche peut chercher jusqu'à ce que la couverture des sources soit suffisante
Le nœud de rédaction peut réviser jusqu'à ce que l'évaluateur de style réussisse
Le nœud de vérification des faits peut retourner des affirmations non étayées exactes au lieu d'un rejet vague
L'imbrication est la partie importante
Le graphe s'exécute à l'intérieur du harnais
Les boucles s'exécutent à l'intérieur de parties du graphe
Le harnais fournit les outils, l'état et les preuves dont ces boucles ont besoin
Les couches se chevauchent car les couches logicielles réelles se chevauchent
Elles vous donnent néanmoins trois leviers différents lorsque le système échoue
Diagnostiquer l'échec avant de changer l'architecture
Symptôme
Commencez par
Correctif probable
L'agent ne peut pas accéder aux bonnes données en toute sécurité
Harnais
Meilleur contrat d'outil, permissions, sandbox et injection de contexte
L'agent oublie sa progression entre les sessions
Harnais
État durable, points de contrôle, artefacts de progression et compaction
La première tentative est proche mais peu fiable
Boucle
Évaluateur externe, tests déterministes, retour d'information actionnable et nouvelle tentative bornée
L'agent continue après le succès ou s'arrête avant la preuve
Boucle
États terminaux basés sur les preuves et règles d'arrêt conscientes du budget
Les spécialistes doivent s'exécuter dans un ordre contrôlé
Graphe
Nœuds, arêtes, conditions de routage et jonctions explicites
Un échec en plusieurs étapes est impossible à localiser
Graphe + harnais
Traces avec état alignées sur les nœuds et les transitions
Le processus change trop vite pour un diagramme fixe
Harnais plus simple
Garder la planification pilotée par le modèle et différer la formalisation du graphe
Ce tableau est plus utile que de débattre de la terminologie
Trouvez la couche responsable de l'échec
Corrigez cette couche en premier
Les erreurs coûteuses derrière les systèmes d'agents faibles
Construire le graphe trop tôt
Ne convertissez pas un processus métier imaginaire en quarante nœuds avant d'avoir observé un agent puissant effectuer le travail
Tracez d'abord
Formalisez ensuite
Laisser le créateur s'évaluer lui-même
L'auto-évaluation est utile mais partage les mêmes angles morts que la tentative originale
Préférez les vérifications déterministes lorsque c'est possible
Utilisez un contexte de relecteur isolé pour les vérifications subjectives
Exigez une approbation humaine pour les actions à fort impact
Définir la boucle comme "continuer à essayer"
Une nouvelle tentative illimitée n'est pas de la fiabilité
C'est une fuite de coûts
Chaque cycle a besoin de preuves fraîches, d'un nombre maximum de tentatives et d'un chemin d'escalade nommé
Transformer le harnais en entrepôt
Plus d'outils ne créent pas automatiquement un meilleur agent
Un ensemble d'outils surchargé augmente les erreurs de sélection
Un contexte bruyant augmente la confusion
Des permissions larges augmentent le risque
Donnez à l'agent le plus petit environnement capable d'accomplir le travail
Blamer le modèle pour les échecs d'orchestration
Un modèle plus puissant ne peut pas réparer de manière fiable un état obsolète, des API cassées, des schémas d'outils ambigus ou des conditions de sortie manquantes
Ne mettez pas à niveau le modèle avant d'avoir prouvé que le modèle est le problème
Une liste de contrôle prête pour la production
Harnais
- les outils sont-ils précis, documentés et observables
- l'état est-il durable entre les sessions
- les permissions sont-elles au moindre privilège
- un opérateur peut-il mettre en pause, inspecter et reprendre l'exécution
- chaque action importante peut-elle être reconstruite à partir des traces
Boucle
- quelle preuve prouve le succès
- quel retour est fourni après un échec
- combien de nouvelles tentatives sont autorisées
- que se passe-t-il lorsque le budget est épuisé
- où le jugement humain est-il requis
Graphe
- quels chemins doivent être déterministes
- où le travail peut-il s'exécuter en parallèle
- quel état est partagé
- où sont les jonctions, approbations et chemins de récupération
- quels cycles sont légaux et comment se terminent-ils
Évaluation
- l'équipe peut-elle rejouer des traces réelles
- les versions peuvent-elles être comparées sur les mêmes tâches
- une amélioration peut-elle être attribuée à un changement spécifique
Opérations
- les coûts et la latence sont-ils surveillés
- le taux d'échec est-il visible par nœud et par outil
- l'intervention humaine est-elle mesurée
- le succès au niveau de la tâche est-il mesuré en production
La façon la plus simple de se souvenir de la différence
L'ingénierie du harnais rend le modèle opérationnel
L'ingénierie de la boucle rend le travail itératif et vérifiable
L'ingénierie du graphe rend l'exécution complexe explicite et contrôlable
Aucune ne remplace les autres
Un graphe parfait ne peut pas sauver un agent qui perd son état
Un harnais parfait gaspille encore de l'argent si la boucle n'a ni preuve ni règle d'arrêt
Une boucle forte devient difficile à opérer lorsque les branches, le parallélisme et les approbations sont cachés dans du code ad hoc
Des agents fiables apparaissent lorsque les trois couches sont conçues ensemble
Et lorsque chaque couche a un travail clair
1ENVIRONNEMENT -> HARNAIS2RÉTROACTION -> BOUCLE3FLUX -> GRAPHE
Voilà tout le cadre
Sources et lectures complémentaires
- Tâches planifiées de Claude
- OpenAI AgentKit
- OpenAI Agents SDK
- AutoGen GraphFlow
- Building Effective AI Agents
Si vous avez lu jusqu'ici
Ajoutez l'article à vos favoris et suivez @0xwhrrari pour plus d'ingénierie pratique des agents
Vous pouvez aussi lire d'autres articles :
- Comment j'ai configuré Obsidian + Claude comme mon second cerveau
- Comment j'ai configuré Claude pour vraiment faire avancer les choses
- Comment j'ai configuré les projets Claude pour qu'ils fonctionnent vraiment
- 30 prompts système Claude que j'utilise réellement
- Loop Engineering : La compétence IA dont tout développeur aura besoin en 2026
- 30 paramètres, raccourcis et workflows Claude Code que la plupart des utilisateurs ignorent
- Comment j'utilise Claude Cowork pour fonctionner comme une entreprise individuelle
