La gestion des lancements décrit les étapes ou phases clés de votre projet, depuis la naissance de l’idée jusqu’à la création d’une nouvelle fonctionnalité, son test, puis sa mise en production.
Ce processus doit être géré avec soin. En tant que Product Manager, vous livrez aux clients un produit issu de recherches approfondies, conçu pour répondre à leurs besoins spécifiques. Cependant, il ne suffit pas de lancer un produit en espérant qu’il atteigne ses objectifs. La planification du lancement est l’un des éléments les plus cruciaux pour garantir un déploiement réussi et offrir à vos utilisateurs finaux une expérience irréprochable.
Ce guide détaillera le processus de lancement, de la planification à l’exécution, en explorant différentes stratégies de déploiement adaptées à vos objectifs et cas d’usage.
Qu’est-ce que la gestion des lancements ?
La gestion des releases est le système que vous mettez en place pour contrôler le cycle de vie du développement logiciel, depuis la planification jusqu’aux tests, en passant par la mise en production.
Elle permet à votre équipe de rester sur la bonne voie et de travailler vers un objectif commun, en s’assurant que chaque membre est aligné sur les priorités.
En termes simples, le processus de gestion des lancements garantit que votre produit est prêt à être déployé en production et livré aux utilisateurs finaux.
Lorsqu’elle est bien gérée et correctement mise en œuvre, cette démarche aboutit à des lancements de haute qualité et à une productivité accrue, vous permettant de publier plus fréquemment et avec un risque réduit.
Au cœur d’une feuille de route Agile efficace se trouve la gestion des lancements de fonctionnalités, qui divise le développement en sprints, tout en mettant l’accent sur les besoins des utilisateurs.
Les phases de la gestion des lancements
Le processus de gestion des lancements est très similaire aux principales étapes du cycle de vie du développement logiciel (SDLC), qui comprend :
- Planification
- Construction
- Test
- Déploiement
- Évaluation
Au début, le chef de produit planifie la nouvelle fonctionnalité en identifiant un problème client et comment cette fonctionnalité pourra y remédier. Il répondra à des questions telles que ce que cette version fera, comment elle sera utilisée et par qui.
Il développera ensuite une stratégie en conséquence et commencera à travailler sur la feuille de route produit. La fonctionnalité sera ensuite construite et gérée à travers les différents cycles de développement.
Le Product Manager devra alors décider d’une stratégie de lancement appropriée en fonction du cas d’usage, des objectifs et du budget.
Le rôle d’un chef de produit tourne donc autour de la gestion des lancements de produits. Dans ce guide, nous examinerons ce que nous entendons par lancements et les types de stratégies de lancement ou de déploiement qui permettent aux chefs de produit d’expérimenter et de tester leurs produits pour garantir une satisfaction optimale des clients.
Tout d’abord, lors de l’étape de planification, le Product Manager recueillera des idées pour commencer à planifier une nouvelle fonctionnalité. Le chef de produit identifiera un problème client et comment il peut être résolu avec cette nouvelle fonctionnalité.
Le persona utilisateur et la proposition de valeur seront définis à cette étape. Le Product Manager mettra en place des KPIs pour évaluer le succès du produit après son lancement. Il élaborera ensuite un plan sur ce qui est nécessaire pour livrer cette nouvelle fonctionnalité et la date de sortie prévue, selon les éléments suivants :
- Former l’équipe nécessaire pour construire la fonctionnalité.
- Définir les exigences et les objectifs finaux.
- Construire une feuille de route.
De la stratégie produit à la livraison : Planifier un lancement
Une fois qu’une stratégie produit a été mise en place, la prochaine étape logique est de construire un processus de gestion des lancements. Ce processus nécessite une planification minutieuse du périmètre et des phases de travail, ainsi que l’établissement d’attentes et d’exigences claires.
Un plan de lancement permettra à chaque membre de l’équipe de savoir ce qu’il doit faire et selon quel calendrier. Il définira les priorités et le déroulement du projet. Parmi les éléments à inclure dans un plan de lancement figurent :
- Les objectifs du produit et la feuille de route
- Les nouvelles fonctionnalités à ajouter
- Les phases de travail
- Une estimation des livrables
La feuille de route produit est un composant essentiel pour assurer le succès de vos produits. Elle décrit la stratégie, la vision et les objectifs et sert de guide pour que les différentes équipes impliquées puissent exécuter cette stratégie tout en restant alignées et concentrées.
Ainsi, le Product Manager est responsable de la création et de la définition d’une liste priorisée des fonctionnalités à développer au fil du temps, en fonction des objectifs de l’organisation. Cette liste est généralement élaborée en collaboration avec la direction et d’autres parties prenantes.
Le développement d’une feuille de route Agile sera beaucoup plus flexible qu’une feuille de route traditionnelle, permettant des délais plus courts et des ajustements pour s’adapter à l’évolution des priorités.
Dans la méthodologie Agile, le Product Manager est censé lancer régulièrement de nouvelles fonctionnalités, que ce soit trimestriellement, mensuellement ou même chaque semaine. Étant donné que la méthodologie Agile est centrée sur l’utilisateur, le succès sera mesuré en fonction des retours des utilisateurs, de leur engagement, des conversions, etc.
Une fois le plan de lancement établi, il est temps de planifier le lancement effectif. De nombreuses stratégies de lancement ou de déploiement doivent être prises en compte par le Product Manager, en fonction des objectifs, des besoins de l’entreprise et de l’impact sur les utilisateurs finaux.
Quelles équipes sont impliquées dans le processus de lancement ?
Comme mentionné précédemment, un lancement réussi nécessite le soutien de plusieurs départements. Ainsi, l’équipe produit devra coordonner ses efforts avec d’autres équipes, notamment :
- Équipes produit : C’est une évidence, mais pour clarifier, cette équipe peut être petite ou grande selon l’organisation. Elle est composée de plusieurs rôles avec des responsabilités différentes, notamment des responsables produit (product managers) et des propriétaires de produit (product owners). Les rôles de ces deux profils peuvent parfois se chevaucher, bien qu’il existe des distinctions.
- Développement : L’équipe produit travaillera en étroite collaboration avec les développeurs pour définir les exigences du lancement et fixer les délais pour chaque étape. Une fois les exigences définies, les développeurs créeront la documentation et concevront la fonctionnalité.
- Ventes : Cette équipe devra être formée et recevoir du matériel ainsi que de la documentation pour être prête à vendre le produit.
- Marketing : Ils contribueront à développer une communication efficace autour du lancement afin d’éduquer et de convaincre les clients potentiels d’essayer le produit.
Outre les chefs de produit, il existe d’autres rôles techniques spécifiques dans la gestion des lancements, tels que :
- Responsables de lancement (Release Managers) : Ils jouent un rôle majeur en gérant tous les aspects du cycle de vie de la livraison logicielle.
- Ingénieurs DevOps : Ces ingénieurs supervisent la mise en production du nouveau code.
- Ingénieurs en fiabilité des sites (Site Reliability Engineers, SRE) : Ils font le lien entre l’informatique et les opérations, créent des systèmes logiciels fiables et évolutifs, et surveillent les éventuels dysfonctionnements des systèmes en place.
Choisir une stratégie de déploiement
Il existe plusieurs façons de déployer de nouvelles fonctionnalités en production. Le choix de la bonne stratégie est essentiel et dépendra de nombreux facteurs, notamment l’impact sur les utilisateurs finaux et le cas d’usage.
Certaines approches, appelées déploiements “big bang”, consistent à déployer l’ensemble de l’application en une seule fois, nécessitant des cycles de développement et de finalisation plus longs. Cependant, de tels déploiements ne sont plus adaptés au développement logiciel moderne en raison des risques élevés qu’ils comportent, tels que des pannes importantes et des retours en arrière presque impossibles.
C’est pourquoi, dans ce guide, nous avons choisi de nous concentrer sur quatre stratégies qui font partie des approches de déploiement progressif (phased deployments) et qui sont couramment utilisées par les organisations et les équipes modernes.
Déploiement blue/green
Le déploiement blue/green est une technique qui utilise deux environnements de production, appelés blue et green. Une fois les modifications prêtes, le trafic est dirigé vers l’un de ces environnements.
Ainsi, ce type de déploiement repose sur deux environnements de production, mais un seul est actif à la fois, tandis que l’autre reste inactif. L’environnement inactif sert de sauvegarde en cas de problème dans l’environnement actif, permettant un retour rapide à l’environnement inactif pendant que l’incident est résolu.
Cette pratique offre de nombreux avantages, notamment des mises en production rapides et des retours en arrière simples. Cependant, le déploiement blue/green nécessite de nombreuses ressources pour maintenir deux environnements de production, en particulier pour les Product Managers qui auront besoin de logiciels spécialisés pour suivre les performances de leurs fonctionnalités.
Lisez-en davantage sur notre blog pour découvrir les avantages et inconvénients du déploiement blue/green et déterminer si cette approche est viable pour votre équipe.
Déploiement canary
Le déploiement canary est une stratégie qui réduit les risques liés aux nouvelles versions en les testant d’abord sur un sous-ensemble d’utilisateurs avant de les déployer pour l’ensemble des utilisateurs.
Cela signifie que vous pouvez sélectionner un pourcentage d’utilisateurs pour effectuer des tests, en fonction de certains attributs. Si aucun problème n’est détecté, vous pouvez progressivement étendre le déploiement au reste des utilisateurs.
Le déploiement canary se distingue du déploiement blue/green par son approche plus ciblée, ce qui est particulièrement avantageux si la version comporte des risques élevés. À l’inverse, le déploiement blue/green adopte une stratégie plus “tout ou rien”.
Déploiement en anneaux (Ring Deployment)
Le déploiement en anneaux est une stratégie qui permet d’introduire progressivement de nouvelles fonctionnalités auprès de différents groupes d’utilisateurs afin de minimiser l’impact. Ces groupes d’utilisateurs sont représentés par une série d’anneaux en expansion, d’où le nom de cette technique.
Ainsi, cette méthode commence avec un petit groupe d’utilisateurs, comme des utilisateurs internes, et s’élargit progressivement à mesure que vous gagnez en confiance pour déployer la version à l’ensemble de vos utilisateurs.
Test A/B
Le test A/B est une stratégie de lancement couramment utilisée par les Product Manager pour tester des fonctionnalités en production avec un risque minimal. Cette approche est particulièrement utile pour l’expérimentation, afin d’observer et de déterminer quelle variation fonctionne le mieux auprès des utilisateurs.
Les tests A/B sont donc employés dans le cadre de tests de fonctionnalités, où les Product Managers peuvent tester leurs idées sur leur audience cible en collectant des données sur les performances des fonctionnalités, afin de prendre des décisions éclairées.
Dans ce type de test, deux versions d’une fonctionnalité ou d’un système sont comparées. En fonction des KPIs prédéfinis, la version qui génère le plus de conversions, de revenus, ou autres indicateurs de succès devient la variation gagnante, et tous les utilisateurs sont ensuite dirigés vers cette version.
Cette méthode est particulièrement avantageuse pour les Product Manager, car elle leur permet de tester leurs idées directement auprès de leur cible avec moins de risques. Elle offre également la possibilité de continuer à tester différentes variations jusqu’à trouver la solution idéale, basée sur les retours en temps réel des utilisateurs.
Déploiement progressif via des rollouts par phases
Comme nous l’avons vu, les déploiements peuvent être de type “tout ou rien” ou effectués progressivement sous forme de rollouts progressifs, comme dans le cas des déploiements canary et des tests A/B. Découvrez comment les rollouts progressifs peuvent vous aider à réaliser des mises en production rapides et pourquoi ils sont essentiels dans une méthodologie Agile dans notre guide sur les rollouts progressifs.
Comme mentionné précédemment, la gestion des lancements guide un produit depuis son développement jusqu’aux tests, puis enfin à sa mise en production.
L’implémentation de feature flags dans votre processus de gestion des lancements peut accélérer vos déploiements et en améliorer la qualité tout en réduisant les risques. Grâce aux feature flags, toutes les nouvelles modifications peuvent être déployées et accessibles à vos utilisateurs finaux, tandis que les modifications non finalisées peuvent rester masquées et enveloppées dans un drapeau (flag) jusqu’à leur achèvement.
Avec les feature flags, vous contrôlez le “quand” et le “qui”, vous donnant un contrôle total.
Toutes les stratégies de déploiement mentionnées précédemment peuvent intégrer l’utilisation des feature flags pour la publication de nouvelles fonctionnalités, qu’il s’agisse de déploiements basés sur un pourcentage (comme dans les déploiements canary) ou de la publication ou du masquage de certaines fonctionnalités dans un déploiement en anneaux.
Tout comme les feature flags facilitent des déploiements plus rapides, ils sont également essentiels pour effectuer des rollbacks rapides en cas de bugs nécessitant une correction avant d’être diffusés à tous les utilisateurs. Ces rollbacks rapides donnent aux chefs de produit un contrôle accru sur le processus de déploiement, leur permettant de tester leurs nouvelles fonctionnalités avec une plus grande confiance et de recueillir des retours précieux pour améliorer leur produit. Découvrez dans quelles situations un rollback de fonctionnalité sera nécessaire.
Choisir la bonne stratégie de lancement
Comme nous l’avons vu, il existe plusieurs façons de lancer une nouvelle version d’une application ou de nouvelles fonctionnalités. Quelle que soit la stratégie utilisée, elle dépendra de vos objectifs et de votre budget.
Ainsi, la stratégie de lancement choisie dépendra de nombreux facteurs, notamment :
- Les besoins de vos clients
- Le type de fonctionnalité que vous souhaitez lancer
- Les objectifs ou indicateurs que vous cherchez à atteindre avec ce lancement
- Les ressources disponibles
Par exemple, si vous disposez des ressources nécessaires pour maintenir deux environnements, comme dans le cas des déploiements blue/green, cette approche offre de nombreux avantages avec peu d’interruptions.
Cependant, si vous disposez d’un budget et de ressources limités, et que votre lancement repose davantage sur des configurations, le déploiement canary pourrait être une meilleure option.
Votre choix dépendra également largement de vos objectifs commerciaux. D’un côté, si vous souhaitez déployer des changements avec un minimum ou aucune interruption, le déploiement blue/green est une option viable. De l’autre, si vous souhaitez tester vos fonctionnalités sur un petit groupe d’utilisateurs, vous pourriez envisager des rollouts progressifs en utilisant, par exemple, des feature flags.
Après le lancement
Une fois le lancement effectué, il est important de continuer à surveiller les déploiements pour détecter tout problème éventuel et le corriger immédiatement.
Des services tiers comme la fonctionnalité de flagging d’AB Tasty offrent un tableau de bord sophistiqué qui permet à des équipes autres que celles du développement de surveiller les flags utilisés et d’accéder à des rapports pour déterminer si le lancement a atteint les KPIs définis au début de l’expérience.
Ces fonctionnalités avancées dans une plateforme de feature flagging donnent aux chefs de produit un contrôle accru sur les lancements, sans dépendre des développeurs.
Le retour d’expérience : un pilier central de l’Agile
Le retour d’expérience, ou feedback loop, est un processus continu de collecte des retours clients pour améliorer le produit. Cela garantit que le produit que vous développez apporte une réelle valeur à vos clients.
Pourquoi la livraison continue est importante pour les équipes produit
Comme mentionné précédemment, des lancements fréquents sont au cœur de la méthodologie Agile. Maintenir un environnement de livraison continue est donc crucial.
Cela signifie essentiellement que les équipes publient des produits en petits lots et sur des périodes réduites, afin de livrer rapidement aux consommateurs. Cela leur permet de recueillir des retours précieux pour améliorer continuellement leurs produits.
De même, une culture DevOps est souvent associée à la livraison continue, car les deux concepts visent à renforcer la collaboration entre les équipes de développement et les opérations, tout en utilisant des processus automatisés pour accélérer et multiplier les lancements.
De plus, le déploiement continu (continuous deployment), qui combine l’intégration continue et la livraison continue, est tout aussi essentiel pour les équipes produit. L’idée derrière ce concept est de rendre les logiciels disponibles sans intervention humaine, en s’appuyant entièrement sur des processus automatisés.
Les avantages de la livraison continue pour les équipes produit
- Lancer des produits plus rapidement : Répondre aux exigences d’un marché en constante évolution.
- Améliorer le retour d’expérience : Des lancements fréquents permettent d’accélérer la collecte des retours des clients, contrairement à un lancement complet, plus risqué.
- Augmenter la qualité des versions : Les retours clients permettent d’améliorer le produit, aboutissant à des lancements qui répondent précisément aux besoins des utilisateurs.
En conclusion…
En tant que chef de produit, vous avez pris soin de construire le bon produit, il est donc tout aussi crucial d’être méticuleux dans la façon dont vous le lancez.
Pour garantir un lancement de qualité, il est indispensable de tester en production avec de vrais utilisateurs. Cette pratique vous permet de recueillir des retours précieux pour améliorer le produit en fonction des besoins réels de vos utilisateurs, mais aussi de recueillir des idées pour de futures versions.
Découvrez pourquoi le test en production est aujourd’hui une composante essentielle du rôle d’un chef de produit en consultant cet article, ainsi qu’une approche plus légère sur l’importance des tests en production, expliquée à travers des mèmes.
