Gestion de projet: Limites des approches classiques

Caractéristiques d’une approche « en cascade »

Le cycle en « cascade » se caractérise par des phases séquentielles, qui se succèdent après la validation des livrables produits lors de la phase précédente :

• Tous les besoins sont exprimés et recueillis lors de la première phase, puisque l’analyse détaillée de ces besoins, puis la conception du système qui répondra à ces besoins, en dépendront.

• La conception du système, bien que textuelle ou représentée sous forme dediagrammes, doit être validée avant le démarrage des développements.

• Les développements doivent être achevés pour permettre à l’équipe de testeurs de lancer ses campagnes de tests fonctionnels et techniques.

• Enfin, une fois, et seulement une fois, que les anomalies ont été corrigées, on peut procéder à l’intégration globale finale et à la mise en production du système.

Dans ce contexte, et sur la base du périmètre défini, on demande au chef de projet de s’engager sur un planning détaillé de réalisation, prévoyant les jalons de début et fin de phases, et les activités à mener. On devine très rapidement, si l’on ne les a déjà expérimentées, les failles de cette approche.

Les failles d’une approche « en cascade »

Métaphore du chalet

Prenons l’exemple du projet de construction d’un chalet à la montagne : le client souhaite un chalet différent de ceux qui peuplent déjà la station, original, construit avec des matériaux écologiques et respectant les nouvelles normes environnementales. Il a confié la réalisation des plans à un architecte qui a pris en compte ces considérations ; mais le client sait que certains choix et certaines décisions ne pourront être définitifs qu’après avoir vu réellement le chalet prendre forme. Il sait que le coût du chalet ainsi que le délai de réalisation pourront évoluer en fonction de ces choix définitifs, même s’il dispose d’une enveloppe globale qu’il ne

souhaite pas dépasser et d’une date de livraison approximative. Cet exemple paraît tout à fait courant pour celui qui a déjà été confronté à un tel projet et personne ne contesterait la légitimité des hésitations de ce client devant un engagement important. Comment, dans ces conditions, fournir un planning détaillé de tous les travaux, de toutes  les ressources matérielles et humaines, de toutes les fournitures… en sachant qu’au gré des

choix du client, la nature même des travaux et des matériaux pourrait évoluer ? Comment fournir un budget détaillé définitif, alors que le client, en fonction de certains choix, devra peut-être renoncer à tel ou tel équipement initialement prévu pour rester dans l’enveloppe budgétaire qu’il s’est fixée ?

Le développement d’un nouveau produit ou d’un nouveau logiciel est confronté aux mêmes conditions : le chef de produit marketing aura sondé ses consommateurs pour définir son nouveau produit, mais lors de la réalisation, certaines attentes ne pourront être satisfaites en raison d’un surcoût imprévu ou d’une nouvelle norme incompatible apparue en cours de développement ; le responsable des ressources humaines d’une grande entreprise aura associé ses collaborateurs pour définir les fonctionnalités d’un nouveau logiciel de recrutement en ligne ; mais la complexité technique sous-estimée au départ ou la difficulté d’intégration avec

le système central en place contraindront peut-être l’équipe à revoir à la baisse ses attentes ou à accepter un délai supplémentaire ; ou bien encore, le site d’un concurrent faisant apparaître une nouvelle fonctionnalité attrayante amènera le responsable à faire évoluer son cahier des charges en ajoutant cette nouvelle demande en cours de projet.

La rigidité de l’approche

On déplore que la nouveauté, la marge de manoeuvre laissée, à juste titre, au client pour préciser ou faire évoluer ses attentes, la non-prévisibilité de tous les événements soient difficilement compatibles avec une approche prédictive comme celle du cycle en cascade. En fait, une fois le plan de management du projet validé, il constitue la référence de base. La préoccupation majeure du chef de projet devient alors de coller au plus près au plan, quels que soient les événements ; tout écart constaté, concernant la durée des activités, la productivité ou la disponibilité des ressources ou encore les risques imprévus, est perçu comme

un échec, vécu par certains comme une incompétence ou une incapacité à anticiper. L’approche « en cascade » est par conséquent trop rigide pour permettre des retours en arrière ; elle suppose que l’on fasse bien du premier coup. Une décision ou une anomalie détectée dans une phase aval de la cascade peuvent remettre en cause partiellement ou totalement des travaux validés précédemment et considérés comme définitifs.

L’effet tunnel

L’effet tunnel est une autre des caractéristiques de l’approche « en cascade » : un projet dure un an, la phase de recueil des besoins dure deux mois et le client ne voit le résultat

que neuf mois plus tard !

Que s’est-il passé entre-temps ? « On ne sait pas trop ce qu’ils font ces informaticiens ! », « Que va-t-il sortir de la « boîte » ? », « Mais, ce n’est pas ce que l’on attendait ! » ou bien

« C’est ce que nous voulions mais notre besoin a un peu évolué depuis ! » D’une part, la non-transparence des équipes de développement suscite des sarcasmes sur leur capacité à coopérer, d’autre part, la longueur des phases techniques auxquelles le client n’est pas associé rend celui-ci dubitatif sur le résultat à venir. Ce qui ne favorise pas la collaboration efficace entre informaticiens et utilisateurs !

D’autant plus si le résultat livré n’est pas conforme à ce qui est attendu. À la différence, lors des projets industriels de développement de produits sur une chaîne d’assemblage, tout est (presque) prévisible et le degré de nouveauté (presque) néant : les spécifications peuvent alors être précises dès le début et le budget ainsi que le délai sûrement établis. Comment revenir sur une conception validée il y a deux mois lorsque l’on constate, à la fin des développements, que l’architecture développée ne permet pas de respecter les exigences de performance ? D’autant que l’approche en cascade n’encourage pas, explicitement, le prototypage

qui aurait pu éviter cette mauvaise surprise.