Que fait auto-évaluation de l'agent ?
Après avoir terminé une tâche complexe, l'agent marque une pause pour noter sa propre production selon une grille structurée à 5 axes. Ce n'est PAS un contrôle succès/échec — c'est une étape de réflexion délibérée qui repère les omissions, l'excès de confiance et les axes d'amélioration avant que l'utilisateur n'ait à le faire.
Quand l'Activer
- Après avoir écrit du code qui s'étend sur 3+ fichiers ou 50+ lignes
- Après avoir terminé un workflow en plusieurs étapes (implémenter → tester → réviser)
- Après une session de débogage qui a impliqué 3+ tentatives
- Après avoir produit un document de conception, une décision d'architecture ou une analyse écrite
- Lorsque l'utilisateur demande « c'était comment ? » ou « note-toi »
- À la fin de tout hook d'arrêt de session (si configuré — voir
references/hook-integration.md)
Concepts de Base
Les 5 Axes d'Évaluation
| Axe | Question | Ce qu'il repère |
|---|---|---|
| Précision | Les faits, affirmations et résultats sont-ils corrects ? | Hallucinations, noms d'API erronés, syntaxe incorrecte, fausses déclarations |
| Exhaustivité | Est-ce que tout ce que l'utilisateur a demandé a été couvert ? | Cas limites manqués, chemins d'erreur non traités, exigences oubliées, sous-tâches ignorées |
| Clarté | L'explication est-elle compréhensible et bien structurée ? | Explications confuses, jargon non défini, contexte manquant, divagation |
| Opérationnabilité | L'utilisateur peut-il agir immédiatement sur le résultat ? | Suggestions vagues, étapes manquantes, « vous devriez X » sans montrer comment, pas de chemin de vérification |
| Concision | Le minimum de mots/tokens a-t-il été utilisé ? | Redondance, sur-explication, répétition textuelle de la question de l'utilisateur, contenu de remplissage |
Échelle de Notation
5 — Exceptionnel : aucune amélioration raisonnable possible
4 — Bon : uniquement des broutilles mineures, pas de lacunes substantielles
3 — Adéquat : répond à la demande mais présente une faiblesse notable sur au moins un axe
2 — Faible : présente une lacune claire qui affecte l'utilisabilité ou la justesse
1 — Médiocre : ne répond pas fondamentalement à la demande ou contient des erreurs significatives
La Règle de la Preuve
Toute note inférieure à 5 DOIT citer une preuve spécifique. Une note de 3 ne peut pas se contenter de dire « pourrait être mieux » — elle doit dire exactement ce qui manque ou ce qui est faux. Le mantra : « Montrez l'écart, ne vous contentez pas de le nommer. »
Workflow
Étape 1 : Collecter le Matériau Brut
Rassemblez ce que vous allez évaluer :
- La demande originale de l'utilisateur (relue depuis la conversation)
- Votre réponse/résultat final (le livrable)
- Toute sortie d'outil qui vérifie la justesse (résultats de tests, codes de sortie, sortie de lint)
- Tout retour utilisateur reçu pendant la tâche (corrections, « réessayez », « ce n'est pas correct »)
Étape 2 : Noter Chaque Axe Indépendamment
Parcourez les 5 axes un par un. Pour chacun :
- Lisez la question de l'axe
- Trouvez une preuve (ou l'absence de preuve) dans le résultat
- Attribuez une note de 1 à 5
- Si la note < 5, rédigez une note d'amélioration d'une phrase citant l'écart
Ne faites PAS la moyenne des notes dans votre tête d'abord pour travailler ensuite à rebours. Notez chaque axe à nouveau.
Étape 3 : Produire le Rapport d'Évaluation
Utilisez le modèle de templates/evaluation-report.md. Le rapport doit inclure :
- Résumé en une ligne
- Tableau de bord des 5 axes (note + preuve par axe)
- Note globale (moyenne simple, arrondie à 1 décimale)
- 1 à 3 améliorations spécifiques classées par impact
- Auto-vérification : « L'utilisateur serait-il d'accord avec cette évaluation ? »
Étape 4 : Appliquer l'Amélioration
Si un axe a obtenu 3 ou moins :
- Indiquez ce que vous feriez différemment
- Si l'écart est réparable en moins de 30 secondes (lien manquant, formulation peu claire), corrigez-le maintenant
- Si l'écart nécessite une reprise, signalez-le explicitement : « Cet axe a obtenu [raison] parce que [preuve]. Relancer avec [correctif spécifique] le porterait probablement à [note]. »
Exemples de Code
Exemple : Bonne Évaluation (Note >= 4)
Tâche : Ajouter une logique de réessai au client HTTP
Tableau de bord :
Précision : 5 — Tous les appels API corrects. Vérifié : les réessais utilisent
un backoff exponentiel. Aucune méthode hallucinée.
Exhaustivité : 4 — Couvre le chemin heureux + 3 cas d'erreur. Manque :
la gestion de timeout pour les connexions bloquées.
Clarté : 5 — Les commentaires de code expliquent la formule de backoff.
La description de la PR renvoie à l'incident qui a motivé cela.
Opérationnabilité :5 — Un seul merge. Aucune tâche de suivi. Les tests passent.
Concision : 4 — 47 lignes au total. La boucle de réessai pourrait être extraite
dans un helper pour gagner ~8 lignes.
Note globale : 4,6 — Un écart (gestion de timeout). Corriger avant de merger.
Exemple : Évaluation Faible (Note 2-3)
Tâche : Ajouter une logique de réessai au client HTTP
Tableau de bord :
Précision : 2 — Utilisé urllib3 qui ne correspond pas à notre
base de code httpx. Mauvaise bibliothèque.
Exhaustivité : 3 — Fonctionne pour GET. POST/PUT non gérés (l'utilisateur
a dit « toutes les requêtes HTTP »).
Clarté : 4 — Code lisible. Bons noms de variables.
Opérationnabilité :2 — « Ajouter des tests » mentionné mais aucun fichier de test créé.
L'utilisateur doit écrire les tests avant le merge.
Concision : 3 — 120 lignes. La configuration de réessai est dupliquée à
3 endroits au lieu d'un seul objet RetryConfig partagé.
Note globale : 2,8 — Mauvaise bibliothèque utilisée. Nécessite une réécriture en httpx.
Corriger d'abord la précision (passer à httpx), puis étendre à toutes les
méthodes HTTP, puis consolider la configuration.
Anti-Patrons
« Tout est 5 »
ÉCHEC : Précision : 5 — Tout va bien.
Exhaustivité : 5 — Tout est couvert.
Clarté : 5 — Clair.
Aucune preuve citée. C'est de l'auto-congratulation, pas de l'évaluation. Un vrai 5 exige de prouver qu'il n'y a rien à améliorer.
Sur-Pénaliser l'Extension du Périmètre
ÉCHEC : Exhaustivité : 2 — N'a pas géré les connexions WebSocket ou
le streaming gRPC (l'utilisateur n'a pas demandé cela)
Évaluez uniquement par rapport à ce que l'utilisateur a réellement demandé, pas par rapport à ce que vous auriez pu construire en plus.
Utiliser l'Évaluation pour Re-Litiger
ÉCHEC : « Comme je l'ai dit plus tôt, cette approche est erronée. Note : 1 »
L'évaluation porte sur le résultat livré, pas sur la remise en cause de décisions de conception déjà prises. Si l'approche était erronée, cela aurait dû être repéré avant la livraison.
Mélanger Préférence Personnelle et Lacunes Objectives
ÉCHEC : « Note : 3. Je n'aime pas les décorateurs Python. »
« Je n'aime pas » n'est pas une preuve. Citez une préoccupation concrète de lisibilité, de testabilité ou de justesse, ou laissez la note à 4+.
Bonnes Pratiques
- Évaluez le résultat, pas le processus. L'utilisateur se soucie de ce que vous avez livré, pas du nombre d'itérations que vous avez prises.
- Une amélioration par axe faible. Ne listez pas 5 choses pour un seul axe — choisissez l'écart à plus fort impact.
- Reliez les améliorations à l'impact utilisateur. « L'absence de gestion d'erreur signifie que l'appel API de l'utilisateur plantera silencieusement » est mieux que « ajouter une gestion d'erreur. »
- **Soyez précis sur ce à quoi ressemble un « corrigé ». ** « Relancer avec le transport httpx configuré pour les réessais » est mieux que « corriger le problème de bibliothèque. »
- Utilisez les sorties d'outil comme preuves. Si les tests passent, citez-les. Si le lint est propre, citez-le. Ne devinez pas — grep pour la preuve.
- Si vous ne trouvez aucun écart, essayez plus fort. Un score parfait sur les 5 axes est rare. Demandez : « Si j'étais l'utilisateur, qu'est-ce qui m'agacerait dans ce résultat ? »
Compétences Connexes
agent-eval— Comparaison directe de différents agents de codage sur des tâches de benchmarkverification-loop— Vérification systématique des résultats par rapport aux résultats attendussecurity-review— Liste de contrôle de revue de code axée sur la sécurité