Kernel Panic & Redémarrages Aléatoires sur macOS Tahoe 26.5 : Lire le Journal de Panique et Résoudre le Problème

Vous êtes en train de rédiger un document, de rendre une timeline, ou simplement de lire une page web — et l'écran devient noir. Quelques secondes plus tard, votre Mac affiche la fenêtre de connexion avec un message : « Votre ordinateur a redémarré en raison d'un problème. » C'est un kernel panic, et sur macOS Tahoe 26.5, il est devenu l'une des plaintes de type « la machine entière vient de s'éteindre » les plus signalées dans les forums d'assistance et les fils de discussion pour développeurs. Un kernel panic n'est pas un plantage d'application — c'est le cœur du système d'exploitation qui décide que continuer serait dangereux, ce qui entraîne un arrêt complet suivi d'un redémarrage.

La bonne nouvelle est qu'un kernel panic laisse presque toujours une empreinte : un rapport de panique. Enfoui dans ce rapport se trouvent un panicString, un backtrace, et une liste des extensions noyau présentes en mémoire au moment du plantage. Une fois que vous pouvez lire ces trois éléments, vous cessez de faire des suppositions et commencez à diagnostiquer. Ce guide est construit autour de cette compétence. Nous lirons un rapport de panique réel ligne par ligne, puis nous suivrons un arbre de décision qui associe ce que vous trouvez aux déclencheurs les plus courants sur Tahoe 26.5 — taux de rafraîchissement élevés des moniteurs externes, extensions noyau et système, pannes lors du cycle sommeil/réveil avec des périphériques, les problèmes matériels reconnus par Apple dans la version 26.5, et les états système corrompus.

macOS Tahoe 26.5 a été publié le 11 mai 2026 et, comme toute mise à jour mineure, il a corrigé certains problèmes tout en en faisant apparaître d'autres. Les notes de version entreprise d'Apple reconnaissent des correctifs de redémarrage affectant les MacBook Air M5 et les modèles M5 Pro/Max, des extensions réseau de filtrage de contenu provoquant des redémarrages, et une condition d'écran noir après une mise à jour. Ce contexte est important, car il indique qu'Apple sait que des régressions de stabilité au niveau du noyau existent dans cette génération. Mais tous les panics ne sont pas des bugs à corriger par Apple — beaucoup sont causés par un écran tiers tournant trop vite, un ancien kext VPN ou un hub Thunderbolt défaillant. Le journal de panique vous permet de distinguer chaque cause.

Points Clés

• Un kernel panic est un redémarrage complet du système déclenché par le cœur du système d'exploitation, et non par un plantage d'application — il écrit toujours un rapport de panique dans /Library/Logs/DiagnosticReports/ qui identifie la cause probable.
• Lisez trois champs en premier : le panicString (la raison lisible par l'humain), le backtrace (quel processus/pilote était en cours d'exécution) et « Kernel Extensions in backtrace » (les pilotes tiers impliqués).
• Le correctif le plus propre et le plus confirmé par la communauté pour Tahoe 26.5 est de réduire le taux de rafraîchissement d'un écran externe tiers de 120/144/240 Hz à 60 Hz — les panics GPU/affichage à taux de rafraîchissement élevé sur Mac Studio et Mac mini sont répandus et se résolvent instantanément une fois le taux abaissé.
• Auditez les extensions noyau et système avec kmutil showloaded et systemextensionsctl list, puis démarrez en Safe Mode pour vérifier si une extension tierce est à l'origine du problème ; les outils VPN, antivirus et virtualisation sont les suspects habituels.
• Apple a reconnu des correctifs de redémarrage dans la version 26.5 pour les MacBook Air M5 / M5 Pro & Max, les extensions réseau de filtrage de contenu, et une condition d'écran noir après mise à jour ; les panics restants sont signalés par la communauté avec des solutions de contournement — mettez à jour entièrement, puis isolez méthodiquement avant de supposer une défaillance matérielle.

Kernel Panic vs Plantage d'Application vs Blocage : Identifier ce que vous observez

Avant d'ouvrir un seul journal, clarifiez la terminologie, car le chemin de résolution est complètement différent selon chaque cas.

Un kernel panic est une défaillance à l'intérieur du noyau XNU — la couche la plus basse de macOS qui communique directement avec le CPU, le GPU, le contrôleur de mémoire et les pilotes. Lorsque le noyau atteint un état dont il ne peut pas se remettre de manière sûre (un accès mémoire incorrect dans un pilote, une faute matérielle, un blocage dans un chemin critique), il arrête délibérément l'ensemble du système et redémarre. Le signe révélateur est la boîte de dialogue qui apparaît après le redémarrage : « Votre ordinateur a redémarré en raison d'un problème. Appuyez sur une touche ou attendez quelques secondes pour continuer le démarrage. » Sur les anciens Mac ou les Mac Intel, vous pouvez brièvement voir un écran assombri avec le message « Vous devez redémarrer votre ordinateur. Maintenez le bouton d'alimentation enfoncé... » en plusieurs langues. Dans les deux cas, toute la machine s'est arrêtée, pas seulement une application.

Un plantage d'application est un seul processus qui se ferme de manière inattendue. Le reste de macOS continue de fonctionner, vous obtenez une boîte de dialogue « [Application] a quitté de manière inattendue » avec des boutons Rouvrir/Signaler, et vous pouvez continuer à utiliser tout le reste. Les plantages d'application écrivent également des rapports .crash ou .ips, mais ils sont limités à un seul processus. Si vos onglets Safari meurent mais que le Dock, Finder et les autres applications restent actifs, c'est un plantage d'application, pas un panic — couvert par notre guide séparé sur les plantages d'onglets Safari sur macOS Tahoe 26.5.

Un blocage ou gel se produit quand le système cesse de répondre mais ne redémarre pas. Le curseur peut devenir une boule arc-en-ciel tournante, l'écran est figé et rien ne réagit — mais il n'y a pas de redémarrage automatique. Un blocage peut parfois précéder un panic (le noyau se bloque, puis déclenche un watchdog qui force un redémarrage), mais un blocage pur nécessite que vous forciez l'extinction vous-même. Le diagnostic des blocages est différent — spindump, la fonctionnalité « Échantillonner le processus » du Moniteur d'Activité, et log show pour la période précédant le gel.

Voici la décision rapide :

• La machine entière a redémarré d'elle-même + boîte de dialogue « redémarré en raison d'un problème » → kernel panic. Lisez le rapport de panique. C'est ce guide.
• Une application a quitté, le reste du système fonctionne bien → plantage d'application. Examinez le rapport .ips de cette application.
• Système figé, pas de redémarrage, vous avez dû forcer l'extinction → blocage. Ensemble d'outils différent.

Identifier correctement le problème évite des heures de travail inutile. Des utilisateurs passent des jours à réinstaller des applications pour corriger un « plantage » qui était en réalité un kernel panic causé par un moniteur 240 Hz.

Comment Trouver et Lire le Rapport de Panique

Chaque kernel panic sur macOS écrit un rapport de diagnostic. Il existe deux façons d'y accéder : Console.app (graphique) et le système de fichiers / Terminal (plus rapide et scriptable).

Où se trouvent les journaux de panique

Les rapports de panique sont stockés ici :

# Rapports de diagnostic par machine (les kernel panics se trouvent ici)
ls -lt /Library/Logs/DiagnosticReports/ | head -20

Vous recherchez des fichiers nommés comme Kernel-2026-05-22-143012.panic ou panic-full-2026-05-22-143012.ips. Les plus récents sont en haut grâce à -lt (tri par date). Sur Apple silicon, les versions récentes de macOS écrivent un rapport panic-full plus riche ; sur les anciens systèmes, vous verrez peut-être des fichiers texte .panic. Il existe également un dossier au niveau utilisateur, mais les kernel panics sont à l'échelle du système et vont dans /Library/Logs/DiagnosticReports/.

Pour lister uniquement les rapports liés aux panics :

ls -lt /Library/Logs/DiagnosticReports/ | grep -iE 'panic|kernel'

Ouvrir un rapport de panique dans Console.app

Si vous préférez une interface graphique :

1. Ouvrez Console (Applications → Utilitaires → Console, ou Spotlight « Console »).
2. Dans la barre latérale gauche sous Rapports, cliquez sur Rapports de plantage (ancienne macOS) ou Rapports système.
3. Faites défiler pour trouver les entrées commençant par Kernel ou contenant panic dans leur nom. Cliquez sur l'une d'elles.
4. Le rapport complet apparaît à droite. Utilisez Cmd+F pour accéder directement à panicString.

Console est pratique, mais lire le fichier brut est souvent plus rapide, car vous pouvez effectuer des recherches instantanément et copier l'intégralité du rapport.

Le journal unifié en direct

Le fichier de panique est écrit au moment du plantage. Vous pouvez également extraire les messages liés aux panics du journal unifié, ce qui est utile lorsque vous souhaitez voir ce qui s'est passé dans les secondes précédant le redémarrage :

# Afficher les messages liés aux panics du dernier jour
log show --predicate 'eventMessage contains "panic"' --last 1d

# Limiter au processus kernel et aux 6 dernières heures, très utile juste après un panic
log show --predicate 'process == "kernel"' --last 6h | grep -i panic

Le journal unifié ne contiendra pas le backtrace complet comme le fait le fichier .panic, mais il vous donne le contexte temporel — ce que le système faisait dans la période précédant le problème.

Anatomie d'un rapport de panique : un exemple annoté

C'est la partie qui vous transforme d'un utilisateur qui suppute en un vrai diagnosticien. Un rapport de panique a une structure prévisible. Voici un panicString Apple silicon représentatif (anonymisé et illustratif) du type que les utilisateurs voient avec des problèmes de taux de rafraîchissement d'affichage élevé :

panic(cpu 4 caller 0xfffffff0291a7c40): userspace watchdog timeout:
no successful checkins from com.apple.WindowServer in 120 seconds
service: com.apple.logd, total successful checkins since load
(831 seconds ago): 83, last successful checkin: 0 seconds ago
service: com.apple.WindowServer, total successful checkins since
load (831 seconds ago): 8, last successful checkin: 120 seconds ago

Panic occurred in process WindowServer

Backtrace (CPU 4), panicked thread: 0xfffffff...
...
AppleH13CamIn ... AGXG16X ... IOMobileFramebuffer ...

Kernel Extensions in backtrace:
   com.apple.iokit.IOMobileFramebufferFamily
   com.apple.AGXG16X

Lisez-le de haut en bas :

• panic(cpu 4 caller 0x...) — quel cœur CPU a déclenché le panic et l'adresse du code qui l'a appelé. Les adresses hexadécimales ne vous sont pas destinées ; les mots qui les suivent le sont.
• userspace watchdog timeout: no successful checkins from com.apple.WindowServer in 120 seconds — c'est le panicString, la ligne la plus importante. Elle vous dit pourquoi. Ici, WindowServer (le processus d'affichage/composition) a cessé de répondre au watchdog, ce qui a forcé un redémarrage. Un WindowServer bloqué est typique des problèmes d'affichage/GPU — fréquemment un taux de rafraîchissement trop élevé.
• Panic occurred in process WindowServer — le « processus dans le backtrace ». C'est le processus qui était en cours d'exécution. WindowServer = graphiques. Un démon réseau = réseau/filtre de contenu. kernel_task uniquement = souvent matériel ou une faute de pilote profonde.
• Symboles du backtrace — noms de fonctions présentes dans la pile. Voir AGXG16X, IOMobileFramebuffer, AppleH13... pointe vers la pile GPU/affichage d'Apple.
• Kernel Extensions in backtrace: — c'est l'indice décisif pour les pilotes tiers. Si vous voyez quelque chose comme com.yourvpn.tun ou com.thirdparty.av ici, un kext est impliqué. Si vous ne voyez que des extensions com.apple.*, la faute est dans le propre code d'Apple ou est due au matériel/à la configuration plutôt qu'à un kext tiers.

Autres patterns panicString et leur signification habituelle :

• Sleep Wake failure in EFI ou Previous Sleep Wake failure — un panic sommeil/réveil. Presque toujours un périphérique, un hub ou un écran externe qui se comporte mal pendant le réveil. (CAUSE 3 ci-dessous.)
• Kernel data abort / DAR ... avec un kext tiers dans le backtrace — un pilote a accédé à de la mémoire incorrecte. Suspectez ce kext.
• KP / machine check, ECC, ou panics sans kext tiers et avec des processus incohérents — tendance vers le matériel (RAM, thermique). (CAUSE 5.)
• watchdog timeout ... WindowServer de manière répétée, uniquement lorsqu'un moniteur spécifique est connecté — affichage/taux de rafraîchissement. (CAUSE 1.)

La discipline essentielle : lisez d'abord le panicString, puis vérifiez si un kext non-Apple apparaît dans « Kernel Extensions in backtrace ». Ces deux informations vous orientent vers la bonne cause dans plus de 80 % des cas.

L'Arbre de Décision Diagnostique

Utilisez ce processus à chaque fois. Il vous évite des réinstallations aléatoires.

1. Reproduisez ou notez le schéma. Le panic se produit-il uniquement lorsqu'un moniteur externe est connecté ? Uniquement au réveil du sommeil ? Uniquement lorsqu'une application ou un VPN spécifique fonctionne ? Aléatoirement sans rien en commun ? Le schéma représente la moitié du diagnostic. Notez-le.
2. Lisez le rapport de panique le plus récent. Obtenez le panicString et la liste « Kernel Extensions in backtrace » (voir ci-dessus).
3. Y a-t-il un kext tiers dans le backtrace ?
   • Oui → allez à la CAUSE 2 (extensions). Identifiez le fournisseur, mettez-le à jour ou supprimez-le, retestez en Safe Mode.
   • Non → continuez.
4. Le panicString mentionne-t-il WindowServer / framebuffer / GPU, et cela se produit-il uniquement avec un moniteur connecté ? → CAUSE 1 (taux de rafraîchissement). Réduisez d'abord l'écran externe à 60 Hz.
5. Le panicString mentionne-t-il Sleep Wake failure, ou cela se produit-il uniquement au réveil ? → CAUSE 3 (sommeil/réveil + périphériques). Déconnectez tout et testez.
6. Êtes-vous sur un MacBook Air M5 / M5 Pro/Max, ou utilisez-vous une extension réseau de filtrage de contenu, ou avez-vous vu un écran noir après la mise à jour ? → CAUSE 4 (éléments 26.5 reconnus par Apple). Assurez-vous d'être entièrement à jour.
7. Pas de kext tiers, pas de schéma affichage/sommeil, les panics sont aléatoires et le rapport varie à chaque fois ? → CAUSE 5 (matériel). Exécutez Apple Diagnostics, vérifiez la RAM/eGPU/thermique.
8. Toujours non résolu après ce qui précède ? → CAUSE 6 (état système corrompu) : réinitialisez la NVRAM, réinitialisez le SMC (Intel), réinstallez macOS sur place.

Voici maintenant les causes en détail.

CAUSE 1 : Taux de Rafraîchissement Élevé du Moniteur Externe (120 / 144 / 240 Hz)

Il s'agit du problème phare de Tahoe 26.5 et, heureusement, celui qui bénéficie du correctif le plus propre. Une grande partie des rapports de « redémarrage aléatoire » sur Mac Studio et Mac mini s'avèrent être des panics du watchdog GPU/affichage déclenchés lorsqu'un écran externe tiers à taux de rafraîchissement élevé est utilisé à 120 Hz, 144 Hz ou 240 Hz. Le rapport de panique affiche un timeout du watchdog WindowServer avec la pile GPU/framebuffer d'Apple (AGX..., IOMobileFramebuffer) dans le backtrace, exactement comme dans l'exemple annoté ci-dessus.

Pourquoi cela se produit

À des taux de rafraîchissement élevés, le pilote GPU et le contrôleur d'affichage échangent des informations de timing, de mode et de synchronisation de manière bien plus agressive qu'à 60 Hz. Les mises à jour mineures de macOS modifient périodiquement le pipeline d'affichage (gestion HDR, négociation du taux variable/ProMotion, dithering, multi-flux via DisplayPort/Thunderbolt). Lorsque le firmware d'un moniteur tiers annonce un mode que le pilote actuel ne négocie pas correctement — ou lorsque le câble/lien DSC est marginal à 240 Hz — le côté GPU peut se bloquer. WindowServer cesse de répondre, le watchdog se déclenche à la marque des 120 secondes, et l'ensemble du système redémarre. Cela semble aléatoire car cela dépend de ce qui est affiché, mais c'est lié à l'écran.

Indices pointant vers le taux de rafraîchissement :

• Les panics ne se produisent jamais sur l'écran intégré seul (ordinateurs portables) ou sans le moniteur externe connecté (les utilisateurs de Mac mini/Studio qui ont également un petit écran secondaire peuvent tester).
• Le panicString mentionne le watchdog WindowServer et le backtrace liste uniquement les kexts GPU/framebuffer d'Apple (aucun kext tiers).
• C'est pire lors de travaux intensifs du GPU, de vidéos, de contenus HDR, ou au réveil depuis la mise en veille de l'écran.
• Un moniteur ou câble haute fréquence spécifique est impliqué ; revenir à un écran 60 Hz fait disparaître le problème.

Le correctif propre : réduire le taux de rafraîchissement

Il s'agit d'une solution de contournement solide, confirmée par la communauté. Réduire le taux de rafraîchissement supprime entièrement le chemin de timing marginal.

1. Ouvrez Réglages Système → Moniteurs.
2. Sélectionnez le moniteur externe.
3. Trouvez le menu déroulant Taux de rafraîchissement. Passez de 240 Hz → 120 Hz, ou pour plus de stabilité, → 60 Hz.
4. Si vous voyez une option ProMotion / Taux de rafraîchissement variable, réglez-la sur un taux fixe plutôt que variable pendant les tests.
5. Utilisez l'écran pendant une journée. Si les panics s'arrêtent, le taux de rafraîchissement était la cause.

Si le panneau Moniteurs de macOS n'expose pas le taux souhaité ou masque les étapes intermédiaires, SwitchResX (un utilitaire d'affichage tiers de longue date) vous permet de définir des timings exacts et de verrouiller un taux de rafraîchissement. Définissez un mode propre à 60 Hz ou 120 Hz et enregistrez-le comme valeur par défaut pour cet écran.

Autres leviers qui aident à la stabilité à taux de rafraîchissement élevé :

• Utilisez un câble certifié. À 144/240 Hz, vous avez besoin d'un câble DisplayPort ou Thunderbolt 4 / USB4 à véritable haute bande passante. Un câble marginal qui « fonctionne » à 60 Hz tombera en panne par intermittence à 240 Hz. Changez le câble avant de blâmer le logiciel.
• Connectez directement, sans passer par un dock, pendant les tests. Les docks et les hubs MST DisplayPort ajoutent une couche de négociation qui peut être le maillon faible.
• Désactivez HDR sur l'écran externe temporairement ; le pipeline HDR ajoute une complexité de timing.
• Mettez à jour le firmware du moniteur si le fabricant en propose un. Les fournisseurs d'écrans publient des correctifs pour les bugs de négociation Mac.

Parce que le correctif est si propre, essayez-le en premier chaque fois qu'un panic se produit uniquement lorsqu'un moniteur externe est connecté. Si réduire à 60 Hz arrête les panics, vous avez votre réponse et vous pouvez décider de rester à un taux sûr, d'essayer 120 Hz ou d'attendre une future mise à jour macOS/firmware. Pour l'ensemble plus large des problèmes d'écran externe sur Tahoe, consultez notre guide de diagnostic pour écran externe non détecté.

CAUSE 2 : Extensions Noyau & Système Défectueuses ou Obsolètes

Si un kext tiers apparaît dans « Kernel Extensions in backtrace », vous avez trouvé votre catégorie de coupable. Les contrevenants habituels sur Tahoe sont les clients VPN, les agents antivirus/sécurité des terminaux, les outils de virtualisation, les pilotes d'interface audio, et les utilitaires de disque/RAID — tout ce qui installe une extension noyau (kext) ou une extension système pour s'accrocher profondément dans le système d'exploitation.

Apple pousse les développeurs depuis des années à migrer des anciens kexts vers les extensions système en espace utilisateur, et chaque version de macOS resserre ce que les kexts hérités peuvent faire. Un kext conçu pour un ancien système peut accéder à la mémoire d'une manière que le nouveau noyau ne tolère pas, ce qui entraîne un panic Kernel data abort nommant ce kext.

Étape 1 : Inventoriez ce qui est chargé

Listez les extensions noyau actuellement en mémoire :

# Afficher toutes les extensions noyau chargées
kmutil showloaded

# Filtrer les extensions d'Apple pour ne voir que les tierces
kmutil showloaded | grep -v com.apple

Tout élément dans cette liste filtrée est un pilote tiers fonctionnant dans votre noyau en ce moment. Comparez-le avec les identifiants de bundle dans la liste « Kernel Extensions in backtrace » de votre rapport de panique — une correspondance est votre principal suspect.

Listez maintenant les extensions système (l'équivalent moderne en espace utilisateur utilisé par les VPN, les filtres de contenu et la sécurité des terminaux) :

# Lister les extensions système installées et leur état (activated/enabled)
systemextensionsctl list

Cela montre chaque extension système, son identifiant d'équipe, et si elle est activated enabled. Les VPN et les filtres de contenu installent des extensions réseau ici — et comme indiqué dans la CAUSE 4, les extensions réseau de filtrage de contenu ont été spécifiquement mentionnées dans les correctifs de redémarrage 26.5 d'Apple.

Étape 2 : Prouvez-le avec le Safe Mode

Le Safe Mode démarre macOS avec les kexts tiers et de nombreux éléments de démarrage désactivés. Si les panics s'arrêtent en Safe Mode, la cause est presque certainement quelque chose que le Safe Mode a désactivé — le plus souvent une extension tierce.

Apple silicon (M1/M2/M3/M4/M5) :

1. Éteignez complètement.
2. Appuyez sur le bouton d'alimentation et maintenez-le jusqu'à l'apparition de « Chargement des options de démarrage ».
3. Sélectionnez votre disque de démarrage, puis maintenez Shift et cliquez sur Continuer en Safe Mode.
4. Connectez-vous. Vous devriez voir « Safe Boot » dans la barre de menus (cherchez dans la fenêtre de connexion ou dans Réglages Système).

Intel :

1. Éteignez.
2. Allumez et maintenez immédiatement Shift jusqu'à l'apparition de la fenêtre de connexion, puis relâchez.

Utilisez le Mac en Safe Mode de la manière qui déclenche normalement les panics (connectez le moniteur, faites fonctionner le réseau du VPN — notez que certaines extensions réseau ne se chargeront pas en Safe Mode, ce qui est lui-même informatif). Pas de panics en Safe Mode → le logiciel tiers est la cause. Redémarrez normalement pour confirmer qu'ils réapparaissent.

Étape 3 : Supprimez ou mettez à jour l'extension défectueuse

Une fois que vous avez un suspect :

1. Mettez-le à jour en premier. Le fournisseur a peut-être déjà publié une version compatible avec Tahoe. La mise à jour est moins perturbatrice que la suppression.
2. Si la mise à jour n'aide pas, désinstallez-le en utilisant le désinstallateur officiel du fournisseur (pas en le glissant dans la Corbeille — les kexts et les extensions système nécessitent une suppression appropriée pour se désinscrire correctement).
3. Après avoir supprimé une extension système, vous devrez peut-être réapprouver ou effacer complètement dans Réglages Système → Confidentialité et sécurité, où macOS liste les extensions en attente d'autorisation ou de suppression. Approuvez celles en lesquelles vous avez confiance ; supprimez celles qui ne vous conviennent pas.
4. Redémarrez et retestez pendant une journée.

Catégories courantes à examiner attentivement, dans l'ordre approximatif où elles causent des panics sur Tahoe : clients VPN (en particulier les anciens kexts de tunnel), agents antivirus/EDR, virtualisation (anciens kexts d'hyperviseur), pilotes d'interface audio, et utilitaires de disque/chiffrement tiers. Si vous en utilisez plusieurs, supprimez-les un par un afin de savoir lequel était responsable plutôt que d'éliminer toute votre pile.

CAUSE 3 : Panics Sommeil/Réveil avec Périphériques et Hubs

Si le panic se produit au réveil depuis le sommeil — vous ouvrez le couvercle ou bougez la souris, l'écran clignote, et la machine redémarre au lieu de se réveiller — et surtout si le panicString indique « Sleep Wake failure », le déclencheur est presque toujours quelque chose connecté au Mac qui ne négocie pas correctement la transition sommeil/réveil. Les docks Thunderbolt, les hubs USB, les disques durs externes, les interfaces audio, les lecteurs de cartes et certains écrans sont les contrevenants récurrents.

Confirmez qu'il s'agit d'un panic sommeil/réveil

Deux vérifications :

# Examiner l'historique sommeil/réveil ; les entrées "Failure" indiquent des problèmes au réveil
pmset -g log | grep -iE 'failure|wake|sleep' | tail -40

pmset -g log est le journal des événements de gestion de l'alimentation. Recherchez des événements Wake suivis de Failure, ou des notes « Previous Sleep Wake failure ». Associez cela au timestamp du rapport de panique — si l'heure du panic correspond à un événement de réveil, vous avez un panic sommeil/réveil.

# Voir quelles assertions et quels appareils sont impliqués dans les transitions d'alimentation
pmset -g assertions

Résolvez-le

1. Déconnectez tout et testez la machine seule. Débranchez tous les hubs, docks, disques durs et périphériques non essentiels. Laissez le Mac dormir et se réveiller à plusieurs reprises pendant une journée. Si les panics s'arrêtent, un périphérique est la cause.
2. Reconnectez un appareil à la fois, en attendant une journée entre chaque, jusqu'à ce que le panic réapparaisse. Le dernier que vous avez ajouté est le coupable.
3. Alimentez le hub/dock de manière externe. Les hubs alimentés par le bus qui tirent du Mac sont une source fréquente de panic au réveil. Un hub auto-alimenté (alimenté par le secteur) résout souvent le problème.
4. Mettez à jour le firmware du dock/hub et le Mac vers la dernière version 26.5. Les correctifs de firmware Thunderbolt sont réels.
5. Essayez un port différent ou une connexion directe. Déplacez l'appareil problématique hors d'une chaîne en guirlande.
6. Comme solution de contournement, ajustez le comportement de sommeil pendant l'isolation de l'appareil — par exemple, empêchez l'écran de mettre les disques en veille, ou utilisez pmset pour ajuster le réveil sur réseau si un périphérique réseau réveille le Mac dans un mauvais état. Faites cela uniquement pour gagner du temps ; la vraie solution est d'identifier le périphérique.

Les panics sommeil/réveil sont fastidieux à diagnostiquer précisément car ils nécessitent d'attendre entre les tests, mais la méthode de déconnexion et de reconnexion progressive est fiable. Résistez à l'envie de réinstaller macOS pour un panic sommeil/réveil — c'est un problème de négociation de périphérique bien plus souvent qu'un problème de corruption du système d'exploitation.

CAUSE 4 : Les Éléments Matériels & Entreprise Reconnus par Apple dans la Version 26.5

macOS Tahoe 26.5, publié le 11 mai 2026, incluait des correctifs de stabilité qu'Apple a documentés dans ses notes de version entreprise. Les connaître vous aide à distinguer « déjà corrigé si je mets à jour » de « encore ouvert, nécessite une solution de contournement ».

Ce qu'Apple a reconnu et traité dans la version 26.5 :

• Problèmes de redémarrage sur les MacBook Air M5 et les modèles M5 Pro / Max. Apple a publié des correctifs pour les redémarrages inattendus affectant ces nouvelles machines Apple silicon. Si vous utilisez l'un de ces modèles et rencontrez des panics sur une version antérieure, vous assurer que vous êtes sur la version complète 26.5 (ou ultérieure) est la première étape.
• Redémarrages liés aux extensions réseau de filtrage de contenu. Les redémarrages liés aux extensions réseau de filtrage de contenu — courants dans les environnements gérés/entreprise et dans certains outils VPN/contrôle parental grand public — ont été traités. Cela recoupe la CAUSE 2 : si votre systemextensionsctl list affiche une extension réseau de filtrage de contenu et que vous rencontrez des panics, mettez à jour à la fois macOS et l'application du fournisseur de cette extension.
• Écran noir après la mise à jour. Une condition où certains Mac affichaient un écran noir après la mise à jour a été traitée.

Le cadrage honnête : le fait qu'Apple corrige une classe de redémarrages ne signifie pas que toutes les instances ont disparu. Certains utilisateurs sur le matériel affecté, ou exécutant des extensions particulières, continuent de signaler des redémarrages après la mise à jour — ceux-ci sont signalés par la communauté et traités avec les solutions de contournement dans ce guide (mise à jour complète, réduction du taux de rafraîchissement, audit des extensions, isolation des périphériques), et non avec un correctif garanti par Apple. Donc :

1. Mettez à jour entièrement. Réglages Système → Général → Mise à jour de logiciels. Installez la version 26.5 complète (et tout supplément 26.5.x qui suit).
2. Puis retestez. Une part significative des panics sur le matériel M5 et les configurations de filtrage de contenu disparaissent simplement après la mise à jour complète.
3. S'ils persistent, traitez le rapport de panique comme la source de vérité et orientez-vous vers CAUSE 1/2/3/5 en fonction de ce qu'il indique.

Pour l'image complète de ce qui a été publié dans cette version, y compris les correctifs de sécurité, consultez notre guide complet de mise à jour macOS Tahoe 26.5. Si vous venez d'une version antérieure, les schémas de notre guide de correction des bugs et plantages 26.3 et le guide de dépannage 26.2 fournissent un contexte historique utile sur la façon dont ces problèmes de stabilité ont évolué au cours du cycle Tahoe.

CAUSE 5 : Matériel — RAM, eGPU / Thunderbolt et Thermique

Lorsque les rapports de panique varient à chaque fois, ne mentionnent aucun kext tiers, ne montrent aucun schéma affichage/sommeil, et survivent à une réinstallation propre, vous êtes probablement confronté à un problème matériel. Les panics matériels ont tendance à être incohérents précisément parce qu'ils dépendent de conditions physiques — température, une cellule de mémoire marginale, un connecteur défaillant.

Exécutez Apple Diagnostics

Le test matériel intégré d'Apple est le premier geste :

Apple silicon :

1. Éteignez.
2. Appuyez sur le bouton d'alimentation et maintenez-le jusqu'à l'apparition de « Chargement des options de démarrage », puis relâchez.
3. Appuyez sur Cmd+D pour lancer Diagnostics.

Intel :

1. Éteignez.
2. Allumez et maintenez immédiatement la touche D (ou Option+D pour tester via internet) jusqu'à l'apparition d'une barre de progression ou d'un sélecteur de langue.

Diagnostics s'exécute et renvoie des codes de référence. Les codes commençant par PPM sont liés à l'alimentation ; PPT à la batterie ; NDC/VFD à la caméra/l'affichage ; et plusieurs codes liés à la mémoire pointent vers la RAM. Notez tout code qu'il vous donne — c'est le langage que parlera l'assistance Apple.

RAM (Intel / Mac Pro avec mémoire extensible par l'utilisateur)

Sur les machines où vous pouvez changer la RAM :

• Si vous avez récemment ajouté de la RAM tierce et que les panics ont commencé, remettez-la en place ou supprimez-la. Une mémoire incorrecte ou incompatible est une source classique de panics.
• Testez avec une barrette/une banque à la fois pour isoler un module défaillant.
• Les Mac Apple silicon ont une mémoire unifiée soudée — vous ne pouvez pas la changer, donc une faute mémoire confirmée là-bas nécessite une visite de service.

eGPU et Thunderbolt

• Les GPU externes (principalement les configurations de l'ère Intel) ajoutent un pilote complexe et un chemin d'alimentation. Si vous utilisez un eGPU et voyez des panics dans la pile GPU, déconnectez-le et testez. Le support des pilotes eGPU s'est rétréci au fil des récentes versions de macOS.
• Des liaisons Thunderbolt marginales — un mauvais câble, un bus surchargé — peuvent produire des panics qui semblent aléatoires. Simplifiez la chaîne Thunderbolt et utilisez des câbles de qualité confirmée (cela recoupe la CAUSE 3).

Thermique

• Un Mac qui panique sous une charge soutenue élevée (longs rendus, jeux, compilation) et qui chauffe beaucoup peut atteindre une faute liée à la thermique. Assurez-vous que les ventilations sont dégagées, que la machine est sur une surface dure et que la température ambiante est raisonnable.
• Les panics thermiques répétés sur une machine avec une pâte thermique vieillissante ou un ventilateur défaillant nécessitent une intervention de service.

Si un panic se produit uniquement lorsque votre Mac est également lent et surchargé sous charge, le guide pour corriger un Mac lent couvre la réduction de la charge en arrière-plan et la gestion de la pression des ressources, ce qui peut abaisser le plafond thermique que vous atteignez.

CAUSE 6 : État Système Corrompu — NVRAM, SMC et Réinstallation sur Place

Lorsque vous avez éliminé les écrans, les extensions, les périphériques et le matériel, la dernière catégorie est un état de bas niveau corrompu ou une installation macOS endommagée.

Réinitialiser la NVRAM (principalement Intel)

La NVRAM/PRAM stocke de petits paramètres — affichage, disque de démarrage, certaines valeurs d'alimentation. Sur les Mac Intel, la réinitialiser peut effacer une valeur corrompue provoquant des panics. Il existe deux méthodes :

# Depuis un Mac Intel connecté, effacer la NVRAM, puis redémarrer
sudo nvram -c

Ou au démarrage sur Intel : éteignez, allumez, et maintenez immédiatement Option+Cmd+P+R pendant environ 20 secondes, puis relâchez. Les Mac Apple silicon gèrent la NVRAM automatiquement et n'ont pas de réinitialisation par combinaison de touches manuelle — un redémarrage normal réinitialise l'état pertinent, donc la combinaison de touches ne s'applique pas.

Réinitialiser le SMC (Intel uniquement)

Le System Management Controller gère l'alimentation, la thermique et certains comportements matériels sur les Mac Intel. Un état SMC corrompu peut provoquer des panics liés à l'alimentation et au réveil. La séquence exacte de touches dépend du modèle (T2 vs. non-T2, ordinateur de bureau vs. portable) — suivez les étapes de réinitialisation du SMC spécifiques au modèle d'Apple. Les Mac Apple silicon n'ont pas de SMC à réinitialiser ; une extinction complète (laissez-le éteint environ 30 secondes) et un redémarrage accomplissent l'équivalent.

Réinstaller macOS sur place

Si les panics persistent sans cause claire, réinstaller macOS sur votre système existant remplace les fichiers système sans effacer vos données :

1. Sauvegardez d'abord avec Time Machine (toujours, avant toute réinstallation).
2. Démarrez en Récupération : sur Apple silicon, maintenez le bouton d'alimentation jusqu'à « Chargement des options de démarrage », puis choisissez Options → Continuer ; sur Intel, maintenez Cmd+R au démarrage.
3. Choisissez Réinstaller macOS Tahoe et suivez les instructions. Il s'agit d'une réinstallation sur place — vos fichiers, applications et réglages restent intacts.
4. Si les panics persistent encore après une réinstallation propre dans un état de configuration d'usine propre, les preuves pointent fortement vers le matériel (CAUSE 5) ou une extension réinstallée (CAUSE 2) — auquel cas une visite au Genius Bar est justifiée.

Une réinstallation est une étape importante. Ne la faites pas en premier ; n'y recourez que lorsque le rapport de panique et l'arbre de décision n'ont genuinement pas réussi à identifier une cause.

Quand Aller Chez Apple

Certains panics ne sont pas à vous de résoudre. Apportez le Mac à Apple (ou à un fournisseur de services agréé Apple) quand :

• Apple Diagnostics renvoie un code de référence matériel. Il s'agit d'un problème de composant confirmé.
• Les panics persistent après une réinstallation propre sur place dans une configuration par ailleurs standard — le logiciel a été éliminé.
• Le rapport de panique nomme de manière constante une faute matérielle (machine check, erreurs ECC/mémoire) sans kext tiers.
• Vous êtes sur un MacBook Air M5 / M5 Pro/Max, entièrement mis à jour vers 26.5 ou ultérieur, et vous continuez à avoir des panics — Apple a reconnu des problèmes de redémarrage sur ces modèles, donc votre cas est une donnée pertinente pour eux et peut être couvert.
• Le Mac ne reste pas démarré assez longtemps pour diagnostiquer (boucle de panique) même après les étapes de récupération ci-dessous.

Avant de vous rendre chez Apple, rassemblez les preuves : copiez les rapports de panique les plus récents depuis /Library/Logs/DiagnosticReports/, notez votre code Apple Diagnostics, et écrivez le schéma (quand cela se produit, ce qui est connecté). Un rapport clair et un schéma reproductible accélèrent considérablement une visite d'assistance. Les Mac Apple silicon sont toujours sous garantie pour la génération M5, et les problèmes de redémarrage reconnus sont exactement le type de chose que les équipes de service souhaitent voir documenté.

Résolution des Problèmes Courants

Problème : Mon Mac panique uniquement lors du réveil depuis le sommeil

Solution : Il s'agit d'un panic sommeil/réveil, presque toujours causé par un périphérique. Exécutez pmset -g log | grep -iE 'failure|wake' pour confirmer que les échecs de réveil correspondent aux heures de panique. Déconnectez tous les hubs, docks et disques durs externes, puis laissez le Mac dormir et se réveiller à plusieurs reprises pendant une journée. S'il est stable, reconnectez les appareils un par un jusqu'à ce que le panic réapparaisse — cet appareil (ou son câble/alimentation de hub) est la cause. Alimentez votre hub de manière externe et mettez à jour son firmware ; les hubs alimentés par le bus sont le déclencheur le plus courant.

Problème : Mon Mac panique uniquement lorsque mon moniteur externe est connecté

Solution : Il s'agit d'un panic affichage/GPU, et le correctif est généralement simple. Ouvrez Réglages Système → Moniteurs, sélectionnez le moniteur externe, et réduisez le Taux de rafraîchissement de 240/144/120 Hz à 60 Hz. Utilisez-le pendant une journée. Si les panics s'arrêtent, le taux de rafraîchissement élevé était la cause — vous pouvez ensuite essayer 120 Hz, passer à un câble certifié haute bande passante, vous connecter directement au lieu de passer par un dock, et désactiver HDR. SwitchResX peut verrouiller un mode sûr exact si le panneau Moniteurs masque le taux dont vous avez besoin.

Problème : Mon Mac panique aléatoirement sans schéma évident

Solution : Laissez le rapport de panique décider. Ouvrez le fichier le plus récent dans /Library/Logs/DiagnosticReports/, lisez le panicString, et vérifiez « Kernel Extensions in backtrace ». Un kext tiers là-dedans → mettez à jour ou supprimez ce logiciel et testez en Safe Mode. Pas de kext tiers et les rapports diffèrent à chaque fois → exécutez Apple Diagnostics (Cmd+D au démarrage sur Apple silicon) pour un code matériel. Les panics aléatoires sont généralement soit une extension qui se comporte mal, soit du matériel marginal — le rapport vous dit lequel.

Problème : Mon Mac est bloqué dans une boucle de panique et ne finit pas de démarrer

Solution : Démarrez en Safe Mode d'abord (Apple silicon : maintenez l'alimentation → sélectionnez le disque → maintenez Shift → Continuer en Safe Mode ; Intel : maintenez Shift au démarrage). Le Safe Mode désactive les extensions tierces, donc s'il démarre normalement, un kext est la cause — supprimez-le de là. Si le Safe Mode boucle également, démarrez en Récupération (Apple silicon : maintenez l'alimentation → Options ; Intel : Cmd+R), exécutez Premiers secours dans Utilitaire de disque, et si nécessaire réinstallez macOS sur place. Une boucle persistante même depuis une réinstallation propre pointe vers le matériel — apportez-le à Apple.

Foire Aux Questions

Un kernel panic est-il la même chose qu'un plantage de mon Mac ?

Pas tout à fait. Un kernel panic est l'arrêt et le redémarrage de l'ensemble du système parce que le cœur du système d'exploitation a atteint un état dangereux — vous obtenez une boîte de dialogue « Votre ordinateur a redémarré en raison d'un problème ». Un plantage d'application est un seul programme qui quitte tandis que le reste de macOS continue de fonctionner. Ils écrivent des rapports différents et ont des solutions différentes, alors identifiez lequel vous observez avant de dépanner.

Où exactement se trouve le journal de panique sur macOS Tahoe ?

Les rapports de kernel panic se trouvent dans /Library/Logs/DiagnosticReports/, nommés comme Kernel-2026-05-22-143012.panic ou un fichier panic-full-...ips plus riche sur Apple silicon. Vous pouvez également les ouvrir dans Console.app sous Rapports de plantage / Rapports système. Exécutez ls -lt /Library/Logs/DiagnosticReports/ | grep -i panic dans Terminal pour les lister du plus récent au plus ancien.

Réduire le taux de rafraîchissement de mon moniteur arrêtera-t-il vraiment les redémarrages ?

Si vos panics ne se produisent qu'avec ce moniteur connecté et que le rapport affiche un timeout du watchdog WindowServer/GPU, alors oui — passer de 240/144/120 Hz à 60 Hz est une solution de contournement solide, confirmée par la communauté, qui supprime le chemin de timing marginal. C'est la première chose à essayer pour les panics liés à l'affichage. Vous pouvez ensuite tester 120 Hz avec un câble certifié une fois le système stable.

Apple a-t-il corrigé les bugs de redémarrage dans macOS Tahoe 26.5 ?

Les notes de version entreprise 26.5 d'Apple ont reconnu et traité des correctifs de redémarrage pour les MacBook Air M5 et M5 Pro/Max, les redémarrages liés aux extensions réseau de filtrage de contenu, et une condition d'écran noir après la mise à jour. Cela couvre un ensemble significatif de cas, donc mettez d'abord entièrement à jour. Mais certains utilisateurs signalent encore des panics après — ceux-ci sont signalés par la communauté et nécessitent les solutions de contournement dans ce guide plutôt qu'un correctif garanti.

Comment savoir si un pilote tiers a causé mon panic ?

Ouvrez le rapport de panique et trouvez la section « Kernel Extensions in backtrace ». Si vous voyez des identifiants de bundle qui ne sont pas com.apple.* — le nom d'un fournisseur VPN, antivirus ou virtualisation — cette extension est impliquée. Confirmez en démarrant en Safe Mode (qui désactive les kexts tiers) : si les panics s'arrêtent, le logiciel tiers est la cause. Ensuite, mettez à jour ou désinstallez cette extension.

Devrais-je réinstaller macOS pour corriger les kernel panics ?

La réinstallation est un dernier recours, pas une première étape. Travaillez d'abord l'arbre de décision — taux de rafraîchissement, extensions, périphériques, les éléments 26.5 reconnus, matériel. Seulement après que ceux-ci échouent devriez-vous faire une réinstallation sur place (qui conserve vos données). Sauvegardez toujours d'abord avec Time Machine. Si les panics persistent même après une réinstallation propre, la cause est presque certainement le matériel, et il est temps d'aller chez Apple.

Conclusion

Les kernel panics semblent catastrophiques, mais sur macOS Tahoe 26.5, ils sont généralement traçables à une courte liste de causes — et le rapport de panique vous indique laquelle. Lisez d'abord le panicString et la liste « Kernel Extensions in backtrace » ; ces deux champs orientent la plupart des panics vers le bon correctif. Pour le déclencheur le plus courant de Tahoe 26.5, un taux de rafraîchissement d'écran externe trop élevé, le correctif est aussi simple que de passer à 60 Hz. Pour les panics liés aux extensions, auditez avec kmutil showloaded et systemextensionsctl list, puis prouvez-le en Safe Mode. Pour les panics sommeil/réveil, isolez le périphérique. Assurez-vous d'être entièrement à jour afin que les éléments reconnus par Apple dans la version 26.5 soient déjà traités, et réservez les tests matériels et les réinstallations pour quand le rapport et l'arbre de décision n'ont genuinement pas réussi à identifier une cause.

Diagnostiquez, ne supposez pas — et vous résoudrez la grande majorité de ces redémarrages par vous-même. Pour des lectures complémentaires, consultez notre guide de mise à jour et de sécurité macOS Tahoe 26.5, le guide de diagnostic d'écran externe, et le correctif des plantages d'onglets Safari si votre problème s'avère être au niveau de l'application plutôt qu'un véritable kernel panic.