Le disque plein sans raison apparente ? Vérifiez le dossier de journaux de root

Voici un problème de stockage qui met en échec pratiquement tous les outils auxquels on pense en premier.

Votre Mac indique que le disque est presque plein. Vous ouvrez un analyseur de stockage et additionnez ce qu'il a trouvé — et le total tombe en dessous de ce que macOS annonce comme utilisé, de plusieurs dizaines de gigaoctets. Disk Utility ne signale aucun instantané. Vous supprimez des applications, vous déchargez des photos, vous videz la corbeille, et le chiffre ne bouge presque pas. Redémarrer aide pendant une heure, puis l'espace disparaît à nouveau.

Les fichiers sont bien réels. Vos outils ne peuvent pas les voir parce qu'ils se trouvent dans /private/var/root — le dossier personnel du compte root — et chacun de ces outils s'exécute en tant que vous.

Sur les Mac où ce problème frappe le plus fort, l'essentiel tient à une seule chose : des fichiers journaux écrits par un daemon système appelé rtcreportingd, en quantités qui atteignent plusieurs dizaines de gigaoctets. Michael Tsai a documenté le 21 août 2026 un cas où /private/var/root/Library/Logs consommait à lui seul 74 Go sur un MacBook Air M4, et où le dossier était remonté à 27 Go en une seule journée après avoir été vidé.

Les journaux ne sont pas la maladie. Ils sont ce à quoi ressemble un daemon bloqué quand personne ne regarde le thermomètre. Cet article explique comment trouver l'espace occupé, comment le récupérer sans commettre l'erreur classique qui réduit toute la manœuvre à néant, et comment identifier le processus qui le génère réellement.

Points clés à retenir

• /private/var/root est invisible pour tout ce qui s'exécute sous votre compte utilisateur. Nous avons confirmé sur macOS 26.5.2 que ls /private/var/root renvoie Permission denied. Les analyseurs de stockage, le Finder et les chiffres d'utilisation de Disk Utility passent tous à côté de ce qu'il contient.
• rtcreportingd est un véritable daemon système Apple qui s'exécute en tant que root. Nous avons vérifié que son job launchd déclare UserName => root, ce qui explique précisément pourquoi ses journaux atterrissent dans le dossier personnel de root plutôt que dans le vôtre.
• Les tailles observées atteignent plusieurs dizaines de gigaoctets, et repoussent vite. 74 Go dans un cas documenté, de retour à 27 Go en une journée après suppression, parce que la cause sous-jacente tournait toujours.
• L'erreur classique gâche tout le travail. Supprimer des fichiers avec un outil graphique lancé sous sudo les déplace vers la corbeille de root, invisible. L'espace n'est pas récupéré. Il faut supprimer immédiatement, ou vider la corbeille de root.
• Cherchez un client de synchronisation bloqué. Dans le cas documenté, rtcreportingd et fileproviderd étaient tous deux épinglés près de 100 % de CPU, et quitter Dropbox a stoppé les deux. fileproviderd est le processus macOS qui héberge les extensions File Provider de stockage cloud.
• Ne supprimez pas au hasard des éléments dans /private/var/root. Les journaux et les caches peuvent être supprimés sans risque. D'autres éléments présents là ne le peuvent pas, et cet article précise clairement ce qui relève de l'une ou l'autre catégorie.

Pourquoi vos outils de stockage ne le voient pas

Avant la solution, le mécanisme — parce que le comprendre est ce qui vous évite de courir après la mauvaise piste la prochaine fois.

Root a un dossier personnel, et les daemons s'en servent

Sur macOS, le dossier personnel du compte root est /private/var/root. La plupart des gens supposent qu'il est essentiellement vide et qu'on n'y touche que lorsqu'on lance Terminal depuis macOS Recovery. Cela n'est plus vrai depuis des années. Les daemons système qui s'exécutent en tant que root et souhaitent stocker un état, des caches ou des journaux les écrivent là, avec la même structure Library que celle utilisée par votre propre dossier personnel :

/private/var/root/Library/Logs
/private/var/root/Library/Caches

Vous pouvez confirmer que ce dossier vous est interdit en une seule commande. Sur un Mac où Terminal ne dispose pas de privilèges élevés :

ls /private/var/root

Nous avons exécuté exactement cette commande sur macOS 26.5.2 (build 25F84) et obtenu :

ls: /private/var/root: Permission denied

Il s'agit d'un simple refus de permission Unix — le dossier personnel de root est restreint en mode à root. Ce n'est pas une protection de confidentialité TCC et ce n'est pas quelque chose que Full Disk Access peut corriger. Un analyseur de stockage lancé depuis le Dock s'exécute en tant que vous, il parcourt donc le système de fichiers en tant que vous, et tout ce qui se trouve sous ce dossier constitue un trou dans sa cartographie.

Voilà pourquoi les chiffres ne concordent pas

Le symptôme que les gens décrivent est « les totaux de mon outil de stockage ne concordent pas », et voici pourquoi. Dans le cas documenté, les totaux par dossier d'OmniDiskSweeper arrivaient à environ 90 Go de moins que ce que macOS indiquait comme utilisé.

Il vaut la peine de distinguer ceci des autres raisons pour lesquelles les chiffres d'espace libre d'un Mac ne concordent pas, car il y en a plusieurs et une seule correspond à ce bug précis.

Howard Oakley a détaillé l'arithmétique générale le 21 août 2026, et les chiffres relevés sur son propre Mac mini illustrent le propos :

Source	Espace signalé comme utilisé sur le même volume
Différence du conteneur diskutil apfs list	837,101 Go
Somme de la capacité consommée par volume	837,027 Go
Informations du volume dans le Finder	826,67 Go
Disk Utility	814,03 Go

Quatre outils, quatre chiffres, un écart d'environ 23 Go, et rien d'anormal. Les différences proviennent de la comptabilité conteneur-versus-volume, de l'espace purgeable et du comportement des fichiers spéciaux APFS :

• Conteneur versus volume. Un conteneur APFS héberge plusieurs volumes qui partagent l'espace libre. « L'espace libre sur Macintosh HD » et « l'espace libre dans le conteneur » sont deux questions différentes avec des réponses différentes.
• Espace purgeable. macOS marque certains contenus comme supprimables à la demande — caches, certains instantanés, certains contenus téléchargés. L'aide de Disk Utility indique elle-même que « vous ne pouvez pas supprimer manuellement les fichiers désignés comme purgeables, mais macOS les supprime lorsque l'espace est requis ». Oakley a mesuré 47,04 Go purgeables sur son volume Data.
• Fichiers spéciaux. Les fichiers clonés APFS partagent leur stockage jusqu'à ce qu'ils divergent ; les fichiers creux (sparse) ne stockent que leurs données non nulles ; certains fichiers système sont compressés ; les fichiers dataless conservent leurs données dans le cloud et se matérialisent à la demande. La comptabilité de l'espace libre reflète ce qui est sur le disque à l'instant présent.

Rien de tout cela ne produit un écart persistant, croissant et inexpliqué de 90 Go. Si votre écart est faible et stable, il s'agit d'une comptabilité normale. S'il est important et croît alors que le Mac reste inactif, quelque chose écrit des fichiers que vous ne pouvez pas voir.

Pour les confusions de stockage les plus courantes — les données système qui ne diminuent pas, les instantanés qui ne se libèrent pas — nous les traitons séparément dans Les données système occupent un espace énorme sur Mac et le guide de gestion du stockage macOS. Vérifiez d'abord ces pistes-là. Cet article traite du cas où ces explications ne conviennent pas.

Ce qu'est réellement rtcreportingd

Soyons honnêtes quant aux limites de cet article, car Internet va bientôt se remplir d'explications péremptoires sur un daemon qu'Apple n'a jamais documenté.

Ce que nous avons vérifié directement, sur macOS 26.5.2 (build 25F84) :

L'exécutable existe à l'emplacement /usr/libexec/rtcreportingd et pèse environ 1,45 Mo. Son job launchd se trouve dans /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist, et se lit ainsi :

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

Vérifiez-le vous-même sur votre Mac — le plist est lisible par tout le monde :

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => root explique à lui seul où vont les journaux. Un daemon qui s'exécute en tant que root et écrit dans ~/Library/Logs écrit dans /private/var/root/Library/Logs. Il n'y a rien d'exotique là-dedans.

Le binaire est écrit en Swift, et les noms de ses classes internes sont visibles avec strings. On y trouve BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity et — notez celui-ci — CacheCleanupActivity. Ses noms de services Mach incluent com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor et com.apple.rtcreportingd.storebag.

Ce que nous n'allons pas affirmer, c'est ce que « RTC » signifie ou ce que le daemon rapporte précisément. Apple ne le documente pas, et nous n'allons pas inventer le développement d'un acronyme pour le présenter comme un fait. Ce que les noms de classes permettent, c'est une description modeste : il s'agit d'un service de rapport ou de télémétrie qui dialogue avec un backend Apple via HTTP, met en cache un état localement, surveille la disponibilité du chemin réseau, et dispose d'une activité planifiée pour nettoyer son propre cache.

Ce dernier détail est le plus intéressant. Le daemon dispose d'une logique de nettoyage. Quand ses journaux grossissent jusqu'à plusieurs dizaines de gigaoctets, l'interprétation raisonnable n'est pas « Apple a oublié de faire tourner les journaux », mais plutôt « quelque chose génère des événements plus vite que le daemon ne peut les traiter et les nettoyer ». Ce qui pointe vers ce qui génère ces événements.

Pour être clair sur la limite de cette analyse : il s'agit d'une inférence tirée des noms de classes, pas d'une affirmation sur l'implémentation d'Apple. Considérez-la comme une hypothèse qui se trouve correspondre au comportement observé.

Trouver l'espace occupé

Vous aurez besoin de sudo pour tout ceci, et vous devriez lire chaque commande avant de l'exécuter.

1. Confirmer que l'écart existe

D'abord, ce que macOS pense être utilisé :

df -h / /System/Volumes/Data

Sur un Mac récent, vous obtenez deux lignes, car le volume système est un instantané scellé en lecture seule et vos données vivent sur un volume distinct dans le même conteneur. Sur notre Mac de test :

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

Notez que les deux lignes indiquent la même Size et le même Avail — c'est l'espace libre du conteneur partagé, pas un quota par volume. C'est la distinction conteneur-versus-volume évoquée plus haut, rendue concrète.

Vérifiez ensuite les instantanés, pour pouvoir les écarter :

diskutil apfs listSnapshots /System/Volumes/Data

Et la vue du conteneur :

diskutil apfs list

Si les instantanés sont minimes et que la capacité utilisée du conteneur dépasse largement ce que votre analyseur de stockage a trouvé, vous avez un problème de fichiers invisibles.

2. Mesurer le dossier personnel de root

Voici la commande qui le trouve :

sudo du -h -d 2 /private/var/root/

-d 2 limite la profondeur à deux niveaux, ce qui suffit pour voir si Library/Logs ou Library/Caches est le coupable sans attendre un parcours complet. Comptez une à deux minutes sur une machine avec un gros coupable.

Pour une vue triée des pires coupables un niveau plus bas :

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

Sur un Mac sain, ces totaux sont faibles — des mégaoctets, pas des gigaoctets. Si /private/var/root/Library/Logs renvoie un chiffre suivi de « G » avec plus d'un chiffre devant, c'est votre espace manquant.

3. Voir ce qu'il y a à l'intérieur

Avant de supprimer quoi que ce soit, regardez :

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

Dans le cas documenté, le contenu était « presque entièrement issu de RTCReporting ». Si le vôtre est dominé par autre chose, cela change ce que vous devez faire — la démarche diagnostique de cet article reste valable, mais le coupable sera un sous-système différent.

4. Une alternative graphique

Si vous préférez visualiser cela dans une fenêtre, OmniDiskSweeper est gratuit et c'est ce qui a fait surgir le problème dans le rapport original. Le point important est que vous devez le relancer avec des privilèges élevés pour qu'il voie le dossier personnel de root. Lancé normalement, il vous montrera la même image incomplète que tous les autres outils.

Notre comparatif d'analyseurs de stockage couvre les options, mais sachez que la même limitation s'applique à tous : si l'outil ne s'exécute pas en tant que root, cet espace lui est invisible.

Le récupérer — et l'erreur qui gâche tout le travail

Voici le piège, et c'en est un bon.

Si vous supprimez ces fichiers avec un outil graphique lancé sous sudo, l'outil fait ce qu'il fait toujours : il les déplace vers la corbeille. Mais comme le processus s'exécute en tant que root, il s'agit de la corbeille de root, dans /private/var/root/.Trash, qui n'apparaît pas dans votre Dock et que vous ne penserez jamais à vider. Les fichiers restent sur le disque. Votre espace libre ne change pas. Vous en concluez que la suppression n'a pas fonctionné.

Dans OmniDiskSweeper spécifiquement, maintenez Option pour transformer Supprimer en Supprimer immédiatement.

Depuis Terminal, supprimez directement le contenu des journaux :

sudo rm -rf /private/var/root/Library/Logs/*

Lisez cette commande avant de l'exécuter. Elle supprime le contenu du dossier Logs de root et rien d'autre. Ne raccourcissez pas le chemin. N'ajoutez pas d'espace avant la barre oblique.

Vérifiez ensuite si quelque chose se trouve dans la corbeille de root suite à une tentative précédente :

sudo du -sh /private/var/root/.Trash

Et si c'est le cas :

sudo rm -rf /private/var/root/.Trash/*

Les caches présents dans le dossier personnel de root peuvent eux aussi généralement être vidés sans risque — ils sont, par définition, régénérables :

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

Ce qu'il ne faut pas toucher. Ne supprimez pas /private/var/root lui-même. Ne supprimez pas /private/var/root/Library en bloc. Ne retirez pas les trousseaux, préférences ou tout autre élément que vous ne reconnaissez pas. Les journaux et les caches sont les catégories sûres ; tout le reste appartient à un composant système qui l'a placé là pour une raison.

Redémarrez ensuite. Puis revérifiez avec df -h pour confirmer que l'espace est bien revenu.

Trouver maintenant ce qui en est la cause

Si vous vous arrêtez à la suppression, l'espace revient puis repart. Dans le cas documenté, il était de retour à 5 Go quelques minutes après un redémarrage, et à 27 Go en une journée.

Surveillez le CPU

Ouvrez le Moniteur d'activité, triez par % CPU, et repérez deux processus :

• rtcreportingd — le daemon qui écrit les journaux
• fileproviderd — le processus macOS qui héberge les extensions File Provider de stockage cloud

Dans le cas documenté, les deux étaient épinglés près de 100 % de CPU en continu, sur un Mac inactif.

Depuis Terminal :

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

Ces deux processus existent et s'exécutent sur tout Mac sain — nous avons confirmé qu'ils tournaient tous les deux sur notre machine de test, qui n'a aucun problème de stockage. Leur présence est normale. Leur usage CPU soutenu ne l'est pas. Quelques pourcents pendant qu'une synchronisation est en cours est attendu. Se maintenir à 90-100 % avec le Mac inutilisé est le signal d'alerte.

Observez les journaux grossir

La confirmation la plus directe est de mesurer deux fois :

sudo du -sh /private/var/root/Library/Logs

Attendez dix minutes avec le Mac inactif, et relancez la commande. Sur un Mac sain, le chiffre ne bouge pas de manière significative. S'il augmente sensiblement alors que vous ne faites rien, quelque chose tourne en boucle.

Suspectez d'abord la synchronisation cloud

fileproviderd est l'indice révélateur. C'est le processus système qui héberge les extensions File Provider — le mécanisme moderne que Dropbox, OneDrive, Google Drive, Box et iCloud Drive utilisent tous pour présenter les fichiers cloud dans le Finder. S'il consomme du CPU en continu, l'une de ces extensions est bloquée.

Dans le cas documenté, le client en cause était Dropbox, sur un Mac où il se comportait mal depuis environ un an — ne conservant pas les fichiers hors ligne comme configuré, et semblant se synchroniser en permanence alors que rien n'avait changé. Quitter Dropbox a immédiatement stoppé l'usage CPU et la croissance des journaux.

Pour tester cela sur votre propre Mac, quittez vos clients de synchronisation un par un et observez. Quittez le client complètement — icône dans la barre de menu, Quitter — plutôt que de mettre la synchronisation en pause, car une extension mise en pause peut rester chargée.

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

Si quitter un client fait retomber les deux processus au repos, vous avez trouvé le coupable.

Que faire à propos du client de synchronisation

Les options, à peu près dans l'ordre d'effort :

1. Mettez-le à jour. Les bugs d'extensions File Provider sont courants et fréquemment corrigés. Vérifiez la présence d'une mise à jour avant toute autre chose.
2. Déconnectez-vous puis reconnectez-vous. Cela reconstruit l'état local de l'extension et résout un nombre surprenant de cas de synchronisation bloquée.
3. Retirez et réinstallez le client. Plus perturbant mais plus complet.
4. Déplacez les données ailleurs. Dans le cas documenté, le dénouement a été une migration vers iCloud Drive, après que Dropbox se soit révélé incapable de télécharger les fichiers de manière fiable pour la migration — l'auteur a fini par télécharger le dossier depuis l'interface web de Dropbox à la place. iCloud Drive a ensuite « tout téléversé rapidement puis s'est stabilisé dans un état sans usage CPU ».

Ce dernier point mérite d'être signalé honnêtement : migrer entre fournisseurs cloud lorsque le client source est cassé est réellement pénible, et l'interface web peut être votre chemin d'exportation le plus fiable. Notre guide iCloud Drive couvre le côté destination, et si iCloud Drive lui-même se comporte mal, le bug de téléchargement automatique d'iCloud Drive est un problème distinct déjà connu.

Nous n'affirmons pas que Dropbox soit spécifiquement en tort. C'est le client du cas documenté. N'importe quelle extension File Provider peut se bloquer, et le diagnostic est le même quel que soit le client utilisé.

Les autres endroits où le stockage se cache

Le dossier personnel de root est celui que presque personne ne vérifie, mais ce n'est pas le seul endroit où un outil s'exécutant à votre niveau d'utilisateur se révèle insuffisant. Si votre écart ne se trouve pas dans /private/var/root, passez en revue les points suivants avant de conclure que les chiffres mentent.

Les données d'autres daemons appartenant à root. /private/var/root est le dossier personnel de root, mais d'autres composants système écrivent aussi sous /private/var/db, /private/var/folders et /Library/Logs. Mesurez-les de la même façon :

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

/private/var/folders héberge des conteneurs temporaires et de cache par utilisateur et peut légitimement atteindre plusieurs gigaoctets. Il est géré par macOS et devrait généralement rester intouché ; un redémarrage nettoie les parties volatiles.

Les instantanés Time Machine locaux. Ce sont la cause la plus souvent accusée, et la moins souvent réellement coupable. Vérifiez plutôt que de supposer :

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

Si les instantanés sont réellement en cause, macOS les allège automatiquement sous pression d'espace, et les cas plus complexes sont couverts dans notre guide de dépannage Time Machine.

Les dossiers personnels d'autres utilisateurs. Évident une fois dit, invisible en pratique — un second compte sur le Mac avec 200 Go de vidéos n'est pas quelque chose que votre outil de stockage vous montrera en s'exécutant en tant que vous. sudo du -h -d 1 /Users répond en une ligne.

Des fichiers maintenus ouverts par un processus en cours d'exécution. De l'espace supprimé mais non libéré, parce qu'un processus détient toujours le descripteur de fichier. Cela se manifeste par un écart qui disparaît après un redémarrage :

sudo lsof / 2>/dev/null | grep -i deleted | head

Le stockage local de Mail, les sauvegardes d'appareils iOS et Xcode. Les trois dossiers classiques, volumineux et oubliés, sur le Mac d'un développeur ou d'un gros utilisateur de Mail :

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

Ceux-ci sont tous lisibles en tant que votre propre utilisateur, donc un analyseur de stockage les trouvera — ils se perdent simplement dans une longue liste. À vérifier avant d'escalader vers sudo.

Des fichiers placeholder cloud qui se sont matérialisés. Si vous utilisez un réglage « conserver les fichiers en ligne uniquement » dans un client de synchronisation, un bug ou une recherche en texte intégral peut discrètement tout télécharger. C'est la même catégorie de panne que celle traitée dans cet article, et cela se manifeste généralement par une croissance régulière du dossier de synchronisation lui-même.

Ce problème est-il fréquent ?

Réponse honnête : nous ne le savons pas, et personne d'autre publiant à ce sujet ne le sait non plus.

Ce qui existe dans les archives publiques, c'est un témoignage de première main avec des chiffres précis et une solution précise, un fil de discussion sur l'Apple Support Community à propos du stockage RTCReporting, et un fil Reddit d'utilisateurs se demandant ce qui occupait leur stockage. C'est suffisant pour établir que le problème est réel et reproductible, et insuffisant pour dire quelle proportion de Mac est concernée.

Ce que nous pouvons dire d'après nos propres vérifications : rtcreportingd s'exécute sur un Mac standard sans problème de stockage, ses journaux y sont anodins, et le daemon dispose d'une logique de nettoyage qui fonctionne visiblement la plupart du temps. Il s'agit d'un mode de défaillance, pas d'un comportement par défaut. Si les chiffres de stockage de votre Mac concordent, vous n'avez rien à corriger.

Apple n'a publié aucun document de support à ce sujet, ne l'a pas reconnu, et n'a pas déployé de correctif documenté. Si vous rencontrez ce problème, envoyer un rapport à Apple vaut les cinq minutes que ça prend — un problème non signalé reste non reconnu.

Résolution des problèmes courants

sudo du prend un temps interminable

C'est normal sur une arborescence volumineuse ou fortement fragmentée. Utilisez d'abord -d 1 pour trouver quel dossier de premier niveau est volumineux, puis descendez seulement dans celui-ci. Évitez de lancer du sur l'ensemble du disque quand vous connaissez déjà le dossier qui vous intéresse.

J'ai supprimé les journaux mais l'espace libre n'a pas changé

Le problème de la corbeille. Vérifiez sudo du -sh /private/var/root/.Trash et videz-la avec sudo rm -rf /private/var/root/.Trash/*. Cela couvre presque tous ceux qui ont utilisé un outil graphique.

La seconde possibilité est qu'un processus détient encore les fichiers supprimés ouverts, auquel cas l'espace n'est libéré qu'à la fermeture du processus. Redémarrez le Mac et vérifiez à nouveau.

L'espace est revenu en un jour

C'est attendu, si vous n'avez pas trouvé la cause. Supprimer les journaux traite le symptôme. Passez à l'étape du Moniteur d'activité et trouvez ce qui boucle.

rtcreportingd utilise du CPU mais je n'ai aucun client de synchronisation cloud

Alors le déclencheur est autre chose. Triez le Moniteur d'activité par CPU et regardez ce qui d'autre est actif. Vérifiez le journal unifié pour l'activité propre du daemon :

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

Sachez que les requêtes du journal unifié ne renvoient que ce qui a réellement été écrit, et que les données de journal expirent — une requête sur une longue fenêtre peut légitimement ne rien renvoyer.

Disk Utility First Aid dit que le disque va bien

C'est normal. Il ne s'agit pas d'une corruption du système de fichiers. First Aid vérifie la cohérence des métadonnées ; un dossier plein de fichiers volumineux mais valides est parfaitement cohérent.

Puis-je simplement désactiver rtcreportingd ?

Nous ne le ferions pas. C'est un daemon système Apple sur un Mac avec System Integrity Protection, et désactiver des daemons de lancement système pour contourner un symptôme tend à produire un second problème, plus obscur, plus tard. Corrigez plutôt le processus qui le déclenche. Si le daemon se comporte mal sans déclencheur identifiable, c'est un bug Apple qui mérite d'être signalé plutôt que contourné.

Mon Mac manque d'espace et j'ai besoin de place maintenant

Des gains immédiats et sûrs pendant que vous diagnostiquez : videz votre propre corbeille, videz la corbeille de root comme ci-dessus, supprimez le contenu des journaux de root, et vérifiez sudo du -h -d 1 /private/var/root/Library/Caches. Combinés, ces gestes libèrent souvent assez d'espace pour rendre le Mac à nouveau utilisable pendant que vous cherchez la cause. Notre guide sur les échecs de mise à jour causés par un manque d'espace couvre la marche à suivre si cela bloque spécifiquement une mise à jour macOS.

FAQ

Qu'est-ce que /private/var/root ?

C'est le dossier personnel du compte root sur macOS. Il n'est lisible que par root, ce qui explique pourquoi les outils s'exécutant sous votre compte utilisateur ne peuvent pas voir à l'intérieur. Les daemons système qui s'exécutent en tant que root y stockent journaux, caches et états, en utilisant la même structure Library que votre propre dossier personnel.

Pourquoi le Finder ou mon application de stockage ne voient-ils pas ces fichiers ?

Parce qu'ils s'exécutent en tant que vous, et que les permissions Unix du dossier excluent votre utilisateur. Ce n'est pas une protection de confidentialité que Full Disk Access peut lever — ce sont des permissions de fichiers ordinaires. Un outil graphique doit être relancé avec des privilèges élevés pour parcourir ce dossier.

Qu'est-ce que rtcreportingd ?

Un daemon système Apple situé à /usr/libexec/rtcreportingd, lancé par com.apple.rtcreportingd et s'exécutant en tant que root. Apple ne le documente pas. Sa structure interne indique un service de rapport qui communique avec un backend Apple via HTTP et maintient un cache local. Il existe sur les Mac sains et n'est pas en soi un problème.

Est-ce un logiciel malveillant ?

Non. C'est un binaire Apple dans /usr/libexec, lancé par un daemon de lancement à l'intérieur du volume système scellé. Vous pouvez confirmer sa signature :

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

Quel espace est normal pour le dossier Logs de root ?

Sur un Mac sain, c'est faible — un dossier que vous ne devriez même pas remarquer. Si sudo du -sh /private/var/root/Library/Logs renvoie un chiffre en dizaines de gigaoctets, c'est le problème. Il n'existe pas de seuil officiel Apple ; le test pratique consiste à voir s'il croît alors que le Mac est inactif.

Une application de nettoyage Mac va-t-elle corriger cela ?

Presque certainement pas, pour la même raison que votre analyseur de stockage a manqué le problème : à moins que le nettoyeur n'escalade ses privilèges et ne parcoure spécifiquement le dossier personnel de root, il ne peut pas voir les fichiers. Et même un nettoyeur qui les supprimerait n'empêcherait pas leur retour, car la cause est un processus en boucle plutôt qu'une accumulation de fichiers inutiles.

Cela n'affecte-t-il que certains Mac ou certaines versions de macOS ?

Il n'y a pas assez de données publiques pour le dire. Le cas documenté concernait un MacBook Air M4. Nous avons vérifié le daemon et le comportement des permissions sur macOS 26.5.2. Rien dans le mécanisme n'est spécifique à une puce ou à une version de macOS — root dispose d'un dossier personnel depuis que macOS existe.

Dois-je signaler cela à Apple ?

Oui, si vous le rencontrez. Incluez la sortie de sudo du -h -d 2 /private/var/root/, les chiffres de CPU pour rtcreportingd et fileproviderd, et quel client de synchronisation, une fois arrêté, a résolu le problème. Apple n'a rien publié à ce sujet, et ce sont des rapports précis qui font évoluer cette situation.

Conclusion

La raison pour laquelle ce problème est si frustrant, c'est que chaque instinct que vous avez sur le stockage d'un Mac se trompe pour ce cas précis. Les fichiers ne sont pas dans un dossier que vous pouvez trouver. Ce ne sont pas des instantanés. Ce ne sont pas des données système au sens où le panneau Stockage l'entend. Supprimer des applications n'aide pas, les chiffres ne concordent pas, et le seul outil qui vous le montrerait est celui que vous n'avez pas pensé à lancer avec sudo.

Une fois que vous savez où regarder, c'est l'affaire de dix minutes : mesurez /private/var/root avec du, supprimez les journaux, videz la corbeille de root, puis — la partie qui compte vraiment — surveillez le Moniteur d'activité jusqu'à trouver le processus qui les remplit à nouveau. Neuf fois sur dix, avec fileproviderd juste à côté de rtcreportingd dans la liste du CPU, il s'agit d'un client de synchronisation cloud discrètement défaillant depuis des mois.

Et si les chiffres de stockage de votre Mac divergent de quelques gigaoctets plutôt que de quatre-vingt-dix, détendez-vous. C'est juste APFS qui se comporte comme APFS, et l'arithmétique de Howard Oakley explique tout cela.

Lecture complémentaire : Les données système occupent un espace énorme sur Mac et ne diminuent pas · Gestion et optimisation du stockage macOS · Comparatif des outils d'analyse de stockage Mac · Guide complet iCloud Drive · Mise à jour macOS bloquée : pas assez d'espace

Sources : Michael Tsai, « Huge RTCReporting Logs and Dropbox », 21 août 2026 · The Eclectic Light Company, « The arithmetic of free space », 21 août 2026 · fil de discussion Apple Support Community 254838127 (RTCReporting) · Apple, Aide de Disk Utility (espace purgeable) · Vérification locale sur macOS 26.5.2 (build 25F84), 22 août 2026, à l'aide de ls, plutil, strings, df et ps.