QA en 2026 : un poste en sursis ou plus indispensable que jamais ?

En 2026, dans l'écosystème startup, le QA est souvent le premier poste qu'on supprime quand les temps sont durs. "Les devs peuvent tester eux-mêmes." "L'IA va automatiser tout ça." "On n'a pas le budget."

J'entends ces phrases régulièrement. Et pourtant, dans mon équipe chez DJUST, la QA est devenue le pilier silencieux sans lequel plus personne ne veut travailler. Voici l'histoire.

Le contexte : une startup B2B sous pression

DJUST est une plateforme e-commerce B2B SaaS. En tant qu'Engineering Manager, je gère l'équipe OMS (Order Management System) — commandes, paiements, panier, intégrations fournisseurs. C'est le cœur transactionnel, là où chaque bug a un impact business direct.

Comme beaucoup de startups, DJUST a connu des phases de croissance et de contraction. Les signatures clients sont complexes, le marché B2B est exigeant, et chaque décision de recrutement ou de réduction d'effectif se ressent immédiatement.

Acte 1 : De 0 à 3 QA — la montée en puissance

Au début, il n'y avait qu'une seule QA manuelle. Les tests étaient artisanaux, les régressions fréquentes, et chaque release était un moment de stress. On testait "à la main", on croisait les doigts, on déployait le jeudi en espérant que le vendredi se passe bien.

Puis l'équipe QA a grandi à 3 personnes. C'est à ce moment qu'elle est arrivée — une développeuse C# avec 10 ans d'expérience qui avait décidé de changer de voie pour devenir QA. Un profil atypique qui allait tout changer.

Acte 2 : Le profil atypique qui change la donne

Quand une développeuse senior avec une décennie de code derrière elle arrive en QA, ça se voit immédiatement. Elle ne se contente pas de cliquer sur des boutons et de remplir des fiches de bug. Elle comprend le code, elle anticipe les cas limites, elle pense en systèmes.

Dès son arrivée, elle a poussé pour structurer la QA :

  • Tests E2E automatisés adaptés à nos développeurs — pas des tests Selenium fragiles écrits dans un coin, mais des tests pensés avec et pour l'équipe dev
  • Spécifications en amont — elle s'est naturellement rapprochée de notre Product Manager pour valider les specs avant le lancement des développements
  • Critères d'acceptance rigoureux — chaque ticket est passé au crible avant même qu'un dev n'ouvre son IDE
  • Processus de validation structuré — fini le "ça a l'air de marcher", place à des scénarios de test reproductibles

Son background de développeuse C# lui donnait un avantage énorme : elle parlait le même langage que les devs, comprenait les contraintes techniques, et savait exactement où les bugs allaient se cacher.

Acte 3 : La réduction — et le choix que j'ai dû faire

Le contexte startup a rattrappé l'équipe. Signatures difficiles, complexité du marché B2B, nécessité de réduire les coûts.

La première QA est partie d'elle-même — elle avait envie de changer de voie et est devenue Product Manager. Une belle évolution.

Le deuxième QA a été licencié dans le cadre d'une réduction d'effectif. Les temps étaient durs, il fallait faire des choix.

Et puis il y a eu la question : est-ce qu'on garde la troisième ?

Je l'ai défendue. Pas par sentimentalisme — par conviction. J'ai expliqué à la direction son apport global à la boîte : la stabilité de nos releases, la réduction des bugs en production, le temps gagné par les développeurs qui ne passaient plus leurs journées à debugger des régressions, et surtout son rôle critique auprès du Product Manager.

Elle est restée. La dernière QA de la boîte.

Acte 4 : Le pilier silencieux

Aujourd'hui, son rôle est angulaire. C'est le mot exact.

Notre Product Manager ne peut plus travailler sans elle. Avant chaque sprint, elle est là en amont : elle challenge les specs, identifie les incohérences, pose les questions que personne n'a pensé à poser. Quand le PM présente une feature aux devs, les specifications ont déjà été passées au crible. Résultat : moins d'allers-retours, moins d'ambiguïté, des développements plus fluides.

Nos Project Managers, ceux qui sont face aux clients — Franprix, Eiffage, VEJA — ont vu l'evolution. Ils ont vécu l'avant et l'apres. La stabilité de la plateforme s'est améliorée de manière visible. Ils ne veulent pas perdre ça. Quand on parle de QA, leur réponse est unanime : "On ne peut pas revenir en arrière."

Les développeurs eux-mêmes, qui au début voyaient la QA comme un frein ("encore un bug a corriger avant la release..."), ont compris que c'était un filet de sécurité qui les rendait plus rapides, pas plus lents.

Acte 5 : L'inquiétude face a 2026

Mais elle s'inquiète. Et je la comprends.

Première inquiétude : l'IA. Quand on voit Claude Code écrire des tests unitaires en quelques secondes, quand les outils d'IA génèrent des scénarios de test automatiquement, la question se pose naturellement : "Est-ce que l'IA va me remplacer ?"

Deuxième inquiétude : la solitude. Elle est la dernière QA de la boîte. Pas de pair avec qui échanger, pas de communauté QA interne, pas de mentor. C'est un poste isolé dans une entreprise qui a tendance à voir la QA comme un coût plutôt qu'un investissement.

Troisième inquiétude : l'incompréhension. Dans une startup tech, le prestige va aux développeurs, aux architectes, aux devops. Le QA est souvent le "mal nécessaire" qu'on tolère. Certains collègues ne comprennent pas pourquoi ce poste existe encore en 2026.

Ma réponse : l'IA ne remplace pas la rigueur humaine

Voici ce que je lui ai dit, et ce que je crois profondément :

L'IA est un multiplicateur, pas un remplaçant. Claude Code peut générer des tests, oui. Mais il ne peut pas :

  • Comprendre le contexte métier d'un client qui commande 10 000 palettes de café via une API B2B

  • Anticiper qu'un flux de paiement Adyen va se comporter différemment en production qu'en sandbox

  • Sentir qu'une spec est incomplète parce qu'elle connaît l'historique des 50 dernières features

  • Challenger un Product Manager sur la cohérence d'un parcours utilisateur

Avec l'IA et elle, on peut aller plus loin. Maintenant qu'elle vient de passer senior, c'est le moment d'élever les exigences. L'IA automatise les tâches répétitives — les tests de régression, la génération de cas de test, la détection de patterns. Ça la libère pour ce que seule elle sait faire : la réflexion stratégique sur la qualité.

Notre vision pour 2026 :

  • L'IA génère les tests, elle les revoit et les enrichit

  • L'IA détecte les régressions, elle analyse les causes profondes

  • L'IA couvre la quantité, elle assure la pertinence

  • Les exigences qualité montent, parce qu'on a les moyens de les imposer

Ce que j'ai appris en tant qu'Engineering Manager

Défendre un poste QA dans une startup qui réduit ses effectifs, c'est un acte de management. Pas un acte technique.

Ça demande de :

  1. Quantifier l'apport — pas en "nombre de bugs trouvés" (métrique absurde), mais en stabilité des releases, temps gagné par les devs, confiance des project managers face aux clients

  2. Expliquer le coût de l'absence — combien coûte un bug en production chez un client B2B qui passe 2M de commandes par an ?

  3. Projeter l'avenir — montrer que le QA + IA est plus puissant que le QA seul ou l'IA seule

  4. Encourager malgré l'adversité — parce qu'être le dernier à un poste dans une boîte, c'est dur. C'est solitaire. Et ça demande une vraie force de caractère.

Elle a cette force. Et elle le prouve chaque jour.

Conclusion : QA en 2026, plus que jamais

Non, le QA ne disparaît pas en 2026. Il se transforme.

Le QA manuel pur, celui qui clique et remplit des fiches — oui, celui-là est en danger. Mais le QA qui comprend le code, qui structure les processus, qui travaille en amont avec le product, qui impose une rigueur que les développeurs seuls ne peuvent pas maintenir — celui-là est irremplaçable.

Et quand en plus ce QA a 10 ans de développement C# derrière lui, qu'il parle le langage des devs, qu'il sait écrire des tests E2E qui tiennent la route, et qu'il a la résilience de tenir bon quand tout le monde autour dit que son métier va disparaître...

Ce n'est pas un poste à supprimer. C'est un poste à protéger.

Chetana YIN — Février 2026