Il existe une catégorie d'objets dont on parle beaucoup et qu'on n'a jamais lus. Le Modern Agile en fait partie. On le cite en réunion comme une version 2.0 de l'agilité, on suppose qu'il s'agit d'un cadre plus moderne que Scrum, et on passe à autre chose. Or il n'y a rien à installer, rien à acheter, rien à certifier. Quatre phrases, et l'obligation désagréable de regarder ce que votre organisation fait vraiment.

Depuis 2012 que je travaille l'agilité et que je facilite des collectifs, j'ai vu passer beaucoup de cadres. La plupart arrivent avec un vocabulaire, des rôles, un calendrier de cérémonies et une offre de formation. Le Modern Agile arrive sans rien de tout cela, ce qui explique à la fois pourquoi il n'a pas fait fortune et pourquoi il reste utile. C'est un miroir, pas un dispositif. Cet article vous donne sa formulation exacte, son histoire réelle, ce qu'il change concrètement, et ce qu'il ne sait pas faire.

Qu'est-ce que le Modern Agile exactement ?

Le Modern Agile est un ensemble de quatre principes guides destinés à orienter le travail d'une équipe, sans prescrire aucune pratique. Il ne définit ni rôle, ni artefact, ni réunion, ni durée d'itération. Le site officiel du mouvement le présente comme guidé par des principes et libre de tout framework, et publie l'ensemble sous licence Creative Commons Attribution-ShareAlike 4.0, graphisme et police compris.

Cette absence est volontaire et elle est le coeur du sujet. Un framework vous dit quoi faire lundi matin. Un principe vous dit à quoi vous devez ressembler dans six mois, et vous laisse la charge de trouver comment. Le premier est confortable et se vend. Le second est inconfortable et ne se vend pas. C'est exactement pour cela qu'il ne peut pas être appliqué de travers par un prestataire, faute d'avoir quoi que ce soit à appliquer.

Ce que le Modern Agile ne contient pas, et ce n'est pas un oubli

• Aucun rôle. Pas de Scrum Master, pas de Product Owner, pas de Release Train Engineer.
• Aucune cérémonie. Ni Daily, ni Sprint Planning, ni Rétrospective imposée, ni revue de fin d'itération.
• Aucun artefact obligatoire. Ni backlog, ni burndown chart, ni story point, ni vélocité.
• Aucune certification. Il n'existe pas de Certified Modern Agile Practitioner, et ce n'est pas un manque à combler.
• Aucune unité de mise à l'échelle. Rien qui ressemble à un train, à une tribu ou à un chapitre.

Un framework se déploie, un principe s'assume. La différence n'est pas sémantique, elle détermine qui porte la responsabilité de l'échec.

D'où vient le Modern Agile et qu'est-ce qui l'a déclenché ?

Il vient d'un praticien qui a constaté que ses propres pratiques ne tenaient plus. Joshua Kerievsky, fondateur d'Industrial Logic et auteur de Refactoring to Patterns paru chez Addison-Wesley en 2004, publie un premier billet intitulé Modern Agile le 3 novembre 2015. Il y écrit qu'il tenait autrefois pour essentiels l'estimation en story points, le calcul de la vélocité et les itérations de durée fixe, et qu'il n'utilise plus aucun des trois. Le mouvement naît de cet aveu, pas d'un manifeste collectif.

La formulation en quatre principes vient ensuite, et c'est la keynote donnée à la conférence Agile2016, à Atlanta, qui la fait connaître largement. Retenez la chronologie : le nom et l'intuition datent de 2015, la mise en forme et la diffusion de 2016. Beaucoup de résumés en circulation datent la création de 2016 seulement, ce qui écrase l'année où l'idée s'est cherchée.

Kerievsky n'était pas seul à trouver que quelque chose clochait

La remise en cause venait déjà de l'intérieur, et depuis un moment. Dès novembre 2011, Jim Highsmith, l'un des dix-sept signataires du Manifeste Agile, publie un texte au titre sans ambiguïté, « Velocity is Killing Agility », dans lequel il explique que la mesure de vélocité, censée aider une équipe, sert en réalité à la comparer et à la presser.

En mai 2019, Ron Jeffries, autre signataire et cofondateur de l'Extreme Programming, va plus loin dans un texte intitulé « Story Points Revisited ». Il y écrit qu'il a peut-être inventé les story points et que, si c'est le cas, il en est désolé aujourd'hui. La formule est célèbre, mais elle est souvent tronquée : il conclut son article en précisant qu'il en est un peu désolé, pas très désolé, et il recommande simplement d'abandonner l'estimation quand elle n'apporte pas de valeur réelle. La nuance compte, parce qu'elle distingue une critique d'usage d'une abjuration.

Ce que je retiens de cette généalogie, c'est qu'elle ne vient pas de critiques extérieurs. Elle vient des gens qui ont construit ces pratiques et qui ont regardé ce qu'on en avait fait. C'est le même mécanisme que je décris dans mon article sur les rituels agiles qui ne produisent pas d'agilité : la forme survit longtemps à l'intention, et personne ne s'en aperçoit tant que les cérémonies ont lieu à l'heure.

Que disent exactement les quatre principes ?

Ils tiennent en quatre phrases impératives, dans un ordre canonique qui n'est pas une hiérarchie. Les voici dans leur formulation d'origine, avec ce que chacun oblige réellement à regarder et le contresens que je rencontre le plus souvent en accompagnement.

D'où viennent ces principes, puisqu'ils ne sortent pas du logiciel

Kerievsky cite ses sources dans son billet fondateur, et elles viennent en bonne partie d'ailleurs que de l'informatique. On y trouve le Lean appliqué au développement logiciel, le Lean Startup d'Eric Ries paru en 2011, les travaux du psychologue britannique James Reason sur les accidents organisationnels, et la culture de sécurité industrielle telle que Paul O'Neill l'a imposée chez Alcoa entre 1987 et 1999.

Cette généalogie explique la place inhabituelle de la sécurité dans le dispositif. Elle ne vient pas du monde du logiciel, elle vient des industries où une erreur non signalée tue quelqu'un. C'est le point le plus intéressant du Modern Agile, et c'est aussi celui que les organisations vident le plus vite de son contenu.

Pourquoi la sécurité est-elle le principe le plus mal compris ?

Parce qu'on la confond avec la douceur, alors qu'elle désigne une capacité à encaisser le conflit et la mauvaise nouvelle. Un environnement sûr n'est pas un environnement où personne ne se contredit. C'est un environnement où contredire ne coûte rien à celui qui contredit.

Ce que la recherche établit réellement

Le concept est documenté et daté. Amy Edmondson, professeure de leadership à la Harvard Business School, publie en 1999 dans Administrative Science Quarterly une étude devenue la référence du domaine, Psychological Safety and Learning Behavior in Work Teams. Elle porte sur 51 équipes de travail d'une entreprise industrielle.

Son résultat structurant est souvent mal restitué, alors qu'il est décisif. La sécurité psychologique n'améliore pas directement la performance. Elle rend possible un comportement d'apprentissage, poser des questions, demander de l'aide, signaler une erreur, et c'est ce comportement qui, lui, produit la performance. Autrement dit, la sécurité n'est pas la récompense d'une équipe qui va bien, c'est le prérequis d'une équipe qui progresse. Le Modern Agile n'invente pas cette idée, il la range là où elle doit être, en amont de tout le reste.

Une équipe qui ne peut pas dire « je me suis trompé » ne peut pas apprendre. Toutes les autres pratiques que vous installerez par-dessus ne feront que rendre cette impossibilité plus rapide.

Le test que je fais passer aux comités de direction

Dans mes accompagnements de CODIR, j'observe que la sécurité ne se mesure pas au discours mais à un seul événement : ce qui arrive à la première personne qui annonce que le calendrier ne tiendra pas. Si l'information remonte vite, qu'elle est traitée comme une donnée et qu'elle modifie une décision, la sécurité existe. Si elle attend le prochain comité, qu'elle est reformulée en point d'attention et qu'elle ne change rien, elle n'existe pas, quel que soit le nombre de séminaires sur la bienveillance.

C'est aussi pourquoi je me méfie du mot bienveillance quand il sert de synonyme à sécurité. Les deux ne se recouvrent pas, et la vraie bienveillance au travail suppose de pouvoir dire des choses désagréables. Une équipe qui confond les deux glisse vers la fausse harmonie, l'un des dysfonctionnements classiques où l'absence de conflit visible masque une absence de confiance.

En quoi le Modern Agile diffère-t-il du Manifeste Agile, de Scrum et de SAFe ?

Il diffère par sa nature, pas par son contenu. Le Manifeste énonce des valeurs, Scrum et SAFe prescrivent une organisation du travail, le Modern Agile propose des objectifs à atteindre sans dire par quel chemin. Comparer les quatre sur le même axe est la source de la plupart des malentendus.

Non, le Modern Agile ne remplace pas le Manifeste Agile

C'est le point sur lequel les résumés se trompent le plus souvent, et il mérite d'être posé clairement. Le Manifeste pour le développement agile de logiciels a été rédigé et signé par dix-sept personnes réunies dans l'Utah du 11 au 13 février 2001. Joshua Kerievsky n'en fait pas partie. Le Modern Agile n'a jamais été entériné par les signataires d'origine, et n'a aucun statut officiel vis-à-vis du texte de 2001, dont les douze principes restent publiés inchangés.

Ce que Kerievsky a fait, et qu'il présente comme sa proposition personnelle, c'est suggérer des correspondances entre les quatre valeurs de 2001 et ses quatre principes, et défendre publiquement l'idée que le texte de 2001 a vieilli. C'est un point de vue d'auteur, argumenté et discutable. Ce n'est pas une révision. Un article qui présente le Modern Agile comme « le nouveau Manifeste » vous induit en erreur sur son statut, et vous prive au passage du droit de le contester.

Peut-on faire du Scrum et du Modern Agile en même temps

Oui, et c'est même le cas d'usage le plus fréquent, parce que les deux objets ne jouent pas au même niveau. Ken Schwaber et Jeff Sutherland vous disent comment organiser le travail d'une équipe. Le Modern Agile vous demande à quoi sert cette organisation. Rien n'interdit de garder vos itérations et vos rétrospectives, et d'utiliser les quatre principes comme critère d'évaluation de ces mêmes rituels.

La friction apparaît ailleurs, et elle est réelle. Si vous prenez la sécurité au sérieux, certaines pratiques installées deviennent difficiles à défendre : comparer la vélocité de deux équipes, faire de l'engagement de sprint un objet d'évaluation individuelle, ou tenir des rétrospectives en présence de la ligne hiérarchique qui décide des augmentations. Le Modern Agile ne vous demande pas d'abandonner Scrum. Il vous met devant ce que vous avez ajouté à Scrum sans le dire.

Comment s'en servir sans en faire un framework de plus ?

En le traitant comme une grille de diagnostic répétée dans le temps, jamais comme un dispositif à installer. Le réflexe organisationnel classique consiste à créer un chantier Modern Agile, à nommer un référent et à produire une feuille de route. C'est le meilleur moyen de reproduire exactement ce que le Modern Agile critique. Voici la façon la plus simple que je connaisse de l'utiliser.

1. Notez les quatre principes sans rien changer d'autre. Réunissez l'équipe une heure et évaluez honnêtement, principe par principe, où vous en êtes. Aucun plan d'action à ce stade, aucun outil nouveau, aucune cérémonie ajoutée. La seule règle qui compte est que chacun puisse poser une mauvaise note sans conséquence, ce qui constitue déjà un test du deuxième principe.
2. Traitez la sécurité en premier, quelle que soit la note des autres. Si les gens ne peuvent pas signaler une mauvaise nouvelle sans risque, aucun des trois autres principes ne tiendra, et vos expérimentations seront des démonstrations déguisées. Cherchez des preuves concrètes plutôt que des déclarations : comment le dernier incident a-t-il été traité, qu'est-il arrivé à la personne qui a annoncé le dernier retard.
3. Choisissez une seule expérimentation, avec sa mesure définie avant le lancement. Une expérimentation dont le critère de réussite n'est pas écrit à l'avance n'est pas une expérimentation. Fixez un horizon court, une mesure unique et une date à laquelle vous arrêtez, poursuivez ou modifiez. C'est le même mécanisme que celui du feedback comme boucle d'apprentissage plutôt que comme jugement.
4. Refaites l'exercice au trimestre suivant et comparez. Le Modern Agile n'a de valeur qu'en série. Reprenez la même grille trois mois plus tard, comparez les notes et discutez des écarts. C'est le mouvement qui informe, pas le score. Une note stable et honnête vaut mieux qu'une progression fabriquée pour le comité.

La qualité de cet exercice dépend entièrement de celle de la conversation, ce qui en fait un sujet de facilitation avant d'être un sujet de méthode. Une évaluation collective menée sans cadre produit soit un consensus mou, soit la note du plus gradé. C'est là qu'un vrai travail sur les niveaux d'intelligence collective d'un atelier change tout, et c'est aussi ce qui distingue une organisation qui apprend d'une organisation qui documente son apprentissage.

Une dernière remarque de méthode, qui vaut pour les quatre principes. Ne les faites pas descendre. Si le Modern Agile arrive par une note de direction, il deviendra un référentiel d'évaluation des équipes, et la sécurité sera la première victime. Il fonctionne quand une équipe se l'approprie et invite ensuite sa hiérarchie à regarder le résultat, ce qui suppose d'avoir déjà travaillé la dynamique de votre culture projet.

Quelles sont les limites du Modern Agile ?

Sa principale force est aussi sa principale faiblesse : il ne vous dit pas quoi faire lundi matin. Une équipe qui manque de repères opérationnels n'y trouvera aucun secours, et le reproche est légitime. Quatre objectifs sans aucune pratique associée laissent une marge d'interprétation considérable, et cette marge se remplit avec la culture existante, qui est précisément ce qu'on voulait changer.

Trois limites que je pose honnêtement

• L'absence de guidance opérationnelle. C'est la critique la plus fréquente et la plus fondée. Le Modern Agile suppose des équipes déjà matures, capables de traduire un principe en pratique. Dans une organisation qui découvre l'agilité, il produira surtout des affiches.
• « Rendre les gens géniaux » est un piège rhétorique. Le principe est le plus facile à récupérer en discours managérial creux, et le plus difficile à mesurer. Formulé sans destinataire précis, il ne veut rien dire. Nommez les personnes concernées ou n'utilisez pas le principe.
• Le mouvement n'a pas produit d'écosystème. Le site officiel reste en ligne et le contenu reste sous licence libre, mais je n'ai trouvé aucune activité publique documentée récemment, ni événement, ni corpus qui s'enrichisse. Kerievsky lui-même publie aujourd'hui surtout sur l'ingénierie assistée par l'IA. Un cadre qui ne vit que par sa communauté et dont la communauté est silencieuse pose un vrai problème de fraîcheur.

Cette dernière limite est ironique, et il faut l'assumer plutôt que la cacher. Le Modern Agile a refusé de se doter d'une industrie, d'un institut et d'un programme de certification, et c'est très exactement pour cela qu'il n'a pas d'organisme pour le maintenir en vie. La cohérence a un prix.

Ce que j'en fais aujourd'hui

Je ne propose jamais le Modern Agile comme une transformation, et je ne connais personne de sérieux qui le fasse. Je m'en sers comme d'un jeu de quatre questions à poser à un collectif qui a déjà tout installé et qui ne comprend pas pourquoi rien ne bouge. Dans ce contexte précis, sa nudité est un avantage : il n'y a rien à acheter, donc rien à mettre en scène, donc rien derrière quoi se cacher.

Et si vous ne deviez retenir qu'un principe, gardez le deuxième. La sécurité conditionne les trois autres et se dégrade sans bruit, souvent au moment précis où l'organisation se met sous tension. C'est d'ailleurs le lien direct entre agilité et capacité d'une organisation à encaisser les perturbations : une équipe qui ne peut pas dire ce qui ne va pas ne vous préviendra pas non plus de ce qui arrive.