# Comment mettre en place une boucle d’auto-amélioration d’agent en toute sécurité?

Date: 2026-02-08 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/boucle-auto-amelioration-agent-securite/

**Answer:** Une boucle d’auto-amélioration laisse un modèle proposer une meilleure version du prompt d’un agent, note chaque version sur un ensemble fixe de cas de test et garde la meilleure. Pour la rendre sûre, limitez ce qu’elle peut changer au prompt, plafonnez les tours et les dépenses dans le code, journalisez chaque tentative et exigez qu’une personne approuve toute nouvelle version avant sa mise en service.

« Auto-amélioration » sonne plus grandiose que ce que font la plupart des systèmes en service. Dans les exemples publiés, un agent ne réécrit pas son propre code et ne s’accorde pas de nouveaux pouvoirs. Une étape distincte lit les commentaires sur les résultats récents de l’agent, rédige une version révisée du **prompt** (les consignes selon lesquelles l’agent fonctionne) et teste cette ébauche. Si l’ébauche obtient une meilleure note sur un ensemble fixe de vérifications, elle devient candidate pour remplacer l’ancien prompt. Puis le cycle recommence.

Le *cookbook* d’OpenAI (son recueil d’exemples) appelle cela un agent qui évolue de lui-même et l’illustre avec un agent qui résume des documents réglementaires. Anthropic décrit la même forme comme un flux de travail **évaluateur-optimiseur** (*evaluator-optimizer*) : un appel au modèle produit le travail, un autre le juge et donne une rétroaction, tour après tour. Les deux insistent sur le fait que cela ne fonctionne que si vous avez des critères clairs de ce qui est « meilleur », et les deux ajoutent des limites et des vérifications humaines autour.

## Les quatre parties de la boucle

1. **Un agent de référence** avec un prompt versionné, pour que chaque changement puisse être annulé.
2. **Un ensemble d’evals** : quelques dizaines d’entrées réalistes, chacune avec des vérifications que le résultat doit réussir. Une **eval** est simplement un test automatisé pour le résultat d’un modèle.
3. **Des correcteurs** qui notent chaque résultat. Certains sont du simple code (est-ce sous 120 mots? le numéro de commande est-il mentionné?); l’un d’eux peut être un **LLM-as-judge** (un modèle juge), un modèle qui note selon une grille écrite. L’exemple d’OpenAI combine quatre correcteurs, deux en Python, un qui mesure la ressemblance avec le texte source et un juge fondé sur une grille, chacun avec son propre seuil de réussite.
4. **Un optimiseur** qui lit les échecs et propose un prompt révisé.

La boucle s’arrête quand la note dépasse une cible ou quand elle a épuisé ses tentatives. Dans le *cookbook*, la cible donnée en exemple est 0,8 et la limite, dix nouvelles tentatives; atteindre la limite avertit les ingénieurs qu’une personne doit intervenir.

## Un exemple concret

L’ébauche ci-dessous améliore le prompt d’un agent de résumé. Elle utilise l’API Responses de la bibliothèque Python `openai`. Les prix, les seuils et le choix du modèle sont des valeurs provisoires à fixer d’après votre propre compte et vos propres tests.

```python
import json, time
from openai import OpenAI

client = OpenAI()                       # lit OPENAI_API_KEY
MODEL = "gpt-5-mini"                    # n'importe quel modèle offert par votre compte
MAX_ROUNDS = 5                          # plafond strict de tours d'amélioration
MAX_COST_USD = 2.00                     # plafond strict de dépenses pour toute l'exécution
TARGET = 0.85                           # note moyenne nécessaire pour proposer un changement
PRICE_IN, PRICE_OUT = 0.25e-6, 2.00e-6  # USD par jeton : à titre d'illustration, utilisez votre grille de prix
spent = 0.0

def call(instructions, text):
    global spent
    r = client.responses.create(model=MODEL, instructions=instructions, input=text)
    spent += r.usage.input_tokens * PRICE_IN + r.usage.output_tokens * PRICE_OUT
    if spent > MAX_COST_USD:
        raise RuntimeError(f"Budget atteint : {spent:.2f} $ US")
    return r.output_text

def grade(case, summary):
    checks = [len(summary.split()) <= 120]
    checks += [term.lower() in summary.lower() for term in case["must_mention"]]
    return sum(checks) / len(checks)

def evaluate(prompt, cases):
    results = []
    for case in cases:
        summary = call(prompt, case["text"])
        results.append({"id": case["id"], "score": grade(case, summary), "summary": summary})
    return sum(r["score"] for r in results) / len(results), results

def log(entry):
    with open("loop_log.jsonl", "a", encoding="utf-8") as f:
        f.write(json.dumps(entry) + "\n")

cases = json.load(open("eval_cases.json"))   # [{"id", "text", "must_mention": [...]}]
prompt = open("prompt_v1.txt").read()
best_score, results = evaluate(prompt, cases)
log({"round": 0, "score": best_score, "prompt": prompt})

for rnd in range(1, MAX_ROUNDS + 1):
    if best_score >= TARGET:
        break
    failures = [r for r in results if r["score"] < 1][:5]
    candidate = call(
        "Tu améliores les consignes d'un assistant de résumé. Renvoie seulement les consignes "
        "révisées. N'ajoute ni outils, ni permissions, ni nouvelles tâches.",
        f"Consignes actuelles :\n{prompt}\n\nCas échoués :\n{json.dumps(failures)[:6000]}")
    score, cand_results = evaluate(candidate, cases)
    log({"round": rnd, "score": score, "spent": round(spent, 4), "prompt": candidate, "time": time.time()})
    if score > best_score:
        prompt, best_score, results = candidate, score, cand_results

with open("prompt_candidate.txt", "w", encoding="utf-8") as f:
    f.write(prompt)
print(f"Meilleure note {best_score:.2f}, dépenses {spent:.2f} $ US. Examinez prompt_candidate.txt avant le déploiement.")
```

Trois choix de conception assurent la sécurité. L’optimiseur ne peut changer que la formulation d’un seul prompt, et ses propres consignes lui interdisent d’ajouter des outils ou des tâches. Chaque tour, avec sa note et son coût, est consigné dans `loop_log.jsonl`. Et le script ne déploie jamais rien : il écrit `prompt_candidate.txt` et s’arrête, pour qu’une personne le compare avec la version actuelle et lise un échantillon de résultats avant de faire le changement. Le *cookbook* fait la même remarque : il qualifie son exemple de simplifié et précise qu’un vrai système devrait encadrer les tentatives d’optimisation par des garde-fous et faire approuver les nouveaux prompts par une personne.

> **À essayer :** constituez un ensemble d’evals de 15 entrées tirées de votre propre travail, lancez seulement le tour 0 et lisez vous-même les cinq résultats les moins bien notés. Si vous n’êtes pas d’accord avec les notes des correcteurs, corrigez les correcteurs avant de laisser un optimiseur s’approcher du prompt.

## Quelles limites l’empêchent de s’emballer?

**Une limite de tours et un plafond de dépenses, appliqués dans le code.** `MAX_ROUNDS` et `MAX_COST_USD`, ci-dessus, arrêtent la boucle peu importe ce qu’écrit le modèle. Anthropic note que les limites du nombre maximal d’itérations sont une façon courante de garder les agents sous contrôle, et que l’autonomie entraîne des coûts plus élevés et des erreurs qui s’accumulent. Ajoutez une limite d’utilisation mensuelle dans le compte de votre fournisseur comme deuxième couche.

**Une barrière d’évaluation.** Une nouvelle version n’est retenue que si elle bat l’ancienne sur les mêmes tests. Gardez quelques cas que l’optimiseur ne voit jamais, et vérifiez aussi la gagnante sur ceux-là, pour que le prompt n’apprenne pas simplement à plaire aux correcteurs.

**Une portée étroite.** Laissez la boucle changer les prompts, pas le code, les outils, les permissions ni ses propres limites. Ceux-là restent entre les mains des personnes.

**Un historique des versions et un retour en arrière.** Le *cookbook* conserve chaque version du prompt pour qu’une régression puisse être annulée. Le journal ci-dessus sert au même but.

**Une personne à la fin, et une alerte au milieu.** Quand la boucle atteint sa limite sans atteindre la cible, ou qu’une exécution est arrêtée par le budget, avertissez quelqu’un plutôt que de réessayer. Les conseils d’Anthropic sur les agents vont dans le même sens : testez dans un bac à sable, ajoutez des points de contrôle où une personne peut examiner le travail et gardez le jugement humain sur tout ce qui est mis en service.

## Sources

- Self-Evolving Agents: A Cookbook for Autonomous Agent Retraining: https://github.com/openai/openai-cookbook/blob/b3ee6e549d35e4c3de372375ed5374ae75c79992/examples/partners/self_evolving_agents/autonomous_agent_retraining.ipynb
- Building effective agents: https://www.anthropic.com/engineering/building-effective-agents