Qu’est-ce que la méthode Agile ?
La méthode Agile n’est pas une méthode unique, mais une famille de pratiques de gestion de projet qui partagent le même parti pris : découper le travail en cycles courts, livrer quelque chose d’utilisable à la fin de chaque cycle, et ajuster la suite en fonction de ce qu’on a appris.
Le point de départ est le Manifeste Agile, rédigé en 2001 par dix-sept praticiens du développement logiciel. Il tient en quatre valeurs et douze principes, et sa formule la plus reprise résume l’esprit du texte : préférer la réponse au changement au suivi d’un plan.
Le Manifeste ne décrit aucun rituel, aucun rôle et aucun outil. Ce sont les cadres qui s’en réclament, Scrum en tête, qui apportent cette mécanique.
Agile ou cycle en V : quelle différence ?
Le cycle en V, encore très présent en France dans l’industrie et les grands comptes, enchaîne les phases dans l’ordre : spécifications, conception, développement, puis une série de tests qui répondent une à une aux phases de définition. Chaque étape se termine avant que la suivante ne commence, et le périmètre est figé au départ.
Agile inverse le raisonnement. Le périmètre reste ouvert, le budget et le délai sont fixés, et l’équipe livre par tranches successives. On accepte de ne pas savoir dès le début ce que contiendra la version finale.
Ce choix n’est pas universellement supérieur. Un projet dont les exigences sont réglementaires, stables et validées à l’avance, comme un système embarqué certifié, s’accommode mal d’un périmètre mouvant. Agile prend l’avantage quand l’incertitude porte sur le besoin lui-même.
Scrum, Kanban, SAFe : quel cadre pour quoi ?
Scrum est le cadre le plus répandu. Il repose sur des sprints de une à quatre semaines, trois responsabilités (Product Owner, Scrum Master, développeurs), et des rendez-vous fixes : planification, point quotidien, revue, rétrospective.
Kanban ne découpe pas le temps en sprints. Il visualise le flux de travail sur un tableau et limite le nombre de tâches en cours par colonne, ce qui rend visibles les goulets d’étranglement. Il convient mieux aux équipes dont l’arrivée du travail est imprévisible, comme le support ou l’exploitation.
SAFe, LeSS et les autres cadres dits « à l’échelle » cherchent à coordonner plusieurs dizaines d’équipes. Ils ajoutent des niveaux de planification et des rôles, ce qui leur vaut le reproche de réintroduire la lourdeur que l’agilité prétendait supprimer.
Extreme Programming (XP) est plus ancien et plus technique : tests automatisés, intégration continue, programmation en binôme, remaniement permanent du code. Beaucoup d’équipes qui se disent Scrum empruntent en réalité leurs pratiques d’ingénierie à XP.
Comment se déroule un projet Agile ?
Le besoin est consigné dans une liste ordonnée, le backlog, tenue par une personne responsable des priorités. Rien n’y est figé : les éléments se reformulent, se découpent ou disparaissent.
L’équipe prend en charge le haut de cette liste pour le cycle en cours, produit une version fonctionnelle, la montre, et recueille les retours. Elle se réunit ensuite pour examiner sa propre façon de travailler, ce qu’on appelle la rétrospective.
Le cycle suivant intègre à la fois les retours sur le produit et les décisions prises sur le fonctionnement de l’équipe. C’est cette double boucle qui distingue un projet réellement agile d’un projet en cascade découpé en sprints.
Ce qui fait échouer un projet Agile
Les cas d’échec se ressemblent d’une entreprise à l’autre. Un Product Owner sans mandat réel, obligé de faire valider chaque arbitrage ailleurs, bloque toute la chaîne de décision.
Vient ensuite l’agilité de façade : les rituels sont tenus, le tableau est à jour, mais la date de livraison et le périmètre ont été gravés dans le contrat six mois plus tôt. L’équipe fait du reporting déguisé en rétrospective.
Dernier écueil, la dette technique laissée de côté sprint après sprint. Livrer vite sans tests automatisés fonctionne pendant six mois, puis chaque nouvelle fonctionnalité casse une fonctionnalité existante.
Exemples ou cas d’usage concrets
Une équipe produit lance une application mobile avec un périmètre volontairement réduit : inscription, recherche, réservation. Les fonctions suivantes sont arbitrées à partir de l’usage réel, ce qui évite de développer des écrans que personne n’ouvre.
Une équipe de recrutement suit ses postes sur un tableau Kanban et limite le nombre de recherches ouvertes en parallèle. Le délai moyen de recrutement baisse, non parce que l’équipe travaille plus, mais parce qu’elle traite moins de dossiers à la fois.
Un service informatique interne fonctionne en flux continu pour les demandes courantes et en sprints pour les projets. Mélanger les deux dans une même équipe conduisait auparavant à sacrifier systématiquement le projet à l’urgence.
Une direction marketing organise ses campagnes par cycles de deux semaines, avec une revue à chaque fin de cycle. L’adaptation la plus difficile n’a pas été le rythme, mais l’acceptation de montrer un travail inachevé.
Les métiers de l’agilité et ce que valent les certifications
Trois intitulés dominent les annonces, et ils recouvrent des responsabilités bien distinctes.
- Product Owner : porte la valeur produit, arbitre les priorités du backlog, tranche entre les demandes concurrentes. Ce n’est pas un secrétaire de comité de pilotage.
- Scrum Master : lève les obstacles, fait progresser les pratiques de l’équipe, protège son fonctionnement. Ce n’est pas un chef de projet, et l’amalgame reste la confusion la plus fréquente dans les fiches de poste.
- Coach agile : intervient au niveau de plusieurs équipes ou de l’organisation, souvent dans un contexte de transformation. Poste plus senior, moins nombreux, et davantage exposé aux missions de conseil.
Côté certifications, les plus citées sont PSM et PSPO (Scrum.org), CSM (Scrum Alliance) et les parcours SAFe. Elles s’obtiennent en quelques jours et attestent d’un vocabulaire commun, pas d’une expérience. Un candidat certifié qui n’a jamais animé de rétrospective difficile n’a pas encore fait le métier.
En entretien, la question qui trie le mieux est concrète : « racontez une fois où vous avez dû retirer une fonctionnalité du périmètre, et comment ça s’est passé avec le client ». Les réponses théoriques s’arrêtent là.