Depuis quelques années, une rumeur circule : l'agilité serait morte. Des dirigeants l'annoncent lors de réunions de gouvernance. Des articles la déclarent obsolète face aux crises économiques actuelles. Des entreprises réduisent leurs investissements en transformation agile, licencient leurs coachs (ou srum master), reviennent à des modèles "plus traditionnels et sérieux". Car pour elles l’agilité n'a pas tenu face aux vrais défis. Sauf que les chiffres racontent une tout autre histoire.
En 2023, 60% des organisations ayant adopté l'agilité ont augmenté leur chiffre d'affaires et leurs bénéfices. Les équipes agiles sont 25% plus productives et mettent leurs produits sur le marché 50% plus vite (étude Delta Matrix, 2023). Plus frappant encore : selon un récent rapport du Forum économique mondial sur l'avenir de l'emploi (2025), 61% des organisations prévoient d'adopter ou de renforcer les pratiques agiles au cours des deux prochaines années. L'agilité ne disparaît pas. Elle s'étend même au-delà de l'informatique : vers la manufacture, l'industrie, les ressources humaines, la stratégie. On parle désormais de "Business Agility", qui englobe l'ensemble des fonctions de l'entreprise.
Alors pourquoi dit-on que l'agilité est morte ? Pourquoi ce fossé entre les données d'adoption et le sentiment d'échec ?
La réponse tient peut-être davantage à ce qui se passe quand une organisation essaie vraiment de l'appliquer qu’à la méthode elle-même. Elle tient peut-être davantage à ce qui se passe quand une organisation essaie vraiment de l'appliquer. Et surtout, à ce qui s'active en elle et qui l'empêche de le faire.
L'agilité est-elle morte avec l'IA ?
Il y a une nouvelle rumeur, plus récente encore : avec l'IA, l’agilité n’a plus vraiment de raison d’être.
L'argument semble séduisant : avec l'IA générative, on peut désormais prédire beaucoup de choses. On peut anticiper les bugs, générer du code plus vite, automatiser les tâches répétitives. Ne serait-ce pas un retour à la prédictibilité ? N'aurions-nous plus besoin d'itérer puisque les modèles IA peuvent nous donner des réponses rapidement ?
C'est une confusion. Et elle révèle précisément pourquoi l'agilité ne disparaîtra pas : parce que la complexité ne fait que s’accroitre.
L'IA ne rend pas l'avenir plus prévisible. Elle le rend plus complexe. Oui, l'IA peut générer un prototype en une journée au lieu d'une semaine. Mais cela accélère le besoin d'itération, ne l'élimine pas. Parce qu'une IA peut aussi générer quelque chose qui semble parfait sur le papier mais qui échoue totalement face aux vrais utilisateurs. Ou qui crée des biais imperceptibles. Ou qui ouvre des portes de sécurité.
L'arrivée massive de l'IA dans les organisations augmente justement le besoin d'agilité. Pourquoi ? Parce qu'aucune organisation ne sait vraiment comment l'IA va affecter ses processus. Aucun modèle IA n'est stable à long terme (ils se dégradent, nécessitent du réentraînement, révèlent des comportements inattendus). Et surtout, l'IA crée une pression constante d'adaptation.
Ce qu'on observe réellement en 2025, c'est que les organisations qui adoptent l'IA sans une vraie agilité se retrouvent avec le pire des deux mondes : la vitesse d'une machine et les décisions d'une hiérarchie figée. Elles génèrent des solutions rapidement, mais qui ne correspondent pas vraiment aux besoins. Elles accélèrent dans la mauvaise direction. À l'inverse, les rares organisations qui combinent IA et « agilité véritable » créent quelque chose de puissant : la capacité de générer rapidement, d'itérer souvent, d'apprendre vite, d'ajuster. Donc non, l'IA n'a pas tué l'agilité. L'IA l'a rendue indispensable.
I. L'apparent échec de l'agilité : comment on en est arrivé là ?
Parcourez les témoignages et les cas d'entreprises en 2024-2025 : vous trouverez un schéma répétitif, presque identique.
Une grande organisation décide de passer à l'agilité. Elle engage un cabinet de conseil reconnu. On forme les équipes. On installe les outils (Jira, Azure DevOps, peu importe). On nomme des Scrum Masters. On établit les sprints, les daily standups, les rétrospectives. Les cérémonies agiles s'installent. Pendant quelques mois, il y a de l'énergie, de la mobilisation. Puis, progressivement, quelque chose se fissure.
Les sprints deviennent des séances de reporting où chacun justifie son travail de la semaine. Les rétrospectives tournent en rond : on énumère les problèmes, mais rien ne change vraiment. Les équipes appliquent la méthode, respectent les rituels, mais l'esprit a disparu. On fait de l'agilité sans être agile. Et après deux ans, trois ans parfois, un dirigeant déclare : "L'agilité ne marche pas chez nous. C'est trop lent. On revient à quelque chose de plus structuré." Ces organisations ne mentent pas. Elles ont sincèrement l'impression que l'agilité n'a pas fonctionné. Mais ce qu'elles ont appliqué n'était pas vraiment l'agilité.
Ce qu'elles ont appliqué, c'était une méthode vidée de son essence. Une coquille agile remplie d'un contenu très traditionnel.
La distinction est cruciale. Il y a une différence entre connaître les pratiques agiles et adopter le mindset agile. Beaucoup de consultants maîtrisent la première. Peu d'organisations sont prêtes pour la seconde. Et c'est précisément là que réside le problème : ce n'est pas que l'agilité ne fonctionne pas. C'est que les organisations se défendent contre elle sans même le réaliser.
Les signes d'une mauvaise application
Reconnaître une fausse agilité est facile, une fois qu'on sait quoi chercher. Voici les signaux les plus courants :
- Premièrement, les rituels sans autonomie. Les équipes font des standups quotidiens, mais aucune décision n'est prise à ce niveau. Tout remonte au manager qui était déjà là avant l'agilité. Les daily deviennent des rapports à la hiérarchie plutôt que des moments d'auto-organisation. Et c’est encore plus vrai lors des rétrospectives.
- Deuxièmement, les backlogs gérés comme des listes de tâches. Au lieu que l'équipe se pose la question "qu'est-ce qui crée vraiment de la valeur", on énumère les demandes du client, on les traite dans l'ordre, et on boucle les sprints. Pas de reconsidération. Pas de remise en question de ce qui compte vraiment.
- Troisièmement, les rétrospectives superficielles. On identifie les problèmes (souvent les mêmes d'ailleurs), mais les causes systémiques, les patterns organisationnels qui les créent, ne sont jamais soulevées. Les problèmes qui menacent le statu quo restent silencieusement enfouis.
- Quatrièmement, l'absence d'expérimentation. L'agilité est censée permettre d'apprendre rapidement en itérant. Mais quand on demande à une équipe d'essayer quelque chose de nouveau et ça échoue, le message est clair : "On n'a pas le temps pour ces expériences. Continue avec ce qui marche." Le droit à l'erreur, fondamental en agilité, disparaît.
- Enfin, la proximité du client s'affaiblit. Au lieu que les équipes dialoguent directement et continuellement avec les utilisateurs, les demandes passent par un Product Owner qui, lui-même, dépend de la direction. Le feedback devient indirect, filtré, lent.
Tout cela a une apparence agile. Les murs sont décorés de post-its roses et jaunes. Les graphiques burndown sont visibles. On parle d'itération et de feedback. Mais le cœur du système n'a pas bougé d'un millimètre : la prise de décision reste centralisée, le contrôle reste serré, et l'apprentissage collectif reste tabou.
Et c'est là que l'organisation conclut : "L'agilité ne nous convient pas."
II. Le vrai diagnostic : l'agilité expose les défenses des organisations
Pour comprendre pourquoi tant d'adoptions d'agilité restent superficielles, il faut poser la question qui dérange : qu'est-ce que l'agilité menace vraiment dans une organisation ? Ce n'est pas l'efficacité opérationnelle. Ce n'est pas le respect des sprints ou la taille des backlogs. C'est quelque chose de bien plus profond. L'agilité, authentique, pose une question existentielle à l'organisation : "Sommes-nous prêts à mettre en question nos façons de faire, nos hiérarchies, nos habitudes ? Sommes-nous prêts à donner du pouvoir réel aux équipes ? Sommes-nous prêts à accepter que nous ne savons pas et que nous devons apprendre ensemble ?".
Ces questions dérangent. Pas parce que les gens sont résistants par nature (ce cliché est inexact). Elles dérangent parce qu'elles menacent des systèmes de sécurité psychologique profondément enracinés dans les organisations.
Les organisations, comme les humains, se construisent des défenses. Ces défenses ne sont pas pathologiques. Elles ont une fonction. Elles permettent à l'organisation de maintenir un ordre, une stabilité, une certitude. Elles rassurent. Elles rendent le monde prédictible. Elles protègent les rôles, les statuts, les pouvoirs établis. (voir le livre de Chris Argyris « Savoir pour agir : Surmonter les obstacles à l'apprentissage organisationnel »).
Mais l'agilité est une pratique qui repose précisément sur l'acceptation de l'incertitude, sur le droit à l'erreur, sur l'expérimentation, sur la remise en question continue. Elle demande aux organisations de vivre dans un état de décristallisation permanent, pour reprendre le vocabulaire du psychosociologue Kurt Lewin. Et ça, fondamentalement, provoque de l'anxiété.
Quand une organisation détecte cette menace, elle ne dit pas consciemment : "Non, on préfère rester rigides et inefficaces." Elle dit plutôt : "Adoptons les bonnes pratiques agiles, mais de manière qui ne déstabilise rien de fondamental." Et là commence le sabotage inconscient.
L'agilité exige une remise en question en "double boucle"
Pour bien saisir pourquoi ce sabotage est quasiment inévitable sans un vrai travail sur le mindset, il faut comprendre une distinction que le théoricien de l'organisation Chris Argyris a énoncée avec clarté : celle entre l'apprentissage en "simple boucle" et l'apprentissage en "double boucle".
- L'apprentissage en simple boucle, c'est améliorer ce qu'on fait déjà : faire un processus plus vite, utiliser un outil meilleur, optimiser la tâche. On reste dans le même cadre de référence. On demande : "Comment faire ça plus efficacement ?"
- L'apprentissage en double boucle, c'est remettre en question le cadre lui-même : "Pourquoi faisons-nous ça ? Quelles hypothèses sous-tendent nos décisions ? Nos règles non dites servent-elles encore ? Quel est le problème réel que nous essayons de résoudre ?" On sort du cadre de référence. On le remet en question. L'agilité authentique requiert un apprentissage en double boucle. Elle n'est pas une meilleure manière de faire ce qu'on faisait avant. C'est une question sur ce qu'on devrait faire et pourquoi.
Or, les organisations résistent naturellement à l'apprentissage en double boucle. Pas par malveillance. mais parce que ce type d'apprentissage provoque de l'inconfort. Il crée une zone grise où rien n'est certain. Il demande de renoncer à certaines croyances. Et ce renoncement, psychologiquement, a un coût.
Donc, ce qui se passe, c'est ceci : on adopte les formes de l'agilité (simple boucle : apprenons à faire Scrum mieux), mais on évite l'essence de l'agilité (double boucle : remettons en question comment et pourquoi nous organisons le travail).
Et une fois ce contournement bien installé, l'organisation accumule les frustrations. Les équipes voient qu'on parle d'auto-organisation, mais qu'aucune vraie autonomie n'est donnée. On parle de feedback continu, mais les vrais problèmes ne sont jamais abordés. On demande de l'innovation, mais l'expérimentation échoue dès qu'elle sort de la zone autorisée. Au bout d'un certain temps, chacun abandonne. Et le dirigeant conclut : "L'agilité n'a pas marché."
Les routines défensives : comment l'organisation s'auto-sabote
Argyris utilise une notion précise pour décrire ces mécanismes : les "routines défensives". Ce sont des actions, des pratiques, des non-dits qui permettent aux gens de ne pas se retrouver dans une situation embarrassante. Mais elles ont une conséquence involontaire : elles interdisent la discussion honnête et la résolution des vrais problèmes.
Voici ce que ça ressemble en pratique dans une pseudo-agilité :
Lors d'une rétrospective, quelqu'un dit : "Je trouve qu'on n'a pas assez d'autonomie pour prendre des décisions." Tout le monde sait que c'est vrai. Mais il y a une routine défensive : ne pas critiquer explicitement la structure. Donc on répond : "Oui, mais il faut bien que quelqu'un valide pour la qualité." Ou : "C'est vrai, mais on n'a pas le budget pour ça." On met un pansement rhétorique. Et on passe au point suivant.
Le vrai problème, qui est systémique, n'est jamais nommé : "Nous avons bâti une organisation où le contrôle prime sur la confiance, et l'agilité demande le contraire." Cette phrase ne sera jamais dite, parce qu'elle exposerait les gens au risque d'être vus comme critiques de la direction, ou comme inexpérimentés.
Résultat : la rétrospective a eu lieu. Mais rien ne change.
Et avec le temps, chacun comprend le message implicite : "On peut parler de changement, mais en réalité, on n'affrontera jamais les questions qui menacent l'ordre établi." À ce moment-là, l'agilité n'est plus une pratique de travail. Elle est un simulacre. Et le simulacre finit par s'effondrer.
Les mécanismes non conscients : l'anxiété comme force organisatrice
Ici, il faut aller plus loin encore. Car les routines défensives ne sont pas juste des choix. Elles sont activées par quelque chose de plus profond : l'anxiété organisationnelle. Le sociologue Elliott Jaques l'a formulé ainsi : "Les systèmes sociaux, même en apparence rationnels, fonctionnent souvent comme des défenses contre l'anxiété." En d'autres termes, les structures hiérarchiques, les règles, les processus, les rituels ne sont pas là que pour être efficaces. Ils sont aussi là pour contenir l'anxiété. Ils créent un espace prévisible où chacun sait sa place, ses responsabilités, ce qui est attendu de lui. C'est rassurant.
Quand une organisation est dans un tel système, la structure elle-même fonctionne comme un anti-anxiogène. Elle maintient les gens dans un état d'équilibre psychologique. Et puis on arrive avec l'agilité, qui dit : "Désormais, vous allez vous auto-organiser. Vous allez expérimenter. Vous allez accepter l'incertitude. Vous allez remettre en question vos façons de faire."
Ce n'est pas un problème technique. C'est une agression contre le système défensif lui-même. L'anxiété qui était contenue par la structure va resurgir. Et face à cette anxiété, l'organisation va réagir de manière entièrement non consciente. Elle ne dit pas : "J'ai peur, donc je vais saboter." Elle va plutôt dire : "On va faire de l'agilité, mais on va la faire de manière raisonnable, structurée, et sûre." Et sans le savoir, elle va la vider de son sens.
Cet automatisme est un phénomène normal et universel. Kurt Lewin l'appelait "décristallisation" : le moment où l'ancienne structure se désagrège et l'anxiété monte. C'est une phase inévitable du changement. Mais elle est insoutenable pour beaucoup. Et plutôt que de la traverser consciemment, l'organisation va inconsciemment chercher à la repousser. D'où la pseudo-agilité. Ce qui est crucial de comprendre : cette réaction n'est pas due à une mauvaise volonté ou une bêtise des gens. C'est une réaction psychologique d'auto-préservation. Et tant qu'elle reste non consciente, elle va continuer à saborder les efforts d'adoption.
C'est précisément pour cela que tant de projets agiles échouent.
On forme les gens à Scrum. On les équipe d'outils. On change les processus. Mais on ne travaille jamais sur ce qui bloque réellement : la peur. Et sans affronter cette peur consciemment, les anciens mécanismes de protection vont continuer à opérer, silencieusement, jusqu'à ce que la pseudo-agilité implose.
III. Les quatre défenses psychologiques qui sabotent l'agilité
On sait maintenant pourquoi les organisations se défendent contre l'agilité : elle menace le système psychologique qui les a jusqu'à présent contenues. Mais cette défense n'est pas une chose homogène. Elle opère sur plusieurs niveaux, activant différents mécanismes psychologiques selon le contexte.
Comprendre ces quatre niveaux aide à diagnostiquer où exactement une tentative d'agilité s'est enlisée.
1) La défense de l'anxiété existentielle
C'est le niveau le plus basique et le plus universel. Chaque être humain dans l'organisation ressent une anxiété face à l'inconnu. L'agilité demande d'accepter l'incertitude, l'itération, l'essai-erreur. Pour quelqu'un qui a passé dix ans à travailler dans un système prévisible et hiérarchisé, cette demande provoque une anxiété réelle.
Cette anxiété ne disparaît pas parce qu'on suit une formation Scrum. Elle persiste. Et elle provoque une régression inconsciente : on cherche à reconstituer la prévisibilité sous une nouvelle forme. D'où les sprints qui deviennent de petits cycles en cascade. D'où les daily standups qui deviennent des rapports de statut. D'où les rétrospectives qui tournent en rond : on énumère les problèmes sans jamais toucher à la structure.
Le mécanisme psychologique en jeu est simple : l'anxiété est insoutenable, donc on la combat en transformant l'agilité en quelque chose qui ressemble à l'ordre ancien. C'est une forme de fuite. Et elle fonctionne, temporairement. La pseudo-agilité offre une sensation de sécurité : on a les formes de l'agilité (donc on peut dire qu'on l'a adoptée), mais le contenu reste familier.
2) La défense identitaire et du statut
Ici, le mécanisme est différent. Ce n'est pas juste l'anxiété face à l'inconnu. C'est la menace à l'identité professionnelle et au statut.
Prenez un manager traditionnel. Son rôle a été de prendre les décisions, de contrôler, de valider. Son statut venait de là. Quand l'agilité arrive et dit "les équipes vont s'auto-organiser, les décisions vont être distribuées", ce manager entend : "Ton rôle n'existe plus." C'est une menace existentielle pour son identité professionnelle.
Mais le manager ne va pas dire : "Non, je ne veux pas perdre mon pouvoir." Il va dire : "On va faire de l'agilité, bien sûr. Mais avec de la gouvernance, de la validation, des points de contrôle." Et progressivement, il va reconstituer les anciens mécanismes de contrôle, cette fois-ci masqués sous le langage agile. Ou prenez un expert technique. Son identité venait de son savoir spécialisé. L'agilité valorise la collaboration, la polyvalence, l'apprentissage mutuel. Pour cet expert, c'est une dilution de ce qui le rendait unique. Sa défense ? Se positionner comme "gardien de la qualité" et bloquer les expériences qui pourraient affecter son domaine.
Ce niveau de défense est particulièrement puissant parce qu'il est légitime. Chacun a besoin d'une identité professionnelle stable. Mais quand cette identité est menacée, la personne va inconsciemment protéger le statu quo, tout en disant qu'elle soutient le changement.
3) La défense collective (les normes de groupe)
Kurt Lewin l'avait démontré : pour changer un individu, il faut changer les normes du groupe. Pourquoi ? Parce que les groupes fonctionnent comme des entités. Ils ont leur propre vie, leurs propres règles non dites, leur propre cohésion.
Quand une organisation adopte l'agilité, elle bouleverse les normes de groupe. Par exemple, une norme implicite était : "On ne critique pas les décisions d'en haut en public." L'agilité dit : "Dites ce que vous pensez vraiment. Challengez les hypothèses." C'est une violation de la norme établie. Mais les gens, de manière non consciente, vont résister parce que respecter la norme, c'est ce qui les garde intégrés au groupe. Violer la norme, c'est risquer le rejet. Donc, même si quelqu'un est intellectuellement d'accord avec l'agilité, émotionnellement, il va hésiter à vraiment s'y exposer. Et le groupe, collectivement, va exercer une pression silencieuse pour maintenir les normes anciennes.
Résultat : dans les rétrospectives, on parlera de changement. Mais personne n'osera vraiment le proposer. Et personne n'osera vraiment le critiquer. Le groupe reste soudé dans son inertie.
4) La défense informationnelle (les routines défensives)
C'est le niveau le plus sophistiqué, et peut-être le plus destructeur, parce qu'il se masque derrière une apparence de rationalité.
Argyris appelle cela les "routines défensives" : des patterns de communication qui permettent de ne pas affronter les vraies questions. Par exemple : "Oui, c'est vrai qu'on n'a pas assez d'autonomie, mais on a d'autres priorités maintenant." Ou : "Le problème ce n’est pas notre structure, c'est qu'on n'a pas encore bien compris Scrum." Ces routines permettent à tout le monde de continuer sans confrontation. Mais elles ont un coût : on n'apprend jamais. Les vrais problèmes ne sont jamais nommés. Et donc ils ne sont jamais résolus.
Cette défense opère surtout à un niveau organisationnel, pas individuel. Ce n'est pas qu'une personne refuse la vérité. C'est que l'organisation, comme système, met en place des mécanismes informationnels qui rendent certaines conversations impossibles.
IV. L'agilité : pas une méthode, un changement de rapport au pouvoir
Il faut maintenant poser la vraie question. On parle de "mauvaise application" de l'agilité. Mais qu'est-ce que l'agilité, vraiment ?
Ce n'est pas Scrum. Ce n'est pas les sprints, les standups, les rétrospectives. Ce sont des outils, des contenants. Ce qui remplit le contenant, c'est quelque chose de plus profond : une transformation du rapport au pouvoir dans l'organisation. Tant qu'on regarde l'agilité comme une méthode de gestion de projet à appliquer, on manque le point. Et c'est précisément pourquoi les consultants qui "connaissent la méthode" ne suffisent pas. Ils peuvent enseigner la mécanique. Mais ils ne peuvent pas changer les croyances fondamentales qui gouvernent comment l'organisation fonctionne.
L'agilité authentique repose sur une hypothèse radicale : ceux qui font le travail comprennent mieux que la hiérarchie ce qu'il faut faire. Pas systématiquement, pas dans toutes les situations. Mais assez souvent pour que la vraie question ne soit plus qui sait, mais qui décide. C'est précisément ce que David Marquet a démontré à bord du USS Santa Fe, une expérience qu'il raconte dans “Turn the Ship Around !” : au lieu de faire remonter l'information vers l'autorité, il a déplacé l'autorité là où se trouvait l'information. C'est une remise en question complète de comment les organisations ont été structurées pendant des décennies. Les organisations modernes héritent d'un modèle né à l'époque de la manufacture : la hiérarchie décide, les gens exécutent. Ce modèle a marché quand le travail était répétitif et prévisible. Mais dès qu'il y a complexité et changement (c'est-à-dire : dans presque tous les contextes modernes), ce modèle s'effondre.
L'agilité n'est pas une "meilleure version" de ce modèle. C'est une alternative. Elle demande : et si on faisait confiance aux gens qui effectuent le travail ? Et si on les écoutait vraiment ? Et si on organisait le pouvoir de décision différemment ? Cela rejoint directement une distinction fondamentale en théorie organisationnelle : celle entre "Activité de Groupe" et "Travail de Groupe" selon la Théorie Organisationnelle de Berne. L'Activité de Groupe c'est ce que le groupe fait pour s'adapter à la hiérarchie et au système établi. C'est souvent de l'énergie stérile, de la politique, du jeu de pouvoir. Le Travail de Groupe, c'est le groupe qui crée vraiment de la valeur, qui innove, qui produit ensemble.
Or, la pseudo-agilité est l'Activité de Groupe. C'est le groupe qui fait semblant de changer tout en protégeant les structures anciennes. L'agilité véritable demande de passer à du Travail de Groupe : créer des espaces où le groupe peut vraiment penser, vraiment décider, vraiment créer sans être constamment parasité par les mécanismes d'adaptation au système hiérarchique.
Cela n'est possible que si deux conditions sont remplies.
Premièrement, la hiérarchie doit renoncer à une certaine forme de contrôle. Pas tout contrôle, mais le contrôle du détail, de chaque décision tactique. Elle doit confier le pouvoir. Et cela demande une transformation profonde du mindset des dirigeants.
Deuxièmement, le groupe doit être prêt à accepter le pouvoir réel. Ce qui signifie accepter la responsabilité réelle de ses erreurs. Accepter que s'auto-organiser, c'est aussi accepter l'échec. Et cela demande une transformation profonde du mindset des collaborateurs.
Sans ces deux transformations de mindset, on n'a que du théâtre. Des rituels sans substance. Une pseudo-agilité qui accumule les frustrations avant de s'effondrer.
V. Pourquoi l'agilité n'est pas morte, elle est plus nécessaire que jamais
Revenons aux chiffres. Parce que c'est important de ne pas rester dans l'abstrait. Les organisations qui ont vraiment adopté l'agilité gagnent. Les données le montrent. Elles sont plus rapides, plus innovantes, plus réactives. Elles retiennent mieux leurs talents (parce que travailler dans un environnement où on a vraiment du pouvoir est plus engageant). Et oui, elles sont plus profitables.
Mais pourquoi alors tant d'organisations abandonnent-elles ? Parce qu'elles n'ont pas vraiment adopté. Elles ont adopté la forme, pas le fond. Et la forme sans le fond, c'est fatigant et inefficace.
Or, le contexte d'aujourd'hui rend l'agilité encore plus nécessaire, pas moins.
Les entreprises font face à trois défis simultanés : la complexité croissante de leurs environnements (technologie, régulation, concurrence), la volatilité du marché (on ne peut plus planifier cinq ans à l'avance), et la transformation rapide des compétences requises. Aucune de ces trois choses n'a diminué. Toutes trois s'accélèrent.
Face à cela, les modèles de gestion centralisés et prédictifs sont simplement dépassés. Pas de manière théorique ; de manière pratique, les organisations qui tentent de fonctionner avec un modèle traditionnel en 2025 sont de plus en plus à la traîne. En même temps, une nouvelle vague d'adoption de l'agilité émerge. Elle est moins visible que celle des années 2010, moins marketing. Mais elle est réelle. Elle n'est pas seulement en informatique. Elle est dans la manufacture (agilité hardware), dans les ressources humaines, dans la stratégie. Et ce qui change, c'est que les organisations qui adoptent maintenant l'agilité l'ont enfin compris : ce n'est pas une méthode de projet. C'est une transformation organisationnelle profonde. Et elles n'essaient plus de faire semblant. Elles acceptent le travail profond : transformer les mindsets, créer la sécurité psychologique, accepter l'apprentissage en double boucle.
La question pour chaque organisation est donc simple : êtes-vous prêt à affronter vos propres défenses psychologiques ? Êtes-vous prêt à transformer votre rapport au pouvoir ? Ou allez-vous continuer le spectacle de la pseudo-agilité jusqu'à ce que la réalité vous force la main ?
VI. Sortir du piège : les responsabilités par niveau hiérarchique
Si la pseudo-agilité est inévitable (elle l'est, tant qu'on n'adresse pas les défenses psychologiques), comment en sortir ?
La réponse demande de clarifier quelque chose qui reste souvent flou : chaque niveau hiérarchique a une responsabilité transformationnelle différente. Et tant que chaque niveau croit que "c'est l'autre qui doit changer", rien ne change.
C'est un mécanisme de défense organisationnelle très courant : la direction dit "on va faire de l'agilité, c'est aux équipes de changer leur mentalité". Les managers disent "je suis d'accord avec l'agilité, mais c'est la direction qui doit lâcher du contrôle". Les équipes disent "on aimerait être agiles, mais c'est le manager qui ne nous laisse pas faire". Et pendant ce temps, rien ne bouge. Voici ce qui devrait être travaillé par un coach à chaque niveau.
Le rôle du coach : créer la conscience et naviguer sur l'anxiété
Un coach ou un consultant qui arrive dans une organisation avec un plan de transformation agile ne doit pas commencer par les pratiques. Il doit commencer par l'anxiété. Parce que l'anxiété est le moteur des défenses. Tant qu'elle n'est pas nommée et travaillée, elle va continuer à saboter. Mais le coach n'est pas un thérapeute. Son rôle n'est pas de résoudre l'anxiété. C'est de la rendre visible, et d'aider chaque niveau à en prendre conscience.
Concrètement, cela signifie créer des espaces où l'anxiété peut être parlée. Non pas dans des réunions formelles avec tous les niveaux ensemble (ce serait une routine défensive : personne n'oserait parler franchement). Mais dans des moments de confidentialité avec chaque niveau séparément.
- Avec la direction : "Qu'est-ce qui vous fait vraiment peur dans la vraie agilité ? Quel est le scénario cauchemar ? Qu'est-ce que vous pourriez perdre ?"
- Avec les managers : "Comment imaginez-vous votre rôle si les équipes prenaient vraiment les décisions ? Qu'est-ce qui changerait pour vous ?"
- Avec les équipes : "Qu'avez-vous peur qu'il se passe si vous aviez vraiment du pouvoir ? Qu'est-ce qui vous bloquerait ?"
Une fois que l'anxiété est nommée, le vrai travail peut commencer. Il ne s'agit pas de rassurer ("tout ira bien"). Il s'agit d'aider l'organisation à traverser son anxiété consciemment (phase de "décristallisation".). Le coach doit aider à rester dans cet inconfort sans y réagir par la défense. Ensuite, il faut créer les conditions pour l'apprentissage en double boucle. Cela signifie : créer des moments où les vraies questions peuvent être posées, même si elles menacent le statu quo. Créer une culture où dire "je ne sais pas" et "je me suis trompé" est non seulement acceptable, mais valorisé. Et c'est un travail continu, pas un projet de trois mois.
Le rôle du manager d'équipe : créer l'espace, pas diriger l'espace
Le manager d'équipe est souvent oublié dans les discussions sur l'agilité. On parle de la direction et des équipes. Mais le manager est le point de friction critique.
Traditionnellement, le rôle du manager était : prendre les décisions, contrôler l'exécution, valider le travail. L'agilité demande quelque chose de radicalement différent. Le manager doit devenir un facilitateur. Quelqu'un qui crée les conditions pour que l'équipe prenne les décisions, qui s'assure que l'équipe a les informations dont elle a besoin, qui protège l'équipe des perturbations externes.
Mais ce changement est terrifiant pour beaucoup de managers. Parce que leur identité professionnelle a été bâtie sur le fait qu'ils savaient, qu'ils décidaient, qu'ils contrôlaient. Si ce rôle disparaît, qui sont-ils ?
C'est pourquoi beaucoup de managers vont inconsciemment saboter l'agilité. Ils vont dire "bien sûr, soyez agiles". Mais ils vont continuer à exiger des rapports détaillés, à remettre en question les décisions de l'équipe, à imposer leur vision. Et l'équipe va comprendre le message réel : "Tu peux jouer à l'agilité, mais c'est moi qui commande vraiment."
Donc, la transformation du manager doit être explicite. Et elle doit adresser son anxiété : "Qu'est-ce que tu craindras si tu laisses vraiment ton équipe décider ?" Une fois nommée, il y a une conversation à avoir : "Si l'agilité, c'est que ton équipe décide, quel est vraiment ton rôle ?" Et la réponse, c'est : créer la clarté (quels sont nos objectifs ?), protéger l'équipe (des demandes contradictoires venant d'ailleurs), enlever les blocages (y a-t-il des obstacles que seul toi peux enlever ?), et bien sûr, être responsable des résultats. Mais pas diriger comment on atteint ces résultats. C'est fondamentalement différent. Et ce changement doit être visible. Le coach doit le vérifier régulièrement. Parce que c'est facile de dire qu'on a transformé son rôle. C'est dur de vraiment le faire. Les vieilles habitudes vont réapparaître sous stress.
Le rôle des niveaux hiérarchiques supérieurs : lâcher la micro-gestion, accepter l'incertitude
La direction et les niveaux hiérarchiques supérieurs jouent un rôle différent mais tout aussi crucial. Traditionnellement, le rôle de la direction, c'était : prévoir, planifier, donner les directives. Et puis vérifier que les directives sont suivies. C'est un modèle prédictif. On anticipe l'avenir (ou on pense le faire), on décide une trajectoire, et on s'assure que tout le monde la suit. L'agilité demande d'accepter qu'on ne puisse pas prévoir. Que l'avenir va surprendre. Que la meilleure façon de naviguer est d'avoir une direction générale (pourquoi existons-nous ? quels sont nos objectifs stratégiques ?), mais de laisser les équipes adapter comment on y arrive.
C'est vertigineux pour beaucoup de PDG et de dirigeants. Parce qu'on leur dit depuis toujours que leur rôle est de prévoir et de maîtriser. Lâcher prise sur le "comment", c'est accepter l'incertitude. Et c'est source d'anxiété. Mais cette anxiété doit être affrontée. Parce que si la direction reste dans le mode "micro-gestion prévisionnelle", elle va empêcher mécaniquement les managers de laisser les équipes s'auto-organiser. Et donc, la transformation s'arrête au premier niveau. Concrètement, la direction doit :
- Premièrement, donner une vision claire et stable (le "pourquoi"), mais laisser la flexibilité tactique (le "comment"). Et accepter que le "comment" va évoluer, va surprendre.
- Deuxièmement, accepter de communiquer l'incertitude. Au lieu de dire "voici le plan pour les cinq prochaines années", dire "voici notre direction. Voici ce qu'on sait maintenant. Voici ce qui pourrait changer. Et on va adapter ensemble." C'est moins rassurant. Mais c'est vrai.
- Troisièmement, mesurer non pas la conformité aux plans, mais l'impact réel. Avons-nous créé de la valeur ? Avons-nous appris ? Avons-nous innové ? Pas : avez-vous suivi le plan à 100%.
- Et quatrièmement, la direction doit accepter que si on demande aux équipes de prendre des risques et d'expérimenter, il y aura des échecs. Et ces échecs ne doivent pas être punis. Sinon, personne ne va vraiment prendre de risques.
C'est difficile pour les dirigeants qui ont une phobie de l'échec. Mais c'est la condition.
Ce qui doit changer à chaque niveau : un résumé
- Direction : passe de "je prévois et je contrôle" à "je donne la direction et j'accepte l'adaptation".
- Managers : passe de "je décide et je contrôle" à "je crée les conditions et j'enlève les obstacles".
- Coach : n'est pas un "faiseur agile", mais un facilitateur de conscience et de transformation du mindset.
Et le point critique : chaque niveau doit voir et accepter sa propre transformation, pas juste demander aux autres de changer.
Tant que la direction croit que "les managers peuvent changer sans que nous changions", ça ne marche pas. Tant que les managers croient que "les équipes peuvent changer sans que nous changions", ça ne marche pas. Et tant que les équipes croient que "c'est au manager de changer, pas à nous", ça ne marche pas. C'est une transformation systémique. Chaque niveau doit y contribuer.
VII. Conclusion : L'agilité n'est pas un choix, c'est une évolution
Revenons au point de départ. On dit que l'agilité est morte. Les chiffres disent qu'elle s'étend. C'est un paradoxe qui ne l'est qu'en apparence.
Ce qui est mort, c'est peut-être l'illusion qu'on pouvait adopter l'agilité en changeant juste les processus. L'agilité est morte en tant que buzzword, en tant que mode, en tant que solution miracle qu'on peut acheter auprès d'un cabinet de conseil.
Ce qui n'est pas mort, loin de là, c'est le besoin profond que l'agilité satisfait. Ce besoin s'appelle : la capacité à naviguer la complexité. À apprendre vite. À s'adapter. À innover.
Ces besoins vont croître, pas diminuer. Parce que le monde devient plus complexe, plus volatil, plus incertain. Les organisations qui ont traversé la phase inconfortable de la véritable transformation agile vont prospérer. Celles qui vont rester dans la pseudo-agilité vont de plus en plus sentir le fossé entre leur image (agile) et leur réalité (hiérarchique, lente, rigide). Et celles qui ne font rien vont simplement disparaître.
L'agilité n'est pas morte. Elle est en train de devenir normale. Et cela signifie que bientôt, on ne parlera plus d'agilité. On parlera juste d'organisations qui savent se réinventer, qui font confiance à leur personnel, qui apprennent ensemble. Et ça, ce sera simplement la condition pour exister.
