Non, les méthodes Agiles ne sont pas adaptées à tous les projets

Même s’il est inhabituel de commencer un article par sa conclusion, je vais tout de même étayer celle-ci dans les lignes qui suivent.

J’ai en effet eu l’occasion d’utiliser pas mal de méthodologies différentes de gestion de projet. Que ce soit des méthodes classiques telles que celles en cycle en V, ou des méthodes dites « Agiles » telles que l’eXtreme Programming, SCRUM ou encore RAD JAD.

Même s’il est vrai qu’aujourd’hui plus personne ne questionne les forces des méthodologies dites « Agiles », il n’en reste pas moins qu’elles sont, d’une part, inégales dans les avantages qu’elles apportent mais surtout qu’elles ont, d’autre part, un défaut, une défaillance fondamentale.

Une méthode de gestion de projet : pourquoi faire?

Il semble trivial de poser cette question ici, mais détrompez-vous. De par mon expérience la méthode de projet que j’ai vu la plus utilisée dans les projets informatiques est : pas de méthode (certains dénomment ceci la méthode La RACHE). J’ai également beaucoup entendu des chefs de projets sérieux dire « Nous faisons de l’Agile » alors que dans la réalité des faits, les méthodes appliquées n’en étaient pas. Ces pauvres méthodes Agiles ont parfois bon dos pour justifier l’absence de processus!

Alors, pour répondre à la question : une méthode de gestion de projet est en réalité un processus qui va vous permettre de suivre pas à pas une organisation projet prédéfinie. L’idée étant de pouvoir valider étape après étape ce qui a été accompli et ce qui reste à faire.

Ce qu’une méthode de projet n’est pas, en revanche, c’est un moyen fiable à 100% de faire réussir vos projets, ou encore de vous fournir un planning ou des dates qui ne changeront pas dans le temps. J’ai en effet pour habitude de rappeler que l’essence d’un planning est d’être modifié.

Les fausses faiblesses des méthodes Agiles

Même si je fais un raccourci en mettant toutes les méthodes Agiles dans le même pot, celles-ci n’en gardent pas moins des similarités. Contrairement aux autres méthodes qui sont plus structurées (et contraignantes), les méthodes Agiles consistent bien souvent en un ensemble de bonnes pratiques qui peuvent être appliquées en tout en en partie.

Il n’est en effet pas nécessaire de respecter à lettre chaque méthode Agile. Par contre, il y a deux écueils dans lesquels tombent le plus souvent les gens « faisant de l’Agile » :

• Ils confondent Agile et « manque de rigueur ». Même si les méthodes Agiles sont un ensemble de pratiques, il n’en reste pas moins que celles-ci exigent une rigueur absolue dans leur application. L’exemple le plus flagrant est que bien souvent certains pensent que les méthodes Agiles ne demandent pas de documentation. C’est faux! La documentation est une pratique de l’Agile tout autant que les autres. Et rigoureuse de plus est. Ce n’est donc pas une faiblesse de ces méthodes.
• Comme je le disais les méthodes Agiles sont un ensemble de pratiques que l’on peut respecter en tout ou partie. Il n’est donc pas requis de respecter à la lettre toutes les pratiques, mais cela dit il faut savoir en respecter l’esprit. Comprendre l’esprit des méthodes Agiles ne se fait pas juste en lisant un livre. Il faut avoir pratiqué la gestion de projet, en comprendre les tenants et les aboutissants, avoir souffert des écueils des différentes méthodes. Bref il faut avoir de l’expérience. Ce n’est qu’à cette condition que l’on saura choisir les pratiques à associer pour mener à bien un projet, en sachant que chaque projet est unique et qu’il faudra faire preuve d’adaptabilité dans le choix des pratiques en fonction du contexte du projet.

Les vraies faiblesses des méthodes Agiles

Les méthodes « Agiles » favorisent, vous l’aurez deviné, l’agilité face à la complexité que peut représenter un projet informatique. Par exemple :

• La planification et la réalisation du projet par cycles courts permet d’être adaptable en fonction de l’évolution inévitable du périmètre du projet. Cette approche permet également d’éviter « l’effet tunnel » pendant lequel les clients du projet n’ont aucune visibilité sur les livrables.
• La validation successive du projet par les clients / utilisateurs permet d’éviter un rejet des livrables en fin de projet.
• Des règles de suivi du projet donnant une visibilité quotidienne sur l’avancement comme les daily standup (SCRUM).

En face des avantages apportés par les méthodes Agiles, il y a pourtant bien des inconvénients. Et ils sont majeurs. En voici les principaux :

• La réalisation du projet par itérations successives implique que la découverte des besoins se fasse aussi de la même manière. Le problème de cette approche est que la conception de l’application se fait également de manière itérative. Ayant adopté cette approche sur un projet complexe, nous avons découvert en milieu de projet des besoins utilisateurs qui ont remis en cause la conception que nous avions choisie et implémentée au fur et à mesure du projet. Dans ce type de cas, le risque est de devoir recommencer tout ou partie du projet!
• Un projet en mode Agile ne peut réussir que s’il existe un certain niveau de flexibilité sur les budgets et le planning. Lorsque vous êtes dans une relation contractuelle avec les clients ou les utilisateurs finaux, il est indispensable d’avoir un engagement de la part de ces derniers sur le périmètre du projet. Cet engagement prend la forme d’un cahier des charges complet et détaillé. Ne pas avoir ce cahier des charges en début de projet (ou dans une première phase – avant la réalisation) c’est prendre le risque d’arriver dans une situation où le projet n’aboutit pas, à cause des évolutions régulières du périmètre permises par les méthodes Agiles. C’est toute l’histoire de la poule et du cochon. Et c’est également pourquoi malgré ce que beaucoup de SSII vantent, je ne crois pas à une approche Agile dans le cadre d’un projet au forfait.

Il existe encore de nombreuses raisons contre l’utilisation des méthodes Agiles dans certains scénarios. Le choix d’une méthode Agile doit dépendre du contexte du projet et du niveau de confiance qui existe entre les acteurs. Et même lorsque la confiance est là, il est souvent plus avisé d’adopter tout ou partie du cycle en V. Le cycle en V a encore de beaux jours devant lui.