Le choix d’une méthode de gestion de projet passe souvent pour une formalité. L’organisation utilise PRINCE2, donc le prochain projet suivra PRINCE2. L’équipe a travaillé en Scrum sur le dernier produit, donc le projet d’infrastructure suivra Scrum. Cette logique par défaut semble inoffensive, mais elle constitue l’une des décisions les plus structurantes du projet, et l’une des plus négligées.
Le PMI Pulse of the Profession 2024 confirme un constat qui va à l’encontre de l’intuition habituelle: les approches prédictives, agiles et hybrides produisent des résultats statistiquement comparables en termes de respect des objectifs. Ce n’est donc pas le type de méthode qui détermine le succès, mais la pertinence de son application au contexte réel du projet.
La méthode prédictive imposée à un projet instable
Un projet dont les exigences évoluent chaque semaine ne peut pas fonctionner sur un plan détaillé figé en début de cycle. C’est pourtant ce qui se produit quand une organisation applique systématiquement une approche en cascade (waterfall), quel que soit le degré d’incertitude.
Le premier symptôme est le scope creep, cette dérive du périmètre que le PMI documente depuis des années. Quand le cadre méthodologique ne prévoit pas de mécanisme d’adaptation régulier, les changements s’infiltrent de manière informelle: une demande verbale ici, un ajout “mineur” là. Le plan de référence devient rapidement obsolète, mais personne ne le met à jour parce que le processus de gestion des changements est trop lourd pour des ajustements fréquents.
L’estimation en souffre directement. Un plan prédictif repose sur l’hypothèse que le périmètre est stable. Quand cette hypothèse est fausse dès le départ, les estimations de délais et de coûts deviennent des fictions administratives que l’équipe maintient par obligation contractuelle plutôt que par utilité opérationnelle.
L’agilité sans structure: le rituel vide
Le problème inverse est tout aussi fréquent. Une équipe adopte Scrum ou Kanban parce que “c’est moderne”, sans comprendre les prérequis organisationnels. Le daily stand-up devient une réunion de statut classique de vingt minutes. Les sprints n’ont pas de définition de “terminé” (definition of done) claire. Le backlog n’est pas priorisé par un product owner (responsable de la valeur du produit et de la priorisation du backlog) légitime mais par quiconque parle le plus fort en réunion de planification.
Dans ce scénario, l’agilité n’apporte aucun de ses bénéfices. L’équipe ne livre pas de valeur incrémentale parce que les incréments ne sont pas définis. Elle ne s’adapte pas aux retours parce que les rétrospectives produisent des listes de plaintes sans actions concrètes. Le résultat est un projet qui accumule les rituels sans en tirer la substance: davantage de réunions, mais pas plus de visibilité ni de contrôle.
Les organisations à haute maturité en gestion de projet voient 27% de leurs projets manquer leurs objectifs, contre 47% pour les organisations à faible maturité, selon le même rapport du PMI. L’écart ne s’explique pas par le choix entre agile et prédictif, mais par la capacité à appliquer une méthode avec rigueur et discernement.
La communication s’effondre en premier
Quand la méthode ne correspond pas au projet, c’est la communication qui se dégrade en premier. Un cadre prédictif trop rigide génère des rapports d’avancement qui ne reflètent pas la réalité du terrain. Un cadre agile trop lâche produit une transparence de façade où les tableaux Kanban sont mis à jour sporadiquement et les informations circulent par conversations informelles que seule une partie de l’équipe capte.
Le PMI estime que 56% des ressources gaspillées sur les projets en difficulté sont attribuables à une communication inefficace. Sur un projet de grande envergure, cela représente des montants considérables. Le problème n’est pas que les gens communiquent mal par nature: c’est que le cadre méthodologique ne fournit pas les bons canaux, la bonne fréquence ni les bons formats pour le type de projet en cours.
Un projet de construction avec des sous-traitants multiples a besoin de rapports formels hebdomadaires et de réunions de coordination structurées. Un projet de développement produit en phase exploratoire a besoin de démonstrations fréquentes et de boucles de feedback courtes. Appliquer le schéma de communication d’un projet stable à un projet exploratoire étouffe l’équipe sous la paperasse, tandis que l’inverse laisse les parties prenantes sans visibilité.
L’estimation devient un exercice de fiction
Le choix méthodologique influence directement la manière dont les estimations sont produites et utilisées. Dans un cadre prédictif, l’estimation se fait en début de projet sur la base d’un périmètre supposé complet. Dans un cadre agile, elle se fait par itération sur la base de la vélocité observée. Aucune des deux approches n’est supérieure dans l’absolu, mais chacune devient dangereuse quand elle est appliquée dans le mauvais contexte.
Estimer un projet de recherche et développement avec un diagramme de Gantt détaillé sur 18 mois relève du vœu pieux. Les incertitudes techniques sont trop nombreuses pour que le plan survive au contact de la réalité. À l’inverse, estimer un projet réglementaire par story points et vélocité de sprint ne fournit pas aux parties prenantes institutionnelles les jalons contractuels dont elles ont besoin.
Le contrôle du périmètre ne fonctionne que si le mécanisme de contrôle est adapté au rythme du projet. Un comité de changement mensuel convient à un projet stable. Il paralyse un projet dont le périmètre évolue quotidiennement.
Reconnaître les signaux d’une méthode inadaptée
Certains indicateurs permettent d’identifier le problème avant qu’il ne devienne critique. Le premier est le décalage entre les artefacts produits et leur utilisation réelle. Si personne ne consulte le plan de projet, le registre des risques ou le tableau Kanban, c’est que ces outils ne correspondent pas à la façon dont l’équipe travaille effectivement.
Le deuxième signal est la multiplication des processus parallèles informels. Quand l’équipe contourne systématiquement le processus officiel pour “aller plus vite”, le cadre méthodologique est probablement trop lourd ou mal adapté. Le troisième signal est l’incapacité à répondre simplement à la question “où en est le projet?”. Si cette réponse nécessite de croiser plusieurs sources d’information contradictoires, le système de pilotage ne remplit pas sa fonction.
Adapter le cadre en cours de route
La compétence la plus sous-estimée d’un chef de projet est sa capacité à remettre en question le cadre méthodologique en cours d’exécution. Les référentiels contemporains reconnaissent cette nécessité: le PMBOK 7e édition du PMI a abandonné les groupes de processus prescriptifs au profit de principes directeurs. PRINCE2 intègre le principe d’adaptation à l’environnement projet. PM2 de la Commission européenne prévoit explicitement un mécanisme de tailoring (adaptation de la méthode au contexte spécifique du projet).
Remettre en question la méthode ne signifie pas tout changer du jour au lendemain. Il s’agit d’ajustements ciblés: réduire la fréquence des comités de pilotage si le projet est stable, introduire des revues de sprint si le périmètre évolue rapidement, simplifier le reporting si les rapports ne sont pas lus. Ces ajustements demandent une légitimité que le chef de projet doit construire en démontrant que le cadre actuel produit des inefficacités mesurables, pas en invoquant une préférence personnelle.