Ne promtez plus manuellement votre agent de code. Créez une boucle d'automatisation

Vous ne devriez plus piloter vos agents de codage avec des prompts isolés. Vous devriez concevoir des boucles qui les guident. Les équipes qui tirent vraiment parti des agents de codage IA ne traitent plus l’agent comme un partenaire de discussion, mais comme un exécutant dans un système contrôlé par des vérifications.

Essayez Apidog aujourd’hui

En bref

Une boucle d’agent de codage exécute toujours le même cycle :

1. générer un changement ;
2. exécuter le code ;
3. vérifier le résultat avec un signal fort ;
4. renvoyer l’échec à l’agent ;
5. répéter jusqu’au succès ou jusqu’à une limite.

L’agent n’est pas la partie la plus importante. La porte de vérification l’est.

Une porte vague comme « ça a l’air incorrect, réessaie » pousse l’agent à deviner. Une porte déterministe comme un test échoué, une incompatibilité de schéma ou un contrat API rompu le force à corriger un problème concret.

Pour le backend et les API, vos tests d’API, vos schémas et vos contrats doivent donc être au centre du flux agentique, pas ajoutés à la fin.

Passer du prompting à la conception de boucles

Le prompting manuel ressemble à ceci :

1. vous demandez une modification ;
2. l’agent génère du code ;
3. vous lisez la sortie ;
4. vous exécutez les tests ;
5. vous copiez l’erreur ;
6. vous reformulez un nouveau prompt.

Dans ce modèle, vous êtes la boucle. L’agent peut générer vite, mais il attend votre prochaine action à chaque itération.

Une boucle automatisée inverse ce fonctionnement :

1. l’agent modifie le code ;
2. un script exécute la vérification ;
3. le résultat est capturé ;
4. si ça échoue, l’erreur devient le feedback suivant ;
5. l’agent réessaie sans intervention humaine.

Vous n’intervenez qu’aux limites : définir la tâche, approuver le résultat ou arrêter l’exécution.

L’article d’Anthropic sur la construction d’agents efficaces va dans le même sens : la performance vient surtout de l’environnement construit autour du modèle, pas d’un prompt magique.

La question à poser n’est donc plus :

Que dois-je dire à l’agent ?

Mais plutôt :

Quelle boucle permet à l’agent de recevoir automatiquement le bon feedback ?

Ce qu’est une boucle d’agent de codage

Une boucle utile contient cinq éléments.

1. Une spécification de tâche

Évitez les consignes floues comme :

Fais fonctionner /orders.

Préférez une spécification vérifiable :

POST /orders doit renvoyer 201 avec la commande créée, valider le corps de requête selon le schéma OpenAPI et renvoyer 422 si un champ obligatoire est absent.

2. L’agent

C’est le modèle et ses outils : lecture de fichiers, écriture de fichiers, commandes shell, appels HTTP, etc.

C’est souvent la partie la plus visible, mais ce n’est pas celle qui garantit la qualité.

3. Une action exécutable

Après génération, quelque chose doit réellement tourner :

• tests unitaires ;
• compilation ;
• type checking ;
• linting ;
• tests API ;
• validation de schéma ;
• appel HTTP contre un service local ou mocké.

4. Une porte de vérification

La porte doit répondre de manière déterministe :

• succès ;
• échec avec raison exploitable.

Exemples :

• Expected 201, got 500
• response.total should be number, got string
• missing required field customer_id
• contract mismatch with OpenAPI schema

5. Une condition d’arrêt

Une boucle sans sortie est dangereuse. Définissez toujours :

• un nombre maximal d’itérations ;
• un budget ;
• une règle d’escalade vers un humain.

Exemple minimal :

task = load_spec("orders-endpoint.md")
last_result = None

for attempt in range(MAX_ITERATIONS):
    agent.run(task, feedback=last_result)

    result = run_verification()

    if result.passed:
        break

    last_result = result.failures
else:
    escalate_to_human(last_result)

Le principe est simple : l’agent génère, la porte juge, l’échec devient l’instruction suivante.

C’est aussi la version minimale du harnais décrit dans notre analyse de l’architecture du harnais d’agent.

Pourquoi le prompting ponctuel atteint ses limites

Un prompt isolé suppose deux choses :

1. le modèle réussira du premier coup ;
2. vous détecterez ce qui est incorrect.

Ces deux hypothèses cassent vite sur du code réel.

Un modèle peut générer un endpoint qui compile, semble cohérent et renvoie pourtant le mauvais code HTTP dans un cas limite. Dans une conversation, vous pouvez ne pas le voir. En production, vos utilisateurs le verront.

La boucle corrige ce problème en retirant à l’agent le droit de déclarer son propre travail terminé.

Ce n’est pas l’agent qui décide que c’est fini. C’est la porte.

Si les tests sont rouges, la tâche n’est pas terminée. L’erreur devient le prochain feedback.

C’est aussi ce qui permet de paralléliser. Avec du prompting manuel, vous surveillez un agent. Avec des boucles, vous pouvez en lancer plusieurs, chacun avec sa propre tâche et sa propre porte. C’est le principe abordé dans notre article sur les flux de travail d’agents dynamiques et parallèles.

La partie critique : la porte de vérification

La plupart des workflows agentiques échouent parce que le signal de feedback est trop faible.

Comparez ces deux retours :

Quelque chose ne va pas. Vérifie ton implémentation.

et :

Test failed: POST /orders without customer_id
Expected status: 422
Actual status: 500
Error: Cannot read property 'id' of undefined

Le second retour permet à l’agent de corriger un écart précis.

Une bonne porte a quatre propriétés.

Elle est binaire et reproductible

Même entrée, même verdict.

Pas de jugement subjectif. Pas de validation par le modèle lui-même.

Elle échoue bruyamment

Elle doit fournir :

• un nom de test ;
• une différence attendu/réel ;
• un chemin JSON ;
• un code HTTP ;
• une trace utile ;
• une erreur de schéma.

L’agent ne peut pas la modifier discrètement

Si l’agent peut changer le test pour le faire passer, la porte ne sert plus à rien.

Traitez les tests, contrats et schémas comme la spécification. Ils doivent être protégés.

Elle est assez rapide

Une suite de 20 minutes est utile avant merge, mais mauvaise pour une boucle interne.

Pour la boucle agentique, gardez une porte rapide :

• tests ciblés ;
• dépendances mockées ;
• scénarios API courts ;
• validation de contrat focalisée.

Les portes existent déjà dans la plupart des bases de code :

• tests unitaires ;
• linters ;
• compilateurs ;
• vérificateurs de types ;
• validateurs de schéma ;
• tests de contrat ;
• tests API automatisés.

Si cette couche n’est pas encore claire dans votre projet, commencez par formaliser les bases du test automatisé.

Pour les API et le backend, votre suite de tests est la boucle

Quand un agent implémente un endpoint, la vérité ne vient pas de son résumé final. Elle vient du comportement mesuré :

• bon code HTTP ;
• corps de réponse conforme au schéma ;
• authentification appliquée ;
• entrées invalides rejetées ;
• contrat OpenAPI respecté ;
• erreurs cohérentes.

Ces vérifications sont automatisables. Elles forment donc une porte idéale.

Une boucle API concrète ressemble à ceci :

1. l’agent lit la tâche et la définition OpenAPI ;
2. il modifie ou crée l’endpoint ;
3. le harnais lance la suite de tests API ;
4. les réponses sont validées : statut, JSON Schema, contrat ;
5. les échecs structurés sont renvoyés à l’agent ;
6. l’agent corrige ;
7. la boucle continue jusqu’au vert ou jusqu’à la limite.

Exemples de feedbacks utiles :

Expected 422 when customer_id is missing, got 500.

Response field total is string, but schema expects number.

Endpoint /orders/{id} exists in OpenAPI but has no implementation.

Les tests basés sur le schéma et les tests de contrat deviennent ici essentiels, car la spécification OpenAPI devient la source de vérité partagée par l’agent et la porte.

C’est le rôle qu’Apidog peut jouer dans ce type de workflow : centraliser conception API, schéma, serveur de mock et tests automatisés dans un même espace. La porte et la spécification restent synchronisées, et la boucle peut exécuter des scénarios validés par schéma à chaque itération.

Pour les équipes qui veulent connecter leurs agents à des outils d’inspection API, le débogueur d’agent IA d’Apidog permet à l’agent d’interagir avec les endpoints de façon plus proche d’un testeur humain.

Vous pouvez aussi télécharger Apidog si vous voulez construire cette porte visuellement au lieu d’écrire tout le harnais à la main.

Construire une boucle API auto-correctrice minimale

Vous n’avez pas besoin d’un framework complexe pour commencer.

Il vous faut :

• une spécification ;
• une commande de test ;
• un script de boucle ;
• une règle d’arrêt.

Étape 1 : écrire la spécification

Placez le contrat dans OpenAPI et le comportement attendu dans des tests.

Exemple de tâche :

Implémenter POST /orders.

Critères :
- renvoyer 201 si la commande est valide ;
- valider customer_id, items et shipping_address ;
- renvoyer 422 si un champ obligatoire manque ;
- renvoyer une réponse conforme au schéma Order ;
- ne pas modifier openapi.yaml ni les tests.

Étape 2 : choisir une commande de test honnête

La commande doit retourner un code non nul en cas d’échec.

Exemples possibles :

pytest tests/api/test_orders.py

newman run orders.postman_collection.json

apidog run ./tests/orders-suite --reporter json > result.json

La boucle n’a pas besoin de comprendre tout l’outil. Elle a besoin de deux choses :

• exit code == 0 : succès ;
• exit code != 0 : échec avec sortie exploitable.

Étape 3 : connecter la boucle

Exemple en Python :

import subprocess

MAX_ITERATIONS = 8
feedback = None

for attempt in range(MAX_ITERATIONS):
    run_agent(
        task="implement orders API per spec",
        feedback=feedback,
        allowed_paths=["src/", "app/", "routes/"]
    )

    gate = subprocess.run(
        [
            "apidog",
            "run",
            "./tests/orders-suite",
            "--reporter",
            "json"
        ],
        capture_output=True,
        text=True
    )

    if gate.returncode == 0:
        print(f"green on attempt {attempt + 1}")
        break

    feedback = parse_failures(gate.stdout)

else:
    print("8 tentatives, toujours rouge ; remontée à un humain")
    notify_human(feedback)

Étape 4 : protéger la porte

Ne laissez pas l’agent modifier :

• openapi.yaml ;
• les fichiers de tests ;
• les snapshots de contrat ;
• les scripts de validation ;
• la configuration de CI.

Sinon, il peut faire passer la suite en abaissant la qualité de la porte.

Étape 5 : limiter les coûts

Ajoutez toujours :

• MAX_ITERATIONS ;
• un timeout par exécution ;
• un plafond de coût ;
• des logs par tentative ;
• une remontée humaine en cas d’échec répété.

Les conseils de réduction des coûts dans les boucles rejoignent ceux de la réduction des coûts de jetons d’agent : une boucle qui ne converge pas brûle vite le budget.

Erreurs fréquentes dans les boucles d’agents

Laisser l’agent s’auto-valider

Si la seule vérification est :

As-tu terminé ?

vous n’avez pas une boucle fiable. Vous avez un chatbot qui affirme avoir fini.

La validation doit venir d’un système externe.

Utiliser une porte trop faible

Trois tests superficiels produisent une confiance superficielle.

Si la porte ne couvre pas les cas limites, l’agent ne les corrigera pas.

Ajoutez au minimum :

• cas nominal ;
• champ obligatoire manquant ;
• type invalide ;
• authentification absente ;
• ressource inexistante ;
• validation du schéma de réponse.

Oublier la condition d’arrêt

Une boucle sans limite peut tourner longtemps sur une tâche mal spécifiée ou impossible.

Fixez une règle simple :

MAX_ITERATIONS = 8
MAX_SECONDS = 600
MAX_COST_USD = 5

Puis remontez vers un humain.

Utiliser une porte trop lente

Une suite complète d’intégration peut être utile avant merge, mais trop lente pour guider un agent.

Séparez :

• porte rapide pour la boucle interne ;
• porte complète pour la CI ou la revue finale.

Laisser la spécification mutable

Si l’agent peut modifier OpenAPI pour correspondre à son code incorrect, le contrat devient inutile.

La règle pratique :

L’agent peut modifier l’implémentation, pas la constitution.

Donner une tâche trop grande

Évitez :

Construis tout le service de commandes.

Préférez :

Implémente POST /orders avec validation du corps et tests de contrat.

Les petites boucles convergent. Les grandes boucles dérivent.

Ces modes de défaillance sont les mêmes que ceux décrits dans le câblage des outils de flux de travail agentique, que vous utilisiez Claude Code, Cursor, Codex ou un agent interne.

Modèle pratique de boucle pour un endpoint

Voici une structure simple à adapter.

Arborescence

project/
  openapi.yaml
  tasks/
    implement-post-orders.md
  src/
    routes/
      orders.py
  tests/
    orders-suite/
  scripts/
    agent_loop.py

Spécification de tâche

# Implémenter POST /orders

## Entrée

POST /orders

Body :
- customer_id: string, obligatoire
- items: array, obligatoire
- shipping_address: object, obligatoire

## Comportement attendu

- 201 si la commande est créée
- 422 si un champ obligatoire manque
- 401 si l’utilisateur n’est pas authentifié
- réponse conforme au schéma Order dans openapi.yaml

## Contraintes

- ne pas modifier openapi.yaml
- ne pas modifier tests/
- ne pas désactiver la validation

Boucle

MAX_ITERATIONS = 6
feedback = "Lis tasks/implement-post-orders.md et implémente uniquement le code nécessaire."

for attempt in range(1, MAX_ITERATIONS + 1):
    run_agent(feedback)

    result = subprocess.run(
        ["apidog", "run", "./tests/orders-suite", "--reporter", "json"],
        text=True,
        capture_output=True
    )

    if result.returncode == 0:
        print(f"✅ Endpoint validé à la tentative {attempt}")
        break

    feedback = f"""
Les tests API ont échoué.

Corrige uniquement l'implémentation.
Ne modifie pas openapi.yaml ni tests/.

Sortie de la porte :
{result.stdout}
"""
else:
    raise RuntimeError("La boucle n'a pas convergé. Revue humaine nécessaire.")

Ce n’est pas sophistiqué, mais c’est déjà suffisant pour transformer un agent en système auto-correcteur sur une tâche ciblée.

Où cela nous mène

La compétence importante n’est plus seulement d’écrire de meilleurs prompts.

Elle devient :

• écrire des spécifications précises ;
• définir des portes déterministes ;
• protéger les contrats ;
• choisir des limites ;
• découper le travail en petites boucles ;
• décider ce que l’agent peut toucher ou non.

C’est plus proche de l’architecture système que du prompt engineering.

Cela change aussi la valeur des tests automatisés. Dans un workflow classique, ils servent surtout de filet de sécurité. Dans un workflow agentique, ils deviennent le mécanisme de direction.

Les équipes qui disposent déjà d’une bonne couverture de tests automatisés et de contrats clairs peuvent brancher des agents avec beaucoup moins de risque. Les équipes sans porte fiable obtiennent surtout un moyen rapide de générer du code confiant mais non vérifié.

À retenir

Arrêtez d’optimiser uniquement vos prompts. Optimisez la boucle.

Un agent de codage est un générateur rapide, mais il ne sait pas de manière fiable si son travail est correct. Une porte déterministe lui fournit ce signal.

Pour les API, vous possédez déjà les meilleurs composants de cette porte :

• schéma OpenAPI ;
• tests automatisés ;
• tests de contrat ;
• validations de réponse ;
• mocks ;
• CI.

Commencez petit :

1. choisissez un endpoint ;
2. écrivez une spécification précise ;
3. créez une suite de tests API rapide ;
4. interdisez à l’agent de modifier la porte ;
5. limitez les itérations ;
6. laissez la boucle faire passer le code du rouge au vert.

Si vous voulez une porte visuelle, synchronisée avec le schéma et partageable avec votre équipe, Apidog réunit conception, simulation et tests automatisés dans un même espace de travail. Vous pouvez le télécharger et utiliser vos tests comme mécanisme de pilotage de vos agents.