Donner à l’agent un moyen de vérifier son travail

L’exécution réelle est le pilier de la vérification du code généré par l’agent. Le jugement du modèle sur sa propre génération n’est pas fiable. Les moyens de vérification sont multiples et décrits dans les sections suivantes, le préalable étant d’exécuter le code généré sur le poste du développeur ou en CI/CD (avec plus d’isolation et de sandboxing dans ce cas).

La vérification doit donc s’appuyer sur un oracle que l’agent n’a pas produit : l’exécution réelle, la spécification, le type system, un vérificateur déterministe, etc. Le rôle de l’agent est de réagir à un résultat de vérification, pas de le produire.

Oracle. Mécanisme qui détermine si le comportement observé d’un système est correct pour une exécution donnée, en fournissant un verdict : succès ou échec.
L’oracle répond à « le résultat est-il celui attendu ? » : c’est un critère de correctness (spécification, propriété, valeur de référence, invariant, etc.) qui est distinct du système évalué. Sa fiabilité tient à son indépendance vis-à-vis de l’implémentation : idéalement, il est créé avant le code, ou par un autre auteur que celui qui le génère.

Les principes généraux :

• Le comportement évalué par les tests doit provenir de spécifications établies (EARs, Domain-Driven, invariant, pré et post-condition d’opérations, etc.).
• L’exécution est primordiale.
• Diversifier les oracles :
  • computationnel (example-based, property-based)
  • inférentiel (LLM-as-judge, analyse de logs)
  • hybrides (browser execution par ex.).
• Privilégier une approche CLI plutôt que MCP pour des raisons d’économie de tokens et d’intégration plus aisée avec les Skills (un rapport de consommation de tokens de 1 pour la CLI à 5 pour le MCP est souvent constaté).

Validation statique des sources

Les analyses statiques sont la première barrière et le premier feedback. C’est la moins coûteuse et la plus déterministe, qui doit passer au vert avant toute autre exécution (test, etc.).

• Compilateur / type-checker : Un type system exploité pour rendre les états illégaux non représentables permet de filtrer une classe entière d’erreurs sans écrire de test.
• Linters & formatters : conventions, code smells, cohérence (en pre-commit et en CI).
• Analyse statique / SAST & détection de secrets : indispensable car l’auto-review d’un agent ne rattrape pas l’essentiel des failles de sécurité.
• Audit de dépendances des librairies : versions, vulnérabilités connues, licences.
• Audit d’architecture La définition des dépendances entre modules fait partie de la spécification et le renforcement des règles de dépendances (tel module dépends de tels autres modules) fait partie de la boucle de feedback pour garantir la modularité attendue du système (exemple dependency-cruiser, eslint-plugin-boundaries).

Brancher ces contrôles en gate : aucun artefact ne progresse tant que la couche statique n’est pas verte.

Exécution du code

Donner à l’agent la capacité d’exécuter les commandes du dépôt (lancer ou builder le projet, lire la sortie et les logs du runtime) puis de réagir aux erreurs observées : corriger, relancer, jusqu’à ce que l’exécution passe. L’auto-jugement ne remplace jamais l’exécution réelle.

Browser

Donner à l’agent un contrôle navigateur réel pour obtenir sa boucle de feedback sur le rendu et les parcours UI : naviguer, remplir, cliquer, capturer, asserter. L’agent vérifie ainsi ce qui s’affiche réellement dans le navigateur.

• L’extension Claude for Chrome permet de donner à Claude la capacité de naviguer, cliquer, remplir des formulaires au sein d’un navigateur Chrome. Pour du développement frontend ou toute interaction web cette extension est indispensable.
• Playwright CLI et MCP
  • Playwright CLI : Même moteur que Playwright, cross-browser (Chromium/Firefox/WebKit), mais architecture « data on disk » : les snapshots sont écrits en YAML, les screenshots en PNG, et l’agent ne lit que ce dont il a besoin. S’intègre en Skill, pas en MCP.
    • npm install -g @playwright/cli@latest;playwright-cli install
  • Playwright MCP : la version éprouvée. A choisir dès que l’agent n’a pas d’accès shell (ex. environnement sandboxé). Les deux ne sont pas exclusifs : on peut installer CLI + MCP en parallèle.
    • claude mcp add playwright npx @playwright/mcp@latest
• Browser-use : le plus polyvalent pour les sessions authentifiées et le parallélisme. Trois modes : Chromium isolé, vrai Chrome avec profil utilisateur (logins/cookies/extensions existants, sans ré-authentification), et cloud avec proxy intégré pour le scraping parallèle et le contournement anti-bot. Seul à offrir ces trois modes plus la parallélisation cloud. Installation Python (pip install browser-use), intégration en Skill.
• Agent Browser : Adapté à la navigation simple, aux screenshots et au remplissage de formulaire. Mécanisme snapshot + refs courts très compact.
• Chrome DevTools MCP : pour du debug. Il enveloppe le Chrome DevTools Protocol (console, réseau, DOM, perf, exécution JS) pour comprendre pourquoi une page ne fonctionne pas correctement. Contrainte : lancer Chrome avec --remote-debugging-port=9222 à chaque session.

Playwright CLI s’inscrit naturellement dans une logique de vérifiabilité : il permet à l’agent d’exécuter les tests d’acceptance comme des fitness functions, fournissant un oracle exécutable sur le comportement réel du système sans saturer le contexte sur les suites de tests avec un nombre important d’étapes.

Privilégier Playwright CLI exposé en Skill (économe en contexte, snapshots/screenshots sur disque) plutôt que le serveur MCP, et garder Chrome DevTools MCP pour le diagnostic (console, réseau, DOM).

Appel d’API / Messaging / CLI

Exposer et faire invoquer par l’agent les interfaces réelles du système : clients HTTP (avec curl, wget ou httpie), CLI métier, flux de messages, etc. L’agent confronte alors ses hypothèses au comportement réel du système.

Privilégier les commandes idempotentes et les modes dry-run afin d’éviter les changements d’états qu’il faudra nettoyer.
Pensez aussi à isoler les credentials hors du contexte de l’agent.