Cycle de vie de publication logicielle (SRLC) : Les 6 étapes expliquées
De la même façon que les êtres humains traversent différentes étapes au cours de leur vie, les produits logiciels évoluent également par étapes successives. On parle alors fréquemment de cycle de vie de la publication logicielle.
Il existe des périodes bien définies qui sont associées aux différentes phases du cycle de vie ou aux « stades de développement » des applications, mais il est parfois difficile de prévoir précisément le moment où une phase s’achève et la suivante commence. Chaque phase comprend son propre ensemble de tâches et d’exigences interservices, il est donc essentiel que les responsables produits comprennent chaque phase afin de piloter efficacement l’entreprise tout au long du cycle de vie de la publication logicielle.
Au fil de cet article, j’apporterai mon point de vue basé sur mon expérience de la vente et de l’intégration de BankerBox, une société FinTech SaaS à destination des banquiers d’investissement, à SS&C Intralinks avec mon cofondateur, dans les différentes phases du SRLC.
Vous voulez plus de The CPO Club ?
Inscrivez-vous gratuitement pour terminer la lecture de cet article :
Have an account? Log In
Qu'est-ce qu'un cycle de vie de publication logicielle (SRLC) ?
Le cycle de vie de la publication logicielle (SRLC) est une série d’étapes/phases clés qui décrivent les différentes périodes dans le cycle de vie d’un logiciel ou sur un calendrier de publications successives, depuis sa conception jusqu’à sa sortie définitive. La durée de ce cycle varie en fonction de plusieurs facteurs, comme le type de produit, son usage prévu, ainsi que les normes de sécurité, de conformité et générales du secteur.
Par exemple, les applications logicielles ont généralement un cycle de vie plus court que la plupart des autres produits car de nouvelles fonctionnalités et améliorations sont fréquemment mises sur le marché à travers des méthodes agiles afin de répondre à l’évolution de la demande et aux nouvelles tendances technologiques.
Il est proche du cycle de vie du développement logiciel (SDLC), qui définit la structure suivie pour le développement de produits logiciels. La différence entre ces deux cycles est que le SDLC décrit uniquement le processus de développement et de conception logicielle, tandis que le cycle de vie de publication inclut non seulement ce développement mais également l’utilisabilité du logiciel, les tests et sa diffusion.
Les publications logicielles doivent être planifiées et testées avec soin (idéalement par une équipe dédiée aux tests) afin de s’assurer qu’elles ne génèrent pas plus de problèmes qu’elles n’en résolvent. Un cycle de vie de publication logicielle fixe un plan clair pour réussir la publication du logiciel via une planification adéquate, des tests et des corrections de bugs.
Les entreprises devraient utiliser le cycle de vie de publication logicielle pour anticiper quand et comment elles mettront à jour leur application web ou leurs apps au fil du temps. En implémentant des pratiques de gestion des versions adéquates, elles peuvent conserver un produit fiable qui répondra continuellement à la fois aux attentes des utilisateurs, au cœur des fonctionnalités et aux standards du secteur (c’est aussi un domaine où l’IA dans la gestion des versions peut les aider). Cela leur permet de maintenir un produit robuste qui répond en permanence aux besoins des utilisateurs, aux fonctionnalités essentielles ainsi qu’aux exigences du secteur.
Les 6 étapes du cycle de vie de publication logicielle
Il existe différentes phases du cycle de vie de publication logicielle qui peuvent être utilisées selon le type de système développé et les besoins de l’équipe de développement.
Les « étapes » marquent des jalons dans le développement d’un produit et permettent à l’équipe de développement ainsi qu’aux chefs de projet de suivre l’avancement. Elles permettent aussi d’analyser les tendances au sein des applications web ou mobiles et de valider que les améliorations sont bien faites à travers les itérations successives. Typiquement, ce cycle comprend les six phases suivantes :
1. Version Pré-Alpha
La première étape du cycle de vie de publication logicielle est la Pré-Alpha. Cette phase du processus est entièrement orientée sur le développement du produit et non sur son lancement marketing ou public. Elle englobe chaque action réalisée lors du développement initial avant tout test. Les phases les plus courantes de la Pré-Alpha sont l’analyse, la conception, le développement et les tests unitaires.
Une grande partie de la version pré-alpha consiste à identifier de quelle façon l’application logicielle doit évoluer pour la préparer aux versions ultérieures, telles que les versions alpha et bêta. L’équipe de développement doit mettre en œuvre des processus rigoureux de test logiciel, d’ergonomie et d’automatisation pour garantir des transitions stables entre les différentes phases du cycle de vie de la publication logicielle.
Avec la solution SaaS que mon cofondateur et moi avons intégrée chez SS&C Intralinks, nous avions déjà validé et accompli la phase Pré-Alpha. Nous disposions d’une application opérationnelle qui avait été architecturée, conçue puis développée. Il est néanmoins important de noter que la définition des étapes Analyse, Conception, Développement et Test unitaire dans une petite structure logicielle peut différer sensiblement du point de vue, et du niveau d’exigence, d’une grande entreprise sur ces mêmes étapes.
4 phases pour lancer la version Pré-Alpha
Analyse : c’est la première étape du cycle de vie de publication logicielle, ou SRLC, qui consiste à étudier en détail la problématique et les besoins du système. Elle inclut l’analyse des besoins utilisateurs, la définition des fonctionnalités critiques, l’identification des points de blocage, la préparation de rapports de faisabilité et la rédaction du cahier des exigences logicielles (SRS : Software Requirement Specification).
Conception : à cette étape, les équipes de développement élaborent une solution au problème identifié lors de l’étape d’analyse. Cette phase inclut la rédaction d’un document de conception de haut niveau et des maquettes qui expliquent comment mettre en œuvre le produit logiciel. Le document de conception met en avant les étapes de base à suivre pour construire l’application web.
Si vous travaillez sur des maquettes ou des flux d’interface utilisateur, ces outils de prototypage de design réactif peuvent vous aider à tester rapidement des idées avant de passer au développement. Le document de conception met en avant les étapes de base à suivre pour construire l’application web.
Développement : il s’agit de la phase réelle de codage où une équipe de développement transforme les spécifications des besoins en un véritable produit logiciel. Une fois le codage terminé, les développeurs effectuent des tests et corrigent les bogues dès que possible.
Tests unitaires : ceux-ci sont réalisés par les développeurs avant de livrer leur module à l’équipe QA (Assurance Qualité) pour la suite du processus de test. À cette étape, les développeurs vérifient chaque ligne de code source pour s’assurer que le code fonctionne correctement avant son intégration dans l’application globale.
2. Version Alpha
La phase alpha représente la première lettre de l’alphabet grec, et c’est aussi un nom de code pour la phase de développement qui a lieu avant le lancement d’un produit. Les développeurs de logiciels utilisent le terme « alpha » ou « version alpha » pour décrire un logiciel qui est dans sa première phase de test logiciel.
Les tests alpha sont réalisés par des employés internes ou des développeurs au sein de l’entreprise. Ce type de test est effectué chez le développeur mais pas chez le client. Les tests alpha sont menés après la fin des tests système et avant les tests bêta. Ce test vise à identifier les bogues ou défauts liés à l’utilisabilité, la fonctionnalité et la cohérence.
Dans ce type de test, un groupe de personnes appelées « testeurs » effectue des opérations similaires à celles des utilisateurs finaux puis signale les problèmes rencontrés. Le but principal des tests alpha est de s’assurer que tous les modules sont bien intégrés et fonctionnent comme attendu.
Lorsque nous sommes passés par l’étape Alpha pour BankerBox, nous avons sollicité des pairs spécialisés dans le produit, le logiciel, et dans notre cas (développer une solution pour les banques) plusieurs banquiers d’investissement et contacts dans la haute finance.
Un logiciel en version alpha est complet sur le plan des fonctionnalités mais probablement sujet à des bogues. L’objectif du test alpha est d’améliorer le produit en repérant les problèmes avant le passage en test bêta et d’ajouter éventuellement des ajustements de dernière minute suggérés au fil des retours de l’alpha.
3. Version Bêta
La phase bêta, nommée d’après la deuxième lettre de l’alphabet grec, est le nom de code qui signifie qu’un logiciel est passé à la seconde étape de test et est prêt à être utilisé par des clients ou utilisateurs externes, souvent appelés « testeurs bêta ». Certaines organisations appellent aussi cette étape la phase « Early Adopter ».
Une fois qu’une version bêta est diffusée, elle subit généralement des tests plus poussés que lors de la phase alpha. Cela permet aux entreprises d’estimer la performance de leur logiciel dans des conditions réelles d’exploitation.
Après l’acquisition de BankerBox par SS&C Intralinks, nous avons rapidement réalisé quelques points clés d’intégration entre notre logiciel et les systèmes plus larges de l’entreprise (authentification, serveurs cloud, etc.). Ensuite, nous avons présenté la solution en démonstration et collaboré avec plusieurs clients de l’entreprise pour les inviter à « tester la bêta » en direct sur un dossier de fusion-acquisition.
Cela nous a permis d’obtenir du retour, d’établir une relation client et d’identifier les points où le logiciel devait évoluer pour répondre aux exigences et au « niveau » attendu pour un Release Candidate (RC) ou une Disponibilité Générale (GA).
Dans ce type de test, les clients donnent un retour précieux sur le fait que le produit ou l’application répond à leurs attentes concernant la fonctionnalité, la convivialité, la performance, la fiabilité, la montée en charge, etc. Les retours des utilisateurs finaux aident à améliorer l’expérience utilisateur et à corriger les problèmes opérationnels avant la mise en production du produit. Il existe deux types de phases bêta :
- Bêta ouverte : Durant cette phase, toute personne souhaitant participer au processus de test bêta peut le faire. Cela aide les développeurs à identifier et corriger rapidement et facilement les bogues grâce aux retours de multiples utilisateurs qui peuvent faire ressortir des problèmes.
- Bêta fermée : À cette étape, il y a un marché cible spécifique constitué de groupes déterminés de testeurs. Le marché cible permet de concentrer les tests logiciels sur certains aspects et garantit que tout fonctionne selon les besoins des consommateurs ciblés.
4. Release Candidate
Un release candidate (RC) est une version pré-livraison du logiciel qui se prépare à sa sortie finale (en phase RC) auprès du public. Cela s’appelle parfois « Disponibilité Contrôlée ». Même si elle inclut l’ensemble des fonctionnalités prévues et fonctionne comme attendu, elle peut encore évoluer, parfois de manière radicale, en fonction des retours reçus.
Les développeurs peuvent publier plusieurs release candidates avant de diffuser la version finale pour s’assurer que le programme ne plante pas sous forte charge, ne provoque pas de fuite mémoire significative, etc.
5. Disponibilité Générale
La disponibilité générale (GA) signifie qu'un produit ou service a été mis à la disposition de la plupart des clients (généralement à l’échelle mondiale), habituellement via des canaux commerciaux. En ingénierie logicielle, cette expression fait généralement référence à une application web ou une application accessible à tous les utilisateurs ciblés. Pendant cette phase, toutes les mises à jour ou travaux de développement supplémentaires sur le produit visent à en améliorer les fonctionnalités et les performances afin de le rendre plus attractif pour les clients.
Autrefois connu sous le nom de BankerBox, désormais « Deal Marketing » sous la nouvelle marque, une fois que nous avons atteint la Disponibilité Générale, nous avons été en mesure d’étendre le produit auprès de clients partout en Amérique du Nord et de recueillir des retours précieux, des chiffres d’utilisation, des mesures de scalabilité, etc. pour valider l’adéquation produit-marché avant de passer à la phase finale du cycle de vie logiciel : la version de production.
6. Version de production
Une version stable est une version d’un paquet logiciel qui a été testée et vérifiée. Il s’agit de la dernière (et parfois de la version finale) d’un programme considérée comme sûre pour le public. Ce type de version est également appelé « Stable ».
Lorsqu’un logiciel ou une application web entre dans cette phase, cela permet à l’organisation dans son ensemble et au marché de mesurer le niveau de préparation de votre produit. Chez SS&C Intralinks, j’ai rattaché les grandes initiatives transversales auxquelles j’ai contribué, en tant que responsable produit, à ces différentes phases.
À la phase de Production, nous avons pu élaborer une stratégie d’offre, effectuer des lancements marketing et commerciaux à grande échelle, ainsi que fournir le soutien nécessaire à travers le service client, l’ingénierie de la fiabilité du site, et d’autres départements, afin d’assurer le succès du produit.
Ce produit est considéré comme complet selon la plupart des standards, bien qu’il puisse subsister quelques problèmes mineurs jugés acceptables. Dans certains cas, comme pour Linux, on distingue deux types de versions stables : les LTS (prise en charge à long terme) et les versions stables classiques.
- Versions stables classiques – Ce sont les types de versions les plus courantes. Elles sont faciles à installer (dans le cas des logiciels systèmes) et, comme leur nom l’indique, elles sont stables. Si vous souhaitez tester un logiciel dans un environnement de production, c’est le type de version que vous utiliserez généralement. Pour les applications web, les versions stables classiques sont souvent appelées versions « majeures ».
- Versions LTS (longue durée de support) – Elles sont spécialement conçues pour une utilisation sur le long terme en environnement de production. Ces versions bénéficient d’un support plus long que les versions stables classiques (le délai moyen entre deux versions LTS est de trois ans). Cela signifie qu’elles ont été testées de manière approfondie et sont considérées comme plus sûres que les versions stables classiques.
Dernières réflexions
Comprendre les différentes phases du cycle de vie de la publication d’un logiciel est un excellent moyen pour un chef de produit de cadrer et de relier les activités transverses et celles orientées client aux différentes étapes du SRLC. Cela permet une segmentation claire du produit dans l’ensemble des objectifs, stratégies et initiatives de l’entreprise.
Utiliser ces étapes comme « points de déclenchement » m’a permis d’intégrer avec succès mon produit dans une grande entreprise, et de rythmer les différentes actions pour assurer le succès sur le marché.
Une fois les étapes du SRLC franchies, que le produit a traversé ses cycles de vente et de croissance, et que l’organisation détecte des signaux indiquant que le produit arrive à maturité, commence alors le cycle de maintenance, qui inclut :
- la correction de bugs signalés par le client durant la phase de déploiement,
- l’ajout de nouvelles fonctionnalités, ou
- la modification des fonctionnalités existantes selon les besoins changeants et l’évolution technologique à la demande du client.
Enfin, à un moment donné, tous les produits logiciels atteignent leur fin de vie lorsqu’ils ne sont plus pris en charge par leurs développeurs.
Pour en savoir plus sur les meilleures pratiques de gestion et de développement produit, n’hésitez pas à vous abonner ! À bientôt.
Lectures associées :
- 6 étapes du cycle de vie du développement logiciel (SDLC)
- Comment rédiger des notes de version qui raviront vos utilisateurs
Liste associée d’outils : Outils de gestion de publication logicielle
À voir également :
