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

Dans une équipe que j'accompagnais chez un assureur, un développeur avait utilisé Claude pour implémenter une règle de calcul de cotisation. Le code compilait. Les tests unitaires passaient, des tests également générés par l'IA. La PR a été mergée. Deux semaines plus tard, en recette, le client a trouvé que les cotisations de certains profils d'assurés étaient calculées avec un taux incorrect. La règle métier avait une condition que le LLM avait simplifiée sans le dire.

Ce n'était pas un bug de code. C'était un bug de jugement métier que l'IA ne pouvait pas avoir.

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 l'IA se trompe sur le métier

Un LLM génère du code plausible basé sur des patterns statistiques. Il ne comprend pas les règles métier de votre domaine spécifique. Il génère du code qui ressemble à du code qui traite des commandes, des paiements, ou des utilisateurs, mais pas du code qui traite vos commandes, selon vos règles métier, dans votre contexte spécifique.

La conséquence est directe : le code IA-généré peut être techniquement impeccable (pas d'injection, pas de null pointer, 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. Les LLMs ont tendance à implémenter des règles "standard" qui peuvent différer des règles spécifiques de votre domaine.

Exemple concret : un LLM peut implémenter un calcul de TVA avec les taux standards sans tenir compte des règles spéciales de votre secteur ou des articles exonérés.

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

Les LLMs ont 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 vu en production.

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é. Les LLMs oublient fréquemment la validation des types, des ranges, et des formats.

Point 6 : Aucune injection n'est possible

Pour tout code qui génère des requêtes SQL, 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.

# Vérification rapide : chercher les patterns f-string dans les requêtes
query = f"SELECT * FROM users WHERE id = {user_id}"  # ❌ injection possible
query = "SELECT * FROM users WHERE id = %s"           # ✅

Point 7 : Les secrets ne sont pas hardcodés

Recherchez dans le code généré : passwords, API keys, tokens, connection strings. Les LLMs les hardcodent fréquemment dans les exemples de code et les configurations, car c'est le pattern dominant dans le code d'exemple sur lequel ils ont été entraînés.

Point 8 : La gestion des exceptions est appropriée

Vérifiez que :

• Les exceptions sont capturées au bon niveau (pas de catch(Exception) généralisé 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) 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 de N+1 est l'un des patterns de performance les plus fréquemment générés par les LLMs : une query dans une boucle.

# ❌ Pattern N+1 généré fréquemment
for order in orders:
    customer = db.get_customer(order.customer_id)  # 1 query par order
    process(order, customer)

# ✅ Eager loading
customer_ids = [o.customer_id for o in orders]
customers = db.get_customers_by_ids(customer_ids)  # 1 seule query

Point 10 : La complexité est acceptable

Calculez mentalement (ou avec un outil) la complexité cyclomatique du code généré. Les LLMs peuvent générer des fonctions avec des imbrications de conditions très profondes difficiles à maintenir. Seuil d'alerte : complexité cyclomatique supérieure à 10.

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

Ne pas se contenter des tests générés par le LLM pour valider le code du LLM. Écrivez 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. Les LLMs peuvent 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 : Dans les 1-on-1 : utiliser les 12 points comme framework de discussion avec les développeurs qui adoptent l'IA. Identifier les patterns de lacune récurrents pour cibler la formation.

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