Tester un logiciel que vous n'avez pas conçu signifie que vous ne disposez pas du modèle mental utilisé par l'auteur. Avec du code généré par l'IA, il n'y a pas eu d'auteur humain, de sorte que ce modèle peut tout simplement ne pas exister. La conséquence pratique est que les métriques de couverture deviennent des indicateurs peu fiables pour évaluer la confiance.
Pourquoi la couverture est trompeuse ici
La couverture des lignes et des branches vous indique quel code a été exécuté lors des tests. Elle ne dit rien sur le fait que les tests aient été écrits pour sonder le bon comportement. Lorsqu'un modèle génère à la fois l'implémentation et la suite de tests, les tests tendent à refléter les mêmes hypothèses qui ont façonné le code. Les lacunes dans la compréhension du modèle apparaissent aux deux endroits simultanément, de sorte que les indicateurs de couverture semblent satisfaisants tandis que des scénarios significatifs ne sont pas testés.
Ce n'est pas un risque théorique. Les modèles d'IA génèrent du code d'apparence plausible. Plausible et correct ne sont pas la même chose, et un test écrit par le même modèle que celui qui a écrit la fonction mettra rarement en évidence la différence.
Que faire à la place
Le changement consiste à passer de la mesure de l'exécution au raisonnement sur le comportement.
Commencez par la spécification, pas par le code. Écrivez les tests à partir des exigences ou du comportement attendu avant de lire l'implémentation. Si aucune spécification n'existe, rédigez-en une, même brièvement, avant d'ouvrir le fichier généré. Cela évite que le code n'ancre vos attentes.
Testez les cas limites que le modèle était peu susceptible de prendre en compte. Les modèles gèrent bien le cas nominal. Les cas limites impliquant des entrées vides, des écritures concurrentes, des différences de locale, un dépassement d'entier ou des permissions manquantes sont plus susceptibles d'être insuffisamment couverts. Énumérez-les de façon indépendante.
Utilisez les tests basés sur les propriétés lorsque c'est applicable. Plutôt que d'affirmer des sorties spécifiques, affirmez des invariants : une fonction de tri doit toujours renvoyer une liste de même longueur ; une fonction de tarification ne doit jamais renvoyer une valeur négative. Les outils basés sur les propriétés génèrent automatiquement des centaines d'entrées et mettent en évidence les hypothèses que le modèle a intégrées implicitement.
Lisez le code pour comprendre l'intention, pas seulement la correction. Avant de faire confiance à la suite de tests, parcourez l'implémentation et demandez-vous pour quoi le code est optimisé. Le code généré par l'IA résout parfois un problème légèrement différent de celui énoncé, notamment lorsque la consigne était ambiguë. Comprendre le comportement réel, plutôt que le comportement prévu, change ce que vous testez.
Traitez les appels externes avec un scepticisme accru. Le code généré qui appelle des API, des bases de données ou des files de messages se contente souvent de simuler ces dépendances dans les tests. Vérifiez si les simulations reflètent le comportement réel de la dépendance, y compris les modes de défaillance et les limites de débit, et pas seulement le cas de succès.
La question de la confiance
La couverture est un indicateur de confiance parce que, dans du code écrit par un humain, la personne qui l'a rédigé a généralement aussi conçu les tests pour détecter les problèmes qui la préoccupaient. Cette relation disparaît lorsque le code et les tests partagent une origine automatisée unique.
La confiance dans le code généré par l'IA doit venir d'ailleurs : de la compréhension de ce que fait le code, de tests écrits à partir de la spécification plutôt que de l'implémentation, et d'une attention systématique aux catégories de défaillances que les modèles sous-estiment systématiquement.
Ce sujet est lié à une question plus large : comment relire du code généré par IA. La revue de code et les tests sont deux activités distinctes. Quand le code n'a aucun concepteur humain, elles doivent pourtant se compléter davantage que d'habitude. Un ingénieur qui sait seulement lancer un linter et vérifier la couverture n'est pas équipé pour cela.
Cela rejoint également ce qui a changé dans la révision de code de manière plus générale. L'ingénieur chargé de la révision est désormais la principale source de jugement de conception, et pas seulement un approbateur du travail de quelqu'un d'autre.
Ce que nous évaluons
Trois de nos critères de scorecard portent directement sur ce point. La vérification des sorties de l'IA évalue si un ingénieur détecte des API hallucinées, une logique subtilement incorrecte ou des failles de sécurité avant que le code généré ne soit mis en production. Le jugement par le risque examine si l'effort de relecture est proportionnel aux conséquences, et non à l'assurance affichée par l'agent. La prise en charge couvre les tests, l'observabilité et le débogage après mise en production, quel que soit l'auteur du code. Les deux sessions testent ces compétences dans des conditions réalistes, avec et sans outils d'IA. Voir notre processus de sélection.
Réponses courtes
Pourquoi une couverture à 100 % ne suffit-elle pas pour le code généré par l'IA ?
La couverture mesure quelles lignes ont été exécutées, pas si les bonnes questions ont été posées. Lorsque le même modèle écrit le code et les tests, les deux partagent les mêmes angles morts. Une couverture élevée peut coexister avec de larges catégories de comportements non testés.
Faut-il écrire les tests avant ou après avoir lu le code généré par l'IA ?
Avant, dans la mesure du possible. Lire l'implémentation en premier ancre vos attentes sur ce que le modèle a produit. Écrire les tests à partir des spécifications en premier vous oblige à définir le comportement attendu de manière indépendante, ce qui permet de détecter les divergences de façon plus fiable.
Quels types de défaillances les tests générés par l'IA manquent-ils le plus souvent ?
Les cas limites avec des entrées vides ou mal formées, les accès concurrents, les défaillances de dépendances externes, la sensibilité aux paramètres régionaux ou aux fuseaux horaires, et les limites de permissions. Les modèles optimisent pour le chemin nominal ; les tests systématiques doivent couvrir les cas peu probables mais à forte incidence.
