Product Manager QA Automation - Lyon ou Paris - Anglais Fluent - H/F

Sweet IT

Le besoin

Product Manager

1. Contexte Le domaine Apps Foundation Apps Foundation est un domaine plateforme : il ne livre pas de fonctionnalités directement aux utilisateurs finaux. Ses clients sont les autres domaines de l'entreprise (« value domains » : Streaming & Ads, Content Discovery, User Lifecycle...).

Sa mission : fournir les fondations multi-device, le design system et les « golden paths » - de plus en plus outillés par l'IA - qui permettent aux équipes de livrer plus vite, avec plus de qualité et de cohérence, sur iOS, Android, Web et CTV.

Le succès du domaine ne se mesure pas au nombre de fonctionnalités livrées, mais à l'adoption et à la capacité des équipes clientes à livrer plus vite (outcomes, pas outputs). La squad QA Automation Foundation porte sur ce périmètre une plateforme d'automatisation de tests partagée, mutualisée entre les squads et les applications clientes.

2. Le rôle : PM en domaine plateforme Ce poste n'est pas un rôle de PM « classique ». Trois spécificités structurantes :

- Deux niveaux de clients à tenir. Les domaines clients (qui « achètent » la plateforme et sont responsables d'un outcome business) et les développeurs / QA qui consomment et contribuent aux capacités. Le PM possède l'expérience de ces deux populations.

- Modèle de contribution. Les domaines clients implémentent eux-mêmes leurs changements sur les capacités partagées. Le « produit » n'est donc pas un lot de features, mais des standards, des golden paths, des contrats partagés et l'ergonomie de contribution. Le vrai signal d'échec n'est pas le faible usage : c'est le « fork silencieux » - quand une équipe contourne la capacité plutôt que de bâtir dessus.

- Un « Duo », pas un « Trio ». Pas de Product Designer embarqué : le PM travaille en binôme avec un Squad Engineer. Le risque d'usabilité demeure - l'ergonomie d'un SDK, d'une API, d'un framework de test EST du travail d'usabilité, adressée au développeur. Le Duo la porte explicitement. Important : le PM n'a pas besoin d'être un implémenteur technique. Il doit néanmoins avoir la culture technique suffisante pour dialoguer d'égal à égal avec des ingénieurs sur des sujets de test automation, CI/CD et architecture de test.

3. Missions principales Trois axes structurent la mission, ici déclinés au périmètre QA Automation :

Axe 1 - Connecter le travail à la vision et aux objectifs - Ancrer la direction de la squad aux objectifs du domaine et à la stratégie produit, plutôt qu'aux demandes entrantes ou aux préférences techniques. - Distinguer le travail piloté par les objectifs (le changement à conduire) du BAU (fiabilité, sécurité, dette, compatibilité, suivis par des KPIs). Ne pas affamer le travail plateforme nécessaire sous prétexte qu'il n'est pas rattaché à un objectif.

Axe 2 - Discovery : comprendre les vrais problèmes des équipes - Identifier proactivement frictions et goulets des équipes clientes avant qu'ils ne deviennent des demandes formelles. Distinguer le besoin exprimé (« on veut ce framework ») du vrai problème (« on réimplémente la même infra de test chaque trimestre »). - Tenir une discovery continue (dual-track), en étant présent dans les rituels des domaines clients - pas une grande étude ponctuelle par trimestre.

Axe 3 - Mesurer l'impact, pas l'output - Définir le succès avant de construire, le suivre après livraison, boucler via des outcome reviews avec le Duo et les domaines impactés. - Mesurer l'adoption « à la manière plateforme » : non pas « utilisent-ils le framework » mais « construisent-ils sur le golden path plutôt que de forker ». Suivre la part de contributions conformes vs divergences, le time-to-first-successful-integration (« time to Hello World ») et le nombre de contournements supprimés. - Dé-risquer avant de passer à l'échelle : piloter chaque capacité avec un domaine « design partner » avant un déploiement plateforme.

4. Compétences recherchées A. Compétences produit - plateforme / developer-facing - Expérience de Product Manager sur un produit interne / plateforme / developer-facing (Platform-as-a-Product, developer experience, internal tooling, SDK, API, design system, CI/CD). C'est le critère différenciant n°1. - Capacité à raisonner en outcomes et en adoption plutôt qu'en features livrées ; culture de la discovery continue et de la décision fondée sur des preuves (evidence-based). - Aptitude à influencer sans autorité hiérarchique : le PM sert des domaines clients qu'il ne dirige pas et dépend de leur adoption volontaire. - Aisance avec des interlocuteurs techniques (ingénieurs, QA), sans être nécessairement un profil d'ingénieur. B. Compétences spécialisées - QA / Test Automation Le PM doit comprendre en profondeur le domaine du test automatisé pour arbitrer la valeur et poser les bonnes frontières de golden path. Compétences à sourcer : - Culture du test automation as a product : frameworks et test runners, architecture d'infrastructure de test, stratégie de test (unitaire / intégration / E2E), notion de flaky tests et de fiabilité des suites. - Test cross-platform : compréhension des enjeux de test sur iOS, Android, Web et CTV (device farms, émulateurs/simulateurs, spécificités TV/consoles). - CI/CD et exécution à l'échelle : intégration des tests dans les pipelines, parallélisation, reporting de test unifié, accélération par l'IA (agentic CI). - Domaine streaming / vidéo (atout fort) : QA du player, assertions de lecture, tests de flux de login, certification cross-platform, parité entre plateformes. - Réutilisation et mutualisation : penser des composants de test partagés et réutilisables entre squads plutôt que des solutions par squad. - Métriques qualité : taux de défauts, couverture de test, effort QA par release, délai de livraison cross-platform, taux de certification. Note : l'objectif n'est pas de recruter un QA Lead ou un Test Architect (c'est le rôle du Squad Engineer), mais un PM capable de porter la valeur produit d'une plateforme de test. La séniorité technique QA est un atout, pas le coeur du poste.