Les différentes méthodes agiles

Avant de parler de Scrum, de Kanban ou de tableaux remplis de post-its, il faut comprendre d'où vient l'agilité — et ce qu'elle est vraiment. Elle naît en 2001, quand dix-sept praticiens du logiciel se réunissent dans une station de ski de l'Utah pour poser par écrit ce qui, selon eux, fait réussir un projet. Le résultat tient sur une page : le Manifeste agile. Retiens ceci avant tout le reste : ce n'est pas une méthode, pas un mode d'emploi à appliquer à la lettre, c'est un état d'esprit. Toutes les méthodes que tu verras ensuite ne sont que des façons différentes d'incarner cet esprit.

Le contexte explique tout. Dans les années 90, le développement suit surtout des cycles « en V » : on spécifie tout au début, on développe pendant des mois, on livre à la fin. Problème, le monde change pendant ces mois, et les projets arrivent en retard, hors budget et à côté du besoin réel. Le Manifeste répond par un renversement de priorités, formulé en quatre valeurs.

Contexte historique

Crise du logiciel des années 90 : les projets livrent en retard, hors budget, hors besoin. Les cycles en V rigides ne supportent pas le changement. Réponse : un manifeste court qui change la priorité des choses.

Les 4 valeurs

• Individus et interactions plutôt que processus et outils
• Logiciel qui marche plutôt que documentation exhaustive
• Collaboration avec le client plutôt que négociation contractuelle
• Adaptation au changement plutôt que suivi d'un plan

La subtilité qui change tout tient dans deux mots : le Manifeste dit « plutôt que », jamais « au lieu de ». Il ne s'agit pas de jeter la documentation, les processus ou les plans — ils gardent leur utilité. Il s'agit de savoir ce qu'on privilégie en cas d'arbitrage : quand il faut choisir, on met en avant les personnes, le logiciel qui marche, la collaboration et l'adaptation. Quiconque te dit « c'est agile, donc on ne documente pas » ou « on ne planifie plus » a mal lu le texte : l'agilité n'est ni un dogme, ni une recette miracle, ni une excuse pour bâcler. Les douze principes qui accompagnent les quatre valeurs ne font que préciser cet esprit, comme le résume la liste suivante.

Les 12 principes en bref

• Livraisons fréquentes (semaines, pas mois)
• Accueil du changement, même tard dans le projet
• Équipes auto-organisées
• Rythme soutenable
• Simplicité (l'art de maximiser le travail à ne pas faire)
• Rétrospectives régulières pour s'améliorer

Scrum est, de loin, le framework agile le plus répandu — au point qu'on confond souvent « faire de l'agile » et « faire du Scrum ». C'est une erreur : Scrum est une façon d'appliquer l'agilité, très utile dans certains contextes, mal adaptée à d'autres. Son idée centrale est de découper le travail en itérations courtes et régulières (les sprints) pour livrer souvent, obtenir du feedback vite, et ajuster le cap. C'est une machine à cadence : elle donne un rythme prévisible à une équipe.

Scrum définit trois rôles, et les malentendus sur ces rôles sont la première cause de Scrum raté. Le Product Owner porte la vision et priorise le backlog — ce n'est pas un chef de projet qui distribue les tâches. Le Scrum Master est un facilitateur : il retire les obstacles et protège l'équipe — ce n'est pas un chef d'équipe ni un manager. L'équipe de développement, enfin, est pluridisciplinaire (5 à 9 personnes) et surtout auto-organisée : c'est elle qui décide comment atteindre l'objectif, pas une hiérarchie extérieure.

Le cœur de Scrum, c'est son rythme, fait d'événements et d'artefacts. Chaque sprint (une à quatre semaines, deux en pratique) s'ouvre par une planification, se rythme par un point quotidien de quinze minutes — orienté équipe, surtout pas reporting au manager — se conclut par une revue (démo de ce qui a été livré) et une rétrospective (ce qu'on garde, ce qu'on change). Côté artefacts, le Product Backlog liste tout ce qu'on aimerait faire, le Sprint Backlog ce qu'on s'engage à faire, et l'incrément ce qui est réellement livrable à la fin. Point clé : pendant le sprint, l'objectif est figé — on ne change pas le périmètre en cours de route.

Scrum a des forces réelles : cadence prévisible, transparence, boucle de feedback régulière. Mais il a aussi des limites qu'il faut assumer. Appliqués mécaniquement, ses rituels deviennent chronophages et vident de sens. Et il colle mal aux contextes de flux continu — support, exploitation, maintenance — où les urgences arrivent en permanence et cassent la belle mécanique du sprint. Si tes journées sont rythmées par l'imprévu plutôt que par un plan de deux semaines, Scrum va te frustrer, et c'est normal : le chapitre suivant présente l'approche taillée pour ça.

Les 3 rôles

• Product Owner : porte la vision, priorise le backlog. Pas un chef de projet
• Scrum Master : facilitateur, retire les blocages. Pas un chef d'équipe
• Équipe de développement : pluridisciplinaire, 5 à 9 personnes, auto-organisée

Les événements

• Sprint planning : on choisit les stories du prochain sprint
• Daily stand-up : 15 min max, debout, focus équipe (pas reporting au chef)
• Sprint review : démo de ce qui a été livré, feedback des parties prenantes
• Rétrospective : ce qu'on garde, ce qu'on change, on agit

Les artefacts

• Product Backlog : la liste de tout ce qu'on aimerait faire, priorisée
• Sprint Backlog : ce qu'on s'engage à faire dans le sprint
• Incrément : ce qui est potentiellement livrable à la fin du sprint

Le sprint

Une itération de 1 à 4 semaines (2 semaines = standard de facto). L'objectif est figé pendant le sprint : on ne change pas le scope en cours.

Kanban vient de l'industrie — le système de production Toyota — et repose sur une idée simple : au lieu de découper le temps en itérations, on optimise le flux du travail. Pas de sprint, pas d'engagement figé sur deux semaines : les tâches entrent, avancent et sortent en continu. Le premier geste est de rendre le travail visible sur un tableau dont les colonnes représentent les étapes (« À faire », « En cours », « Revue », « Terminé »), qu'on adapte à son propre processus. Voir le travail, c'est déjà mieux le piloter.

L'outil le plus puissant de Kanban, et le plus contre-intuitif, c'est la limite d'en-cours (WIP limit) : un nombre maximum de tâches autorisées par colonne. Quand une colonne est pleine, interdit d'en démarrer une nouvelle tant qu'on n'a pas fini une des tâches en cours. L'effet est immédiat et puissant : on finit avant de commencer, et le multitâche destructeur — cette illusion de productivité où l'on avance sur dix choses sans en terminer aucune — disparaît. Effet bonus : les blocages remontent tout de suite, parce qu'une colonne saturée force l'équipe à s'attaquer à ce qui coince plutôt qu'à l'ignorer.

La différence de fond avec Scrum tient en un mot : le flux tiré. En Scrum, l'équipe pousse du travail dans le sprint lors de la planification. En Kanban, elle tire une nouvelle tâche du backlog seulement quand elle a terminé la précédente. Plus fluide, moins de cérémonie. Pour piloter, on suit quelques métriques simples : le lead time (durée totale entre la création d'une tâche et sa fin), le cycle time (durée entre le début effectif du travail et sa fin) et le throughput (nombre de tâches finies par semaine). Kanban brille pour les équipes de support, de maintenance ou d'exploitation, et pour les solos ou très petites équipes où le cérémonial de Scrum serait trop lourd.

Le board

Colonnes typiques : À faire, En cours, Review, Terminé. Tu adaptes selon ton workflow (ajout de Bloqué, En staging, etc.). Le board visualise le flux.

WIP limits (Work In Progress)

• Tu fixes un nombre maximum de tâches par colonne
• Si la colonne est pleine, tu ne peux pas en ajouter avant d'avoir terminé une existante
• Effet immédiat : tu finis avant de commencer. Le multitâche destructeur disparaît
• Effet bonus : les blocages remontent vite (la colonne se bloque, on doit s'en occuper)

Flux tiré, pas poussé

En Scrum, l'équipe pousse du travail dans le sprint au planning. En Kanban, l'équipe tire une tâche du backlog quand elle a fini la précédente. Plus fluide, moins de cérémonie.

Les métriques

• Lead time : temps entre la création de la tâche et sa fin
• Cycle time : temps entre le début du travail et sa fin
• Throughput : nombre de tâches finies par semaine

L'eXtreme Programming (XP) est la grande oubliée des présentations sur l'agilité, alors qu'elle est peut-être la plus influente pour nous, développeur·euses. Là où Scrum et Kanban organisent le travail, XP s'attaque directement à la qualité du code. Son principe : prendre les bonnes pratiques techniques reconnues et les pousser à l'extrême. Puisque tester est bon, testons en permanence. Puisque la revue de code est utile, relisons-nous en continu à deux. C'est de cette philosophie que sont nées la plupart des pratiques qu'on considère aujourd'hui comme évidentes.

Les pratiques phares, détaillées ci-dessous, forment un tout cohérent. Le pair programming (deux dev, un clavier) réduit les bugs et diffuse la connaissance. Le développement piloté par les tests (TDD) écrit le test avant le code. Le refactoring continu améliore le code sans changer son comportement, en permanence plutôt qu'un jour « quand on aura le temps ». L'intégration continue fusionne et teste souvent. La propriété collective autorise chacun à modifier tout le code, sans chasse gardée. Et le client sur site garde une personne produit accessible en continu.

Même si peu d'équipes déclarent « faire du XP » aujourd'hui, son héritage est partout : l'intégration et le déploiement continus, le TDD, le refactoring, le pair programming viennent tous de là. C'est sans doute la méthode qui a le plus transformé le métier de développeur·euse. XP brille particulièrement avec des équipes techniques expérimentées et motivées, sur des contextes où la qualité est critique (santé, finance, systèmes embarqués) et sur des projets longs où la dette technique deviendrait vite un boulet. Sa contrepartie : elle exige une vraie discipline et de la maturité, ce qui la rend moins immédiate pour une équipe qui débute.

Les pratiques phares

• Pair programming : 2 devs, 1 clavier, moins de bugs, meilleur transfert de connaissances
• TDD (Test-Driven Development) : test d'abord, code après
• Refactoring continu : améliorer le code sans changer son comportement, en permanence
• Intégration continue : merger souvent, tester automatiquement (CI/CD)
• Propriété collective du code : tout le monde peut modifier tout, pas de chasse gardée
• Petites livraisons : déployer souvent, en petits incréments
• Client sur site : un PO accessible en continu, pas un sponsor lointain

Quand XP brille

• Équipes techniques senior, motivées
• Contextes où la qualité du code est critique (santé, finance, embarqué)
• Projets longs où la dette technique pèserait vite

Shape Up est une méthode plus récente, formalisée par l'entreprise Basecamp en 2019 dans un livre gratuit. Elle est née d'un constat : sur un produit déjà installé, avec une équipe expérimentée, la mécanique des sprints de deux semaines et du backlog infini devient plus une contrainte qu'une aide. Shape Up propose donc un autre rythme et une autre philosophie, taillés pour l'autonomie.

Ses concepts clés changent la façon de penser un projet. On travaille par cycles de six semaines, suivis de deux semaines de cooldown pour souffler, corriger les bugs et préparer la suite. Il n'y a pas de backlog qui gonfle à l'infini : avant d'engager un projet, on le shape, c'est-à-dire qu'on le cadre — ni trop vague, ni trop détaillé. On raisonne en appétit plutôt qu'en estimation : au lieu de demander « combien de temps ça va prendre ? », on décide « combien de temps j'accepte d'y consacrer », et on ajuste le périmètre pour tenir dedans. Une betting table décide périodiquement de ce qu'on engage, et un hill chart visualise l'avancement (la montée, c'est l'incertitude qu'on lève ; la descente, l'exécution qui reste).

Attention toutefois : Shape Up n'est pas un bon point de départ pour une équipe junior. Elle demande aux équipes de cadrer elles-mêmes leur travail, de faire des arbitrages difficiles et d'abandonner un projet devenu trop gros — autant de compétences qui s'acquièrent avec l'expérience. Elle suppose aussi une base d'utilisateur·ices existante et peu d'interlocuteurs externes à coordonner. Si tu débutes, Scrum reste un meilleur cadre d'apprentissage ; garde Shape Up en tête comme une option pour plus tard, quand ton équipe aura gagné en autonomie.

Les concepts clés

• Cycles de 6 semaines + 2 semaines de cooldown pour respirer
• Pas de backlog infini : on shape un projet (le cadrer) avant de l'engager
• Appetite plutôt qu'estimation : on fixe le temps qu'on accepte d'investir, pas l'inverse
• Betting table : décision périodique sur quoi engager pour le cycle suivant
• Hill chart : visualiser la progression (montée = découverte, descente = exécution)

Pertinent pour

• Produit installé, base utilisateur·ices existante
• Équipe senior autonome (devs qui savent shape)
• Peu de stakeholders externes à coordonner

Si tu ne devais retenir qu'une chose de tout ce cours, ce serait celle-ci : aucune méthode n'est meilleure dans l'absolu. Chacune est un outil optimisé pour un contexte. Se demander « quelle est la meilleure méthode agile ? » revient à demander « quel est le meilleur outil ? » — ça dépend de ce que tu as à faire. Le vrai savoir-faire n'est pas de connaître Scrum par cœur, mais de savoir lire ton contexte pour choisir ce qui va vraiment aider ton équipe.

Pour choisir, pose-toi quelques questions concrètes plutôt que de suivre une mode. Quelle est la prévisibilité du travail ? Scrum aime la stabilité, Kanban absorbe la variabilité. Quelle est la taille de l'équipe ? Scrum vise 5 à 9 personnes, Kanban fonctionne même en solo. Quelle est la maturité technique ? XP et Shape Up demandent de l'expérience. Quel est le rythme attendu ? Déploiement continu ou livraisons planifiées ? Les réponses à ces questions t'orientent bien mieux que n'importe quel avis tranché sur « la bonne méthode ».

Dans la vraie vie, très peu d'équipes appliquent une méthode « pure ». La plupart finissent en ScrumBan : la structure de Scrum (sprints, rétrospectives) mariée aux limites d'en-cours du Kanban et à une dose d'asynchrone. Et la tendance de fond, aujourd'hui, est au pragmatisme assumé : prendre ce qui marche dans chaque approche pour son contexte, sans en faire une religion. C'est même le signe d'une équipe mature — elle ne subit pas une méthode, elle se l'approprie et l'ajuste à ses rétrospectives.

• Scrum : produit en construction, équipe stable, besoin de cadence prévisible
• Kanban : flux imprévisible, support, ops, maintenance, équipe très petite
• XP : équipe technique mature, qualité critique
• Shape Up : produit installé, équipe senior autonome, peu de stakeholders
• No-method / hybride : tendance 2025, prendre ce qui marche pour ton contexte sans religion

Les vraies questions à se poser

• Quelle est la prévisibilité du travail ? (Scrum aime la prédictibilité, Kanban la variabilité)
• Quelle est la taille de l'équipe ? (Scrum demande 5-9 ; Kanban marche dès 1)
• Quelle est la maturité technique ? (XP et Shape Up demandent du senior)
• Quel est le rythme attendu ? (déploiement continu vs releases planifiées)

Il existe une chose pire que de ne pas faire d'agile : faire de la fausse agilité. Une équipe qui empile les rituels sans en comprendre l'esprit se retrouve avec tous les coûts (réunions, cérémonies, jargon) et aucun des bénéfices (adaptation, qualité, motivation). C'est frustrant, ça discrédite l'agilité auprès de tout le monde, et ça finit souvent par livrer moins bien qu'avant. Savoir repérer ces dérives est aussi important que de connaître les méthodes elles-mêmes.

Le mécanisme commun à tous ces échecs porte un nom : le cargo cult. On copie les rituels visibles — le daily, le sprint, la rétro, les post-its — sans adopter les valeurs qui leur donnent un sens (auto-organisation, adaptation, qualité). On imite la forme en espérant que le résultat suive, comme ces cultes du Pacifique qui construisaient de fausses pistes d'atterrissage en attendant que les avions reviennent. Le symptôme est facile à reconnaître : on a « l'air agile », mais rien ne s'améliore concrètement. La liste ci-dessous rassemble les dérives les plus fréquentes, et le scénario qui suit te met en situation d'en corriger une.

• Scrum imposé top-down sans buy-in de l'équipe : rituels vides, frustration générale
• Fake agile : on garde le cycle en V mais on renomme les phases « sprints »
• Story-points olympiques : course à la vélocité, on triche, on baisse la qualité pour faire monter le chiffre
• Daily stand-up qui dure 45 min et devient un reporting au manager
• Rétro alibi : on parle, rien ne change, on rejoue les mêmes sujets sprint après sprint
• Product Owner fantôme : pas de vision, le backlog devient une todo-list de demandes random
• Scrum Master mi-chef de projet, mi-coach : double casquette qui crée des conflits d'intérêt
• Refacto interdit : « on n'a pas le temps, on est sous pression ». La dette technique explose

L'agilité a été pensée à une époque où l'équipe partageait la même pièce, avec un tableau physique et des post-its qu'on déplaçait ensemble. Le télétravail et les équipes réparties sur plusieurs pays ont changé la donne, et beaucoup de rituels classiques ont dû être repensés. Le principe qui domine aujourd'hui, c'est l'async-first : on privilégie ce qui n'exige pas que tout le monde soit connecté en même temps, et on réserve le synchrone aux moments où il apporte vraiment quelque chose.

Concrètement, cela transforme les pratiques. Le point quotidien devient un message écrit dans un canal, que chacun lit à son heure, plutôt qu'une réunion debout à horaire fixe. Les démos longues se font en vidéo enregistrée, qu'on regarde en accéléré si besoin, au lieu de mobiliser toute l'équipe en direct. La documentation prend une importance nouvelle : tout ce qui se disait spontanément « à la machine à café » doit désormais s'écrire, sinon l'information se perd. Et l'on tient des journaux de décisions pour garder une trace de pourquoi tel choix a été fait — précieux quand on rejoint le projet six mois plus tard.

Deux facteurs conditionnent la réussite. Les fuseaux horaires d'abord : pour conserver quelques rituels synchrones (rétrospective, planification), vise au moins trois à quatre heures de recouvrement dans la journée ; au-delà, l'équipe fonctionne en asynchrone quasi pur, façon follow-the-sun. La confiance ensuite, qui est non négociable : l'agilité distribuée oblige à renoncer au micro-management. On mesure les résultats — objectifs atteints, qualité livrée — et non le présentéisme, comme le temps passé en ligne ou la vitesse à répondre sur Slack. Sans cette confiance par défaut, le distribué ne tient tout simplement pas.

Async-first

• Daily écrit dans un canal Slack au lieu d'un stand-up synchrone
• Vidéo enregistrée pour les démos longues (le live sync force toute l'équipe à se réunir)
• Documentation renforcée : ce qui se disait à la machine à café doit s'écrire
• Decisions logs : trace écrite des décisions, retrouvable

Outils 2025

• Linear : gestion de projet, alternative moderne à Jira
• Notion : doc et wiki, parfois Confluence
• Miro / FigJam : whiteboards collaboratifs (planning, rétro, brainstorm)
• GitHub Projects : si toute l'équipe est sur GitHub
• Slack / Discord : communication async + sync

Fuseaux horaires

Règle de base : overlap de 3 à 4h minimum dans la journée pour les rituels synchrones (rétro, planning). Au-delà, l'équipe est follow-the-sun et fonctionne en async pur.