Quality architect: le métier QA de demain selon Karim Jouini

Un épisode pour les testeurs et automaticiens qui se demandent où va leur métier, et pour les QA leads qui repensent leur équipe. Pour aller à l’essentiel: l’anecdote du Kinect à 09:25, le moment où Rosie et Karim adoptent le titre de quality architect à 22:49, et les compétences du rôle à 28:59. L’épisode est en anglais.

Pour Karim Jouini, l’IA ne supprime pas le métier QA: elle en retire les tâches répétitives. Écrire des scripts Selenium ou Playwright, exécuter des campagnes manuelles, enquêter sur l’origine d’un bug: ces tâches, qui représentent selon lui jusqu’à 90 % du travail actuel d’un testeur, vont largement passer aux agents. Le test devient pourtant plus important, parce que le rythme de livraison s’accélère.

Le rôle qui en sort, Rosie Sherry et lui l’appellent le quality architect: celui qui définit « à quoi ressemble le bon », met en place l’architecture, l’outillage et les garde-fous, et fait monter toute l’équipe en compétence, pendant que la responsabilité de la qualité se répartit entre produit, développement et métier. Ce rôle demande quatre compétences:

• le management, parce que chacun devient manager d’agents ;
• la pensée systémique ;
• la compréhension de la boucle complète, du besoin marché à la livraison ;
• des métriques de qualité orientées produit.

Le Kinect: quand un produit est plus dur à tester qu’à construire

L’amour de Karim pour le test est né chez Microsoft, sur un projet précis: le Kinect, la caméra de la Xbox qui permettait de jouer sans manette, vers 2010. Il n’était pas développeur sur le projet mais bêta-testeur, parmi un millier d’employés choisis pour leur diversité (taille, couleur de peau, configuration familiale, installation).

Chaque jour, les testeurs recevaient des tâches: jouer au football, au golf devant la caméra, puis noter l’expérience. Les vidéos étaient enregistrées, et chaque nuit, les millions de vidéos collectées étaient rejouées sur la nouvelle version de l’algorithme pour vérifier qu’elle faisait mieux. Même définir « mieux » était un problème: si Karim joue mal au golf, il aura l’impression que la caméra ne reconnaît pas son geste, alors que c’est sa faute. Comment calibrer la qualité perçue sans récompenser les mauvais joueurs ?

Une culture de recrutement à l’envers

L’autre souvenir de Karim est moins positif: une culture où, au recrutement, les excellents ingénieurs étaient orientés vers le développement et les ingénieurs moyens vers le test. Il s’y est opposé jusqu’aux équipes RH, pour revoir la façon de recruter et d’évaluer les testeurs. Sa conviction: d’excellents testeurs transforment la vélocité de toute une organisation, parce que les développeurs vont plus vite quand chaque changement est bien évalué et qu’ils peuvent faire confiance au système.

Pourquoi la qualité a freiné Expensya, et a donné naissance à Thunders

Chez Expensya, solution de gestion des notes de frais à base d’IA (60 pays, 2 millions d’utilisateurs), Karim n’avait pas l’argent de Microsoft pour « jeter des centaines de personnes sur le problème ». Dans une fintech présente dans 60 pays, la réglementation change deux à trois fois par semaine, et les clients (compagnies d’énergie, de transport, de défense, la moitié des banques européennes) n’acceptent aucune régression. L’équipe a tout essayé: une grande équipe QA, beaucoup d’automatisation, environ un million de lignes de Playwright. Les problèmes restaient: un coût qui ralentissait l’innovation, et un écart croissant entre les besoins du métier et ce que les équipes construisaient et testaient.

Après la vente d’Expensya, Karim et son cofondateur Jihed Othmani ont interrogé une centaine de CTO, CPO et QA leads. 92 % citaient l’assurance qualité, sous une forme ou une autre, comme leur principal frein. Leur thèse: l’IA générative permet de retrouver la qualité du test manuel, avec des agents à la place des humains, et donc à l’échelle.

L’IA mange des tâches, pas des métiers: la leçon des ops

Rosie observe que les titres de poste bougent partout: son responsable communauté fait aussi du produit, et elle-même se dit « community architect ». Karim répond par une transformation que tout le monde a oubliée: celle des ops.

Dans son entité chez Microsoft, d’abord rattachée à la Xbox puis à Azure, environ 250 personnes travaillaient, dont une vingtaine d’ops chargés de déployer en production, de provisionner les machines et de sécuriser l’infrastructure. Huit ans plus tard, il n’en restait qu’un. Personne n’a été « supprimé »: 80 à 90 % des tâches classiques sont passées chez les hyperscalers, le reste chez les développeurs devenus DevOps. La technologie a mangé des tâches, pas des métiers. L’ops restant n’était pas là par chance: c’était celui qui comprenait en profondeur le fonctionnement du système, et qui savait réparer quand tout cassait vraiment.

Pour Karim, le test vit la même transformation, mais en 5 à 10 ans au lieu de 15 à 20. Si votre métier consiste à 100 % à écrire des scripts d’automatisation, vous êtes en difficulté. S’il consiste à penser et architecturer la qualité, l’IA est une chance: vous perdiez 80 % de votre temps à écrire des scripts, vous pouvez désormais le déléguer. À plus long terme, il voit émerger un rôle dominant de technical product manager, et observe déjà des équipes qui fusionnent QA et business analysts, là où le QA est la personne qui connaît le mieux le produit.

Qu’est-ce qu’un quality architect ?

Un quality architect est l’expert qui définit ce que « bonne qualité » veut dire pour un produit, puis met en place l’architecture de test, l’outillage, les garde-fous et les métriques qui permettent à toute l’équipe (produit, développement, métier et agents IA) d’atteindre ce niveau. Il ne porte plus seul l’exécution des tests: il conçoit le système qui la rend possible.

C’est la conclusion de l’échange. Comme avec le DevOps, la qualité devient le travail de tous: produit, développeur ou business analyst, « la qualité fait partie de votre travail, ce n’est pas ce que vous faites quand vous avez le temps ». Mais tous s’appuient sur des architectes qui posent les bons outils et les bonnes règles, font les bons investissements et définissent à quoi ressemble le bon. Dans les grandes équipes, c’est un rôle à part entière ; dans les petites, une compétence portée par d’autres rôles, un product manager par exemple. Rosie rapproche le rôle du quality coaching, qui en serait une partie.

Karim détaille quatre compétences.

1. Le management, y compris des agents

La première compétence est « douce », et Karim la juge la plus sous-estimée: apprendre le management. Chaque contributeur individuel devient manager, d’humains ou d’agents. Et manager des agents ressemble beaucoup à manager une équipe: penser le plan avant de construire, le découper, le distribuer, coordonner, vérifier qu’on construit la bonne chose de la bonne façon, mesurer les bons indicateurs. C’est, dit-il, une façon de pratiquer le shift left.

2. La pensée systémique

Rosie évoque le risque du « glaze », ce moment où l’on survole des sorties d’IA trop nombreuses sans vraiment les lire. Karim y voit un besoin de pensée systémique. Ce n’est pas un don: « c’est une compétence dure, et ça s’apprend ». Il l’a vu chez des développeurs brillants qui construisaient une excellente solution sans voir qu’elle exploserait en production. À l’échelle de Microsoft, « chaque virgule que vous placez est multipliée par des centaines de millions ». Le penseur systémique sait qu’il est une pièce d’une grande machine, et l’intègre dans son raisonnement.

3. Comprendre la boucle

Un quality architect doit penser en vélocité. Son travail n’est pas seulement de tester ce qui part en production, mais de le faire d’une façon efficace pour tous. Il doit donc comprendre toute la boucle, du besoin du marché à la livraison au marché, et connaître l’état de l’art de l’outillage.

4. Des métriques de qualité orientées produit

Karim recommande à chaque équipe qualité le framework des « 11 étoiles » d’Airbnb: à quoi ressemble une expérience 5 étoiles, 6 étoiles, 10 étoiles, celle dont les utilisateurs se souviendront et parleront ? Beaucoup d’équipes QA ne s’en servent pas parce qu’elles sont absorbées par l’exécution des campagnes. D’où sa conviction que produit et qualité vont fusionner: « la qualité ne sera jamais extraordinaire si vous testez seulement ce qu’on vous livre ». Il faut influencer la conception dès le début.

Ce qui va disparaître du métier de testeur QA

Rosie pose la question sans détour. Les réponses de Karim:

• Écrire des scripts Selenium et Playwright à la main, « au moins comme on le fait aujourd’hui ». Superviser des agents qui les écrivent, pourquoi pas.
• Le test manuel tel qu’on le pratique, même si beaucoup ne sont pas d’accord. Le testeur manuel de demain est l’équivalent d’un QA lead qui dirige des QA agents: il décide quoi tester, quelle couverture viser, quelles dimensions couvrir (accessibilité, réglementation…), puis confie l’exécution aux agents.
• Le travail de détective du débogage: chercher d’où vient un bug est un domaine où l’IA excelle, parce qu’elle a accès à énormément de données. Chez Thunders, où nous testons notre propre produit avec Thunders, l’IA débogue « à une vitesse incroyable ».

Au total, peut-être 90 % des tâches actuelles d’un testeur, estime-t-il. Mais le test devient plus important, parce que le code est généré de plus en plus vite. Karim cite une statistique récente selon laquelle le nombre de défauts en production par demande de changement aurait triplé: les équipes survolent des changements produits trop vite. Pour un débat plus large, lisez notre analyse de l’impact de l’IA sur les métiers du test.

Adopter l’IA sans tout jeter: migration, attentisme et conduite du changement

Faut-il supprimer son million de lignes de Playwright et repartir de zéro ? Non, répond Karim: il n’y a pas de projet IA réussi qui ne réutilise pas le meilleur de l’existant. Chez Thunders, nos clients migrent leurs tests en quelques jours, parce que convertir du code en langage naturel est facile: « aller du rigide vers l’intelligent, c’est simple. L’inverse est parfois impossible. »

Le piège de l’attentisme

Le vrai danger, selon lui, c’est ce qu’il appelle l’« attentisme » (waitism, en traduction libre pour Rosie): les modèles changent chaque semaine, alors on attend de voir qui va gagner. Or c’est une course, et un concurrent qui adopte l’IA peut vous sortir du marché. Et quand un prospect préfère attendre la « bonne » solution de test IA, Karim répond que 90 % de ce qu’on apprend reste valable, comme les compétences Selenium se transfèrent à Playwright. L’important est le changement d’état d’esprit: passer de faire les tests à déléguer les tests.

La conduite du changement

Pas de big bang. Chez nos clients, majoritairement de grands comptes, nous déployons une équipe, recueillons les retours, puis trois équipes trois mois plus tard, en ajustant au passage. Karim compare le changement au passage du vélo à la voiture: on gagne beaucoup, mais on perd des choses, comme se garer n’importe où, et aucune amélioration de la voiture ne les rendra. Il faut accompagner les équipes dans ce deuil, avec des spécialistes de la conduite du changement et des intégrateurs partenaires qui agissent comme des forward deployed engineers. Chez PwC, par exemple, les déploiements SAP reposent surtout sur des tests d’acceptation SAP qui mobilisaient 200 à 300 testeurs ; Thunders raccourcit ces projets en jouant le rôle d’une « armée de testeurs ».

Surtout: n’achetez pas l’IA pour licencier votre équipe. « Les équipes ne sont pas douées pour mettre en œuvre ce qui va les faire licencier. » Karim conseille de fixer des objectifs partagés sur la vitesse de livraison (que se passe-t-il pour votre activité si vous livrez chaque semaine au lieu de chaque mois ?) et sur les bugs en production, plutôt que sur les coûts. Rosie partage sa pratique du « 20 % de temps IA », une à deux heures par jour pour explorer ; chez Thunders, les équipes marketing et ventes ont leur « mercredi IA », avec une feuille de route des tâches à automatiser classées par impact et par risque.

• L’IA mange des tâches, pas des métiers: comme pour les ops, la plupart des tâches du testeur vont être absorbées, et le rôle va se déplacer vers la conception.
• Le quality architect définit « le bon » et construit le système (outils, garde-fous, métriques) qui permet à toute l’équipe de l’atteindre.
• Apprenez le management: manager des agents demande les mêmes réflexes que manager des humains, planifier, découper, coordonner, mesurer.
• La pensée systémique s’apprend et devient indispensable face au volume de ce que produisent les IA.
• Mesurez la qualité côté produit, avec des cadres comme les 11 étoiles d’Airbnb, et intervenez dès la conception.
• N’attendez pas la solution parfaite: commencez petit, sur une équipe, avec des objectifs de vitesse et de qualité plutôt que de réduction des coûts.

Into the MoTaverse est le podcast de Ministry of Testing, l’une des plus grandes communautés de professionnels du test logiciel, aussi appelée MoTaverse. Sa fondatrice, Rosie Sherry, y reçoit des testeurs, des leaders de la qualité et des acteurs de l’écosystème pour parler de la façon dont la qualité se construit, et de plus en plus de l’effet de l’IA sur le métier. Nous sommes partenaires de MoTaverse. Voir l’épisode sur ministryoftesting.com.