Chrome passe à un cycle de release de deux semaines

À partir du 8 septembre 2026, Chrome 153 inaugure un rythme de publication inédit : une version stable toutes les deux semaines, contre quatre auparavant. Annoncé par Google en mars, ce changement touche Desktop, Android et iOS, et rebat les cartes du calendrier de tests des équipes web.

#Ce qui change le 8 septembre

Chrome 153 marque le passage à un cycle de deux semaines. La version 154 suivra le 22 septembre, la 155 le 6 octobre, et ainsi de suite : environ vingt-six versions stables par an, là où le rythme mensuel en produisait treize. Le canal bêta accompagne le mouvement, chaque bêta étant publiée trois semaines avant la stable correspondante. Le canal Extended Stable, lui, conserve son cycle de huit semaines pour les parcs qui privilégient la stabilité à la fraîcheur.

#Pourquoi Google accélère la cadence

La logique est celle des petits lots. Des versions plus rapprochées transportent moins de changements à la fois, ce qui réduit la surface de régression à chaque palier et raccourcit le délai entre le développement d’une fonctionnalité et sa disponibilité pour le public. Correctifs de sécurité, gains de performance et nouvelles API arrivent plus tôt, sans l’effet « grosse mise à jour » qui accompagnait le cycle mensuel. Le mouvement prolonge une trajectoire entamée en 2023 avec les mises à jour de sécurité hebdomadaires.

Caler son code sur un numéro de version de Chrome n’a jamais été une bonne idée ; à raison de vingt-six versions par an, cela devient intenable.

#La détection de fonctionnalité devient la seule stratégie tenable

Multiplier les versions par deux rend le reniflage de numéro de version (version sniffing) encore plus fragile qu’il ne l’était. La bonne pratique consiste à interroger la présence effective d’une API ou d’une propriété plutôt que la version du moteur. Les mêmes réflexes qui valent pour l’adoption des container queries ou pour la migration vers htmx 4.0 s’appliquent ici : tester la capacité, prévoir un repli, ne jamais présumer d’un numéro.

// Détecter la capacité, pas la version du navigateur
if (CSS.supports('container-type: inline-size')) {
  document.documentElement.classList.add('has-container-queries');
}

if ('URLPattern' in globalThis) {
  const route = new URLPattern({ pathname: '/articles/:id' });
  // routage côté client sans dépendance
}

// Anti-pattern : ne jamais faire ceci
// const version = navigator.userAgent.match(/Chrome\/(\d+)/);
// if (Number(version?.[1]) >= 153) { /* ... */ }

#Adapter sa veille et ses tests

Pour les équipes, l’enjeu n’est pas de suivre chaque version, mais d’installer une routine. Tester sur le canal bêta donne trois semaines d’avance pour repérer un changement de comportement avant qu’il n’atteigne les utilisateurs. Le suivi des fonctionnalités passe par le Chrome Status Roadmap et le tableau de bord Chromium, qui annoncent les évolutions palier par palier. Les en-têtes de sécurité livrés par le navigateur, comme ceux décrits dans le guide sur la Content-Security-Policy, évoluent eux aussi au fil des versions : les valider en continu évite les mauvaises surprises.

#Ce qu’il faut retenir

Chrome publie désormais une version stable toutes les deux semaines à partir du 8 septembre, soit environ vingt-six par an, la bêta gardant trois semaines d’avance et Extended Stable son rythme de huit semaines. La conséquence pratique tient en une phrase : la détection de fonctionnalité et les tests sur le canal bêta remplacent définitivement le suivi manuel des numéros de version.

Pour aller plus loin : l’annonce officielle sur le blog Chrome for Developers, Get features faster with Chrome’s two-week release cycle.