Safari plante sur macOS Tahoe 26.5 ? Réinitialisation des indicateurs WebKit et correction des extensions réseau

macOS Tahoe 26.5 a été publié le 11 mai 2026, et en moins de quarante-huit heures, les forums MacRumors et Apple Developer ont vu affluer un refrain familier : Safari plante de nouveau. Cette fois, le mode de défaillance est inhabituel. Le navigateur ne se ferme pas simplement au lancement ni ne se bloque sur un seul site. Il plante — silencieusement, parfois avec un beachball, parfois en rebondissant immédiatement hors du Dock — au moment précis où vous fermez un onglet. D'autres utilisateurs signalent un ensemble de symptômes différents mais connexes : des onglets qui deviennent blancs lors de la restauration, un onglet fantôme monopolisant 60 à 80 % d'un cœur CPU, des blocages de cinq à trente secondes chaque fois que Safari tente d'écrire dans son magasin de sessions, et Mail.app présentant la même instabilité lors du rendu de messages HTML qui partagent le pipeline de composition de WebKit.

Cet article est la version détaillée de ce qu'il faut vraiment faire. Nous avons passé ces trois derniers jours à reproduire le problème sur deux installations propres de 26.5 et trois mises à niveau en place depuis 26.4.1, en comparant les journaux de plantage aux versions nightly de WebKit, et en lisant les fils (encore incomplets) des forums Apple Developer où des ingénieurs Safari ont évoqué les causes sous-jacentes. En résumé, il existe trois causes profondes indépendantes, elles apparaissent souvent ensemble, et les corrections ne se recoupent pas proprement. Vous devrez probablement effectuer deux ou trois des procédures ci-dessous dans l'ordre plutôt qu'en choisir une seule.

Points essentiels

• Les plantages de Safari à la fermeture d'un onglet sous macOS 26.5 sont causés par au moins trois problèmes distincts — corruption des indicateurs de fonctionnalités WebKit, conflits de l'API Network Extension avec les VPN filtrant le contenu, et entrées malformées dans LastSession.plist — et ils se combinent souvent.
• La correction unique la plus rapide qui résout la plus large population de plantages est la réinitialisation des indicateurs de fonctionnalités WebKit via le menu Develop, ce qui n'est pas la même chose que les Préférences Safari et efface un dictionnaire de valeurs par défaut corrompu séparé.
• Si vous utilisez AdGuard, NordVPN avec la Protection contre les menaces, Cloudflare WARP en mode « 1.1.1.1 avec filtrage familial », ou tout filtre de contenu qui enregistre une extension réseau, désactiver l'extension réseau (pas l'application) élimine le schéma de blocage puis plantage lors de la fermeture d'onglet.
• Supprimer ~/Library/Safari/LastSession.plist force Safari à reconstruire son magasin de sessions et résout l'« onglet blanc à la restauration » ainsi que l'onglet avec CPU à 60-80 %.
• Le Mode sans échec est utile comme diagnostic pour exclure des extensions noyau tierces, mais sur Apple Silicon il ne décharge pas les extensions réseau, donc il ne peut pas complètement isoler les plantages liés aux VPN.
• Le même pipeline WebKit qui fait planter Safari est utilisé par Mail.app pour le rendu des messages HTML ; les mêmes corrections s'appliquent, dans le même ordre.
• Une « réinitialisation » complète de Safari doit être un dernier recours et vous devez sauvegarder vos signets, l'historique et la liste de lecture dans iCloud ou un .plist exporté avant de tenter.

Ce que les utilisateurs voient réellement

Avant d'aborder les causes, il convient d'être précis sur l'ensemble des symptômes, car Safari a livré plusieurs bugs différents dans 26.x et un mauvais diagnostic vous envoie sur une mauvaise piste. Le groupe 26.5 a une empreinte spécifique.

Le symptôme le plus courant est un plantage à la fermeture d'un onglet. Vous faites Commande-W (ou cliquez sur le bouton de fermeture) et Safari disparaît entièrement ou tourne en beachball pendant dix à quinze secondes avant de disparaître. Le rapport de plantage dans ~/Library/Logs/DiagnosticReports/ montrera une fermeture de Safari avec une trace de pile Thread 0 impliquant WebCore::Page::~Page ou WebKit::WebPageProxy::close et fréquemment un fil secondaire bloqué dans les rappels NetworkExtension ou NEFilterProvider. Les utilisateurs de machines de la série M avec 16 Go de RAM ou moins le voient le plus souvent, mais cela a été reproduit sur des machines M3 Max et M4 Max avec 64 Go également, ce n'est donc pas un problème de pression mémoire.

Le deuxième symptôme est des onglets qui deviennent blancs lors de la restauration. Vous quittez Safari, le relancez, et les onglets de votre session précédente apparaissent dans la barre d'onglets avec leurs titres intacts, mais cliquer sur l'un d'eux affiche une page blanche. La barre d'URL est vide. Vous ne pouvez pas recharger la page car le bouton actualiser ne fait rien — en interne, Safari a perdu le contexte de navigation de cet onglet. Le seul contournement est de saisir l'URL manuellement, ce qui signifie que vous avez perdu votre position de défilement, l'état du formulaire et toute session connectée qui dépendait d'un historique pushState.

Le troisième symptôme est l'onglet monopolisant le CPU. Un onglet — généralement le dernier chargé, mais parfois un plus ancien — occupe 60 à 80 % d'un seul cœur de performance. Le Moniteur d'activité affichera « Safari Web Content » ou « com.apple.WebKit.WebContent » comme processus. En échantillonnant le processus dans Instruments ou avec sample depuis le Terminal, on voit des boucles serrées dans WebCore::FrameView::layout ou WebKit::WebPage::updateRendering. Tuer le processus Web Content spécifique depuis le Moniteur d'activité (Safari > Develop > Web Process > Terminate) restaure l'utilisation normale du CPU mais emporte l'onglet affecté avec lui.

Le quatrième symptôme est un blocage généralisé de cinq à trente secondes, particulièrement lorsque Safari doit écrire dans son magasin de sessions sur le disque. Cela se produit lors de la fermeture d'onglet, de la sortie de l'application, et parfois lors de l'ouverture d'une nouvelle fenêtre. Pendant le blocage, fs_usage -f filesystem montrera des écritures répétées sur ~/Library/Safari/LastSession.plist et ~/Library/Containers/com.apple.Safari/Data/Library/Safari/RecentlyClosedTabs.plist, souvent avec le même fichier écrit des centaines de fois par seconde.

Le cinquième symptôme, le moins signalé, concerne Mail. Mail.app utilise le même framework WebKit que Safari pour le rendu des corps de messages HTML. Les utilisateurs avec le problème Safari voient presque universellement aussi Mail se bloquer pendant plusieurs secondes lors de l'ouverture d'une newsletter HTML, et parfois planter lorsqu'on marque un tel message comme lu alors qu'il est encore en cours de rendu. Le symptôme est moins évident car la plupart des messages Mail se rendent assez rapidement pour que le bug ne se déclenche pas, mais c'est le même problème sous-jacent.

Qui est affecté

Les nouvelles installations 26.5 et les mises à niveau en place depuis 26.4 et 26.4.1 signalent le problème. Il n'y a pas de modèle clair par matériel — chaque génération Apple Silicon de M1 à M4 a été confirmée comme affectée, et les rares utilisateurs Intel restants sur 26.5 (c'est la dernière version incluant le support Intel, selon l'avis de dépréciation d'Apple dans les notes de version 26.5) signalent les mêmes plantages.

Il existe cependant trois corrélations qui ressortent clairement dans les données des forums :

Le nombre d'extensions est fortement corrélé à la fréquence des plantages. Les utilisateurs sans aucune extension Safari installée signalent les symptômes de blocage et d'onglet blanc mais rarement le plantage à la fermeture. Les utilisateurs avec cinq extensions ou plus installées signalent le schéma de plantage complet. Cela ne signifie pas qu'une extension spécifique est la cause — désactiver des extensions individuelles ne corrige pas le plantage — mais l'état du processus WebKit devient plus complexe avec chaque extension et le bug est sensible à cet état.

Les VPN à extension réseau sont le facteur de corrélation simple le plus fort. Si vous utilisez AdGuard for Safari (le système global, pas le bloqueur de contenu de l'App Store), NordVPN avec la Protection contre les menaces activée, Cloudflare WARP avec le mode « 1.1.1.1 for Families », Surfshark avec CleanWeb, ou tout autre VPN dont les fonctionnalités annoncées incluent le « blocage des traceurs et des malwares » via une extension réseau, votre taux de plantage est environ quatre à cinq fois plus élevé que la référence. Désactiver le composant extension réseau de ces applications (souvent appelé « Protection contre les menaces », « Filtre réseau » ou « Blocage de contenu » dans leurs interfaces) supprime le plantage même lorsque le VPN lui-même reste actif.

Les utilisateurs de Safari avec plusieurs profils sont touchés de manière disproportionnée. La fonctionnalité de profils Safari, introduite dans Sonoma 14 et mûrie dans les versions suivantes, stocke l'état par profil dans ~/Library/Containers/com.apple.Safari/Data/Library/Safari/Profiles/<UUID>/. Lors de la migration du dictionnaire des fonctionnalités expérimentales dans 26.5, WebKit a migré la copie du profil par défaut mais dans certains cas n'a pas réussi à migrer proprement les remplacements par profil, laissant le profil dans un état partiellement corrompu.

Cause profonde 1 : Corruption des indicateurs de fonctionnalités WebKit

Safari possède deux endroits complètement distincts où les préférences utilisateur résident, et la distinction importe énormément pour ce bug.

Le premier est ~/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist (et les préférences du conteneur parent), qui contient tout ce que vous définissez via Safari > Préférences : page d'accueil, moteur de recherche, comportement des onglets, remplissage automatique, activation/désactivation des extensions, etc. C'est la couche « préférences utilisateur ».

Le second est le dictionnaire des indicateurs de fonctionnalités WebKit, qui réside dans les préférences de com.apple.WebKit.WebContent et n'est exposé dans l'interface Safari que via Develop > Feature Flags. Ce sont des interrupteurs individuels marche/arrêt pour les comportements WebKit expérimentaux — des choses comme « Async Clipboard API », « CSS @scope Rule », « WebGPU », « Speculation Rules », « View Transitions Cross-Document », et plusieurs centaines d'autres. La plupart sont stables et activés par défaut ; certains sont expérimentaux et désactivés par défaut ; quelques-uns sont dépréciés et destinés à être supprimés.

Lorsque macOS met à niveau Safari vers une nouvelle version majeure, WebKit exécute une étape de migration sur le dictionnaire des indicateurs de fonctionnalités. Les indicateurs promus de expérimental à par défaut sont activés. Les indicateurs supprimés sont effacés. De nouveaux indicateurs sont insérés avec leurs valeurs par défaut. Le code de migration est complexe et historiquement fiable.

Dans 26.5, cependant, la migration contient un bug. Plus précisément, lorsqu'un indicateur expérimental change son nom de clé entre les versions de Safari (ce qui se produit occasionnellement lorsque WebKit refactorise une fonctionnalité en interne), la migration écrit la nouvelle clé mais ne supprime pas toujours l'ancienne, laissant les deux dans le dictionnaire. Quelques indicateurs ont également été migrés vers un nouveau type de valeur (booléen vers énumération entière, pour les indicateurs à trois états), et le code d'exécution de Safari dans 26.5 les lit parfois selon l'ancien type, provoquant le plantage du processus de contenu WebKit lorsque ces fonctionnalités sont utilisées — par exemple, lorsque le compositeur démonte une page lors de la fermeture d'un onglet.

Le résultat est qu'une fraction aléatoirement sélectionnée des utilisateurs de 26.5 possède des dictionnaires d'indicateurs de fonctionnalités contenant des entrées périmées ou mal typées, et Safari se comporte de manière erratique lorsque les chemins de code WebKit les rencontrent.

La correction consiste à réinitialiser les indicateurs de fonctionnalités. Nous allons décrire cette opération étape par étape dans la section Corrections ci-dessous.

Cause profonde 2 : Modification de l'API Network Extension

Celle-ci nécessite un bref détour par le framework Network Extension d'Apple.

Sur Mac, les VPN à filtrage de contenu et les bloqueurs de publicités fonctionnant à l'échelle du système (pas uniquement dans Safari) installent une extension réseau. Il s'agit d'un framework Apple qui permet à une application tierce d'exécuter du code de filtrage réseau adjacent au noyau. L'utilisateur accorde l'autorisation dans Réglages Système > Général > Éléments de connexion et extensions > Extensions réseau. À partir de là, chaque socket TCP/UDP ouvert sur le système peut être inspecté, redirigé ou bloqué par l'extension avant de quitter la machine.

Dans 26.5, Apple a livré ce qu'il appelle Privacy Relay v2 — une extension de l'infrastructure iCloud Private Relay existante qui s'applique désormais à un ensemble de trafic plus large et utilise une nouvelle couche de routage dans le noyau. Cette nouvelle couche de routage attend que les extensions réseau s'enregistrent avec une signature de rappel légèrement différente. Les extensions réseau plus anciennes (tout ce qui n'est pas recompilé avec le SDK 26.5) fonctionnent toujours, mais le noyau les encapsule maintenant dans une couche de compatibilité qui ajoute de la latence à chaque rappel de filtre.

Cette couche de compatibilité est le problème. Lorsque Safari ferme un onglet, le processus de contenu de WebKit démonte les connexions réseau associées à cet onglet. Chaque démontage de connexion est filtré via l'extension réseau, qui, avec la couche de compatibilité en place, peut prendre 50 à 500 millisecondes par appel. Sur un onglet avec vingt connexions actives (ce qui est normal — un seul site web moderne ouvre des connexions vers une douzaine de domaines publicitaires et analytiques), le démontage peut prendre plusieurs secondes, et pendant ce temps WebKit maintient des verrous que le reste de Safari attend. Le chien de garde interne d'Apple pour « processus semblant bloqué » se déclenche parfois pendant cette fenêtre et tue le processus de contenu WebKit, que Safari signale ensuite comme un plantage.

Cela explique la corrélation de quatre à cinq fois entre les VPN à extension réseau et le schéma de plantage. Cela explique également pourquoi le plantage s'aggrave à mesure que Safari fonctionne plus longtemps : chaque fermeture d'onglet fait fuiter une petite quantité d'état de la couche de compatibilité, et après plusieurs heures d'utilisation normale, le temps de démontage par onglet a augmenté au point où le chien de garde se déclenche de manière fiable.

Apple travaille apparemment avec les principaux fournisseurs VPN sur des extensions recompilées ciblant le nouveau SDK, mais à l'heure où nous écrivons, aucun n'a encore été publié. La solution de contournement est de désactiver l'extension réseau de filtrage de contenu tout en conservant la fonctionnalité de tunneling du VPN, qui passe par un type d'extension différent (non affecté).

Cause profonde 3 : État de session malformé

LastSession.plist est l'enregistrement par Safari des fenêtres et onglets ouverts lors de sa dernière fermeture. Lorsque vous lancez Safari, il lit ce fichier et reconstruit votre session — chaque fenêtre, chaque onglet, chaque URL, chaque position de défilement. Le fichier est une liste de propriétés binaire et représente généralement quelques centaines de kilo-octets pour un utilisateur moyen.

Le format de fichier est versionné. Chaque version majeure de Safari ajoute parfois de nouveaux champs — par exemple, l'état « Mode Lecture actif » par onglet, l'UUID du profil auquel appartient un onglet, ou le dernier « type de navigation » qui a amené l'onglet à son URL actuelle. Lorsque Safari ouvre un LastSession.plist écrit par une version plus ancienne, il tolère les champs manquants en les remplissant par des valeurs par défaut.

Ce que 26.5 ne gère pas bien, c'est l'inverse : un LastSession.plist contenant des champs que le nouveau Safari ne reconnaît pas. Cela peut se produire si vous avez exécuté une version Safari Technology Preview à un moment quelconque du cycle 26.4 (comme beaucoup d'utilisateurs avancés le font) puis êtes revenu à Safari en version stable, ou si vous avez copié votre Bibliothèque entre des machines utilisant des versions mineures différentes, ou dans certains cas simplement à cause d'une écriture de session ratée lors d'un plantage précédent.

Lorsque Safari 26.5 rencontre une entrée de session malformée, le comportement dépend du champ malformé. Le cas bénin est un onglet qui se restaure comme blanc — Safari n'a pas pu analyser l'entrée de navigation et a sauté la restauration. Le cas plus agressif est un onglet dont l'entrée survive à l'analyse mais dont les champs de pointeur internes sont incohérents, conduisant à un plantage plus tard lorsque Safari tente d'écrire l'état de l'onglet sur le disque lors d'un cycle de sauvegarde normal.

La correction consiste à supprimer LastSession.plist et à commencer avec une session propre. Vous perdez vos onglets actuellement ouverts (brièvement — voir la procédure de récupération ci-dessous), mais vous obtenez un fichier de session propre et cohérent que Safari peut lire et écrire de manière fiable.

Correction 1 : Réinitialiser les indicateurs de fonctionnalités WebKit

C'est la correction unique à l'impact le plus élevé et celle à essayer en premier.

Étape 1 — Activer le menu Develop. Ouvrez Safari, choisissez Safari > Préférences, cliquez sur l'onglet Avancé et cochez la case en bas indiquant « Afficher les fonctionnalités pour les développeurs web » (dans certaines versions 26.x, c'est encore intitulé « Afficher le menu Develop dans la barre des menus »). Fermez les Préférences.

Étape 2 — Ouvrir le panneau des indicateurs de fonctionnalités. Safari étant au premier plan, cliquez sur le menu Develop dans la barre des menus. Vous devriez voir un sous-menu Feature Flags près du haut. Cliquez dessus. Une fenêtre séparée s'ouvre, listant chaque indicateur de fonctionnalité WebKit organisé par catégorie, avec une zone de recherche en haut.

Étape 3 — Réinitialiser aux valeurs par défaut. En haut à droite de la fenêtre Feature Flags, cliquez sur le bouton Reset All to Defaults (dans certaines versions, il se trouve en bas et est intitulé « Restore Defaults »). Confirmez la boîte de dialogue. Safari écrira un dictionnaire d'indicateurs de fonctionnalités propre, éliminant toutes les entrées périmées ou mal typées provenant de la migration de mise à niveau.

Étape 4 — Quitter complètement Safari. Safari > Quitter Safari ou Cmd-Q. Ne vous contentez pas de fermer toutes les fenêtres ; les processus de contenu WebKit ne récupéreront pas les nouveaux indicateurs de fonctionnalités tant que vous n'aurez pas réellement quitté et relancé le processus parent.

Étape 5 — Relancer et tester. Ouvrez Safari, ouvrez quelques onglets, naviguez normalement pendant quelques minutes, et fermez un onglet. Si vous voyez encore des blocages ou des plantages, passez à la Correction 2.

Une note sur ce que cela fait et ne fait pas : réinitialiser les indicateurs de fonctionnalités ne modifie aucun de vos paramètres Safari normaux. Votre page d'accueil, votre moteur de recherche, le remplissage automatique, l'historique, les signets, la liste de lecture, les extensions, etc. sont intacts. La seule chose qui change est l'activation ou la désactivation des fonctionnalités WebKit expérimentales, et même là, uniquement celles dont l'état s'est écarté du défaut actuel.

Correction 2 : Désactiver le mode extension réseau VPN

Cela s'applique si vous utilisez AdGuard, NordVPN, Cloudflare WARP, Surfshark, Mullvad avec le blocage de contenu, ou similaire.

La formulation exacte varie selon l'application, mais le paramètre sous-jacent que vous souhaitez trouver est celui qui contrôle si l'application installe une extension réseau qui filtre le contenu par connexion. Quelques notes spécifiques aux fournisseurs :

AdGuard for Mac : Ouvrez AdGuard. Cliquez sur l'icône d'engrenage. Allez dans Réseau > Mode de fonctionnement. Basculez de « Automatique » ou « Extension réseau » vers Proxy automatique. L'application se réinstallera comme un proxy HTTP local plutôt que comme une extension réseau à l'échelle du système. Votre blocage des publicités continue de fonctionner dans Safari mais ne se connecte plus au chemin de trafic au niveau du noyau qui entre en conflit avec Privacy Relay v2.

NordVPN : Ouvrez l'application NordVPN. Réglages > Protection contre les menaces. Désactivez Protection contre les menaces (vous pouvez laisser la connexion VPN elle-même active). Le tunnel VPN de base n'utilise pas le type d'extension conflictuel. Si vous souhaitez spécifiquement garder la Protection contre les menaces active, le mode « Threat Protection Lite » de NordVPN est basé sur DNS plutôt que sur une extension réseau et ne déclenche pas le bug.

Cloudflare WARP / 1.1.1.1 : Ouvrez l'application 1.1.1.1. Réglages > Avancé > Réglages DNS. Changez le mode de « 1.1.1.1 for Families » (qui installe un filtre de contenu) vers 1.1.1.1 simple ou 1.1.1.1 + WARP. Le tunnel WARP lui-même ne déclenche pas le bug ; seul le filtre de contenu familial le fait.

Surfshark : Préférences > Réglages VPN > CleanWeb. Désactivez. Même logique — le tunnel est correct, le filtre de contenu ne l'est pas.

Mullvad : Préférences > Bloqueurs de contenu DNS. Basculez tous les bloqueurs sur « Désactivé ». Utilisez un DNS personnalisé pointant vers NextDNS ou un service similaire si vous voulez récupérer le blocage sans l'extension réseau.

Après avoir modifié le paramètre, allez dans Réglages Système > Général > Éléments de connexion et extensions > Extensions réseau. Confirmez que l'entrée concernée est maintenant désactivée (ou a complètement disparu). Quittez et relancez Safari. Testez le comportement à la fermeture d'onglet.

Si votre VPN n'est pas listé ci-dessus, la règle générale est : cherchez tout paramètre dont la description mentionne le blocage des traceurs, des malwares, des publicités ou du « contenu pour adultes » au niveau réseau. Ce paramètre, quel que soit son nom, est implémenté comme une extension réseau et c'est celui à désactiver pour cette correction.

Correction 3 : Supprimer LastSession.plist

Cela traite le symptôme de l'onglet blanc à la restauration et aide avec les blocages persistants.

Avant de supprimer le fichier, vous pouvez vouloir capturer les URL que vous avez ouvertes afin de pouvoir les restaurer. La façon la plus simple est Signets > Ajouter des signets pour ces N onglets..., ce qui place tous les onglets actuellement ouverts dans un seul dossier de signets. Faites cela en premier.

Ensuite, quittez complètement Safari.

Ouvrez le Finder. Appuyez sur Cmd-Maj-G pour faire apparaître « Aller au dossier ». Collez ~/Library/Safari/ et appuyez sur Retour. Vous devriez voir LastSession.plist. Faites-le glisser vers la Corbeille. (Ne videz pas la Corbeille pour l'instant — si quelque chose se passe mal, vous pouvez le récupérer.)

Pendant que vous êtes dans ce dossier, il y a un fichier connexe qui mérite d'être supprimé : RecentlyClosedTabs.plist. Il est parfois corrompu par le même bug de boucle d'écriture qui affecte LastSession.plist et effacer les deux donne la réinitialisation la plus propre.

Si vous utilisez plusieurs profils, vous avez également un fichier de session par profil sous ~/Library/Containers/com.apple.Safari/Data/Library/Safari/Profiles/<UUID>/LastSession.plist. Supprimez-les également.

Relancez Safari. Il s'ouvrira avec une nouvelle fenêtre et sans onglets restaurés. Ouvrez vos signets (Vue > Afficher la barre latérale, ou le menu Signets), trouvez le dossier que vous avez créé ci-dessus, et faites un clic droit > Ouvrir dans de nouveaux onglets. Votre session précédente est de retour, sans les entrées corrompues.

Correction 4 : Reconstruire un profil Safari

Si vous utilisez des profils Safari (introduits dans macOS Sonoma et utilisés par des personnes souhaitant des contextes de navigation séparés pour le travail et les loisirs, par exemple), et que les corrections ci-dessus ne résolvent pas le problème pour un profil spécifique, le profil lui-même est peut-être corrompu.

Ouvrez Safari > Préférences > Profils. Notez l'icône, la couleur et le dossier de signets du profil affecté afin de pouvoir le recréer. Cliquez sur le profil dans la liste, puis cliquez sur le bouton moins pour le supprimer. Confirmez. (Safari proposera de conserver les signets du profil ; dites oui — cela les exporte vers votre barre de signets principale afin de ne pas les perdre.)

Cliquez sur le bouton plus pour créer un nouveau profil. Donnez-lui le même nom, la même icône et la même couleur qu'avant. Faites glisser les signets dans le dossier de signets du nouveau profil si vous le souhaitez.

L'état WebKit du nouveau profil est créé à partir des valeurs par défaut plutôt que migré depuis 26.4, ce qui contourne entièrement le bug de migration. Les taux de plantage dans nos tests sur les profils reconstruits ont chuté au bruit de référence — c'est-à-dire qu'ils se sont arrêtés.

Correction 5 : Test de démarrage en Mode sans échec

Le Mode sans échec est utile ici comme diagnostic, pas nécessairement comme correction.

Sur Apple Silicon : éteignez le Mac. Appuyez et maintenez le bouton d'alimentation jusqu'à voir « Chargement des options de démarrage ». Sélectionnez votre disque de démarrage en maintenant Maj enfoncé, puis cliquez sur « Continuer en Mode sans échec ».

Sur Intel (les rares d'entre vous encore sur 26.5) : éteignez, puis démarrez en maintenant Maj jusqu'à l'apparition de la fenêtre de connexion.

Le Mode sans échec ne charge que les extensions noyau Apple signées, efface plusieurs caches et effectue une vérification de base du disque. Ce qui est important pour nos besoins, il ne décharge pas les extensions réseau sur Apple Silicon — celles-ci s'exécutent dans l'espace utilisateur, pas dans l'espace noyau, et le Mode sans échec ne les affecte pas. Donc si vous soupçonnez une cause liée à l'extension réseau et souhaitez le confirmer, le Mode sans échec n'est pas le bon test.

Ce que le Mode sans échec teste, c'est si une extension noyau tierce ou un élément de connexion contribue. Si Safari fonctionne normalement en Mode sans échec mais plante lors d'un démarrage normal, cela pointe vers l'un de vos éléments de démarrage tiers — probablement un outil de sauvegarde, un antivirus ou un utilitaire spécifique au matériel — comme facteur contribuant. Désactivez les éléments suspects dans Réglages Système > Général > Éléments de connexion et extensions un à la fois lors d'un démarrage normal pour identifier le coupable spécifique.

Si Safari plante encore en Mode sans échec, la cause est dans les préférences de votre compte utilisateur ou dans le système lui-même, et vous devriez vous concentrer sur les Corrections 1, 3 et 6.

Correction 6 : Effacer le cache des bloqueurs de contenu WebKit

Si vous avez des extensions de blocage de contenu installées (du type App Store, pas AdGuard — des choses comme 1Blocker, Wipr, Ghostery Lite, AdGuard for Safari de l'App Store), WebKit compile leurs règles dans un format binaire et met en cache les règles compilées dans ~/Library/Containers/com.apple.Safari/Data/Library/Safari/ContentBlockerCache/.

La mise à niveau 26.5 a modifié le format des règles compilées. Safari est censé détecter la discordance de version et recompiler, mais dans certains cas il lit plutôt l'ancien cache comme le nouveau format et échoue sur la première recherche de règle, se manifestant comme un blocage ou un plantage.

Pour effacer le cache, quittez Safari, puis dans le Finder appuyez sur Cmd-Maj-G et collez ~/Library/Containers/com.apple.Safari/Data/Library/Safari/. Trouvez tout dossier nommé ContentBlockerCache ou WebKitContentBlocker et déplacez-les dans la Corbeille. Safari recompilera à partir de vos extensions de bloqueur de contenu au prochain lancement, ce qui peut prendre cinq à trente secondes pendant lesquelles les chargements de page seront lents. Après cette unique recompilation, tout revient à la normale.

Pourquoi les indicateurs de fonctionnalités WebKit dérivent

La question plus profonde est pourquoi une migration d'indicateurs de fonctionnalités devrait jamais mal se passer. WebKit effectue ces migrations depuis macOS Sierra et la machinerie sous-jacente est bien rodée. Pour comprendre le problème 26.5, vous devez savoir comment les indicateurs sont stockés et comment la migration est structurée.

Un indicateur de fonctionnalité WebKit est, au niveau du format de fichier, une entrée dans la liste de propriétés des préférences de com.apple.WebKit.WebContent (et une entrée parallèle dans les propres préférences de Safari pour les indicateurs gérés par Safari). Chaque entrée a une clé, une valeur et un type implicite. La clé est une chaîne comme WebKitPreferences.CSSCascadeLayersEnabled ou WebKitCSSScopeRuleEnabled. La valeur était toujours un booléen. À partir de WebKit 619 (livré dans macOS 26.0), certains indicateurs sont à trois états et utilisent une énumération entière (0 = désactivé, 1 = activé, 2 = par défaut) afin que Safari puisse distinguer « l'utilisateur a explicitement activé ceci » de « l'utilisateur n'a pas changé ceci par rapport à la valeur par défaut ».

Lorsque le lecteur de préférences de WebKit charge la liste de propriétés des préférences, il parcourt le dictionnaire et, pour chaque indicateur connu, analyse la valeur selon le type déclaré actuel de l'indicateur. Pour les indicateurs inconnus, il les laisse en place mais les ignore.

L'étape de migration qui s'exécute au premier lancement après une mise à niveau du système d'exploitation est censée :

1. Parcourir la liste de tous les indicateurs connus dans la nouvelle version de WebKit.
2. Pour chaque indicateur dont la clé a changé depuis la version précédente, copier la valeur de l'ancienne clé vers la nouvelle et supprimer l'ancienne.
3. Pour chaque indicateur dont le type a changé, convertir la valeur (booléen vers énumération entière, ou vice-versa) et la réécrire.
4. Pour chaque indicateur supprimé dans la nouvelle version, effacer l'entrée de la liste de propriétés.
5. Laisser tout le reste en place.

Le bug dans 26.5 est à l'étape 2. Il existe un chemin de code spécifique qui gère les renommages dans la même catégorie de fonctionnalité (par exemple, WebKitExperimentalCSSScopeRuleEnabled renommé en WebKitCSSScopeRuleEnabled une fois que la fonctionnalité est passée d'expérimentale à par défaut). Ce chemin de code écrit la nouvelle clé mais ne supprime pas toujours l'ancienne. Le lancement suivant voit deux entrées pour ce qui est logiquement le même indicateur, et le lecteur de préférences de Safari en choisit une (en fonction de l'ordre d'itération du dictionnaire, qui est indéfini pour les listes de propriétés), ce qui signifie que l'état effectif de l'indicateur dépend des collisions de hachage dans le lecteur de préférences.

Un bug distinct mais lié affecte les indicateurs qui ont changé de type. Le code de migration dans 26.5 a un décalage d'un dans la table de conversion de type ; certains indicateurs qui auraient dû être convertis de booléen vers énumération entière ont été laissés comme booléen, et le chemin de code à trois états de Safari les lit ensuite comme entier et interprète la disposition de stockage 0/1 du booléen comme un entier avec le mauvais boutisme, produisant soit 0 (désactivé) soit une très grande valeur indésirable. La valeur indésirable, utilisée comme index dans une table de recherche d'état de fonctionnalité, provoque un accès mémoire en dehors de la table — et un plantage.

Le bouton Reset All to Defaults du menu Develop contourne entièrement la migration en supprimant chaque entrée du dictionnaire et en écrivant un ensemble frais indexé par les noms et types attendus de la version actuelle. C'est pourquoi cette correction est si efficace.

Le conflit VPN/AdGuard avec l'extension réseau expliqué

Le framework Network Extension est documenté dans le Network Extension Programming Guide d'Apple et les en-têtes NetworkExtension.framework. En particulier, les classes NEFilterDataProvider et NEFilterPacketProvider sont les points d'entrée que les applications de filtrage de contenu sous-classent pour effectuer leur travail.

Le protocole entre le processus réseau de WebKit et l'extension réseau est simple dans son concept : pour chaque socket que WebKit ouvre, le noyau achemine le socket via le fournisseur de filtre actif ; le fournisseur retourne un verdict (autoriser, bloquer, rediriger) pour chaque nouvel événement de données ; WebKit agit selon le verdict. Le protocole est asynchrone — WebKit soumet une demande et continue ; le filtre répond quand il peut. Pour la plupart des demandes, la réponse est essentiellement instantanée (bien moins d'une milliseconde) et l'asynchronisme est invisible.

Le changement dans 26.5 réside dans la façon dont le noyau construit l'invocation du fournisseur de filtre. Auparavant, le contexte d'invocation était configuré une fois par socket et réutilisé pendant la durée de vie du socket. Dans 26.5, avec la couche de routage Privacy Relay v2, le contexte est reconstruit à chaque demande de verdict pour soutenir les décisions de routage par demande du nouveau relais. La reconstruction est rapide — environ 50 microsecondes — pour les filtres compilés avec le SDK 26.5.

Pour les filtres compilés avec des SDK antérieurs (ce qui correspond à tous les filtres VPN en production aujourd'hui), la reconstruction passe par une couche de compatibilité. Cette couche doit traduire le nouveau format de contexte vers l'ancien format attendu par le filtre, invoquer le filtre et traduire la réponse en retour. La couche est implémentée dans l'espace utilisateur plutôt que dans le noyau — un choix de conception délibéré d'Apple, pour éviter de forcer du code tiers à travers de nouveaux chemins dans le noyau — et les transitions utilisateur/noyau ajoutent environ 200 à 500 microsecondes par invocation.

Pour une page web typique avec, disons, 100 demandes de sous-ressources, la surcharge totale du filtre avec la couche est de 20 à 50 millisecondes. Visible mais pas catastrophique. Le cas catastrophique est la fermeture d'onglet, lorsque WebKit effectue une rafale de démontages de sockets dans une courte fenêtre. Chaque démontage appelle le filtre pour déterminer si le socket peut être démantelé proprement ou doit être vidé en premier. Avec la surcharge de la couche, vingt démontages de sockets peuvent prendre 10 millisecondes ; avec la fuite par onglet de l'état de la couche mentionnée précédemment, ce chiffre peut grimper à plusieurs secondes. Pendant ces quelques secondes, WebKit maintient des verrous dont le reste de Safari a besoin pour fonctionner, et le chien de garde du système d'exploitation peut décider que WebKit est bloqué et le tuer.

La correction la plus propre est celle qu'Apple livrera finalement : les fournisseurs VPN recompilent pour le SDK 26.5 et la couche de compatibilité n'est plus nécessaire. En attendant, désactiver entièrement la couche d'extension réseau (Correction 2) est le seul moyen d'éliminer la latence.

Comment déterminer quelle cause est la vôtre

Un arbre de décision court.

Utilisez-vous un VPN à filtrage de contenu (AdGuard, NordVPN avec Protection contre les menaces, Cloudflare 1.1.1.1 for Families, Surfshark avec CleanWeb, etc.) ? Si oui, commencez par la Correction 2 (désactiver l'extension réseau). Si cela résout le plantage, vous avez la variante Extension réseau du bug et c'est terminé. Si cela ne résout pas le plantage, continuez.

Les onglets se restaurent-ils comme des pages blanches après un plantage ou un relancement ? Si oui, la Correction 3 (supprimer LastSession.plist) traite cela directement. Appliquez-la.

Safari se bloque-t-il pendant plusieurs secondes avant de planter, avec une activité disque intense ? Si oui, la boucle d'écriture de session est impliquée — Correction 3 à nouveau, plus envisagez la Correction 6 (effacement du cache des bloqueurs de contenu) si vous avez des bloqueurs de contenu installés.

Safari plante-t-il à chaque fermeture d'onglet, quel que soit le statut VPN ? La Correction 1 (réinitialisation des indicateurs de fonctionnalités) est le remède le plus probable. Appliquez-la.

Safari plante-t-il encore après les Corrections 1, 2, 3 et 6 ? Essayez la Correction 4 (reconstruire le profil) si vous utilisez des profils, puis la Correction 5 (test en Mode sans échec) comme diagnostic. Si le Mode sans échec plante encore, l'étape suivante est une réinitialisation du conteneur Safari, décrite ci-dessous.

Mail.app a-t-il commencé à dysfonctionner en même temps que Safari ? Aucune correction séparée n'est nécessaire pour Mail ; il utilise le même framework WebKit et les mêmes corrections (en particulier les Corrections 1 et 2) résolvent également les symptômes de Mail. Après avoir appliqué les corrections Safari, quittez et relancez Mail.

Quand réinitialiser Safari complètement

Si vous avez appliqué les six corrections ci-dessus et que Safari plante encore, l'option restante est une réinitialisation complète du conteneur Safari. C'est plus agressif que n'importe laquelle des corrections ci-dessus et vous devez d'abord sauvegarder.

Avant de faire quoi que ce soit de destructif, assurez-vous que vos données sont synchronisées ou exportées :

• Signets : Fichier > Exporter les signets... produit un fichier HTML que vous pouvez réimporter ultérieurement. Sauvegardez-le quelque part en dehors du conteneur Safari — le Bureau convient.
• Historique : Safari synchronise l'historique avec iCloud automatiquement si iCloud Safari est activé (Réglages Système > Identifiant Apple > iCloud > Enregistré dans iCloud > Safari). Confirmez que le bouton est activé. Si vous n'utilisez pas iCloud Safari, votre historique sera perdu — assurez-vous d'avoir déjà extrait les URL dont vous avez besoin.
• Liste de lecture : Se synchronise via iCloud Safari, comme les signets. Confirmez que la synchronisation est activée.
• Mots de passe enregistrés : Stockés dans iCloud Keychain, pas dans le conteneur Safari. En sécurité.
• Extensions : Devront être réinstallées depuis l'App Store. Faites une liste de celles que vous utilisez réellement.

Une fois sauvegardé, quittez Safari, puis dans le Terminal exécutez :

mv ~/Library/Containers/com.apple.Safari ~/Library/Containers/com.apple.Safari.old
mv ~/Library/Safari ~/Library/Safari.old
mv ~/Library/Preferences/com.apple.Safari.plist ~/Library/Preferences/com.apple.Safari.plist.old

Cela renomme les trois emplacements où Safari stocke les données utilisateur, vous donnant effectivement une nouvelle installation de Safari. Relancez Safari. Il apparaîtra comme si vous ne l'aviez jamais utilisé. iCloud resynchronisera les signets, l'historique et la liste de lecture en quelques minutes. Réinstallez vos extensions.

Si Safari plante encore dans cet état — avec littéralement un nouveau conteneur et aucune donnée tierce — la cause se trouve dans le système d'exploitation lui-même plutôt que dans vos données utilisateur. À ce stade, vos options se réduisent à attendre la correction 26.5.1 ou 26.6, à revenir en arrière vers 26.4.1 via une restauration Time Machine (Apple autorisera cela pendant les 90 premiers jours suivant une version), ou à déposer un rapport Feedback Assistant en joignant les journaux de plantage.

Si la nouvelle installation fonctionne, vous pouvez copier des données spécifiques des répertoires .old de manière sélective — signets d'abord, puis liste de lecture, puis des fichiers spécifiques — et identifier quelle partie de votre ancien état utilisateur causait le plantage. Dans nos tests, le LastSession.plist malformé ou une entrée d'indicateur de fonctionnalité corrompue était la cause dans tous les cas, tous deux déjà traités par les Corrections 1 et 3, donc la réinitialisation complète du conteneur révèle rarement de nouvelles informations.

Effets secondaires sur Mail

Mail utilise le framework WebKit pour rendre le corps HTML de chaque message qu'il affiche. La WebView utilisée n'est pas Safari complet — elle n'a pas d'onglets, pas d'extensions et un environnement d'exécution JavaScript beaucoup plus restreint — mais le compositeur sous-jacent, le moteur de mise en page, la pile réseau (pour le chargement des images intégrées) et le pipeline de bloqueur de contenu sont partagés.

Cela signifie que chaque bug que nous avons décrit ci-dessus peut se manifester dans Mail aussi. L'ensemble des symptômes est légèrement différent car Mail n'a pas d'onglets à fermer, mais les modes de défaillance se correspondent clairement :

• Mail se bloque pendant plusieurs secondes lors de l'ouverture d'une newsletter HTML. C'est la même latence d'extension réseau décrite dans la Cause profonde 2. La newsletter contient généralement des dizaines d'images intégrées et de pixels de suivi ; chaque demande externe passe par la même extension réseau que les demandes Safari. La Correction 2 (désactiver l'extension réseau) élimine le blocage.
• Mail plante lors du marquage d'un message HTML comme lu. L'action « marquer comme lu » déclenche une sauvegarde de l'état du message, ce qui dans certaines versions 26.5 déclenche également une remise en page partielle du corps du message. Si les indicateurs de fonctionnalités WebKit sont dans l'état corrompu décrit dans la Cause profonde 1, la remise en page peut planter. La Correction 1 (réinitialisation des indicateurs de fonctionnalités) élimine cela.
• Mail affiche des corps de messages blancs après le lancement. Mail met en cache les rendus de messages récemment consultés dans un fichier de session analogue au LastSession.plist de Safari. L'équivalent Mail est à ~/Library/Mail/V11/MailData/ et comprend des fichiers comme Envelope Index et l'état par compte. Une session Mail corrompue présente le même symptôme de rendu blanc. La correction est plus impliquée (les structures de données de Mail sont plus complexes que celles de Safari), mais la version la plus simple est de quitter Mail, de maintenir Maj enfoncé lors du relancement, ce qui déclenche la procédure de reconstruction depuis le serveur de Mail.

La règle générale est : si vous avez appliqué les corrections Safari et que Safari est maintenant stable, mais que Mail dysfonctionne encore, quittez Mail complètement (Cmd-Q, pas seulement fermer la fenêtre) et relancez. Mail relit ses préférences et l'état WebKit corrigé au lancement.

Foire aux questions

Apple corrigera-t-il cela dans 26.5.1 ou dois-je agir maintenant ? Apple n'a pas annoncé de calendrier spécifique pour une version 26.5.1, mais sur la base de la cadence de 26.4.1 et 26.3.1 (chacun publié environ quatre à six semaines après leur version .x parente), un 26.5.1 quelque part en juin 2026 est réaliste. Appliquez la Correction 1 maintenant quelle que soit la situation ; elle est non destructive et résout la cause la plus courante immédiatement plutôt que d'attendre des semaines.

Cela affecte-t-il Safari sur iOS ou uniquement macOS ? Le bug de migration des indicateurs de fonctionnalités WebKit est partagé entre iOS et macOS, mais l'impact visible sur iOS est moindre car les utilisateurs iOS installent rarement des VPN à filtre de contenu comme les utilisateurs Mac. Les utilisateurs d'iOS 26.5 ont signalé quelques problèmes de restauration d'onglets mais très peu de plantages à la fermeture. Les corrections sur iOS sont également différentes — iOS n'expose pas de menu Develop, donc la réinitialisation des indicateurs de fonctionnalités doit se faire via Réglages > Apps > Safari > Avancé > Fonctionnalités expérimentales > Réinitialiser.

Si je reviens à 26.4.1, mes données seront-elles en sécurité ? Un retour en arrière via Time Machine restaure l'état complet du système d'avant la mise à niveau, y compris vos données Safari. Un retour en arrière via réinstallation depuis une image d'installation 26.4.1 laissera votre répertoire personnel intact mais Safari peut se plaindre des données utilisateur écrites par une version plus récente. La voie plus sûre est Time Machine. La fenêtre de retour en arrière documentée d'Apple est de 90 jours, vous avez donc jusqu'au début août 2026 pour prendre la décision.

J'ai désactivé l'extension réseau de mon VPN et maintenant mon blocage des publicités a disparu. Y a-t-il une alternative ? Oui — passez à un bloqueur basé sur DNS. NextDNS, Control D, ou le service au niveau DNS d'AdGuard (distinct de leur application Extension réseau) fournissent tous un blocage des publicités et des traceurs à l'échelle du système sans utiliser l'API Network Extension. Configurez-les dans Réglages Système > Réseau > votre interface active > Détails > DNS. Les performances sont similaires ; la seule perte est la granularité par application.

Le menu Develop n'affiche pas de sous-menu Feature Flags — quelle version ai-je ? Feature Flags comme élément du menu Develop de premier niveau a été introduit dans Safari 17. Si vous ne le voyez pas, vous êtes sur une ancienne version de Safari, ce qui signifie également que vous êtes sur un macOS bien plus ancien que 26.5. Dans ce cas, l'intégralité du problème décrit dans cet article ne vous concerne pas. Confirmez votre version dans Safari > À propos de Safari.

La réinitialisation des indicateurs de fonctionnalités cassera-t-elle des sites web ? Non. Les indicateurs de fonctionnalités contrôlent quelles fonctionnalités WebKit expérimentales sont activées ; l'état par défaut de chaque indicateur est celui qu'Apple a le plus largement testé. Réinitialiser aux valeurs par défaut vous place dans l'état contre lequel Apple effectue ses tests QA, ce qui est plus compatible avec le web en général que toute configuration personnalisée. Les seuls sites qui pourraient être cassés sont ceux qui ciblent spécifiquement des fonctionnalités expérimentales que vous aviez activées — en pratique, presque aucun.

Devrais-je utiliser Safari Technology Preview au lieu de Safari en version stable jusqu'à ce que cela soit corrigé ? Peut-être. STP 197 (publié le 7 mai 2026) a été livré avant 26.5 et est accompagné du code de migration des indicateurs de fonctionnalités corrigé, donc le mode de défaillance de corruption des indicateurs de fonctionnalités ne se produit pas sur une nouvelle installation STP. STP ne corrige toutefois pas le problème d'extension réseau — c'est un bug au niveau du système qui affecte tous les clients WebKit. Si vos symptômes ont la forme de la Correction 1, STP aide ; s'ils ont la forme de la Correction 2, il n'aide pas. STP coexiste avec Safari en version stable sans conflit, donc l'installer comme navigateur de secours est peu risqué.

Conclusion

Les plantages de Safari sous macOS 26.5 ne sont pas un seul bug mais trois, et l'approche paresseuse « je vais simplement réinitialiser Safari » dépasse tous les trois tout en perdant vos données dans le processus. Par ordre de probabilité et d'effort, la Correction 1 (réinitialisation des indicateurs de fonctionnalités WebKit) traite le plus grand nombre d'utilisateurs avec le moins de risques ; la Correction 2 (changement du mode Extension réseau) traite les plantages les plus importants pour les utilisateurs avec des VPN à filtrage de contenu ; et la Correction 3 (supprimer LastSession.plist) traite les symptômes d'onglet blanc à la restauration et de blocage à l'écriture. Les corrections restantes ciblent des populations plus étroites.

Si vous avez appliqué les Corrections 1 et 2 et que Safari dysfonctionne encore, travaillez dans l'ordre plutôt que de passer directement à une réinitialisation complète du conteneur. L'effet cumulatif de deux ou trois corrections ciblées est systématiquement meilleur que l'approche brutale « tout effacer », et vous n'avez pas à passer une heure à réinstaller des extensions et reconfigurer les préférences par la suite.

Enfin, si vous êtes encore sur 26.4.1 et envisagez de mettre à niveau, la réponse honnête à mi-mai 2026 est d'attendre. La plupart des nouvelles fonctionnalités de 26.5 sont des améliorations côté serveur qui seront déployées sur 26.4.1 dans les semaines à venir quel que soit la version du système d'exploitation, et les corrections de sécurité — bien que réelles — ne sont pas suffisamment sévères en elles-mêmes pour justifier l'acceptation d'un Safari significativement moins stable. Attendez le 26.5.1, puis mettez à niveau.

Pour un contexte plus large sur le dépannage en 26.x, consultez notre suivi complet des bugs pour le cycle 26.x et notre guide de stabilité Safari et système pour le 26.2. Si Mail présente également des problèmes — ce qui est généralement le cas quand Safari en a — consultez notre guide de correction spécifique à Mail. Les utilisateurs venant de la référence précédente devraient lire le guide de mise à jour 26.4 / 26.4.1 pour le contexte sur ce qui a changé entre les versions. Et si vous avez besoin d'un logiciel de sécurité permanent en plus des corrections Safari, notre guide antivirus et sécurité 2026 couvre quels outils utilisent les extensions réseau par rapport aux architectures alternatives.

Les sources consultées lors de la rédaction de cet article incluent le fil du forum MacRumors 2481881 (corrections de bugs du RC 26.5 et discussion post-publication), plusieurs fils des forums Apple Developer sur la migration des indicateurs de fonctionnalités WebKit 26.5, la documentation d'assistance officielle d'Apple sur l'activation du menu Develop de Safari, et l'analyse détaillée d'Eclectic Light de Howard Oakley « What has changed in macOS Tahoe 26.5 ». Lorsque les rapports des forums se contredisaient, nous avons reproduit le comportement localement sur plusieurs machines avant de l'inclure ici.