A presentation at DevQuest Niort 2026 in in 79000 Niort, France by KLAUK FANNY
TechLeads : arrêtez de répondre. Commencez à questionner ! © Aggretsuko
Y a-t-il des TechLeads dans la salle ? © Aggretsuko
© Aggretsuko
On connait le code. On connait l’historique. On connait les pièges. On connait les interlocuteurs. On sait débloquer vite. On devient un point de blocage. © Aggretsuko
Debugging Architecture Produit Coordination Mentoring Gestion de crise S.P.O.F. © Aggretsuko
© Aggretsuko
Répondre trop vite Mon code ne marche pas, tu peux regarder ? Ah oui, ton problème vient de ton pom.xml ! Dette de dépendance Quand il y a un problème, viens me voir. Je réfléchirai à ta place. © Aggretsuko
Répondre trop vite Mon code ne marche pas, tu peux regarder ? Ah oui, ton problème vient de ton pom.xml ! Dette de dépendance Quand il y a un problème, viens me voir. Je réfléchirai à ta place. © Aggretsuko
Mon code ne marche pas, tu peux regarder ? Qu’est-ce que tu as déjà testé? Quelles hypothèses fais-tu ? Relance de la réflexion Si tu me sollicites, on se basera sur ta réflexion. © Aggretsuko
Questionnement puissant « Pourquoi tu as fait ça ? » Besoin de se défendre « Qu’est-ce qui t’a amené à ce choix ? » Besoin de réfléchir © Aggretsuko
Réfléchir = Chercher une hypothèse Engager sa mémoire, son expérience Apprendre Construire un raisonnement Développer son autonomie © Aggretsuko
Réfléchir = Chercher une hypothèse Engager sa mémoire, son expérience Apprendre Construire un raisonnement Développer son autonomie Les interruptions diminuent L’équipe monte en compétence Les décisions deviennent collectives L’équipe scale réellement. © Aggretsuko
Clarification « Que veux-tu résoudre exactement ? » « Quel est le comportement attendu ? » « Depuis quand ça arrive ? » Exploration « Qu’as-tu déjà testé ? » « Quelles hypothèses fais-tu ? » « Quelles options vois-tu ? » Responsabilisation « Quelle option te semble la meilleure ? » « Pourquoi ? » « Quel risque vois-tu ? » © Aggretsuko
Mon code ne marche pas, tu peux regarder ? Clarification « OK, qu’est-ce qu’on sait exactement ? » « Est-ce qu’on parle de la totalité de l’application ou d’un composant ? » Exploration « As-tu déjà une piste ? » « Qu’as-tu trouvé ?» Responsabilisation « Quelle serait la prochaine piste à suivre ? » « Quelle possibilité préfères-tu entre les deux ? » © Aggretsuko
Limites & obstacles du questionnement puissant A éviter lors d’incident critique Attention aux interlocuteurs / interlocutrices très juniors L’investissement nécessaire L’inconfort du changement des règles du jeu Cela demande de la pratique © Aggretsuko
Contre-exemples du questionnement puissant Réduire le champ des possibles avec des questions fermées : « ce n’est pas la base de données qui est mal indexée ? » Orienter la réponse dans la question : « tu ne penses pas qu’on devrait faire un bus d’évènements dans ce cas précis ? » Fausser les questions ouvertes : « Qu’est-ce qu’on pourrait refaire, à part refactorer ? » Poser des questions Google / ChatGpt : « tu as regardé la doc ? » Mitrailler de questions Manipuler pour se défausser © Aggretsuko
Avoir les réponses Construire une équipe autonome © Aggretsuko
Dans le rôle de Retsuko : Fanny KLAUK Accompagnatrice agile & DevOps Formatrice - TechLead Co-créatrice de fanny-klauk klf37 https://klaukf.github.io/blog/ © Aggretsuko
On attend du Techlead qu’il sache.
On vient le voir pour chaque décision : relecture de code, décision d’architecture, arbitrage produit, debug complexe, médiation d’équipe… Et plus il est compétent, plus il est sollicité !
Le paradoxe ? Sa valeur crée sa surcharge.
Et si le rôle du TechLead n’était pas d’avoir les meilleures réponses… mais de poser les meilleures questions ?
Le questionnement puissant est une compétence centrale en coaching mais quasiment absente de la culture technique.
Alors permettez-moi de vous offrir cet angle nouveau qui pourrait vous permettre de :
Un sujet pour celles et ceux qui veulent faire grandir leur impact sans s’épuiser.
