Explore every episode of the podcast La Guilde ! - Devenez un expert en Quality Engineering

« C'est bon, tous les tests sont passés. »

Cinq minutes avant la mise en production, c'est la phrase qu'on attend de toi. Et personne ne te demande si c'est une bonne idée de livrer.

Si on te perçoit comme celui qui exécute les tests, ce n'est pas un problème de compétence. C'est que tu parles d'activité, alors que les autres parlent de décisions.

Dans cet épisode, je te donne 4 leviers concrets pour passer de « celui qui teste » à « celui qu'on consulte avant de décider » :

→ Rapporter des risques plutôt que des tests : un risque, un impact, une option
→ Adapter ton discours à chaque interlocuteur : développeur, Product Owner, manager
→ Défendre ta position sans t'effacer et sans jouer les gendarmes
→ Gérer un désaccord avec des faits et un objectif commun

Tu repars avec des phrases prêtes à l'emploi pour ta prochaine réunion de go/no-go.

À retenir : ton rôle n'est pas de dire non. Ton rôle, c'est que la décision soit prise en connaissance de cause.

Et toi, dans quelle situation t'es-tu senti le moins légitime ? Dis-le-moi en commentaire, je lis toutes les réponses.

Un épisode de La Guilde, la communauté des professionnels de la qualité logicielle.

Tu fais peut-être déjà le travail d'un Test Lead (Lead QA) sans en avoir le titre. Dans cet épisode, je passe en revue 7 signaux concrets qui montrent que tu ne fais plus seulement du test logiciel, mais que tu pilotes déjà la qualité de ton équipe.

Les développeurs, les PO et les autres QA viennent te consulter pour évaluer un risque, arbitrer une priorité ou comprendre l'impact d'une anomalie avant la mise en production ? Tu questionnes les critères d'acceptation, tu structures la stratégie de test, tu fais progresser les autres testeurs et tu influences les décisions sans autorité hiérarchique ? Alors tu exerces probablement déjà ce rôle.

Le leadership qualité commence souvent avant le titre. Il commence au moment où tes décisions influent sur le travail des autres.

Je termine sur le piège à éviter quand tu te reconnais dans ces signaux, et sur la question que tu dois absolument te poser pour faire évoluer ta carrière de testeur vers un rôle de Test Lead, QA Lead ou Test Manager.

Autoévaluation gratuite de ta posture de Lead QA : https://tally.so/r/D4Qel5

Bootcamp Leader QA, 6 semaines pour prendre ton rôle de Test Lead avec une vraie méthode : https://shiftopsolutions.systeme.io/bootcamp-qalead

Échanger avec moi sur ta situation : https://tally.so/r/QKdBNl

Newsletter La Guilde : https://laguilde.substack.com
Version vidéo sur YouTube : https://www.youtube.com/watch?v=UISQnooalDA

Autoévaluation gratuite de ta posture de Lead QA : [lien]

Bootcamp Leader QA, 6 semaines pour prendre ton rôle de Test Lead avec une vraie méthode : https://shiftopsolutions.systeme.io/bootcamp-qalead

Échanger avec moi sur ta situation : https://tally.so/r/QKdBNl

Newsletter La Guilde : https://laguilde.substack.com
Version vidéo sur YouTube : https://www.youtube.com/watch?v=UISQnooalDA

Tu rejoins un sprint en cours. Le développeur te dit : "C'est prêt, tu peux tester." Tu demandes la spec. Il te répond : "Il y en a pas vraiment, on a fait au feeling, c'était urgent."

Bienvenue dans la réalité de 80% des équipes agiles. Pas de user story formalisée, pas de critères d'acceptation, parfois même pas de maquette validée. Dans cet épisode, on parle de comment tester dans ces conditions, et pourquoi cette compétence peut rendre ton rôle plus stratégique que jamais.

Au programme :

1️⃣ Pourquoi l'absence de spec n'est pas toujours un signe d'amateurisme, et ce que ça change dans ta posture
2️⃣ La méthode en 5 étapes : reconstituer l'intention, utiliser l'heuristique SFDIPOT, documenter en temps réel, tester par risque, clôturer par une déclaration de couverture
3️⃣ Les 5 pièges à éviter absolument, du "ça fonctionne donc c'est bon" au testing en solitaire

Tester sans spec, ce n'est pas un sous-mode dégradé du testing. C'est une compétence de haut niveau, qui mobilise le sens critique, la pensée systémique et le leadership qualité.

👉 Tu veux muscler ce réflexe sur des cas concrets, avec un retour extérieur qui pointe ce que toi tu ne vois plus ? C'est exactement ce qu'on travaille dans le Bootcamp Leader QA, en mise en situation, pas en théorie.
👉 Infos et inscription : shiftopsolutions.systeme.io/bootcamp-qalead

La production révèle ce que les environnements de test ne montrent pas toujours.

Dans ce dernier épisode de la série, on parle du rôle des ops dans la performance : supervision, observabilité, corrélation entre incidents et métriques, compréhension du comportement réel du système. On aborde aussi les notions clés : logs, métriques, traces, alerting, SLI/SLO, shift right.

La performance ne s'arrête pas aux tests : elle se confirme et se comprend vraiment dans la réalité de production.

Dernier épisode de la série "La performance : l'impact invisible" — la performance ne se pilote pas seulement avant la mise en prod, elle se surveille et se travaille dans la durée.

Attendre les tests de perf pour découvrir les problèmes, optimiser trop tard, ne regarder que le nominal : ce sont les erreurs les plus fréquentes côté dev. Et elles coûtent cher.

Dans cet épisode, on montre que la performance se joue très tôt, dans les choix techniques et l'architecture : requêtes coûteuses, appels inutiles, traitements mal optimisés, dette technique silencieuse. Et on parle des bons réflexes à adopter : profiler, observer, challenger les hypothèses, penser scalabilité et résilience dès la conception.

La performance ne se corrige pas uniquement après coup : elle se prépare dès les choix de conception et de développement.

La performance, un sujet réservé à quelques experts ? Pour les QA, ce temps-là est révolu.

Dans cet épisode, on explique pourquoi la performance concerne directement les QA : elle impacte l'expérience utilisateur, elle révèle des fragilités invisibles en test fonctionnel, elle influence la qualité perçue. On parle aussi des réflexes à développer côté QA : intégrer la performance dans l'analyse de risque, penser temps de réponse et fluidité dès les scénarios, repérer les signaux faibles en recette.

La performance n'est pas un sujet à côté de la QA : c'est une composante directe de la qualité.

Le cliché a la vie dure : le testeur de performance lance un outil, génère de la charge, produit un rapport.

La réalité est bien plus large. Dans cet épisode, on parle du vrai rôle du testeur de performance : modéliser des usages réalistes, choisir les bons scénarios, interpréter les résultats, repérer les signaux faibles, et dialoguer avec les autres métiers.

On passe aussi en revue les erreurs fréquentes : scénarios irréalistes, métriques mal lues, conclusions trop rapides, tests isolés du contexte métier.

Le testeur de performance ne produit pas seulement des chiffres : il produit de la compréhension.

"Ça ira en production." "On verra plus tard." "Si ça marche fonctionnellement, c'est suffisant."

Trois phrases qu'on entend encore trop souvent, et qui montrent à quel point la performance reste un sujet mal compris.

Dans ce premier épisode de la série "La performance : l'impact invisible", on pose le cadre : pourquoi tester la performance, ce n'est pas juste "mettre de la charge". On revient sur les grandes familles de tests (charge, stress, endurance, montée en charge, capacité) et sur ce qu'on cherche réellement à comprendre : temps de réponse, stabilité, tenue sous contrainte, comportements dégradés, limites du système.

Tester la performance, c'est comprendre comment un système réagit sous contrainte, pas seulement vérifier qu'il tient.

Tu bloques une release parce qu'un risque te semble trop élevé. Le PO te répond que le planning est non négociable. Le dev t'explique que c'est un comportement attendu, pas un bug. Et tout le monde attend que tu trouves une solution. Vite.

Dans cet épisode, on parle de la partie du métier de Test Lead qu'aucune formation technique ne prépare : le conflit. Et surtout, pourquoi il faut le gérer différemment selon qu'on est face à un dev ou face à un PM/PO.

Au programme :

1️⃣ Avec les devs : pourquoi débattre de "c'est un bug ou pas" te fait perdre en crédibilité, et ce qui marche à la place
2️⃣ Avec les PMs et POs : comment traduire ton alerte technique en risque business pour être vraiment entendu
3️⃣ Que faire quand le désaccord persiste malgré une argumentation solide

La règle qui traverse tout l'épisode : séparer la personne du problème. Un conflit bien géré n'est pas un conflit qui disparaît, c'est un conflit qui devient une décision claire, assumée et documentée.

👉 Tu te reconnais dans ces situations et elles te mettent encore en difficulté aujourd'hui ? Le Bootcamp Leader QA est fait pour ça : on travaille ces réflexes sur des mises en situation concrètes, pas en théorie, pour que le bon geste soit déjà là le jour où le vrai conflit arrive en réunion.
👉 Infos et inscription : shiftopsolutions.systeme.io/bootcamp-qalead

Tu présentes ta stratégie en comité de pilotage. Et là : "Pourquoi vous ne testez pas ça ?" "On peut pas juste tester moins ?"

Si tu bafouilles ou que tu sors une réponse trop technique, t'as déjà perdu. Pas parce que ta stratégie est mauvaise : parce qu'elle n'a pas été construite pour être défendue.

Dans cet épisode, je te donne 3 leviers pour arrêter de subir ces réunions et commencer à les gagner :

1️⃣ Traduire en risques, pas en couverture
2️⃣ Anticiper les objections avant qu'on te les pose
3️⃣ Rendre ta stratégie lisible en 10 secondes

Le piège du testeur, c'est de parler test à des gens qui pensent risque et argent. Cet épisode t'aide à sortir de ce piège.

👉 Tu veux aller plus loin et structurer une stratégie de test béton, capable de tenir face à n'importe quel comité ? Rejoins le Bootcamp Leader QA : shiftopsolutions.systeme.io/bootcamp-qalead

🎧 Bonne écoute, et dis-moi en commentaire ta dernière objection reçue en réunion sur une stratégie de test.

Pas de spécialiste a11y, pas de budget identifié, pas de process clair, juste une vague conscience collective que "ça serait bien d'y penser un jour." Dans cet épisode, on montre que l'accessibilité ne nécessite pas une équipe dédiée, mais une méthode, quelques réflexes bien placés, et une compréhension claire de pourquoi c'est devenu non-négociable.

Au programme :

→ Pourquoi l'accessibilité n'est plus une option : le contexte réglementaire (Acte Européen d'Accessibilité, juin 2025) et l'argument business
→ Les bases : WCAG, RGAA, et les 4 principes d'un contenu accessible (perceptible, utilisable, compréhensible, robuste)
→ Comment l'intégrer sans expert dédié, rôle par rôle : design, développement, QA (les 3 niveaux de vérification), organisation
→ Les 4 erreurs qui font échouer les initiatives accessibilité : projet ponctuel, outils automatisés seuls, confondre conformité et accessibilité, attendre l'expert pour commencer

Une chose à retenir : intégrer tôt, tester en continu, progresser par paliers. Pas besoin d'être conforme à 100 % du premier coup, chaque composant rendu accessible est un utilisateur de plus qui peut utiliser ce que tu livres.

🎙️ Un épisode de La Guilde, le podcast pour les passionnés de Quality Engineering.

Nouvelle équipe, nouveau produit, et trente jours pour comprendre comment les choses fonctionnent sans marcher sur les plates-bandes de quelqu'un ni promettre ce que tu ne pourras pas tenir.

Dans cet épisode, on traverse semaine par semaine les trente premiers jours qui définissent ta crédibilité pour les mois qui suivent.

Au programme :

→ Semaine 1 : pourquoi écouter avant tout, les trois questions à poser à chaque membre de l'équipe, et l'intérêt d'explorer le produit avec un œil neuf
→ Semaines 2-3 : cartographier les risques, analyser la stratégie de test existante, repérer les quick wins
→ Semaine 4 : produire un bilan partageable, lancer un premier chantier concret, formaliser son périmètre
→ Les 4 erreurs classiques qui compromettent l'onboarding qualité : arriver avec ses solutions, rester dans son couloir, promettre trop tôt, ignorer le rythme de l'équipe

Une chose à retenir : écouter, cartographier, agir progressivement. La crédibilité en qualité se gagne dans la durée, et elle commence par un premier mois bien géré.

🎙️ Un épisode de La Guilde, le podcast pour les passionnés de Quality Engineering.

📌 Un cadre structuré pour accompagner ta prise de poste QA, Test Lead ou Test Manager ? Retrouve le pack coaching prise de poste de La Guilde en description.

🎯 Pourquoi certaines équipes retombent vite dans leurs anciens réflexes, et ce qui fait qu'une transformation devient culturelle plutôt qu'un simple sprint d'initiatives.

Rapport au feedback, droit à l'erreur, exigence partagée : on referme la série sur les signes d'une culture qui porte la QA, plutôt qu'une seule personne. L'automatisation comme levier d'embarquement, le contact terrain comme vrai moteur, et le fameux déclic : "si ça n'a pas marché, on revient sur des réflexes."

👉 La vraie réussite d'une transformation QA, ce n'est pas un nouveau process. C'est une nouvelle culture d'équipe.

🎯 Un sujet qu'on évite trop souvent d'aborder frontalement : l'ego, et son impact réel sur la qualité et la dynamique d'équipe.

Fermeture, posture défensive, refus du feedback, guerre de territoire d'un côté. Fierté du travail bien fait, ambition, leadership de l'autre. On décrypte les signaux d'un ego qui freine la transformation, et comment le canaliser au service du collectif plutôt que du pouvoir. On parle aussi d'ego-less programming, et de sortir du modèle du sauveur pour co-construire.

👉 L'ego n'est pas le problème. Le problème, c'est quand il prend le dessus sur l'objectif commun.

🎯 Les meilleurs frameworks ne suffisent jamais. Une transformation QA se joue d'abord dans les relations humaines.

Manque de confiance, peur du jugement, communication qui coince entre QA, produit et dev : on regarde ce qui bloque vraiment, et ce que demande une transformation qui tient : écoute, pédagogie, clarté, patience, capacité à embarquer.

Spoiler : les savoir-être ont souvent plus d'impact que les savoir-faire.

👉 Avance avec les motivés. Les autres suivront.

🎯 Aucune transformation sérieuse ne démarre sans lucidité sur ce qui ne marche pas. Et regarder ses dysfonctionnements en face, ce n'est jamais confortable.

On explore les réflexes classiques face aux irritants (minimiser, se justifier, accuser, protéger l'existant), et comment créer un cadre où on peut parler des problèmes sans chercher un coupable. Le rapport d'étonnement, les 5-10 points critiques listés en une minute sur une feuille, le rôle de la QA pour rendre visible ce qui grince : autant de leviers concrets pour lancer le changement.

👉 Un cheval à la fois. Choisis tes combats.

🎯 En QA, changer un outil ou un process, c'est facile à dire. Changer des habitudes, des repères et des façons de collaborer, c'est une autre histoire.

Dans ce premier épisode, on pose le cadre de la série avec Jerémie Hattat : pourquoi presque tous les sujets QA sont, au fond, des sujets de transformation. On parle du shift left comme activité continue (pas une étape en fin de cycle), de l'adhésion de la direction qui ne suffit jamais seule, et des résistances classiques : peur de perdre le contrôle, fatigue du changement, décalage entre la vision et le terrain.

👉 Si t'arrives en QA dans une équipe qui n'en a jamais eu, cet épisode est pour toi.

T'es seul profil qualité dans l'équipe, sans mandat, sans budget, parfois sans même qu'on comprenne ce que tu fais. Dans cet épisode, on parle survie et stratégie, sans langue de bois.

Au programme :

→ Pourquoi se battre contre le contexte est la première erreur à éviter, et quelle posture adopter à la place
→ Les 3 batailles à choisir quand on ne peut pas tout faire : bugs récurrents, lisibilité des critères d'acceptance, filet de régression minimal
→ Comment construire de l'influence sans autorité formelle : visibilité des problèmes, victoires rapides, langage de l'équipe
→ Les signaux qui indiquent que le problème dépasse le levier individuel, et comment se positionner face à ça

Une chose à retenir : cartographier, choisir ses batailles, rendre la valeur visible. Le changement culturel se mesure en trimestres, pas en sprints, mais chaque victoire concrète est une brique qui s'accumule.

🎙️ Un épisode de La Guilde, le podcast pour les passionnés de Quality Engineering.

94 % de taux d'exécution. 847 cas de test. 23 bugs résolus. Le management hoche la tête et pourtant, personne ne sait si le produit est prêt à livrer.

C'est le problème des métriques vanité : elles mesurent l'activité de test, pas la qualité du produit.

Dans cet épisode, on passe de l'un à l'autre.

Au programme :
→ Pourquoi les métriques classiques (taux d'exécution, nombre de bugs) ne permettent pas de prendre une décision
→ Les indicateurs orientés risque, flux et vélocité qui changent vraiment la lecture
→ Une structure en 3 couches pour construire un tableau de bord qualité cohérent
→ Comment introduire ces nouveaux KPIs sans créer de résistance dans ton organisation

Un bon KPI qualité répond à une question que quelqu'un se pose vraiment. Il a un seuil, un propriétaire, et une action associée. Tout le reste, c'est du bruit.

🎯 À écouter si tu es Test Lead, Test Manager ou Engineering Manager et que tu veux que tes rapports qualité servent à quelque chose.

Tu as déjà vu une appli tenir la route à 10 utilisateurs... et s'effondrer à 1 000 ? C'est exactement ce que les tests de performance sont censés prévenir et pourtant, ils restent l'un des angles morts les plus fréquents en QA.

Dans cet épisode, on démystifie le sujet pour ceux qui n'ont jamais mis les mains dedans.

Au programme :
→ La différence concrète entre test de charge, test de stress et test d'endurance
→ Les 4 métriques essentielles à mesurer (et pourquoi la moyenne ne suffit pas)
→ 3 étapes pour lancer un premier test fonctionnel sans expertise préalable
→ Comment lire et communiquer les résultats pour que ça serve à quelque chose

Des outils open source, des scénarios simples, une logique décisionnelle claire. Pas de théorie décorative : juste ce qu'il faut pour commencer.

🎯 À écouter si tu fais du QA, du dev, ou si tu travailles sur un produit qui devra un jour encaisser une vraie charge.

Dans ce cinquième et dernier épisode, Guillaume Cousin conclut la mini-série avec un sujet qu'il connaît bien : l'audit QA, et pourquoi c'est souvent le point de départ le plus solide pour une transformation crédible.

Un audit bien conduit, ce n'est pas une inspection. C'est une lecture fine de la réalité d'une équipe : les irritants réels que personne ne formule clairement, les écarts entre ce qui est dit et ce qui est pratiqué, les points forts que l'on oublie de valoriser, et les priorités d'action concrètes avec des horizons réalistes à un mois, trois mois, six mois.

Guillaume revient aussi sur le lien naturel entre l'audit, le conseil et la formation, trois niveaux d'intervention qui se renforcent quand ils sont articulés autour d'une même compréhension du terrain.

Un épisode pour ceux qui veulent agir avec méthode, en commençant par regarder la situation en face avant de proposer quoi que ce soit.

Dans ce quatrième épisode, Guillaume Cousin explique ce que le conseil QA apporte là où la formation ne peut pas aller.

Quand une équipe est bloquée, quand les rôles ne sont pas clairs, quand les pratiques ne décollent pas malgré la bonne volonté, il faut quelqu'un capable de prendre du recul, d'identifier ce qui coince vraiment, et de structurer une trajectoire réaliste. C'est le cœur du travail de conseil.

Guillaume détaille ce que cela implique concrètement : prioriser les actions qui auront de l'impact, rester rattaché aux réalités terrain plutôt qu'à un modèle idéal, et accompagner les Test Leads juniors qui manquent souvent de repères pour avancer seuls. Il trace aussi une distinction nette entre former et conseiller, deux postures complémentaires mais différentes dans leur nature et dans leur effet.

Un épisode pour comprendre pourquoi transformer une organisation QA ne se décrète pas, et ce que l'accompagnement par le conseil change vraiment dans la façon dont les équipes progressent.

Dans ce troisième épisode, Guillaume Cousin s'attaque à une question plus profonde qu'il n'y paraît : à quoi sert vraiment une formation QA ?

Pas à cocher une case. Pas à délivrer un certificat. Une bonne formation, selon Guillaume, c'est ce qui permet de valider le métier de testeur, de créer un langage commun dans une équipe, de renforcer les fondamentaux souvent survolés, et de développer les réflexes qui font la différence au quotidien.

Mais il soulève aussi les limites que l'on rencontre trop souvent : des formations trop théoriques, déconnectées du contexte réel des participants, ou qui n'intègrent pas suffisamment de mise en pratique. Et surtout, le manque de suivi dans la durée, particulièrement critique pour les profils en reconversion qui ont besoin d'un accompagnement qui ne s'arrête pas le dernier jour de formation.

Un épisode utile pour toute personne qui forme, qui encadre, ou qui cherche à progresser dans le métier, avec une vision claire de ce qui transforme vraiment les compétences.

Dans ce deuxième épisode, Guillaume Cousin aborde un sujet qui fait débat sur le terrain : l'agilité a-t-elle vraiment transformé la qualité ?

Sur le papier, les promesses sont séduisantes. Des cycles courts, une collaboration renforcée, une qualité intégrée au flux de développement.

Mais dans la réalité des équipes, Guillaume observe autre chose. Des rôles QA flous, attribués d'office sans véritable volonté ni préparation. Une qualité diluée, réduite à un mini cycle en V coincé à l'intérieur d'un sprint. Et des pratiques comme le TDD ou le DevOps présentées comme des évidences, alors qu'elles demandent des conditions organisationnelles et une maturité réelle pour fonctionner.

On parle aussi de collaboration inégale, de théories trop idéalistes face à la réalité du terrain, et de ce qui manque souvent pour que la transition agile produise de vrais effets côté qualité.

Un épisode ancré dans le concret, pour ceux qui ont vécu ces situations de l'intérieur et qui cherchent à comprendre pourquoi changer de méthode ne suffit pas quand les postures et les pratiques restent les mêmes.

Dans ce premier épisode, je reçois Guillaume Cousin pour ouvrir une mini-série de cinq épisodes autour du conseil et de la formation en QA.

Avant de parler pratiques, méthodes ou transformation des équipes, on commence par l'essentiel : qui est Guillaume, d'où il vient, et ce que son parcours dit de la QA.

Son terrain de jeu ? La Défense.

Un univers où la qualité ne se discute pas, elle se prouve. Des systèmes critiques, des exigences de fiabilité et de traçabilité poussées à leur maximum, des équipes QA qui ne peuvent pas se permettre l'à-peu-près. Guillaume nous plonge dans ce contexte particulier et on comprend vite pourquoi passer par la Défense forge une certaine vision de ce que la qualité veut vraiment dire.

On explore aussi un concept central dans cet univers : la V&V, vérification et validation. Un cadre rigoureux qui relie chaque test à une exigence, chaque exigence à une preuve, chaque preuve à un niveau de confiance. Pas de la théorie mais une discipline de travail, avec tout ce que ça implique en termes de documentation, de méthode et de posture professionnelle.

Un épisode pour poser les bases : comprendre que la QA, quand elle est pratiquée dans des environnements à forts enjeux, est d'abord une discipline de rigueur et de compréhension du risque, avant d'être une question d'outils ou de frameworks.

Et si le rôle du QA n’était plus de tester pour tout le monde, mais d’aider toute l’équipe à mieux construire la qualité ?

Dans cet épisode, on parle de Quality Assistance, une évolution naturelle du rôle QA dans les équipes agiles et produit matures.

Pendant longtemps, le QA a été vu comme le gardien de la qualité : celui qui teste à la fin, trouve les bugs, valide ou bloque une livraison. Ce modèle peut rassurer, mais il montre vite ses limites : qualité en bout de chaîne, dépendance au QA, goulot d’étranglement, corrections tardives.

Le modèle Quality Assistance propose autre chose : faire de la qualité une responsabilité partagée.

Le QA ne disparaît pas. Il change de posture. Il intervient plus tôt, challenge les critères d’acceptance, aide à identifier les risques, accompagne les développeurs dans leurs pratiques de test, structure les guidelines et facilite la montée en maturité de l’équipe.

Dans cet épisode, tu vas découvrir :

• pourquoi le modèle QA classique atteint ses limites ;
• ce que signifie vraiment Quality Assistance ;
• comment amorcer cette transition dans une équipe ;
• ce que ce modèle ne veut surtout pas dire ;
• pourquoi le QA gagne en impact lorsqu’il arrête de tout porter seul.

Un épisode pour les QA, Test Leads, Engineering Managers et équipes produit qui veulent sortir d’une logique de contrôle tardif pour construire une qualité plus collective, plus durable et plus efficace.

L'IA va remplacer les testeurs. L'IA génère des tests automatiquement. L'IA détecte tous les bugs. Tu as lu ces titres. Maintenant, voilà la réalité terrain.

Dans cet épisode, on démêle ce que l'IA fait vraiment bien (génération de cas de test, analyse de logs, données de test), ce qu'elle ne fait pas et ne fera pas de sitôt (jugement métier, exploration, priorisation par le risque) et comment l'intégrer concrètement dans ton quotidien, sans budget dédié ni expertise particulière.

Ni évangélisation, ni rejet. La posture de l'utilisateur critique : accélérer, pas déléguer.

🎯 Au programme :

• Les cas d'usage où l'IA apporte une vraie valeur terrain
• Les limites que personne ne te dit (hallucinations, fausse confiance, couverture illusoire)
• 3 intégrations pragmatiques accessibles dès maintenant
• La bonne posture pour rester propriétaire de ta stratégie

La Guilde - le podcast pour les QA, Dev et Test Lead qui veulent du concret.🔗 laguilde.substack.com

Tu es Test Lead depuis quelques années.

Tu maîtrises ton périmètre, tu connais ton équipe, tu sais faire tourner une stratégie de test… et maintenant, on te propose peut-être de devenir Test Manager.

Ou alors tu vises ce rôle, mais tu te demandes ce que ça change vraiment.

Dans cet épisode, je te partage une idée essentielle : devenir Test Manager, ce n’est pas simplement devenir un Test Lead avec plus de responsabilités. C’est changer de métier, d’horizon et de posture.

On parle moins d’exécution, plus d’organisation.
Moins de pilotage opérationnel, plus de vision transverse.
Moins de “faire soi-même”, plus de capacité à faire grandir les autres.

Dans cet épisode, on explore :

✅ ce qui change vraiment entre Test Lead et Test Manager ;
✅ les compétences que le rôle de Lead ne t’a pas toujours permis de développer ;
✅ la gestion budgétaire, le recrutement, la communication stratégique et la vision transverse ;
✅ comment te préparer progressivement à cette transition ;
✅ les pièges classiques des premiers mois : rester trop opérationnel, manager tout le monde pareil, ou perdre le lien avec le terrain.

Un épisode pour les Test Leads, QA Leads et profils qualité qui veulent prendre plus de hauteur, évoluer vers le management, ou mieux comprendre ce que ce rôle exige réellement.

🎧 Bonne écoute.

Tu jongles entre les tutos YouTube, les frameworks à la mode et les certifications qui s'empilent… mais tu as toujours l'impression de courir sans vraiment avancer ?

Le problème n'est pas le manque de ressources. C'est l'absence de cap.

Dans ce dernier épisode, Fode Cissé partage ce qu'il aurait aimé savoir plus tôt et comment construire un parcours d'apprentissage solide, sans dispersion.

Au programme :🎯 Les erreurs classiques de formation (l'outil sans le pourquoi, le copier-coller de tutos)🎯 Les fondamentaux qui font vraiment la différence : stratégie, architecture, process métier🎯 Une progression concrète

Tout le monde parle d'IA. Beaucoup promettent l'autonomie totale. La réalité est ailleurs.

L'IA ne remplace pas la réflexion stratégique. Elle l'amplifie pour ceux qui savent déjà ce qu'ils font.

Avec Fode Cissé, on ouvre les perspectives sans tomber dans la hype : ce que l'IA change vraiment pour les QA et QE, et comment te positionner intelligemment face à cette évolution.

Au programme :🎯 Ce que l'IA n'est pas (encore) et les illusions à déconstruire🎯 Ce qu'elle apporte déjà : génération de tests, analyse de logs, aide à la décision🎯 Agents,, no-code et les nouveaux rôles qui émergent pour les profils qualité

L'automatisation qui fait du bruit, c'est souvent celle qui dysfonctionne.Celle qui tourne en silence depuis 18 mois ? Personne n'en parle. Et c'est exactement ça, le signe que c'est du bon travail.

Dans cet épisode, Fode Cissé partage les repères concrets qu'il applique, que ce soit en test auto ou en automatisation de processus.

Au programme :🎯 Comment bien choisir quoi automatiser (critiques, stables, à forte valeur métier)🎯 Penser maintenabilité avant rapidité : lisibilité, nommage, design patterns🎯 Intégration CI/CD, observabilité, et pont avec l'orchestration de processus

Tu as lancé ton projet d'automatisation avec de bonnes intentions.Quelques mois plus tard : des scripts qui cassent pour un rien, une maintenance qui bouffe tout ton temps, et une équipe qui ne fait plus confiance aux résultats.

Bienvenue dans la dette technique déguisée en progrès.

Avec Fode Cissé, on décortique les erreurs classiques qui transforment l'automatisation en boulet et comment les éviter avant qu'il ne soit trop tard.

Au programme :🎯 Les pièges les plus fréquents (tout automatiser, tester l'instable, sans stratégie)🎯 Les faux bons indicateurs qui te donnent bonne conscience🎯 Quand l'automatisation devient toxique

On t'a vendu l'automatisation comme la solution à tous tes problèmes de qualité.Plus rapide. Moins coûteuse. Scalable.

Sauf que sur le terrain, la réalité est souvent toute autre : des scripts fragiles, une maintenance qui explose, et des équipes qui perdent confiance dans leurs propres tests.

Alors, pourquoi autant de projets d'automatisation finissent-ils dans le mur ?

Dans ce premier épisode, je reçois Fode Cissé — Expert en Automatisation des tests et Formateur. Aujourd'hui, il partage son expérience sur YouTube à l'intersection de la qualité, de l'efficacité opérationnelle et des systèmes automatisés.

Au programme :🎯 Les 3 grands malentendus sur l'automatisation (vitesse, coût, remplacement humain)🎯 Ce qu'on automatise vraiment et pourquoi🎯 Les vraies raisons qui font échouer les projets d'auto

Pour en savoir plus sur le programme de formation de Fodé : zotomatise.com

Un pipeline CI/CD, c'est une promesse : livrer vite, livrer souvent, livrer avec confiance.

Dans la pratique ?

La plupart des pipelines livrent vite et souvent. Mais pas toujours avec confiance. Parce que les checks qualité sont soit trop légers, soit mal placés - soit tellement lourds que l'équipe finit par les contourner.

Dans cet épisode, on parle stratégie. Pas d'outils. Pas de stack. De principes.

- La pyramide des tests et pourquoi l'anti-pattern du cône de glace tue les pipelines- Ce qu'on place sur chaque commit, sur chaque merge, sur chaque release candidate-Les erreurs de placement les plus fréquentes (et leurs conséquences concrètes)- Pourquoi une Quality Gate n'est pas qu'un check technique - Comment faire évoluer un pipeline pour qu'il reste utile, pas juste présent

Un épisode pour les QA, les devs et les DevOps qui veulent un pipeline que l'équipe respecte vraiment - parce qu'il est rapide sur ce qui compte, et honnête sur ce qu'il ne peut pas détecter.

🎙️ La Guilde - le podcast Quality Engineering francophone.📩 Newsletter & ressources : laguilde.substack.com

T'as déjà déployé en recette avec tous les tests au vert… et retrouvé l'appli cassée en prod deux heures plus tard ?

Pas à cause d'un bug. Pas à cause d'une mauvaise config. Juste parce qu'une autre équipe a renommé un champ dans son API.

C'est le couplage invisible. Et c'est exactement ce que le Contract Testing permet de détecter - avant le merge, avant le déploiement, avant la casse.

Dans cet épisode, on démonte le concept de bout en bout :

- Pourquoi les tests d'intégration classiques ne suffisent plus en architecture distribuée- Ce qu'est un contrat API et la différence entre contract-first et Consumer-Driven Contract Testing- Comment le flux fonctionne concrètement : du consommateur au registre jusqu'au pipeline du fournisseur- Ce que ça change vraiment dans l'organisation : autonomie des équipes, détection dans la PR, et rôle du QE

Un épisode terrain, sans jargon inutile, pour comprendre pourquoi formaliser les contrats entre services c'est pas une option : c'est une condition de maturité.

🎙️ La Guilde - le podcast Quality Engineering francophone.📩 Newsletter & ressources : laguilde.substack.com

Le QA ne s'arrête pas à la fin du sprint. Ni au périmètre du projet.

Pour clore cette série, Christophe Popiol et moi on élargit la focale : le rôle des communautés QA comme France-QA dans la montée en compétences collective, ce que les entreprises recherchent vraiment quand elles recrutent un QA (spoiler : pas juste quelqu'un qui exécute des cas de test), et comment se différencier concrètement pour trouver des missions qui ont du sens.

Curiosité, autonomie, posture d'explorateur : c'est ça que le marché valorise. Et c'est ça que cette série a cherché à illustrer, épisode après épisode.

Sur desktop, les specs sont incomplètes. Sur mobile, elles sont insuffisantes par construction.

Devices, OS, réseau instable, interruptions, gestes, contextes d'usage réels : le mobile expose tout ce que les cas nominaux ne couvrent jamais. Et c'est là que les QA qui se limitent aux specs se font rattraper par la réalité utilisateur.

Dans cet épisode, Christophe Popiol partage sa vision du QA mobile comme explorateur — celui qui teste dans la vraie vie, observe les usages réels, et ne se contente pas de valider que ça "fonctionne en conditions idéales".

On parle batterie, performance, interruptions, et posture d'investigation dans un contexte où l'environnement est par nature incontrôlable.

Si tu testes uniquement ce que tu vois à l'écran, tu testes la surface.Les vraies anomalies, elles se cachent ailleurs : dans les logs, dans les temps de réponse, dans les warnings que personne ne regarde.

Dans cet épisode, Christophe Popiol explique comment un QA mature sort du mode "boîte noire" pour exploiter les signaux techniques. Erreurs silencieuses, comportements intermittents, dégradations de performance : autant d'indices que l'UI ne te montrera jamais mais que les logs, eux, racontent.

On parle méthode : comment corréler symptômes et causes, comment poser les bonnes questions au bon niveau, comment passer du cochage de cases à l'enquête système.

"Je suis QA fonctionnel. Le code, c'est pas mon problème."

C'est la réponse confortable. Ce n'est pas la bonne.

Dans cet épisode, Christophe Popiol et moi on s'attaque à la question qui fâche : est-ce qu'un QA qui ne regarde jamais le code peut vraiment bien tester ?

On ne parle pas de devenir développeur. On parle de lire un diff, comprendre une stacktrace, identifier les zones à risque avant même d'ouvrir l'appli.

Comprendre le code, c'est comprendre ce qu'on teste. Et ça change tout : sur la couverture, sur les échanges avec les devs, sur l'anticipation des effets de bord.

Tu testes ce qui est écrit. Tu couvres le périmètre. Tu fermes tes tickets.Et pourtant… des bugs passent. Des angles morts persistent. Des décisions implicites ne sont jamais questionnées.

Dans ce premier épisode, j'accueille Christophe Popiol , professionnel QA engagé dans la communauté , pour ouvrir une série qui va déranger quelques habitudes.

On démonte ensemble le mythe du QA "exécutant de cas de test" : pourquoi les specs sont toujours incomplètes par nature, ce que ça coûte de s'y limiter, et ce que le vrai rôle du QA implique vraiment : questionner, explorer, détecter les signaux faibles.

Tu viens d'être nommé Test Lead. Ou tu l'es depuis quelques mois et tu as encore ce sentiment bizarre d'être entre deux chaises. Ni vraiment testeur, ni vraiment manager.

C'est normal. Et c'est exactement le sujet de cet épisode.

La prise de poste Test Lead est l'une des transitions les plus mal accompagnées de nos métiers. On prend le meilleur profil de l'équipe, on lui donne un titre — et on s'attend à ce que ça suive. Mais les compétences qui t'ont amené là ne sont pas celles dont tu as besoin maintenant.

Dans cet épisode, on démonte les 4 erreurs classiques du Test Lead débutant :→ Rester testeur dans la tête alors que le rôle a changé→ Vouloir tout contrôler au lieu de structurer et déléguer→ Oublier de communiquer vers le haut — et subir en silence→ Confondre couverture de tests et vraie qualité

Et surtout, on parle de ce qu'on fait à la place : comprendre avant d'agir, poser des critères clairs, devenir visible côté produit, et construire les bonnes relations — avec ton équipe QA, les devs, et le PM.

En résumé : comprendre, structurer, influencer. Le titre ne fait pas le rôle. C'est la posture qui le construit.

🎙️ La Guilde — le podcast des professionnels du Quality Engineering📬 Newsletter & ressources : laguilde.substack.com

Deux critères vagues dans la user story. Un sprint qui part mal. Un dev qui dit "c'est fini", un QA qui trouve des bugs, un PO qui dit "c'était pas ça". Le scénario te parle ?

Dans cet épisode, on ouvre le vrai chantier : les critères d'acceptance. Ce contrat interne qu'on bâcle faute de temps et qui coûte deux à trois fois plus en retravail qu'il n'aurait coûté à bien écrire.

Au programme :→ Pourquoi l'ambiguïté a un coût direct sur la vélocité→ Les 4 dimensions d'un bon critère (nominal, alternatif, erreur, non-fonctionnel)→ Given/When/Then vs liste de règles : quand utiliser quoi→ Two rituels concrets pour changer la pratique en équipe : Three Amigos et Definition of Ready

Pas de théorie décorative. Des formats actionnables, des exemples concrets, et une règle simple : si tu ne peux pas le vérifier de façon non ambiguë, il n'est pas encore assez précis.

🎙️ La Guilde, le podcast des professionnels du Quality Engineering📬 Newsletter & ressources : laguilde.substack.com

Ta suite de régression prend 3 jours à tourner et personne n'ose rien supprimer ?

Dans cet épisode, je démonte le mythe du "il faut tout tester" et on pose une approche concrète pour reprendre le contrôle : auditer sa suite existante, prioriser par le risque, et segmenter par fréquence d'exécution.

👉 Résultat : moins de bruit, plus de confiance, un feedback loop qui a du sens.

Au programme :

• Pourquoi les suites de régression dérivent (et coûtent cher)
• Le principe du test basé sur le risque appliqué à la régression
• 3 actions concrètes pour restructurer ta suite dès ce sprint

Pas de théorie décorative. Du terrain, des choix, de l'ownership.

On a parlé des utilisateurs, des QA, des managers. Il était temps de prendre de la hauteur.

Parce que la qualité, au fond, ne dépend pas d'une seule personne. Elle émerge — ou elle s'effondre — du fonctionnement global de l'équipe.

Dans ce dernier épisode, Imen Naguez et moi on clôt la série avec la question la plus profonde : et si le QA était le révélateur de l'état psychologique d'un système entier ?

Défensivité, silos, déresponsabilisation, non-dits collectifs… Le QA les voit. Les ressent. Les absorbe. Mais surtout, s'il est bien positionné, il peut les mettre en lumière et aider le système à se transformer.

👉 Dans cet épisode, on explore :

• L'équipe comme système vivant : interactions, rituels, zones d'ombre
• Les signaux faibles que le QA capte avant tout le monde
• Comment passer du rôle de détecteur à celui d'accompagnateur et de coach
• Vers une qualité collective : responsabilisation, coaching, sens partagé

💡 La qualité n'est pas un livrable, c'est l'état psychologique du système.

Merci d'avoir suivi cette série. On espère qu'elle t'a donné envie de regarder ton projet… avec d'autres yeux.

🎧 Bonne écoute.

Entre le management qui pousse, les équipes qui doutent, et les délais qui ne bougent pas — le test manager marche sur un fil.

Chaque jour, il absorbe des tensions contradictoires. Qualité vs vitesse. Risque vs engagement. Exigences business vs réalités terrain. Et il doit trancher. Assumer. Expliquer. Sans perdre ni sa crédibilité ni sa sérénité.

Dans cet épisode, Imen Naguez et moi on décortique ce rôle de "tampon émotionnel" que personne ne revendique, mais que tout le monde attend du test manager.

👉 Dans cet épisode, on explore :

• Les arbitrages invisibles que le test manager fait seul, chaque semaine
• Pourquoi calme, clarté et décision assumée sont ses vraies compétences clés
• Comment rassurer une équipe, recadrer un sponsor et tenir une posture sous pression
• Le test manager comme psychologue collectif, celui qui donne du sens quand tout part dans tous les sens

💡 Manager la qualité, c'est manager aussi des tensions humaines.

Si tu es test manager ou lead QA, cet épisode est un miroir. Et peut-être un peu de réconfort.

🎧 Bonne écoute.

Être celui qui dit non. Annoncer les mauvaises nouvelles. Soulever les problèmes que personne ne veut entendre. Et recommencer. Sans toujours être écouté. Sans toujours être reconnu.

Dans cet épisode, Imen Naguez et moi on aborde un sujet encore tabou dans nos métiers : le vécu émotionnel du QA.

Le syndrome de l'imposteur. La fatigue de devoir se justifier. Le besoin de perfection qui épuise. Et ce burn-out silencieux qui s'installe quand personne ne remarque que le QA, lui aussi, a besoin de soutien.

👉 Dans cet épisode, on explore :

• Les émotions du quotidien du QA — celles qu'on ne verbalise jamais
• Les biais internes qui fragilisent la posture : sur-contrôle, perfectionnisme, peur de ne pas être légitime
• La fatigue émotionnelle du QA psychologue… sans psychologue pour lui
• Les leviers concrets pour retrouver équilibre, recul et crédibilité

💡 Un QA qui ne va pas bien ne peut pas effectuer son travail.

Avant de parler de qualité logicielle, parlons de qualité de vie au travail.

🎧 Bonne écoute.

Les utilisateurs ne font jamais ce qu'on attend d'eux.

Et ce n'est pas un problème — c'est la réalité humaine.

Dans cet épisode, Imen Naguez et moi on creuse une conviction que beaucoup d'équipes refusent d'accepter : tester, ce n'est pas valider un scénario. C'est explorer un comportement.

On parle de raccourcis mentaux, d'émotions, de contexte d'usage. On parle de ces biais d'équipe qui font qu'on conçoit des logiciels pour un utilisateur imaginaire — rationnel, attentif, patient — qui n'existe pas.

👉 Dans cet épisode, on explore :

• Pourquoi les utilisateurs "font n'importe quoi"… et ont pourtant raison
• Le QA comme observateur des usages réels, pas des cas prévus
• Empathie, personas, parcours utilisateurs : les outils du QA psychologue
• Les croyances limitantes qui sabotent les tests avant même qu'ils commencent

💡 Tester, ce n'est pas vérifier un scénario, c'est explorer un comportement.

Si tu veux des tests qui reflètent le monde réel, commence par comprendre les humains qui l'habitent.

🎧 Bonne écoute.

Et si les bugs n'étaient que des symptômes ?

Dans ce premier épisode, j'accueille Imen Naguez pour ouvrir une série qui sort des sentiers battus : la psychologie au cœur de la qualité logicielle.

On parle souvent de méthodes, de coverage, de KPIs. Mais rarement de ce qui se passe vraiment entre les humains d'un projet.

Pourtant, le QA observe. Écoute. Reformule. Questionne sans juger. Il capte ce qui est dit… et surtout ce qui ne l'est pas.

👉 Ça te rappelle quelqu'un ?

Dans cet épisode, on explore :

• Le parcours d'Imen et pourquoi ce parallèle QA / psychologue lui parle profondément
• Le rôle invisible du QA : celui qui met en lumière les non-dits
• Les points communs entre curiosité, neutralité et questionnement, des deux côtés du canapé
• Pourquoi la qualité échoue si souvent… et que ce n'est presque jamais un problème technique

💡Un bug est souvent le symptôme d'un malaise plus profond.

Si tu penses que la qualité, c'est avant tout une affaire d'humains, cet épisode est fait pour toi.

🎧 Bonne écoute.La série complète : 5 épisodes, 5 angles psychologiques, une seule conviction — la qualité naît des interactions, pas des outils.

Couverture de code, nombre de tests, bugs ouverts, taux de réussite des pipelines… Et si tout ça ne servait à rien ?

La plupart des dashboards qualité sont des posters. Ils sont pleins de courbes. Ils rassurent. Et ils ne changent rien.

Dans cet épisode, j'introduit le concept de Quality Intelligence : transformer des signaux qualité en décisions actionnables ; pas en vanity metrics.

Au programme :

📊 Vanity metrics vs indicateurs décisionnelsPourquoi le pourcentage de couverture, le nombre total de tests ou le pass rate global sont des chiffres qui occupent l'espace sans guider aucune décision et comment les reconnaître.

🎯 La règle d'or : "quelle décision ?"Avant de choisir un KPI, trois questions à poser systématiquement. Et une formule simple à garder : Un KPI utile = Décision + Risque + Action + Seuil.

🏗️ Le framework en 3 couchesImpact utilisateur et business, qualité du delivery, diagnostic engineering — comment structurer un dashboard lisible, sans 30 graphiques inutiles, avec un maximum de 8 à 12 indicateurs.

🛠️ La méthode en 5 étapesChoisir 3 décisions récurrentes, cartographier 5 risques majeurs, associer un indicateur et un levier par risque, fixer des seuils, et installer la boucle de décision dans les rituels d'équipe.

💡 Des exemples concrets prêts à l'emploiFlaky rate, change failure rate, MTTR, bugs critiques ouverts — avec pour chacun la décision qui suit et le levier à actionner.

Que vous soyez engineering manager, tech lead, QA ou product owner, cet épisode vous donne un cadre pour que votre tableau de bord qualité réponde enfin à une seule question : qu'est-ce qu'on fait lundi matin ?

10 tests. Puis 30. Puis 300. Un pipeline qui dure 45 minutes, des flakes une fois sur cinq, et plus personne n'ose toucher à la suite de tests.

Si tu reconnais ce scénario, cet épisode est fait pour toi.

Je décortique l'un des problèmes les plus coûteux et les plus silencieux des équipes tech : la dette E2E. Pas pour te dire d'arrêter les tests end-to-end mais pour t'aider à les garder sous contrôle.

Au programme :

🔍 Pourquoi les E2E explosentLes 3 causes principales : les E2E utilisés comme béquille, des tests trop détaillés, et une dépendance à tout l'environnement. Résultat : une suite lente, fragile et bruyante.

🎯 Le bon rôle des tests E2EUn E2E n'est pas une preuve. C'est une alarme. Apprenez à définir votre "zone de confiance" : login, parcours principal, flux critiques et rien de plus.

📉 Réduire la surface E2EPourquoi une suite efficace tient souvent en 10 à 30 scénarios, et comment identifier les tests qui n'ont rien à faire en E2E grâce à une checklist simple.

⚡ 4 leviers pour des tests plus rapidesShift-left du flux, parallélisation, smoke vs full suite, bannir les sleeps : des pratiques concrètes pour récupérer un pipeline vivable.

🛠️ Traiter la fragilité à la racineSélecteurs instables, stratégie de données, asynchronisme, observabilité du test et une règle terrain : un test qui flake deux fois sort du pipeline bloquant.

Que vous soyez développeur, QA, tech lead ou engineering manager, cet épisode vous donne les outils pour remettre vos E2E à leur juste place dans votre stratégie de tests.