Chrome et Brave ne chargent pas les sites web sur la bêta de macOS 27 ? La solution

Vous avez installé la bêta publique de macOS 27 « Golden Gate », ouvert Chrome, tapé une URL, et… rien. L'onglet tourne. La barre d'état affiche Connexion… et n'avance jamais. Après un moment, vous obtenez une erreur brute — ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED, ou le joyeux Ce site est inaccessible de Brave. Vous essayez un autre site. Même chose. Tous les sites. Puis, presque par réflexe, vous ouvrez Safari — et il charge instantanément, du premier coup, sans hésitation. Internet fonctionne visiblement bien. Votre Wi-Fi fonctionne bien. Pourtant, Chrome qui ne charge pas les sites web sur la bêta de macOS 27 vient de vous gâcher toute l'après-midi, et le phénomène touche aussi Brave, Edge, Arc et Vivaldi.

Si c'est votre cas, respirez un bon coup : votre Mac n'est pas cassé, votre réseau non plus. C'est l'une des aspérités les plus largement signalées de l'actuelle bêta de macOS 27 — un schéma où les navigateurs basés sur Chromium ne parviennent à rien charger, tandis que Safari passe sans encombre. On le retrouve sur les forums de la communauté Brave, dans les fils de discussion d'Apple Discussions et sur les forums bêta de MacRumors, et le fil conducteur est toujours le même : le navigateur WebKit fonctionne, ceux basés sur Chromium non. Cette scission est en réalité le plus gros indice dont nous disposons sur la nature du problème, et c'est pour cette raison que la plupart des correctifs ci-dessous sont rapides, réversibles, et ne vous obligent à rien détruire.

Ce guide fait deux choses. D'abord, il explique — honnêtement, et avec toutes les réserves qu'une bêta impose — pourquoi ce sont les navigateurs autres que Safari qui tombent en panne. Ensuite, il vous propose une échelle de correctifs à gravir dans l'ordre, depuis le bascule de trente secondes qui résout le problème pour beaucoup jusqu'au repli honnête que personne n'aime formuler à voix haute : c'est une bêta, et parfois la bonne décision consiste à s'appuyer sur Safari ou à revenir à la version stable de Tahoe jusqu'à ce qu'Apple publie une nouvelle version. Récupérons vos navigateurs.

Points clés à retenir

• Safari qui fonctionne alors que Chrome, Brave, Edge, Arc et Vivaldi échouent tous est la signature de ce problème de bêta. Cela pointe vers la façon dont l'actuelle bêta de macOS 27 achemine le trafic réseau pour les applications non-WebKit — DNS, extensions réseau, chemin réseau par application — plutôt que vers un navigateur en particulier.
• Ceci est rapporté par les bêta-testeurs, ce n'est pas un bug confirmé par Apple. Les fils de discussion sur Brave Community, Apple Discussions et MacRumors le décrivent ; Apple n'a publié aucune reconnaissance officielle. Le comportement peut changer d'une version bêta à l'autre, donc retestez après chaque mise à jour.
• Les correctifs les plus efficaces sont simples et réversibles : désactivez le DNS sécurisé / DNS-over-HTTPS du navigateur, désactivez toute extension système de filtrage réseau ou de VPN (Little Snitch, LuLu, filtres d'entreprise, certains antivirus), réglez l'IPv6 sur Link-local uniquement, et videz le cache DNS.
• Vérifiez tôt Private Relay et le VPN. iCloud Private Relay et les tunnels VPN à moitié connectés se comportent différemment pour Safari que pour les applications Chromium sous cette bêta, et sont un coupable fréquent.
• Le repli honnête, c'est Safari ou un retour en arrière. Sur une bêta, certains problèmes attendent tout simplement Apple. Si un navigateur Chromium fonctionnel n'est pas négociable pour vous, envisagez de revenir à la version stable de Tahoe plutôt que de vous battre contre la version bêta.

Première étape : êtes-vous vraiment sur la bêta de macOS 27 ?

Avant de modifier le moindre réglage, confirmez que vous êtes bien sur la bêta dont parle cet article — car les correctifs ci-dessous ciblent précisément le comportement de la bêta et peuvent être une perte de temps (voire légèrement contre-productifs) sur la version stable.

Vérifiez votre version exacte

Ouvrez le menu Pomme > À propos de ce Mac et lisez la ligne de version. Cliquez ensuite sur Plus d'infos > Mise à jour de logiciels (ou Réglages Système > Général > Mise à jour de logiciels) pour voir si vous êtes sur une version bêta.

• Si vous lisez macOS 27.0 bêta (ou que la bannière bêta développeur/publique s'affiche), vous êtes au bon endroit. La bêta publique est arrivée mi-juillet 2026 — Bêta publique 1 le 13 juillet, Bêta publique 2 le 22 juillet — et la dernière version développeur au moment de la rédaction est la bêta 4, build 26A5388g (20 juillet). Apple n'a pas publié de numéros de build fixes pour les versions publiques, donc ne vous focalisez pas sur un numéro précis ; « la bêta publique de macOS 27 » est la façon la plus honnête de le décrire.
• Si vous lisez macOS 26.5.2 (build 25F84) ou similaire, vous êtes sur Tahoe stable, pas sur la bêta. Dans ce cas, une panne totale de Chromium n'est pas le schéma bêta connu, et vous devriez le traiter comme un problème réseau ordinaire — commencez par notre guide complet de résolution des déconnexions Wi-Fi et notre guide de dépannage VPN plutôt que par les étapes spécifiques à la bêta ci-dessous.

Une remarque pour les propriétaires de Mac Intel

macOS 27 « Golden Gate » est réservé aux puces Apple — M1 ou ultérieur. Tout Mac Intel a été abandonné pour ce cycle. Si vous êtes sur une machine Intel, vous ne pouvez tout simplement pas faire tourner la bêta de macOS 27, donc un problème de navigateur là-bas relève d'autre chose. Ce guide suppose un Mac série M sur la bêta.

Rappelez-vous ce que « bêta » signifie ici

Tout ce qui suit s'articule autour de ce que les bêta-testeurs rapportent, agrégé à partir des forums communautaires et de la couverture presse. Rien de tout cela n'est un défaut reconnu par Apple avec un correctif officiel. Cela compte pour deux raisons : le comportement peut évoluer d'une version à l'autre (un correctif nécessaire sur la Bêta publique 2 pourrait devenir inutile après la version suivante), et pour certains testeurs, le remède ultime a tout simplement été d'attendre Apple. Calibrez vos attentes en conséquence : c'est un système d'exploitation préliminaire.

Pourquoi seuls les navigateurs autres que Safari tombent en panne sur la bêta de macOS 27

Le fait de diagnostic le plus utile dont vous disposez est la scission Safari/Chromium. Comprendre pourquoi ces deux catégories se comportent différemment vous oriente directement vers les correctifs — alors passons en revue le mécanisme, avec la réserve qu'il s'agit d'une inférence éclairée fondée sur des retours communautaires, pas d'une certitude issue de rétro-ingénierie.

Safari et Chromium empruntent des chemins réseau différents

Safari est construit sur WebKit et étroitement intégré à macOS. Il s'appuie sur la pile réseau native du système (NSURLSession, le résolveur système, le magasin de confiance système) de la manière que les propres frameworks d'Apple attendent, et il hérite des commodités de niveau système — iCloud Private Relay, la politique réseau par application, le résolveur DNS du système — en tant que citoyen de première classe.

Les navigateurs Chromium (Chrome, Brave, Edge, Arc, Vivaldi partagent tous le moteur Chromium) effectuent une grande partie de ce travail eux-mêmes. Chromium embarque son propre service réseau, fréquemment son propre résolveur DNS-over-HTTPS, son propre pool de connexions, et ses propres conventions pour ouvrir des sockets. Cette indépendance est normalement un atout. Sur une bêta où Apple modifie peut-être la façon dont le réseau par application, le DNS ou le filtrage par extension réseau se comporte, elle devient un handicap : les hypothèses de Chromium et le nouveau comportement de la bêta peuvent se désynchroniser d'une manière que Safari ne rencontre jamais, puisque Safari procède par défaut à la façon d'Apple.

L'angle extension réseau et DNS (la version nuancée)

macOS moderne achemine le trafic des applications via un framework d'extension réseau. Les filtres de contenu, clients VPN, proxies DNS et pare-feux s'enregistrent tous en tant qu'extensions réseau système et peuvent inspecter, rediriger ou bloquer le trafic par application. Lorsque les bêta-testeurs rapportent que Safari fonctionne et que chaque navigateur Chromium se bloque, les deux principales théories communautaires se situent dans ce domaine :

1. La résolution DNS échoue spécifiquement pour les applications Chromium. Si Chrome et Brave utilisent leur propre DNS sécurisé (DNS-over-HTTPS) alors que la bêta fait quelque chose de nouveau avec la gestion du DNS, les recherches de nom peuvent se bloquer indéfiniment — ce qui correspond exactement à un Connexion… sans fin. Safari, utilisant le résolveur système, contourne le problème. Des erreurs comme ERR_NAME_NOT_RESOLVED s'accordent parfaitement avec cette théorie.
2. Un filtre d'extension réseau abandonne silencieusement le trafic non-Safari. Les outils qui s'installent en tant qu'extensions réseau — Little Snitch, LuLu, les filtres de contenu d'entreprise et certaines suites antivirus — arbitrent la connectivité par application. Si la bêta a modifié la manière dont les extensions sont évaluées ou approuvées, un filtre peut finir par laisser passer Safari tout en engloutissant les applications Chromium. C'est la même famille de friction bêta que nous avons documentée autour des filtres de contenu par extension réseau dans le correctif de l'extinction liée aux extensions réseau sur macOS Tahoe 26.5.1 — symptôme différent, même sous-système sous tension.

Les deux sont cohérents avec les retours, et honnêtement il n'y a probablement pas une seule cause universelle — différents testeurs ont probablement des déclencheurs différents empilés sur le même socle « Chromium suit son propre chemin réseau ». C'est une bonne nouvelle pour la résolution du problème : vous n'avez pas besoin de savoir lequel vous concerne. Vous descendez simplement l'échelle et un échelon fonctionne généralement.

Décoder le message d'erreur exact

L'erreur que Chrome vous affiche restreint considérablement la cause, donc lisez-la avant de commencer à cliquer. Voici quelques erreurs courantes et ce qu'elles signifient généralement sur cette bêta :

• ERR_NAME_NOT_RESOLVED — un pur échec DNS. Le navigateur n'a absolument pas pu convertir le domaine en adresse IP. Cela pointe fortement vers le Correctif 1 (désactiver le DNS sécurisé) et le Correctif 4 (vider le cache). C'est la signature la plus courante du schéma de cette bêta.
• ERR_CONNECTION_TIMED_OUT — le nom a été résolu mais la connexion elle-même n'a jamais abouti. Cela penche vers un filtre d'extension réseau (Correctif 2), une course IPv6 (Correctif 3), ou un VPN à moitié en vie (Correctif 5) qui engloutit le trafic silencieusement.
• ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET — quelque chose a activement fermé la connexion. Sur un Mac avec un filtre de contenu ou une extension pare-feu, c'est votre filtre en plein verdict — allez directement au Correctif 2.
• ERR_PROXY_CONNECTION_FAILED — un proxy est configuré (souvent par un profil de configuration résiduel ou une application VPN) et il est hors service. Voir la vérification des profils du Correctif 5.
• Un onglet qui tourne indéfiniment sans erreur — généralement une recherche DNS qui se bloque plutôt qu'elle échoue franchement, ce qui relève à nouveau des Correctifs 1 et 4.

Rien de tout cela n'est définitif sur une bêta, mais ces indices vous indiquent quel échelon essayer en premier plutôt que de tous les parcourir laborieusement.

Ce qu'est réellement une « extension réseau », en clair

Si l'expression extension réseau ne vous évoque rien, voici la version courte — c'est important car la moitié des correctifs ci-dessous tournent autour de cette notion. Il y a des années, les applications qui devaient inspecter ou filtrer votre trafic (VPN, pare-feux, contrôle parental, boucliers web antivirus) le faisaient avec des extensions du noyau qui s'exécutaient avec des privilèges système profonds. Apple a passé plusieurs versions à faire migrer tout cela hors du noyau vers un framework en espace utilisateur, isolé dans une bac à sable, appelé Network Extensions. Lorsque vous installez Little Snitch, un filtre d'entreprise ou un VPN aujourd'hui, il s'enregistre comme une extension réseau système à travers laquelle macOS achemine votre trafic afin que l'outil puisse autoriser, bloquer ou rediriger les connexions — souvent application par application.

Cette capacité par application est le nœud du problème. Une extension réseau peut, en principe, traiter Safari et Chrome différemment, et elle dépend du système d'exploitation pour lui indiquer comment les connexions sont structurées. Lorsqu'une bêta modifie la plomberie sous-jacente — la façon dont les extensions sont approuvées, dont le trafic par application est étiqueté, dont l'extension reçoit chaque connexion — une extension qui se comporte parfaitement pour Safari peut finir par abandonner ou bloquer le trafic Chromium sans que personne ne l'ait voulu. C'est pourquoi « désactivez l'extension réseau et retestez » est une étape aussi déterminante ici, et pourquoi il est important de réapprouver les extensions après chaque mise à jour bêta.

Pourquoi cela crie « bêta » et non « votre navigateur est cassé »

Si Chrome lui-même était cassé, une réinstallation le résoudrait et Brave/Edge/Arc/Vivaldi ne tomberaient pas tous en panne à l'unisson. Si votre réseau était cassé, Safari échouerait aussi. La seule chose qui explique proprement « chaque navigateur Chromium mort, WebKit intact, même machine, même Wi-Fi » est quelque chose au niveau du système d'exploitation et du réseau qui traite ces deux catégories d'applications différemment — c'est exactement le genre d'erreur que commet un système d'exploitation préliminaire. La lecture du récapitulatif des problèmes connus de la bêta Golden Gate vaut la peine pour comprendre l'ampleur des aspérités présentes dans cette version.

Une liste de tri de 60 secondes

Avant l'échelle complète, effectuez ces cinq vérifications rapides. Elles ne coûtent presque rien et pointent fréquemment directement vers le correctif gagnant.

1. Safari charge-t-il un site ? Si oui, c'est confirmé : c'est le schéma spécifique à Chromium et l'échelle ci-dessous s'applique. Si Safari échoue lui aussi, il ne s'agit pas du bug de navigateur de la bêta — c'est une connectivité générale ; consultez le guide des déconnexions Wi-Fi.
2. Un VPN ou un filtre de contenu est-il en cours d'exécution ? Regardez dans la barre de menus et dans Réglages Système > Général > Éléments de connexion et extensions > Extensions réseau. Si quelque chose y figure, c'est le suspect numéro un.
3. iCloud Private Relay est-il activé ? Réglages Système > [votre nom] > iCloud > Private Relay. Notez s'il est activé.
4. Les adresses IP fonctionnent-elles quand les noms de domaine ne fonctionnent pas ? Dans Chrome, essayez de charger http://1.1.1.1. Si une IP brute se charge mais pas cloudflare.com, votre problème vient du DNS, et les Correctifs 1 et 4 sont vos cibles.
5. Un tout nouveau profil de navigateur se comporte-t-il de la même façon ? Dans Chrome, ouvrez une nouvelle fenêtre Invité. Si elle échoue également, la cause est à l'échelle du système, pas de votre profil — passez directement aux correctifs réseau.

Quoi que ces cinq points vous indiquent, vous pouvez toujours simplement commencer au Correctif 1 et suivre l'ordre. Redémarrez Chrome complètement entre chaque correctif (Cmd+Q, pas seulement fermer la fenêtre) afin que chaque changement soit effectivement pris en compte.

Confirmer exactement où ça casse (optionnel mais puissant)

Si vous voulez avoir la certitude de la couche qui échoue avant de modifier des réglages, cinq commandes Terminal sûres vous le diront. Aucune ne modifie quoi que ce soit — elles se contentent de lire l'état — vous pouvez donc toutes les exécuter sans risque. L'objectif est de séparer trois questions : Le réseau est-il joignable du tout ? Le DNS fonctionne-t-il ? Le chemin HTTP au niveau système fonctionne-t-il alors même que Chrome échoue ?

1. Pouvez-vous joindre internet par IP brute ? Ceci contourne entièrement le DNS.

ping -c 4 1.1.1.1

Si vous obtenez des réponses, votre Mac dispose d'une connectivité fonctionnelle et le problème se situe plus haut (DNS ou par application). Si cela échoue aussi, Safari échouerait également et vous êtes face à une connectivité générale, pas au schéma bêta des navigateurs.

2. La résolution DNS fonctionne-t-elle ?

ping -c 4 cloudflare.com

Si l'étape 1 a fonctionné mais que celle-ci indique impossible de résoudre ou se bloque, vous avez confirmé un problème de DNS — exactement ce que ciblent les Correctifs 1 et 4.

3. Interrogez directement le résolveur. dig et nslookup sont tous deux fournis avec macOS et vous montrent ce que renvoie le résolveur système :

dig cloudflare.com +short
nslookup cloudflare.com

Une réponse ici signifie que le résolveur système fonctionne correctement et que c'est le propre DNS-over-HTTPS de Chromium qui est bloqué — un signal fort que le Correctif 1 (désactiver le DNS sécurisé du navigateur, pour qu'il se repose sur ce résolveur système fonctionnel) va aider.

4. La pile HTTP du système charge-t-elle une page même quand Chrome n'y arrive pas ? curl utilise le réseau propre de macOS, la même catégorie de chemin qu'utilise Safari :

curl -I https://www.cloudflare.com

Si curl renvoie des en-têtes (HTTP/2 200 et compagnie) alors que Chrome se bloque, c'est tout le diagnostic en une seule ligne : le chemin de l'OS fonctionne, celui de Chromium non. C'est le schéma bêta, confirmé, et cela signifie que les correctifs au niveau système ci-dessous sont votre meilleur pari.

5. Quel DNS le système utilise-t-il réellement ?

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

Ceci montre si un VPN, un profil ou un filtre vous a discrètement orienté vers des serveurs DNS que vous n'avez pas choisis. Si vous voyez des adresses inattendues, revoyez les vérifications de profils et de VPN du Correctif 5.

Exécutez ces cinq commandes, et vous saurez avant même de toucher à un réglage si vous traquez un problème de DNS, un filtre, ou un problème de chemin par application. Si Terminal n'est pas votre truc, sautez entièrement cette section — l'échelle de correctifs fonctionne très bien sans elle.

L'échelle de correctifs

Travaillez de haut en bas. Retestez après chaque étape ; arrêtez-vous dès que vos sites reviennent. Chaque étape ici est réversible.

Correctif 1 : désactiver le DNS sécurisé / DNS-over-HTTPS dans le navigateur

C'est le correctif le plus rentable pour ce schéma bêta, car le DNS chiffré intégré de Chromium est exactement le type de gestion réseau autonome qui peut se désynchroniser d'un OS bêta. Vous demandez au navigateur d'arrêter de résoudre les noms lui-même et de se reposer sur le système.

Dans Chrome, Brave, Edge et Vivaldi :

1. Ouvrez Réglages > Confidentialité et sécurité > Sécurité.
2. Faites défiler jusqu'à Utiliser le DNS sécurisé et désactivez-le entièrement. (Ne changez pas simplement de fournisseur — désactivez-le complètement pour que le navigateur utilise le résolveur de l'OS.)
3. Quittez complètement le navigateur (Cmd+Q) et rouvrez-le.

Dans Arc : ouvrez Arc > Réglages, trouvez la section confidentialité/sécurité, et désactivez le DNS sécurisé de la même manière ; Arc expose le réglage de Chromium dans ses propres menus.

Si une IP brute s'est chargée lors de votre vérification de tri mais pas les domaines, cette seule étape résout très souvent le problème.

Correctif 2 : désactiver ou supprimer les extensions de filtrage réseau, VPN et de filtrage de contenu

Si vous utilisez Little Snitch, LuLu, un filtre de contenu d'entreprise, une application de filtrage DNS, ou une suite antivirus avec protection web, elle s'est presque certainement installée en tant qu'extension réseau système — et c'est le principal suspect pour laisser passer Safari tout en bloquant Chromium sous cette bêta.

1. Allez dans Réglages Système > Général > Éléments de connexion et extensions, puis cliquez sur le (i) à côté de Extensions réseau (ancien chemin : Extensions réseau ou Contenu et confidentialité selon la version).
2. Désactivez chaque extension tierce de filtrage réseau / VPN / pare-feu une par une.
3. Quittez et rouvrez complètement Chrome après chaque bascule, puis retestez.

Si désactiver l'une d'elles fait revenir Chrome, vous avez trouvé votre coupable. À partir de là, vous pouvez la laisser désactivée jusqu'à ce qu'Apple publie une version corrigée, mettre à jour l'outil vers sa dernière version (les éditeurs corrigent rapidement pour les bêtas), ou vérifier les notes de compatibilité bêta de l'éditeur. Si vous êtes sur un Mac géré/professionnel, vous ne pourrez peut-être pas désactiver vous-même un filtre d'entreprise — c'est un cas pour votre équipe informatique, et une raison légitime de repousser la bêta. Notre article sur les filtres de contenu par extension réseau approfondit la façon dont ces extensions se comportent lorsque l'OS change sous elles.

Correctif 3 : régler l'IPv6 sur Link-local uniquement pour le service réseau actif

Plusieurs testeurs rapportent que la course de connexion en double pile (IPv4 + IPv6) de Chromium se bloque sous la bêta quand l'IPv6 se comporte mal, alors que Safari le tolère. Forcer le service réseau à abandonner l'IPv6 complet pousse le trafic vers le chemin IPv4 qui fonctionne.

Via Réglages Système (recommandé, en douceur) :

1. Réglages Système > Réseau, sélectionnez votre service actif (Wi-Fi ou Ethernet), cliquez sur Détails….
2. Allez dans l'onglet TCP/IP.
3. Réglez Configurer IPv6 sur Link-local uniquement.
4. Cliquez sur OK, puis quittez et rouvrez complètement Chrome.

Via Terminal (équivalent, si vous préférez la ligne de commande) : commencez par lister les noms de vos services, puis désactivez l'IPv6 pour celui que vous utilisez. Notez que -setv6off désactive l'IPv6 de manière plus complète que le « Link-local uniquement » de l'interface graphique, mais pour isoler ce problème, les deux fonctionnent.

# Voir les noms exacts des services réseau
networksetup -listallnetworkservices

# Désactiver l'IPv6 pour le Wi-Fi (utilisez votre nom de service exact)
sudo networksetup -setv6off "Wi-Fi"

Pour restaurer l'IPv6 normal plus tard :

sudo networksetup -setv6automatic "Wi-Fi"

Correctif 4 : vider le cache DNS

Si le DNS est en cause (et sur cette bêta, c'est souvent le cas), un cache de résolveur périmé ou corrompu peut maintenir des recherches en échec bloquées même après avoir modifié un réglage. Videz-le. C'est une paire de commandes macOS standard et sûre — elle vide le cache et redémarre le répondeur DNS multicast :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On vous demandera votre mot de passe administrateur. Il n'y a aucune sortie visible en cas de succès — c'est normal. Quittez et rouvrez Chrome ensuite et essayez un site. Combinez ceci avec le Correctif 1 (DNS sécurisé désactivé) pour les meilleures chances ; les deux ensemble s'attaquent au mode d'échec DNS le plus courant rapporté pour cette bêta.

Correctif 5 : vérifier Private Relay, le VPN et les profils de configuration

iCloud Private Relay et les VPN remodèlent tous les deux la façon dont le trafic quitte votre Mac, et tous deux sont traités différemment pour Safari que pour les applications Chromium — ce qui en fait des suspects classiques d'échec asymétrique.

• iCloud Private Relay : Réglages Système > [votre nom] > iCloud > Private Relay. Désactivez-le temporairement et retestez Chrome. Private Relay n'achemine que Safari et une partie du trafic système, mais le basculer peut réinitialiser un état réseau dans lequel Chromium restait coincé.
• VPN : si un VPN est connecté, déconnectez-le complètement (ne vous contentez pas de minimiser l'application) et retestez. Les tunnels à moitié connectés ou incompatibles avec la bêta sont une cause très courante de « le navigateur se bloque indéfiniment ». Si le VPN s'avère être votre problème, parcourez notre guide de dépannage VPN macOS — la plupart des clients VPN ont besoin d'une mise à jour compatible avec la bêta.
• Profils de configuration : dans Réglages Système > Général > Gestion des appareils (ou Confidentialité et sécurité > Profils), supprimez tout ancien profil DNS ou proxy que vous ne reconnaissez pas ou dont vous n'avez pas besoin. Les profils résiduels peuvent figer de mauvais serveurs DNS.

Correctif 6 : le bascule FaceTime / « Autoriser les appels sur d'autres appareils » que certains testeurs jurent efficace

Celui-ci est étrange, non confirmé, et vaut trente secondes d'essai car un groupe de contributeurs sur les forums rapporte qu'il a ramené leurs navigateurs Chromium à la vie. La théorie est que basculer cette fonctionnalité Continuity pousse la pile réseau à réinitialiser les chemins par application que la bêta avait laissés dans un mauvais état.

1. Ouvrez FaceTime > Réglages (barre de menus : FaceTime > Réglages).
2. Trouvez Appels depuis l'iPhone / Autoriser les appels sur d'autres appareils et désactivez-le, puis réactivez-le.
3. Alternativement, sur iPhone : Réglages > Téléphone > Appels sur d'autres appareils, désactivez puis réactivez votre Mac.
4. Retestez Chrome.

Considérez cela comme du folklore qui fonctionne par hasard pour certaines personnes, pas comme un correctif garanti. Cela ne coûte rien et se réverse instantanément, ce qui justifie sa place dans l'échelle.

Correctif 7 : réinitialiser les réglages réseau du navigateur ou démarrer un profil neuf

Si les correctifs au niveau système n'ont rien donné, isolez si votre profil de navigateur spécifique conserve un état réseau corrompu.

• Chrome/Brave/Edge : ouvrez Réglages > Réinitialiser les réglages > Restaurer les réglages à leurs valeurs par défaut. Cela efface le DNS personnalisé, le proxy et les ajustements de démarrage sans toucher à vos favoris ni à vos mots de passe.
• Test avec un profil neuf : créez un nouveau profil (icône de profil > Ajouter) ou ouvrez une fenêtre Invité et essayez un site. Si le profil neuf fonctionne, le problème était local au profil — réinitialisez l'ancien ou migrez vers le nouveau.
• Vider le cache des sockets/hôtes : dans Chrome, visitez chrome://net-internals/#sockets et cliquez sur Flush socket pools, puis chrome://net-internals/#dns et Clear host cache. (Brave et Edge exposent les mêmes pages sous leur propre schéma, par exemple brave://net-internals.)

Correctif 8 : réinstaller proprement le navigateur

Si un navigateur spécifique est le seul irréductible après les correctifs réseau, réinstallez-le proprement. Comme Chrome, Brave, Edge, Arc et Vivaldi partagent tous le même moteur, ne faites cela que si un seul navigateur est à la traîne par rapport aux autres — une cause système ne sera pas guérie par une réinstallation.

1. Quittez le navigateur (Cmd+Q).
2. Faites-le glisser depuis Applications vers la Corbeille.
3. Téléchargez la dernière version directement depuis l'éditeur — les correctifs de compatibilité bêta arrivent constamment dans les mises à jour des navigateurs, une version actuelle peut donc déjà mieux gérer la bêta.
4. Réinstallez et retestez. Vos données synchronisées (favoris, mots de passe) reviennent lorsque vous vous reconnectez.

Correctif 9 (le repli réaliste face à la bêta) : utiliser Safari, ou revenir à Tahoe

Voici la partie honnête. C'est une bêta, la panne des navigateurs est rapportée par les bêta-testeurs et non reconnue par Apple, et certains testeurs ont constaté que rien dans l'échelle ci-dessus ne tient complètement jusqu'à ce qu'Apple publie une nouvelle version. Si vous avez tout essayé jusqu'au bout et que Chromium reste mort, vous avez deux options raisonnables :

• Vous appuyer sur Safari pour l'instant. Il fonctionne, il est rapide, et il importe vos favoris. Faire tourner votre navigation quotidienne sur Safari pendant quelques semaines pendant que la bêta mûrit est un pis-aller parfaitement raisonnable, et vous pouvez continuer à retester Chrome après chaque nouvelle version (le comportement change réellement d'une version à l'autre).
• Revenir à Tahoe stable. Si un navigateur Chromium fonctionnel n'est pas négociable — pour le travail, pour des extensions, pour un flux de travail que vous ne pouvez pas déplacer — la solution la plus propre est de quitter la bêta. Suivez notre guide étape par étape pour revenir de la bêta de macOS 27 à Tahoe sans perdre de données. Et si vous ne faites que considérer la bêta, tout ce problème plaide fortement en faveur de son installation en toute sécurité sur un volume séparé la prochaine fois, afin que votre système de travail ne soit jamais celui qui casse.

Il n'y a aucune honte à aucune de ces options. Une bêta est un aperçu que vous vous êtes porté volontaire pour tester, pas un engagement à subir un navigateur cassé.

Résolution des problèmes courants

Problème : Chrome charge certains sites mais se bloque sur d'autres sous la bêta

Solution : un chargement partiel signifie presque toujours DNS, et non un blocage total. Certains noms se résolvent depuis le cache pendant que les nouvelles recherches se bloquent. Effectuez le Correctif 1 (désactiver le DNS sécurisé) et le Correctif 4 (vider le cache DNS) ensemble, puis quittez complètement Chrome et réessayez. Si le problème persiste, réglez votre DNS système sur un résolveur simple — Réglages Système > Réseau > Détails > DNS et ajoutez 1.1.1.1 et 8.8.8.8 — afin que l'OS ne dépende pas d'un résolveur mal géré par la bêta.

Problème : tout fonctionnait, puis a de nouveau cassé après une mise à jour bêta

Solution : attendez-vous à cela. Chaque nouvelle version peut réinitialiser les approbations d'extensions réseau et les comportements de bascule. Après toute mise à jour bêta de macOS 27, réapprouvez vos extensions réseau dans Réglages Système > Général > Éléments de connexion et extensions > Extensions réseau, puis relancez le Correctif 1 et le Correctif 4. Comme il s'agit d'un comportement de bêta non reconnu, traitez chaque version comme un diagnostic neuf plutôt que de supposer que votre correctif précédent tient toujours.

Problème : un Mac professionnel ou scolaire bloque les correctifs dont j'ai besoin

Solution : les Mac gérés imposent des filtres de contenu d'entreprise et des profils de configuration que vous ne pouvez pas désactiver vous-même, et ces filtres sont un suspect de premier plan pour la scission Safari-fonctionne/Chromium-échoue. Ne combattez pas le MDM. Contactez votre équipe informatique, indiquez-leur que le navigateur échoue uniquement pour les applications Chromium sur la bêta de macOS 27, et demandez si l'éditeur de leur filtre dispose d'une version compatible avec la bêta. Sinon, c'est un signal clair qu'un Mac de production ou géré ne devrait pas encore être sur la bêta.

Problème : désactiver mon extension réseau a réparé Chrome mais j'ai besoin que cet outil tourne

Solution : vous avez confirmé le coupable — restaurez maintenant la protection de la bonne manière. Mettez à jour l'outil (Little Snitch, LuLu, votre antivirus) vers sa dernière version, car les éditeurs publient rapidement des correctifs de compatibilité bêta. Vérifiez les notes de version de l'éditeur ou son forum pour une mention de macOS 27. S'il n'existe pas encore de version compatible, vous devez choisir entre l'outil et Chromium sur cette bêta — une raison légitime d'envisager un retour à Tahoe en attendant que l'éditeur rattrape son retard.

FAQ

Pourquoi Safari fonctionne-t-il mais pas Chrome et Brave sur la bêta de macOS 27 ?

Safari utilise le réseau et le DNS natifs de macOS, il hérite donc de tout ce que la bêta a modifié. Les navigateurs Chromium gèrent leur propre DNS, leurs sockets et leur logique de connexion, ce qui peut se désynchroniser de la nouvelle gestion réseau par application de la bêta. Même machine, même Wi-Fi, chemin réseau différent — voilà pourquoi l'un fonctionne et les autres se bloquent.

S'agit-il d'un bug officiel d'Apple avec un correctif à venir ?

Pas officiellement. Le problème est rapporté par les bêta-testeurs sur Brave Community, Apple Discussions et MacRumors, et relayé par la presse, mais Apple n'a publié aucune reconnaissance officielle. Comme il vit dans une version préliminaire, le comportement peut changer à chaque nouvelle version, donc retestez après chaque mise à jour bêta de macOS 27.

Désactiver le DNS sécurisé rendra-t-il ma navigation moins privée ?

Légèrement, et seulement temporairement. Désactiver le DNS-over-HTTPS du navigateur signifie que les recherches de noms utilisent votre résolveur système au lieu d'un résolveur chiffré. Pour un contournement sur une bêta, c'est un compromis correct, et vous pourrez réactiver le DNS sécurisé une fois qu'Apple publiera une version qui cohabite bien avec Chromium. Votre trafic de page HTTPS reste chiffré dans les deux cas.

Je suis sur macOS 26.5.2, pas sur la bêta. Ces correctifs s'appliquent-ils ?

Probablement pas. Une panne totale de Chromium est le schéma de la bêta. Sur Tahoe stable 26.5.2 (build 25F84), un navigateur qui échoue à charger des sites relève plus probablement d'une connectivité ordinaire, d'un VPN ou d'un filtre. Commencez par les guides Wi-Fi et VPN liés ci-dessus plutôt que par les étapes spécifiques à la bêta présentées ici.

Réinstaller Chrome pourrait-il régler le problème à lui seul ?

Rarement, pour ce problème. Si Brave, Edge, Arc et Vivaldi échouent tous en même temps que Chrome, la cause est au niveau système et réinstaller un seul navigateur n'aidera pas. Réinstallez uniquement lorsqu'un seul navigateur Chromium est à la traîne par rapport aux autres — et prenez toujours la dernière version, car les mises à jour de navigateurs ajoutent souvent la compatibilité bêta.

Devrais-je simplement revenir à Tahoe pour ce problème ?

Si un navigateur Chromium fonctionnel est essentiel à votre quotidien et que l'échelle de correctifs n'a rien donné de durable, oui — c'est une décision raisonnable. Suivez le guide de rétrogradation lié ci-dessus pour revenir en arrière sans perdre de données. Si vous pouvez vivre avec Safari pendant quelques semaines, rester sur la bêta et retester chaque nouvelle version est la voie qui demande le moins d'effort.

Conclusion

Lorsque Chrome ne charge pas les sites web sur la bêta de macOS 27 alors que Safari fonctionne parfaitement, vous n'êtes pas face à un Mac cassé ou à un navigateur cassé — vous êtes face à un système d'exploitation préliminaire qui traite le chemin réseau indépendant de Chromium différemment de celui de WebKit. Cette seule idée explique pourquoi les correctifs sont pour la plupart de simples bascules : désactivez le DNS sécurisé du navigateur, désactivez une extension de filtrage réseau, réglez l'IPv6 sur Link-local uniquement, videz le cache DNS, et vérifiez Private Relay et le VPN. L'un de ces échelons résout le problème pour la plupart des testeurs, et chacun d'eux se réverse en quelques secondes.

Mais gardez le cadre honnête bien en vue : ceci est un comportement rapporté par les bêta-testeurs, pas un bug confirmé par Apple, et sur une bêta, le correctif ultime est parfois la patience. Le comportement change d'une version à l'autre, donc retestez après chaque nouvelle version — et si un navigateur Chromium fonctionnel est quelque chose dont vous ne pouvez pas vous passer, il n'y a aucune honte à s'appuyer sur Safari ou à revenir à Tahoe stable jusqu'à ce qu'Apple règle le problème. Vous vous êtes porté volontaire pour tester un aperçu ; traiter un navigateur cassé comme une situation d'« attente de la prochaine version » est exactement le bon réflexe.

Une dernière habitude pratique : surveillez le rythme des bêtas. Apple a publié des versions à peu près toutes les une à deux semaines — la Bêta publique 1 est arrivée le 13 juillet, la Bêta publique 2 le 22 juillet, avec la bêta développeur 4 (build 26A5388g) le 20 juillet — et le comportement réseau a réellement évolué entre les versions. La routine intelligente consiste donc à garder votre correctif fonctionnel en place, à noter quel échelon a résolu votre problème, et après chaque nouvelle version, à désactiver brièvement ce contournement et à retester Chrome. Si une version résout discrètement le problème sous-jacent, vous voudrez rétablir le DNS sécurisé et l'IPv6 à leurs réglages normaux plutôt que de les laisser modifiés indéfiniment. Les bêtas évoluent ; vos contournements ne devraient pas être permanents.

Travaillez l'échelle du haut vers le bas, arrêtez-vous au premier échelon qui ramène vos sites, et si vous hésitez à rester sur Golden Gate, le guide des problèmes connus et le guide d'installation sûre vous aideront à décider en toute clarté.