Leadership : cap, cohérence et confiance

Cette publication est l’épisode 6 sur 9 de la série « De la preuve à l’action — L’agilité incarnée ». Elle conserve la distinction de la source entre références établies, retours d’expérience anonymisés et cas pédagogiques simulés.

Les méthodes n’éliminent pas la responsabilité du leadership. Les équipes ont besoin d’un cap compréhensible, de contraintes explicites, d’un accès aux décisions et d’un environnement où les informations difficiles peuvent circuler. Lorsque les messages, les incitations et les comportements se contredisent, les pratiques agiles deviennent cérémonielles.

Cette partie traite deux conditions de crédibilité : relier le travail quotidien à une intention stratégique observable, puis réduire l’écart entre les valeurs déclarées et les pratiques effectivement récompensées. Le leadership est ici considéré comme un système de décisions et de comportements, pas comme une qualité réservée à un titre hiérarchique.

Chapitre 16 — Donner un cap sans prescrire la solution

De la stratégie au travail quotidien

Un cap utile permet de choisir. Il décrit le changement recherché, les personnes concernées, les contraintes et les preuves qui permettront d’apprendre. Il n’est ni un slogan général, ni une liste détaillée de fonctionnalités.

Dans Scrum, le Product Goal donne une cible de long terme au Scrum Team ; le Sprint Goal fournit l’objectif unique du Sprint et laisse de la souplesse sur le travail exact nécessaire pour l’atteindre. Ces engagements soutiennent l’empirisme, mais le Guide Scrum n’impose ni horizon standard ni format métrique unique.[2]

Rendre le cap testable sans le réduire à un chiffre

Une mesure aide à apprendre, mais un indicateur isolé peut être trompeur. Associer au moins un signal de résultat, un signal de qualité et une contrainte de risque limite les optimisations indésirables. Une formulation robuste peut suivre ce modèle :

Pour \[population\], nous pensons que \[intervention\] améliorera \[résultat\]. Nous l’évaluerons avec \[signaux\], sans dépasser \[contraintes\], avant \[date de revue\].

Exemple pédagogique

Au lieu de « améliorer l’expérience utilisateur », une équipe vise à permettre aux nouveaux utilisateurs d’achever seuls une tâche critique. Elle observe le taux d’achèvement, le temps nécessaire, les demandes d’assistance et les erreurs. Le seuil de décision est défini avant l’expérience ; il ne constitue pas une vérité universelle.

Le rôle du leadership

Le leadership clarifie les choix et les renoncements, garantit l’accès aux parties prenantes et protège l’espace d’apprentissage. Il évite de transformer un objectif en contrat figé lorsque de nouvelles informations invalident l’hypothèse. Inversement, l’autonomie ne dispense pas l’équipe d’expliquer ses décisions, de rendre le progrès transparent et d’escalader les risques qui dépassent son mandat.

Questions de revue

• Quelle décision cet objectif permet-il de prendre ou de refuser ?
• Quelle hypothèse relie le travail au résultat attendu ?
• Quelles données seraient susceptibles de nous faire changer d’avis ?
• Quels risques et effets secondaires surveillons-nous ?
• Qui décide de poursuivre, d’adapter ou d’arrêter ?

Chapitre 17 — Réduire l’écart entre discours et pratiques

Observer le système réel

Une organisation peut déclarer valoriser l’autonomie tout en exigeant des validations systématiques, promouvoir la transparence tout en sanctionnant les mauvaises nouvelles, ou encourager l’expérimentation tout en récompensant uniquement le respect du plan. La distinction entre théorie professée et théorie d’usage aide à examiner cet écart à partir de comportements observables plutôt que d’intentions supposées.[15]

Diagnostiquer sans procès d’intention

Le diagnostic s’appuie sur plusieurs traces : décisions récentes, critères de promotion, arbitrages budgétaires, réactions aux incidents, objectifs individuels et résolution des alertes. Une enquête déclarative seule mesure surtout ce que les personnes pensent pouvoir dire. Croiser entretiens, observations et données opérationnelles réduit ce biais.

Cas pédagogique — My Little Old Cie

La direction affirme que les équipes sont autonomes. L’examen de dix décisions récentes montre pourtant que huit ont nécessité une validation managériale non prévue. L’intervention ne consiste pas à accuser les managers : elle vise à expliciter les risques qu’ils cherchent à couvrir, puis à définir un mandat plus proportionné.

Protocole de réalignement

1. Choisir une valeur importante et la traduire en deux ou trois comportements vérifiables.
2. Examiner des décisions récentes pour repérer les règles et incitations contraires.
3. Désigner le niveau responsable de chaque contradiction.
4. Modifier un mécanisme concret : objectif, règle d’approbation, allocation de capacité ou rituel de revue.
5. Observer les effets pendant une période définie, y compris les risques déplacés.
6. Publier la décision de poursuivre, d’adapter ou d’abandonner.

Les dirigeants renforcent la crédibilité lorsqu’ils rendent visibles leurs propres hypothèses, reconnaissent une décision devenue inadéquate et expliquent ce qui change. Les équipes contribuent en formulant les alertes avec des faits, des conséquences et des options, plutôt qu’en réduisant le débat à l’adhésion ou à la résistance.

Critère de cohérence

Une valeur devient opérante lorsqu’elle influence les décisions sous contrainte : délai, budget, incident, désaccord ou pression commerciale.

Conclusion de l’acte II — Des obstacles aux leviers

L’écart entre connaissance et action est rarement imputable à une cause unique. Il résulte d’interactions entre raisonnements biaisés, mesures mal choisies, dépendances structurelles, latence décisionnelle et incohérences de leadership. Le diagnostic doit donc rester systémique et proportionné.

L’acte III transforme ces constats en leviers : expérimenter à petite échelle, aligner la structure sur l’intention stratégique, déléguer avec des garde-fous et créer les conditions d’une parole fiable. Chaque intervention sera traitée comme une hypothèse à éprouver, avec une situation initiale, une responsabilité, une durée et des critères de décision.

Sources

1. Manifesto for Agile Software Development, Kent Beck et al., 2001.

2. Le Guide Scrum, Ken Schwaber et Jeff Sutherland, version française, novembre 2020.

3. The Kanban Guide, Kanban Guides, mai 2025.

4. Evidence-Based Management Guide, Scrum.org, 2024.

5. Unskilled and unaware of it, Justin Kruger et David Dunning, Journal of Personality and Social Psychology, 1999.

6. Psychological Safety and Learning Behavior in Work Teams, Amy C. Edmondson, Administrative Science Quarterly, 1999.

7. Certified Tester Foundation Level — CTFL v4.0, ISTQB, page et syllabus officiels.

8. DORA metrics, DORA, guide officiel des indicateurs de performance de livraison logicielle.

9. Shape Up, Basecamp, ressource officielle en ligne.

10. Org Topologies — Mapping, Org Topologies, ressource officielle de cartographie.

11. The Kanban Guide for Scrum Teams, Scrum.org, guide officiel.

12. Turn the Ship Around!, L. David Marquet, page officielle de l’ouvrage.

13. Managing the Development of Large Software Systems, Winston W. Royce, actes IEEE WESCON, 1970.

14. Problems of Monetary Management: The U.K. Experience, Charles A. E. Goodhart, 1975.

15. Theory in Practice: Increasing Professional Effectiveness, Chris Argyris et Donald A. Schön, 1974.

16. Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin et Janet Gregory, Addison-Wesley, 2009.

17. Thinking, Fast and Slow, Daniel Kahneman, Farrar, Straus and Giroux, 2011.