L'agilité n'est pas née d'une seule méthode. En 2001, dix-sept praticiens du développement logiciel, venus d'approches différentes, se réunissent et rédigent un texte court : le manifeste agile.

Ce qu'ils avaient en commun

Ils travaillaient déjà, chacun de leur côté, avec des méthodes légères : Scrum, Extreme Programming, et d'autres moins connues. Toutes réagissaient au même constat : les processus lourds, centrés sur la documentation et la validation par étapes, produisaient souvent des logiciels livrés en retard et à côté du besoin réel.

Ce que le manifeste a apporté

Il n'a pas inventé de technique. Il a nommé ce que ces méthodes partageaient : quatre valeurs (leçon suivante) et douze principes (vus au chapitre « Aller plus loin »). Le mot « agile » a été choisi comme terme générique, à la place de « léger », jugé trop dévalorisant.

Ce que le manifeste n'est pas

Ce n'est pas une méthode. On ne « fait » pas le manifeste : on l'utilise comme boussole pour choisir entre Scrum, Kanban, XP ou une combinaison, selon le contexte. Une équipe peut être parfaitement agile sans jamais avoir lu le manifeste, et parfaitement rigide tout en récitant ses valeurs.

Pourquoi connaître cette origine

Elle rappelle que l'agilité est d'abord une réponse à un problème concret — livrer utile dans l'incertitude — et non un ensemble de rituels à appliquer pour eux-mêmes. Chaque fois qu'une pratique agile semble absurde, la bonne question est : « quel problème cette pratique cherchait-elle à résoudre ? »

Exemple concret : l'équipe de l'application de fidélité hésite à documenter chaque écran avant de coder. Le manifeste ne dit pas « ne documentez rien » : il dit qu'un écran qui fonctionne et qu'on peut montrer à une cliente vaut mieux qu'un cahier de specs de trente pages que personne ne relira.

À vous de jouer : citez le problème concret auquel le manifeste agile répondait, en une phrase.