Une approche (ou méthode) définit la manière générale de conduire un projet. Un framework fournit un cadre concret pour organiser le travail d’une équipe. D’autres outils répondent à des besoins plus ciblés : répartir les responsabilités, planifier les tâches, gérer les risques, formuler des objectifs ou établir des priorités.
Ces éléments ne sont donc pas concurrents. Un même projet peut très bien être conduit selon une approche agile, s’appuyer sur Kanban pour organiser le flux de travail, sur une matrice RACI pour répartir les responsabilités et sur un diagramme de Gantt pour suivre les grandes échéances.
1. Les principales approches de gestion de projet
Les approches définissent les principes généraux selon lesquels un projet est organisé et conduit.
La méthode en cascade (Waterfall)
La méthode en cascade organise le projet en phases successives : analyse des besoins, conception, réalisation, tests, puis livraison. Chaque phase est en principe terminée avant que la suivante commence.
Elle convient aux projets dont les exigences peuvent être définies précisément dès le départ et restent relativement stables. Elle devient en revanche contraignante lorsque des changements importants surviennent en cours de route, puisqu’il faut alors revenir sur des étapes déjà closes.
Petite ironie de l’histoire : l’article de Winston Royce (1970), souvent cité comme l’acte de naissance du modèle en cascade, présentait justement l’enchaînement strictement linéaire comme risqué et recommandait des retours en arrière entre les phases.
Le cycle en V
Le cycle en V reprend l’organisation séquentielle de la cascade, mais met chaque phase de conception en regard d’une phase de vérification ou de validation :
- l’expression des besoins est validée par les tests d’acceptation (la recette) ;
- les spécifications fonctionnelles sont vérifiées par les tests système ;
- la conception générale (architecture) est vérifiée par les tests d’intégration ;
- la conception détaillée est vérifiée par les tests unitaires.
Le cycle en V est surtout utilisé lorsque les exigences de validation, de documentation et de traçabilité sont fortes : industrie, aéronautique, dispositifs médicaux, marchés publics…
L’approche agile
L’agilité repose sur une logique itérative et incrémentale. Plutôt que de chercher à spécifier l’intégralité du produit avant de le construire, on le découpe en éléments plus petits, développés, évalués et améliorés progressivement. L’équipe sollicite régulièrement les retours des utilisateurs ou des parties prenantes pour ajuster le produit.
L’agilité est d’abord un ensemble de valeurs et de principes, formalisés en 2001 dans le Manifeste pour le développement Agile de logiciels (quatre valeurs et douze principes). Il ne faut donc pas la confondre avec Scrum, qui n’est que l’un des frameworks utilisables dans un contexte agile.
Le Lean
Issu du système de production de Toyota, le Lean cherche à maximiser la valeur produite pour le client tout en éliminant les activités qui n’en apportent pas.
Il met l’accent sur la réduction des gaspillages, l’amélioration continue et la fluidité du travail. Kanban, présenté plus bas, en est directement inspiré.
PRINCE2
PRINCE2 (PRojects IN Controlled Environments) est une méthode structurée de management de projet, née dans l’administration britannique et aujourd’hui portée par PeopleCert (la 7ᵉ édition date de 2023). Elle accorde une place centrale à la gouvernance, à la définition des rôles, à la justification économique continue du projet (business case) et au pilotage par séquences.
Contrairement à Scrum ou Kanban, elle ne se limite pas au fonctionnement quotidien d’une équipe : elle fournit un cadre global de pilotage et de contrôle, qui peut d’ailleurs être combiné avec des pratiques agiles au niveau de la réalisation.
2. Les frameworks d’organisation du travail
Les frameworks fournissent des règles, des rôles ou des mécanismes qui structurent concrètement le fonctionnement d’une équipe.
Scrum
Scrum est le framework agile le plus répandu. Sa définition officielle est donnée par le Scrum Guide de Ken Schwaber et Jeff Sutherland (version française téléchargeable).
Le travail est organisé en itérations courtes et de durée fixe, les sprints, d’un mois au maximum (souvent deux semaines en pratique). Les besoins sont rassemblés dans un Product Backlog ; au début de chaque sprint, l’équipe sélectionne les éléments qu’elle s’engage à traiter.
Scrum définit trois responsabilités (Product Owner, Scrum Master et Developers) et cinq événements : le Sprint lui-même, le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective.
L’objectif est de produire à chaque sprint un incrément utilisable du produit et de pouvoir réajuster les priorités d’une itération à l’autre.
Kanban
Kanban repose sur la visualisation et l’optimisation du flux de travail. Le Kanban Guide en donne une définition de référence, disponible en français.
Les tâches sont représentées sur un tableau dont les colonnes correspondent aux étapes du processus, par exemple :
À faire → En cours → À valider → Terminé
Kanban n’impose pas de colonnes particulières : chaque équipe modélise son propre flux.
Sa caractéristique essentielle est la limitation du travail en cours (Work In Progress, ou WIP), c’est-à-dire du nombre de tâches traitées simultanément. Cette limite évite l’accumulation de travaux entamés et pousse à terminer une tâche avant d’en commencer une autre (« arrêtez de commencer, commencez à finir »).
3. Décomposer et formaliser le travail
Avant de planifier, il faut savoir précisément ce qui doit être réalisé.
La Work Breakdown Structure
La Work Breakdown Structure (WBS, ou organigramme des tâches du projet) consiste à décomposer progressivement le projet en éléments de plus en plus fins, selon une logique du type :
Projet → lots de travail → livrables → activités
Pour une refonte de site web, on pourrait ainsi distinguer : conception, développement, migration des contenus, recette et mise en production.
Cette décomposition facilite ensuite l’estimation des charges, l’attribution des responsabilités et la construction du planning.
Le backlog
Le backlog est une liste ordonnée, généralement par priorité, de tout ce qui reste à réaliser. Dans un projet logiciel, on y trouve des fonctionnalités, des améliorations, des corrections de bugs ou des travaux techniques.
Le Product Backlog est l’un des artefacts centraux de Scrum.
Les User Stories
Une User Story formalise un besoin du point de vue de l’utilisateur. La formulation la plus courante est :
En tant que [type d’utilisateur], je souhaite [action ou fonctionnalité] afin de [objectif ou bénéfice].
Elle décrit le besoin et sa finalité, pas les détails de son implémentation. La phrase écrite n’est d’ailleurs qu’un point de départ : Ron Jeffries la résume par les « 3C », Card (la carte), Conversation (l’échange qui précise le besoin) et Confirmation (les critères d’acceptation).
4. Planifier les tâches et les délais
Une fois le travail identifié, plusieurs outils permettent de l’organiser dans le temps.
Le diagramme de Gantt
Le diagramme de Gantt, popularisé par l’ingénieur Henry Gantt dans les années 1910, représente les tâches d’un projet sur une échelle de temps.
On y visualise la durée de chaque tâche, ses dates de début et de fin, les chevauchements et, dans les outils modernes, les dépendances. Il offre une vision chronologique du projet et de ses principales échéances.
PERT
La méthode PERT (Program Evaluation and Review Technique), développée à la fin des années 1950 pour le programme de missiles Polaris de l’US Navy, représente les activités d’un projet sous forme de réseau de dépendances.
Elle permet d’identifier les tâches qui doivent être terminées avant que d’autres puissent commencer et d’analyser les différents chemins à travers le projet.
PERT se distingue aussi par son estimation à trois points : pour chaque activité, on estime une durée optimiste (O), la plus probable (M) et pessimiste (P), puis on calcule une durée attendue pondérée : (O + 4M + P) / 6.
Le chemin critique
La méthode du chemin critique (Critical Path Method, CPM) identifie la séquence d’activités la plus longue du projet, qui en détermine donc la durée minimale.
Les activités de ce chemin n’ont, par définition, aucune marge : tout retard sur l’une d’elles repousse d’autant la date de fin du projet, sauf à réorganiser le planning. À l’inverse, une activité hors du chemin critique dispose d’une marge qu’on peut consommer sans impact sur l’échéance finale.
WBS, PERT, CPM et Gantt répondent ainsi à des questions complémentaires :
- WBS : que faut-il réaliser ?
- PERT : comment les activités dépendent-elles les unes des autres ?
- CPM : quelles activités conditionnent la durée du projet ?
- Gantt : quand chaque activité doit-elle être réalisée ?
5. Définir les responsabilités et la prise de décision
Un projet bien gouverné précise qui fait quoi, et qui décide.
La matrice RACI
La matrice RACI attribue un rôle à chaque personne impliquée dans une activité ou un livrable :
- Responsible : la ou les personnes qui réalisent le travail ;
- Accountable : la personne qui porte la responsabilité finale du résultat et dispose de l’autorité pour le valider ;
- Consulted : les personnes dont l’avis est sollicité avant ou pendant la réalisation ;
- Informed : les personnes tenues informées de l’avancement ou du résultat.
La règle d’or : un seul A par activité, et au moins un R. Une matrice RACI évite ainsi qu’une tâche n’ait aucun responsable clairement identifié ou, à l’inverse, que plusieurs personnes s’estiment chacune décisionnaires.
DACI
DACI, popularisé notamment par Atlassian, est davantage orienté vers la prise de décision. Il distingue quatre rôles : Driver, Approver, Contributors et Informed.
Le Driver pilote le processus qui mène à la décision ; l’Approver, une seule personne là encore, tranche.
RAPID
RAPID, outil développé par le cabinet Bain & Company, structure les décisions qui impliquent de nombreux acteurs ou plusieurs niveaux hiérarchiques. L’acronyme correspond aux rôles Recommend, Agree, Perform, Input et Decide.
Attention, l’ordre des lettres ne reflète pas la chronologie : on recommande après avoir recueilli les contributions (Input), et la décision (Decide) intervient avant la mise en œuvre (Perform).
RACI, DACI et RAPID traitent donc de problématiques voisines mais distinctes : RACI porte sur les responsabilités liées au travail, DACI et RAPID sur le processus de décision.
6. Prioriser les besoins et les tâches
Tous les éléments d’un projet n’ont pas la même importance. Plusieurs techniques aident à arbitrer.
La méthode MoSCoW
Issue de la méthode agile DSDM, MoSCoW classe les besoins en quatre catégories :
- Must have : indispensable à la version ou au projet concerné ;
- Should have : important, mais pas vital ;
- Could have : souhaitable si le temps et les ressources le permettent ;
- Won’t have (this time) : explicitement exclu, pour cette fois.
La nuance du this time compte : un « Won’t have » n’est pas abandonné définitivement, il est simplement écarté du périmètre en cours et pourra être reconsidéré plus tard.
MoSCoW est particulièrement utile quand le nombre de fonctionnalités envisagées dépasse ce qui est réalisable dans les délais ou le budget. Le guide DSDM recommande d’ailleurs que les Must have ne dépassent pas environ 60 % de l’effort total, pour conserver une marge de manœuvre.
La matrice Impact/Effort
La matrice Impact/Effort positionne chaque action selon deux axes : l’impact attendu et l’effort nécessaire.
Elle fait ressortir les actions à fort impact pour un effort limité, les fameux quick wins.
La matrice d’Eisenhower
La matrice d’Eisenhower classe les activités selon leur importance et leur urgence.
Elle sert surtout à gérer des priorités individuelles ou opérationnelles, et ne suffit pas à elle seule à structurer un projet complet.
7. Définir et mesurer les objectifs
D’autres outils portent non pas sur les tâches, mais sur les résultats recherchés.
Les objectifs SMART
SMART, formalisé par George T. Doran en 1981, fournit une grille de critères pour formuler un objectif. Selon les variantes, l’acronyme correspond généralement à Specific, Measurable, Achievable, Relevant, Time-bound.
Un objectif SMART est donc précis, mesurable, atteignable, pertinent et assorti d’une échéance.
Les OKR
Les OKR (Objectives and Key Results), conçus par Andy Grove chez Intel puis popularisés par John Doerr, qui les a introduits chez Google en 1999, associent un objectif à quelques résultats clés mesurables.
L’Objective indique la direction visée, qualitative et si possible motivante ; les Key Results définissent les résultats chiffrés qui permettent d’évaluer la progression. Les OKR sont généralement fixés et évalués par trimestre.
SMART est avant tout une grille de rédaction d’un objectif, tandis que les OKR constituent un système complet de définition et de suivi des objectifs à l’échelle d’une équipe ou d’une organisation.
8. Gérer les risques, problèmes et dépendances
Piloter un projet, c’est aussi anticiper ce qui pourrait le faire dérailler.
La matrice des risques
Une matrice des risques classe les risques selon deux dimensions :
Probabilité × Impact
Un événement peu probable mais aux conséquences majeures peut ainsi mériter autant d’attention qu’un événement moins grave mais très probable.
Le registre des risques
Le registre des risques documente chaque risque identifié : description, probabilité, impact, responsable, actions préventives prévues et statut.
Le RAID Log
Le RAID Log rassemble quatre catégories d’informations :
- Risks : les risques susceptibles de se produire ;
- Assumptions : les hypothèses sur lesquelles repose le projet ;
- Issues : les problèmes déjà constatés ;
- Dependencies : les dépendances qui peuvent influer sur l’avancement.
Il offre une vue synthétique de tout ce qui peut affecter le projet.
9. Combiner plusieurs pratiques au sein d’un même projet
Ces pratiques ne s’excluent généralement pas. Prenons l’exemple d’une refonte de site WordPress conduite selon une approche agile :
- Kanban sert à suivre au quotidien les tâches de conception, de développement et de recette ;
- une WBS définit les grands lots du projet, tandis qu’un backlog regroupe les fonctionnalités et corrections restant à réaliser ;
- MoSCoW distingue les fonctionnalités indispensables à la mise en production de celles qui peuvent attendre une version ultérieure ;
- une matrice RACI clarifie les responsabilités respectives du client, du chef de projet, du designer et des développeurs ;
- un diagramme de Gantt garde en vue les grandes échéances, même si l’équipe travaille au quotidien avec Kanban ;
- enfin, un RAID Log centralise les risques, problèmes et dépendances : validation client en attente, disponibilité d’une API externe, modification DNS à prévoir avant la mise en production…
On peut résumer l’ensemble ainsi :
| Niveau | Pratique retenue |
|---|---|
| Approche de gestion du projet | Agile |
| Organisation du travail | Scrum ou Kanban |
| Décomposition du travail | WBS et backlog |
| Priorisation | MoSCoW |
| Responsabilités | RACI |
| Planification | Gantt, PERT et chemin critique |
| Objectifs | SMART ou OKR |
| Risques et problèmes | Matrice des risques et RAID Log |
10. Quelle pratique utiliser selon le besoin ?
Le choix dépend avant tout du problème à résoudre.
| Besoin | Pratiques courantes |
|---|---|
| Définir la manière générale de conduire le projet | Agile, Waterfall, cycle en V, Lean |
| Encadrer la gouvernance et le pilotage | PRINCE2 |
| Organiser le travail d’une équipe | Scrum, Kanban |
| Décomposer un projet | WBS |
| Centraliser le travail restant | Backlog |
| Formaliser les besoins utilisateurs | User Stories |
| Planifier les activités dans le temps | Gantt |
| Représenter les dépendances | PERT |
| Identifier les tâches critiques | CPM |
| Répartir les responsabilités | RACI |
| Organiser la prise de décision | DACI, RAPID |
| Prioriser des fonctionnalités | MoSCoW |
| Arbitrer entre valeur et effort | Matrice Impact/Effort |
| Formuler précisément un objectif | SMART |
| Piloter des objectifs et des résultats | OKR |
| Évaluer les risques | Matrice des risques |
| Centraliser risques, problèmes et dépendances | RAID Log |
Conclusion
Il n’existe pas de méthode unique applicable à tous les projets. La gestion de projet s’organise plutôt en plusieurs niveaux de pratiques, chacun répondant à un besoin distinct.
Les approches (agile, cascade, cycle en V) fixent la logique générale de conduite du projet. Les frameworks comme Scrum ou Kanban organisent le travail au quotidien. Les outils (RACI, Gantt, WBS, MoSCoW, RAID Log…) traitent ensuite des questions précises de responsabilités, de planification, de décomposition, de priorisation ou de risques.
La vraie question n’est donc pas de choisir entre RACI, Scrum, Gantt ou MoSCoW, mais de trouver la combinaison de pratiques adaptée aux caractéristiques et aux contraintes de votre projet.
Laisser un commentaire