La majeure partie du micro-management n’est pas un problème de contrôle : c’est un échec de clarté déguisé.

Stop Telling Professionals How to Do Their Job — Commander’s Intent at Work par Stefan Wolpers

Cet article présente l’Intention du Commandant : un modèle de briefing en cinq parties qui remplace les instructions prescriptives par un objectif commun, des contraintes strictes et une marge d’adaptation.

On n’embauche pas des gens intelligents pour leur dire quoi faire.

Dans des environnements complexes, la performance dépend moins d’instructions détaillées que d’une intention claire, de contraintes strictes et d’espace d’adaptation.

Vous avez engagé des gens intelligents. Ensuite, vous leur avez écrit un scénario.

Le Sprint Backlog est rempli de tâches décomposées à l’heure près. Les critères d’acceptation ressemblent à des instructions pour assembler les meubles. Le Daily Scrum devient un rituel de reporting pour des personnes extérieures à l’équipe. L’organisation, la seule chose qui rend le travail de connaissance productif, disparaît avant même que le Sprint ne commence.

La plupart des praticiens Agile reconnaissent cela comme du micro-management. Moins comprennent pourquoi cela arrive.

Le vrai problème n’est pas le contrôle.

Le micro-management peut être un délire de pouvoir, mais la plupart du temps, c’est un échec de clarté déguisé en contrôle.

Les managers prescrivent des méthodes et des résultats parce qu’ils ne font pas confiance à ce que l’intention soit suffisamment comprise. Les gens du produit surspécifient parce qu’ils craignent que le résultat réel soit ambigu. La personne qui donne les instructions ne parvient pas à exprimer ce que signifie « bien », alors elle dicte les étapes à la place.

Cette approche n’est pas un défaut de caractère. C’est une défaillance systémique : une tentative de fabriquer la certitude en verrouillant une méthode dans des conditions où le résultat lui-même reste incertain. Dans des environnements complexes, cette approche échoue de manière prévisible. La méthode commence à se dégrader dès que les conditions changent, et dans les travaux complexes, elles restent rarement immuables.

Il existe un meilleur modèle. Il s’appelle Commander’s Intent.

Que signifie l’intention du commandant ?

L’intention du commandant est simple en concept :

Communiquez l’état final souhaité, ses contraintes et le but de la mission. Puis faites confiance aux personnes qui font le travail pour déterminer comment y parvenir, s’adaptant au changement des conditions.

Cette approche ne vise pas à militariser le travail. C’est plutôt l’inverse : décentralisez l’exécution parce que le centre ne dispose jamais d’assez d’informations dans des conditions complexes.

Et ce n’est pas du théâtre d’autonomisation. L’Intention du Commandant est très précise là où elle compte et relâchée là où elle doit l’être. La différence avec le micro-management n’est pas moins de leadership, mais un leadership différent : une réflexion plus intense au départ, une communication plus claire et une retenue délibérée sur la méthode.

Un briefing utile basé sur l’intention du commandant comporte 5 parties :

1. Résultat : À quoi ressemble « fait (done) » ?
2. But : Pourquoi cela est-il important maintenant ? Qu’est-ce qui est en jeu ?
3. Contraintes : Qu’est-ce qui est non négociable ?
4. Critères de réussite : Comment allons-nous mesurer ?
5. Déclencheurs d’escalade : Quels signaux devraient inciter à une conversation plutôt qu’à une décision unilatérale ?

Cette structure donne aux équipes suffisamment de contexte pour s’adapter intelligemment lorsque la réalité brise le plan.

Pourquoi les équipes Agiles en ont besoin.

Scrum est conçu pour cette réalité : dans un travail complexe, l’adaptation dépend du jugement local. Le Product Owner apporte une clarté sur la valeur, les résultats souhaités et les priorités. Les développeurs décident comment transformer cette intention en un incrément fonctionnel. L’équipe Scrum s’autogère dans ces limites.

Le Scrum Guide 2020 a explicitement rendu cet engagement structurel : l’objectif de Sprint (Sprint Goal) est l’engagement pour le Sprint Backlog, et il « offre de la flexibilité quant au travail exact nécessaire pour l’atteindre ». Le Sprint Goal est l’analogue le plus proche du Commander’s Intent, mais il ne fonctionne que lorsque l’équipe comprend aussi son but, les contraintes qui l’entourent et l’espace pour s’adapter.

En supprimant cette compréhension, on obtient le Scrum Theater : une équipe qui exécute les tâches, attend l’approbation et livre exactement ce qui a été spécifié, même lorsque la réalité a déjà évolué.

Chaque coach expérimenté a vu cela se produire : une partie prenante importante dicte les détails de la mise en œuvre, et l’équipe cesse de réfléchir pour se concentrer sur être payée. La partie prenante n’a pas le contexte nécessaire pour prendre de bonnes décisions. Le même schéma se répète : l’intention floue est remplacée par une méthode prescriptive.

La même erreur, un nouvel outil.

La raison pour laquelle ce principe est important au-delà de Scrum est simple : il s’applique chaque fois que l’exécution se fait plus proche de la réalité que la planification.

Considérez combien de personnes interagissent avec les agents IA : des requêtes qui ressemblent à des tickets Jira infusés de Gherkin, avec des instructions étape par étape, un format de sortie fixe et chaque paragraphe dicté à l’avance.

Comparez 2 approches :

1. Prescriptif : « Rédigez un article de blog de 500 mots. Utilisez trois en-têtes. Commencez par une définition de l’agilité. Incluez une liste à puces de cinq avantages. Terminez par un appel à l’action. »
2. Basé sur l’intention : « J’ai besoin d’un billet qui mette au défi les Scrum Masters d’arrêter de confondre la conformité aux processus avec l’agilité réelle. Le public connaît le cadre. Le ton doit être direct et inconfortable. »

Le premier prompt est plus susceptible de produire un résultat générique. Le second est plus susceptible de produire quelque chose qui vaut la peine d’être lu. Cela ne signifie pas que la structure est mauvaise. Cela signifie que sur-spécifier une méthode devient contre-productif lorsque la tâche nécessite du jugement ou une adaptation.

Le schéma est le même dans les deux cas : lorsqu’un avis est requis, la clarté de l’intention combinée à la latitude dans l’exécution l’emportent sur un script trop spécifié.

La compétence d’intention du commandant.

Si vous travaillez avec Claude, vous pouvez mettre en pratique l’Intention du Commandant dès maintenant. J’ai créé une « Commander’s Intent skill » gratuite qui s’exécute comme une couche invisible de pré-exécution sur chaque tâche que vous envoyez.

Au lieu de vous demander d’écrire des instructions détaillées, il identifie quand votre intention est floue et pose les bonnes questions avant d’exécuter, tout comme le ferait un collègue avisé. Quand votre intention est déjà claire, il s’efface et produit le résultat. Téléchargez la Commander’s Intent skill et voyez la différence entre dicter la méthode et communiquer l’intention : Téléchargez le Claude Skills Pack .

Conclusion : L’intention du commandant est le modèle opérationnel.

La prochaine fois que vous rédigez un objectif de Sprint, demandez-vous :

Transmet-il l’intention, ou est-ce qu’il dicte la méthode ?

Dans les systèmes complexes, le leader qui dicte la méthode devient le goulot d’étranglement. Le leader qui clarifie l’intention crée les conditions pour l’adaptation.

¹ L’intention du commandant est enracinée dans la tradition prussienne de l’Auftragstaktik (tactiques par type de mission) : les leaders communiquent leur objectif et l’état final désiré, tandis que les leaders subordonnés conservent la liberté d’exécution en fonction des circonstances.