L'agilité n'est pas universelle. La présenter comme la seule bonne façon de travailler dessert la cause. Plusieurs contextes lui conviennent mal.

Le besoin est clair, stable et bien compris

Reproduire une installation déjà faite dix fois, appliquer une réglementation précise : le besoin ne bougera pas, les boucles de feedback n'apprennent rien de nouveau. Une planification classique est plus efficace.

Le coût de chaque livraison intermédiaire est prohibitif

Couler une dalle de béton, imprimer 100 000 exemplaires : on ne livre pas « une version partielle » à moindres frais. L'itération perd son intérêt quand chaque incrément coûte presque autant que le tout.

L'environnement impose une spécification complète d'emblée

Certains marchés publics, certains domaines critiques (aéronautique, dispositifs médicaux) exigent un cahier des charges validé et figé avant de commencer. On peut être agile à l'intérieur des phases, mais pas sur la structure globale.

Pas d'accès à un retour réel

Sans utilisateur, client ou testeur disponible régulièrement, la boucle de feedback tourne à vide. L'agile devient alors un rituel sans substance.

Le cas fréquent : l'hybride

La plupart des projets réels mélangent. On planifie fermement ce qui est stable et coûteux à changer (l'infrastructure, les contrats, une date de lancement) et on travaille en itérations ce qui est incertain (les fonctionnalités, l'ergonomie, le contenu). Le module « Gestion de projet » détaille l'approche prédictive ; ce module, l'itérative ; les deux se combinent.

Exemple concret : pour l'application de fidélité, le choix de l'hébergement et la conformité au traitement des données personnelles sont traités en amont, une fois, de façon classique. Les écrans, les règles de points et les notifications sont développés en sprints, ajustés au fil des retours clientes.

À vous de jouer : citez un projet ou une partie de projet pour lequel une approche classique serait plus adaptée que l'agile, et pourquoi.