Versions 1.0 et 1.x : pourquoi les mises à jour sont en développement avant la disponibilité de la v1.0 ?

Par:
francoistonic

lun, 26/01/2026 - 11:50

Réflexion. Il arrive souvent qu'un éditeur lance le développement d'une mise à jour d'un OS, ou un outil, ou d'un framework, avant même la sortie de la version x.0. Cette situation peut sembler paradoxale, mais en réalité, cela correspond aux cycles de développement.

Cas concret

Un site internet en production depuis plusieurs années avec une stack technique ancienne prépare une Vnext que l'on pourrait assimiler à une version 1.0. Cette Vnext introduit une nouvelle stack technique, la plus récente possible, réécriture quasi complète du core code, remise à plat du back office, simplification de nombreux processus internes, réduction des bases de données, nouvelle interface, structure plus modulaire, nouvelle infrastructure... Bref, une refonte totale ou presque.

Le développement s'approche de la fin mais...

Dans la dernière phase de développement de la Vnext 1.0 : l'objectif est de terminer les spécifications les plus importantes, d'avoir un scope fonctionnel le plus proche possible du site actuel, assurer la bonne migration des comptes utilisateurs, des bases de données, etc.

... il faut tenir au maximum les délais

À un moment donné, il n'est plus possible de reculer la date de déploiement. Cette échéance doit fixer les dernières fonctionnalités incontournables avant les tests finaux et les tests de migration. Cela signifie que des features non développées ou encore incomplètes doivent être décalées à la version x.1, soit par manque de temps, soit parce que la fonctionnalité peut attendre la mise à jour.

Il faut donner le go final et déployer.

La version x.1 se prépare avant le déploiement de la version x.0.

Dans notre cas concret, la Vnext 1.1 est dans le cycle de vie du projet même si son développement n'est pas encore (réellement) actif. Il ne faut pas attendre le déploiement de la x.0 pour spécifier la x.1. Cette préparation en amont doit permettre :

1 / avoir une vision la plus claire possible des fonctionnalités qui compléteront la v1

2 / de mieux préparer le déploiement de la v1

3 / établir un planning de sortie de la v1.1 permet de faire un rétro-planning

Et cela évite de stresser inutilement les développeurs et d'aborder le plus sereinement possible la fin du premier cycle de développement.

Et vous, quelles expériences avez-vous vécu ?