Qui teste le code écrit par l'IA ? Quand un test vert cesse d'être une preuve

Beaucoup d'équipes ont construit, sans s'en rendre compte, cette boucle : l'IA écrit le code, l'IA écrit les tests, la CI passe au vert et la production casse. Chaque étape semble raisonnable prise seule. Le problème est dans la somme, car personne dans la boucle n'est indépendant de celui qui a écrit le code.

Les chiffres de 2026 pointent vers cette tension. Dans une enquête d'Applause menée en août et publiée le 30 septembre, plus de 92 % des répondants utilisaient l'IA dans leur processus de test, contre 59,6 % lors de l'enquête précédente, et 29 % ont signalé une hausse du nombre ou de la gravité des défauts. Dans une autre, celle de SmartBear, auprès de 1 436 participants aux États-Unis et au Royaume-Uni, 46 % des équipes avaient déjà mis en production du code généré par IA qui a ensuite échoué, et pourtant 69 % de ce groupe gardait beaucoup ou une totale confiance dans le fait que ce type de code se comporte comme prévu. Je traite ces chiffres comme un indice, et non comme un verdict, car ce sont des enquêtes de fournisseurs, avec leurs propres échantillons et critères. Malgré cela, la combinaison de plus de vitesse, plus de défauts et d'une confiance intacte décrit un problème que toute personne du QA reconnaît.

Pourquoi un test vert ne prouve plus rien

Quand le test est généré à partir du code, il hérite des mêmes hypothèses que le code. Si l'implémentation a mal compris l'exigence, le test la comprend mal de la même façon, et les deux s'accordent entre eux. Prenons un paiement en plusieurs fois, en centimes :

// code généré
function parcelar(totalCentavos, n) {
  return Array(n).fill(Math.round(totalCentavos / n));
}

// test généré à partir du code
expect(parcelar(1000, 3)).toEqual([333, 333, 333]);

Le test passe, mais la somme des échéances est de 999 : un centime a disparu. Le test a copié le comportement du code, et non l'exigence, qui dit que les échéances doivent totaliser le montant. Un test dérivé de l'exigence échoue dès la première ligne :

// test dérivé de l'exigence
const p = parcelar(1000, 3);
expect(p.reduce((a, b) => a + b, 0)).toBe(1000);
expect(Math.max(...p) - Math.min(...p)).toBeLessThanOrEqual(1);

La question qui sépare les deux tests est simple : d'où vient la valeur attendue ? Si elle vient du code, le test confirme seulement que le code fait ce que le code fait. Si elle vient de l'exigence, il peut la contredire, et c'est cette capacité à contredire qui donne sa valeur à un test. Avec une bibliothèque de tests basés sur les propriétés, comme fast-check, ces deux dernières lignes deviennent une règle vérifiée sur des milliers d'entrées générées.

Il existe une deuxième vérification peu coûteuse : se demander si le test peut échouer. Les outils de test de mutation, comme Stryker (JavaScript et TypeScript) et PIT (Java), modifient volontairement le code et vérifient si un test s'en aperçoit. Dans l'exemple ci-dessus, remplacer Math.round par Math.floor ne change rien pour le test généré, et une suite qui ne remarque pas ce remplacement ne protège pas ce qu'elle semble protéger. La couverture de lignes dit que le code s'est exécuté, alors que la mutation dit si le test remarquerait une erreur.

Ce qui change pour le QA

Si générer du code et des tests est devenu bon marché, le travail du QA se déplace vers la question la plus coûteuse : peut-on faire confiance au processus qui a produit ce logiciel ? C'est plus que trouver des bugs en fin de chaîne. Cela signifie mesurer la confiance avec des preuves, et non la déclarer. Quelques mesures aident : le score de mutation sur les modules critiques, le taux de tests instables, les défauts échappés en production et le temps que l'équipe met à mettre à jour l'automatisation après un changement. Dans une enquête de Leapwork en partenariat avec SD Times, auprès de 302 répondants entre décembre 2025 et janvier 2026, 56 % ont cité la maintenance des tests comme ce qui ralentit le plus leurs équipes, juste derrière la création de tests, citée par 71 %, ce qui montre que l'automatisation seule ne suffit pas.

En pratique, trois habitudes changent beaucoup le résultat. La première est d'écrire la valeur attendue à partir de l'exigence avant de demander le code à l'IA. La deuxième est de relire chaque test généré avec la question sur l'origine de la valeur attendue. La troisième est de lancer la mutation sur les chemins qui ne peuvent pas échouer, comme le calcul de montants, l'autorisation et l'intégration avec des tiers. Et comme aucune suite ne couvre tout, il vaut la peine d'ajouter de l'observabilité et un déploiement progressif en production, pour que l'erreur qui a échappé apparaisse petite et soit annulée vite.

Ce travail exige de lire du code et d'en écrire, et il fonctionne donc mieux quand le QA et le développement cessent d'être des camps opposés. La vitesse de l'IA est un fait. La confiance dans ce qu'elle livre reste quelque chose que l'équipe doit construire, test après test, avec des preuves.