Ce que veut vraiment dire « dernière version de Chrome » : quatre canaux, trois versions, une semaine

Dans la semaine du 14 septembre 2026, le blog officiel des versions de Chrome a annoncé que tout ce qui suit était déployé auprès d’utilisateurs réels :

• 152.0.7977.130 sur Extended Stable, pour Windows et Mac
• 153.0.8010.47/.48 sur Stable pour ordinateur, avec 42 correctifs de sécurité
• 154.0.8037.44/.45 sur Windows, décrite comme faisant « partie de notre déploiement Early Stable auprès d’un petit pourcentage d’utilisateurs »
• 154.0.8037.49 sur Android, « auprès d’un petit pourcentage d’utilisateurs »
• 154.0.8037.41 sur Chrome pour iOS, comme la version stable ordinaire sur cette plateforme

Trois versions majeures, en une semaine, toutes à jour, aucune fausse. N’importe qui parmi ces utilisateurs répondrait à « quel navigateur utilisez-vous ? » par « la dernière version de Chrome », et chacun d’eux dirait la vérité.

C’est pourquoi la mention « Chrome, dernière version » en tête d’un rapport de bug n’est pas une information. Cela vaut dix minutes de compréhension de ce qu’elle cache, car cette réalité explique toute une catégorie de bugs qui touchent certaines personnes et pas d’autres.

Les canaux, tels que Google les définit

Chrome n’a pas de version. Il a des canaux, chacun portant une version majeure différente à tout moment. D’après la documentation de Google destinée aux administrateurs :

• Stable « a été entièrement testé par l’équipe de test de Chrome et doit être utilisé par la plupart de vos utilisateurs ». Il se met à jour « toutes les 2 à 3 semaines pour les versions mineures, et toutes les 4 semaines pour les versions majeures ».
• Les utilisateurs d’Extended Stable « reçoivent les mises à jour de fonctionnalités moins souvent, mais continuent de recevoir les correctifs de sécurité », et le canal est « mis à jour toutes les 8 semaines ». Dans la pratique, il reste une version majeure derrière Stable pendant la majeure partie du cycle, ce qui explique l’écart entre 152 et 153 vu plus haut.
• Beta est « un aperçu de 4 à 6 semaines de ce qui arrive dans la version Stable de Chrome ».
• Dev est « un aperçu de 9 à 12 semaines », et Canary est « une future version de Chrome encore en développement ».

Beta, Dev et Canary sont des choix volontaires, et une personne qui en a choisi un le sait généralement. Stable et Extended Stable sont les deux canaux qui comptent pour les rapports de bug, parce que personne sur l’un ou l’autre n’a rien choisi : Extended Stable est défini par un administrateur, pour toute l’entreprise, souvent des années auparavant, et les personnes qui l’utilisent n’en ont aucune idée.

Les déploiements progressifs, la partie qui surprend tout le monde

Un canal n’est pas non plus une version, car une version ne parvient pas à tout le monde sur le canal en même temps. La documentation pour développeurs de Chrome ne tourne pas autour du pot :

Chrome utilise des déploiements progressifs pour chaque canal, plutôt que de publier une nouvelle version auprès de tous les utilisateurs à la fois en espérant que tout se passe bien. Cela signifie qu’au départ, seul un petit nombre d’utilisateurs de chaque canal de publication reçoit la mise à jour. Cela peut commencer avec seulement 1 à 5 % des utilisateurs, avant de monter progressivement jusqu’à 100 %.

Ainsi, n’importe quel mercredi, deux personnes sous Chrome Stable, sur le même système d’exploitation, dans le même bureau, peuvent se trouver sur des versions majeures différentes, sans que ni l’une ni l’autre n’y soit pour quelque chose. « Early Stable » est le nom donné à cette première tranche : la version 154 citée plus haut est arrivée chez les utilisateurs Windows avant même que la 153 ait fini de se déployer auprès de tout le monde.

La conséquence pratique, c’est un bug qui apparaît chez quelques pour cent de vos utilisateurs et personne d’autre, à partir d’un jour où vous n’avez rien déployé. Depuis vos journaux, cela est indissociable d’un bug que vous auriez causé, et le premier endroit où la plupart des équipes regardent, c’est leur propre dernière mise en production.

Faible

Deux utilisateurs signalent que le sélecteur de date est cassé. Nous n'avons rien déployé hier. Ce doit être une question de données.

Mieux

Deux signalements, tous deux sous Chrome 154.0.8037.44 sur Windows, sorti hier en Early Stable auprès d'un petit pourcentage d'utilisateurs. Tous les autres sont sous 153.0.8010.47 et n'ont aucun problème.

Les versions mobiles ne sont pas du tout le même navigateur

Chrome sur Android, c’est Chrome : Blink, V8, le même moteur que sur ordinateur, avec son propre calendrier de publication (153 le 15 septembre, 154 auprès d’un petit pourcentage le 16).

Chrome sur iOS, non. Les règles de l’App Store d’Apple imposent aux navigateurs d’utiliser le moteur web du système, donc Chrome sur un iPhone, c’est WebKit habillé de l’interface de Chrome. La version citée plus haut, la 154 sur iOS, est une nouvelle version de l’interface autour d’un moteur qui change quand iOS change, pas quand Chrome change. Un bug CSS signalé depuis « Chrome sur mon iPhone » est en réalité un bug Safari, et le reproduire dans Chrome sur ordinateur revient à reproduire un autre navigateur. Nous avons écrit sur ce que cela fait aux rapports de bug quand Safari 27 est sorti.

Extraire la version réelle d’un rapport

Il existe trois façons de procéder, classées par ordre décroissant de chance d’obtenir une réponse.

Demandez chrome://version. Tapée dans la barre d’adresse, elle donne la version complète sur la première ligne, ainsi que le système d’exploitation et la ligne de commande. C’est un simple copier-coller, ça fonctionne sur Android, et c’est sans ambiguïté. C’est la bonne chose à demander à un développeur ou à un client technique.

Lisez le user agent. Quelque chose de votre côté le reçoit déjà à chaque requête, donc il n’y a rien à demander. La limite à connaître, c’est que Chrome a réduit cette chaîne il y a quelques années : les composants mineur, build et patch sont envoyés à zéro, donc ce que vous obtenez, c’est Chrome/153.0.0.0 et non la version qui a réellement été déployée. La version complète reste disponible, mais seulement si vous allez la demander : Sec-CH-UA-Full-Version-List est un indice client à haute entropie, qu’un serveur ne reçoit qu’après l’avoir demandé via un en-tête Accept-CH, ou qu’une page peut lire via navigator.userAgentData.getHighEntropyValues(). Ni la chaîne réduite ni l’indice ne disent quoi que ce soit sur le canal, car Extended Stable 152 et Stable 152 sont la même version par des voies différentes.

Demandez à la personne. Ce qui renvoie « la dernière version », pour toutes les raisons vues plus haut. Ce n’est pas de sa faute : la version se trouve à trois clics dans un menu et ne lui dit rien une fois trouvée.

Ce que ces trois méthodes ont en commun, c’est que les réponses fiables ne viennent pas du fait de demander. Elles viennent de quelque chose sur la page qui lit le navigateur au moment où l’échec s’est produit, ce qui plaide pour que le rapport capture lui-même son environnement plutôt que d’interroger la personne qui l’a déposé. Notre guide du rapport de bug place la version du navigateur dans le modèle pour cette raison, et la lecture honnête de ce choix, c’est que le modèle est une solution de repli pour les cas où rien ne l’a capturée automatiquement.

Ce que cela implique pour les tests

Deux conclusions pratiques se dégagent de ce qui précède, et elles vont à l’encontre des conseils habituels.

Tester « la dernière version de Chrome » revient à tester une version parmi au moins trois en circulation. Si vos clients comptent une entreprise d’une taille quelconque, certains d’entre eux sont sous Extended Stable, une version majeure en retard, et ce pendant huit semaines d’affilée. Une fonctionnalité qui repose sur quelque chose livré dans la version majeure actuelle est cassée pour ces utilisateurs, volontairement, et votre matrice de tests reste au vert. L’article sur les tests multi-navigateurs plaide pour raisonner en moteurs plutôt qu’en navigateurs ; l’axe des versions est le même argument, un cran plus bas.

Un déploiement progressif est un suspect, et il coûte peu de le vérifier. Quand des signalements commencent sans qu’il y ait eu de déploiement de votre côté, avant de repasser en revue vos propres changements, regardez si les utilisateurs concernés partagent un numéro de version que personne d’autre n’a. Le blog des versions de Chrome est public et daté, donc la question « quelque chose a-t-il été déployé auprès d’une partie des utilisateurs le jour où cela a commencé ? » se répond en une minute.

Ce qu’il faut en retenir

« Dernière version » est un mot qui parle d’intention, pas de logiciel. La version réellement exécutée est un fait, elle est connaissable, et c’est ce qui fait la différence entre un rapport sur lequel vous pouvez agir et un rapport qui vous envoie fouiller votre propre historique git pendant tout un après-midi.

Le blog des versions de Chrome est la source de référence, et il vaut la peine de l’avoir dans un lecteur de flux si vous supportez un navigateur pour gagner votre vie : Chrome Releases.