Les effets de l'IA sur les tests unitaires et fonctionnels

Publié le 11 août 2025

J'ai toujours été contre les tests, qu'ils soient unitaires ou fonctionnels — je trouve ça contre-productif.

L'impact des tests

Empiriquement, qu'est-ce que ça donne ?

Empiriquement déjà, avec plus de 10 ans de carrière, j'ai toujours constaté autour de moi ainsi que dans mon entourage que les projets à succès n'avaient strictement aucun tests — le contraire des bonnes pratiques attendues.

Quand je parle de projet à succès, j'entends par là un projet qui rapporte de l'argent — celui qui permet de payer nos salaires. Cela peut être le projet d'une startup ou bien le projet legacy d'une entreprise, ce projet "mal codé" que personne ne comprend vraiment mais qui plaît pourtant aux clients.

C'est le point commun entre tous les projets legacy : ils génèrent des revenus, sinon ils auraient été abandonnés depuis longtemps. Et surtout, ils ont été conçus sans aucun test.

Aujourd'hui, on fait les choses bien, une belle architecture, des sprints bien organisés, de belles pipelines et des tests dans tous les sens. Tout le monde travaille comme cela maintenant — mais en attendant, ce qui marche c'est l'inverse.

Les tests, c'est fastidieux

En dehors du côté empirique, ce qui me gêne avec les tests, c'est que c'est long et fastidieux à coder. Pour développer une nouvelle feature, 50% du temps de développement est consacré à l'écriture des tests. Non seulement, cela prend la moitié du temps mais en plus cela demande plus d'énergie et de concentration que la fonctionnalité en elle-même. Il faut penser à couvrir tous les cas d'utilisation possibles, y compris les plus tordus — cela demande beaucoup d'énergie — énergie qui pourrait être utilisée pour développer d'autres fonctionnalités ou corriger des bugs. Ajoutez à cela, qu'en cas du moindre petit refacto ou changement de feature au prochain sprint, tous les tests vont casser et il faudra les recommencer.

C'est pour cela que je trouve les tests contre-productifs. Je pense que c'est utile seulement pour les fonctionnalités complexes ou critiques de l'application.

Il est plus efficace de ne pas écrire de test et, lors de la découverte de bugs, de les corriger rapidement. Cela fait gagner tellement de temps que ça permet de corriger plus de bugs et de développer plus de features. Même si moins de bugs sont attrapés, diviser le temps de dev par deux en supprimant les tests permet d'aller théoriquement deux fois plus vite. Divisant aussi les coûts de dev théoriquement par deux. On comprend vite pourquoi certains projets sont réussis et rentables et d'autres non.

Les tests et le moral

L'autre point négatif des tests est le moral. Les tests, ce n'est pas fun à écrire. Personne ne devient développeur par passion pour écrire des tests. La preuve, personne n'écrit de tests dans ses projets persos.

Quand tu passes 50% de ton temps à faire quelque chose que tu n'apprécies pas, cela pèse sur le moral. Personne ne l'avoue car personne ne veut passer pour quelqu'un de démotivé — mais ça pèse.

Il est normal de faire des choses que l'on n'aime pas, on passe tous l'aspirateur chez nous, pourtant personne n'aime le passer. S'il fallait passer 50% de son temps libre à passer l'aspirateur, je pense que tout le monde trouverait cela problématique. Regardez combien de personnes laissent traîner la vaisselle dans l'évier — on voit bien que ça pèse sur la motivation.

Un dev moins motivé, c'est un dev moins performant. Si non seulement il ne passe que 50% de son temps à développer des features, s'il est démotivé, cela devient encore plus problématique.

L'arrivée de l'IA

L'IA a totalement changé la façon de développer des applications. Elle est décriée pour sa qualité de code produite et par les problèmes de maintenabilité que cela va engendrer. Mais l'amélioration constante des modèles a fortement amélioré la qualité du code généré. Depuis l'arrivée de Claude 4 en mai, son efficacité est encore plus importante — et cela ne va faire que s'améliorer au cours des prochaines années.

Je pense qu'au contraire des idées répandues, l'IA va améliorer la qualité du code. Elle compense tous les défauts des tests.

En utilisant Claude Code (ou n'importe quel modèle performant), écrire des tests devient trivial et ne prend que quelques minutes. Pareil pour les refactos, Claude ne se plaindra jamais de devoir corriger les tests. En tant que dev, il n'est plus nécessaire de dépenser de l'énergie et de la concentration lors de la rédaction des tests. Il suffit juste de regarder que les tests générés soient corrects et cohérents. Plus de baisse de moral non plus après avoir passé une après-midi à écrire des tests.

L'IA va non seulement permettre d'accélérer le travail mais va permettre aussi aux développeurs d'écrire plus facilement et rapidement des tests s'assurant de la qualité du code.

Conclusion

Avec l'IA, nous allons enfin pouvoir profiter de tous les côtés positifs des tests sans aucun des côtés négatifs.

Les tests continueront à garantir la qualité du code, à détecter les régressions et à documenter le comportement attendu de l'application — tous les bénéfices que nous recherchions.

Mais nous n'aurons plus à subir la lenteur de développement, la frustration de l'écriture fastidieuse des tests, ni la démotivation qui en découle. L'IA s'occupe de la partie pénible, nous laissant nous concentrer sur ce que nous aimons vraiment : créer des fonctionnalités et résoudre des problèmes.

C'est probablement l'une des évolutions les plus importantes de notre métier : réconcilier enfin qualité et productivité.