Ce Manifeste qui nuit à l'Agilité

Pourquoi il faut arrêter de se référer au Manifeste Agile, surtout pour parler de l'Agilité en industrie, et pistes pour une V2.^[1][2]

Le Manifeste Agile, c'est quoi ?

A) Le Manifeste Agile, un écrit sacré ?

Le Manifeste Agile a été écrit en 2001 par 17 « luminaires » du développement logiciel : Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland et Dave Thomas.

C'est un travail collectif, fruit d'un week-end de réflexion dans une station de ski de l'Utah. Pas une étude scientifique, pas un standard industriel : un texte de consensus entre praticiens du logiciel.

B) Une volonté de convaincre

Alors que l'Agilité évolue naturellement par essais et erreurs sur le terrain, le Manifeste est une conclusion décrétée. Son objectif explicite : « faire adopter l'Agilité par les développeurs logiciels ». Ce n'est pas une découverte, c'est un acte de communication.

C) Un biais de séduction

Le Manifeste comporte trois biais majeurs :

1. Il a figé l'Agilité dans un texte fixe, alors qu'elle est par nature évolutive.
2. Il a orienté l'Agilité vers le développement logiciel, créant une bijection exclusive entre les deux : dans l'esprit de beaucoup, Agilité = logiciel.
3. Il a emprunté des termes à la Qualité et à l'Amélioration Continue, brouillant les frontières et rendant l'Agilité difficilement identifiable en tant que discipline propre.

D) Devenu une référence

Malgré ces biais, le Manifeste est devenu LA référence canonique de l'Agilité. C'est étrange : utiliser un document spécifiquement écrit pour le logiciel comme référence universelle de l'Agilité, y compris hors logiciel. Comme utiliser un guide de Romorantin pour visiter Naples.

E) Point positif ?

Malgré toutes ces critiques, le Manifeste a un mérite : il évoque la possibilité d'une approche alternative au développement traditionnel. Il a ouvert une porte. Le problème, c'est qu'il l'a ouverte dans un couloir trop étroit.

Peut-on Critiquer le Manifesto ?

Au sein même de SolidCreativity, certains considèrent le Manifeste comme une base solide. OK, mais là, il fait jour.

Disclaimer

Oui, j'ose remettre en question le Manifeste. Pourquoi ?

• Trop de gens pensent comprendre l'Agilité après avoir lu la page Wikipédia.
• Les études sur l'Agilité hors logiciel référencent systématiquement le Manifeste, alors qu'elles ne devraient pas.
• Le Manifeste se focalise sur la gestion de projet sans jamais mentionner les capacités agiles naturelles des équipes.

Critique du Manifeste Agile

Le Manifeste se compose de 4 valeurs et 12 principes. Examinons-les.

A) Les 4 valeurs

Le Manifeste déclare valoriser :

• « Les individus et leurs interactions plus que les processus et les outils »
• « Des logiciels opérationnels plus qu'une documentation exhaustive »
• « La collaboration avec les clients plus que la négociation contractuelle »
• « L'adaptation au changement plus que le suivi d'un plan »

B) Idéal tentant ou effrayant ?

Ces valeurs sont idéalistes. Elles dessinent un monde séduisant, mais pas conducteur à l'adoption en entreprise. Elles créent une barrière à l'entrée inutile : un dirigeant industriel qui lit « moins de processus, moins de documentation, moins de contrats » voit un risque, pas une opportunité. Ces valeurs ne sont pas indispensables à l'Agilité.

C) Un Manifeste Agile ou Logiciel ?

Le Manifeste parle toujours de logiciel. Pourquoi utiliser un plan de Romorantin pour visiter Naples ?

Le Manifesto n'est PAS une référence en Agilité MAIS en développement logiciel.

Critique des 4 valeurs

A) « Les individus et leurs interactions plus que les processus et les outils »

1. Ce n'est pas spécifique à l'Agilité. N'importe quel bon manager le dit depuis toujours.
2. Cela donne la fausse image que l'Agilité ne valorise pas les processus. Or une équipe agile a besoin de processus solides, adaptés et évolutifs.
3. En industrie, les outils et processus sont souvent réglementaires (normes, certifications). Suggérer qu'ils passent au second plan est irréaliste.
4. Cette valeur éloigne les industriels de l'Agilité au lieu de les attirer.

B) « Des logiciels opérationnels plus qu'une documentation exhaustive »

1. Cette valeur enferme l'Agilité dans le développement logiciel. Pourquoi parler de logiciels dans un manifeste censé définir l'Agilité en général ?
2. Elle confond le chemin et le résultat. La documentation n'est pas l'ennemi, la documentation inutile l'est.
3. En industrie, la documentation est vitale : traçabilité, certification, sécurité, transfert de compétences.
4. Cette formulation donne l'impression que l'Agilité est synonyme de « pas de doc », ce qui est faux et dangereux.

C) « La collaboration avec les clients plus que la négociation contractuelle »

1. Collaborer sans contrat est le meilleur moyen de couler une entreprise. Les contrats protègent les deux parties. On peut collaborer ET avoir des contrats clairs.
2. Ce n'est pas non plus un différenciateur de l'Agilité : toute entreprise saine cherche à collaborer avec ses clients.

D) « L'adaptation au changement plus que le suivi d'un plan »

1. C'est LA différence clé. S'adapter au changement plutôt que de suivre un plan rigide, c'est précisément ce qui définit l'Agilité.
2. Cette seule valeur aurait dû constituer l'intégralité du Manifeste. Tout le reste en découle.

Critique des 12 principes

1. « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

Satisfaire le client est l'objectif de toute entreprise, agile ou non. « Livrer rapidement et régulièrement » est pertinent pour du logiciel livré en continu, mais inadapté à un satellite ou un médicament. Le terme « fonctionnalités » ancre encore le propos dans le logiciel.

=> Principe générique déguisé en spécificité agile.

2. « Accueillez positivement les changements de besoins, même tard dans le projet. »

C'est un bon principe, mais sa formulation est naïve. En industrie, un changement tardif peut coûter des millions et retarder de plusieurs années. L'Agilité ne consiste pas à accueillir tout changement les bras ouverts, mais à s'organiser pour absorber les changements inévitables au moindre coût.

=> L'intention est bonne, la formulation est irresponsable hors logiciel.

3. « Livrez fréquemment un logiciel opérationnel, avec des cycles de quelques semaines à quelques mois. »

Là encore, du logiciel. Les cycles de quelques semaines sont un luxe du numérique. En aéronautique, un cycle de test peut durer 18 mois. Cela ne signifie pas que l'équipe n'est pas agile.

=> Principe valide en logiciel, inapproprié comme référence universelle.

4. « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »

Travailler « ensemble quotidiennement » ? En industrie, le client final est rarement disponible tous les jours. Et les « développeurs » sont des chercheurs, des ingénieurs, des techniciens. Ce vocabulaire exclut.

=> Principe tourné logiciel, difficile à transposer tel quel.

5. « Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le soutien dont ils ont besoin et faites-leur confiance. »

Magnifique. Et totalement universel. N'importe quel bon manager signe des deux mains, agile ou non. Ce principe n'a rien de spécifiquement agile.

=> Bon sens managérial, pas de l'Agilité.

6. « La méthode la plus simple et la plus efficace pour transmettre de l'information est le dialogue en face à face. »

Vrai en 2001, plus nuancé en 2025 avec les équipes distribuées et le télétravail. Ce n'est pas non plus spécifique à l'Agilité.

=> Conseil de communication générique, daté.

7. « Un logiciel opérationnel est la principale mesure d'avancement. »

Encore du logiciel. Et surtout, c'est faux même en logiciel : un logiciel opérationnel mais inutile ne mesure aucun avancement. La vraie mesure, c'est la réduction du risque et de l'incertitude.

=> Faux, même dans son domaine d'origine.

8. « Les processus agiles encouragent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient maintenir indéfiniment un rythme constant. »

Bon principe pour éviter le burn-out, mais pas spécifique à l'Agilité. La gestion traditionnelle aussi recommande un rythme soutenable. En pratique, les sprints Scrum créent souvent plus de pression que le cycle en V.

=> Conseil de bon sens, pas un différenciateur agile.

9. « Une attention continue à l'excellence technique et à une bonne conception renforce l'Agilité. »

L'excellence technique renforce tout, pas seulement l'Agilité. Paradoxalement, ce principe contredit l'image véhiculée par le Manifeste lui-même (moins de doc, moins de processus).

=> Vrai, universel, et en contradiction interne avec le Manifeste.

10. « La simplicité, c'est-à-dire l'art de minimiser la quantité de travail inutile, est essentielle. »

Principe fondamental du Lean, pas de l'Agilité. Minimiser le travail inutile est un objectif universel. Aucune méthodologie ne recommande de maximiser le travail inutile.

=> Emprunt au Lean présenté comme spécifiquement agile.

11. « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. »

L'auto-organisation est un idéal séduisant, mais rarement applicable tel quel. En industrie, les architectures et spécifications sont souvent contraintes par des normes, des brevets, des choix stratégiques. L'équipe n'est pas seule décisionnaire.

=> Idéaliste et déconnecté des réalités industrielles.

12. « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

Excellent principe. Mais c'est de l'Amélioration Continue, pilier de la Qualité depuis les années 1950. La roue de Deming (PDCA) faisait déjà exactement cela.

=> Emprunt à la Qualité, pas une invention de l'Agilité.

Le Manifesto, quel rôle aujourd'hui ?

Un agiliste chevronné comprend ce qui se cache derrière le Manifeste : l'esprit, l'intention, les non-dits. Mais un spécialiste traditionnel qui le découvre en est induit en erreur. Il y lit « pas de doc, pas de plan, pas de contrat » et conclut que l'Agilité est du chaos organisé.

Pourtant, l'Agilité fonctionne dans tous les domaines industriels. Nos références clients le démontrent au quotidien. Le problème n'est pas l'Agilité, c'est son Manifeste.

Le Manifesto V2 en Industrie

Chez SolidCreativity, nous avons mis à jour les 4 valeurs et les 12 principes pour l'industrie. Cette version est disponible lors de nos formations Agilité pour l'Industrie.

Mise à jour : La V2 ne porte finalement pas ce nom, jugé trop présomptueux. De plus, elle est uniquement mise à disposition des personnes ayant suivi l'une de nos formations agiles.

[1] Pascal Jarry est fondateur et directeur pédagogique de SolidCreativity. Il accompagne les équipes R&D industrielles dans leur transition vers l'Agilité hors logiciel depuis plus de 15 ans.

[2] Cet article s'inspire en partie d'un article de la SIA (Société des Ingénieurs de l'Automobile) qui a alimenté la réflexion initiale.

Vous souhaitez en discuter ? Contactez-nous.