Gérer les conflits avec les devs, les PMs et les POs : méthodes concrètes
Cet article est le 3e d'une série de 5 consacrée au Test Lead moderne : influence, légitimité et leadership sans hiérarchie. Après avoir posé le cadre de l'influence sans autorité et exploré l'art du reporting stratégique, on aborde aujourd'hui le terrain le plus inconfortable du rôle : le conflit ouvert.
Vous bloquez une release parce qu'un risque vous semble trop élevé. Le PO vous répond que le planning a été annoncé au client et qu'il n'est pas négociable. Le développeur, lui, vous explique que ce que vous appelez un bug est en réalité un comportement attendu que vous n'avez pas compris. Et le delivery manager, au milieu, attend que vous trouviez un terrain d'entente et vite.
Bienvenue dans la partie du métier qu'aucune formation technique ne prépare vraiment : le conflit. Pas le conflit de personnalité, le conflit de lecture du risque. Et c'est précisément là que l'influence sans autorité est mise à l'épreuve la plus dure, parce qu'un Test Lead ne peut pas trancher par décret. Il doit convaincre, ou accepter de perdre l'arbitrage, proprement.
Le conflit n'est pas un échec de communication, c'est un désaccord légitime
La première erreur, fréquente chez les Test Leads qui débutent dans le rôle, est de considérer tout désaccord comme un problème à éliminer au plus vite, par peur de l'escalade ou par envie de préserver une relation de travail agréable. Cette approche produit l'effet inverse de celui recherché : à force d'éviter le désaccord, on finit par taire des risques réels, et le conflit explose plus tard, avec plus de dégâts.
Un conflit bien géré n'est pas un conflit qui disparaît. C'est un conflit qui se transforme en décision claire, assumée, et documentée, que cette décision aille dans votre sens ou non. Le PM, le dev, le PO n'ont pas tort par principe de défendre leur position : ils ont des contraintes, un planning, une pression client, une compréhension différente du produit. Votre rôle n'est pas de les avoir tort. Votre rôle est de vous assurer que la décision finale est prise en pleine connaissance du risque.
Avec les développeurs : sortir de la posture accusatoire
Le conflit avec un développeur prend presque toujours la même forme : vous remontez un défaut, il le conteste, soit en niant que ce soit un bug, soit en minimisant son impact, soit en expliquant que ce n'était pas dans le scope de ce qu'il devait livrer.
La tentation, dans ce moment, est de défendre votre position en insistant sur le fait que c'est bien un bug. C'est rarement le bon levier. La discussion technique sur la définition d'un bug est un terrain glissant où chacun a ses arguments, et où vous perdez en crédibilité si vous campez sur une position qui ressemble à un combat d'ego.
Le déplacement qui fonctionne consiste à sortir du débat sémantique pour entrer dans le débat d'impact. Plutôt que d'argumenter sur la nature du défaut, montrez ce qu'il produit pour l'utilisateur final, avec un scénario concret. Un développeur qui conteste qu'un comportement soit un "bug" cesse généralement de contester quand vous lui montrez la séquence exacte d'actions qui mène à une perte de données ou à un blocage utilisateur. Ce n'est plus une opinion contre une autre. C'est un fait observable.
Et quand le développeur a raison, que ce que vous pensiez être un défaut est effectivement un comportement voulu, reconnaissez-le immédiatement, sans round de négociation inutile. C'est exactement ce type de moment qui construit votre crédibilité sur la durée : un Test Lead qui sait reconnaître ses erreurs techniques est un Test Lead qu'on croit quand il insiste sur un vrai problème.
Avec les PMs et les POs : traduire le risque en langage business
Le conflit avec un PM ou un PO prend une forme différente. Il ne porte presque jamais sur la réalité d'un bug mais il porte sur la priorité qu'on lui accorde face à un planning, un engagement client, ou une pression commerciale. C'est un conflit d'arbitrage, pas un conflit de fait.
C'est précisément le terrain où l'erreur classique consiste à insister sur la gravité technique du problème, alors que votre interlocuteur raisonne en termes de delivery et de risque business. Dire "c'est un bug critique" à un PO obsédé par une date de livraison contractuelle ne produit presque jamais l'effet voulu, parce que vous ne parlez pas le même langage.
La méthode qui fonctionne reprend le réflexe du "traducteur de risque" évoqué dans le premier article de cette série : reformulez systématiquement votre alerte en conséquence business, et associez-y toujours une option, jamais un blocage sec. "Si on livre en l'état, voici le scénario probable côté client et voici deux options pour réduire ce risque sans décaler la date." Cette formulation change la nature de l'échange : vous n'êtes plus celui qui bloque, vous êtes celui qui éclaire une décision difficile. Le PO garde l'autorité de trancher. Vous gardez votre influence sur la qualité de cette décision.
Un point souvent négligé : documentez systématiquement votre alerte, même quand elle est entendue et suivie. Pas pour vous couvrir dans une logique défensive, mais parce que cette trace devient, avec le temps, la preuve tangible de la valeur que vous apportez, c’est exactement la matière de votre reporting stratégique évoqué dans l'article précédent.
Quand le conflit ne se résout pas : l'escalade qui ne casse rien
Il arrive, malgré une argumentation solide et une formulation business impeccable, que le désaccord persiste. Le PO maintient sa décision malgré le risque que vous avez identifié. Que faire, quand vous n'avez pas d'autorité pour imposer votre lecture ?
La réponse n'est pas le silence résigné, ni l'escalade frontale qui braque tout le monde. C'est l'escalade documentée et neutre : vous remontez le sujet au niveau supérieur (delivery manager, direction produit) sans accuser personne, en présentant simplement les faits, le risque identifié, et la décision prise en connaissance de cause. Vous ne dites jamais "le PO a refusé de m'écouter". Vous dites : "voici le risque identifié, voici la décision prise, je voulais m'assurer qu'elle est bien remontée au bon niveau."
Cette formulation protège la relation avec le PO : vous ne le dénoncez pas, vous informez. Et elle protège votre crédibilité : si le risque se matérialise, votre alerte est tracée et vous n'aurez pas à dire "je vous l'avais dit" : ce qui serait une erreur relationnelle même si vous aviez raison. Si le risque ne se matérialise pas, vous n'aurez fait de mal à personne en ayant simplement fait votre travail correctement.
La règle qui change tout : séparer la personne du problème
Tous ces cas de figure reposent sur un principe unique, souvent répété en théorie de la négociation mais rarement appliqué sur le terrain QA : séparer systématiquement la personne du problème. Le développeur n'est pas "celui qui ne comprend rien à la qualité". Le PO n'est pas "celui qui sacrifie tout pour le planning". Ce sont des personnes avec des contraintes différentes des vôtres, qui défendent une position légitime depuis leur poste.
Tant que vous attaquez la position et jamais la personne, le conflit reste un désaccord professionnel qui peut se résoudre par les faits. Dès que la discussion glisse vers le jugement de la personne , même implicitement, dans le ton ou le choix des mots, le conflit devient relationnel, et il devient beaucoup plus difficile à désamorcer, parce qu'il touche à l'ego plutôt qu'aux faits.
Ce que le conflit révèle vraiment
Un Test Lead qui ne vit jamais de conflit n'est probablement pas en train d'exercer une réelle influence, il valide silencieusement tout ce qu'on lui propose. Le conflit, géré proprement, n'est pas un signe d'échec relationnel. C'est le signe que vous portez une position qui compte suffisamment pour être discutée.
Le prochain article de cette série s'appuiera directement sur tout ce qui précède pour aborder un livrable central du métier : comment construire un diagnostic QA qui convainc réellement, plutôt qu'un rapport qu'on archive sans lire.
Vous voulez vous entraîner à gérer ces situations de conflit avant qu'elles ne se présentent en vrai ? C'est l'un des piliers du Bootcamp Leader QA.
Inscrivez-vous pour être informé des prochaines sessions : https://shiftopsolutions.systeme.io/devenirleadqa