Jusqu’à présent, le cycle de développement de macOS 27 se déroulait sous des auspices plutôt favorables. Si tout n’était pas encore parfait - bêta oblige —, les premières versions se montraient suffisamment stables pour que certains testeurs les utilisent au quotidien. La troisième bêta vient toutefois rappeler brutalement les risques d’une préversion destinée aux développeurs.
L’alerte a été donnée sur Reddit, où plusieurs utilisateurs de macOS 27 bêta 3 rapportent des anomalies touchant leur volume de données APFS. Les deux premiers cas les plus graves suivent un scénario voisin : le système se fige en pleine utilisation, certaines applications cessent de s’ouvrir et des fichiers locaux deviennent ensuite inaccessibles, voire semblent disparaître.
Ces témoignages convergents sont préoccupants, mais ils ne suffisent pas encore à déterminer l’étendue du phénomène ni à prouver formellement que la bêta 3 en est la cause. Apple n’a, à ce stade, ni reconnu le problème ni mentionné de dysfonctionnement d’APFS dans les notes de version.
Des corruptions parfois impossibles à réparer
Le premier témoignage concerne un MacBook Air M5 passé directement de macOS 26.5.2 à la bêta 3. La machine s’est figée pendant une réunion Zoom avant de redémarrer spontanément. Son propriétaire a ensuite constaté que plusieurs documents stockés en local ne pouvaient plus être ouverts.
La vérification du volume a signalé de nombreux attributs étendus de sécurité inattendus (found unexpected security xattr) avant de déclarer le volume de données corrompu. Ces avertissements ne prouvent pas à eux seuls que le contenu des fichiers est altéré, mais ils témoignent d’incohérences dans les métadonnées associées à certains objets APFS. Dans ce cas précis, même l’environnement de récupération n’est pas parvenu à réparer le volume. L’assistance Apple a finalement recommandé d’effacer le disque et de revenir à macOS 26.5.2.
Un second cas concerne un MacBook Pro M4 Max mis à jour depuis la bêta 2. Selon l’analyse de son propriétaire, une importante série d’écritures de métadonnées aurait été validée par le système sans être correctement enregistrée sur les supports. Les structures de catalogue et les tables d’objets d’APFS auraient alors été endommagées aussi bien sur le volume interne que sur le disque externe utilisé par Time Machine.
L’outil fsck_apfs a échoué à réparer les deux volumes, avec une erreur Tree node repair failed et un code de sortie 8. Le contenu brut d’une grande partie des fichiers semblerait encore présent, mais les structures permettant au système de les retrouver et de les ouvrir seraient endommagées. La corruption simultanée de deux supports distincts, combinée à des indicateurs de santé normaux, rend peu probable une simple défaillance physique du SSD interne.
Tous les résultats rapportés ne sont cependant pas aussi graves. Chez certains testeurs, la vérification a d’abord déclaré le volume corrompu, puis effectué des réparations différées avant de conclure qu’il était sain. D’autres n’avaient remarqué aucun symptôme avant de lancer la commande. Il faut donc distinguer les avertissements automatiquement corrigés des cas dans lesquels fsckapfs échoue réellement.
Time Machine soupçonné, mais probablement pas responsable
La présence de Time Machine dans l’un des deux cas les plus documentés a d’abord conduit l’auteur du fil à soupçonner les sauvegardes et le renouvellement fréquent des instantanés locaux. Cette piste s’est toutefois rapidement affaiblie.
Le propriétaire du MacBook Air M5 affirme ne pas avoir utilisé Time Machine. Plusieurs autres utilisateurs dépourvus de destination de sauvegarde configurée ont également obtenu des résultats anormaux, notamment sur des Mac équipés de puces M1, M3, M4 et M5. L’un d’eux rapporte un code de sortie 8 et l’échec de SOS depuis l’environnement de récupération, sans avoir jamais utilisé Time Machine.
Les témoignages ne permettent donc pas d’en faire la cause du problème. Les opérations de sauvegarde et la gestion des instantanés pourraient éventuellement augmenter la sollicitation des métadonnées ou agir comme facteur déclenchant, mais ce rôle reste entièrement à démontrer.
Une vérification qui n’est pas anodine
À la suite de ces signalements, plusieurs testeurs ont lancé une vérification de leur disque avec l’Utilitaire de disque ou le Terminal. Chez certains, l’opération a duré plusieurs minutes et a donné l’impression que le Mac était complètement bloqué.
Avant toute tentative de réparation, mieux vaut donc commencer par mettre à l’abri les fichiers les plus importants sur un support externe sain. L’auteur du fil recommande également de débrancher les disques non indispensables et d’éviter les manipulations lourdes, comme la suppression massive des instantanés locaux, tant que les données n’ont pas été sécurisées.
Une fois la sauvegarde effectuée, il est possible de lancer SOS depuis l’Utilitaire de disque. Mais les témoignages montrent que l’outil ne parvient pas toujours à réparer les volumes les plus gravement touchés.
Mieux vaut rester à l’écart de cette bêta
Il est encore impossible de savoir si ces incohérences ont été introduites par la troisième bêta ou si elles existaient déjà auparavant sans avoir été détectées. L’absence de vérification réalisée avant la mise à jour empêche notamment d’établir un lien de causalité certain dans chaque cas.
La répétition de résultats similaires sur plusieurs générations de Mac et l’apparition de cas impossibles à réparer constituent néanmoins un signal suffisamment sérieux pour déconseiller l’installation de macOS 27 bêta 3 sur une machine principale. Les utilisateurs restés sous macOS 26 ou sous une bêta antérieure ont tout intérêt à attendre une nouvelle build et des éclaircissements d’Apple avant de poursuivre le cycle de test.
