CYCLE DE VIE ET CADRAGE

Deux chefs de projet également talentueux, deux résultats opposés : l'un livre, l'autre échoue. Souvent, la différence tient à un seul choix fait au départ — celui du cycle de vie. Se tromper d'approche, c'est se condamner quel que soit le talent d'exécution.

Les cinq phases génériques d'un projet

Un projet, selon le PMI (Project Management Institute), est « un effort temporaire entrepris pour créer un produit, service ou résultat unique » : il a un début et une fin, produit un livrable nouveau et mobilise des ressources contraintes. Quel que soit le secteur, on retrouve cinq phases canoniques :

• Initiation — idée, business case, décision Go/No-Go, charte projet.
• Planification — WBS, planning Gantt, budget, registre des risques.
• Exécution — production effective des livrables.
• Pilotage / Contrôle — suivi des écarts, gestion des changements ; phase parallèle à l'exécution.
• Clôture — recette (VABF, VSR), REX, transfert au support.

Les quatre familles de cycles de vie

• Prédictif (« cascade » / waterfall) — tout est planifié à l'avance, le périmètre est figé tôt.
• Itératif et incrémental — le produit est affiné progressivement par cycles.
• Adaptatif (Agile) — réponse à l'incertitude par des livraisons fréquentes.
• Hybride — combine les approches.

Aucun cycle n'est universellement supérieur

Le choix dépend du degré d'incertitude sur le besoin et sur la solution technique : à quel moment le périmètre est-il figé ? Les familles se différencient précisément par leur réponse à cette question.

Les trois grands référentiels mondiaux

Trois cadres coexistent et convergent désormais : PMI/PMBOK (USA), PRINCE2 (UK) et l'Agile (Manifeste, 2001). Le PMBOK 7ᵉ édition (2021) intègre les approches adaptatives, et la plupart des organisations matures pratiquent aujourd'hui l'hybridation. Maîtriser le cycle de vie est la première compétence du chef de projet.

Selon les enquêtes du Standish Group, la première cause d'échec des projets n'est pas l'exécution — c'est un cadrage bâclé. Comment transformer une idée diffuse en projet solide avant de s'engager ?

Le poids du cadrage dans la réussite

Le CHAOS Report du Standish Group suit depuis 1994 le taux de réussite des projets : environ 30 % de projets réussis, 50 % en difficulté (dépassements ou périmètre réduit) et 20 % d'échecs purs. En tête des causes : le cadrage initial — besoins mal exprimés, périmètre flou, parties prenantes oubliées. D'où une règle empirique : investir 5 à 15 % du temps total dans le cadrage. Chaque heure investie économise 5 à 15 heures en exécution.

Les trois questions du cadrage

• Que veut-on faire ? Le périmètre, les livrables, le résultat attendu. Risque si négligé : scope creep et dérives.
• Pourquoi le faire ? Le besoin sous-jacent, les bénéfices, l'alignement stratégique. Risque : démobilisation, abandon.
• Avec quoi le faire ? Les ressources et les contraintes (délai, qualité, légal). Risque : blocages, dépassements budgétaires.

Le funnel de cadrage en 5 étages

Le cadrage suit une logique d'entonnoir qui précise progressivement ce qui était diffus :

• Idée / signal — opportunité, menace, demande client, obligation réglementaire, intuition.
• Expression du besoin — le quoi et le pourquoi.
• Étude d'opportunité — faut-il y aller ? Marché, faisabilité, alternatives, ordre de grandeur du ROI.
• Cadrage détaillé — périmètre, parties prenantes, contraintes, livrables, jalons, budget cadre.
• Décision Go / No-Go — validation par le sponsor/COPIL et production de la charte projet.

Les outils et la posture du chef de projet

Le cadrage mobilise des outils éprouvés : 5W2H, matrice des parties prenantes de Mendelow, triangle QCD (Qualité-Coût-Délai), grille Go/No-Go. Il produit deux livrables-clés : la note de cadrage et la charte projet. Il requiert enfin une posture : écouter, faire émerger, structurer, formaliser, faire valider.

Le jeu en vaut-il la chandelle ? Et sur quelles bases engage-t-on le projet ? Ce sont deux questions différentes — et c'est pourquoi le cadrage produit deux documents, pas un seul.

Deux documents, deux fonctions

Le business case justifie économiquement le projet (« pourquoi le faire ? »). La charte projet l'autorise officiellement (« sur quelles bases on l'engage ? »). Ils reflètent deux moments décisionnels et deux audiences différents : le business case précède la charte, il instruit la décision d'investir ; la charte vient ensuite et encadre la mise en œuvre.

Le business case : justifier

• Audience — direction financière (DAF) et COMEX.
• Contenu — analyse des options, chiffrage des coûts et bénéfices, calcul de la NPV, du TRI et du payback.
• Format — 10 à 30 pages plus un modèle Excel.
• Cycle de vie — document vivant, actualisé à chaque jalon majeur ; il peut justifier la poursuite, l'ajustement ou l'arrêt du projet.

La charte projet : autoriser

Définie par le PMI comme « le document émis par le commanditaire qui autorise formellement l'existence du projet et donne au chef de projet l'autorité d'utiliser les ressources de l'organisation ». C'est un document court (2 à 5 pages, jusqu'à 10 pour les projets complexes), normalisé et signé. Elle joue trois rôles cumulatifs :

• Autorisation — elle officialise le projet et la nomination du chef de projet.
• Référence — elle fixe les engagements initiaux ; une fois signée, elle devient le contrat de référence, modifié seulement par avenant.
• Communication — elle sert de « pitch » aux parties prenantes absentes du cadrage.

La séquence type

Business case « léger » en phase d'opportunité, puis enrichissement du business case et rédaction de la charte au cadrage approfondi. Au Go/No-Go, le COMEX valide le business case (engagement financier) et le sponsor signe la charte (engagement opérationnel). En clôture, un bilan compare les bénéfices réels à ceux promis (revue post-implémentation, 12 à 24 mois après).

« Il faut que ça marche mieux. » Comment transformer ce besoin vague, partiel et contradictoire en quelque chose de précis, mesurable et testable ? C'est tout le travail de l'analyse des exigences — le pont entre le cadrage et la réalisation.

Du besoin flou à l'exigence testable

Une exigence est, selon l'IEEE 830, « une condition ou une capacité qui doit être satisfaite ou possédée par un système ». Le besoin est vague, partiel, contextuel ; l'exigence est précise, complète, formelle, traçable. L'analyse effectue ce passage sans trahir le besoin initial.

Le coût caché des défauts d'exigences

Les études de Barry Boehm établissent la règle des 1-10-100 : un défaut détecté en phase d'exigences coûte 1 à corriger ; en conception, 5 ; en développement, 10 ; en test, 50 ; après mise en production, 100 à 1 000. Le CHAOS Report du Standish Group identifie d'ailleurs les défauts d'exigences comme cause principale d'échec dans 40 à 60 % des projets en difficulté — devant les défauts techniques ou de planification.

Les quatre niveaux d'exigences

Le BABOK Guide (IIBA) distingue quatre niveaux à ne jamais confondre, dans une pyramide cumulative :

• Exigences métier — ce que veut l'organisation.
• Exigences parties prenantes — ce dont chaque acteur a besoin.
• Exigences fonctionnelles — ce que le système fait.
• Exigences non fonctionnelles — comment il le fait (qualité, performance, sécurité).

La règle d'or : une exigence doit toujours pouvoir remonter à un objectif métier.

Prioriser, exprimer, tracer

• MoSCoW (Must / Should / Could / Won't) priorise les exigences.
• User story (« En tant que… je veux… afin de… ») les exprime de manière centrée utilisateur.
• Modèle de Kano — les classe selon leur impact sur la satisfaction.
• Matrice de traçabilité — les relie aux livrables et aux tests.