Safari peut mesurer les promotions de Chrome dans certaines pages de Google

Le 6 octobre, du code découvert dans la bêta 2 d’iOS 27.2 a révélé que Safari pouvait mesurer certaines promotions de Chrome et de l’application Google.

Ces outils de télémétrie interviennent directement dans des pages consultées avec Safari. Ils ne se limitent donc pas à compter des ouvertures de liens à l’extérieur du navigateur. Leur rôle apparent consiste à reconnaître des éléments promotionnels précis sur certaines pages de Google, puis à relever la manière dont l’utilisateur réagit lorsqu’ils s’affichent.

La découverte apporte ainsi un aperçu technique d’un mécanisme encore expérimental. Elle permet de distinguer les événements que le navigateur paraît capable d’observer. En revanche, elle ne renseigne ni sur la destination des données enregistrées ni sur leur éventuelle utilisation par Apple.

Un script injecté dans certaines pages de Google

Le mécanisme repose sur l’injection d’un script JavaScript par Safari. Son champ d’intervention comprend certaines pages d’accueil de Google ainsi que des pages de résultats de recherche, selon les descriptions concordantes publiées par Next et iPhoneAddict.

Le script analyse les éléments visibles de ces pages pour rechercher des bannières ou d’autres composants incitant à ouvrir Chrome ou l’application Google. La télémétrie se concentre donc sur des sollicitations liées aux applications de Google rencontrées au cours d’une navigation dans Safari. Le code découvert ne décrit pas un dispositif chargé d’examiner indistinctement toutes les publicités du Web.

Cette distinction délimite la portée du test. Safari paraît chercher des formes déterminées de promotion sur un ensemble circonscrit de pages, plutôt que mesurer toute exposition de l’utilisateur à la marque Chrome. Une sollicitation présentée dans une autre application, sur un autre site ou par un autre canal ne relève pas du périmètre décrit.

L’injection du script donne au navigateur la possibilité d’examiner la page au moment où elle est rendue. Il peut alors détecter la présence d’un composant promotionnel et associer cette apparition à certains événements observables pendant la consultation. Il ne s’agit pas seulement d’identifier un lien vers une autre application, mais de reconnaître une incitation affichée dans la page et la réaction immédiate qu’elle suscite.

Ce mécanisme offre aussi un exemple concret de la différence entre affichage et interaction dans la conception des applications mobiles. La présence d’une bannière constitue un premier événement mesurable. Une action sur cette bannière en constitue un autre, sans suffire à décrire tout ce que l’utilisateur fera ensuite.

Les événements que Safari paraît pouvoir relever

Le mécanisme ne relève pas uniquement l’existence d’une bannière dans le code de la page. Il semble pouvoir enregistrer plusieurs informations au cours de son affichage et de la réaction qui suit :

• l’apparition effective de la promotion dans la page consultée avec Safari ;
• une éventuelle interaction de l’utilisateur avec l’élément détecté ;
• le fait que l’utilisateur semble connecté à un compte Google ;
• l’acceptation ou, au contraire, l’ignorance de la sollicitation.

Ces signaux répondent à des questions différentes. Le premier concerne l’exposition réelle à la promotion, et non sa seule présence théorique dans une page. Le deuxième indique une action sur le composant détecté. La connexion apparente à Google apporte un élément de contexte supplémentaire. Enfin, la distinction entre acceptation et absence de réponse permet de qualifier l’issue observable de la sollicitation.

Cette succession d’événements pourrait permettre de séparer plusieurs situations qui sembleraient autrement identiques. Une promotion peut avoir été détectée sans interaction. Elle peut aussi avoir entraîné une action de l’utilisateur, puis avoir été acceptée ou ignorée. Le code donne ainsi une lecture plus fine qu’un simple comptage de liens présents dans les pages analysées.

Il faut toutefois éviter de confondre ces événements techniques avec une interprétation complète du comportement. Ignorer une bannière indique qu’aucune acceptation n’a été relevée dans la situation observée. Cela n’établit pas la raison de cette absence d’action. L’utilisateur peut avoir vu la promotion sans vouloir y répondre, comme il peut ne pas lui avoir accordé d’attention. Le signal ne permet pas de trancher entre ces explications.

De même, une interaction ne suffit pas, à elle seule, à documenter toutes les étapes qui pourraient suivre dans Chrome ou dans l’application Google. Les informations décrites dessinent un suivi de la promotion depuis son affichage jusqu’à la première réaction mesurable dans Safari. Elles ne permettent pas d’affirmer que le système reconstitue l’ensemble du parcours ultérieur de l’utilisateur.

Le mécanisme mesure donc des événements observables, pas les motivations de la personne. Cette limite compte lorsqu’il s’agit d’interpréter une acceptation, une interaction ou une absence de réaction. Le code repéré renseigne sur ce que Safari paraît pouvoir enregistrer, mais il ne transforme pas ces signaux en explication exhaustive du choix effectué.

Le code d’une bêta ne vaut pas annonce de lancement

La présence du mécanisme dans une version bêta ne garantit pas son intégration à la version publique d’iOS 27.2. Un composant repéré pendant cette phase peut être modifié, désactivé ou retiré avant la diffusion finale du système. La découverte décrit donc un état du logiciel en cours de test, et non une fonction promise aux utilisateurs.

Apple n’a par ailleurs ni officialisé cette fonction ni publié de documentation à son sujet. Il n’existe pas d’annonce précisant son calendrier, son activation, les appareils concernés ou les conditions dans lesquelles elle pourrait fonctionner après la bêta. Le code permet d’en décrire les capacités apparentes, mais pas de transformer l’expérimentation en engagement de déploiement.

Cette limite vaut également pour la finalité du dispositif. La télémétrie montre qu’une mesure technique de certaines promotions de Google est possible dans Safari. Elle ne permet pas d’établir l’objectif poursuivi par Apple. Elle ne dit pas davantage comment les données seraient conservées, exploitées ou présentées si le mécanisme était maintenu.

L’absence de documentation publique empêche aussi de connaître les réglages éventuels associés à cette fonction. Rien dans les informations décrites ne précise si elle serait active par défaut, limitée à certaines configurations ou liée à une phase de test particulière. Ces questions ne peuvent pas être résolues par la seule présence du code dans la bêta.

Le constat reste ainsi précisément délimité : la bêta 2 d’iOS 27.2 contient des outils capables d’analyser certaines pages de Google dans Safari, d’y repérer des incitations à utiliser Chrome ou l’application Google, puis d’enregistrer quelques événements liés à leur affichage. Le mécanisme peut différencier l’exposition, l’interaction et l’issue immédiate de la sollicitation, mais son maintien dans la version finale n’est pas confirmé.

Photo à la une. Source : Pexels. Photographe : cottonbro studio. Licence Pexels.