En séparant l’environnement, la boucle de feedback et le flux de contrôle. C’est là que beaucoup d’agents IA deviennent fragiles en production. Je vais clarifier agent harness engineering, loop engineering et graph engineering, puis montrer dans quel ordre les diagnostiquer quand le système casse.
C’est quoi la différence ?
L’agent harness engineering construit l’environnement d’exécution autour du modèle, le loop engineering conçoit les cycles de feedback, le graph engineering rend le flux de contrôle explicite.
Ces trois sujets se ressemblent parce qu’ils parlent tous d’agents IA. Mais ils ne règlent pas le même problème. C’est là que beaucoup d’équipes se mélangent les pinceaux, surtout quand l’agent commence à partir en vrille en production.
Le harness répond à une question très concrète : Dans quoi le modèle agit-il ? Est-ce qu’il a accès aux bons outils, aux bons fichiers, aux bonnes permissions, à une mémoire exploitable, à des logs propres, à un système capable de reprendre après une erreur ? Bref, est-ce que le modèle peut vraiment faire quelque chose, ou est-ce qu’on lui demande juste de réfléchir dans le vide.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le loop engineering arrive après. Il répond à : Comment le système vérifie, corrige et recommence ? Une loop, c’est une boucle de rétroaction. Le système produit une action, observe le résultat, juge si c’est correct, puis ajuste. C’est ce qui permet d’éviter le mode “one shot” où l’agent tente un truc et s’arrête, même si c’est faux.
Le graph engineering, lui, répond à : Quel chemin exact le processus peut-il prendre ? Là, on rend explicites les étapes, les embranchements, les conditions. Si le client répond A, on va ici. Si l’API échoue, on va là. Si la validation passe, on continue. C’est très utile dès que le process devient sérieux.
| Discipline | Rôle | Question clé |
| Agent harness engineering | Environnement d’exécution | Le modèle peut-il agir vraiment ? |
| Loop engineering | Cycle de feedback | Le système sait-il vérifier et recommencer ? |
| Graph engineering | Flux de contrôle explicite | Les chemins d’exécution sont-ils clairs ? |
Quels serveurs MCP choisir pour vos agents IA ?
En production, je regarde toujours dans cet ordre : l’environnement, puis la boucle, puis le flux. C’est plus simple, et franchement ça évite de perdre des heures.
Si un agent ne peut pas écrire un fichier, conserver son état, relancer une tâche après une erreur ou accéder correctement à son outil métier, ce n’est pas encore un problème de loop ou de graph. C’est d’abord un problème de harness. J’ai déjà vu une équipe refaire toute l’orchestration d’un agent alors que le vrai souci venait juste d’un répertoire non accessible en écriture. Classique. Pas glorieux, mais très réel.
Pourquoi le harness passe avant ?
Le harness passe avant parce qu’un modèle seul ne peut pas exécuter des tâches réelles sans outils, stockage, logs, contexte et contrôles d’exécution.
Un modèle sait produire du texte, raisonner, proposer une action. Mais pour faire quelque chose dans un vrai système, il lui faut une couche autour. C’est ça l’agent harness engineering. C’est la fondation qui permet à l’agent de lire un fichier, appeler une API, écrire dans une base, retrouver une information, garder un état, suivre une consigne métier et laisser une trace exploitable.
Le harness regroupe les outils, les accès fichiers ou API, le stockage, la récupération d’informations, le middleware, l’historique de dialogue, les consignes de contexte, la journalisation et les mécanismes de contrôle. Le middleware, c’est simplement la couche intermédiaire qui orchestre les échanges entre le modèle, vos systèmes et les règles d’exécution. Sans cette couche, l’agent peut avoir l’air très bon en démo, puis devenir instable dès qu’il doit travailler avec un CRM, un ERP, un drive partagé ou une base client.
Les contrôles sont souvent ce qui fait la différence. Un TTL, pour Time To Live, limite la durée de vie d’une tâche pour éviter qu’elle tourne sans fin. Les retries permettent de retenter proprement après une erreur temporaire. Les quotas évitent de consommer trop d’API, de tokens ou de budget. Le routage choisit le bon outil ou le bon modèle selon la demande. La reprise après échec permet de redémarrer au bon endroit. La persistance d’état garde la mémoire opérationnelle de ce qui a déjà été fait.
J’ai souvent vu des équipes vouloir améliorer le prompt ou changer de modèle alors que le vrai problème venait de l’exécution autour du modèle. L’agent n’avait pas de mémoire fiable, pas assez de logs, ou aucun mécanisme propre pour reprendre après une erreur. Dans ce cas, changer de modèle ne règle presque rien.
- Outils : Pour agir sur des fichiers, APIs ou services.
- Stockage : Pour conserver l’état et récupérer les informations utiles.
- Logs : Pour comprendre ce qui s’est passé.
- Contrôles : Pour éviter les boucles infinies, les abus de ressources et les échecs silencieux.
- Reprise : Pour redémarrer proprement après une erreur.
Comment rendre une loop fiable ?
Une loop devient fiable quand elle ne se contente pas de demander au modèle de s’améliorer, mais vérifie objectivement si le résultat est correct.
Une loop, c’est juste une boucle de travail. L’agent produit une action, on regarde si le résultat passe un contrôle, puis on corrige si besoin. Si ça marche, on arrête. Si ça échoue trop souvent, on escalade à un humain. C’est ça le loop engineering : formaliser ce cycle au lieu de laisser l’agent improviser jusqu’à “ça a l’air mieux”.
Le point clé, c’est la vérification déterministe. Déterministe veut dire que le résultat du contrôle ne dépend pas d’une impression ou d’une humeur du modèle. Ça passe ou ça casse. Par exemple : un test unitaire qui valide une fonction, une validation de schéma JSON, un contrôle de présence de champs obligatoires, une requête SQL qui doit retourner zéro anomalie, ou un score métier avec un seuil clair.
J’ai vu des agents tourner longtemps sur des consignes du genre “rends ça plus clair”, “fais mieux”, “nettoie le résultat”. Le problème, c’est que personne n’a défini ce que “mieux” veut dire. Donc l’agent reformule, ajuste, retouche, parfois il dégrade même le résultat, et il continue parce qu’il n’a aucune preuve de réussite. Une bonne loop ne cherche pas une impression de qualité. Elle cherche une preuve.
Un pseudo-code simple ressemble à ça : run_loop(objectif) : pour chaque tentative jusqu’à max_attempts, produire une action avec l’agent, exécuter l’action, appeler verify(résultat), si verify valide alors retourner succès, sinon fournir le feedback vérifiable à l’agent et retenter, après le nombre maximum d’essais déclencher une escalade humaine avec l’objectif, les erreurs et les derniers résultats.
Ce petit détail change tout. On passe d’un agent qui “essaie de s’améliorer” à un système qui sait quand il a réussi, quand il doit recommencer, et quand il doit arrêter de faire semblant.
| Mauvaise loop | Bonne loop |
| Critères subjectifs | Vérification déterministe |
| Nombre d’essais flou | Tentatives limitées |
| Pas d’escalade | Escalade humaine après échec répété |
| Feedback vague | Preuve objective de réussite |
Quand passer au graph ?
Il faut passer au graph quand le processus a plusieurs chemins, branches, retours, validations ou fusions qu’on ne veut plus laisser implicites.
Le graph engineering sert à représenter le flux de contrôle avec des nœuds, des branches, des merges et des boucles contrôlées. Le flux de contrôle, c’est simplement la manière dont une demande circule dans le système. Ce qui se passe d’abord. Ce qui se passe ensuite. Ce qui bloque. Ce qui repart en arrière. Ce qui termine le traitement.
Le but n’est pas de rendre votre agent plus compliqué. C’est même l’inverse. On rend visible ce qui existe déjà, mais qui est souvent planqué dans du code, dans un prompt trop long, ou dans des conditions un peu bricolées. J’ai vu ça chez un client avec un agent support client. Tout “marchait”, jusqu’au moment où personne ne savait pourquoi certaines demandes partaient en escalade humaine et d’autres non. Le problème n’était pas l’IA. Le chemin était juste invisible.
Si le harness donne à l’agent les moyens d’agir, et si la loop lui donne un mécanisme de correction, le graph donne une carte claire du processus. On sait où une décision est prise, où une validation intervient, où une boucle peut revenir, et où le flux se termine.
Prenons un cas simple. Un agent reçoit une demande, choisit un outil, exécute une action, vérifie le résultat, puis passe soit vers une correction, soit vers une validation finale. Sans graph, ce flux reste caché. Avec graph, il devient auditable. On peut le relire, le tester, le surveiller.
- Nœuds pour représenter les actions ou validations.
- Branches pour gérer les décisions, par exemple succès ou échec.
- Merges pour réunir plusieurs chemins au même endroit.
- Boucles contrôlées pour revenir en arrière sans créer une boucle infinie.
Ma règle de diagnostic est simple. Si l’agent n’a pas les moyens d’agir, on corrige le harness. Si l’agent agit mais n’apprend pas de ses erreurs, on corrige la loop. Si les chemins deviennent confus, on explicite le graph.
Vous voulez des agents IA qui tiennent vraiment en production ?
Je résume simplement : un agent IA fiable ne repose pas seulement sur un bon modèle. Il lui faut un harness solide pour agir, conserver son état, journaliser et redémarrer proprement. Il lui faut une loop claire pour vérifier objectivement le résultat, limiter les essais et escalader quand ça bloque. Il lui faut parfois un graph pour rendre le flux de contrôle lisible, avec ses nœuds, branches, merges et boucles. Quand un système casse, je regarde dans cet ordre : environnement, feedback, flux. Le bénéfice pour vous, c’est moins de flou, moins de bricolage, et des agents IA vraiment exploitables.
FAQ
- Quelle est la différence entre agent harness engineering, loop engineering et graph engineering ?
L’agent harness engineering concerne l’environnement d’exécution autour du modèle. Le loop engineering concerne les cycles de feedback, de vérification et d’amélioration. Le graph engineering concerne la représentation explicite du flux de contrôle avec des nœuds, des branches, des merges et des boucles. - Pourquoi diagnostiquer le harness avant la loop ou le graph ?
Parce que si l’agent ne peut pas accéder aux outils, écrire dans un système de fichiers, garder son état ou redémarrer après une erreur, le reste ne sert pas à grand-chose. Le problème vient d’abord de l’environnement d’exécution, pas du cycle de feedback ni du flux de contrôle. - Qu’est-ce qu’un bon harness pour un agent IA ?
Un bon harness fournit les outils, le stockage, la récupération d’information, le contexte, les logs, le middleware et les contrôles d’exécution. Il doit aussi gérer les retries, les quotas, le TTL, le routage, la persistance d’état et la reprise après échec. - Comment éviter qu’une loop tourne dans le vide ?
Il faut une vérification déterministe. Par exemple des tests automatiques, une validation de schéma ou un contrôle objectif. La loop doit avoir un nombre d’essais limité et prévoir une escalade humaine si les tentatives échouent plusieurs fois. - À quoi sert le graph engineering dans un agent IA ?
Il sert à rendre le processus explicite. Quand un agent suit plusieurs chemins possibles, prend des décisions, revient en arrière ou fusionne des branches, le graph permet de visualiser et contrôler ces chemins au lieu de les laisser cachés dans le code ou les prompts.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes qui veulent fiabiliser leurs systèmes data, IA et automatisation, pas juste faire des démos. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place des agents IA plus robustes dans votre business, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.