Alors que nous déléguons des tâches de plus en plus ambitieuses à Claude, il devient de plus en plus important qu’il puisse vérifier son propre travail.
Plus Claude peut s’auto-vérifier :
- plus il peut travailler de manière indépendante sur des tâches de longue durée
- meilleure est la qualité du résultat final
- moins il nécessite d’allers-retours pour y parvenir
Quand les vérifications dépendent de vous, les sessions de codage deviennent un jeu au tour par tour, et vous perdez ce qui rend les agents utiles : l’autonomie.
La bonne nouvelle, c’est que Claude s’auto-vérifie déjà par rapport à des signaux déterministes comme les erreurs de type, les erreurs de lint, les tests échoués et les erreurs d’exécution. Et à mesure que les modèles s’améliorent, cela ne fera que s’améliorer.
Ce que Claude ne peut pas toujours déduire, ce sont les vérifications manuelles que vous effectuez après qu’il a répondu, et plus tard, avant de fusionner le code en production.
Plus vous pouvez encoder ces vérifications, plus la première réponse de Claude se rapproche du résultat final que vous aviez en tête.
Vous passez moins de temps à superviser, et Claude peut continuer pendant que vous travaillez sur autre chose.
Écrivez vos processus
Un bon point de départ est d’écrire la version des meilleures pratiques de ce que vous ou votre équipe faites déjà.
Pour le frontend, c’est généralement : lancer le serveur de développement, ouvrir le navigateur, vérifier la console pour les erreurs, cliquer comme le ferait un utilisateur et surveiller des éléments comme les décalages de mise en page ou les navigations lentes.
Chaque domaine a sa propre version. Pour chacune de ces étapes, il y a probablement un outil que Claude peut utiliser pour la vérification :
Encodez votre processus sous forme de skill
Une fois le processus clair, encodez-en autant que possible sous forme de skill. Installez le plugin skill-creator, puis demandez à Claude de vous interviewer :
1/skill-creator Créez un skill pour vérifier les modifications frontend de bout en bout. Interviewez-moi sur mon workflow.
Si vous avez du mal à mettre votre processus en mots, demandez d’abord à Claude les meilleures pratiques du domaine et laissez-le vous montrer à quoi pourrait ressembler un flux de vérification de bout en bout.
Le goût et le jugement sont difficiles à codifier, mais de nombreuses vérifications ont des critères que Claude peut mesurer : un budget de performance, une checklist d’accessibilité, des règles de système de design, des exemples bons vs mauvais.
Par exemple, un skill frontend pourrait inclure des instructions pour capturer une trace de performance via le Chrome DevTools MCP ou Agent browser.
1---2name: frontend-verify3description: Vérifier les modifications frontend dans un navigateur. Exécuter chaque fois qu’une modification d’interface (page, composant, typographie, style CSS) est effectuée.4---56# Vérification frontend78- Effectuer une vérification en deux étapes dans un vrai navigateur.9- Corriger les problèmes et revérifier avant de répondre à l’utilisateur.1011## Étape 1 — Vérifier que la modification se comporte comme attendu12131. Ouvrir l’URL dans un navigateur :14 - Dans l’application de bureau Claude Code, utiliser l’aperçu intégré.15 - Dans la CLI, utiliser le Chrome DevTools MCP.162. Interagir avec le nouvel élément et confirmer qu’il s’affiche et se comporte comme attendu.1718## Étape 2 — Vérifier que la modification passe un audit mobile19201. Ouvrir l’URL dans une nouvelle page via le Chrome DevTools MCP212. Exécuter une trace de performance et auditer les Core Web Vitals
D’autres vérifications sont plus qualitatives que binaires (réussite/échec), comme la comparaison de données avec des normes historiques. Pour celles-ci, vous pouvez travailler avec Claude pour définir une grille d’évaluation des résultats.
Relire le code avant la fusion avec un second agent
Tout ce qui précède se produit à l’intérieur de la boucle agentique. Il y a une deuxième étape de vérification, juste avant la fusion, où vous pouvez demander à un autre agent de faire une revue.
Un nouvel agent n’aura pas les mêmes biais que celui qui a écrit le code. Il a son propre contexte et n’est pas influencé par la conversation précédente. Cet isolement rend la revue plus honnête et permet de détecter des choses que le premier agent aurait pu manquer.
Quelques options, de manuelle à automatisée :
/review(skill intégré) – une lecture rapide en un seul passage d’une PR dans votre terminal.- /code-review (plugin installable) – lance plusieurs sous-agents en parallèle, chacun lisant le diff sous un angle différent, note les résultats selon leur confiance et publie le résultat sur la PR.
- Claude Code Review – un service géré qui s’exécute automatiquement sur chaque PR via GitHub, pour les plans Team et Enterprise.
Quel que soit votre choix, il est utile d’avoir une dernière ligne de défense avant de fusionner en production.
Assembler le tout
Vous avez maintenant deux couches :
- une vérification qui s’exécute pendant que Claude construit
- une revue avant fusion par un agent qui n’a pas écrit le code.
Les deux appartiennent au même cycle de développement. Pensez à vos étapes manuelles actuelles : vous faites une modification, la nettoyez, confirmez qu’elle fonctionne, committez, ouvrez une PR, la faites relire, et surveillez la CI.
Vous pouvez intégrer toutes ces étapes en un seul workflow en écrivant un skill qui appelle d’autres skills. Par exemple, l’équipe Claude Code a un skill qu’elle exécute lorsqu’elle travaille sur des fonctionnalités, qui regroupe :
- Le skill
/simplifypour nettoyer le diff - Un skill personnalisé
/verifypour confirmer que la modification fonctionne de bout en bout - Une vérification de design si le diff a touché l’interface
- Une étape pour ouvrir et s’abonner à une PR
- Un skill pour surveiller la CI et corriger les échecs au fur et à mesure
Bien que votre workflow puisse être différent, créer des boucles de rétroaction et regrouper des skills permet à Claude de vérifier et d’exécuter plus de travail de bout en bout.
