Couverture de tests du code IA : pourquoi le pourcentage trompe

La couverture de tests mesure quelles lignes de code ont été exécutées lors d'une exécution des tests – pas si le comportement a été vérifié. Avec les tests générés par IA s'ajoute un raisonnement circulaire : le modèle déduit les valeurs attendues du comportement du code qu'il doit vérifier. Si le code contient une erreur, l'erreur devient une assertion. Le test est vert et protège l'erreur.

Que dit la couverture de tests – et que ne dit-elle pas ?

La couverture est une statistique d'exécution. Elle répond à la question : quelles lignes, branches ou conditions ont été touchées pendant l'exécution des tests ? Elle ne répond pas à la question : a-t-on vérifié que le résultat obtenu était le bon ?

Un test qui appelle une fonction et ne contient aucune assertion produit une couverture totale pour cette fonction. Ce n'est pas un contre-exemple fabriqué – c'est un schéma qui apparaît dès qu'un seuil de couverture est fixé comme objectif.

Pourquoi les tests générés par IA sont-ils particulièrement trompeurs ?

Parce qu'ils sont déduits de l'état existant au lieu d'une exigence. Le déroulement habituel est le suivant : le code existe, on demande au modèle d'écrire des tests pour lui, le modèle lit le code et produit des assertions qui lui correspondent.

Le résultat ressemble à une vérification et n'est qu'une description. Si le code calcule mal la TVA, le test généré attend le montant erroné. Il restera fiablement vert, même si quelqu'un corrige plus tard l'erreur – il échoue alors et est considéré comme cassé.

Cette inversion explique une partie des frictions que les développeurs rapportent avec le code IA : dans la Stack Overflow Developer Survey 2025, 45 % des personnes interrogées ont indiqué perdre un temps considérable à déboguer du code généré par IA. Un test qui porte l'erreur au lieu de la signaler allonge précisément cette recherche.

C'est l'inversion du but véritable : un test doit consigner le comportement souhaité, non le comportement constaté. Lors de la sécurisation d'un code ancien, consigner l'état existant est expressément voulu – pour du code nouveau, c'est une erreur. La différence doit être connue de l'équipe, voir Moderniser le code hérité avec l'IA.

Quel indicateur devrais-je utiliser à la place ?

La couverture des lignes modifiées, non la couverture globale. Trois raisons plaident en ce sens.

• Elle est pilotable. La couverture globale d'un projet établi ne bouge guère, quoi que l'on fasse – le dénominateur est trop grand. La couverture du code nouveau réagit immédiatement.
• Elle est équitable. Personne n'est tenu responsable d'un héritage qu'il n'a pas causé.
• Elle agit de façon cumulative. Si chaque modification est bien couverte, la valeur globale monte d'elle-même – là où l'on travaille réellement.

Comme seuil, la règle suivante convient : la couverture des lignes modifiées n'est pas inférieure à la valeur existante du projet. Cette règle n'exige aucun pourcentage arbitraire et empêche la dégradation.

Comment vérifier que mes tests valent quelque chose ?

Avec des tests de mutation – la seule méthode répandue qui mesure la qualité des tests eux-mêmes.

Le procédé est simple : un outil modifie le code de production de façon ciblée et minimale – inverse un opérateur de comparaison, remplace une valeur de retour, supprime un appel – puis lance les tests. Si aucun test ne remarque la modification, la suite de tests présente une lacune à cet endroit, indépendamment de ce que dit la couverture.

C'est précisément ce contrôle qui démasque le raisonnement circulaire évoqué plus haut : un test dont les assertions ont été déduites du code survit à certaines mutations, parce qu'il ne fige pas réellement le comportement. Les tests de mutation sont gourmands en calcul et n'ont pas leur place à chaque exécution – une fois par semaine ou sur les modules critiques suffit pour obtenir l'information.

De quels tests le code généré par IA a-t-il particulièrement besoin ?

De tests pour les cas qui n'apparaissaient pas dans le prompt – c'est là que se trouvent les lacunes avérées.

• Les cas d'erreur. Saisie manquante, mauvais type, liste vide, dépassement de délai du service tiers. Les exceptions mal traitées forment depuis 2025 une catégorie OWASP à part entière (A10).
• Les autorisations. Un test qui vérifie qu'un autre utilisateur n'y a pas droit. Le contrôle d'accès défaillant occupe la première place des OWASP Top 10:2025 – et ce contrôle est ce qui manque le plus souvent dans le code généré.
• Les limites. Zéro, un, le maximum, un au-dessus.
• La simultanéité. Deux opérations sur le même enregistrement. Jamais survenu dans le prototype, dès le premier jour en production.

Ces quatre groupes, une IA peut d'ailleurs très bien les écrire dès qu'on le lui demande expressément. Le point est qu'elle ne le demande pas d'elle-même.

Questions fréquentes sur la couverture de tests

Quelle couverture de tests est suffisante ?

Il n'existe pas de chiffre universel, et tout pourcentage cité est une convention, pas une norme. La règle relative est fiable : le code nouveau n'est pas inférieur à la valeur existante du projet.

Dois-je laisser une IA écrire les tests ?

Oui, mais dans l'ordre inverse : décrivez d'abord le comportement souhaité en prose et faites-en générer des tests – non à partir du code terminé. Ainsi naît une vérification au lieu d'une description.

Quelle différence entre couverture de lignes et couverture de branches ?

La couverture de lignes compte les lignes exécutées, la couverture de branches compte les chemins de branchement parcourus. Une condition à deux branches atteint une couverture de lignes totale si un seul des deux chemins a été testé. La couverture de branches est le chiffre le plus parlant.

Les tests de bout en bout valent-ils la peine pour le code IA ?

Pour les chemins principaux, oui, car ils vérifient l'interaction – et c'est précisément là que se trouvent plus souvent les erreurs du code généré que dans des fonctions isolées. Comme couverture étendue, ils sont trop lents et trop fragiles.

Une exécution de tests verte n'est une preuve que lorsqu'elle n'est pas seulement affirmée. Code Guardian exige, à la clôture de chaque modification, la sortie de la vérification – et ne laisse même pas passer une modification sans tests.

Sources

• OWASP Top 10:2025, catégories A01 « Broken Access Control » et A10 « Mishandling of Exceptional Conditions ».
• Stack Overflow Developer Survey 2025 (45 % des personnes interrogées perdent un temps considérable à déboguer du code IA).

Mise à jour : 27 juillet 2026. Analyse professionnelle générale.