Méthode agile : comprendre Scrum, Kanban et Lean pour choisir la bonne approche

La méthode agile est une approche de gestion de projet qui découpe le travail en courtes itérations, livre régulièrement un résultat utilisable et ajuste le plan en fonction des retours, au lieu de tout planifier en détail dès le départ. Scrum, Kanban et Lean sont les trois façons les plus répandues de la mettre en pratique.

Ce guide s’adresse aux chefs de projet, managers, Product Owners, futurs Scrum Masters et professionnels en reconversion. Vous y comprendrez les fondements de l’agilité, le fonctionnement concret de Scrum et de Kanban, l’apport du Lean, et surtout comment choisir, ou combiner, ces approches selon votre contexte.

Qu’est-ce que la méthode agile ?

La méthode agile regroupe des approches de travail itératives et incrémentales, fondées sur le Manifeste pour le développement agile de logiciels, publié en 2001. Elles privilégient la collaboration, la livraison fréquente d’un produit utilisable et l’adaptation au changement, plutôt que le respect strict d’un plan établi au départ.

Le Manifeste agile repose sur quatre valeurs. Ses auteurs reconnaissent la valeur des éléments de droite, mais privilégient ceux de gauche :

On valorise davantage…	…que
Les individus et leurs interactions	Les processus et les outils
Un logiciel qui fonctionne	Une documentation exhaustive
La collaboration avec le client	La négociation contractuelle
L’adaptation au changement	Le suivi d’un plan

Ces valeurs se déclinent en douze principes, parmi lesquels : satisfaire le client en livrant tôt et régulièrement, accueillir les changements de besoins même tardifs, faire travailler ensemble au quotidien les métiers et les développeurs, mesurer l’avancement par ce qui fonctionne réellement, et s’améliorer à intervalles réguliers.

Agile ou cycle en V : deux logiques opposées

En gestion de projet dite prédictive (cycle en V, cascade), on fixe le périmètre au départ, puis on estime le coût et le délai. En agilité, on inverse souvent la logique : le délai (la durée des itérations) et le coût (l’équipe) sont fixés, et c’est le périmètre qui s’ajuste, en livrant en priorité ce qui a le plus de valeur.

Ce triangle coût-délai-périmètre explique pourquoi l’agilité convient aux projets incertains : quand on ne peut pas tout savoir à l’avance, mieux vaut livrer vite une première version, apprendre, puis ajuster.

Pourquoi adopter une méthode agile ?

Les bénéfices recherchés par les organisations qui passent à l’agilité sont assez constants :

• Livrer de la valeur plus tôt : une première version utile arrive en quelques semaines, pas en fin de projet.
• Réduire le risque : chaque itération est une occasion de vérifier que l’on construit le bon produit.
• S’adapter : une priorité qui change n’oblige pas à tout replanifier.
• Rendre le travail visible : tableaux, démonstrations régulières, objectifs partagés.
• Maîtriser le budget : le coût d’une itération est connu, et le client décide à chaque étape s’il continue d’investir.
• Améliorer l’équipe : les rétrospectives transforment les difficultés en actions concrètes.

L’agilité n’est pas pour autant une solution universelle. Un projet au périmètre parfaitement connu et stable, soumis à des contraintes réglementaires fortes, peut rester plus simple à mener de façon prédictive.

Comment mettre en place Scrum : les étapes

Scrum est le cadre agile le plus utilisé. Il est défini dans le Guide Scrum, rédigé par ses créateurs Ken Schwaber et Jeff Sutherland, dont la dernière version date de 2020. Voici comment le mettre en place pas à pas.

Étape 1 — Définir les trois responsabilités

Une équipe Scrum est petite, généralement dix personnes ou moins, et comprend :

• Le Product Owner : il maximise la valeur du produit. Il gère le Product Backlog, fixe les priorités et représente les besoins des utilisateurs et des parties prenantes.
• Le Scrum Master : il garantit la bonne application de Scrum, aide l’équipe à s’améliorer et lève les obstacles. Ce n’est pas un chef de projet qui distribue les tâches.
• Les développeurs : les personnes qui réalisent le travail de chaque sprint, quel que soit leur métier (développement, test, design, rédaction…).

Étape 2 — Construire le Product Backlog

Le Product Backlog est la liste ordonnée de tout ce qui pourrait être fait sur le produit. Ses éléments sont souvent rédigés sous forme de user stories, qui décrivent un besoin du point de vue de l’utilisateur :

En tant que <type d'utilisateur>,
je veux <action ou fonctionnalité>,
afin de <bénéfice attendu>.

Exemple :
En tant que client, je veux suivre ma commande en ligne,
afin de savoir quand je serai livré sans appeler le service client.

Critères d'acceptation :
- le statut de la commande s'affiche dans l'espace client ;
- le client reçoit une notification à l'expédition.

Le Product Owner place en haut les éléments qui apportent le plus de valeur. Le backlog est vivant : il est affiné en continu avec l’équipe.

Étape 3 — Planifier le sprint

Le sprint est une période fixe d’un mois maximum, pendant laquelle l’équipe produit un incrément utilisable. Il commence par le Sprint Planning (huit heures maximum pour un sprint d’un mois, moins pour un sprint plus court), où l’équipe répond à trois questions :

1. Pourquoi ce sprint a-t-il de la valeur ? L’équipe définit l’objectif du sprint.
2. Quoi : quels éléments du Product Backlog peuvent être réalisés ?
3. Comment : comment l’équipe va-t-elle s’organiser pour les réaliser ?

Le résultat est le Sprint Backlog : l’objectif du sprint, les éléments sélectionnés et le plan pour les livrer.

Étape 4 — Synchroniser l’équipe avec la mêlée quotidienne

Le Daily Scrum est un point de quinze minutes, chaque jour, à la même heure. Les développeurs y inspectent leur progression vers l’objectif du sprint et ajustent leur plan. Ce n’est pas un compte rendu au manager : c’est un moment d’organisation de l’équipe. Les sujets qui demandent une discussion plus longue sont traités juste après, avec les seules personnes concernées.

Étape 5 — Présenter le résultat lors de la revue de sprint

À la fin du sprint, la Sprint Review (quatre heures maximum pour un sprint d’un mois) réunit l’équipe et les parties prenantes. On y présente ce qui a été réalisé, on recueille les retours et on ajuste le Product Backlog. L’incrément présenté doit respecter la Definition of Done, la définition partagée de ce qu’est un travail « terminé » : testé, documenté, prêt à être livré.

Étape 6 — S’améliorer avec la rétrospective

La Sprint Retrospective (trois heures maximum pour un sprint d’un mois) clôt le sprint. L’équipe examine ses interactions, ses outils et sa façon de travailler, puis choisit une ou deux actions d’amélioration concrètes pour le sprint suivant. Un format simple consiste à demander à chacun ce qu’il faut commencer, arrêter et continuer. La rétrospective ne fonctionne que si chacun peut s’exprimer franchement ; notre guide sur la confiance en soi au travail donne des techniques utiles pour exprimer un désaccord de façon constructive.

En résumé, Scrum compte cinq événements (le sprint lui-même, le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective) et trois artefacts (Product Backlog, Sprint Backlog, Incrément), chacun associé à un engagement : l’objectif de produit, l’objectif de sprint et la Definition of Done.

Kanban : visualiser et optimiser le flux de travail

Kanban vient du système de production de Toyota, où des cartes (« kanban » en japonais) signalaient le besoin de réapprovisionner un poste. La méthode a été adaptée au travail intellectuel, notamment par David J. Anderson dans les années 2000. Contrairement à Scrum, elle ne crée ni rôle ni itération : on part de l’organisation existante et on l’améliore progressivement.

Concevoir son tableau Kanban

Un tableau Kanban représente chaque étape du travail par une colonne, et chaque tâche par une carte qui se déplace de gauche à droite :

| À faire | Analyse (2) | En cours (3) | En validation (2) | Terminé |
|---------|-------------|--------------|-------------------|---------|
| Carte F | Carte D     | Carte A      | Carte C           | Carte X |
| Carte G |             | Carte B      |                   | Carte Y |
|         |             | Carte E      |                   |         |

Les nombres entre parenthèses sont les limites de WIP. Ici, la colonne « En cours » a atteint sa limite de trois : personne ne peut y ajouter de carte tant qu’une tâche n’a pas avancé.

Les pratiques clés de Kanban

1. Visualiser le travail : toutes les tâches, y compris les demandes urgentes et les interruptions, apparaissent sur le tableau.
2. Limiter le travail en cours : c’est la pratique la plus efficace et la plus négligée. Moins de tâches en parallèle, c’est moins de changements de contexte et des délais plus courts.
3. Gérer le flux : on surveille le temps que mettent les tâches à traverser le tableau et on traite les blocages en priorité.
4. Rendre les règles explicites : ce qu’il faut pour passer d’une colonne à l’autre est écrit et partagé.
5. Mettre en place des boucles de retour : points réguliers pour examiner le flux et les améliorations possibles.
6. S’améliorer collectivement, par petites évolutions successives.

Mesurer pour améliorer

Deux indicateurs suffisent pour commencer : le délai (lead time, de la demande à la livraison) et le débit (throughput, nombre de tâches terminées par semaine). Ils sont liés au travail en cours par la loi de Little : en moyenne, le délai est égal au travail en cours divisé par le débit. Réduire le WIP, à débit constant, réduit donc mécaniquement les délais.

Lean management : éliminer les gaspillages

Le Lean est issu du système de production de Toyota, formalisé notamment par Taiichi Ohno. Le terme « lean » a été popularisé au début des années 1990 par des chercheurs du MIT qui étudiaient l’industrie automobile. James Womack et Daniel Jones en ont ensuite résumé la démarche en cinq principes :

1. Définir la valeur du point de vue du client.
2. Identifier la chaîne de valeur : toutes les étapes qui mènent au résultat.
3. Créer un flux continu, sans attente ni interruption.
4. Tirer la production à partir de la demande réelle (flux tiré), plutôt que de produire à l’avance.
5. Viser la perfection par l’amélioration continue.

Le Lean identifie traditionnellement sept gaspillages (muda), auxquels on ajoute souvent un huitième :

Gaspillage	Exemple dans un projet ou un service
Surproduction	Développer des fonctionnalités que personne n’a demandées
Attente	Une tâche bloquée plusieurs jours dans l’attente d’une validation
Transport	Transmettre un dossier entre de nombreux services
Traitements inutiles	Des rapports que personne ne lit
Stocks	Des dizaines de tâches commencées et non terminées
Mouvements inutiles	Chercher une information dans plusieurs outils
Défauts	Les erreurs qu’il faut corriger après livraison
Talents inexploités	Des compétences de l’équipe qui ne sont pas sollicitées

Le Lean n’est pas une méthode de réduction des effectifs : c’est une démarche qui supprime ce qui n’apporte pas de valeur, pour consacrer le temps de l’équipe à ce qui en apporte.

Scrum vs Kanban vs Lean : quelle méthode choisir ?

Critère	Scrum	Kanban	Lean
Nature	Cadre de travail	Méthode de gestion du flux	Philosophie de management
Rythme	Sprints fixes d’un mois maximum	Flux continu	Amélioration continue
Rôles	Product Owner, Scrum Master, développeurs	Aucun rôle imposé	Aucun rôle imposé
Changement en cours de route	Protégé pendant le sprint, intégré au suivant	Possible à tout moment	Selon la demande réelle
Indicateurs typiques	Atteinte de l’objectif de sprint	Délai, débit, travail en cours	Valeur, gaspillages, qualité
Idéal pour	Développement de produit	Support, maintenance, flux de demandes	Optimisation de processus

En pratique, beaucoup d’équipes les combinent. Une équipe Scrum peut ajouter des limites de WIP à son tableau de sprint : on parle parfois de « Scrumban ». Une équipe support peut fonctionner en Kanban tout en tenant une rétrospective mensuelle. Les principes Lean servent de fil rouge à toutes ces approches.

L’agilité s’articule aussi avec d’autres référentiels. ITIL 4 intègre explicitement des principes agiles comme la progression itérative et la visibilité, comme le montre notre guide ITIL 4 Foundation. Et côté gestion de projet, le PMI intègre les approches agiles et hybrides à ses référentiels : notre guide de la certification PMP détaille ce cadre.

Les erreurs fréquentes dans l’adoption de l’agilité

• Adopter les rituels sans l’état d’esprit : un Daily Scrum qui devient un reporting au manager n’a plus rien d’agile.
• Transformer le Scrum Master en chef de projet qui distribue les tâches et contrôle.
• Un Product Owner indisponible : sans priorités claires, l’équipe travaille sur ce qui n’a pas le plus de valeur.
• Surcharger les sprints : s’engager sur trop d’éléments garantit de ne pas atteindre l’objectif.
• Ignorer les limites de WIP : un tableau Kanban sans limite n’est qu’une liste de tâches colorée.
• Supprimer les rétrospectives « faute de temps » : c’est pourtant le moteur de l’amélioration.
• Oublier le budget : l’agilité ne dispense pas de suivre les coûts ; un simple suivi dans un tableur, comme ceux présentés dans notre guide Excel pour la comptabilité et la finance, permet de relier chaque sprint à sa consommation budgétaire.

Comment se former à la méthode agile ?

Voici un parcours progressif pour passer de la théorie à la pratique :

1. Comprendre les fondamentaux : Manifeste agile, valeurs, principes, et différence avec l’approche prédictive.
2. Lire le Guide Scrum, court et disponible gratuitement en français sur le site officiel de Scrum, puis simuler un sprint sur un petit projet.
3. Mettre en place un tableau Kanban pour votre propre travail, avec une limite de WIP.
4. Observer les gaspillages de votre activité et en supprimer un par mois.
5. Envisager une certification si votre métier l’exige : les organismes Scrum proposent des certifications de Scrum Master et de Product Owner, et le PMI propose la PMI-ACP.

Pour acquérir ces bases de manière structurée, la formation d’EspritAcadémique sur Agile, Scrum, Kanban et Lean propose 1 h 20 de contenu pratique, sans prérequis. Elle aborde notamment :

• les fondamentaux de l’agilité et du Lean, et leurs bénéfices ;
• l’équilibre entre coût, délai et périmètre, et la gestion du budget projet ;
• les rôles, les responsabilités et les rituels de Scrum, du Sprint Planning à la rétrospective ;
• un exemple concret de projet mené avec Scrum ;
• la conception d’un système Kanban et ses différences avec Scrum ;
• l’articulation de ces méthodes avec les standards du PMI.

En résumé

La méthode agile repose sur un état d’esprit : livrer souvent, apprendre des retours et s’adapter. Scrum l’applique avec des sprints, trois responsabilités et cinq événements ; Kanban avec un tableau visuel et des limites de travail en cours ; le Lean avec la chasse aux gaspillages. Choisissez Scrum pour construire un produit, Kanban pour gérer un flux de demandes, et laissez les principes Lean guider l’amélioration continue dans les deux cas.