Tester du code généré par l'IA : la checklist en 12 points

En développant crmcoaching seul avec Claude, j'ai vécu exactement ça : Claude m'a généré l'implémentation d'une règle de calcul de disponibilité pour les slots d'un coach. Le code compilait. Les tests Vitest passaient, des tests que Claude avait également écrits. La PR a été mergée sur staging. Deux jours plus tard, en testant manuellement, j'ai découvert que certains créneaux étaient marqués disponibles alors qu'un slot-hold actif les bloquait. La règle métier avait une condition de priorité que Claude avait silencieusement simplifiée.

Ce n'était pas un bug de code. C'était un bug de jugement métier que Claude ne pouvait pas avoir sans mes spécifications complètes.

Le code généré par un LLM compile, passe les tests de type, et peut même faire passer une suite de tests unitaires, tout en étant incorrect sur la logique métier. C'est la caractéristique la plus trompeuse du code IA-assisté : les vulnérabilités de sécurité spécifiques aux LLMs s'y cachent de la même façon : il a l'air juste avant d'être évalué en profondeur.

Pourquoi Claude se trompe sur le métier

Claude génère du code plausible basé sur des patterns statistiques. Il ne connaît pas les règles métier de crmcoaching : les contraintes entre lead, client, offre, slot-hold, les invariants de domaine dans chaque bounded context. Il génère du code qui ressemble à du code qui gère des créneaux ou des paiements, mais pas du code qui gère mes créneaux, selon mes règles, dans mon contexte Prisma/PostgreSQL.

La conséquence est directe : le code IA-généré peut être techniquement impeccable (pas d'injection, pas de null assertion sauvage, bonne gestion des erreurs) et fonctionnellement incorrect (mauvaise règle de calcul, cas d'utilisation manqué, contrainte business ignorée). La recherche de NYU (2023) sur le code IA-assisté confirme que les développeurs sous-estiment systématiquement les erreurs de logique dans le code généré, précisément parce que le code "a l'air propre".

Checklist partie 1 : Correction logique et cas limites (points 1-4)

Point 1 : La logique métier correspond aux règles de votre domaine

Ne pas se fier au fait que le code "a l'air logique". Vérifier explicitement que chaque règle métier implémentée correspond exactement à la spécification. Claude a tendance à implémenter des règles "standard" qui peuvent différer des règles spécifiques de votre domaine.

Exemple concret sur crmcoaching : Claude peut implémenter la disponibilité d'un slot en ignorant la priorité d'un slot-hold actif, ou gérer la conversion lead -> client sans propager le createdBy attendu par l'audit trail.

Point 2 : Les cas limites sont couverts

Vérifiez explicitement :

• Que se passe-t-il si la collection est vide ?
• Que se passe-t-il avec des valeurs nulles ou undefined ?
• Que se passe-t-il avec les valeurs extrêmes (0, négatif, très grand nombre) ?
• Que se passe-t-il si une opération concurrente modifie l'état entre deux étapes ?

Point 3 : Les conditions métier sont correctement combinées

Claude a tendance à simplifier les conditions logiques complexes. Une règle business comme "eligible si (A ET B) OU (C ET PAS D)" peut être simplifiée en "eligible si A ET B OU C", ce qui produit des résultats incorrects pour les cas qui impliquent D. C'est exactement le type d'erreur que j'ai rencontré sur le calcul de disponibilité des slots.

Point 4 : Le comportement en cas d'erreur est métier-correct

Le code généré peut gérer les erreurs techniques correctement (try/catch, retours d'erreur) tout en gérant incorrectement les erreurs métier. Vérifiez : quelle est la réponse attendue quand une règle métier est violée ? Est-ce une exception ? Un résultat partiel ? Un état spécifique ?

Checklist partie 2 : Sécurité et gestion des erreurs (points 5-8)

Point 5 : Les inputs utilisateurs sont validés et sanitisés

Vérifiez systématiquement que tout input provenant de l'extérieur (utilisateur, API, message queue) est validé avant d'être utilisé. Claude oublie fréquemment la validation des types, des ranges, et des formats. Sur crmcoaching j'utilise Zod 4 pour parser et valider les DTOs à l'entrée de chaque controller NestJS : vérifier que Claude a bien branché le schéma Zod et qu'il ne fait pas confiance au type TypeScript seul.

Point 6 : Aucune injection n'est possible

Pour tout code qui génère des requêtes SQL brutes, des commandes shell, ou des requêtes LDAP : vérifiez que les valeurs dynamiques sont passées par des paramètres, jamais interpolées directement dans des strings.

Avec Prisma, le client paramétrise automatiquement les requêtes. Le danger apparaît quand Claude utilise $queryRawUnsafe pour une requête qu'il ne sait pas exprimer avec le query builder :

// ❌ Injection possible : Claude a utilisé $queryRawUnsafe avec interpolation directe
const userId = req.params.id; // non validé
const result = await prisma.$queryRawUnsafe(
  `SELECT * FROM "User" WHERE id = '${userId}'`
);

// ✅ Prisma paramétré : passer la valeur comme argument séparé
const result = await prisma.$queryRaw<User[]>`
  SELECT * FROM "User" WHERE id = ${userId}
`;

// ✅ Encore mieux : utiliser le query builder Prisma
const user = await prisma.user.findUnique({
  where: { id: userId },
});

Point 7 : Les secrets ne sont pas hardcodés

Recherchez dans le code généré : passwords, API keys, tokens, connection strings. Claude les hardcode fréquemment dans les exemples de code et les configurations, car c'est le pattern dominant dans le code d'exemple sur lequel il a été entraîné.

Point 8 : La gestion des exceptions est appropriée

Vérifiez que :

• Les exceptions sont capturées au bon niveau (pas de catch(e) {} vide qui avale les erreurs)
• Les exceptions techniques ne leakent pas de détails d'implémentation dans les réponses API
• Les ressources (connexions, fichiers, transactions Prisma) sont correctement fermées en cas d'exception

Checklist partie 3 : Performance, lisibilité, tests (points 9-12)

Point 9 : Pas de N+1 query

Le problème N+1 est l'un des patterns de performance les plus fréquemment générés par Claude : une query Prisma dans une boucle. Je l'ai rencontré plusieurs fois sur crmcoaching lors de la génération de listings agrégés.

// ❌ Pattern N+1 généré par Claude : 1 findUnique par client dans la boucle
const clients = await prisma.client.findMany();
for (const client of clients) {
  // 1 requête supplémentaire par client
  const offres = await prisma.offre.findMany({
    where: { clientId: client.id },
  });
  console.log(client.nom, offres.length);
}

// ✅ Eager loading avec include : 1 seule requête JOIN
const clients = await prisma.client.findMany({
  include: {
    offres: true,
  },
});
for (const client of clients) {
  console.log(client.nom, client.offres.length);
}

Point 10 : La complexité est acceptable

Calculez mentalement (ou avec Biome via noExcessiveCognitiveComplexity) la complexité du code généré. Claude peut générer des fonctions avec des imbrications de conditions très profondes difficiles à maintenir. Seuil d'alerte : complexité cyclomatique supérieure à 10, ou fonction de plus de 50 lignes sans extraction de helper.

Point 11 : Le code est testé avec des tests indépendants

Ne pas se contenter des tests Vitest générés par Claude pour valider le code de Claude. Écrire des tests indépendants, particulièrement pour les branches d'erreur et les cas limites identifiés au point 2.

Règle : au moins 1 test par branche métier critique
Règle : au moins 1 test pour chaque cas d'erreur explicitement géré

Point 12 : Le code est compréhensible par un humain sans explication

Si vous devez lire le code 3 fois pour comprendre ce qu'il fait, le code est trop complexe. Claude peut générer du code "intelligent" avec des patterns avancés ou des one-liners obscurs qui réduisent la lisibilité. La lisibilité prévaut sur le "clever code". Toujours.

Comment intégrer la checklist dans le workflow

Option A : Dans le template de PR : ajouter la checklist comme section "AI-generated code review" dans le template de PR. Combinez-la avec un outil d'analyse statique pour automatiser les vérifications de sécurité. Le reviewer coche les 12 points pour tout code généré par IA.

Option B : Dans le template de Story : pour les stories développées majoritairement avec assistance IA, ajouter la checklist comme critère de DoD. Le développeur self-review avant de créer la PR.

Option C : En session de travail solo : utiliser les 12 points comme checklist personnelle avant chaque merge. Identifier les patterns de lacune récurrents pour affiner les prompts et le contexte fourni à Claude.

FAQ sur le test du code IA-généré