L’agilité est-elle en train de disparaître ?

« L’agilité est morte », nous disait Jurgen Appelo, citant de nombreux articles (ici ou là). Les coachs agiles auraient tué l’agilité et il serait aujourd’hui nécessaire de changer notre façon de travailler, d’après Rachel Dubois. « C’est la revanche des chefs de projets », surenchérit Jean-Pierre Lambert. Les posts linkedIn expliquant que l'agilité est 6 pieds sous terre à l’orée de 2026 sont légion.

Bien que ces messages fassent écho en moi, notamment la nécessité, pour les acteurs du changement, de s’engager sur des résultats, de changer de posture et de s’ouvrir à d’autres approches plutôt que de rester enfermés dans des dogmes méthodologiques,  je vais pourtant aller à contre-courant.

Non, l’agilité n’est pas morte.
Non, le métier de coach agile n’est pas voué à disparaître.
Non, il ne faut pas glorifier les chefs de projets « à l’ancienne ».

Vous voulez peut-être un peu plus d’explications que ces simples affirmations ?

L’agilité est devenue la nouvelle norme

Ce qui donne l’impression que l’agilité est dépassée, c’est qu’elle s’est en réalité imposée comme la nouvelle norme, comme a pu l’être le cycle en V au XXᵉ siècle (oui, j’aime rappeler que cette approche est celle du siècle précédent).

Combien connaissez-vous d’entreprises qui recherchent des développeurs en indiquant dans leur annonce :

« Fer de lance du waterfall, nous recherchons un développeur capable de produire les lignes de code décrites dans la spécification technique définie par le chef de projet MOE, sur la base d’un cahier des charges exhaustif rédigé six mois plus tôt par la MOA » ?

Dans les faits, c’est peut-être ce qui se passera réellement dans l’entreprise, probablement avec un vocabulaire Scrum mal copié sur des rôles biaisés, mais personne ne le dira explicitement.

Au mieux, une offre d’emploi ne mentionne aucune méthodologie ; au pire, elle évoque un fonctionnement « agile » sans entrer dans les détails.
Pourquoi ? Parce qu’aucun développeur compétent, engagé et sain d’esprit n’a envie d’aller « pisser du code » sans intérêt.
(En cas de doute, je vous renvoie à la genèse de l'agilité  dans les années 90 et aux raisons de son émergence.)

Une lecture via le modèle de Kano

Pour une grille de lecture plus concrète, regardons le modèle de Kano et pensons le recrutement comme la vente d’un produit (le poste) à un utilisateur (le développeur).

On distingue trois types de fonctionnalités :

• Les fonctionnalités attractives (ou excitantes)
  Associées à l’innovation. Les utilisateurs ne les demandent pas explicitement. Leur absence ne crée pas d’insatisfaction, mais leur présence génère un effet waouh.
• Les fonctionnalités proportionnelles
  Explicitement demandées. Plus on y répond, plus l’utilisateur est satisfait ; moins on y répond, plus il est insatisfait.
• Les fonctionnalités basiques (ou obligatoires)
  Les standards du marché. Elles ne créent pas de satisfaction particulière lorsqu’elles sont présentes, mais génèrent de l’insatisfaction lorsqu’elles sont absentes.

La particularité de ce modèle est qu’une fonctionnalité innovante à un instant donné devient, avec le temps, proportionnelle, puis finit par devenir un standard du marché lorsque la majorité tardive l’adopte (courbe de Rogers).

L’agilité comme fonctionnalité « basique »

L’agilité ne peut plus aujourd’hui être considérée comme une fonctionnalité excitante. Après plus de vingt ans, ce n’est plus une innovation.

Si les développeurs ne la demandent pas explicitement, c’est justement parce qu’elle est devenue un basique, un standard du marché, là où le salaire ou le télétravail relèvent plutôt des fonctionnalités proportionnelles.

On ne demande pas plus « un environnement agile » qu’on ne demande à un client mail la possibilité de transférer un message.

Être dans un environnement agile ne génère donc plus de satisfaction particulière ; en revanche, son absence crée immédiatement de l’insatisfaction.

Alors, cela signifie-t-il que tout le monde est « full agile » ?
Malheureusement non.

Les transformations agiles ont souvent été dévoyées, mal appliquées et n’ont d’agile que le vocabulaire. Des tentatives ont bien existé pour redonner du sens,(heart of agile, Agilité Radicale, …), mais le problème de fond est resté le même.

La mode de la transformation « produit »

Dans de nombreux grands groupes, après des transformations agiles plus ou moins réussies, la tendance est aujourd’hui à la transformation « produit ».

Comme s’il était pertinent d’opposer agilité et produit.

Vu sous un angle business, le raisonnement est souvent le suivant :

Nous avons investi des millions dans une transformation agile qui, comme le soulignent de nombreux articles, a eu peu d’impact réel car trop centrée sur des certifications ou des processus rigides. Le périmètre étant désormais atteint, nous ne pouvons plus justifier ces budgets. Lançons donc un nouveau projet : la transformation produit, enfin orientée vers la valeur.

Mais il n’y a pas de produit sans agilité, et inversement.
Ce que beaucoup appellent aujourd’hui « transformation produit » n’est ni plus ni moins que la transformation agile qu’ils auraient dû mener il y a des années.

Relisez Alistair Cockburn, Kent Beck, Martin Fowler, ou encore les premiers écrits de Schwaber et Sutherland sur Scrum.
Les approches diffèrent, mais l’objectif est identique : cesser de gaspiller du temps et de l’énergie sur des éléments à faible, voire nulle, valeur ajoutée.

« Nous découvrons comment mieux développer des logiciels » signifie précisément cela. Les quatre valeurs du manifeste ne sont que des moyens pour y parvenir.

La transformation produit poursuit le même but, avec un vocabulaire différent :
se focaliser sur la valeur utilisateur réelle, renforcer la discovery, mesurer l’impact plutôt que la productivité, utiliser les OKR, la stratégie produit, etc.

Si vous avez l’impression que je paraphrase quelque chose de déjà connu… c’est sans doute un indice 😉

Même combat, mêmes risques

L’agilité n’est donc pas morte.
Les coachs agiles ont encore de beaux jours devant eux.
Elle reste indispensable à la survie des entreprises, peut-être plus que jamais.

Elle a simplement changé de nom et vu émerger de nouvelles façons de s’implémenter, souvent mieux « marketées » pour parler aux dirigeants.

Mais attention : les transformations produit risquent de reproduire exactement les mêmes écueils que les transformations agiles précédentes si les mêmes patterns sont appliqués.

Considérer une transformation produit comme terminée parce que :

• tout le monde est certifié sur [insérer ici le framework de votre choix] ;
• les OKR sont pilotés dans toute l’entreprise, avec par exemple :
  • O : respecter l’intégralité des délais et périmètres imposés par le métier
  • KR1 : 80 % des projets respectent la roadmap validée en PIP
  • KR2 : …

mènera aux mêmes résultats : beaucoup de dépenses, peu d’impact, puis dans cinq ans des articles LinkedIn expliquant que « le product management est mort ».

Conclusion

Pour revenir au point de départ :
non, l’agilité n’est pas morte.

Les coachs agiles et les acteurs du changement ont encore du travail, mais les façons d’accompagner doivent évoluer.
S’éloigner du monde des bisounours déconnecté de l’impact réel permettra de faire le tri entre ceux qui accompagnent un véritable changement et ceux qui se contentent de vendre du branding agile, des certifications ou des roadmaps SAFe.

Les entreprises rejoignent aujourd’hui un mouvement de fait “framework agnostic”, non par idéologie, mais parce qu’elles ont compris que le respect d’un framework n’est pas une fin en soi. 

Et c’est une bonne nouvelle.
Cela pousse enfin à mesurer les impacts plutôt que les actions.

Loin d’enterrer l’agilité, elles sont simplement en train de la redécouvrir.

Léonard Prunier, Coach Agile