Le test manuel est-il en train de mourir ?

Voici la position que défend cette page. L'activité de tester à la main devient plus précieuse à l'heure et est requise en un nombre total d'heures moindre. Le jugement humain sur le risque est vraiment irremplaçable. Mais un travail irremplaçable se concentre quand même dans moins de personnes, plus seniors. Une équipe qui avait autrefois besoin de cinq testeurs manuels pour traverser un cycle de régression n'a plus besoin que d'un testeur solide doté de jugement, plus une suite. C'est une excellente nouvelle pour l'un et une nouvelle difficile pour les quatre autres.

Si vous êtes ingénieur QA manuel avec quelques années d'expérience, la question qui vous intéresse vraiment n'est pas philosophique. C'est de savoir s'il faut passer la prochaine année de soirées à apprendre à coder. La réponse est oui — et la raison n'est pas que le test manuel est sans valeur. C'est que « testeur manuel » n'est plus une position défendable à tenir seule, et que ceux qui y restent se disputent un nombre décroissant de sièges contre tous les autres qui y sont restés.

Ce qui a réellement changé

Trois choses, aucune n'étant « l'IA a remplacé les testeurs ».

L'exécution de la régression s'est automatisée, lentement, sur quinze ans. Ce n'est ni nouveau ni de l'IA. La part de la semaine d'une équipe QA passée à rejouer à la main des scénarios connus baisse depuis longtemps — et ce travail était l'employeur de masse des testeurs manuels.

La production d'artefacts de test est devenue bon marché. Écrire des cas de test, remplir un modèle de plan de test, rédiger une matrice de traçabilité, générer cent permutations d'entrées. Un LLM fait ça en secondes, à peu près à la qualité du premier jet d'un testeur intermédiaire. Si une part significative de votre production visible était des documents, votre production visible vient de devenir une commodité. C'est le changement qui est arrivé le plus vite et qui a fait le plus mal, parce que les documents étaient la façon dont beaucoup de testeurs démontraient qu'ils travaillaient.

L'automatisation est devenue bien plus facile à démarrer. Écrire un premier test Playwright est bien moins pénible que ne l'était l'écriture d'un premier test Selenium, et l'assistance de l'IA aplatit encore le début de cette courbe. La conséquence n'est pas que les ingénieurs automatisation sont obsolètes. C'est que « je sais écrire un test UI basique » a cessé d'être un facteur de différenciation, et que la barre est montée vers la conception de framework, l'instabilité, la CI, et savoir ce qu'il ne faut pas automatiser.

Remarquez qu'aucune de ces choses n'a supprimé le besoin de décider ce qui compte. Elles ont supprimé le besoin que des humains fassent les parties mécaniques autour de cette décision.

Ce en quoi l'IA est vraiment mauvaise

Savoir ce que « faux » veut dire ici. Un modèle peut vous dire que le bouton est mal aligné. Il ne peut pas vous dire qu'un délai de 200 ms sur cet écran précis provoquera des tickets de support, parce que c'est l'écran où les utilisateurs saisissent leurs coordonnées de paiement sous pression temporelle. Cette connaissance vit dans la tête des gens qui l'ont vu arriver.

Décider ce qu'il ne faut pas tester. La compétence difficile en QA a toujours été la soustraction. Avec quatre heures avant la release, que vérifiez-vous ? Les modèles sont biaisés vers l'exhaustivité et produisent d'énormes suites indifférenciées. Quelqu'un doit dire « ces onze cas comptent, supprimez le reste » — et avoir raison, et être responsable d'avoir raison.

Tester à travers les jointures. Les bugs de production les plus coûteux vivent entre les systèmes : le webhook du prestataire de paiement arrive deux fois, le fuseau horaire se convertit mal entre deux services, une nouvelle tentative crée une commande en double. Trouver ceux-là exige de tenir un modèle mental du système entier, y compris les parties que personne n'a documentées.

Être responsable. Quelqu'un valide la release. « Le modèle a dit que c'était bon » n'a jamais été une réponse acceptable à une revue d'incident et ne le deviendra pas.

Il y a aussi des preuves que l'ambition court devant le déploiement. Le World Quality Report 2025–26 a constaté que la grande majorité des organisations poursuivent l'IA générative en ingénierie qualité tandis qu'une petite fraction seulement l'a déployée à l'échelle de l'entreprise, la fiabilité et l'intégration figurant parmi les principaux blocages. La plupart des équipes en sont au pilote. Les pilotes ont besoin de gens qui comprennent le test pour les évaluer.

La partie inconfortable

La section ci-dessus est là où la plupart des articles s'arrêtent, et c'est là qu'ils deviennent malhonnêtes par omission.

« Le test exploratoire est irremplaçable » est vrai. Ça ne protège pas votre emploi. Le test exploratoire est une activité à haute compétence et à faibles effectifs : un produit qui avait besoin d'une équipe de six pour la régression scriptée pourrait n'avoir besoin que de deux personnes faisant un travail exploratoire sérieux. Le travail est plus intéressant, plus précieux, mieux payé — et il y en a moins. Être irremplaçable dans l'ensemble n'est pas la même chose qu'être individuellement difficile à remplacer.

Deuxièmement, le test exploratoire n'est pas une activité junior. C'est généralement la chose la plus dépendante de l'expérience qu'un testeur fasse. Donc le terrain sûr est réel, mais il est en montée par rapport à là où beaucoup de gens se tiennent, et le pointer comme réconfort sans dire « et voici la montée » n'aide pas.

Troisièmement, le marché demande de plus en plus aux testeurs manuels de prouver une crédibilité technique avant d'écouter leur jugement. C'est en partie injuste — le jugement n'exige pas Python. Mais les process de recrutement ont besoin d'un filtre, et le code en est un lisible. Savoir lire la base de code, interroger la base de données, inspecter l'onglet réseau et écrire un script rend aussi votre jugement meilleur et vos rapports de bug bien plus difficiles à balayer.

Alors que devrait vraiment faire un QA manuel

Pas « apprendre l'automatisation » dans l'abstrait. Ce conseil est donné depuis une décennie et n'a pas marché, parce qu'il n'a ni séquence ni moyen de dire si vous progressez.

Apprenez correctement un langage. Python ou TypeScript. Correctement veut dire que vous savez résoudre un problème que vous n'avez pas vu avant, pas que vous avez fini un tutoriel. La plupart des gens qui stagnent stagnent ici — ils ont sauté à Selenium avant de savoir écrire une boucle avec assurance, puis ont passé un an à copier des extraits qu'ils ne savaient pas déboguer. Le Code Lab existe exactement pour ça : écrire et exécuter du vrai code, sans solution de référence ouverte dans l'onglet d'à côté.

Construisez une chose qui existe. Un petit framework qui teste un vrai site public, dans un dépôt que vous pouvez envoyer à quelqu'un. Config pour deux environnements, un peu de setup API pour que les tests UI ne se connectent pas via le formulaire à chaque fois, une exécution CI au push. Cet unique artefact fait plus en entretien que n'importe quel certificat, parce qu'il est vérifiable. Entraînez la moitié « sélecteurs » de cette compétence dans le Locator Lab.

Devenez technique sur le poste que vous avez déjà. Lisez les logs. Apprenez le schéma. Reproduisez un bug via l'API plutôt que l'UI. Demandez le ticket avant le build. Rien de tout cela ne demande d'autorisation, et tout cela est de la matière pour des réponses d'entretien sur l'impact — le correcteur d'histoires STAR est un moyen brutal de vérifier si une réponse porte réellement un résultat ou juste une description de ce que vous avez fait.

Utilisez l'IA comme un collaborateur rapide, pas comme un oracle. Les testeurs qui s'en sortent bien avec la traitent comme un junior très rapide : demandez-lui le premier jet, puis soyez la personne qui sait quelles parties sont fausses. Ce rôle n'existe que si vous comprenez le domaine assez bien pour relire la sortie. Il récompense l'expérience plutôt que de la remplacer.

Cessez de vous décrire comme un testeur manuel. Pas comme une astuce — parce que le cadrage utile, c'est ce dont vous êtes responsable, pas l'outil que vous utilisez. « Je possède la qualité du tunnel de paiement » est exact et ne vous met pas dans une catégorie que les gens filtrent activement.

À quoi ça ressemble en douze mois

Réalistement, avec un emploi à temps plein et la plupart des soirées : quelques mois pour devenir vraiment à l'aise à écrire du code, quelques mois de plus pour construire une automatisation UI et API que vous comprenez vraiment, puis une période sur l'architecture, la CI et la préparation aux entretiens. Disons six à douze mois pour être interviewable pour un rôle d'automatisation ou de SDET junior, la fourchette dépendant de la régularité avec laquelle vous savez protéger les heures plutôt que de votre intelligence.

Les gens qui n'y arrivent pas n'échouent généralement sur aucun contenu technique. Ils échouent sur la séquence. Ils recommencent quatre fois, chaque fois depuis une playlist YouTube différente, et après un an ils ont quatre fondations partielles et aucune preuve d'aucune d'elles. Ce mode d'échec est la raison pour laquelle le parcours est ordonné et fini plutôt qu'une bibliothèque de contenu, et pourquoi l'échelle de carrière nomme ce sur quoi chaque niveau est jugé plutôt que de lister des outils à apprendre.

Le résumé honnête de la position

Le test manuel en tant que compétence prend de la valeur. Le test manuel en tant qu'intitulé de poste en perd. Que ce soit une bonne ou une mauvaise nouvelle pour vous personnellement dépend entièrement de savoir si votre valeur est dans le jugement ou dans l'exécution — et de savoir si vous pouvez démontrer le jugement à quelqu'un qui ne vous a jamais rencontré. Où atterrissent les deux rôles après la transition est cartographié dans SDET vs ingénieur QA.