Commençons par la conclusion : les méthodes agiles ne conviennent pas à tous les projets. Ce n’est pas une critique de l’agilité, c’est un constat de terrain, et il mérite d’être argumenté.

Personne ne conteste plus les forces des approches agiles, cycle en V compris chez ceux qui les pratiquent. Elles restent pourtant inégales dans ce qu’elles apportent, et l’une de leurs limites est structurelle.

L’équipe de notre CRM automatisable et flexible vous dit tout.

À quoi sert une méthode de gestion de projet

La question paraît triviale, elle ne l’est pas. Dans les faits, la méthode la plus répandue sur les projets informatiques reste l’absence de méthode, parfois érigée en principe avec un humour qui ne trompe personne.

On entend fréquemment des chefs de projet affirmer « nous faisons de l’agile » alors que rien dans leur pratique ne s’y rattache. Ces méthodes ont bon dos pour justifier l’absence de processus.

Une méthode de gestion de projet est un processus qui permet de suivre une organisation prédéfinie, en validant étape après étape ce qui a été accompli et ce qui reste à faire.

Ce qu’elle n’est pas : une garantie de réussite, ni un moyen d’obtenir un planning immuable. L’essence d’un planning est d’être modifié.

Les fausses faiblesses de l’agile

Contrairement aux méthodes plus structurées, et plus contraignantes, les approches agiles consistent en un ensemble de bonnes pratiques applicables en tout ou partie. Deux malentendus reviennent constamment.

Confondre agilité et absence de rigueur

C’est l’erreur la plus fréquente. Ces méthodes exigent au contraire une rigueur absolue dans leur application.

L’exemple le plus flagrant concerne la documentation. Beaucoup considèrent que l’agile en dispense. C’est faux : documenter est une pratique agile au même titre que les autres, et elle s’y exerce avec la même exigence. Ce n’est donc pas une faiblesse de la méthode, c’est une faiblesse de ceux qui l’appliquent mal.

Croire qu’on peut choisir ses pratiques sans expérience

Il n’est pas obligatoire de respecter chaque pratique à la lettre, mais il faut en respecter l’esprit. Or cet esprit ne s’acquiert pas en lisant un livre.

Il faut avoir mené des projets, s’être heurté aux limites des différentes approches, avoir vu ce qui casse. C’est à cette condition seulement que l’on sait quelles pratiques associer, chaque projet étant un cas particulier.

Les vraies faiblesses

Commençons par les forces, qui sont réelles :

• la planification par cycles courts permet de s’adapter à l’évolution inévitable du périmètre, et évite l’effet tunnel pendant lequel le client n’a aucune visibilité ;
• la validation successive par les utilisateurs évite le rejet des livrables en fin de projet ;
• les rituels de suivi donnent une visibilité quotidienne sur l’avancement.

Face à cela, deux inconvénients majeurs, rarement énoncés.

La conception devient elle aussi itérative

Découvrir les besoins par itérations signifie concevoir l’application par itérations. Sur un projet complexe, un besoin majeur découvert à mi-parcours peut remettre en cause l’architecture retenue et déjà construite.

Le risque est alors de devoir reprendre tout ou partie du projet. Ce n’est pas un cas d’école, c’est ce qui arrive quand la complexité fonctionnelle dépasse ce que quelques itérations permettent d’anticiper.

L’agilité suppose de la souplesse sur le budget et le délai

Un projet agile ne réussit que s’il existe une marge sur le budget et le calendrier. Or dans une relation contractuelle, le client attend un engagement ferme sur le périmètre, qui prend la forme d’un cahier des charges détaillé.

Sans ce cahier des charges au démarrage, ou au moins avant la réalisation, le projet risque de ne jamais aboutir, précisément à cause des évolutions de périmètre que la méthode autorise. C’est pourquoi, malgré ce qu’en disent beaucoup de prestataires, l’agilité s’accorde mal avec un contrat au forfait.

Alors, quelle méthode choisir ?

Le choix dépend du contexte du projet et du niveau de confiance entre les parties. Et même quand cette confiance existe, il est souvent plus avisé d’adopter tout ou partie d’un cycle plus structuré.

Le cycle en V a encore de beaux jours devant lui, notamment sur les projets à périmètre contractuel ferme. Les approches rapides comme le RAD et le JAD constituent une voie intermédiaire, et l’agilité prend tout son sens sur des projets où le périmètre peut légitimement bouger, comme nous le détaillons pour les projets menés sur plateforme low-code.

Vos questions sur les méthodes agiles

L’agile convient-il aux petits projets ?

Souvent oui, et c’est même là qu’il est le plus simple à appliquer. Peu d’interlocuteurs, un périmètre restreint et une conception qui tient dans une tête réduisent fortement le risque de remise en cause en cours de route.

Peut-on mélanger cycle en V et agile ?

Oui, et c’est fréquent en pratique. Une phase de cadrage structurée suivie d’une réalisation itérative réunit l’engagement sur le périmètre et la souplesse d’exécution.

Faut-il un cahier des charges en mode agile ?

Dès qu’il y a un contrat, oui. Sans engagement écrit sur le périmètre, la souplesse profite à une partie et se paie par l’autre, ce qui finit toujours mal.

Comment savoir si une équipe fait vraiment de l’agile ?

Regardez si elle produit et met à jour de la documentation. Une équipe qui invoque l’agilité pour ne pas documenter n’en fait pas : elle improvise avec un vocabulaire emprunté.

L’agile réduit-il les délais ?

Pas nécessairement. Il réduit le délai avant les premiers livrables utilisables, ce qui n’est pas la même chose que le délai total, souvent équivalent voire supérieur si le périmètre s’étend.