Claude Outcomes : Agents IA qui Vérifient Leur Propre Travail (Rubriques + Grader)

Sommaire

---

Pourquoi Outcomes change la production d'agents IA {#introduction}

Le 7 mai 2026, Anthropic a publié une mise à jour majeure de [Claude Managed Agents](/blog/claude-managed-agents-entreprises-2026) avec trois nouvelles features : *Dreaming*, *Multiagent Orchestration*, et Outcomes. Cette dernière est probablement la plus impactante pour quiconque met un agent IA en production.

Le principe d'Outcomes est radical : au lieu de décrire à l'agent comment faire son travail, vous lui dites à quoi ressemble un travail bien fait. L'agent essaie, un évaluateur indépendant note le résultat avec une rubrique, et l'agent ré-itère jusqu'à ce que le résultat passe le crible. C'est l'auto-vérification automatisée à l'échelle.

Et les chiffres sont là : Anthropic rapporte que sur la génération de PowerPoint, Outcomes améliore la qualité finale de +10,1% par rapport à un agent classique sans grader.

Pour le contexte sur les Managed Agents, lisez notre article [Claude Managed Agents pour entreprises](/blog/claude-managed-agents-entreprises-2026).

---

Qu'est-ce qu'un outcome Claude ? {#definition}

Un outcome est une spécification du résultat attendu. Vous le déclarez via un événement user.define_outcome qui contient trois éléments :

Exemple minimal :

\\\json { "type": "user.define_outcome", "description": "Generate a Q2 sales summary CSV", "rubric": "- CSV has columns: region, product, units_sold, revenue\n- All numeric columns are integers or floats\n- No empty rows\n- Total revenue > 0", "max_iterations": 5 } \\\

La différence fondamentale avec un prompt classique

Un prompt classique dit : *"Génère un CSV avec les colonnes X, Y, Z. Fais attention à ne pas mettre de lignes vides."*

Un outcome dit : *"Le CSV doit avoir les colonnes X, Y, Z. Aucune ligne vide n'est tolérée."* — et un autre modèle vérifie objectivement ces critères après chaque tentative.

Ce changement de paradigme (déclarer plutôt qu'instruire) rejoint la philosophie de la commande [/goal récemment ajoutée à Claude Code](/blog/claude-code-goal-agent-view-v2-1-139-dashboard-cli-2026).

---

Architecture : writer, grader, boucle d'itération {#architecture}

Les trois acteurs

\\\text ┌─────────────────────────┐ │ Writer (l'agent) │ │ Lit la description et la │ │ rubrique, produit l'artifact│ └──────────┬──────────────┘ │ artifact ▼ ┌─────────────────────────┐ │ Grader (Claude isolé) │ │ Lit la rubrique + artifact │ │ → verdict par critère │ └──────────┬──────────────┘ │ ┌─────┴─────┐ │ │ PASS FAIL + gaps │ │ ▼ ▼ Outcome Writer itère livré (jusqu'à max_iter) \\\

Le grader tourne dans un contexte isolé

Le point crucial : le grader lit la rubrique et l'artifact uniquement. Il n'a pas accès au transcript du writer, à ses brouillons, à ses pensées intermédiaires. Cette isolation évite le biais classique où "le modèle qui produit est aussi celui qui juge".

Concrètement, c'est un appel API séparé avec une fenêtre de contexte vierge à chaque évaluation.

Le format du verdict

Le grader renvoie un breakdown critère par critère :

\\\json { "iteration": 1, "criteria": [ { "id": "csv_columns", "passed": true, "note": "All required columns present" }, { "id": "numeric_types", "passed": true, "note": "All values are int or float" }, { "id": "no_empty_rows", "passed": false, "note": "Row 47 has empty product and revenue fields" }, { "id": "positive_revenue", "passed": true, "note": "Total = 1.2M" } ], "overall_passed": false } \\\

Le writer reçoit ce feedback et révise. À l'itération 2, il sait exactement quel critère a échoué et pourquoi.

Le compteur d'itération

iteration est un compteur 0-indexé :

L'agent s'arrête dès qu'un verdict global PASS arrive ou quand max_iterations est atteint sans succès.

---

Écrire une rubrique qui fonctionne {#rubrique}

Le critère cardinal : critères vérifiables indépendamment

Une rubrique efficace est composée de critères atomiques, indépendants, vérifiables. Le grader note chaque critère séparément, donc la formulation compte.

Mauvaise rubrique :

\\\`markdown

\\\`

Trop vague. Le grader passe son temps à interpréter, les verdicts sont instables, l'agent boucle sans converger.

Bonne rubrique :

\\\`markdown

\\\`

Chaque critère est testable mécaniquement. Le grader peut renvoyer un PASS/FAIL net.

Astuces d'écriture

Templates par type de tâche

#### Génération de code

\\\`markdown

\\\`

#### Génération de document

\\\`markdown

\\\`

#### Génération de slide deck

\\\`markdown

\\\`

---

Le paramètre max_iterations expliqué {#max-iterations}

Valeurs et défauts

max_iterations est optionnel, avec :

Comment choisir la bonne valeur

max_iterations = 3 convient pour la majorité des tâches où la rubrique est claire et le writer compétent. C'est aussi le compromis coût/qualité optimal pour des tâches répétées en masse.

max_iterations = 5 est recommandé quand la rubrique est stricte et le writer a besoin de marge.

max_iterations = 10+ est utile pour des tâches très contraintes (génération de code passant un test suite vaste, par exemple) où l'écart entre "ça marche" et "ça marche pour 100% des cas" demande plusieurs tours fins.

Le signal qui dit que vous devez baisser ou monter

Le coût caché

Chaque itération = 1 tour writer + 1 appel grader. Si vous tournez sur 1000 outcomes par jour avec max_iterations = 5, vous payez potentiellement 5000 tours writer + 5000 graders dans le pire cas. Surveillez le ratio "tours moyens" dans les dashboards Anthropic.

---

Cas d'usage concrets en production {#cas-usage}

1. Génération de rapports analytiques quotidiens

Une routine cloud génère chaque jour un rapport métier (cf. [routines automatisées](/blog/claude-code-routines-automatisations-cloud-2026)). La rubrique vérifie :

Sans outcome : on découvre les erreurs au bureau le lendemain. Avec : l'agent ré-itère jusqu'à un rapport propre.

2. Migration de code legacy

Un agent migre des fichiers d'AngularJS vers React. Rubrique :

max_iterations = 10 parce que les cas tordus demandent plusieurs essais.

3. Génération de documentation API

Un agent génère la doc d'un endpoint à partir du code source. Rubrique :

4. Génération de slides commerciales

Cas connu où Anthropic a mesuré +10,1% de qualité. Rubrique sur :

5. Création de tests unitaires

Rubrique :

---

Outcomes vs /goal Claude Code : quelle différence ? {#vs-goal}

Les deux fonctionnalités tournent autour de la même idée — boucler jusqu'à un critère — mais leurs cas d'usage diffèrent.

En pratique, /goal est l'outil du développeur qui veut "laisser Claude finir le job". Outcomes est l'outil de l'équipe qui déploie un agent en production avec un SLA de qualité.

Pour le /goal Claude Code, voir notre article dédié [/goal et Agent View](/blog/claude-code-goal-agent-view-v2-1-139-dashboard-cli-2026).

---

Pièges classiques et anti-patterns {#pieges}

Anti-pattern 1 : rubrique subjective déguisée

\\\`markdown

\\\`

Le grader ne peut pas mesurer ça de façon stable. Reformulez en critères objectifs : "Phrase length < 25 mots", "No first-person pronouns".

Anti-pattern 2 : critères qui se contredisent

\\\`markdown

\\\`

L'agent oscillera entre les deux. Choisissez une direction.

Anti-pattern 3 : critère non testable depuis l'artifact seul

\\\`markdown

\\\`

Le grader voit le code, pas les benchs. Soit vous incluez un bench dans l'artifact, soit vous reformulez : "Complexity is O(n log n) or better".

Anti-pattern 4 : `max_iterations` trop bas pour rubrique stricte

Vous mettez max_iterations: 1 avec 12 critères pointus → l'agent va échouer 90% du temps. Calibrez expérimentalement.

Anti-pattern 5 : ne pas observer les logs de grader

Les logs d'itération sont une mine d'or pour ajuster votre rubrique. Si le grader renvoie souvent "ambiguous criterion", c'est votre rubrique qu'il faut clarifier, pas le writer qu'il faut blâmer.

---

Bonnes pratiques de mise en production {#bonnes-pratiques}

1. Versionnez vos rubriques

Comme un schema SQL, une rubrique évolue. Stockez-la dans Git avec un numéro de version. Documentez les changements pour pouvoir comparer les performances entre versions.

2. A/B testez les rubriques

Lancez 100 outcomes avec la rubrique A et 100 avec la rubrique B. Comparez :

3. Loggez les feedbacks de grader

Stockez chaque verdict du grader avec les itérations. Ce dataset devient or pour :

4. Combinez avec la sécurité

Pour les agents en production, les outcomes ne remplacent pas la validation humaine des actions sensibles. Voir notre article sur la [sécurité des assistants IA](/blog/securite-assistants-ia-code-2026).

5. Surveillez la dérive

Si un agent voit son taux de PASS chuter de 85% à 60% sur deux semaines, quelque chose a changé : modèle, données d'entrée, dépendances. Mettez en place une alerte sur le taux PASS hebdo.

---

FAQ {#faq}

Outcomes est-il disponible pour tous ?

Outcomes fait partie de Claude Managed Agents. Au 13 mai 2026, c'est en bêta publique accessible à tous les comptes Anthropic avec accès à la console Managed Agents.

Quel modèle utilise le grader par défaut ?

Le grader utilise par défaut Sonnet 4.6, choisi pour son équilibre rapidité/qualité d'évaluation. Vous pouvez configurer un autre modèle dans les paramètres de l'outcome.

Combien coûte une itération supplémentaire ?

Chaque itération additionnelle = ~1 appel writer (tarifé selon le modèle utilisé) + 1 appel grader (~tarif Sonnet 4.6). Pour une tâche moyenne, comptez 0,01-0,05 EUR par itération supplémentaire.

Peut-on combiner outcomes et sub-agents ?

Oui. Un writer peut déléguer à des sub-agents pendant sa génération. Le grader évalue uniquement l'artifact final, pas le travail des sub-agents. Voir notre [guide des sub-agents](/blog/claude-code-sub-agents-guide-pratique-2026).

Que se passe-t-il si max_iterations est atteint sans PASS ?

L'outcome est marqué FAILED avec le dernier verdict du grader. Vous pouvez configurer un webhook pour être notifié et déclencher une review humaine ou un re-run avec rubrique ajustée.

Outcomes fonctionne-t-il sur Claude Code (CLI) ?

Non, Outcomes est spécifique aux Managed Agents. Sur Claude Code CLI, l'équivalent simple est [/goal](/blog/claude-code-goal-agent-view-v2-1-139-dashboard-cli-2026).

Peut-on utiliser Outcomes pour de la génération créative ?

Oui mais avec précaution. La rubrique doit pinpoint des critères stables (longueur, structure, ton mesurable). Les jugements purement esthétiques restent risqués — le grader n'a pas de "goût".

La rubrique doit-elle être en anglais ?

Non, le français fonctionne bien. Choisissez la langue qui décrit le mieux votre domaine métier, le grader comprend les deux.

Comment versionner une rubrique en production ?

Stockez-la dans votre repo Git avec un champ rubric_version dans l'event define_outcome. Loggez cette version avec chaque outcome pour pouvoir analyser les performances par version.

---

*Sources : Anthropic Managed Agents docs (platform.claude.com/docs/en/managed-agents), Anthropic Cookbook outcome-grader, Claude Blog "New in Managed Agents" (7 mai 2026), MindStudio analysis PowerPoint +10.1%, 9to5Mac coverage, VentureBeat.*