Évaluer la qualité du code généré
Métriques, review agentique systématique et tests de non-régression pour détecter le drift silencieux dans le code produit par un agent.
Pourquoi évaluer le code généré
Un agent produit du code qui compile et passe les tests. Est-ce du bon code ? Pas nécessairement. Les tests vérifient le comportement fonctionnel, mais pas la lisibilité, le respect des conventions, l’absence de code mort, ni la pertinence architecturale.
Point clé : Le fait que « ça marche » est une condition nécessaire, pas suffisante. La qualité du code généré doit être évaluée sur plusieurs dimensions, exactement comme du code humain.
Sans évaluation systématique, le risque principal est le drift silencieux : le code s’éloigne progressivement des conventions du projet sans que personne ne s’en aperçoive, parce que les tests passent.
Les dimensions de la qualité
Au-delà du « ça compile »
La qualité du code généré s’évalue sur cinq axes :
| Axe | Ce qu’on vérifie | Outil / méthode |
|---|---|---|
| Correction | Le code fait ce qu’on demande | Tests unitaires et d’intégration |
| Conventions | Nommage, structure, style du projet | Linter, analyseur statique, review |
| Architecture | Le code est au bon endroit | Review humaine ou agentique |
| Simplicité | Pas de sur-ingénierie, pas de code mort | Review, métriques de complexité |
| Testabilité | Les tests ajoutés couvrent les cas limites | Couverture + review des tests eux-mêmes |
Attention : La couverture de tests peut être trompeuse : un test qui exécute du code sans rien vérifier (assertion manquante ou triviale) gonfle la couverture sans rien garantir.
Patterns de review agentique
Self-review
Demander à l’agent de relire son propre travail avec un regard critique. Simple à mettre en place, mais limité : l’agent a déjà vu son raisonnement et tend à confirmer ses propres choix.
Sub-agent review
Spawner un second agent (sub-agent) qui reçoit uniquement le code final et les conventions du projet — sans l’historique de création. Ce contexte frais donne un regard plus objectif, comparable à un reviewer humain qui ouvre une PR.
Review guidée par checklist
Fournir à l’agent une checklist explicite : nommage, tests manquants, complexité cyclomatique, code mort, gestion d’erreurs. Ce pattern est le plus fiable car il réduit la subjectivité de la review.
Point clé : La review agentique ne remplace pas la review humaine. Elle la prépare en automatisant les vérifications mécaniques, pour que le reviewer humain se concentre sur le design et l’intention.
Métriques automatisables
Certains signaux de qualité sont mesurables sans jugement humain :
- Complexité cyclomatique : nombre de chemins indépendants dans une méthode. Au-delà de 10-15, le code devient difficile à comprendre et tester.
- Couverture de code : utile comme indicateur de zones non testées, mais trompeuse si utilisée comme objectif en soi.
- Code mort : variables non utilisées, branches inaccessibles, imports fantômes. Un agent en génère souvent lors de refactorings successifs.
- Cohérence de nommage : l’agent respecte-t-il les conventions existantes ou invente-t-il ses propres patterns ?
- Ratio tests/code : pas un objectif en soi, mais un signal d’alerte si l’agent génère beaucoup de code sans tests.
En .NET : Des outils comme
dotnet format, les analyseurs Roslyn, et SonarQube automatisent ces vérifications. Les leverage points LP7 (tests), LP6 (types) et LP9 (linting) sont les fondations d’une évaluation automatisée.
Tests de non-régression
Le filet de sécurité minimal : avant et après l’intervention de l’agent, les tests existants doivent passer. Si l’agent ajoute une feature, il doit aussi ajouter les tests correspondants.
Stratégie concrète
Lancer dotnet test avant de confier la tâche (baseline). Après l’intervention de l’agent, relancer la suite complète. Tout test qui passait avant et qui échoue maintenant est une régression — un signal fort que le code généré a un problème.
Attention : Un agent peut involontairement « résoudre » un test qui échoue en le modifiant plutôt qu’en corrigeant le code. C’est un anti-pattern à surveiller dans la review.
Drift silencieux
Le risque le plus insidieux : le code compile, les tests passent, mais le code ne correspond pas à l’intention initiale ou dérive des conventions du projet.
Causes fréquentes
- L’agent interprète le prompt différemment de ce que le développeur avait en tête.
- Sur une session longue, l’agent perd le contexte des premières instructions (context rot).
- L’agent s’aligne sur des patterns trouvés dans sa fenêtre de contexte plutôt que sur les conventions du projet.
Remèdes
- Review humaine du diff final — pas seulement du résultat final, mais de ce qui a changé.
- Instructions persistantes claires (CLAUDE.md, LP12) qui encodent les conventions.
- Sessions courtes pour limiter le context rot.
- Tests d’intention (pas seulement de comportement) : le code fait-il ce qu’on voulait, pas juste ce qui passe les tests ?
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.