Tester un agent IA qui écrit du code : guide pratique

Intro : tu utilises un agent IA pour écrire du code — excellent. Mais comment être sûr que ce qu’il produit est correct, maintenable et sûr ? Ce guide pratique te donne une méthode étape par étape pour tester un agent IA qui écrit du code (Claude Code, Multica, Archon), avec des patterns réutilisables, des exemples de hooks et une checklist opérationnelle.

Pourquoi ce guide ? Le mot‑clé ici est “tester un agent IA qui écrit du code” : c’est une sous-requête très concrète, utile aux devs et aux responsables produit qui veulent passer d’un prototype “vibe coding” à un workflow reproductible.

1) Principe de base : tests rapides + feedback immédiat

Le problème numéro 1 avec les agents qui génèrent des fichiers, c’est le drift : l’agent produit du code qui marche en surface mais casse les invariants du projet. Dans nos précédents retours terrain, “66% des développeurs” ayant adopté des agents se plaignent d’erreurs récurrentes liées au contexte (source : article “Claude Code + SaaS”).

Règle simple : ne laisse jamais un agent écrire sans boucle de vérification immédiate. Trois couches complémentaires :

• Hooks locaux (PostToolUse, Stop) pour validations rapides et ciblées
• Tests unitaires et smoke tests automatisés à la sortie d’une session
• CI complète pour la validation finale et la revue humaine

Cette approche ferme la boucle : l’agent écrit → on vérifie vite → on donne du feedback (et si possible on force une nouvelle itération de l’agent jusqu’à conformité).

2) Patterns pratiques (les hooks qui sauvent)

Si tu utilises Claude Code, tu disposes d’un mécanisme de hooks. Trois patterns à implémenter immédiatement :

• PostToolUse → formater et lint des fichiers modifiés (vite : prettier, eslint)
• Stop → lancer un smoke test ciblé (tests qui valident l’API la plus critique)
• PreToolUse → protéger les fichiers sensibles (bloquer modifications sur config/secret)

Exemple minimal (PostToolUse) :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/format-changed-file.sh"
          }
        ]
      }
    ]
  }
}

Et le script associe : il reçoit le chemin du fichier modifié et exécute prettier/tsc/pytest rapide selon l’extension. L’idée : garder chaque boucle sous les 10–15s pour ne pas ralentir l’itération.

3) Tests ciblés : quoi lancer selon l’édition

Tous les tests ne se valent pas. Pour garder une boucle rapide, mappe le type de modification au test minimal à lancer :

• changement d’un composant UI → lint + tests unitaires du composant (Vitest + Storybook smoke)
• changement d’une endpoint API → test d’intégration rapide sur l’endpoint (mock DB ou PGlite)
• changement d’une migration ou modèle DB → validation schema + migration dry‑run

Ce mapping permet d’éviter la course à la suite complète de tests (time‑consuming) et d’attraper les régressions les plus probables.

4) Workflows reproductibles (Archon / Multica)

Pour des runs plus robustes, encapsule ton process de dev en workflow : plan → implémentation itérative → validation → PR. Archon et Multica sont deux projets open source qui montrent cette approche :

• Multica traite les agents comme des coéquipiers et permet d’assigner des tâches aux agents de façon stable (source : README Multica).
• Archon permet de définir des workflows YAML où seules les étapes IA sont laissées au modèle ; tout le reste (tests, validations) est déterministe.

Le gain : reproductibilité. Quand un agent échoue, tu relances le même workflow et tu obtiens le même set d’artefacts isolés dans un worktree, ce qui facilite le débogage et la revue.

5) Mesures utiles — que collecter ?

Pour piloter la qualité d’un agent qui code, collecte ces métriques :

• Taux de tests passant après session (ex: % commits qui passent smoke tests)
• Nombre d’itérations agent → tests avant PR (combien d’itérations nécessaires pour arriver à tests verts)
• Latence p95/p99 des appels agents (important si l’agent est interactive)

Ces chiffres te donnent un signal opérationnel : si l’agent boucle 6–8 fois avant d’arriver à un état acceptable, revois le CLAUDE.md et les hooks.

Note contextuelle : pour des choix d’infra agentiques, des lancements récents comme Mistral Nova mettent en avant la latence p99 (~32ms) comme KPI pertinent pour l’UX des agents (source : article Mistral Nova). Si tu relies sur des agents en production, surveille latence et coût d’inférence.

6) Exemples concrets (checklist et snippets)

Checklist rapide à coller dans .claude/hooks/ :

• format-changed-file.sh (prettier/black)
• lint-changed-file.sh (eslint/tsc)
• smoke-test.sh (tests ciblés selon matcher)
• protect-files.sh (verrouille modifications de config)

Snippet de smoke-test.sh (exemple Node):

#!/usr/bin/env bash
set -euo pipefail
# Exécute un test rapide sur l'endpoint modifié
pnpm exec vitest -c vitest.config.ts --run --testNamePattern="smoke:api"

Règle : garder ces scripts idempotents et rapides (< 15s). Si ton smoke test prend > 30s, découpe-le en micro‑tests ciblés.

7) Revue humaine et PRs : comment garder le contrôle

Même avec des hooks et des workflows, la revue humaine reste cruciale. Deux recommandations :

• Forces les PRs créées par agents à inclure un changelog succinct produit par l’agent (diff + tests lancés + points d’incertitude)
• Utilise un template PR qui liste exactement les validations automatiques réalisées (lint, smoke, model iterations)

Archon et Multica facilitent la création de PRs reproductibles : Archon isole en worktree, Multica trace l’activité de l’agent. Combine ces outils pour faciliter la revue.

8) Pièges courants et comment les éviter

• Laisser l’agent modifier des fichiers secrets ou configs sans gate → mettre PreToolUse pour bloquer
• Lancer toute la suite de tests après chaque micro‑modification → ralentit et décourage l’utilisation des agents
• Ne pas versionner CLAUDE.md → le contexte se dégrade. Traite CLAUDE.md comme du code (PRs, review)

9) Exemple de brief CLAUDE.md pour tests

Inclure dans CLAUDE.md au moins :

• commandes de test rapides (smoke) et commandes CI
• mapping fichier → tests à lancer
• dossier des tests prioritaires

Extrait :

# tests
smoke_command: "pnpm run smoke"
mapping:
  src/api/: smoke:api
  src/components/: smoke:ui

FAQ (2–3 questions pour featured snippet)

Q : Quel test lancer automatiquement après que l’agent modifie un fichier ? A : Lance un test ciblé selon le type de fichier (UI → unit, API → integration smoke). Évite la suite complète.

Q : Les agents peuvent-ils écrire des tests eux‑mêmes ? A : Oui — fais-les écrire des tests par l’agent, mais vérifie-les via les hooks et rends la boucle itérative (écrire → exécuter → corriger).

Q : Dois‑je agir sur le CLAUDE.md ? A : Oui. Un CLAUDE.md maintenu réduit dramatiquement les erreurs d’agent. Traite‑le comme du code.

Ce qu’il faut retenir

• Ne fais pas confiance par défaut : automatise les vérifications rapides et itératives.
• Trois patterns suffisent pour commencer : PostToolUse (format), Stop (smoke test), PreToolUse (protection).
• Versionne CLAUDE.md et intègre-le au workflow (Archon/Multica) pour reproductibilité.

Sources principales :

• Article “Claude Code + SaaS : construire une app IA-native” (/fr/blog/2026-03-30-claude-code-saas-ia-natif)
• Article “Claude Code hooks : éviter le drift” (/fr/blog/2026-05-24-claude-code-hooks-eviter-drift-lint-tests)
• Multica README (https://github.com/multica-ai/multica)
• Archon README (https://github.com/coleam00/Archon)
• Annonce Mistral Nova (model card) (https://mistral.ai/blog/announcing-mistral-nova)