Il y a quelques mois, j’ai assisté à une réunion qui a tourné au vinaigre. Des managers s’affrontaient sans vraiment comprendre pourquoi. Les uns parlaient de KPIs, de vision long terme, d’itérations et de learning loops. Les autres de jalons, de livrables, de comités de pilotage et de reporting. Même entreprise, même objectif supposé, mais deux langages tellement différents qu’on aurait dit deux planètes. Et – évidement – en tant que coach agile et coach produit, iels m’ont pris a parti. Le fossé entre “projet” et “produit” n’est pas qu’une affaire de mots. C’était une divergence fondamentale de posture et de vision.
Depuis des années, cette distinction anime le monde de la Tech et la communauté agile : faut-il penser nos efforts en mode projet ou en mode produit ? Pour beaucoup, la différence reste floue, souvent perçue comme du jargon de consultant. Pourtant, comprendre ce qui distingue un projet d’un produit n’est pas une coquetterie intellectuelle. C’est s’équiper d’un outil de lecture bien utile quand il nous faut piloter dans un monde où les cycles se raccourcissent, les attentes clients s’intensifient, et l’incertitude devient la norme.
Le véritable enjeu n’est pas de désigner un “meilleur” modèle, mais de discerner dans quel contexte chaque approche est adaptée. Et surtout, de comprendre pourquoi tant d’organisations qui persistent à tout structurer en projets peinent à créer un impact durable. Sans jamais leur asséner qu’elles ont “tout faux” — ce qui, soyons honnêtes, ne fait que renforcer les résistances.
Une histoire de cuisine
Laissez-moi vous raconter l’histoire de Thomas et Claire.
Thomas est un chef renommé. On l’appelle pour des événements exceptionnels. Le mois dernier, il a orchestré le mariage de l’année. Trois mois de préparation, une brigade réunie pour l’occasion, un menu sur mesure, des produits sourcés aux quatre coins du pays. Le jour J, tout était parfait. À minuit, quand le dernier convive est parti, Thomas a rangé ses couteaux, salué son équipe éphémère, et s’est éclipsé. Mission accomplie. Un projet exemplaire : temporaire, ciblé, avec un début, une fin, et un moment de gloire au milieu.
Claire, elle, a ouvert son restaurant il y a cinq ans. Son défi est d’une toute autre nature. Chaque soir, sa porte s’ouvre sur de nouveaux visages, des habitués fidèles, des avis changeants. Sa carte évolue avec les saisons. Son équipe apprend, s’ajuste, progresse ensemble. Un jour, une critique négative l’a poussée à repenser sa formule déjeuner. Un autre, la pénurie d’un ingrédient l’a contrainte à réinventer un plat signature. Claire ne vise pas la perfection d’un soir, mais la satisfaction renouvelée, soir après soir. Son restaurant n’est pas un événement — c’est un organisme vivant. Un produit.
Cette métaphore éclaire l’essentiel : un projet crée un livrable ; un produit crée une valeur continue. Le projet est une parenthèse. Le produit, un engagement.
Quand le projet reste pertinent
J’ai vu Laurent, directeur IT d’une banque, piloter une mise en conformité réglementaire complexe. Délai non négociable, périmètre figé et connu, enjeux juridiques importants : tout appelait une approche projet. Et cela a fonctionné. Six mois plus tard, le système était conforme, l’équipe s’était dissoute, chacun avait repris ses activités. Objectif atteint. Mission close.
Le mode projet n’est ni obsolète ni inadapté. Il reste idéal lorsqu’on connaît la destination, que le chemin est balisé et relativement prévisible, que le succès est binaire : livré ou non. C’est le monde du simple et du compliqué selon le modéle Cynefin (*). Construire un pont, organiser un événement, délivrer un prototype, répondre à une exigence légale – ces défis relèvent d’une logique de projet.
Quand l’approche produit devient indispensable
Mais j’ai aussi accompagné Sarah, qui dirigeait le lancement d’une application mobile dans une entreprise où tout était structuré en projets. L’équipe a livré dans les temps, respecté le budget. Champagne. Trois mois plus tard, c’était un désastre : taux d’usage mediocre, fonctionnalités ignorées, et surtout un ROI loin d’etre garantit. Pourquoi ? Parce qu’au moment où il fallait commencer à apprendre des utilisateurs, l’équipe s’était dissoute. Le budget était épuisé. L’attention tournée vers “le projet suivant”.
Dans un monde de complexité où la durée de vie moyenne d’une app mobile est inférieure à 90 jours (*), où 70-80 % des fonctionnalités développées ne sont jamais utilisées, structurer son innovation comme une suite de projets fermés revient à investir massivement dans des solutions mortes-nées. Ce n’est pas un sujet de gouvernance. C’est une question de survie business.
Changer de relation à la valeur
Le passage du projet au produit transforme radicalement notre rapport à la réussite. Dans un projet, on célèbre la livraison : délais tenus, périmètre respecté, budget maîtrisé. Dans un produit, on mesure l’impact réel : avons-nous résolu un vrai problème ? Créé un usage durable ? Généré de la rétention ? Fait croître le revenu ? Et si ce n’est pas le cas, que devons-nous apprendre, ajuster, tester ?
Cela change tout dans la manière dont on structure les équipes. En projet, les talents se rassemblent temporairement, puis se dispersent. Le savoir se perd. Le contexte s’évapore. La courbe d’apprentissage est effacée à chaque livraison. Dans un modèle produit, on privilégie la stabilité, la montée en expertise sur un périmètre donné, la relation directe avec les utilisateurs. On construit une capacité collective à apprendre vite et à délivrer souvent. C’est un capital long terme.
Une transformation culturelle, pas juste organisationnelle
Je me souviens de Mathieu, que j’ai conseillé sur une bascule vers un operating model produit : “Le plus difficile, ce n’était pas de changer les rôles ou les outils. C’était de changer ce qu’on attend de nous. J’ai dû expliquer à mon COMEX qu’on ne pouvait plus leur promettre ce qu’on livrerait à 12 mois. Mais qu’on serait capable de s’ajuster toutes les semaines pour créer ce qui compte vraiment, et que lón piloterait en se basant sur les revenus, et plus uniquement sur les dépenses.”
Passer d’une logique projet à une logique produit, ce n’est pas troquer un process pour un autre. C’est accepter que la planification parfaite est une illusion. Et que notre meilleure réponse à l’incertitude, c’est notre capacité à apprendre vite, à prioriser bien, à nous adapter en continu.
Le prix caché du tout-projet
Le plus souvent, le modèle projet échoue non pas par manque de rigueur, mais parce qu’il ignore l’après. Une fois le budget consommé, l’équipe dissoute, qui reste pour apprendre ? Qui itère ? Qui corrige ? Qui optimise ? Le coût de ce désapprentissage permanent n’apparaît dans aucun tableau de bord, mais il plombe silencieusement la performance produit. Et par ricochet, la performance de l’entreprise.
Une question de choix, pas d’opposition
Attention : ce n’est pas une guerre de religions. Ce n’est pas projet contre produit. Ce n’est pas passé contre avenir. C’est une question de pertinence.
Vouloir tout gérer en projet, c’est comme vouloir faire tourner un restaurant avec les recettes d’un banquet unique. Cela peut donner l’illusion de fonctionner. Jusqu’au jour où l’on s’épuise à livrer, pendant que d’autres construisent de la valeur pérenne.
Mais l’inverse est tout aussi vrai. Tout vouloir traiter en mode produit n’a pas plus de sens. Certaines initiatives n’ont pas vocation à durer : elles ont un objectif clair, un périmètre défini, une fin assumée. Y greffer artificiellement un modèle produit, c’est risquer la sur-ingénierie, l’alourdissement, voire l’immobilisme. Un bon produit, c’est aussi savoir dire non au modèle produit quand il ne s’impose pas.
Il ne s’agit donc pas de choisir son camp, mais de faire preuve de discernement stratégique. De poser la bonne intention au bon endroit, avec le bon cadre d’exécution.
L’expérience avant la théorie
Ce n’est pas en lisant cet article que vous serez convaincu-e. C’est en voyant une équipe produit réellement autonome, alignée sur la stratégie de l’entreprise et à l’écoute de ses utilisateurs, qui apprend vite, qui livre souvent des fonctionnalités qui font sans sur votre marché, et qui crée un impact tangible. C’est en observant que le “modèle produit” n’est pas une mode, mais une machine à apprendre plus vite que la concurrence.
Et vous, dans votre organisation : êtes-vous en train de planifier un grand banquet, ou de bâtir un restaurant qui traversera les saisons ?
Si ce sujet résonne avec ce que vous vivez, si vous hésitez sur la bonne approche ou sentez que vos équipes naviguent à vue, je serais ravie d’en discuter.
J’ai créé bttrways pour accompagner les dirigeants de la Tech – CxO et leadership teams – dans la mise en place d’organisations Produit solides, sur-mesure et impactantes. Le premier pas est souvent une conversation franche : c’est facile et gratuit 😉
—
(*) a lire au sujet de Cynefin en plus des écrits de Dave Snowden , vous pouvez compléter par l’excellent article de mon ami Nils Lesieur 💚 avec une trés chouette bilbiographie
(*) selon Flurry, le “milieu de vie” d’une app (moment où elle perd 50% de son audience) arrive en moyenne au bout de 3 à 4 mois, selon la plateforme. Les jeux et les apps sociales voient ce déclin encore plus tôt – la durée de 90 jours reflète surtout la réalité de l’engagement utilisateur, pas la durée de disponibilité de l’application sur les stores.
