Le cycle de publication bimensuel de Chrome accélère les mises à jour, mais la sécurité dépend toujours de l’adoption

Google a activé le cycle de publication bimensuel de Chrome avec Chrome 153, réduisant l’intervalle entre les principales versions stables de quatre semaines à deux. La version du 8 septembre concerne les ordinateurs de bureau, Android et iOS. Elle transforme également une décision de gestion des versions annoncée en mars en un nouveau rythme de fonctionnement pour une grande partie du web.

Ce calendrier reflète deux pressions qui vont de plus en plus dans le même sens. Les outils d’IA aident les développeurs à créer plus vite des fonctionnalités pour les navigateurs, mais ils aident aussi les chercheurs à découvrir davantage de failles de sécurité. Dans le même temps, les navigateurs récents utilisent des assistants IA et l’automatisation pour remettre en cause l’expérience familière des onglets et de la barre d’adresse.

Cette combinaison rend l’attente de quatre semaines de plus en plus coûteuse. Pourtant, publier deux fois plus souvent ne rend pas automatiquement Chrome deux fois plus sûr. Google doit toujours identifier les vulnérabilités, produire des correctifs fiables, distribuer les mises à jour et convaincre les particuliers comme les organisations de redémarrer leurs navigateurs.

L’enjeu central n’oppose donc pas Chrome à un concurrent unique. Il oppose la vitesse de livraison à la stabilité et à la discipline de déploiement attendues d’un logiciel utilisé sur des appareils grand public, dans les entreprises, les établissements scolaires et les institutions publiques.

Le cycle de publication bimensuel de Chrome commence avec la version 153

Chrome 153 établit une nouvelle référence : une version stable majeure toutes les deux semaines, avec une version bêta correspondante suivant le même rythme accéléré.

Google a d’abord détaillé ce changement dans son annonce de mars consacrée au cycle de publication bimensuel. Chrome publiait des jalons majeurs toutes les quatre semaines depuis 2021. Avant ce changement, son cycle standard durait six semaines.

L’entreprise a également introduit des mises à jour de sécurité hebdomadaires en 2023. Cette distinction est importante, car un jalon majeur et une mise à jour de sécurité répondent à des objectifs différents. Chrome peut déjà distribuer des correctifs urgents sans attendre la prochaine version numérotée.

Le nouveau calendrier étend ce rythme plus rapide au-delà de ces correctifs de sécurité hebdomadaires. Il permet aux améliorations de performances, aux capacités de la plateforme web, aux fonctionnalités du navigateur, aux correctifs de bugs et aux travaux de sécurité de circuler plus fréquemment dans les canaux bêta et stable.

Chrome 153 a atteint le canal stable le 8 septembre 2026. Chrome 154 Beta était déjà disponible ce jour-là, et sa version stable était prévue pour le 22 septembre, selon la confirmation de lancement de Google.

Les ordinateurs de bureau, Android et iOS sont inclus dans cette transition. Dev et Canary, les canaux de test moins stables de Chrome, conservent leurs calendriers existants. Les versions de ChromeOS nécessitent des tests supplémentaires propres à la plateforme et ne suivent donc pas nécessairement le navigateur grand public le même jour.

Extended Stable reste également disponible selon son cycle actuel de huit semaines. Ce canal donne aux administrateurs d’entreprise et aux intégrateurs de Chromium davantage de temps pour valider les changements avant d’adopter un nouveau jalon.

Ce calendrier scindé révèle le compromis pragmatique de Google. La plupart des utilisateurs de Chrome reçoivent les changements de plateforme deux fois plus souvent, tandis que les organisations disposant de processus de test et d’approbation plus lents peuvent conserver une fenêtre de planification plus longue.

La version immédiate était exceptionnellement importante pour une autre raison. L’avis de Google concernant le canal stable indiquait que Chrome 153 incluait 230 correctifs de sécurité. Le registre des versions de Chrome répertoriait des problèmes affectant notamment WebGL, PDFium, DevTools et le moteur JavaScript V8.

Ce chiffre ne signifie pas que chaque utilisateur était confronté à 230 attaques activement exploitées. Les versions de sécurité regroupent souvent des bugs découverts en interne, des vulnérabilités signalées de l’extérieur, des renforcements de sécurité et des problèmes de gravité variable.

Son ampleur illustre néanmoins la charge de travail qu’implique un navigateur moderne. Chrome analyse des pages non fiables, exécute du JavaScript, affiche des graphiques, charge des extensions, gère des sessions d’authentification et se connecte à des applications d’entreprise. Chaque capacité apporte des fonctions utiles et une surface supplémentaire à examiner en continu.

Le calendrier de deux semaines réduit la taille de chaque jalon en y intégrant moins de changements accumulés à la fois. Google estime que des versions plus petites devraient limiter les perturbations et simplifier le débogage après le déploiement.

Cette affirmation est plausible, mais la première version ne la prouve pas. Chrome 153 lance l’expérience à grande échelle. Des éléments plus solides viendront de plusieurs cycles consécutifs, en particulier lorsqu’un jalon contiendra une régression ou un correctif de sécurité urgent.

L’IA augmente à la fois la vitesse de développement et la charge de sécurité

L’IA réduit le temps nécessaire pour produire du code et découvrir des défauts, obligeant les équipes de navigateurs à traiter davantage de changements sans abaisser leurs exigences de revue.

Google a reconnu une hausse des signalements de sécurité au cours des récents cycles de développement de Chrome. Dans ses notes pour Chrome 150, l’entreprise a indiqué que de nombreux problèmes signalés avaient été découverts avec l’aide de l’IA.

La recherche de vulnérabilités fondée sur l’IA peut examiner de vastes bases de code, identifier des schémas suspects, générer des cas de test et guider le fuzzing. Le fuzzing injecte dans un logiciel de nombreuses entrées automatisées ou malformées afin de révéler des plantages et des comportements inattendus.

Ces systèmes peuvent améliorer la recherche défensive sans remplacer l’examen d’experts. Une découverte générée par un modèle doit toujours être reproduite, évaluée en termes de gravité, analysée pour déterminer sa cause première, corrigée, testée et divulguée de manière coordonnée.

La même automatisation peut aussi aider les attaquants. Lorsqu’un correctif de sécurité devient visible dans le code source public de Chromium, les chercheurs peuvent comparer le code modifié à la version vulnérable. Cette comparaison peut révéler la faiblesse avant que chaque utilisateur n’ait installé la mise à jour.

Cela crée une fenêtre de risque N-day. Une vulnérabilité N-day est déjà connue ou corrigée, à la différence d’une zero-day que les défenseurs n’ont pas encore traitée. Les attaquants peuvent étudier le correctif divulgué tandis que les appareils non mis à jour restent exposés.

Un cycle majeur plus rapide peut réduire certaines formes de retard, notamment lorsqu’un correctif est prêt mais lié à un jalon programmé. Il permet également à des groupes plus importants de changements liés d’avancer dans les tests par lots plus petits.

Cependant, les mises à jour de sécurité hebdomadaires existantes de Chrome traitent déjà de nombreuses vulnérabilités urgentes. Le calendrier de jalons bimensuels doit donc être compris comme une couche du système de sécurité, et non comme un remplacement des correctifs d’urgence.

Le volet développement de l’équation de l’IA est tout aussi important. Google ajoute des fonctionnalités Gemini, des interfaces d’agents, des API d’IA intégrées et des outils de développement assistés par IA dans Chrome.

Lors de Google I/O 2026, l’équipe Chrome a décrit un « web agentique » dans lequel des agents logiciels interagissent avec des sites web et accomplissent des tâches pour les utilisateurs. Sa feuille de route Chrome AI publiée incluait WebMCP, des outils de développement centrés sur les agents, l’automatisation du navigateur et des capacités d’IA sur l’appareil.

Ces fonctionnalités introduisent davantage de code et d’interactions sensibles. Un agent peut agir au sein d’une session de navigateur authentifiée, où les e-mails, documents, achats, calendriers et applications professionnelles sont peut-être déjà accessibles.

L’injection de prompt ajoute un autre risque. Une page malveillante peut placer des instructions dans un contenu qu’un agent IA lit, en tentant de détourner l’agent de l’intention de l’utilisateur. Les frontières traditionnelles des navigateurs n’ont pas été conçues pour des logiciels interprétant le texte des pages web comme de potentielles commandes.

Les propres directives de sécurité de Chrome pour WebMCP identifient les définitions d’outils malveillantes et les sorties d’outils contaminées comme des vecteurs d’attaque pertinents. Les défenses comprennent des limites d’autorisation, une autorisation claire de l’utilisateur, des capacités restreintes et un traitement prudent des contenus non fiables.

La vitesse de publication aide Google à faire évoluer ces protections, mais elle ne peut pas résoudre les questions de conception sous-jacentes. Une livraison plus rapide du code n’améliore la sécurité que si les correctifs sont fiables, si les tests détectent les régressions et si les nouvelles capacités sont publiées avec des autorisations limitées.

C’est le renversement central de cet article. L’IA n’est pas simplement une autre catégorie de fonctionnalités en attente d’intégration dans Chrome. Elle transforme la vitesse à laquelle le code des navigateurs est créé, les failles sont découvertes et ces failles peuvent être exploitées.

Les mises à jour plus rapides de Chrome mettent les développeurs et les équipes IT sous pression

Google raccourcit son cycle de livraison, ce qui signifie que les développeurs de sites web et les administrateurs doivent raccourcir leurs propres cycles de validation ou accepter une dérive de versions plus importante.

Pour les développeurs web, un jalon stable toutes les deux semaines laisse moins de temps entre les changements significatifs de plateforme. De nouvelles API, des comportements CSS, des dépréciations, des règles d’autorisation et des ajustements de rendu peuvent atteindre les utilisateurs plus rapidement.

La réponse pratique consiste à tester plus tôt. Google recommande aux développeurs d’exécuter leurs applications avec Chrome Beta, qui arrive trois semaines avant la version stable associée. Cet aperçu devient plus important lorsque les jalons stables arrivent deux fois plus souvent.

Les tests automatisés de navigateur peuvent absorber une partie de la charge. Les équipes peuvent exécuter des flux de travail critiques sur des versions bêta, comparer des captures d’écran, surveiller les avertissements de la console et détecter les défaillances d’authentification ou de paiement avant qu’une version n’atteigne la plupart des utilisateurs.

L’automatisation couvre toutefois rarement tous les environnements clients. Les applications d’entreprise dépendent souvent d’extensions de navigateur, de fournisseurs d’identité, de contrôles des terminaux, d’interfaces héritées et de logiciels de sécurité internes. Un changement qui fonctionne sur un système de test propre peut tout de même échouer dans un parc administré.

Des versions plus petites devraient faciliter l’isolation des défaillances. Lorsque moins de fonctionnalités entrent dans un jalon, les équipes disposent d’un ensemble de changements plus restreint à examiner après une régression.

La fréquence crée néanmoins son propre coût. Les notes de version doivent être examinées plus souvent, les tests de compatibilité exécutés plus souvent et les équipes de support préparées à davantage de transitions de versions. Les organisations qui exigent une approbation formelle peuvent trouver le calendrier plus difficile à gérer, même si chaque mise à jour est plus petite.

Extended Stable offre une soupape de sécurité. Son cycle de huit semaines permet aux organisations prudentes de consolider leurs tests tout en continuant de recevoir des correctifs de sécurité importants. Ce choix n’élimine pas le travail opérationnel, mais il évite que chaque entreprise soit contrainte d’adopter le rythme grand public.

Il existe également un problème de distribution qui échappe au contrôle direct de Google. Certains utilisateurs laissent Chrome ouvert pendant de longues périodes sans le redémarrer. D’autres dépendent de paquets de système d’exploitation, de boutiques d’applications mobiles ou d’administrateurs qui retardent le déploiement.

Un correctif disponible auprès de Google n’est pas la même chose qu’un correctif actif sur chaque terminal. Le bénéfice de sécurité dépend du délai entre la publication, le téléchargement, l’installation et le redémarrage du navigateur.

Les navigateurs basés sur Chromium ajoutent une couche supplémentaire. Microsoft Edge, Brave, Opera et d’autres produits reposent sur le projet Chromium, mais chaque éditeur intègre les changements dans son propre produit et son propre processus de publication.

Le rythme amont plus rapide de Chrome peut fournir plus tôt des correctifs à ces équipes. Il peut aussi accroître la pression d’intégration, car les éditeurs en aval doivent continuellement fusionner, tester et distribuer un flux de jalons plus rapide.

Les distributions Linux font face à des contraintes similaires lorsqu’elles empaquettent Chromium de manière indépendante. Une distribution qui prend du retard ne manque pas seulement des fonctionnalités visibles. Elle peut accumuler une exposition aux risques de sécurité sur plusieurs versions amont.

Pour les développeurs, la réponse la plus claire n’est pas de suivre chaque fonctionnalité de Chrome. Elle consiste à identifier les flux de navigateur essentiels à l’activité et à les tester continuellement avec les versions à venir.

Pour les équipes IT, la décision essentielle consiste à déterminer quels utilisateurs ont besoin de Stable et lesquels nécessitent Extended Stable. Les environnements de navigation à haut risque peuvent privilégier l’adoption rapide des correctifs, tandis que les systèmes étroitement contrôlés peuvent nécessiter des validations plus longues.

Le navigateur est devenu un environnement d’exécution d’entreprise, et non plus seulement un lecteur de documents. Ce nouveau rythme impose aux organisations de le gérer avec la même rigueur que les systèmes d’exploitation et les autres infrastructures fréquemment mises à jour.

La concurrence entre navigateurs devient une course pour déployer l’IA en toute sécurité

Le changement de calendrier de Chrome accélère également la concurrence, alors que les navigateurs se repositionnent autour des assistants, des agents, de la recherche et des tâches automatisées.

Chrome demeure de très loin le leader du marché. Statcounter a mesuré sa part mondiale du marché des navigateurs à 69,39 % en août 2026, selon ses données sur le marché des navigateurs.

Cette portée confère à Google une influence considérable sur le développement web. Lorsque Chrome déploie une capacité de plateforme, les développeurs ont de solides raisons de l’évaluer. Lorsque Chrome modifie une règle de sécurité, les sites web et les navigateurs basés sur Chromium doivent souvent réagir.

Le leadership du marché n’élimine pas la pression concurrentielle. Comet de Perplexity, Dia de The Browser Company, Opera Neon, Brave, Microsoft Edge et le navigateur de DuckDuckGo représentent différentes tentatives de réinventer la navigation autour de l’IA ou de la confidentialité.

Leurs approches divergent. Certains placent la recherche conversationnelle au centre de l’expérience. D’autres se concentrent sur des agents capables d’accomplir des tâches en plusieurs étapes, de résumer des onglets ou de travailler entre différents services. Les navigateurs établis intègrent également des assistants dans leurs interfaces existantes.

Un cycle de publication de deux semaines aide Google à répondre avec moins de délai calendaire. L’entreprise peut faire progresser plus rapidement les expérimentations via la bêta, ajuster les fonctionnalités selon les retours et éviter de retenir un travail achevé jusqu’au prochain jalon de quatre semaines.

Chrome présente toutefois un profil de risque différent de celui d’un concurrent plus modeste. Un défaut dans un navigateur à diffusion limitée peut toucher un public relativement restreint. Une régression dans Chrome peut perturber des sites web, des entreprises et des utilisateurs sur presque tous les marchés.

La même asymétrie s’applique aux fonctionnalités d’IA. Un agent expérimental dans un nouveau navigateur peut attirer des adopteurs précoces disposés à accepter certaines imperfections. Chrome sert des utilisateurs qui ne choisiraient peut-être jamais consciemment un flux de travail IA, mais qui y sont confrontés à la suite d’une mise à jour du navigateur.

Google doit donc rivaliser sur la vitesse sans traiter sa base installée comme un public de test. Les indicateurs, les déploiements progressifs, les tests bêta, les contrôles côté serveur et la disponibilité graduelle des fonctionnalités restent essentiels.

La concurrence s’étend également aux standards web. Des fonctionnalités telles que WebMCP visent à fournir aux agents des moyens structurés d’interagir avec les sites web. Un outil structuré peut être plus fiable que de demander à un agent de déduire chaque action à partir des éléments visuels d’une page.

Toutefois, une proposition pilotée par Chrome ne devient pas automatiquement un standard largement accepté. Les autres fournisseurs de navigateurs, les développeurs, les chercheurs en sécurité et les groupes de normalisation doivent évaluer l’interopérabilité et la sécurité.

Un calendrier de publication plus rapide peut accélérer l’expérimentation, mais les standards exigent toujours de la réflexion. Chrome doit éviter de transformer sa vitesse de livraison en contrôle unilatéral du fonctionnement des interactions web agentiques.

Le meilleur résultat combinerait une mise en œuvre rapide, un examen ouvert et un accord entre navigateurs. Le pire fragmenterait le web en interfaces d’agents propres à chaque navigateur, que les développeurs devraient prendre en charge séparément.

Pour les utilisateurs, la question concurrentielle n’est pas de savoir quel navigateur ajoute le plus de boutons d’IA. Il s’agit de savoir quel navigateur peut fournir une automatisation utile tout en préservant le consentement, un comportement prévisible et les limites de sécurité.

Le calendrier de Chrome offre à Google davantage d’occasions de répondre à cette question. Il crée également des moments plus fréquents où une décision précipitée peut atteindre une audience immense.

Un calendrier plus rapide ne comble pas à lui seul l’écart de correctifs

Le nouveau rythme raccourcit une étape de la livraison, mais la fenêtre de sécurité complète inclut toujours la divulgation, les tests, le déploiement, le comportement de redémarrage et l’adoption en aval.

L’argument de Google repose en partie sur la réduction de l’écart de correctifs. Dès qu’un correctif apparaît dans le code public de Chromium, des attaquants peuvent analyser le changement et tenter de reconstituer la vulnérabilité.

Intégrer plus rapidement les correctifs dans une version stable peut réduire cette opportunité. Des jalons plus petits peuvent également rendre les décisions de test et de retour en arrière plus faciles à gérer.

Néanmoins, les publications de sécurité hebdomadaires du navigateur demeurent le mécanisme le plus direct pour les défauts urgents. Une vulnérabilité critique activement exploitée ne devrait pas attendre un jalon de deux semaines.

Les deux calendriers fonctionneront désormais ensemble. Les mises à jour de sécurité peuvent corriger la version stable actuelle, tandis que les versions majeures fournissent toutes les deux semaines un ensemble plus large de correctifs et de capacités.

Ce modèle à plusieurs niveaux est logique, mais il complique les affirmations sur les résultats. Une baisse de l’exposition peut provenir de jalons plus rapides, de correctifs hebdomadaires, d’une meilleure détection, d’un code plus sûr, de redémarrages plus rapides ou d’un meilleur déploiement en entreprise.

Google devra fournir des données opérationnelles pour montrer quelles composantes fonctionnent. Parmi les mesures utiles figureraient le délai moyen de déploiement des correctifs, l’achèvement des redémarrages, la fréquence des régressions, les taux de retour en arrière et l’ancienneté des installations vulnérables.

Le volume de vulnérabilités signalées exige également une interprétation prudente. Davantage de découvertes peut indiquer une détérioration de la qualité du code, une meilleure détection, une participation accrue des chercheurs ou plusieurs facteurs à la fois.

La découverte assistée par IA rendra les décomptes bruts de signalements encore moins fiables comme indicateur. Si les modèles aident les chercheurs à inspecter davantage de code, une hausse temporaire des découvertes peut représenter une meilleure couverture défensive.

Les 230 correctifs de sécurité de Chrome 153 illustrent cette ambiguïté. Ce nombre signale un travail de remédiation substantiel. Il ne révèle pas à lui seul combien de failles ont été découvertes par l’IA, combien de temps les utilisateurs ont été exposés ni si les futures versions contiendront moins de défauts.

Des publications plus rapides peuvent aussi introduire des régressions. Un correctif de sécurité peut casser un site web, perturber une extension ou créer un nouveau défaut ailleurs. Des lots plus petits facilitent le diagnostic, mais n’éliminent pas les interactions entre composants.

La capacité de test devient le facteur limitant. Si le code progresse dans le pipeline plus vite que les revues automatisées et humaines ne peuvent l’évaluer, la fréquence des versions peut passer d’un avantage à une source de risque.

Google affirme que de récentes améliorations de processus lui permettent de maintenir la stabilité avec ce nouveau rythme. Cela reste une affirmation de l’entreprise tant que plusieurs cycles de publication n’auront pas fourni de preuves indépendantes.

L’adoption en entreprise présente une autre incertitude. Certains administrateurs peuvent recourir davantage à Extended Stable, car le canal standard évolue trop souvent. Cette réponse préserverait le temps de test, mais réduirait le nombre d’environnements suivant le rythme de fonctionnalités le plus rapide de Google.

Les fournisseurs de Chromium en aval peuvent également adopter des calendriers différents. S’ils ne peuvent pas intégrer rapidement les correctifs en amont, l’écart de correctifs de l’écosystème peut rester plus large que celui de Chrome lui-même.

La distinction cruciale est simple : la disponibilité d’une version mesure la production de Google, tandis que l’adoption des mises à jour mesure la protection des utilisateurs. C’est finalement la seconde métrique qui détermine si la fenêtre de sécurité s’est refermée.

Trois signaux montreront si le pari de Google fonctionne

Les trois prochains cycles de Chrome devraient révéler si des jalons plus rapides améliorent la sécurité et la réactivité sans transférer un risque excessif aux développeurs et aux administrateurs.

Le premier signal sera le bilan de livraison de Chrome 154 et Chrome 155. La sortie stable de Chrome 154 est prévue le 22 septembre, seulement deux semaines après Chrome 153.

Une sortie à l’heure ne suffit pas. Les développeurs devraient surveiller les retours en arrière d’urgence, les déploiements suspendus, les régressions graves ou une concentration inhabituelle de mises à jour correctives après chaque jalon.

Plusieurs publications ordonnées renforceraient l’affirmation de Google selon laquelle des changements plus petits sont plus faciles à tester et à déboguer. Des interruptions répétées ou des défauts perturbateurs affaibliraient l’argument en faveur de l’accélération du canal standard.

Le deuxième signal concernera la gestion de la prochaine vulnérabilité activement exploitée. La chronologie importante commence lorsque Google confirme le problème et se termine lorsque les versions protégées parviennent aux utilisateurs.

Un correctif urgent livré rapidement via le processus de sécurité hebdomadaire montrerait que le rythme de deux semaines complète les défenses existantes. Un retard causé par la coordination des jalons révélerait une faiblesse du nouveau modèle opérationnel.

Les données d’adoption comptent ici. Les organisations devraient suivre la rapidité avec laquelle les terminaux téléchargent et activent les mises à jour du navigateur, et non seulement la date à laquelle Google les publie.

Le troisième signal sera la réponse des navigateurs basés sur Chromium et des clients d’entreprise. Microsoft, Brave, Opera, les responsables des paquets Linux et les équipes gérant des appareils administrés doivent décider dans quelle mesure suivre le rythme plus rapide en amont.

Une adoption large renforcerait le rôle de Chrome comme référence du rythme de l’industrie. Un écart croissant entre les versions de Chromium et les produits en aval montrerait que Google a accéléré plus vite que certaines parties de l’écosystème ne peuvent l’absorber.

Les choix de canaux en entreprise offrent un autre indice. Si de nombreuses organisations passent à Extended Stable, le calendrier standard plus rapide pourrait surtout bénéficier aux consommateurs et aux équipes de développement adoptant rapidement les changements.

Cela ne ferait pas de ce changement un échec. Cela montrerait qu’un même écosystème de navigateurs a besoin de deux vitesses opérationnelles : une livraison rapide pour les logiciels grand public largement diffusés et une validation plus longue pour les environnements étroitement administrés.

Les développeurs n’ont pas besoin d’attendre le verdict de Google. Ils peuvent intégrer Chrome Beta aux tests continus, surveiller les dépréciations et considérer la compatibilité des navigateurs comme une tâche d’ingénierie continue.

Les administrateurs IT peuvent mesurer la latence de redémarrage des navigateurs, identifier les terminaux obsolètes et distinguer les applications qui tolèrent des mises à jour rapides de celles qui exigent Extended Stable.

Les travailleurs du savoir sont également directement concernés. Les navigateurs servent désormais d’intermédiaires pour l’accès aux e-mails, aux documents, aux assistants IA, aux réunions, aux systèmes financiers et aux applications internes. Un modèle de mise à jour plus rapide transforme l’environnement dans lequel se déroule une grande partie de leur travail.

Les équipes qui suivent les changements fréquents de plateforme peuvent conserver les notes de publication, les résultats de test et les décisions liées aux incidents dans une base de connaissances consultable. L’objectif est de relier chaque changement du navigateur aux systèmes affectés et aux correctifs précédents.

Le cycle de publication de Chrome toutes les deux semaines constitue un changement opérationnel significatif, et non une garantie de sécurité. Il accélère l’arrivée des correctifs et des fonctionnalités auprès des utilisateurs de la version stable, tout en exigeant des tests et des déploiements plus rapides de la part de tous les acteurs autour de Chrome.

La prochaine question est mesurable : les versions protégées atteindront-elles plus vite les appareils réels sans augmenter les régressions graves ? Les développeurs et les équipes IT devraient suivre ce résultat au cours des trois prochains jalons, puis choisir leur canal de publication sur la base des preuves.