Firefox passe à une nouvelle version toutes les deux semaines

Mozilla commence à faire évoluer Firefox vers un cycle de publication de deux semaines, contre quatre semaines auparavant, sur ordinateur comme sur Android. La transition débute avec Firefox 155 Beta et doit ensuite concerner les canaux Nightly, Beta et Release. Pour l'utilisateur, les correctifs et fonctions prêts pourront ainsi arriver plus rapidement, sans signifier qu'une quantité deux fois plus importante de nouveautés sera développée.

Ce changement paraît discret face à une nouvelle interface ou à une fonction visible. Il modifie pourtant le rythme de travail de Mozilla, des équipes de traduction, des responsables informatiques et des éditeurs d'extensions. Il impose surtout de distinguer une version plus fréquente d'une mise à jour moins contrôlée : la cadence se raccourcit, mais les étapes de test restent présentes.

La réponse rapide

Un mois d'attente ramené à deux semaines

Avec un cycle de quatre semaines, une modification prête juste après la fermeture d'une version peut attendre le train suivant. En rapprochant les départs, Mozilla gagne de la souplesse pour distribuer un correctif ou une fonction qui a terminé sa validation. Le navigateur peut progresser par lots plus petits, plus faciles à isoler lorsqu'une régression apparaît.

Le numéro de version augmentera donc plus rapidement. Cette progression ne doit pas être interprétée comme une multiplication des ruptures majeures : les navigateurs utilisent depuis longtemps des numéros fréquents pour représenter un flux continu. Les utilisateurs doivent surtout regarder les notes de version, la politique de support et les changements incompatibles, pas la taille du numéro.

Mozilla précise que le développement ne doit pas produire deux fois plus de fonctions. Une équipe qui termine une évolution peut simplement viser une fenêtre plus proche au lieu d'attendre un mois. À l'inverse, une fonction qui manque de maturité peut rester derrière un drapeau ou poursuivre ses tests sur Nightly et Beta.

Nightly, Beta et Release conservent leur rôle

Le modèle reste organisé en plusieurs canaux. Nightly reçoit les changements les plus récents et sert à détecter tôt les problèmes. Beta rapproche le code de la version publique avec une population plus large. Release constitue la version destinée à l'usage courant. Le raccourcissement du calendrier concerne chacun de ces trains, pas la suppression des étapes intermédiaires.

Cette nuance est essentielle pour la qualité. Publier plus souvent peut réduire la taille de chaque lot, mais laisse aussi moins de temps calendaire pour observer une anomalie rare. Mozilla devra s'appuyer sur ses tests automatisés, sa télémétrie, les retours de la communauté et des mécanismes de désactivation à distance lorsqu'une fonction pose problème.

Pour les utilisateurs de Nightly ou Beta, les changements arriveront naturellement plus souvent. Ces versions restent destinées aux personnes capables de tolérer une régression et de la signaler. Installer Beta sur tous les postes d'une entreprise uniquement pour recevoir une fonction quelques jours plus tôt n'est pas une stratégie de déploiement raisonnable.

La traduction perd une semaine de marge

L'impact le plus concret annoncé par Mozilla concerne la localisation. Une chaîne d'interface pouvait auparavant arriver au plus tard environ trois semaines avant sa publication. Ce minimum passe à deux semaines, avec des échéances plus rapprochées à partir du 12 août pour Firefox et Firefox pour Android.

Les équipes ne devraient pas recevoir davantage de texte sur l'ensemble de l'année simplement à cause de cette cadence, mais elles devront absorber des lots plus fréquents. Une communauté de traduction bénévole peut difficilement garantir la même disponibilité toutes les deux semaines, en particulier pour une langue suivie par peu de contributeurs.

Mozilla expérimente plusieurs réponses. Une fonction pourrait apparaître lorsqu'une traduction est disponible plutôt que d'être immédiatement affichée en anglais. Les mises à jour intermédiaires peuvent également embarquer des traductions arrivées après la date initiale. Enfin, Pontoon propose une prétraduction issue de la traduction automatique et de la mémoire de traduction, que des humains peuvent ensuite réviser.

Cette dernière option accélère le premier jet, mais ne remplace pas une validation humaine. Dans un navigateur, une formulation ambiguë dans un réglage de confidentialité ou une boîte de dialogue de sécurité peut conduire à une mauvaise décision. La vitesse doit donc rester subordonnée à la compréhension.

Ce que cela change pour les extensions

Les développeurs d'extensions devront surveiller plus régulièrement les versions Beta et les notes destinées aux développeurs. Les API WebExtensions stables offrent une couche relativement prévisible, mais une modification de comportement, une nouvelle permission ou une évolution du moteur peut affecter une extension complexe.

La meilleure défense n'est pas de tester manuellement tous les quinze jours. Un projet maintenu doit automatiser l'installation de la prochaine Beta, lancer ses scénarios principaux et signaler rapidement les erreurs de console ou changements d'interface. Les extensions qui injectent du code dans des pages ou reposent sur des détails internes sont naturellement plus exposées que celles qui utilisent uniquement des API documentées.

Il faut aussi conserver une procédure de publication rapide sur le magasin d'extensions. Un correctif prêt après la sortie de Firefox ne devra plus attendre longtemps avant la version suivante du navigateur, mais les utilisateurs d'une extension cassée attendront toujours sa propre mise à jour.

Les entreprises doivent vérifier leur canal de support

Pour une organisation, la question n'est pas seulement de savoir quand Firefox publie une version grand public. Elle doit identifier le canal installé, les politiques gérées, les applications Web critiques et le temps disponible pour qualifier chaque évolution. Un calendrier deux fois plus fréquent rend un processus entièrement manuel plus coûteux.

Les équipes peuvent maintenir un petit groupe pilote sur la prochaine version, automatiser les tests de connexion et de saisie sur leurs applications essentielles, puis laisser la mise à jour atteindre le reste du parc si aucun blocage n'est détecté. Les politiques d'entreprise doivent être versionnées et vérifiées sur Beta avant leur arrivée en production.

Les environnements qui privilégient une stabilité longue doivent étudier le canal ESR et sa documentation plutôt que de bloquer indéfiniment les mises à jour standard. Retarder un navigateur expose à des vulnérabilités déjà corrigées. Le bon compromis consiste à obtenir un délai de qualification connu tout en conservant un chemin rapide pour les correctifs de sécurité urgents.

Une accélération commune aux navigateurs

Firefox n'est pas le seul navigateur à réduire l'intervalle entre ses versions. Cette évolution reflète un Web où les fonctions, standards et protections progressent en continu. Des lots plus petits permettent théoriquement d'identifier plus facilement la modification responsable d'un défaut et de diffuser plus vite son correctif.

La fréquence comporte néanmoins un coût pour les équipes situées autour du navigateur : documentation, traduction, support, extensions, administration et tests d'applications. La réussite du nouveau calendrier ne se mesurera donc pas au nombre de versions publiées, mais à la vitesse réelle des correctifs, au taux de régressions et à la capacité de toutes les langues à recevoir une interface compréhensible.

Pour le particulier, aucune action urgente n'est nécessaire. Il faut laisser les mises à jour automatiques fonctionner et redémarrer le navigateur lorsqu'elles sont prêtes. Pour les développeurs et responsables de parc, le rythme plus court est en revanche un signal clair : les tests de compatibilité doivent devenir continus plutôt que dépendre d'une campagne mensuelle.