De la conception de prompts à l’ingénierie de systèmes autonomes
J’ai complètement arrêté d’orchestrer manuellement chaque étape du raisonnement d’un modèle de langage. Au lieu d’écrire un prompt, d’attendre la réponse, d’en analyser les erreurs et de soumettre un prompt correctif, je construis aujourd’hui ce que l’on appelle des boucles d’ingénierie d’agents (agent loop engineering).
Il s’agit d’une évolution majeure dans mon approche de l’IA : je suis passé de l’ingénierie de prompts à la construction d’architectures complètes. Une fois mise en place, la boucle laisse l’agent autonome agir, observer les retours du monde réel, ajuster sa propre stratégie, puis relancer le cycle jusqu’à atteindre un but vérifiable précis.
Comment fonctionne concrètement cette boucle continue
Une simple suite d’instructions mène généralement à un flux linéaire figé. Avec l’ingénierie des boucles d’agents, je me repose sur des mécanismes de retour d’information dynamique.
Quelle que soit l’infrastructure utilisée (de l’outil comme Claude Code aux frameworks de développement spécialisés), chaque cycle se compose invariablement de quatre phases :
- Le déclencheur et l’objectif : Le processus démarre suite à un événement extérieur (une tâche CRON, un webhook ou l’ouverture d’un ticket GitHub) avec un objectif clair assigné à l’IA.
- L’action : L’agent accomplit sa mission grâce à des outils qui lui permettent d’écrire du code, d’explorer un répertoire de fichiers ou d’interroger une base de données.
- L’observation et la vérification : C’est le moment de tester le résultat produit. Dans un contexte de programmation, cela revient à utiliser un programme de test pour s’assurer de la validité syntaxique ou opérationnelle.
- Le raisonnement et l’adaptation : Le modèle analyse ensuite les tests. Si son code plante, il parcourt ses logs d’erreurs pour changer d’approche et relance la boucle. S’il réussit, la condition d’arrêt s’enclenche.
En analysant les différents modèles de conception, j’observe souvent la taxonomie développée par les créateurs de LangGraph, qui divisent cette méthodologie en trois niveaux distincts :
| Niveau | Architecture de boucle | Objectif de la boucle | Exemple concret |
|---|---|---|---|
| 1 | La boucle d’agent | Un cycle basique autorisant le modèle à faire appel à des outils pour achever sa mission première. | Un assistant virtuel télécharge un dépôt Git et ébauche un script automatisé. |
| 2 | La boucle de vérification | L’ajout d’un sas d’évaluation de la production selon une grille de critères stricts. | Un script de test lance la solution produite pour l’analyser et la faire réécrire si des défauts sont constatés. |
| 3 | La boucle événementielle | L’intégration directe au système informatique, agissant silencieusement en toile de fond. | Une alerte Slack éveille l’agent de support, l’obligeant à mettre à jour tous les liens inactifs d’une documentation avant de retourner en veille. |
Mes principes de sécurité indispensables
(Au début de mes essais, j’ai voulu construire de simples scripts basés sur de basiques instructions Python while.
C’est le meilleur moyen de voir le modèle chercher son chemin indéfiniment et de détruire un budget API en un seul après-midi…). Pour qu’un agent évite les cycles infinis, il faut injecter quatre principes de sécurité fondateurs.
Je veille toujours à instaurer des conditions de fin d’exécution rigoureuses. Tant que le système ne peut pas distinguer ce qu’est une réussite incontestable, la boucle continuera. Par la suite, une gestion stricte du contexte et de la mémoire s’avère indispensable pour réduire le bruit accumulé dans l’historique lors de chaque essai.
J’ajoute souvent un concept de délégation à des sous-agents : je divise la résolution d’une difficulté majeure entre différents acteurs d’IA très spécialisés. Enfin, j’utilise toujours des clauses d’arrêt matériel ; c’est un point de sauvegarde forçant la procédure à faire intervenir un humain après trop de stratégies d’échecs similaires.
Frameworks Python vs Environnements visuels
Je le mentionnais tout à l’heure, concevoir tout ceci sans orchestration est difficile à tenir à l’échelle.
Pour mes projets orientés données de bout-en-bout, recherche continue profonde (Deep Research) ou opérations courantes (automatisation de support client par exemple), le marché propose de véritables frameworks de construction performants et gérant à la fois les parcours, l’information d’état ou encore les risques techniques :
- LangGraph (par LangChain) : Pour moi le choix standard de l’industrie dès que la logique complexe s’en mêle. Modélisant l’agent sous l’angle de parcours structurés sous formes de nœuds (“stateful graphs”), son enregistrement de données au passage est très fluide. J’apprécie grandement son implémentation du retour temporel (“Time Travel”) permettant le rebobinage et les pauses structurelles pour ajouter l’œil critique de l’humain de manière maîtrisée.
- CrewAI : Plutôt axé autour de logiques comportementales via la création de rôles multiples. Plus aisé à démarrer que le précédent selon moi, son approche se révèle très efficace lorsque vous instanciez un chercheur, suivi d’un vérificateur devant régulièrement déléguer et se renvoyer mutuellement des analyses pour un rendu spécifique.
- Microsoft AutoGen : Un environnement open-source centré vers un échange en boucle entre instances conversationnelles par excellence. C’est l’endroit tout désigné lorsque je développe sur base de générateurs de requêtes programmatiques. Un de ses forces réside aussi dans ses sandbox hautement sécurisés type Docker.
- LlamaIndex Workflows : La base pour l’interaction massive axée Data/RAG asynchrone guidé nativement selon des évènements. J’y recoure prioritairement avec mes extractions RAG intensives asynchrones s’articulant les unes face aux autres.
Parfois, les enjeux d’orchestration me demandent cependant des configurations purement No-Code et “Low-Code” visuelles.
- Les instances en production intensive : Je citerais la très aboutie n8n qui inclut maintenant directement sur la toile d’exécution la gestion via branches d’erreur correctives asynchrones (bien connue avec son “Advanced AI”). Également Dify, avec un système “open-source” doté d’outils de “boucle d’ingénierie” purement centrés sur de longs listages d’investigation itératifs.
- Déploiements et gestions expertes des processus de validation métier : Gumloop sera ma prérogative pour isoler un agent scripteur du Web dans sa quête d’extraction continuelle ou Stack AI lorsqu’une application à échelle “Enterprise” nécessite d’enfermer logiquement toute itération non approuvée en validation de mise à l’épreuve de norme métier.
- Outils structurels sous architectures propriétaires modérées et simplifiées : Lorsque l’export de programmation doit repasser la main à terme aux outils open-source classiques Python comme sur Langflow, sans occulter Flowise basé directement avec LangChain sur réseau Docker de propre hébergement pour palier les taxes répercutées API de tierce parties, ni les incontournables Zapier Central / Make, qui simplifient la mécanique itérative sur un email.
Sur les canvas d’orchestrateurs no-code sans Python visible, se retrouver confronté à ce que j’appelle le système de la “boîte noire” (bloquer itération 4 dans le plus total silence de console) implique bien évidemment d’exiger a priori la consultation transparente en temps-réel, ce qui constitue d’ailleurs les atouts des supports comme Flowise ou Langflow.
Un système “No-code” requiert d’injecter manuellement le frein (via Max Iterations).
Exemple : Un cycle de vérification automatisé pour la rédaction
Prenons un scénario réel de correcteur littéraire automatisé pour remplacer nos routines archaïques avec invites à la ligne (et reproduire exactement un diagramme que je configurerais en temps normal avec n8n). Mon script gère activement ces injections mémorielles et limites drastiques avec ce flux Python en amont :
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))
# Limites stricts et encapsulation par dictionnaire d'État du suivi projet
state = {
"topic": "The future of quantum computing in 2026",
"current_draft": "",
"feedback_logs": [],
"iteration_count": 0,
"max_iterations": 3,
"status": "IN_PROGRESS"
}
# L'agent d'écriture
def writer_agent(state):
prompt = f"Écris 2 paragraphes à propos de : {state['topic']}."
if state['feedback_logs']:
prompt += f"\nDraft précédent refusé. Corrections cibles demandées : {state['feedback_logs'][-1]}"
prompt += f"\nHistorique draft en cours : {state['current_draft']}"
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
state['current_draft'] = response.choices[0].message.content
state['iteration_count'] += 1
print(f"--- Iteration {state['iteration_count']}: Nouveau draft effectué ---")
# L'agent juge
def critic_agent(state):
rubric = """
Analyse scrupuleuse indispensable :
1. Proscrire expressément l'usage du vocable classique par intelligence générée "révolutionner".
2. Format exigé pour publication limitatif à 2 paragraphes textuels exclusifs.
Validation de publication par code d'arrêt stricts sur renvoi exclusif mot à mot: 'PASS'.
Retour échec et relance cycle : 'FAIL: [Description concises erreurs rencontrées]'
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": rubric},
{"role": "user", "content": state['current_draft']}
]
)
verdict = response.choices[0].message.content.strip()
if "PASS" in verdict:
state['status'] = "SUCCESS"
print("--- Vérification finale acquise : Arrêt fluide acté. ---")
else:
state['feedback_logs'].append(verdict)
state['status'] = "FAIL"
print(f"--- Arrêt de vérification et redémarrage via refus motif suivant: {verdict} ---")
# Orchestration du framework moteur
while state['status'] != "SUCCESS" and state['iteration_count'] < state['max_iterations']:
writer_agent(state)
critic_agent(state)
if state['status'] == "SUCCESS":
print("\nDocumentation Officielle et vérifiée prete par mon automatisation en validation:\n", state['current_draft'])
else:
print("\nSuspension impérative : Le système d'arbitrage interne repousse un format en conflit avec sa base structurelle.")
Dans l’écosystème d’Anthropic (Claude)
Je repense souvent à cette phrase de Boris Cherny (à l’origine de l’outil interactif de la ligne de commande système “Claude Code” de chez Anthropic), qui déclare : “Je n’invite plus Claude [avec un prompt], j’élabore les cadres à l’intérieur desquels il se gère… Ma mission est de paramétrer des cadres autonomes”. Anthropic encadre très logiquement la philosophie d’itération selon 4 paliers évolutifs précis :
- Boucle selon les passages à niveau (“Turn-Based Loops”) : J’octroie les requêtes générales telles “Corrige ces erreurs du formulaire connexion”, après quoi mon interface va engager des requêtes internes répétées à l’intention de Bash, du Bash à mon propre environnement direct avant retour conclusif validant son intuition terminale.
- Itération de précision visée (via Haiku vs Sonnet) : Il découple totalement le faiseur de travaux directs depuis son outil tiers vers une application modélisant uniquement la qualité de rendu post éjection des codes originaux pour statuer avant relai continu (“Goal-Based Loops”).
- Automatisation Programmatique Hebdomadaire et Cyclique temporelle (“Time-based”) : Des tâches silencieuses exécutées de temps et routines répétitives qui, tel de vulgaires crons natifs redessinent au rythme du calendrier l’intégralité du nettoyage ticket.
- La Veille asynchrone totale et passive WebHooks ciblée sur Evènements (“Proactive loops”) : Les alertes s’occupent uniquement au sein d’environnements déclenchés du DevOps, modifiant un Github action rompu afin qu’une réparation éparse soit immédiatement effectuée, soumise tout en retrouvant d’elle-même instantanément son intégrité passive et éteinte juste la micro-seconde clôturée des push terminaux d’opération.
J’use fréquemment de ses protocoles pour des intégrations avec une rapidité impressionnante via leur CLI. Par exemple, si vous tapez cette instruction terminale /goal "Refactor auth.ts until npm test passes completely with 0 errors" ou assignez /loop every 30 minutes "Check the repository..." via la déclinaison d’opérations cycliques hébergée chez eux “Routines”, ce script bloque littéralement en suspension le contrôle clavier chez lui-même avant clôture absolue confirmant zéro fail.
Le Model Context Protocol (MCP) et ses architectures Zero-Context
Derrière les rideaux techniques rendant possibles tous ces cycles, se cache l’universalité de gestion standard de branchements dénommé Modèle Contexte Protocol ou MCP, une prise branchant universellement cet appareil cognitif vers de l’environnement virtuel classique natif sous dossiers Unix d’opérations bas de chaîne logistiques (les fichiers et Bash système eux-mêmes de son appareil) via pont direct sans passer par une interface ou API intermédiaire.
Pour parer à mes hantises principales des redondances incontrôlables des appels à large contextes, j’emploie systématiquement la méthode du playbook Anthropic nommée “Harness Design” de contextes “Zéro Historiques Partagés” au grès des passes du juge vis-à-vis des rédacteurs initiaux ; tout passera par de l’observation direct de réécriture locale.
Ces configurations s’injectant alors au niveau Json “claude_desktop_config.json” pointant Node et Npx ciblés des chemins locaux strictes à impératif en direct des bureaux d’édition récurrents. Voici une esquisse conceptuelle de l’outil Generator :
VOTRE MISSION GÉNÉRATIVE : Modifiez les structures de code de ‘spec.md’ à réactiver techniquement au travers d’indicateurs formels listés au titre exclusif logistique sans omettre le rendu pointilleux exigé et contraint dans le cahier “eval_report.md” issu d’échec du passe d’évaluateur antécédent (Si rapport neutre ce passe itératif ne tient valeur pour référence absolue vierge)… Vous corrigerez tous ses syntaxiques purs sans injecter quelque forme argumentative visuel d’esprit cognitif auprès d’agent auditant pour justifier correctif, la qualité terminale statuera au code fonctionnel résorbant ce correctif et pas autre nature.
Codex et l’art d’autonomiser un processus d’équipe entier
Si j’effectue beaucoup de mes évaluations sous Python pur ou terminal Bash MCP sous mon OS directement par commande unique en direct d’invites simples, certains processus continus intenses m’amènent très spécifiquement au devant des infrastructures dédiées aux codeurs telles la version dite “plateforme d’ingénieur en auto-réparations intégrée” “Codex” (“openai/codex-action”).
La grande force y découle d’inventions purement isolées pour chaque processus lancé évitant de saccager ma branche initiale lors d’automatisation des actions simultanées via création pure asynchrone des ramifications nommées très utilement “Isolated Work Trees”.
Chacun exécute l’ordre non-dévié des plugins couplés entre les outils trackers par suivi externe continu dans des espaces restreints en accès (l’objectif reste central ici également par contrôle précis `/goal`).
Je m’en sers de nombreuses manières (réparation ciblée log erreur Sentry pure sans accès administrateur à travers une itération cyclique et une compilation de rapports passifs d’un flux inébranlable la semaine passée de nettoyage pure (“Continuous tech debts fixes”).
La règle qui définit la base “Agent itératif d’échec de vérification pour jugement continuelle des réecritures successives” en de tels contextes se nomme “Les SKILL”. Sa syntaxe est assez simple et redoutable quand configurée depuis le répertoire “SKILL.md”.
---
name: audit_strict_style_and_sec
description: Activation forcée d'audition d'intégration en boucle empêchant de souiller par retour direct et d'insécure syntaxes
tools_allowed: [grep, cat, write_file, execute_bash]
---
1. Activation exclusive de pytest.
2. Analyser via 'cat' ce retour par inspection en mode exclusion d'active trace sur "try/catch" par simple balisages et hardcoding clés sécurisés
Consigne de blocages stricts du cycle d'arrêt : Ne permet pas boucle fluide terminal par ajout rapport d'instruction d'un échec (.codex/eval_report.md). Passe d'exécution via le renvoi "REJECTED". Assentiment neutre et vierge pur exclusif statuera de par : "VERDICT: PASS" d'approbation et sortie vers état clair de repos boucle actée pure sans retombées.
Et surtout, l’aspect ultime de mes process de déploiements asynchrones tient dans la maîtrise inéluctable qu’ont ces automatisations (que je connecte aux “actions Github”) avec les limites temporelles et structurelles des “tokens burners” inopérantes.
Par un encart simple d’interceptions intégrés au cœur du YAML de la CI tel que `max-iterations: 4`, et grâce à la ségrégation native forçant ce script autonome à systématiquement créer son propre espace (`codex-fix/[base]`) qui coupe de manière préventive toute communication aux éléments à hauts privilèges d’autorisation (`safety-strategy: drop-sudo`), je garantis que le flux, s’il parvient exceptionnellement à se réparer de tous ses manques après la boucle exigée en toute perfection d’audit asynchrone, proposera alors une PR modeste.
Ceci force irrémédiablement l’équipe de développement et moi-même à statuer avant l’union vis-à-vis des directives imposées au principal cœur (“master base”), ce qui referme majestueusement la porte en amont à tous dégâts en cours de fuites d’auto-engagements en chaîne impromptus.
Cette précaution termine là la redoutable efficacité pratique des nouvelles pratiques qui relient mes modèles complexes.