La bonne méthode de projet dépend de ce que vous ignorez encore

Un logiciel de gestion interne devait être livré au printemps. Il est arrivé en hiver, avec deux écrans sur cinq que personne n'ouvre. L'entreprise avait pourtant travaillé proprement : un plan détaillé, des étapes signées, une réunion de suivi chaque mois.

La même année, une autre PME a lancé son projet sans plan d'ensemble. Deux semaines de travail, une démonstration au client, une correction, et on recommence. Six mois plus tard, l'outil tournait. Imparfait, mais utilisé tous les jours.

Les deux équipes ont fait deux paris différents sur ce qu'elles ignoraient au départ. C'est ce pari qui décide, avant la mode et avant l'outil.

Ce que vous ignorez décide de la méthode

Une seule question suffit pour commencer. Pouvez-vous décrire aujourd'hui, par écrit, le comportement exact de ce que vous allez livrer ?

Si oui, vous conduisez une construction. Le résultat se vérifie contre un document, et l'imprévu devient un accident de parcours.

Si non, vous conduisez un apprentissage. Le résultat se découvre en le montrant à ceux qui s'en serviront.

L'analogie tient. Bâtir une maison dont les plans sont validés n'appelle pas la même conduite qu'inventer un plat pour un banquet dont on ne connaît pas encore les invités. Dans le premier cas, on suit le plan. Dans le second, on goûte, on corrige, on ajuste l'assaisonnement.

Il existe un troisième cas. Certaines activités n'ont pas de fin : le support client, la maintenance d'un parc, l'atelier qui traite des commandes à la journée. Là, la question n'est plus « que livrer », mais « à quelle vitesse le travail traverse l'équipe ». Trois situations, trois familles de méthodes.

Le plan complet, quand le résultat est connu d'avance

La méthode en cascade organise le projet en phases successives. On n'ouvre pas la suivante avant d'avoir signé la précédente : cadrage, conception détaillée, réalisation, tests, mise en service. Chaque fin de phase produit un document signé, le jalon, qui autorise la suite.

Le cycle en V est une variante. Il prévoit les tests dès le cadrage, en miroir des phases de conception, pour éviter de découvrir trop tard ce qui n'a pas été vérifié.

Cette organisation a un auteur, et il est souvent mal cité. En août 1970, Winston Royce décrit ce déroulement séquentiel, puis écrit que cette mise en œuvre « est risquée et invite à l'échec ». Il ajoute que, dans ce schéma, la phase de test est le premier moment où l'on touche vraiment le réel. Une découverte tardive peut alors coûter, selon ses mots, jusqu'à un dépassement de 100 % du planning ou du budget.

Sa correction est instructive. Il demande de construire d'abord une version réduite des parties critiques, puis de livrer la seconde. Autrement dit, une répétition générale avant la représentation.

La cascade reste le bon choix dans un cadre précis. Une obligation légale fixe le résultat. Un sous-traitant s'engage sur un périmètre fermé, avec des pénalités. Des contraintes physiques interdisent de tester avant la fin. Dans ces cas, le plan protège.

Elle casse quand le besoin n'est encore qu'une hypothèse. Le plan fige une supposition, et le test arrive trop tard pour la corriger.

Les cycles courts, quand c'est l'usage qui apprend

En février 2001, dix-sept praticiens publient un manifeste de quelques lignes. Ils y opposent quatre préférences : les personnes aux processus, le logiciel qui fonctionne à la documentation, la collaboration au contrat, et la réponse au changement au respect du plan.

Ce texte ne décrit aucune méthode. Il ne dit ni les rôles, ni les réunions, ni la durée des cycles. C'est une posture, pas un mode d'emploi. Confondre les deux est l'erreur la plus fréquente.

Scrum est le cadre le plus répandu. Un cadre, ici, est un squelette de rôles et de rendez-vous qui laisse au métier le soin du contenu. Le guide officiel le dit lui-même : il est « volontairement incomplet », et n'existe que pour être complété par l'équipe.

Trois responsabilités, cinq rendez-vous, des cycles d'un mois au maximum, appelés sprints. Le Product Owner décide de l'ordre des demandes, dans une liste appelée backlog. Le Scrum Master fait tomber les obstacles et garde le cadre vivant. Les Developers construisent. À la fin de chaque cycle, une démonstration montre quelque chose qui fonctionne.

Ce dispositif suppose deux conditions. Quelqu'un doit avoir le pouvoir réel de changer l'ordre des priorités. Et le client, ou l'utilisateur, doit venir voir la démonstration. Sans ces deux conditions, le cycle tourne à vide : on produit des réunions, pas des décisions.

Reste ce que Scrum ne fait pas. Il ne dit jamais quoi construire. Un cadre qui organise des rendez-vous ne remplace pas un arbitrage sur le produit.

Kanban, pour le travail qui n'a pas de fin

Le guide de référence publié en mai 2025 définit Kanban comme « une stratégie pour optimiser la circulation de la valeur dans un processus ». Trois pratiques, qui vont ensemble : rendre le flux visible, gérer activement les éléments qui y circulent, améliorer le flux.

Concrètement, un tableau à colonnes. Chaque colonne est un état du travail. Chaque carte est une demande. La règle qui change tout est une limite : un nombre maximal de cartes par colonne. Colonne pleine, on termine avant de commencer.

Kanban convient aux activités sans livraison finale. Un service support traite des demandes qui arrivent chaque jour. Un atelier enchaîne des réparations. Il n'y a pas de projet à clore, seulement un flux à tenir.

L'avantage est l'entrée en matière : aucun rôle à créer, aucune réunion à imposer. On dessine le tableau lundi, on ajuste les limites deux semaines plus tard.

La limite est ailleurs. Kanban rend le débit visible et le raccourcit. Il ne dit pas ce qui mérite d'exister. Une équipe peut fluidifier parfaitement la production de quelque chose d'inutile.

Le mélange qui coûte le plus cher

Voici la combinaison la plus répandue, et la plus coûteuse : un contrat à forfait, exécuté avec des rites agiles.

Un forfait fixe un prix et un périmètre. L'agilité suppose que le périmètre bouge. Les deux ne peuvent pas être vrais en même temps. Le résultat est prévisible : des cycles de deux semaines où personne n'a le droit de changer une ligne, des démonstrations qui ne débouchent sur aucune décision, et un client qui paie des cérémonies.

Le fournisseur absorbe l'écart sur la qualité, ou il s'en va.

Trois accords cohérents existent.

Périmètre fermé, prix ferme. Un plan détaillé, une version pilote sur les parties risquées, des critères de réception écrits avant le démarrage.

Budget et date fermes, périmètre ouvert. Une liste de priorités classée, une revue toutes les deux semaines, et une règle d'arbitrage écrite. Cette règle dit qui tranche, et comment, quand le budget ne couvre plus la liste.

Flux continu. Un tableau à colonnes, des limites, et une mesure du temps de traversée.

Dans tous les cas, une page suffit. Elle dit qui décide, à quelle fréquence, et sur quelle base. Cette page est plus utile que n'importe quelle certification. Un contrat est une méthode déguisée.

Juger la méthode sur ses délais, pas sur ses réunions

Après six mois, la question n'est plus « avons-nous bien appliqué la méthode ». C'est « le travail sort-il plus vite, et casse-t-il moins ».

Le programme de recherche DORA, qui étudie la livraison logicielle, mesure cinq choses. Le délai entre l'engagement d'un changement et sa mise en production. La fréquence des mises en production. Le temps de rétablissement après un déploiement raté. Le taux d'échec des déploiements. Et le taux de reprise, c'est-à-dire les déploiements non prévus qui répondent à un incident.

Deux de ces mesures suffisent à un dirigeant. Le délai de traversée, du jour où une demande est acceptée au jour où elle sert vraiment. Et le temps de retour à la normale après un incident.

Notez ces deux dates pendant trois mois, sans rien changer d'autre. Vous aurez un chiffre, et ce chiffre ne dépend ni du vocabulaire ni de la taille de l'équipe. Il permet de comparer deux fonctionnements sur la même activité, ce qu'aucune réunion de bilan ne fait.

Une méthode n'est pas une croyance. C'est un pari sur ce que vous ne savez pas encore. Un pari se mesure.

Ce qu'il faut retenir

• La méthode se choisit sur une question : pouvez-vous décrire par écrit le résultat attendu avant de commencer ?
• Si oui, un plan par phases protège, à condition d'ajouter une version pilote des parties risquées.
• Si non, des cycles courts avec une vraie démonstration font apprendre plus vite qu'un plan détaillé.
• Pour une activité sans fin, comme le support ou l'atelier, un tableau à colonnes avec des limites de travail en cours vaut mieux qu'un projet découpé.
• Un forfait à périmètre fixe et des rites agiles se contredisent : choisissez l'un des deux, et écrivez la règle d'arbitrage sur une page.
• Mesurez le délai de traversée et le temps de retour à la normale. C'est ce qui dit si la méthode fonctionne.