Le calendrier des sorties de navigateurs a changé cette semaine, et il a changé pour tout le monde en même temps. Mozilla a publié Firefox 155 le 1er septembre, deux semaines avant la date initialement prévue du 15 septembre, première version d’un nouveau rythme de deux semaines. Google a fait passer Chrome 154 dans le canal Beta le 2 septembre selon son propre nouveau calendrier, et Chrome 153 Stable arrive le 8 septembre. Microsoft a ouvert la voie : Edge 152, le 27 août, a été sa première version Stable à deux semaines.
Depuis 2021, les trois navigateurs qui portent l’essentiel du trafic web mondial publiaient chacun une version majeure environ toutes les quatre semaines. À partir de ce mois-ci, cet intervalle est divisé par deux.
Qui a annoncé quoi, et quand
Rien de tout cela n’est arrivé sans préavis, mais les trois annonces se sont étalées sur six mois, ce qui explique que l’effet cumulé soit passé facilement inaperçu.
Google a publié le plan sur le Chrome for Developers blog le 3 mars. À partir de Chrome 153, une nouvelle Beta et une nouvelle Stable sortent toutes les deux semaines sur Desktop, Android et iOS. Les canaux Dev et Canary ne changent pas. Les mises à jour de sécurité hebdomadaires entre deux jalons continuent. Extended Stable, le canal sur lequel la plupart des administrateurs en entreprise figent leur parc, reste sur un cycle de huit semaines. Le tableau du billet montre l’ampleur du décalage : Chrome 153 Stable était attendu le 22 septembre et sort désormais le 8 septembre ; Chrome 154 passe du 20 octobre au 22 septembre.
Microsoft a suivi le 11 juin. À partir d’Edge 152, le 27 août, le canal Stable passe à deux semaines, et l’entreprise a été explicite sur ce que cela signifie en volume : chaque version Stable contient à peu près la moitié des changements de l’ancienne version mensuelle. Extended Stable conserve son rythme de huit semaines et reprend désormais une version sur quatre, si bien que 156, 160 et 164 sont les prochains jalons Extended Stable. Microsoft conseille aux organisations de placer un groupe pilote sur Beta ou Enterprise Preview afin que les problèmes apparaissent avant que Stable n’atteigne la production.
Mozilla est arrivé en dernier, et avec le plus de prudence. Sylvestre Ledru, Director of Engineering chez Mozilla, a indiqué en juillet sur la liste dev-platform que l’entreprise était « planning to move Firefox Desktop and Android from a 4-week release cadence to a 2-week release cadence starting in September 2026. » En français : elle prévoyait de faire passer Firefox Desktop et Android d’un rythme de sortie de quatre semaines à un rythme de deux semaines à partir de septembre 2026. The Register a rapporté le changement le 17 juillet et noté que Mozilla le présente comme une expérience susceptible d’être annulée. Le Mozilla Support Blog a confirmé les dates le 19 août : Firefox 155 le 1er septembre comme première version à deux semaines, avec cette réserve explicite qu’un rythme plus rapide « doesn’t mean Firefox will ship twice as many features. » En français : ne signifie pas que Firefox livrera deux fois plus de fonctionnalités. Firefox ESR, la branche annuelle à support long, n’est pas concernée ; The Register indique que Firefox 153 est la prochaine base ESR.
Ce qui est réellement sorti cette semaine
Firefox 155 est un bon test pour vérifier si « moitié moins de changements, deux fois plus souvent » tient la route. Ses notes de version du 1er septembre mentionnent l’extension de Smart Window, assisté par IA, aux États-Unis, au Canada et à la France, un compteur de traqueurs bloqués dans la barre d’adresse, la réorganisation des conteneurs dans les Paramètres, ainsi que des correctifs pour les interruptions de l’audio en arrière-plan et pour un vieux bug Linux qui empêchait les machines de se mettre en veille après une session de navigation.
Les changements destinés aux développeurs, consignés sur MDN, sont la partie qui touche les sites web. La fonction CSS attr() fonctionne désormais dans n’importe quelle propriété avec des valeurs typées et des valeurs de repli, et plus seulement dans content. Deux nouvelles fonctions CSS, progress() et alpha(), arrivent aux côtés de font-width, nouveau nom de font-stretch. JavaScript gagne Promise.allKeyed() et Promise.allSettledKeyed(). Les imports de modules échoués ne sont plus mis en cache, de sorte qu’un script qui a échoué sur un réseau instable peut réussir à la tentative suivante. Côté réseau, Firefox 155 implémente Happy Eyeballs version 3 pour la mise en concurrence des connexions IPv6 et IPv4 et négocie QUIC version 2 pour HTTP/3.
Ce n’est pas spectaculaire, et c’est précisément le but. La justification avancée par Google est que « the smaller scope of these releases minimizes disruption and simplifies post-release debugging. » En français : le périmètre réduit de ces versions limite les perturbations et simplifie le débogage après publication. Firefox 155 ressemble exactement à ce type de version : une poignée d’ajouts à la plateforme, une poignée de correctifs, livrés en deux semaines.
Pourquoi les trois ont bougé à la même saison
Google et Microsoft partagent le moteur Chromium : une fois le calendrier de Chrome modifié, celui d’Edge allait suivre. Le raisonnement de Mozilla, tel que le rapporte The Register, était plus interne : des fonctionnalités terminées attendaient des semaines le train suivant, et une série imprévisible de versions intermédiaires entre deux sorties était plus difficile à planifier qu’un rythme fixe de deux semaines.
Chrome est passé de six à quatre semaines entre les versions en 2021 et a ajouté des mises à jour de sécurité hebdomadaires en 2023 ; deux semaines est l’étape suivante dans la même direction.
Ce que cela signifie pour votre entreprise
Votre site rencontre désormais un nouveau moteur de navigateur environ tous les quinze jours. Pour la plupart des sites, c’est invisible, et cela doit le rester. Les éditeurs de navigateurs mènent des tests de compatibilité précisément pour qu’un changement de version ne casse pas les pages. Si votre site dépend d’un comportement propre à un éditeur, d’un polyfill qui lit les numéros de version ou d’un widget tiers vieillissant, la fenêtre entre « un changement arrive en Beta » et « un changement est sous les yeux de vos clients » est passée d’environ quatre semaines à trois.
Le canal Beta est le système d’alerte précoce, et il est gratuit. Chrome publie chaque Beta trois semaines avant la Stable correspondante. Le conseil de Microsoft aux entreprises vaut tout autant pour un site marketing : gardez une machine, ou un profil de navigateur, sur Beta et parcourez votre tunnel de paiement, vos formulaires et votre parcours de réservation une fois tous les quinze jours. C’est moins coûteux que d’apprendre par un client qu’un bouton de paiement ne fonctionne plus.
Cherchez dans vos statistiques une marche, pas une tendance. Si une mise à jour de navigateur casse quelque chose, elle le fait à une date précise. Segmentez le taux de conversion par navigateur et par version dans votre outil d’analyse, et cherchez une chute brutale qui commence un jour de sortie et ne touche qu’un seul navigateur. Ce motif est l’empreinte d’un bug de compatibilité.
Maintenez vos propres dépendances à jour. Les sites qui peinent avec des cycles de navigateur rapides sont généralement ceux qui tournent sur un framework JavaScript, un CMS ou un plugin en retard de plusieurs années. Les éditeurs de ces outils testent avec les navigateurs actuels, pas avec leur propre produit d’il y a plusieurs années. C’est le rythme de maintenance que nous intégrons à chaque site web que nous livrons : une revue des dépendances à échéance fixe, pas quand quelque chose casse.
Les parcs d’entreprise sont largement épargnés, et cela compte si vous leur vendez. Chrome comme Edge maintiennent Extended Stable à huit semaines, et Firefox ESR reste annuel. Si vos clients sont des utilisateurs professionnels sur des appareils gérés, ils verront moins de changements de moteur que le grand public, et des fonctionnalités livrées dans une version Stable à deux semaines peuvent mettre deux mois à les atteindre. Ne construisez pas une page d’atterrissage autour d’une fonctionnalité CSS toute neuve pour un public qui ne la verra pas avant novembre.
Notre lecture : c’est une bonne nouvelle pour le web et un peu plus de travail pour ceux qui y maintiennent des sites. Des versions plus petites et plus fréquentes sont plus faciles à déboguer et plus rapides à corriger. Le prix à payer, c’est que la vieille habitude de vérifier la compatibilité des navigateurs « à peu près une fois par mois » ne correspond plus à la réalité. Mettez un rappel tous les quinze jours dans l’agenda ; c’est l’essentiel du travail.
