Les méthodes agiles remettent en question les approches « projet » au profit d’une approche « produit ». Pourquoi ? Que recouvrent ces deux notions ? Quel impact sur les modes d’organisation ? C’est l’objet de cet article.

Projet vs Produit

Le mode projet : une façon de bousculer l’organisation au profit d’un nouvel objectif.

Si l’on s’appuie sur les définitions de l’AFNOR ou de l’ISO, « un projet est 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 clairement défini avec des exigences spécifiques comme des contraintes de délais, de coûts et de ressources. »

Les prémisses apparaissent dès le moyen âge, dans le domaine de la construction, avec la nécessité de séparer la conception de la réalisation comme pour la construction du dôme de la cathédrale de Florence entre 1377 et 1446. C’est à partir de 1930 que les pratiques de gestion de projet vont vraiment se rationaliser dans certaines entreprises convaincues de posséder une expertise unique. C’est après-guerre que va vraiment se constituer un modèle de gestion à part entière, sous l’impulsion du PMI à partir de 1969 notamment. La gestion de projet s’étend également aux projets SI à partir des années 1970 en translation directe des méthodes de la construction.

Les organisations se sont généralement structurées pour réaliser des tâches de façon industrielle répétitive. Or la mondialisation amène un environnement changeant, et les entreprises doivent régulièrement s’adapter en introduisant de nouveaux objectifs, non prévus : nouvelles offres, nouveaux outils, nouvelles méthodes. Ces objectifs nécessitent le concours de toute l’organisation, et l’allocation de moyens. Avec le mode projet, les entreprises pouvaient définir ces moyens, et dédier des ressources ainsi non perturbées par le « business as usual ». En professionnalisant les méthodes projet, elles pouvaient mettre sous contrôle l’atteinte des objectifs avec efficience.

La remise en cause par les méthodes agiles.

En informatique, des approches dites agiles se sont structurées fin des années 90 / début des années 2000. Elles s’opposaient à la méthode classique dite du « cycle en V » (ou « waterfall » en anglais) et venaient ainsi remettre en cause quelques fondements du mode projet :

  • On ne peut plus demander un engagement initial sur un périmètre précis pour une date donnée. La construction d’un outil informatique s’inscrit dans un objectif général, mais l’expérience montre qu’il est vain de vouloir tout spécifier en détail dès le début. Les conceptions sont alors trop théoriques, souvent incomplètes et, le temps que le projet les ait toutes développées, elles deviennent pour partie obsolètes. C’est pourquoi les méthodes agiles privilégient une construction itérative, s’appuyant sur des expérimentations et de retours terrains fréquents. Cela peut donner un sentiment d’insécurité au décideur qui sait seulement qu’il aura quelque chose à intervalle réguliers, mais c’est plus efficace.
  • L’allocation budgétaire devient donc non déterministe. On investit sur des sujets en fonction de leur horizon de temps. Investissements sur des expérimentations en phase d’évaluation et d’émergence, puis allocation d’un budget et de ressources fixes pour un sujet en fonction de la valeur attendue. L’objectif devient de maximiser la valeur produite sous contrainte. C’est une forme de retour de l’approche industrielle dans la construction informatique.
  • Surtout, on casse la distinction « build vs run » inhérente aux projets. De fait, dans la mesure où on construit le produit informatique par petites touches, par itérations successives, en livrant souvent, ce produit est « en run » très tôt et reste « en construction » pendant très longtemps. Par ailleurs, il y a aussi une volonté philosophique de casser la dichotomie entre les « cow-boys » du projet et les « agriculteurs » de l’exploitation. L’adage devient « you build it, you run it », tu gères ce que tu as construit, et si tu as construit n’importe quoi, tu en assumes toi-même les conséquences. Les approches DEVOPS vont dans ce sens également.

Du mode projet au mode produit.

C’est ainsi que les tenants des approches agiles ont rapidement préconisé de quitter le mode projet au profit d’un mode « produit ». Plutôt que de gérer un ensemble de projets de construction et un ensemble d’applications en maintenance, l’entreprise gère un portefeuille de « produits » auxquels elle alloue des moyens tant qu’il y a de la valeur à les développer.

De la révolution du mode projet, on garde l’idée qu’il faut des ressources dédiées sur un sujet, et on garde l’idée que l’organisation se reconfigure en fonction des objectifs du moment. En revanche, on casse la distinction entre cadrage initial et exécution sur plans préétablis, et on casse l’idée d’un grand soir ou tous les objectifs rêvés sont atteints et ou il n’y a plus qu’à entrer en maintenance.

Cela crée potentiellement un sentiment d’insécurité pour le top décideur qui ne sait pas exactement ce qu’il aura pour son argent à la fin de l’année. Mais s’il accepte de faire le grand saut, il aura potentiellement eu mieux que s’il avait voulu appliquer une approche déterministe.