Ce cas pratique suit une équipe qui développe une application de fidélité client, et qui sert de fil rouge pour tout le module.

Étape 1 — Reconnaître le problème de l'approche classique (leçon 1) : au départ, l'équipe avait prévu de spécifier toute l'application en détail avant de coder quoi que ce soit. Elle réalise que les besoins des clients autour du programme de fidélité ne sont pas encore totalement clairs, et qu'un plan figé à l'avance risquerait de découvrir les écarts trop tard.

Étape 2 — Choisir de travailler par étapes courtes (leçon 1) : l'équipe décide de livrer une première version simple en quelques semaines, pour recueillir des retours réels plutôt que de deviner les besoins pendant des mois.

Étape 3 — Appliquer les valeurs agiles (leçon 2) : plutôt que de rédiger une documentation exhaustive avant de commencer, l'équipe préfère montrer rapidement un résultat qui fonctionne, quitte à l'ajuster ensuite avec le client.

À retenir : l'agilité n'est pas une absence de méthode — c'est un choix délibéré de privilégier les retours fréquents et l'adaptation plutôt qu'un plan figé, quand le besoin n'est pas encore totalement clair.

À vous de jouer : pour un projet que vous menez ou imaginez, identifiez un aspect du besoin qui pourrait encore évoluer, et qui justifierait une approche agile plutôt que tout planifier à l'avance.