Les titres QA Engineer, SDET et Automation Engineer décrivent des postes avec quasiment aucun recoupement au quotidien. Postuler en fonction du titre vous fait perdre des mois sur les mauvaises offres.
Pourquoi les titres de postes QA sont complètement cassés
Dans la plupart des secteurs, les titres de postes signifient à peu près la même chose d'une entreprise à l'autre. Dans le QA, le même titre peut décrire deux postes qui ne partagent presque rien au quotidien.
Cette confusion vient de plusieurs sources. Le test en tant que discipline a évolué vite. Des testeurs manuels dédiés dans les années 1990, on est passé aux rôles orientés automatisation dans les années 2000, puis aux postes à forte composante ingénierie aujourd'hui. Les titres n'ont jamais été standardisés dans le secteur. Les entreprises copient-collent aussi des titres depuis les sites d'offres sans réfléchir à ce qu'ils signifient. Quelqu'un aux RH voit "QA Automation Engineer" sur une offre d'un concurrent et reposte le même titre même si le travail réel est à 90 % manuel.
Résultat : "QA Engineer," "Software QA Engineer," "QA Automation Engineer," "SDET" et "Software Development Engineer in Test" peuvent décrire n'importe quoi. Du clic manuel dans une application web à la conception de l'infrastructure d'une plateforme de test utilisée par 200 ingénieurs.
Vous ne pouvez pas utiliser le titre pour comprendre le poste. Vous devez lire les exigences réelles.
Ce que "QA Engineer" signifie vraiment aujourd'hui
Historiquement, QA Engineer signifiait test manuel. Tests exploratoires, rédaction de cas de test dans des tableurs ou Jira, suivi des bugs, coordination des validations de release. Sans code requis.
Cette définition est largement obsolète, mais le titre persiste et peut aujourd'hui couvrir un large spectre. En pratique, quand une entreprise publie un poste de "QA Engineer" en 2026, elle veut généralement quelqu'un qui fait du test manuel comme travail principal. Un peu d'automatisation vient en complément. "Un peu d'automatisation" peut signifier lancer les tests Playwright de quelqu'un d'autre, écrire quelques scripts dans un framework existant, ou maintenir des collections Postman pour des smoke tests API.
Scénario typique : une startup de 40 personnes livre des fonctionnalités toutes les deux semaines. Elle publie une offre de "QA Engineer". Ce dont elle a réellement besoin, c'est de quelqu'un qui travaille étroitement avec les développeurs et les chefs de produit, détecte les problèmes avant la livraison des fonctionnalités. Ce quelqu'un rédige des cas de test qui documentent le comportement attendu et porte la conversation qualité pendant le sprint planning. Si cette personne peut aussi écrire quelques tests automatisés, tant mieux. Mais le rôle porte fondamentalement sur le jugement qualité produit, pas sur la production d'ingénierie.
C'est le profil type du QA Engineer dans la majorité des recrutements hors entreprises tech. Il comprend profondément le produit, communique clairement les défauts, et a suffisamment d'exposition à l'automatisation pour ne pas être ralenti par elle.
La fourchette salariale pour les QA Engineers au sens traditionnel est la plus basse des trois titres présentés ici. L'écart reflète la différence de demande technique, pas un jugement de valeur sur le travail.
Ce que SDET signifie et d'où ça vient
SDET signifie Software Development Engineer in Test. Microsoft a créé ce titre au début des années 2000 avec une définition précise. Un SDET écrit du code de qualité production pour tester des logiciels, évalué selon les mêmes standards d'ingénierie que les développeurs.
Chez Microsoft, les SDETs étaient des ingénieurs à part entière qui se concentraient sur la testabilité et l'infrastructure de test plutôt que sur les fonctionnalités produit. Ils concevaient des frameworks de test, écrivaient des outils utilisés par toute l'organisation QA, et révisaient le code de production pour sa testabilité. Ils étaient aussi censés prendre en charge des sous-systèmes entiers de la plateforme de test. Un SDET senior pouvait passer six mois à construire un système d'exécution de tests distribué qui réduisait le temps CI de deux heures à quinze minutes. Il n'écrivait pas le moindre test produit pendant ce temps.
Cette définition orientée ingénierie s'est propagée, mais elle s'est diluée. Aujourd'hui, "SDET" est utilisé de façon incohérente. Dans des entreprises comme Amazon, Google ou Meta, SDET signifie encore ce que Microsoft entendait : de l'ingénierie sérieuse appliquée à la qualité. Le niveau de codage est proche de celui d'un développeur. Dans des entreprises plus petites, "SDET" signifie parfois juste "nous voulons plus de rigueur d'ingénierie que ce que le titre QA Engineer implique."
Exemple concret de vrai travail SDET : une entreprise qui exécute 8 000 tests end-to-end constate que son pipeline CI prend 90 minutes. Un SDET est chargé de résoudre ce problème. Il analyse la distribution des tests, construit un système de sharding qui parallélise l'exécution sur 20 conteneurs, et écrit l'infrastructure-as-code pour les provisionner dynamiquement. Il ajoute aussi des outils d'observabilité pour que les tests flaky soient détectés et mis en quarantaine automatiquement. Au terme de ce projet, le temps CI est de 12 minutes. Ce SDET a probablement écrit 500 lignes de code de tests produit ce trimestre et 3 000 lignes de code de framework et d'infrastructure.
Ce n'est pas du travail QA. C'est du travail d'ingénierie logicielle qui rend le travail QA possible.
Les rôles SDET dans les entreprises qui appliquent rigoureusement le titre paient nettement plus que les postes QA Engineer. La différence est généralement de 20 à 35 % pour des niveaux de séniorité équivalents, selon l'entreprise et la région. Dans les grandes entreprises tech spécifiquement, les SDETs sont souvent sur la même grille de rémunération que les développeurs.
Ce que QA Automation Engineer signifie
C'est le profil intermédiaire, et le titre le plus courant que vous verrez en 2026.
Un QA Automation Engineer écrit des tests automatisés et maintient le framework dans lequel ces tests s'exécutent. Il est plus orienté code qu'un QA Engineer traditionnel, car l'automatisation n'est pas une tâche secondaire mais le travail principal. Mais il ne construit pas l'infrastructure de test depuis zéro comme le fait un vrai SDET. Il travaille dans un framework existant, l'étendant et écrivant la couverture de tests réelle.
En pratique : une équipe utilise Playwright avec TypeScript, a une structure Page Object Model en place, et exécute les tests dans GitHub Actions. Un QA Automation Engineer rejoint l'équipe et passe 70 à 80 % de son temps à écrire de nouveaux tests pour les fonctionnalités à mesure qu'elles sont livrées. Il met aussi à jour les tests existants quand l'interface change, investigue les tests flaky et améliore la stabilité. Il peut ajouter un utilitaire au framework, améliorer le reporting d'erreurs, ou configurer une nouvelle suite pour une nouvelle partie du produit. Repenser l'architecture du framework, c'est du territoire SDET.
Un scénario courant : un développeur livre un nouveau flux de paiement. Le QA Automation Engineer lit les critères d'acceptation, écrit six tests Playwright couvrant le chemin nominal et les cas limites clés, puis les exécute en local contre l'environnement de staging. Il détecte deux cas limites non gérés, signale des bugs, et fusionne les tests dans main une fois les bugs corrigés. Un travail de deux jours ordinaire. Pas de conception de framework, pas de travail d'infrastructure. Juste une couverture de tests automatisés solide et bien structurée pour une vraie fonctionnalité.
C'est le travail du QA Automation Engineer. Il requiert de vraies compétences de codage : écrire du code de test propre et lisible dans un vrai langage, comprendre les patterns async, travailler confortablement avec le contrôle de version. Déboguer les échecs sans aide constante des développeurs fait aussi partie du package. Il ne requiert pas de formation en développement logiciel.
La rémunération se situe entre QA Engineer et SDET. Les entreprises qui recrutent des QA Automation Engineers sont généralement prêtes à payer nettement plus que pour un QA traditionnel parce qu'elles ont besoin d'une production de code. Mais elles ne font pas passer un entretien d'ingénierie complet.
Comment déchiffrer ce qu'une offre cherche réellement
Ignorez le titre complètement. Allez directement à la section des exigences et cherchez trois signaux.
Signal 1 : quel langage et framework de codage mentionnent-ils ? S'ils disent "expérience avec Playwright, Selenium ou Cypress," ils veulent de l'automatisation de tests. S'ils spécifient "solides compétences en Python ou Java" puis listent des travaux de construction de framework ou d'"infrastructure de tests," vous regardez du territoire SDET. Si les exigences mentionnent Jira, TestRail ou "documentation des cas de test" mais que le codage est optionnel ou secondaire, c'est un rôle QA orienté manuel. Signal 2 : quel est le travail au quotidien ? "Vous écrirez des tests automatisés pour les nouvelles fonctionnalités" est du travail de QA Automation Engineer. "Vous concevrez et maintiendrez notre framework d'automatisation de tests" penche vers SDET. "Vous coordonnerez les tests entre les releases et gérerez le cycle de vie des défauts" est du QA Engineer traditionnel. Signal 3 : avec qui travaillerez-vous ? Travailler étroitement avec "les chefs de produit et les développeurs" signale une orientation qualité produit (QA Engineer). Travailler avec "l'équipe plateforme pour améliorer la fiabilité CI" ou "les ingénieurs infrastructure" signale un travail de type SDET.Exemple concret de contraste. L'offre A dit : "3+ ans d'expérience en automatisation, Playwright ou Selenium requis, solides compétences TypeScript, expérience en écriture de suites de tests E2E." C'est un rôle QA Automation Engineer, peu importe le titre.
L'offre B dit : "Solides compétences en codage requises, expérience en construction de frameworks de tests, connaissance des systèmes distribués un plus, concevoir l'infrastructure de tests pour des centaines d'ingénieurs." C'est un rôle SDET même si le titre dit "QA Engineer."
Lisez aussi la section "nice to have". Si Docker, Kubernetes, l'administration de plateformes CI ou les outils d'observabilité de tests figurent en bonus, l'entreprise pense en termes SDET même si le titre ne le dit pas.
Quelle voie cibler selon votre profil
Si vous venez d'un milieu entièrement non technique (support, gestion de projet, analyse métier), commencez par la voie QA Engineer. Construisez les fondamentaux du test, soyez à l'aise avec Jira et le suivi des défauts, et ajoutez progressivement des compétences d'automatisation. Le rôle QA Engineer est le point d'entrée le plus accessible parce que les entreprises s'intéressent davantage à la réflexion produit et à la communication qu'à la production de code.
Si vous avez un bagage technique (bootcamp de développement web, expérience en scripting, travail en IT), allez directement vers le QA Automation Engineer. Vous avez déjà le modèle mental pour écrire du code. Ce dont vous avez besoin c'est une couche de connaissances spécifiques aux tests : comment les suites de tests sont structurées, Playwright, l'intégration CI. C'est la voie la plus rapide vers un poste QA bien rémunéré pour la plupart des personnes en reconversion.
Si vous avez un background en développement logiciel, un diplôme en informatique, ou plusieurs années d'expérience en développement, le SDET est la bonne cible. La différence de rémunération est substantielle et le travail est genuinement intéressant sur le plan technique. Le processus d'entretien est plus difficile mais vos compétences existantes se transfèrent directement.
Le titre QA Automation Engineer est là où se passe la plus grande partie de la croissance de carrière pour les personnes qui entrent comme QA Engineers. Ajouter des compétences d'automatisation sur une base QA Engineer est une voie fiable vers une meilleure rémunération et un travail plus intéressant.
Ce que ça signifie pour votre recherche d'emploi
Arrêtez de filtrer par titre. Filtrez par exigences. Quand vous constituez votre liste de candidatures, faites deux vérifications rapides sur chaque offre. Le travail réel décrit correspond-il à mon niveau de compétence actuel ? L'attente en codage correspond-elle à ce que je peux démontrer en entretien ?
Si vous ciblez des rôles QA Automation Engineer, votre portfolio doit montrer du code de test. Pas des descriptions de travaux d'automatisation. De vrais fichiers de tests sur GitHub, organisés proprement, avec un README qui explique ce que les tests font et comment les exécuter. Un responsable du recrutement veut voir du code de test qu'un développeur respecterait : lisible, maintenable, bien organisé.
Si vous ciblez des rôles SDET, vous avez besoin de ça plus des preuves de jugement d'ingénierie. Des décisions de conception de framework que vous avez prises et pourquoi. Du travail d'infrastructure. Idéalement, quelque chose que vous avez construit et que d'autres personnes ont utilisé. L'entretien SDET sonde plus profondément que "pouvez-vous écrire un test Playwright" ; soyez prêt à discuter des compromis de conception.
Si vous ciblez des rôles QA Engineer, votre portfolio doit montrer la réflexion qualité : des rapports de bugs bien rédigés, des plans de test pour des fonctionnalités non triviales. Incluez aussi des exemples de cas limites que vous avez détectés et qui comptaient. L'automatisation est un bonus, pas le pitch central.
Le marché paie nettement plus pour les rôles plus haut sur le spectre d'ingénierie. Ce n'est pas un argument pour dire que le travail QA traditionnel a moins de valeur ; un bon jugement qualité produit est genuinement difficile à trouver. C'est une observation factuelle sur ce que le marché valorise actuellement. Savoir dans quelle direction vous construisez vous aide à investir votre temps d'apprentissage au bon endroit.
Les trois titres décrivent trois emplois différents. La confusion vient du fait que personne n'a convenu quel titre va avec quel emploi. Maintenant que vous savez quoi chercher dans les exigences, la confusion cesse d'être un problème.
→ See also: Parcours Professionnel QA: De Junior à Ingénieur QA Senior | Fiche de Poste QA Automation Engineer: Ce que les Entreprises Recherchent Vraiment | Comment Construire un Portfolio QA qui Vous Fait Recruter (GitHub + Playwright) | QA Manuel vs QA Automatisation: Qui Gagne Plus en 2026?
