Recruter un testeur QA : profil, fiche de poste et entretien

Le recrutement d'un QA échoue rarement sur le candidat. Il échoue en amont, quand personne n'a défini ce qu'on attend du poste : automatiser, faire de la recette, écrire des spécifications, gérer le support ? Ce guide donne le profil à cibler selon votre stade, la fiche de poste qui attire les bons, les questions qui séparent un candidat qui a écrit des tests d'un candidat qui les a subis, et le comparatif honnête avec l'alternative qu'on ne regarde jamais.

1. Ce que fait un QA, et ce qu'il ne fait pas

« QA », « testeur », « ingénieur qualité », « SDET » : les intitulés circulent sans définition partagée, et c'est la première cause de recrutement raté. Avant de publier une annonce, il faut savoir lequel de ces quatre métiers on cherche, parce qu'ils ne se remplacent pas.

• Testeur fonctionnel (ou QA manuel) : déroule des campagnes de recette, rédige des cas de test, qualifie et reproduit les anomalies. Fort sur la compréhension du métier, ne produit pas de code de test.
• QA automation : écrit et maintient des tests automatisés sur les parcours utilisateurs, les branche à la chaîne d'intégration. C'est le profil le plus demandé, et le plus rare.
• SDET (Software Development Engineer in Test) : développeur spécialisé qui construit l'outillage de test, les environnements et les jeux de données. Recruté quand la difficulté est l'infrastructure, pas les scénarios.
• QA lead : définit la stratégie, arbitre ce qu'on teste et ce qu'on ne teste pas, encadre. Utile à partir d'une équipe de plusieurs testeurs, inutile avant.

Et ce qu'un QA ne fait pas, quel que soit le profil : il n'est pas responsable de la qualité à la place de l'équipe. Un QA ne rend pas un produit fiable en le testant après coup, il rend visibles les défauts que l'organisation choisit ensuite de corriger ou d'ignorer. Recruter un QA en espérant transférer la responsabilité de la qualité hors de l'équipe de développement ne marche jamais.

2. À quel stade recruter

Le déclencheur habituel est mauvais : on recrute un QA parce qu'un incident vient de coûter cher, dans l'urgence et la culpabilité. Le résultat est un poste mal cadré, pourvu vite, et une personne seule chargée de réparer un problème d'organisation.

Les signaux qui justifient réellement un recrutement :

1. La vérification avant livraison consomme plus d'une journée de développeur par semaine. À ce stade, vous payez déjà un QA, mais au tarif d'un développeur et sans la méthode qui va avec.
2. Les mises en production sont retardées par la peur. Quand l'équipe repousse une livraison faute de savoir ce qui pourrait casser, le frein est devenu structurel.
3. Le même type de bug revient. Une régression qui réapparaît deux fois est un problème de couverture, pas de vigilance.
4. La surface produit dépasse la mémoire d'une personne. Personne ne sait plus lister les parcours critiques de tête, donc personne ne sait ce qui n'est pas couvert.

À l'inverse, deux situations où recruter est prématuré : une équipe de moins de cinq développeurs sur un produit encore instable dans ses fonctionnalités, et une organisation sans aucun test automatisé où le premier QA passerait ses journées en vérification manuelle. Dans les deux cas, ce qui manque est la couverture des parcours critiques, pas un poste. Le calcul complet des coûts est détaillé dans combien coûte vraiment un QA en 2026.

3. Les profils et le marché français en 2026

Les fourchettes ci-dessous sont des salaires bruts annuels, hors Paris puis à Paris, pour un poste en CDI.

Deux réalités de marché à intégrer avant de lancer le sourcing. D'abord, les profils confirmés en automatisation sont rares : le sourcing dure, et les contre-offres sont fréquentes. Ensuite, les QA seniors sont difficiles à attirer dans les structures de moins de cinquante personnes, parce que le poste y est souvent isolé, sans perspective d'encadrement ni pair pour échanger. Un candidat senior le demandera en entretien, et il faut avoir une réponse.

Au brut s'ajoute le coût employeur, environ 1,4 à 1,5 fois le salaire selon le statut et la convention. Un QA confirmé à 50 k€ brut représente donc de l'ordre de 78 800 € par an tout compris, outils et matériel inclus. À cela s'ajoute le coût du recrutement lui-même : 8 000 à 15 000 € via un cabinet, 2 000 à 5 000 € en sourcing interne si on compte le temps passé.

4. La fiche de poste qui attire les bons

Une annonce de QA se juge à ce qu'elle rend vérifiable. Les bons candidats cherchent trois informations, et la plupart des annonces n'en donnent aucune : sur quoi ils vont travailler, avec quel niveau d'autonomie, et si l'entreprise a déjà une culture de test ou tout à construire.

Les éléments à faire figurer :

• Le périmètre en une phrase. « Construire et maintenir la couverture automatisée des parcours de paiement et d'inscription » vaut mieux que « garantir la qualité du produit ».
• L'état des lieux, sans le maquiller. Nombre de tests existants, ce qui tourne aujourd'hui en intégration continue, ce qui est encore manuel. Un candidat confirmé préfère un chantier assumé à une situation embellie qu'il découvrira la première semaine.
• Le rattachement et le pouvoir de décision. Qui arbitre quand le QA dit « ne livrez pas » ? Cette question est celle qui fait accepter ou refuser une offre.
• La part d'automatisation attendue, en pourcentage grossier du temps. C'est ce qui distingue votre annonce de celles qui promettent de l'automatisation et livrent de la recette manuelle.
• La fourchette de salaire. Sur un marché où les profils sont rares, une annonce sans fourchette est filtrée avant d'être lue.

Et ce qui fait fuir les bons candidats : mélanger dans le même poste la QA, le support client et la rédaction de spécifications. C'est le signe d'une organisation qui n'a pas dimensionné le besoin et qui compte sur une personne pour absorber trois manques. Ceux qui savent tester le repèrent immédiatement.

5. Les questions d'entretien qui discriminent

Un entretien de QA ne doit pas vérifier des connaissances théoriques sur les niveaux de test. Il doit établir une chose : la personne a-t-elle déjà tenu une suite de tests en vie dans la durée ? C'est la seule expérience qui ne s'improvise pas.

Sur l'expérience réelle

• « Racontez-moi un test que vous avez supprimé. Pourquoi ? » Un candidat qui n'a jamais supprimé de test n'a jamais maintenu de suite. La bonne réponse parle de coût de maintenance disproportionné, de test instable ou de couverture redondante.
• « Un test échoue une fois sur cinq. Que faites-vous cette semaine ? » On cherche : investiguer la cause, et en attendant retirer ou isoler le test plutôt que le relancer. Le mauvais signal est « je relance, ça repasse au deuxième essai ».
• « Un bug est passé en production. Comment vous y prenez-vous ? » La réponse attendue va vers la reproduction, l'ajout d'un test qui échoue, puis le correctif. Un candidat qui commence par chercher qui a introduit le bug est un mauvais signal culturel.
• « Qu'est-ce que vous avez choisi de ne pas tester dans votre dernier poste ? » Savoir renoncer est la compétence la plus rare. Un candidat qui prétend avoir tout testé n'a jamais eu à arbitrer.

Sur la technique

• « Comment ciblez-vous un élément dans une interface qui change souvent ? » On attend des identifiants stables posés dans le code plutôt que des sélecteurs liés à la mise en page, sujet que nous détaillons dans le guide des attributs data-testid.
• « Comment gérez-vous les données de test ? » Question qui sépare nettement les niveaux : un candidat confirmé parle d'isolation, de jeu de données recréé à chaque exécution et de nettoyage, pas d'un compte de test partagé.
• « Que mettez-vous dans la chaîne d'intégration, et que gardez-vous en surveillance de production ? » La distinction n'est pas évidente pour tout le monde, nous l'avons posée dans CI ou monitoring synthétique.

Sur la posture

Une dernière question, à ne pas négliger : « Comment annoncez-vous à une équipe qu'il ne faut pas livrer ? » Un QA passe une partie de son temps à porter une mauvaise nouvelle dans un moment de pression. Le candidat qui sait le faire sans se mettre l'équipe à dos vaut plus que celui qui connaît un framework de plus.

6. Le test technique : ce qu'il doit contenir

Le test technique le plus répandu consiste à demander l'automatisation d'un parcours sur un site de démonstration. Il mesure mal, parce qu'il récompense la vitesse d'écriture, alors que le métier est fait de maintenance.

Un meilleur exercice, en une heure : donnez un test existant, volontairement mauvais, et demandez de le critiquer puis de le réparer. Mettez-y délibérément un sélecteur fragile lié à la mise en page, une attente fixe de quelques secondes, une dépendance à une donnée créée par un test précédent, et une assertion qui ne vérifie rien de réel.

Ce que vous observez alors :

• Combien des quatre défauts la personne repère, et dans quel ordre de gravité elle les classe.
• Si elle remplace l'attente fixe par une attente sur un état, ou si elle allonge simplement le délai.
• Si elle voit la dépendance entre tests, qui est la cause la plus fréquente d'instabilité en conditions réelles.
• Comment elle explique ses choix. Un QA passe ses journées à justifier des décisions de test auprès de développeurs, cette capacité fait partie du poste.

Ce que ce test ne doit pas être : un exercice chronométré sur la syntaxe d'un framework précis. Un bon QA change d'outil en une semaine, il ne change pas de jugement en une semaine. Sur les choix d'architecture qui reviennent dans ces discussions, notre article sur le Page Object Model donne un support de conversation utile en entretien.

7. Les cinq erreurs classiques

1. Le QA unique dans une équipe de trente. Une personne seule face à trente développeurs devient un goulot d'étranglement et un point de défaillance unique. Ses congés suspendent la couverture, son départ la supprime.
2. Recruter un QA pour compenser l'absence de tests unitaires. Aucun test de bout en bout ne rattrape un code que personne ne teste au niveau de la fonction. Le QA passera son temps à détecter en fin de chaîne des défauts qui coûtaient dix fois moins cher à attraper en amont.
3. Confondre QA et support. Dès que la personne traite les tickets clients, elle ne construit plus de couverture. L'urgence gagne toujours contre la prévention, et au bout de six mois le poste a changé de nature.
4. Recruter un junior sans personne pour l'encadrer. Un junior progresse dans un cadre existant. Seul et sans stratégie de test à reprendre, il produira de la vérification manuelle, ce qui n'était pas l'objectif du recrutement.
5. Sous-estimer la maintenance. Une suite de tests est un actif vivant. Sans temps dédié à la mise à jour des scénarios quand le produit bouge, elle se désynchronise en quelques mois. C'est le poste de coût le plus systématiquement oublié dans la décision de recruter.

8. Recruter, ou faire surveiller ses parcours critiques

Il existe une alternative que la plupart des équipes ne mettent pas dans la balance, parce que la question est posée d'emblée comme « qui recrute-t-on ? » plutôt que « quel besoin couvre-t-on ? ». Voici la comparaison, à périmètre de surveillance des parcours critiques.

Le tableau ne suffit pas, parce que les deux colonnes ne font pas le même travail. Le point important est celui-ci :

D'où la conclusion, qui n'est pas « ne recrutez pas » :

• Moins de 20 personnes. Ce qui manque est presque toujours la surveillance des parcours critiques, pas un poste. Un service managé la couvre pour une fraction du coût, sans délai de recrutement, et laisse le budget aux développeurs.
• De 20 à 50 personnes. Le premier QA confirmé devient rentable, à condition de lui confier la recette, l'exploratoire et l'accompagnement des développeurs, et de sortir la surveillance continue de son périmètre. C'est la combinaison la plus efficace que nous voyons.
• Plus de 50 personnes. Recrutez un QA lead pour porter la stratégie et structurer l'équipe. La surveillance de production reste un sujet d'outillage, pas un sujet de poste.

Si vous hésitez entre les modèles disponibles (garder la main, plateforme en self-service, service managé), le détail est dans le guide de l'externalisation des tests automatisés, et l'analyse financière complète dans combien coûte vraiment un QA.

9. FAQ

À partir de combien de développeurs faut-il recruter un QA ?

Il n'y a pas de seuil universel, mais un signal fiable : le moment où la vérification avant livraison occupe plus d'une journée de développeur par semaine, ou retarde les mises en production. En pratique cela arrive souvent entre 8 et 12 développeurs, plus tôt si le produit touche au paiement ou à des données sensibles.

Faut-il recruter un QA junior ou un QA confirmé ?

Un junior a besoin d'un cadre déjà posé pour progresser. Sans stratégie de test existante ni personne pour l'encadrer, un premier recrutement junior aboutit généralement à de la vérification manuelle, sans automatisation durable. Le premier QA d'une équipe gagne à être confirmé.

Combien de temps prend le recrutement d'un QA en France ?

Comptez 3 à 5 mois pour un profil confirmé, et 5 à 8 mois entre la décision de recruter et l'autonomie réelle sur votre produit. Les profils confirmés en automatisation sont rares, ce qui allonge le sourcing et pousse les salaires.

Un service managé peut-il remplacer un QA interne ?

Non, les deux ne couvrent pas le même besoin. Le service managé remplace la surveillance continue des parcours critiques. La recette, l'exploratoire, la relecture des spécifications et l'accompagnement des développeurs restent le métier d'un QA interne.

Freelance ou CDI pour un premier QA ?

Un freelance confirmé permet de démarrer en quelques semaines et de poser un cadre de test réutilisable. Il coûte plus cher au jour et repart avec la connaissance accumulée s'il n'a rien documenté. C'est un bon choix pour construire, un mauvais choix pour maintenir dans la durée.