Structures organisationnelles et flux

Cette publication est l’épisode 5 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.

Une équipe peut maîtriser ses pratiques locales et rester lente à l’échelle du système. Dès qu’une évolution traverse plusieurs files d’attente, domaines d’expertise ou niveaux de validation, l’optimisation de chaque unité ne suffit plus : le délai dépend surtout des dépendances et du temps d’attente entre elles.

Cette partie examine deux sources fréquentes de friction : les silos fonctionnels et la concentration des décisions. L’objectif n’est pas de promouvoir un organigramme universel. Une structure doit être appréciée au regard de la stratégie, du niveau de risque, des compétences disponibles et de la nature du travail. Le critère professionnel est sa capacité à permettre un flux de valeur maîtrisé, des responsabilités explicites et des décisions prises au bon niveau.

Question directrice

Quelles contraintes de structure empêchent aujourd’hui une équipe de transformer rapidement une intention en résultat observable, sans dégrader la qualité ni la maîtrise des risques ?

Chapitre 14 — Silos fonctionnels : fragmentation du flux

Pourquoi les silos persistent

Regrouper les personnes par spécialité peut développer l’expertise, faciliter le partage de pratiques et mutualiser des moyens rares. Cette logique devient toutefois coûteuse lorsque la majorité des demandes traverse plusieurs unités dont les priorités, les budgets et les indicateurs diffèrent. Le problème n’est donc pas l’existence d’expertises ; c’est l’absence de mécanisme permettant de les coordonner autour d’un résultat commun.

Cas pédagogique — My Little Old Cie

Le cas est entièrement composite. Une évolution client mobilise successivement produit, développement, test, sécurité et exploitation. Chaque groupe réalise rapidement sa tâche, mais l’élément attend entre les files. Le délai total augmente alors même que chaque unité paraît « occupée » et performante.

Lire le système plutôt que les unités

Une forte utilisation individuelle peut allonger le délai global : lorsqu’aucune capacité n’absorbe les variations, chaque transfert crée une file. Il est donc préférable de suivre le temps écoulé, le temps actif, le travail en cours, les blocages et les reprises plutôt que de conclure à partir d’un taux d’occupation isolé. Aucun seuil universel de « bonne » efficacité de flux ne remplace une comparaison avec la situation initiale et le contexte.

Options de conception

Trois familles d’intervention peuvent être combinées :

• Réduire les transferts en constituant une équipe capable de livrer un incrément de bout en bout sur un périmètre de valeur cohérent.
• Rendre les dépendances explicites lorsque certaines compétences doivent rester partagées : règles de service, capacité réservée, délais attendus et ordre de priorité commun.
• Créer des capacités de plateforme ou d’habilitation pour que les équipes consomment un service réutilisable sans négociation au cas par cas.
• Revoir les objectifs et les indicateurs afin que les fonctions ne soient pas récompensées pour un résultat local contraire au résultat global.

La cartographie proposée par Org Topologies distingue notamment des configurations orientées ressources, livraison et adaptation. Elle sert à rendre visibles les compromis entre profondeur d’expertise, débit et capacité d’adaptation ; elle ne prescrit pas un modèle unique.[10]

Expérimentation recommandée

1. Choisir un type de demande représentatif et reconstituer ses étapes réelles.
2. Mesurer le délai total, le temps actif, les attentes, les retours en arrière et les décisions externes.
3. Identifier une dépendance dominante, puis tester pendant quatre à six semaines une modification limitée : capacité dédiée, nouvelle règle de service ou équipe temporairement élargie.
4. Comparer les données avant/après et recueillir le point de vue des clients internes et externes.
5. Conserver, adapter ou abandonner l’intervention selon les résultats.

Point de contrôle

Une réorganisation n’est pas une fin en soi. Elle est utile si elle réduit une contrainte mesurée, clarifie les responsabilités et améliore un résultat sans déplacer silencieusement le risque ailleurs.

Chapitre 15 — Hiérarchie, contrôle et délai de décision

Le véritable enjeu : placer la décision au bon niveau

Une hiérarchie apporte de la responsabilité, une capacité d’arbitrage et des garde-fous utiles. Elle devient une contrainte lorsque des décisions fréquentes, réversibles et proches du travail suivent le même circuit que des décisions rares, irréversibles ou réglementées. L’objectif n’est pas de supprimer le contrôle, mais de proportionner le niveau d’approbation au risque.

Cartographier la latence décisionnelle

Pour une décision récurrente, documenter la demande, le décideur, les consultations nécessaires, le délai attendu et la règle d’escalade. Le temps entre « décision nécessaire » et « décision obtenue » devient alors observable. Trois symptômes méritent une attention particulière : approbations en série, dossiers produits sans usage démontré et décisions remontées faute de mandat clair.

Déléguer de manière vérifiable

Une délégation professionnelle précise :

• le résultat recherché et les contraintes non négociables ;
• le périmètre dans lequel l’équipe décide seule ;
• les informations à partager avant ou après la décision ;
• les conditions qui imposent une consultation ou une escalade ;
• la date de révision de l’accord.

La délégation peut progresser par paliers : d’abord proposer, puis décider avec consultation, enfin décider et informer. Le chapitre 20 détaille cette logique à travers le leadership par l’intention.

Réduire la bureaucratie sans affaiblir la maîtrise

Toute règle devrait avoir un propriétaire, une justification, un coût d’exécution et une date de réexamen. Les exigences de conformité ne sont pas facultatives ; leur mise en œuvre peut toutefois être simplifiée, automatisée ou intégrée au flux. Supprimer une étape parce qu’elle ralentit le travail serait imprudent si elle prévient un risque matériel. La bonne question est : « quelle preuve ce contrôle produit-il, et existe-t-il une manière plus rapide d’obtenir une assurance équivalente ? »

Mesures utiles

Délai médian de décision, dispersion de ce délai, nombre d’approbations, part des décisions escaladées, taux de retours pour dossier incomplet et incidents associés aux décisions déléguées.

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.