Pour un éditeur de logiciel, la question relative à la périodicité des nouvelles versions commercialisées est toujours un sujet important. Faut-il mettre sur le marché une nouvelle version tous les 3 mois, tous les 6 mois, une fois par an, tous les deux ans ou plus ?

Chaque éditeur se pose un jour ou l’autre cette question épineuse. Faut-il publier uniquement les versions majeures ou faut-il publier les différentes versions intermédiaires ? 

Les modèles SaaS et les modèles On Premise sont-ils différents au regard du cycle de vie des progiciels ?

Comment un éditeur de progiciel de gestion des Archives fait-il pour que sa solution puisse apporter une pérennité indispensable à la mise en œuvre d’un Système d’Archivage fait pour conserver des contenus numériques pendant plusieurs dizaines d’années ?

 

Il est bien évident pour nous que plusieurs cycles de vie du logiciel se superposent. Sans donner dès l’introduction toutes les clefs permettant de prendre cette décision, nous noterons que le cycle de production est essentiellement un cycle technique de mise à disposition de nouvelles fonctionnalités. Le cycle de publication est lié à deux enjeux contradictoires qui sont la communication produit, et la maintenance dans le temps. Enfin, le cycle de maintenabilité est lié en grande partie aux enjeux de sécurité applicative, puisque toute application aujourd’hui s’appuie sur un écosystème dont elle dépend.

Le cycle de production d’un logiciel correspond à l’ensemble des livraisons effectuées en interne permettant de tester et d’évaluer les fonctionnalités nouvelles, améliorations et correctifs mis à disposition. Comme la plupart des éditeurs, les noyaux en développement chez Spark Archives le sont en continu, à savoir qu’ils sont livrés quotidiennement aux équipes produit en charge de leur réception, afin de réduire les itérations et de permettre une intégration simplifiée de ces changements. Cette automatisation s’appuie sur une plateforme d’intégration continue et des tests automatisés permettant le plus possible d’accélérer cette phase de mise en production interne.

 

Le cycle de publication correspond à la mise à disposition du public d’une version testée, documentée, packagée. Elle est liée à des besoins de communication autour du produit, des besoins de mises à disposition de client de fonctionnalités attendues. Par ailleurs, il s’agit également de versions qui seront maintenues dans le temps. En cela, on souhaite que leur nombre reste raisonnable. Nous verrons plus avant que Spark Archives a décidé d’avoir une version majeure par an, et inaugure cette politique avec Spark Ajantâ.

 

Le cycle de maintenabilité correspond à la durée de vie possible et souhaitable d’une version. Plus long, et plus aléatoire, ce cycle est très dépendant des enjeux de sécurité logiciels. On pourrait dire qu’il est au maximum d’une durée correspondant à la durée de mise à jour des composants logiciels externes embarqués dans la solution. En s’appuyant le plus possible sur des composants "open source" dans leur versions LTS (Long-term Support), Spark Archives fait le pari d'avoir la durée de maintenabilité la plus longue possible pour ses clients. Cependant, comme nous le verrons également plus en avant dans cet article, il faut comprendre que dans certain cas, une montée de version restera nécessaire. 

Chez Spark Archives, nos versions internes sont numérotées avec un indice de version majeure, un indice de version mineure et un indice de correctif. Depuis février 2019, nous avons adopté un nom de version commercial pour chaque version majeure et une cadence de mise sur le marché d’une version majeure par an.

Pour exemple, Spark Ajantâ est la version majeure de l’année 2019.

 

La sortie d’une version majeure est un évènement chez Spark Archives car elle correspond à mettre sur le marché le fruit d’une année de travail de notre R&D. Chaque version majeure comporte de nombreuses nouvelles fonctionnalités issues de la roadmap produit.

 

En réalité, une version majeure est le fruit de plusieurs sprints consécutifs intégrant pour chaque sprint une phase d’étude, une phase de spécification, une phase de développement, suivi d’une phase de tests fonctionnels et techniques et des tests de sécurité. La documentation termine ainsi chaque sprint. Chacun de ces sprints s’appuie par ailleurs sur nos outils d’intégration continue, permettant de garantir la qualité du code logiciel.

 

En plus d’une version majeure annuelle, Spark Archives délivre une version intermédiaire permettant de mettre à disposition des patchs de sécurité et quelques améliorations intermédiaires mises à disposition dans un second temps. Si nous faisions un parallèle avec certains éditeurs, cette version intermédiaire pourrait être assimilée à un « Service Pack ». On l’aura compris, ce livrable intermédiaire, généralement livré en cours d’année, comporte quelques correctifs non critiques permettant d’améliorer la version majeure livrée quelques mois avant.

Si des vulnérabilités mineures sont détectées, celles-ci font l’objet de correctifs qui sont alors livrés dans la version intermédiaire en cours d’année ou dans la version majeure suivante.

Si des failles de sécurité critiques sont découvertes en cours d’années, une correction ou un contournement est mis à disposition immédiatement.

Si des failles de sécurité critiques sont liées à des composants tiers (base de données, runtime java, …),  Spark Archives informe ses clients et propose une prestation de montée de version lorsque cela est possible. 

Au-delà de 4 années, il est fortement conseillé de migrer la solution pour éviter tout risque d’obsolescence.Spark Ajantâ s'appuie sur des normes du marché. Ces dernières évoluent tous les 3 à 5 ans. Il est important de respecter les règles de l'Art souvent précisées dans ces textes. Des évolutions sont nécessaires pour que le produit reste leader de son marche. Bien entendu, il n’y a aucune obligation de migrer à chaque nouvelle version. Il est très important de suivre les évolutions pour un produit "SAE" afin d’éviter l’obsolescence normative. Dans le cadre d’un SAE certifié, la non migration tous les 3 ans pourrait être considérée comme une anomalie bloquante aillant pour conséquence de perdre sa certification.