Tester un logiciel demande sans cesse de nouvelles techniques. Explorer un dataset pour identifier les données qui révèlent les vrais comportements. Concevoir une stratégie de test pour du machine learning, où le bug naît parfois des données, et non pas toujours du code. Et aujourd’hui encore, tester ce que les LLM génèrent, plus vite et en plus grand volume.
Ce qu’un testeur maîtrise aujourd’hui peut être automatisé demain. C’est la vitesse à laquelle il apprend qui prime désormais.
Et la valeur se déplace avec : du savoir-faire technique accumulé vers le jugement. Savoir ce qui manque, ce qui sonne faux, ce qui passerait en prod ou pas.
Mais le jugement d’un testeur, aussi affûté soit-il, ne suffit pas seul. Les LLM, par exemple, gagnent du terrain dans les pratiques de test, et pourtant, les délais restent trop longs et les défauts continuent de passer en production. Il manque encore de la visibilité sur les vrais problèmes, et l’organisation pour les traiter. L’expérience montre que pour des testeurs, ce qui change tout, c’est un système où les problèmes de tests remontent naturellement et où chacun développe le réflexe de les traiter de la bonne manière. Ce n’est pas une méthode de plus, mais plutôt une façon de travailler.
Les vrais défis du test aujourd’hui
J’accompagne des équipes de test depuis plusieurs années et je vois revenir les mêmes difficultés.
La pression sur les coûts ne s’arrête jamais. Les clients demandent des tarifs plus bas. En réaction, les sociétés de service en test logiciel externalisent encore des équipes, mais les résultats restent mitigés.
La demande de tests est en dents de scie. Un pic soudain, puis trois semaines de creux. Quelle que soit l’organisation en face, il faut absorber les deux situations, avec les difficultés de recrutement que ça crée.
Les managers manquent de visibilité. Face aux marges trop faibles ou trop variables de l’activité de test logiciel, ils veulent comprendre ce qui se passe concrètement dans les campagnes au jour le jour. Les rapports Excel et les Powerpoint ne suffisent plus.
Les testeurs cherchent du sens. Beaucoup veulent faire évoluer rapidement leurs compétences pour rester employables. Or on perçoit encore le test comme répétitif, sans ouverture. Il faut manager autrement. Et les approches classiques s’essoufflent. Mutualisation, revues, audits, refontes de processus, bases de connaissance : plus rien de tout ça ne fait évoluer une équipe de test au rythme qu’imposent les clients.
Plus de tests, pas plus de valeur
Les LLM ont changé la façon dont le code et les tests se produisent. On génère des cas de test en masse. Sur le papier, tout accélère.
Sur le terrain, le travail ne se livre pas plus vite ou au rythme voulu par les clients. Le goulot a juste changé de place. Ce n’est pas nouveau : l’automatisation a toujours déplacé le goulot, les LLM l’ont juste rendu brutal. Écrire un test n’est plus le problème. C’est le relire, juger si le défaut remonté est réel, décider ce qui vaut la peine d’être testé. Générer mille cas de test ne couvre pas mieux le risque ! Souvent, ça ajoute du bruit, des faux positifs, et de la maintenance.
Et c’est là que ça se gâte. Le réflexe, face à une équipe débordée, c’est d’ajouter un outil. Un LLM de plus, par-dessus un flux qu’on ne voit toujours pas. Le système ne devient pas plus clair. En réalité, il devient plus opaque. On automatise le symptôme.
J’ai vu une équipe de testeur décupler son nombre de tests générés et passer quand même à côté du seul cas d’utilisation qui comptait, tout en croulant sous la maintenance. Plus de volume n’est pas plus de valeur.
Pourquoi il vous faut un système
Reprenez la liste des défis ci-dessus. Ce ne sont pas des problèmes séparés. Ce sont, en réalité, les symptômes d’une seule et même chose : l’absence d’un système qui rend le travail visible et qui apprend à l’équipe à s’améliorer.
Un framework organise le travail. Il ne le répare pas. Il ne développe pas le jugement. Les revues, les audits, les bases de connaissance, l’externalisation, le dernier outil d’IA : des contenants et des rustines, pas des systèmes. On ne corrige pas ce qu’on ne voit pas. Et on ne tient pas dans le temps ce qui dépend du coach ou de l’outil au lieu de l’équipe elle-même.
La question n’est donc pas « quel outil » ni « quel process ». C’est : avez-vous un système qui rend les problèmes visibles et qui forme vos gens à les résoudre ? Le testeur cesse alors d’être uniquement un exécutant. Il devient aussi le porteur de l’amélioration continue. C’est précisément ce que le Lean Management apporte. Un système Lean pour les tests, c’est une façon de travailler où l’équipe voit son propre travail et le corrige elle-même. Les problèmes ne s’accumulent plus en silence. Ils remontent tôt, et l’équipe les traite au fur et à mesure. Ce qu’elle construit ainsi, c’est une capacité qui tient debout toute seule et qui s’améliore au fil du temps.
Ce que ça donne sur le terrain
Regardons des chiffres.
Une équipe de 15 testeurs, sur une application d’assurance complexe. Le client était excédé : trop de défauts, des bugs corrigés qui revenaient. En trois mois, les corrections en échec sont passées de 23 % à 10 %. La productivité a triplé. La satisfaction client est montée de 2 points.
Une autre équipe, 13 testeurs sur deux sites, qui validait des scénarios de facturation avant chaque mise en production. Les tests démarraient trop lentement en début de campagne, et personne ne voyait ce qui se passait au quotidien. En trois jours, l’équipe a su construire son propre plan d’action, précis, pour retourner la situation. Au bout de trois mois, la productivité a gagné 24 %.
Deux choses montent toujours ensemble dans ces transformations : la performance et l’engagement. Les testeurs deviennent plus autonomes, ils portent eux-mêmes les améliorations, et le management apprend à dialoguer sur des faits.
Ni l’une ni l’autre ne croulait sous des tests générés par IA. Et pourtant c’est le même système qui absorbe ce flot, parce qu’il travaille la visibilité et le jugement. Or les LLM ne remplacent ni la visibilité ni le jugement. Ils les rendent encore plus nécessaires.
Comment ça marche, concrètement
L’implémentation d’une telle démarche, requiert une séquence et de la discipline.
Rendre le flux visible. Un cas de test suit un flux : par exemple, « conçu, écrit, exécuté, terminé. » Rendez-le visible, de façon physique ou digitale. J’ai rencontré une équipe qui suivait sa production trois fois par jour, à 11 h, 15 h et en fin de journée, sur un tableau mural. Quand l’exécution décrochait à 15 h, tout le monde le voyait, et on agissait le jour même. On ne peut corriger ce qu’on ne voit pas.
Tirer le flux depuis la date de livraison. Si 30 cas de tests doivent être prêts vendredi, ça fait 6 par jour. Le flux tiré fait remonter les blocages avant qu’ils ne deviennent des retards.
Résoudre les problèmes en équipe (PDCA). Chaque blocage visible devient un sujet de résolution. C’est là que la qualité se gagne, et que l’amélioration continue se diffuse.
Atteindre la cadence du client. La cadence n’est pas le point de départ. C’est le résultat des trois premiers. Et une chose que je ne néglige jamais : ritualiser un tête-à-tête de 20 minutes par jour, entre deux testeurs, pour transmettre une compétence précise. C’est un investissement qui grandit au fil du temps. Les bonnes pratiques se diffusent, la variabilité baisse, l’équipe se renforce toute seule.
Le métier de testeur évolue
Le vrai livrable d’une transformation Lean, ce ne sont pas les chiffres. C’est ce qui reste quand le coach est parti.
Une équipe qui sait voir son propre travail, repérer ses blocages et les résoudre sans qu’on le lui impose d’en haut. Un testeur qui comprend les enjeux de son client et qui apporte de la valeur par de nouvelles solutions. C’est une mutation de métier, et pas une optimisation de processus.
Les approches classiques s’essoufflent. Aujourd’hui, l’IA, avec les LLM, accélère la production sans réparer le système qui l’absorbe. Le Lean Testing fait l’inverse : il redonne à l’équipe la capacité de s’améliorer elle-même. Commencez par une seule chose. Rendez votre flux de test visible cette semaine, et regardez ce que vous n’aviez jamais vu.
J’ai documenté ces deux transformations en détail, chiffres et méthode, sur le blog LeanTechPro : le cas de l’assurance et le cas de la facturation.
