Vous pensez que le mode projet est obsolète ? FAUX !
Le mode produit s’est imposé comme une référence dans les modèles de transformation IT en s’appuyant sur les méthodes agiles. Promu pour ses vertus « disruptives », le mode produit est perçu comme un idéal d’organisation à atteindre pour toute DSI moderne. A contrario, le mode Projet est jugé dépassé, inadapté aux enjeux de transformation des entreprises.
Cette opposition est réductrice.
Chez Valthena, nous pensons que le mode projet et le mode produit ne sont pas opposés, au contraire. Projet et Produit se complètent, chacun contribuant à l’excellence opérationnelle de la DSI dans des contextes différents.
La volatilité des usages commande le mode produit
En mode produit, les usages sont le point d’ancrage de l’organisation : la manière dont les utilisateurs s’approprient réellement le produit structure la démarche et guide les décisions.
Un produit naît d’un use case jugé pertinent pour des utilisateurs ciblés. Il précise sa valeur auprès de ces utilisateurs tout au long du cycle de vie. A mesure que les usages évoluent et que le contexte métier se transforme, cette valeur s’affine et se redéfinit.
Pour suivre l’évolution des usages et des besoins, une logique capacitaire est instaurée, garantissant la capacité à faire évoluer le produit en continu.
Les équipes sont structurées pour couvrir l’ensemble du cycle de vie, avec des compétences renforcées et une collaboration fluide de bout en bout, du développement à l’exploitation, jusqu’au support.
Le développement est priorisé en fonction des usages et attentes des utilisateurs. Or, à mesure que les utilisateurs s’approprient le produit, de nouveaux besoins émergent.
Le backlog (roadmap dynamique) constitue un outil de planification structurant entre les utilisateurs et les équipes produit : il permet de recenser, décrire et prioriser les cas d’usage attendus.
Ainsi, le backlog et les rythmes de mise en production rapprochés (sprints) permettent un réalignement continu sur la satisfaction client.
Autrement dit, l’utilisateur n’est plus seulement une cible : ses usages deviennent un indicateur de l’utilisation, de l’adoption et de la satisfaction ; afin d’aligner l’évolution du produit avec ces attentes.
Le sprint est un point de mesure régulier : il permet la rencontre du besoin et de la solution proposée. Le sprint s’adapte au rythme des usages en dehors des standards, permettant d’accélérer l’innovation. Au fil des itérations, le produit est façonné selon les grandes phases de son cycle de vie.
A titre d’exemple, le lancement d’un portail client B2C est particulièrement sensible à l’adoption des utilisateurs. Dans ce contexte, le mode produit est le mode de fonctionnement adapté : temps de réaction rapide et prise en compte des feedbacks.
Toutefois, multiplier les expérimentations sans cadre clair expose à un risque : celui du prototype éternel, dans lequel des équipes et des moyens sont mobilisés en continu, sans stabiliser la valeur produite.
Le mode produit montre également ses limites lorsque le résultat attendu est clairement identifié et ne dépend pas de l’évolution des usages. Dans ce cas, l’enjeu n’est pas d’itérer en continu, mais de cadrer précisément le besoin et d’en assurer une exécution maîtrisée, orientée vers l’excellence opérationnelle.
Maintenir artificiellement une logique d’itération continue peut alors générer de la complexité inutile et retarder l’atteinte du résultat.
Le mode projet garantit la qualité indépendamment des usages ou prépare le mode produit
En mode projet, l’objectif est d’assurer la mise en œuvre d’un besoin précis, avec un budget et des délais maitrisés. Il privilégie la fiabilité et la robustesse, raison pour laquelle on le préfère lors de transformations IT structurelles.
Ce mode est parfaitement adapté aux besoins qui ne sont pas contingents ou qui précèdent l’usage des utilisateurs finaux, comme les évolutions d’infrastructures, une mise en conformité réglementaire ou le cadrage d’un prototype, par exemple.
Le mode projet structure et cadre les efforts dès le démarrage pour atteindre un résultat concret et opérationnel dès la mise en œuvre ou avant une éventuelle bascule vers le mode produit, une fois le besoin initial spécifié.
Par exemple, la migration vers un réseau WAN illustre l’intérêt du mode projet. La maîtrise des coûts, des délais et de la qualité dès la conception est primordiale. Une fois le réseau déployé, la réussite de la migration repose sur l’absence d’anomalies rapportées par les utilisateurs.
En pratique, nous constatons que les initiatives IT sont menées de manière hybride entre projet et produit.
Le projet n’est pas opposé au produit, il adresse simplement une autre logique de création de valeur.
En conclusion : mode projet et mode produit sont deux approches complémentaires
- Le projet adopte une approche « fit-for-purpose » (Project Management Institute, Project Management Embraces the Fit‑for‑Purpose Approach, 2024) basée sur l’excellence opérationnelle. Il répond à des besoins définis et stables, qu’il s’agisse d’infrastructures, de processus ou de conformité. Bien mené, un projet garantit fiabilité, maitrise des risques et performance.
- Le produit, quant à lui, intervient dans une démarche de qualité face à des usages variables : il évolue au rythme des retours utilisateurs, optimisant la valeur et l’expérience tout au long du cycle de vie, dans un environnement sécurisé.
- Mode projet et mode produit se complètent : l’un propose un socle quand l’autre tire parti des innovations au service des besoins opérationnels. La combinaison de ces deux modes au sein de l’organisation d’une DSI doit faire l’objet de toutes les attentions pour optimiser la performance opérationnelle de l’IT.
