NOTRE MÉTHODE
Un site pour aller droit au but
Ce site s'adresse aux décideurs et à toute personne qui veut acquérir du savoir sérieux sans y passer sa journée. Les sujets traités sont exigeants — économie, psychologie, informatique, intelligence artificielle. Pas de vulgarisation molle. Pas de contenu mâché pour plaire à l'algorithme.
La majorité des sites sur ces sujets sont fatigants à lire. Fatigants sur la forme : des mises en page surchargées, des titres partout, des listes à n'en plus finir. Fatigants sur le fond : un article renvoie vers trois autres, chacun vers trois de plus, et le lecteur se retrouve avec douze onglets ouverts, ayant tout parcouru sans rien compris. C'est la structure en poupée russe — pour comprendre A, il faut d'abord lire B, C et D, qui eux-mêmes supposent E et F.
Ici, chaque notion nécessaire à la compréhension est expliquée au moment où elle apparaît. Dans le texte. Pas ailleurs. Les liens existent, mais ils sont facultatifs — des portes ouvertes pour qui veut approfondir, jamais des passages obligés.
Ce n'est pas un parti pris esthétique. Trois chercheurs ont passé leur carrière à démontrer pourquoi ce type de présentation favorise la compréhension et la rétention : Ebbinghaus sur la mémoire en 1885, Sweller sur la charge cognitive en 1988, Mayer sur la segmentation en 2001. Leurs conclusions convergent : on retient mieux ce qu'on lit sans friction, dans le bon ordre, sans surcharge inutile.
C'est ce principe qui guide chaque page de ce site.
"Ne cassez pas votre rythme de lecture. Si un lien vous intéresse, ouvrez-le dans un nouvel onglet et revenez. Tout ce dont vous avez besoin pour comprendre est déjà sur cette page."
LA MÉTHODE EN V : QUAND ON PLANIFIE TOUT AVANT DE COMMENCER
Gestion de projet — Article 1/4 — 4 minutes de lecture
Le point de départ pour comprendre pourquoi l'Agile est né.
Imaginez que vous commandez la construction d'un pont. Pas question de tester la solidité à mi-chemin et de décider de changer les fondations. Tout doit être arrêté avant de poser la première pierre : les matériaux, les dimensions, les charges supportées. Une fois lancé, on ne revient pas en arrière.
C'est ça, la méthode en V.
CE QUE C'EST
La méthode en V organise un projet en phases séquentielles — un ordre strict où chaque étape doit être bouclée avant de passer à la suivante. On descend d'abord vers la réalisation, puis on remonte vers la validation. Ce mouvement dessine un V, d'où le nom.
Elle est née dans les années 1970 dans l'industrie et l'informatique. Les projets duraient des années, coûtaient des fortunes. Changer de direction en cours de route n'était pas une option — c'était une catastrophe budgétaire. La rigueur séquentielle n'était pas un choix idéologique. C'était une contrainte du réel.
COMMENT ÇA FONCTIONNE
La descente : — on définit, du besoin général vers le détail technique :
- Recueil des besoins du client
- Spécifications fonctionnelles (ce que le produit doit faire)
- Architecture technique (comment il va le faire)
- Développement
La remontée : — on vérifie, chaque test répond à une étape de la descente : 5. Tests unitaires (chaque composant isolément) 6. Tests d'intégration (les composants ensemble) 7. Validation finale avec le client
QUAND ELLE EST PERTINENTE
La méthode en V n'est pas dépassée. Elle est mal utilisée. Pour un avion, un réacteur nucléaire, un système médical embarqué, personne ne teste et itère. Une erreur découverte tard ne coûte pas quelques semaines de retard — elle coûte des vies ou des centaines de millions. La rigueur séquentielle existe parce que l'alternative est inenvisageable.
SA LIMITE FONDAMENTALE
Tout repose sur une hypothèse : le client sait exactement ce qu'il veut avant que le projet commence.
Dans le monde du logiciel, cette hypothèse est presque toujours fausse. Le client découvre ce qu'il veut vraiment en voyant les premières versions. Le marché bouge pendant les dix-huit mois que dure le projet. Un concurrent sort une fonctionnalité qui change les priorités du jour au lendemain.
Avec la méthode en V, chacun de ces imprévus oblige à remonter au début. Des mois de travail à reprendre. Des budgets à revoir. Des équipes démotivées.
C'est ce problème précis qu'un groupe de développeurs a décidé de résoudre en 2001. Leur réponse s'appelle le Manifeste Agile.
Ne cassez pas votre rythme. Ouvrez l'article suivant dans un nouvel onglet quand vous êtes prêt. Tout ce qu'il faut pour comprendre l'Agile est déjà posé sur cette page.
LE MANIFESTE AGILE : QUAND LE LOGICIEL A DÉCIDÉ DE CHANGER DE MÉTHODE
Gestion de projet — Article 2/4 — 5 minutes de lecture
La réponse directe aux limites de la méthode en V.
En février 2001, dix-sept développeurs se retrouvent dans une station de ski de l'Utah. Pas pour skier. Pour régler un problème qui empoisonne leurs projets depuis des années : les méthodes traditionnelles de gestion de projet produisent des logiciels livrés en retard, hors budget, et souvent inutilisables par les gens à qui ils étaient destinés.
Ils repartent avec un texte de 68 mots. C'est le Manifeste Agile.
CE QUE C'EST
Le Manifeste Agile n'est pas une méthode. C'est une déclaration de principes. Il ne dit pas comment travailler — il dit ce qui compte vraiment quand on développe un logiciel.
Il tient en quatre valeurs et douze principes. Les valeurs d'abord.
LES 4 VALEURS
Les individus et leurs interactions plutôt que les processus et les outils. Une équipe soudée qui communique bien produit un meilleur résultat qu'une équipe qui suit des procédures à la lettre. Les processus servent les gens — pas l'inverse.
Un logiciel qui fonctionne plutôt qu'une documentation exhaustive. La documentation est utile. Mais livrer un produit qui marche vaut mieux que livrer un dossier parfait décrivant un produit qui n'existe pas encore. Le résultat prime sur le rapport.
La collaboration avec le client plutôt que la négociation contractuelle. Avec la méthode en V, chaque changement de cahier des charges déclenche une guerre contractuelle. L'Agile part d'un principe différent : le client fait partie de l'équipe. Ses retours ne sont pas des problèmes — ce sont des informations.
L'adaptation au changement plutôt que le suivi d'un plan. Un plan établi en janvier est souvent obsolète en juin. L'Agile ne cherche pas à tout prévoir — il cherche à réagir vite quand la réalité ne correspond pas aux prévisions.
LES 12 PRINCIPES
Ils précisent comment ces valeurs s'appliquent concrètement. En voici les plus importants pour un décideur.
Livrer tôt et souvent. Pas attendre dix-huit mois pour montrer quelque chose. Livrer une première version en quelques semaines, récupérer des retours, améliorer.
Accueillir le changement. Même tard dans le projet. Un concurrent vient de sortir une fonctionnalité que votre client veut absolument ? Ce n'est pas un problème — c'est une information à intégrer.
Mesurer l'avancement sur ce qui fonctionne. Pas sur les cases cochées dans un planning. Un logiciel utilisé par de vrais utilisateurs — voilà la seule mesure qui compte.
Maintenir un rythme soutenable. Les équipes épuisées font des erreurs. L'Agile n'est pas un sprint permanent — c'est un marathon à vitesse constante.
Favoriser l'auto-organisation des équipes. Une équipe qui décide elle-même comment atteindre son objectif est plus efficace qu'une équipe qui attend des instructions. Le rôle du manager change — il fixe le cap, pas les étapes.
CE QUE ÇA CHANGE POUR UN DÉCIDEUR
Avec la méthode en V, vous signez un contrat, vous attendez, vous recevez un produit. Si ce n'est pas ce que vous vouliez, c'est trop tard et trop cher à corriger.
Avec l'Agile, vous êtes dans la boucle à chaque étape. Vous voyez le produit se construire. Vous pouvez changer d'avis sans tout recommencer. Le risque de se retrouver avec dix-huit mois de travail inutilisable disparaît — parce qu'on ne travaille jamais plus de quelques semaines sans validation.
SA LIMITE
Le Manifeste Agile est un ensemble de valeurs, pas un mode d'emploi. Comment organiser concrètement les équipes ? Comment planifier les livraisons ? Comment mesurer les progrès ?
Ces questions ont donné naissance à des frameworks — des cadres de travail concrets. Le plus connu s'appelle Scrum.
SCRUM : COMMENT L'AGILE S'APPLIQUE CONCRÈTEMENT
Gestion de projet — Article 3/4 — 5 minutes de lecture
Le Manifeste Agile pose des valeurs. Scrum pose des règles.
Après 2001, beaucoup d'équipes adhèrent aux principes de l'Agile mais se retrouvent face au même mur : comment s'organiser concrètement ? Les valeurs du Manifeste ne disent pas qui fait quoi, ni quand, ni comment mesurer l'avancement.
Scrum répond à ces questions. C'est le framework — cadre de travail — le plus utilisé au monde pour appliquer l'Agile. Il structure le travail en trois éléments : des rôles, des événements, et des artefacts.
LES RÔLES
Trois personnes portent le projet dans une équipe Scrum.
Le Product Owner. C'est lui qui représente le client et les utilisateurs. Son travail : décider ce qui doit être fait, dans quel ordre, et pourquoi. Il tient à jour une liste de tout ce que le produit doit faire — on appelle ça le backlog. Ce n'est pas un manager. C'est quelqu'un qui connaît le marché, les besoins, et les priorités.
Le Scrum Master. Son rôle est souvent mal compris. Ce n'est pas un chef de projet. C'est quelqu'un dont le travail est de faire en sorte que l'équipe travaille bien — en supprimant les obstacles, en faisant respecter les règles Scrum, en facilitant les échanges. Un facilitateur, pas un donneur d'ordres.
L'équipe de développement. Elle réalise le travail. Elle s'auto-organise — c'est elle qui décide comment atteindre les objectifs fixés par le Product Owner. Généralement entre trois et neuf personnes.
LES ÉVÉNEMENTS
Scrum découpe le temps en sprints — des cycles de travail courts, généralement deux à quatre semaines. À la fin de chaque sprint, une version fonctionnelle du produit est livrée. Pas une maquette. Pas une présentation. Quelque chose qui marche.
Autour de ces sprints, quatre événements structurent le travail.
La planification du sprint. Au début de chaque cycle, l'équipe choisit dans le backlog ce qu'elle va réaliser. Elle s'engage sur un objectif précis pour les deux semaines à venir.
Le daily standup. Chaque matin, quinze minutes debout. Trois questions : qu'est-ce que j'ai fait hier, qu'est-ce que je fais aujourd'hui, est-ce qu'il y a un obstacle qui me bloque. Pas une réunion de reporting — une synchronisation rapide.
La revue de sprint. À la fin du cycle, l'équipe montre ce qu'elle a produit au client et aux parties prenantes. C'est le moment de recueillir des retours concrets sur un produit qui fonctionne.
La rétrospective. Juste après la revue, l'équipe s'interroge sur sa façon de travailler. Pas sur le produit — sur le processus. Qu'est-ce qui a bien marché ? Qu'est-ce qu'on change pour le prochain sprint ?
LES ARTEFACTS
Trois outils permettent de visualiser l'avancement.
Le backlog produit. La liste complète de tout ce que le produit doit faire, priorisée par le Product Owner. Elle évolue en permanence — c'est normal, c'est même le but.
Le backlog de sprint. La portion du backlog que l'équipe s'est engagée à traiter pendant le sprint en cours.
L'incrément. Le résultat concret livré à la fin de chaque sprint — une fonctionnalité qui fonctionne, testée, utilisable.
CE QUE ÇA CHANGE POUR UN DÉCIDEUR
Scrum rend le progrès visible. Toutes les deux semaines, vous voyez quelque chose de concret. Vous n'attendez pas dix-huit mois pour découvrir que le produit ne correspond pas à ce que vous vouliez.
Le risque change de nature. Avec la méthode en V, le risque est invisible pendant des mois — il explose à la livraison finale. Avec Scrum, le risque est petit et visible à chaque sprint. On corrige tôt, quand c'est encore peu coûteux.
SA LIMITE
Scrum fonctionne bien pour des équipes dédiées, stables, co-localisées. Il suppose que le Product Owner est disponible et décisionnaire. Il suppose que l'organisation accepte de voir ses priorités changer toutes les deux semaines.
Dans des structures hiérarchiques rigides, dans des projets avec des contraintes réglementaires fortes, ou dans des équipes dispersées sur plusieurs fuseaux horaires — Scrum se heurte à des obstacles réels.
C'est pour ça qu'une autre approche existe, plus légère et plus visuelle. Plus ancienne aussi — et c'est là où ça devient intéressant. Elle n'est pas née dans le monde du logiciel. Elle n'est pas née de l'Agile. Elle vient de l'industrie automobile japonaise des années 1950, inventée par Taiichi Ohno chez Toyota pour fluidifier des chaînes de production physiques. Des voitures, pas des lignes de code.
Le monde du logiciel l'a découverte bien plus tard et réalisé qu'elle s'adaptait parfaitement à ses propres problèmes. Mais depuis, elle a été adoptée bien au-delà — marketing, ressources humaines, gestion d'équipe, projets personnels. Partout où il faut visualiser un flux de travail et éviter l'engorgement.
Elle s'appelle Kanban.