Chrome passe à un cycle de mise à jour de deux semaines: la sécurité à l'horloge

Google a fait passer Chrome 153 dans le canal Stable le 8 septembre 2026 et, avec lui, a fait basculer le navigateur le plus utilisé au monde d'un cycle de publication de quatre semaines à un cycle de deux semaines. Ce changement, annoncé en mars et activé cette semaine, signifie une nouvelle version bêta et une nouvelle version stable toutes les deux semaines sur ordinateur, Android et iOS. Chrome 154 est déjà en bêta et sa sortie stable est prévue pour le 22 septembre.

À lire aussi: Project Zenith de Microsoft veut rendre Windows « prêt à coder ». Les développeurs ne sont pas convaincus · L'action ServiceNow a perdu 27 % quand la peur de l'IA a gagné le logiciel.

Le calendrier n'est pas fortuit. Google présente ce rythme accéléré autant comme une mesure de sécurité que comme une offensive de fonctionnalités, et Chrome 153 le dit sans détour: la version regroupe 230 correctifs de sécurité, dont cinq classés critiques, et un zero-day déjà exploité par des attaquants. Des versions plus rapides, selon l'argument, réduisent la fenêtre entre le moment où un correctif arrive dans le code public et celui où il parvient aux utilisateurs.

Ce qui change concrètement

Chrome suivait un cycle de jalons de quatre semaines depuis 2021, et de six semaines auparavant. À partir de Chrome 153, l'intervalle est divisé par deux:

• Un nouveau jalon Stable toutes les deux semaines. Chrome 153 est arrivé le 8 septembre; Chrome 154 est prévu pour le 22 septembre.
• Une nouvelle bêta toutes les deux semaines également. Les versions bêta sortent désormais environ trois semaines avant la version stable correspondante.
• Toutes les plateformes. Le rythme de deux semaines couvre ordinateur, Android et iOS.
• Dev et Canary sont inchangés. Google conserve son canal Dev hebdomadaire et son canal Canary quotidien tels quels.
• Des versions plus petites. Chaque jalon contient moins de changements, ce qui, selon Google, rend les régressions plus faciles à isoler.

Le mécanisme sous-jacent est une version « early stable »: un candidat est livré environ un jour après la création de la branche, ce qui permet à Google de guetter les régressions avant le déploiement complet. Avec le nouveau calendrier, Chrome 153 a été coupé pour le canal Stable le 25 août et a atteint les utilisateurs le 8 septembre, une fenêtre de stabilisation plus courte que ne le permettait l'ancien plan.

Le rythme, en clair

L'expression à retenir est celle de « semaine sans version » (no-release week). Elle ne signifie pas une semaine sans correctifs. Depuis 2023, Chrome exploite un canal de sécurité hebdomadaire distinct qui rétroporte les correctifs vers la version stable en cours entre les jalons. Une semaine sans version est simplement une semaine où le numéro de version du navigateur ne bouge pas: pas de nouvelles fonctionnalités, pas de jalon, mais toujours la mise à jour de sécurité habituelle.

Avec l'ancien rythme mensuel, un jalon arrivait environ toutes les quatre semaines, laissant deux semaines plus calmes entre les deux. Dans un cycle de deux semaines, ces vides disparaissent: une semaine apporte généralement un jalon, la suivante un correctif de sécurité ou le début de la bêta suivante. Pour la plupart des utilisateurs, l'effet concret est fait de mises à jour de fonctionnalités plus petites et plus fréquentes, et d'invitations plus fréquentes à redémarrer pour mettre à jour. Pour les entreprises, cela signifie un saut de version sur les appareils gérés deux fois plus souvent.

Rien de tout cela ne modifie le mécanisme de mise à jour. Chrome télécharge toujours les mises à jour en arrière-plan et ne les applique qu'après un redémarrage, et Google déploie toujours la version sur plusieurs jours plutôt que sur toutes les machines à la fois. Sur les Chromebooks, l'entreprise indique que les nouvelles versions continueront d'arriver après des tests de plateforme dédiés, avec des précisions à venir pour les appareils gérés.

Pourquoi Google accélère

L'explication de Google renvoie à l'IA. « Avec les outils automatisés de découverte basés sur l'IA et les signalements de bugs de la communauté qui génèrent un volume de correctifs plus élevé, des cycles de publication plus courts simplifient nettement la gestion des correctifs de sécurité », a écrit l'équipe Chrome. Réduire le délai entre l'arrivée d'un correctif dans le code public de Chromium et sa livraison aux utilisateurs, poursuit l'article, maintient l'écart de correctif « N-day » aussi petit que possible.

L'écart N-day est un vrai problème, pas un slogan. Dès qu'un correctif apparaît dans l'arbre source public de Chromium, quiconque surveille le dépôt peut l'étudier et remonter à un exploit visant la version non corrigée. En principe, chaque jour entre un correctif public et sa livraison aux utilisateurs est un jour qu'un attaquant peut exploiter. Google a déclaré à TechCrunch que les outils automatisés et les signalements de la communauté ont fait grimper le volume de correctifs, et Engadget a rapporté que l'effort s'appuie sur des outils propulsés par Gemini pour trouver les vulnérabilités plus vite.

L'avis de Chrome 153 illustre la tendance de l'IA de façon concrète. Parmi les bugs de gravité élevée crédités figurent des découvertes attribuées à « Google BigSleep@Grape » et à « OpenAI Codex Security », deux systèmes automatisés qui déposent désormais les mêmes rapports que les chercheurs humains. S'y ajoute un motif concurrentiel: des versions plus rapides permettent à Chrome de livrer des fonctionnalités web avant ses rivaux, et Google note que Microsoft, Mozilla et Brave avancent dans la même direction.

Une première version chargée

Chrome 153 montre à quoi ressemblera le nouveau rythme en pratique. L'avis du canal Stable recense 230 correctifs de sécurité, dont cinq bugs critiques: quatre failles de sûreté mémoire dans WebGL et une dans le composant Cast.

Un seul a fait les gros titres: CVE-2026-87491, une écriture hors limites dans V8, le moteur JavaScript et WebAssembly de Chrome. Google le classe « moyen », mais l'avis ajoute la phrase qui compte: « Google est conscient qu'un exploit pour CVE-2026-87491 existe dans la nature. » SecurityWeek l'a comptabilisé comme le septième zero-day Chrome exploité activement en 2026, et l'agence américaine de cybersécurité CISA l'a ajouté à son catalogue des vulnérabilités exploitées le 9 septembre, avec une échéance de remédiation au 23 septembre.

Les versions corrigées sont 153.0.8010.36/.37 pour Windows et macOS et 153.0.8010.36 pour Linux. Selon Google, la mise à jour se déploie au cours des prochains jours et semaines, et sur Android elle arrive via Google Play. Chrome sous iOS n'est pas concerné par cette faille précise, selon l'éditeur.

Le gain de sécurité est-il aussi important qu'il y paraît?

Pas à lui seul. Le canal de sécurité hebdomadaire de Chrome (introduit avec Chrome 116 en 2023) livrait déjà les correctifs selon un rythme de sept jours. Diviser par deux l'intervalle des jalons, de 28 à 14 jours, s'ajoute à un mécanisme qui tournait déjà à la moitié de ce délai. Les plus fortes réductions de la latence des correctifs chez Chrome sont venues en 2020 et 2023, pas maintenant.

Les dates de signalement de l'avis de Chrome 153 soulignent ce point. Beaucoup des bugs corrigés le 8 septembre ont été signalés en mars, avril et mai 2026, des mois, et non des semaines, avant leur livraison. Le temps entre la découverte et la livraison est dominé par le triage, la reproduction, le développement du correctif et la revue, et un train de publication plus rapide ne comprime que le dernier maillon de cette chaîne. Ce que le cycle de deux semaines change réellement, c'est la latence des correctifs qui voyagent avec un jalon, et le rythme global auquel le navigateur évolue en tant que produit. C'est une vraie amélioration, mais incrémentale et superposée à une pratique existante.

Les compromis sont tout aussi réels. Des jalons plus fréquents signifient plus de tests et plus de redémarrages forcés, et des versions plus petites ne sont pas automatiquement plus sûres. Un train plus rapide laisse moins de temps pour repérer une mauvaise compilation avant qu'elle n'atteigne tout le monde, et c'est pourquoi l'étape early stable existe. Savoir si deux semaines est le bon intervalle, ou un intervalle qui échange la stabilité contre la vitesse, voilà l'expérience que Google vient de lancer.

Ce que cela signifie pour les entreprises

La recommandation de Google est inhabituellement directe. Pour les entreprises et les intégrateurs de Chromium, le canal Stable à deux semaines « devient le choix le plus sûr » et devrait être utilisé par la plupart des organisations. Extended Stable reste destiné à celles qui ne peuvent pas absorber une version toutes les deux semaines.

C'est avec Extended Stable que l'arithmétique devient inconfortable. Son intervalle de huit semaines n'a pas changé, mais le nombre de jalons qu'il contient a doublé: il couvre désormais quatre versions stables au lieu de deux, les mises à jour fonctionnelles majeures arrivant toutes les huit semaines, Chrome 156, puis Chrome 160. Un parc sous Extended Stable peut donc accuser jusqu'à trois versions de jalon de retard sur le canal Stable, contre une auparavant.

Google indique continuer à rétroporter chaque semaine les correctifs de sécurité vers Extended Stable, ce qui atténue le risque. Mais sa propre documentation de publication de Chromium précise que les correctifs complexes ou risqués, ainsi que les fonctions de sécurité plus importantes, peuvent ne pas être rétroportables et n'arriver que sur le canal Stable classique. Extended Stable est proposé sous Windows et macOS; les parcs Linux n'ont pas d'option équivalente et adoptent le rythme de deux semaines, qu'ils le veuillent ou non.

La charge opérationnelle augmente elle aussi. La bêta sort désormais toutes les deux semaines et parvient aux utilisateurs environ trois semaines avant le canal Stable, si bien qu'une équipe qui valide sur la bêta affronte environ quatre cycles de test au sein d'un seul cycle de huit semaines d'Extended Stable, au lieu de deux. La recommandation de test n'a pas changé; le travail qui la sous-tend a doublé.

Sept ans d'accélération

L'histoire des versions de Chrome est une compression continue de l'intervalle entre les mises à jour. En 2010, l'équipe a adopté la philosophie « publier tôt, publier souvent ». En 2021, elle est passée de six à quatre semaines. En 2023, elle a ajouté les mises à jour de sécurité hebdomadaires et la version early stable. Le passage à deux semaines en 2026 est le cycle de jalons le plus court jamais adopté par le navigateur et, avec environ 26 versions stables par an au lieu de 13, il double le nombre de fois où l'IT doit intervenir sur les machines gérées.

Ce qu'il faut surveiller

Trois choses montreront si le changement porte ses fruits. La première est Chrome 154 le 22 septembre: un atterrissage fluide validerait le calendrier compressé, tandis qu'une régression précoce rouvrirait le débat sur le point où la vitesse devient excessive. La deuxième est de savoir si le secteur suit Google comme celui-ci le prédit; Microsoft Edge est passé à un cycle majeur de deux semaines fin août, et Mozilla et Brave ont annoncé des plans similaires. La troisième est la documentation destinée aux entreprises, qui décrivait encore cette semaine l'ancien rythme par endroits.

Pour l'utilisateur ordinaire, le conseil est simple et inchangé: garder Chrome à jour et le redémarrer lorsqu'il le demande. Le navigateur fonctionne désormais sur une horloge plus rapide, mais le correctif de sécurité qui compte le plus une semaine donnée ne compte vraiment qu'une fois installé.