Chrome passe à un rythme de deux semaines

Chrome réduit de moitié l'intervalle entre ses grandes versions. Google indique qu'il passe à un rythme de deux semaines pour les grands jalons de Chrome, contre quatre semaines, à partir de Chrome 153 le 8 septembre 2026. La raison avancée : l'apprentissage automatique trouve les failles plus vite qu'un train de quatre semaines ne peut livrer les correctifs.

Deux chiffres expliquent cette décision. Chrome 149 et 150 ont corrigé ensemble 1 072 failles de sécurité. C'est plus que le total des 23 jalons précédents.

Ce qui change et ce qui ne change pas

Les deux semaines concernent les grands jalons. Ce sont les versions numérotées qui apportent les nouveautés. Ce n'est pas le calendrier des correctifs de sécurité, et la distinction se perd facilement.

Volet	Calendrier
Grands jalons	Toutes les deux semaines, dès Chrome 153
Mises à jour de sécurité	Chaque semaine
Mises à jour de sécurité (pilote)	Deux fois par semaine

« Nous sommes en train de passer à un rythme de deux semaines pour les grands jalons de Chrome, avec des mises à jour de sécurité hebdomadaires », a écrit l'équipe sécurité de Chrome. Séparément, elle teste deux versions de sécurité par semaine.

Le changement couvre l'ordinateur, iOS et Android. TechCrunch rapporte que Mozilla, Microsoft Edge et Brave ont déjà adopté le même rythme de deux semaines.

Pourquoi le nombre de failles a bondi

L'équipe sécurité nomme la cause sans détour. Les grands modèles de langage sont le logiciel derrière les chatbots, et on peut les pointer vers du code source pour y chercher des défauts.

« Les grands modèles de langage (LLM) débloquent des capacités inédites pour la découverte automatisée de vulnérabilités », a écrit l'équipe. Elle précise que cela dépasse largement les limites de l'expertise humaine en sécurité et exige de nouvelles approches pour garder une longueur d'avance sur les attaquants.

Cela joue dans les deux sens, et c'est le point à retenir. Les mêmes outils servent aux attaquants. L'objectif affiché de Google est de réduire l'écart dit N-day, c'est-à-dire la fenêtre entre l'arrivée d'un correctif dans le code public et sa livraison aux utilisateurs. Chromium est open source : chaque correctif publié est donc aussi une description publique de la faille qu'il corrige.

Pour le seul mois de mai 2026, Google affirme que des systèmes automatisés ont empêché plus de 20 vulnérabilités d'atteindre la production. L'une était classée S1+, sa catégorie la plus grave.

Ce que cela change pour les développeurs

Vos hypothèses de test méritent un examen. Si votre processus de publication fige une version de Chrome ou fait tourner une matrice de navigateurs, cette matrice bouge désormais deux fois plus souvent. Une vérification trimestrielle contre « le Chrome actuel » n'a plus le même sens qu'en août.

Pour tout ce que vous ne pouvez pas requalifier toutes les deux semaines, Google renvoie vers le Chrome Extended Stable Channel, qu'il recommande aux entreprises et aux environnements sensibles. Ce canal échange la fraîcheur des fonctionnalités contre un cycle plus lent et prévisible. C'est le bon réglage par défaut pour les déploiements réglementés.

Les délais d'abandon restent la question ouverte. Aucune des deux sources ne dit si les retraits et les essais d'origine conservent leur compte en jalons. Si un abandon était planifié en jalons plutôt qu'en dates, sa date calendaire vient de se rapprocher. Vérifiez donc ce dont vous dépendez et qui est déjà marqué pour retrait. Les développeurs d'extensions ont déjà eu une échéance dure ce mois-ci, après que Google a retiré du Chrome Web Store toutes les extensions Manifest V2 le 1er septembre.

Ne lisez pas les 1 072 comme le signe d'un Chrome moins sûr. C'est ce qui arrive quand on lance une recherche automatisée sur une grande base de code, et trouver une faille précède sa correction. Le chiffre à suivre est la vitesse à laquelle les correctifs atteignent les utilisateurs, pas le nombre de failles comptées.

Le point plus large pour la plateforme web : les fonctionnalités arriveront en stable par plus petits incréments, plus souvent. Cela favorise les équipes qui testent en continu et pénalise les longs cycles de QA manuelle. Google subit aussi une pression concurrentielle, puisqu'il dit que le développement assisté par IA a réduit le coût de construire un navigateur.