Google a publié Chrome 153 sur le canal Stable le 8 septembre, pour ordinateur, Android et iOS. C’est la première version livrée selon le cycle de deux semaines annoncé par Google en mars, et ses notes de version, publiées le même jour, montrent à quoi ressemble en pratique un Chrome livré toutes les deux semaines : deux nouveaux éléments HTML pour l’accès à la caméra et au micro, un parseur XML écrit en Rust et sûr en mémoire, quelques ajouts CSS et JavaScript, et une liste de dépréciations qui referme discrètement le chapitre de l’essentiel de la Privacy Sandbox.
Chrome 154 suivra le 22 septembre, selon 9to5Google, qui rapporte aussi la manière dont Google présente ce rythme accéléré : les correctifs atteignent les utilisateurs plus tôt, et une version plus petite facilite l’isolement d’une régression quand l’une d’elles passe entre les mailles.
La caméra et le micro deviennent des éléments HTML
La fonctionnalité phare pour les développeurs est une paire de ce que Google appelle des « capability elements ». L’élément <camera> demande la capture vidéo, l’élément <microphone> la capture audio. Dans son billet « New in Chrome 153 », Rachel Andrew les décrit comme des « declarative, user-activated HTML controls », des contrôles HTML déclaratifs activés par l’utilisateur : le navigateur dessine le bouton, l’utilisateur doit cliquer dessus, et c’est seulement alors qu’une demande d’autorisation apparaît ou qu’un flux démarre.
Ils s’appuient sur l’élément <usermedia> livré avec Chrome 151 en juin. Ce billet antérieur, signé Mari Viana et Minh Le, en expliquait la logique. Un clic sur un bouton contrôlé par le navigateur est « a trusted signal of intent », un signal d’intention fiable, ce qui compte parce que les demandes d’autorisation déclenchées par un script sans action évidente de l’utilisateur sont précisément celles que les navigateurs bloquent ou enterrent de plus en plus. L’élément comporte aussi un chemin de récupération : si un utilisateur a refusé l’accès à la caméra il y a des mois, toucher l’élément déclenche, selon le billet, un flux de récupération spécialisé qui permet de réactiver instantanément la caméra ou le micro sur la page, sans naviguer dans des réglages complexes du navigateur.
Les règles de style sont volontairement strictes pour que le bouton ne puisse pas être déguisé : le billet sur <usermedia> cite un contraste de texte minimal de 3:1, aucune transparence ni marge négative, et des transformations limitées à la translation 2D et à la mise à l’échelle proportionnelle. Les nouveaux éléments à capacité unique conservent, selon les termes du billet de la bêta, le « identical security model, strict styling constraints, and built-in permission recovery path as the <usermedia> MVP », soit le même modèle de sécurité, les mêmes contraintes de style et le même chemin de récupération d’autorisation que le MVP <usermedia>.
Un parseur XML sûr en mémoire
Chrome 153 fait passer l’analyse XML de plusieurs chemins courants à une implémentation en Rust. Les notes de version citent DOMParser, la propriété responseXML de XMLHttpRequest, ainsi que les images SVG autonomes et externes. Les scénarios XSLT ne sont pas concernés par ce changement. L’objectif affiché de Google, d’après le billet de la bêta, est d’éliminer les bugs potentiels de corruption de mémoire tout en maintenant une compatibilité totale avec les spécifications web existantes.
Pour un propriétaire de site, l’enjeu pratique, c’est le SVG. Les logos, icônes et illustrations livrés en fichiers SVG passent désormais par le nouveau parseur. Google affirme que la compatibilité est préservée et qu’il n’y a rien à faire, mais si un élément SVG s’affiche différemment après la mise à jour, c’est ce changement qu’il faut examiner en premier.
Ajouts CSS et JavaScript
Deux changements CSS concernent le défilement. La propriété overflow accepte désormais une valeur défilante combinée à clip : overflow: scroll clip crée un conteneur de défilement sur un axe tandis que l’autre axe reste rogné en place. Les notes de version précisent que position: sticky peut ainsi être contraint par des conteneurs de défilement ancêtres différents selon l’axe. Une nouvelle propriété, scroll-axis-lock, permet au développeur d’indiquer au navigateur de ne pas verrouiller un geste de défilement sur un seul axe lorsque le défilement en diagonale est souhaité.
JavaScript gagne deux propositions TC39. Iterator.prototype.join() concatène la sortie d’un itérateur en une chaîne, à l’image de Array.prototype.join(). Joint Iteration ajoute Iterator.zip() et Iterator.zipKeyed(), qui parcourent plusieurs itérables en parallèle et produisent des tableaux ou des objets à clés ; les modes sont « shortest » par défaut, « longest » avec remplissage optionnel, et « strict », qui lève un TypeError quand les longueurs diffèrent.
Par ailleurs, Chrome 153 décode le conteneur Immersive Audio Model and Formats, un format d’audio spatial ouvert et libre de redevances, via Media Source Extensions ; les connexions WebTransport peuvent transporter des en-têtes HTTP personnalisés ; et l’API Long Animation Frames remonte désormais des données depuis les web workers.
La Privacy Sandbox rejoint la liste des dépréciations
Les notes de Chrome 153 indiquent que la Protected Audience API, la Shared Storage API, l’Attribution Reporting API, les Related Website Sets et document.requestStorageAccessFor sont chacun « planned for deprecation and removal », c’est-à-dire voués à la dépréciation puis à la suppression. La raison avancée pour les Related Website Sets est qu’ils ont été conçus pour un navigateur sans cookies tiers, et que Chrome a décidé de les conserver. Le billet de la bêta du 20 août listait déjà les Related Website Sets et requestStorageAccessFor parmi les suppressions.
Rien de tout cela n’est une surprise. Le 17 octobre 2025, Anthony Chavez, vice-président de Google chargé de la Privacy Sandbox, annonçait que Google retirait dix technologies Privacy Sandbox, dont Topics, Protected Audience, Attribution Reporting, Private Aggregation avec Shared Storage et les Related Website Sets, en invoquant « ecosystem feedback about their expected value and in light of their low levels of adoption », les retours de l’écosystème sur leur valeur attendue et leur faible adoption. Ce billet promettait que les détails suivraient les processus de Chrome et d’Android pour l’abandon progressif de ces technologies. Chrome 153 est le moment où ces processus deviennent visibles dans une note de version.
Ce que cela signifie pour votre entreprise
Si votre site utilise une caméra ou un micro, les nouveaux éléments méritent d’être adoptés tôt. Vérification d’identité, essayage virtuel, parcours « scannez votre document » : chacun de ces flux s’ouvre aujourd’hui par un appel JavaScript et une demande d’autorisation que beaucoup d’utilisateurs rejettent par réflexe. Un bouton dessiné par le navigateur, que l’utilisateur choisit de cliquer, avec un chemin intégré pour récupérer une autorisation refusée auparavant, traite précisément le moment où ces parcours perdent des gens. Chrome est aujourd’hui le seul navigateur à livrer cette fonctionnalité ; elle doit donc relever de l’amélioration progressive : conservez le chemin getUserMedia existant comme solution de repli.
Si votre pile publicitaire ou votre analytique a un jour intégré une API Privacy Sandbox, il est temps de retirer ce code. Les intégrations d’Attribution Reporting, de Protected Audience et de Shared Storage ont surtout été réalisées par des prestataires ad-tech plutôt que par les propriétaires de sites directement, mais des balises et des configurations de consentement qui y font référence existent encore. Demandez à votre prestataire ce qui se passera quand ces API disparaîtront, et assurez-vous que votre mesure des conversions ne dépend pas silencieusement de l’une d’elles. Les cookies tiers restent, ce qui signifie que la configuration de mesure que vous aviez avant la Sandbox est celle qui demeure.
Les Related Website Sets concernaient un groupe précis : les entreprises exploitant plusieurs domaines qui partagent une connexion ou un panier. Si vous avez déclaré un ensemble pour que les cookies circulent entre vos domaines de marque, ce mécanisme est retiré. La Storage Access API elle-même demeure ; seuls le raccourci fondé sur les ensembles et requestStorageAccessFor disparaissent. Vérifiez dès maintenant toute connexion ou tout paiement multi-domaines, plutôt que d’attendre qu’un client le signale.
Rien dans cette version ne devrait casser un site marketing ordinaire. Le changement XML et SVG est censé être invisible, les ajouts CSS sont optionnels et les méthodes JavaScript sont nouvelles, pas modifiées. L’habitude que nous recommandons, et que nous intégrons à chaque site web que nous maintenons, est la même que la semaine dernière : un profil de navigateur sur le canal Beta, et un passage en revue de vos formulaires, de votre tunnel de paiement et de tout parcours caméra une fois toutes les deux semaines. Chrome 154 Beta est déjà disponible ; il passera en Stable le 22 septembre.
Notre lecture : Chrome 153 est une version modeste porteuse d’un signal important. Les fonctionnalités sont incrémentales, mais la liste des dépréciations confirme que le navigateur a cessé de vouloir remplacer les cookies tiers par ses propres API publicitaires. Pour une entreprise, cela supprime une variable qui pesait sur les plans d’analytique web et de publicité depuis six ans. Misez sur les cookies, le consentement et les données first-party, et traitez tout ce qui porte l’étiquette Privacy Sandbox comme une technologie héritée.
