La Volkswagen Golf, véritable icône de l’industrie automobile : un produit régulièrement adapté aux exigences du marché depuis 40 ans. Source : NetCarShow.com.

Le « mode projet », dans son acception la plus classique, est-il vraiment adapté au monde du développement de logiciel et à l’accélération constante des changements de l’arène économique ? Dans cet article de synthèse, nous retraçons les origines et les derniers développements d’un mouvement de fond qui pourrait bien bouleverser un paradigme pourtant solidement ancré dans l’industrie informatique.

Depuis quelques mois, il existe sur Twitter un « signal faible » qui pourrait prendre de l’ampleur dans les années à venir : #beyondprojects / #noprojects.  La première salve a été tirée en 2011 par feu P. Grant Rule, expert en développement Agile et Lean, dans un article intitulé « Quel est le problème avec l’approche projet ? », qui partait d’un constat simple : les projets informatiques échouent très souvent, et dans les grandes largeurs, au point de mettre parfois en danger l’existence même de l’entreprise porteuse (cf. cette étude McKinsey d’octobre 2012). Et cela depuis au moins quarante ans.

Depuis cet article fondateur, qui fait écho aux travaux de Mary et Tom Poppendieck (Lean Software Development), Donald Reinertsen (Product Development Flow), David Anderson (Kanban), etc., le mouvement #beyondprojects / #noprojects s’est accéléré grâce à plusieurs articles d’Allan Kelly et Stephen Smith durant l’année 2013. Allan Kelly nous fait remarquer une chose toute simple : il n’y a pas de “date de fin” pour un logiciel qui rencontre du succès. Prenez par exemple Mozilla Firefox : ce navigateur omniprésent est perfectionné régulièrement, par incréments successifs livrés mondialement toutes les six semaines, à la manière d’un flux continu de valeur ajoutée.

Evolution du célèbre logo du navigateur Mozilla Firefox.

Or comment la norme ISO 10006:2003 définit-elle un projet ?

Processus unique qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques, incluant les contraintes de délais, de coûts et de ressources.

Dans le développement de logiciel, cela se traduit généralement par :

• L’allocation d’une enveloppe budgétaire fixe.
• L’allocation d’une durée de vie de projet fixe.
• La constitution, puis la dispersion, d’une “équipe projet” temporaire.

Un logiciel n’est pas comparable à une maison. Source : Mark Rickmeier, 2013.

En fait, cette approche « en bloc » ressemble à celle utilisée pour construire une maison, par exemple. L’ennui, c’est qu’en terme de nature de produit, un logiciel et une maison n’ont rien à voir : un logiciel n’est jamais « fini », et pour demeurer profitable doit continuellement évoluer pour s’adapter aux demandes changeantes du marché, pour saisir des opportunités technologiques, pour répondre à des contraintes réglementaires, etc. Un logiciel qui n’évolue plus, c’est un logiciel mort.

Et ça tombe bien, beaucoup de projets de développement de logiciel sont, une fois terminés, suivis d’une « phase de maintenance évolutive » qui consiste bien souvent à éponger les bugs accumulés lors de la « phase projet », mais aussi à faire évoluer le produit pour les raisons évoquées précédemment. Malheureusement, l’équipe en charge de la « maintenance évolutive » est rarement la même que « l’équipe projet », ce qui entraîne fatalement un perte de connaissances au passage.

Par ailleurs, le « mode projet » suggère que l’on peut en contrôler l’exécution par la mesure des déviations des dimensions du fameux « triangle de fer » :

• Déviation par rapport à la durée estimée ;
• Déviation par rapport au coût estimé ;
• Déviation par rapport aux périmètre initial d’exigences fonctionnelles.

Naturellement, ces déviations sont de facto considérées comme indésirables alors que, ainsi que Reinertsen l’a démontré dans Product Development Flow, les espérances de perte ou de gain économiques sont asymétriques, à la manière des options financières. Par exemple, une déviation positive en durée peut se justifier économiquement si le temps supplémentaire a permis de capturer une opportunité de marché émergente, non identifiée au début du projet, mais se révélant très profitable pour l’organisation.

Ces mesures de la « performance » d’un projet de développement de logiciel sont des « distractions », comme le dit Allan Kelly. Elles détournent l’attention de ce qui compte vraiment : la performance économique du produit, réalisée sur tout son cycle de vie. Car c’est cette performance qui, sur le long terme, pèsera douloureusement sur les comptes de l’entreprise, ou au contraire fera sa fortune.

Sortir du « mode projet » consiste à s’organiser autour de produits évoluant au fur et à mesure des besoins du marché – et aussi rapidement qu’il est nécessaire à cet égard – grâce à des flux délivrant de la valeur en continu, gérés par des « équipes produit » stables, performantes, engagées sur le long-terme, autonomes et ayant une fine connaissance des attentes du marché. Dans l’industrie du développement de logiciel, cela passe par des approches telles que les méthodes Agiles, Feature-driven development, Lean Startup, Kanban, du financement itératif, ou encore Continuous Delivery.