Penser l'organisation comme un système

Article

Introduction

On reparle encore de frameworks. SAFe, LeSS, Spotify, microservices, product ownership, agile coaching. Chaque année, une nouvelle mode arrive avec sa certification, son vocabulaire, ses patterns. Et chaque année, des centaines d'organisations investissent dans l'implémentation de ces modèles. Puis elles déchantent.

Voici ce que j'ai observé en pilotant ou accompagnant une quinzaine de transformations agiles à l'échelle : l'enjeu n'est jamais le framework. C'est le système que vous manipulez en y greffant ce framework.

Un organigramme, c'est une vue statique. Une liste de cases, une hiérarchie, des reportings. On peut la redessiner en une semaine. Le système, c'est ce qui circule dedans, l'information, les décisions, les feedbacks, la confiance, l'apprentissage, les compensations tacites qui permettent aux choses de tenir. Ce système est vivant, il a une inertie, des mémoires, des patterns de réaction au stress. Et contrairement à ce que proposent les consultants, on ne peut pas le reconfigurer comme on décide de réorganiser les boîtes.

C'est pour cela que deux organisations peuvent implémenter le même SAFe avec succès l'une et catastrophe l'autre. Ce n'est pas que l'une a un meilleur coach. C'est que leurs systèmes de départ, et leur capacité à lire leurs signaux et à en adapter l'approche, diffèrent profondément.

Je vous dis cela sans crédulité. Je dis aussi, si vous comprenez votre organisation comme un système, vous cessez d'attendre du framework qu'il vous sauve. Vous commencez à observer. À apprendre. À arbitrer.

L'organisation est un système, pas un organigramme

Quand on parle d'une transformation agile, ce qu'on vise est souvent énoncé simplement, "passer de la waterfall à l'agile, mettre en place des sprints, former les équipes, mettre à plat la hiérarchie".

Ce langage est tentant. Il donne l'illusion qu'on pilote un graphe. On change les liaisons, on redéfinit les rôles, les flows sortent mécaniquement améliorés.

Sauf que ce n'est pas une machine. C'est un système.

Un système a des propriétés émergentes qui ne sont pas réductibles à la somme des parties. Trois équipes de quatre personnes ne se comportent pas comme une équipe de douze. Une culture d'autonomie n'émerge pas parce qu'on supprime deux niveaux hiérarchiques. La confiance ne surgit pas parce qu'on lance une rétrospective.

Prenez un exemple concret qu'on rencontre partout. Un groupe pharmaceutique a décidé de passer ses équipes IT à Scrum. Trois mois après le lancement officiel de la transformation, les sprints fonctionnent, on a des dailys, des plannings, des démos. Les charts de burn-down sont aux murs. Mais rien ne s'accélère. Les délais ne descendent pas. Les équipes sont sans doute plus synchronisées, mais pas plus efficaces.

Pourquoi, parce que personne n'a changé le système de validation des conteneurs applicatifs. La gouvernance de sécurité impose toujours six signatures avant un déploiement. Les équipes Scrum peuvent pédaler comme des dingues pendant deux semaines, le système en amont les arrête net.

Ce n'est pas un problème de Scrum. C'est un problème systémique. Les boucles de feedback ne ferment pas. L'équipe apprend que ses efforts ne débouchent pas sur un résultat. Elle recalcule ses attentes. Elle ralentit. Elle cesse de chercher à s'accélérer.

Voilà ce que les approches "reconfigurer l'organigramme et appliquer le framework" ratent, elles traitent l'organisation comme un graphe dirigé. On renumérote les nœuds, on redessine les arêtes, et magiquement les flux s'améliorent. Sauf que les vraies dépendances, les feedbacks, les accumulateurs de décisions, les rôles tacites, les coalitions invisibles, restent intactes.

Apprendre à voir l'organisation comme un système, c'est apprendre à voir ce qui ne figure pas sur l'organigramme.

Les boucles de feedback qui font ou défont une transformation

Un système vit par ses boucles de rétroaction. Elles amplifient ou amortissent les perturbations. Elles créent les équilibres. Elles dictent ce qui est appris et ce qui est oublié.

La boucle équipe vers management. Une équipe formule un problème, le sprint est ralenti par des approbations métier tardives. Si ce feedback monte rapidement vers qui peut agir et que le problème est résolu dans la semaine, l'équipe apprend qu'elle peut influencer son environnement. Elle est motivée à en formuler d'autres. Le système se corrige lui-même. Mais si le feedback s'enlise, s'il est renvoyé au service messaging, s'il meurt dans une réunion de gouvernance, l'équipe apprend le silence. Elle n'essaiera plus. La boucle se ferme, mais en amortissant, pas en renforçant.

C'est banal, mais c'est le levier le plus souvent ignoré. La plupart des transformations agiles à l'échelle échouent non parce que les frameworks sont mal implémentés, mais parce que le chemin du feedback équipe-vers-leadership est obstrué. Trop d'étapes. Trop d'interprétation. Trop de silence.

La boucle client vers produit. L'équipe livre une feature. Les données d'utilisation montrent que personne ne l'utilise. Ce signal doit revenir à l'équipe de production. Si elle l'apprend, elle corrige ou retire. Si le signal ne monte pas, parce que la métrique reste cachée, ou parce qu'il faut trois comités pour décider de la retirer, alors l'équipe accumule des features mortes. Elle apprend progressivement que son jugement n'a pas d'importance, que la décision est ailleurs.

La boucle dette technique vers vélocité. Chaque feature qu'on coupe les coins pour finir à temps ajoute une petite dette. Seule, c'est rien. Mais accumulée, cette dette ralentit le code. Les tests ralentissent. Les builds ralentissent. Les déploiements ralentissent. La vélocité baisse. On réduit la complexité pour rester rapide ? Non, on la repousse. La dette explose. Puis un jour la vélocité s'effondre, quatre mois pour faire ce qui se faisait en trois semaines avant.

Cette boucle s'amplifie. Ce n'est pas qu'il y a trop de dette. C'est qu'il n'y a aucun signal de retour qui aurait permis de l'arrêter à temps.

La boucle culture vers attractivité. Si votre culture est un vrai endroit où on peut apprendre et où on est traité en professionnel, les bons candidats arrivent, restent, et parlent de la boîte. De bons profils supplémentaires arrivent. La culture se renforce. À l'inverse, si la culture est de l'héroïsme usé, du micromanagement, des réunions inutiles, les meilleurs s'en vont et parlent. Les nouveaux arrivent moins bons. Ils déchantent plus tôt et partent eux aussi. Vous n'avez plus d'attractivité.

Chacune de ces boucles fonctionne ou ne fonctionne pas. Et c'est cela qui détermine si votre transformation tient ou si elle s'érode.

Les signaux faibles que personne ne lit

Avant que ça casse, il y a toujours des signaux. Ils sont petits, diffus, faciles à ignorer. Et la plupart des leaders les ratent.

Le turnover augmente légèrement. Pas dramatique. Pas une démission spectaculaire. Juste une bonne recrue qui s'en va discrètement après neuf mois. Puis une autre. Puis un ingénieur senior que vous pensiez heureux. Ceux qui partent ne disent rien publiquement. Mais votre meilleur vivier s'érode.

Les questions en réunion raccourcissent et deviennent moins pertinentes. Avant, l'équipe challengeait les décisions, posait de vraies questions. Maintenant, c'est "OK, on fait comme prévu". Les gens n'interrogent plus le cadre. Ça veut dire quoi, que le système d'apprentissage s'est fermé. Personne ne croit plus qu'il vaut le coup de proposer une alternative.

Les rétrospectives s'écourtent. Elles ne durent plus une heure et demie avec tension créative, elles durent quarante-cinq minutes et tout le monde veut partir. Ça paraît normal. Mais c'est un signal, le groupe a cessé de croire qu'il peut s'améliorer. Ou il croit qu'on ne l'écoutera pas.

Les escalades qui devaient mordre se résolvent mollement. Un problème de planning croise une limite budgétaire. Avant, on aurait vu du bras de fer, une décision nette, pas forcément sympathique, mais claire. Maintenant, tout le monde roule des yeux et le problème part en mort-vivant pendant trois mois. Ça veut dire, le système de décision a arrêté de fonctionner. Personne ne veut trancher vraiment.

Ces signaux sont subtils. Un RH n'en verra aucun sur un compte rendu de turnover. Un consultant externe sera ébloui par la mise en place de Scrum bien peignée. Mais un manager qui passe du temps dans les équipes les voit immédiatement.

Le problème est qu'on n'a pas de dashboard de signaux faibles. Il n'y a pas de KPI du système qui s'érode. Il y a des métriques visibles (burn-down, vélocité, leadtime) et il y a le silence. Et le silence, c'est ce qui vous tue.

Apprendre à les lire veut dire apprendre à écouter d'abord. Passer du temps dedans. Poser les vraies questions en rétro. Suivre qui s'en va et pourquoi. Demander à un ingénieur senior pourquoi ses questions se sont taries.

La dette organisationnelle, le vrai sujet

On parle beaucoup de dette technique. C'est visible. On la mesure. Un test qui n'existe pas, une dépendance circulaire, un secret en dur, ça se voit. Et on sait que ça ralentit le code.

La dette organisationnelle est invisible. Et elle est plus coûteuse.

C'est ce qui s'accumule sans qu'on n'en parle, les processus inutiles qui ont prospéré en réaction à une crise oubliée. La signature supplémentaire qu'on a ajoutée pour être sûr. Le comité de validation qu'on a créé juste au cas où. Le rôle flou qui n'apporte plus rien. La réunion bihebdomadaire qui a longtemps servi à quelque chose et qui continue par inertie. Les décisions qu'on repousse semaine après semaine parce qu'elles sont inconfortables.

Cette dette s'accumule rapidement. Après cinq ans, vous avez trois couches d'approbations qui n'ont plus de sens. Vous avez des rôles en doublon. Vous avez des réunions qui tuent votre calendrier. Vous avez des décisions qui prennent des mois.

Et la vraie question de l'organisation, ce n'est plus comment on fait une bonne feature. C'est comment on navigue la bureaucratie interne pour avoir le droit de faire la feature.

Voilà où la plupart des transformations agiles s'enlisent, on a implémenté Scrum dans l'équipe produit, mais on a laissé la dette organisationnelle grandir autour.

La différence entre une organisation qui apprend et une qui s'érode, c'est simple. La première met de l'énergie à nettoyer la dette organisationnelle. Pas une fois tous les quatre ans avec une réorg complète (qui crée généralement plus de dette qu'elle n'en résout). Mais régulièrement. Chaque trimestre, quelqu'un demande "cette signature a-t-elle un sens, cette réunion apporte-t-elle vraiment quelque chose, peut-on tuer ce comité". Et on agit.

La seconde, elle laisse la dette croître. Elle attend qu'une crise la force à réorganiser. Et quand ça arrive, elle réorg violemment. Elle crée du chaos temporaire. Et six mois après, la même dette revient.

Les bifurcations, quand l'organisation bascule

Il y a des moments dans la vie d'une organisation où un changement mineur a un effet disproportionné. C'est ce qu'on appelle en dynamique des systèmes une bifurcation. Le système hésite entre deux états. Et un événement, une décision, une petite action peut le basculer.

Souvent, on ne les reconnaît pas. C'est pour ça qu'on dit après coup "c'est là que tout a commencé à déraper".

Le départ d'un DG, un nouveau CTO pour qui le produit ça compte, une fusion, la perte d'un grand client. Un changement de gouvernance. Une décision de licencier pour économies ou l'inverse, une levée de fonds. L'arrivée d'un concurrent direct. Un scandale interne public.

À ce moment-là, le système est fragile. Il peut basculer vers un apprentissage meilleur ou vers une fermeture défensive. Vers plus d'autonomie ou vers plus de contrôle. Vers une plus grande transparence ou un retranchement.

La plupart des leaders ne le voient pas comme ça. Ils voient une décision qui doit être prise. "On restructure." "On lance Scrum." "On déménage." Ce qu'ils ratent, c'est que le contexte du moment leur permet d'amplifier cette décision ou de la saboter. C'est leur signal aux équipes. C'est ce qui scelle la confiance ou la peur.

Si vous avez payé pour une transformation agile et que vous restez en comité, à approuver les décisions, à dévaloriser les PM qui prennent de vraies responsabilités, alors le système bascule vers le contrôle. La décision de lancer la transformation devient un signal inverse. Vous dites "soyez autonome" et vous dites "mais je signe". Les équipes apprennent à jouer le jeu en surface. La bifurcation vous a échappé.

À l'inverse, si la perte d'un gros client vous force à reprendre complètement votre stratégie produit et que vous le faites en incluant vraiment les équipes, en prenant les propositions sérieusement, en changeant d'avis si c'est juste, alors le système bascule vers l'apprentissage. La crise devient un moment de réunification. Ça paraît banal. Mais c'est rare. Et ça marque.

Reconnaître les bifurcations, c'est apprendre à voir quand votre organisation peut changer. Et c'est apprendre à exploiter ces moments, ou à les amortir, selon ce que vous visez.

En conclusion

Vous avez beaucoup de consultants qui vendront un SAFe, une réorg, une certification, un outil nouveau. Ils viennent avec des slides qui montrent combien ça a aidé ailleurs. Le positionnement est simple, appliquez notre recette, ça va marcher.

En 25 ans, je n'ai jamais vu ça marcher d'une seule traite. Et je crois à la raison profonde, la recette ne connaît pas votre système.

La pensée systémique, ce n'est pas une mode théorique. C'est l'outil qui distingue un praticien qui a vu plusieurs organisations d'un consultant en frameworks. Elle vous dit, avant d'appliquer un modèle, apprenez à lire votre système. Observez les boucles de feedback. Trouvez les signaux faibles. Mesurez la dette organisationnelle. Et seulement après, vous saurez quel levier tirer, où, et quand.

C'est moins vendable qu'une certification. C'est aussi plus long et plus subtil que l'audiovisuel d'une grosse transformation. Mais c'est la différence entre une transformation qui tient et une qui s'érode.

Si cette approche vous parle, trois portes restent ouvertes. L'exploration en formation PSPO II (où la pensée système s'applique concrètement au rôle de Product Owner), une intervention directe pour un audit organisationnel de votre contexte ou de votre transformation, ou la lecture du livre où je développe ces concepts plus profondément. À vous de choisir où vous en êtes.