peopled sature le CPU de votre Mac sous macOS Tahoe ? C'est généralement le widget Contacts

Votre Mac chauffe sans rien faire. L'autonomie estimée a été divisée par deux. Vous ouvrez le Moniteur d'activité, triez par CPU, et en tête de liste se trouve un processus dont vous n'avez jamais entendu parler — peopled — bloqué à 70 ou 80 % et qui y reste. Ou bien c'est contactsd. Ou, sur les machines les plus touchées, accountsd à 180 % avec contactsd et itunescloudd juste derrière. Le quitter ne sert à rien, car vous ne pouvez pas le quitter. Redémarrer aide, mais seulement pendant une heure.

Cela arrive aux utilisateurs de Mac depuis macOS Tahoe 26.4 en mars, cela continue sur 26.5 et 26.6, Apple ne l'a pas reconnu, et la solution la plus fiable ne figure dans aucun des articles du type « redémarrez votre Mac / réinitialisez la NVRAM » qui se classent dans les résultats de recherche. Il s'agit de supprimer un widget.

Ce guide explique ce qu'est peopled (nous avons regardé à l'intérieur), pourquoi un widget le fait entrer en boucle, pourquoi un indicateur de quarantaine sur un dossier dont vous ignoriez l'existence est l'autre déclencheur, et l'ordre exact dans lequel essayer les correctifs.

Points clés

• peopled est le daemon derrière le widget Contacts. Son propre binaire contient des classes nommées WidgetSuggester, WidgetConfigurationReader et CallHistoryFetcher, et son profil sandbox lui donne accès à la base de données de votre historique d'appels. Cette combinaison est à l'origine de la boucle.
• Solution 1 : supprimez tous les widgets Contacts — bureau, Centre de notifications et Centre de contrôle — puis redémarrez. Cela a résolu la majorité des plus de 54 signalements confirmés sur le forum communautaire d'Apple.
• Solution 2 : effacez l'indicateur de quarantaine sur ~/Library/Application Support/CallHistoryDB et forcez l'arrêt de peopled. C'est la solution quand il n'y a aucun widget à supprimer ; elle nécessite l'Accès complet au disque pour Terminal.
• Solution 3 : désactivez Contacts iCloud, puis réactivez-le. Fonctionne pour certains, pas pour tous, et vous prive de la synchronisation tant que c'est désactivé.
• Les pics de contactsd avec un compte Exchange ou Google sont un bug différent, plus ancien, avec le même symptôme mais une solution différente — supprimer le compte ou utiliser un client tiers.
• Apple n'a documenté aucun correctif. Rien dans les notes de version de 26.4.1, 26.5, 26.6 ou 26.6.x n'en fait mention, et les signalements continuent sur 26.5 et au-delà.

Quel processus, exactement

Trois daemons apparaissent dans ces signalements et ils ne sont pas interchangeables. Triez le Moniteur d'activité par % CPU et notez lequel vous concerne.

Processus	À quoi il appartient	Signalement typique	Cause la plus probable
peopled	Framework People — suggestions de widgets, Famille, Temps d'écran, statut	70–80 % en continu depuis 26.4	Widget Contacts + CallHistoryDB illisible
contactsd	Framework Contacts — la base de données du carnet d'adresses et sa synchronisation	Pics à 80 % toutes les 60–90 s, ou en continu	Boucle de synchronisation des contacts iCloud/Exchange/Google
accountsd	Framework Accounts — tous les comptes connectés	180 % avec contactsd et itunescloudd	Boucle d'authentification de compte ; la déconnexion échoue souvent

S'il s'agit de peopled, commencez par la section sur le widget. S'il s'agit uniquement de contactsd, passez directement à la section sur la synchronisation de compte. Si les trois sont concernés avec accountsd en tête, vous êtes dans la variante la moins bien comprise, et la section qui en traite est honnête sur le peu que l'on en sait.

Ce que peopled fait réellement

Le nom évoque les contacts, et les rares guides qui le mentionnent le décrivent comme « gère les données de contact ». C'est globalement vrai et précisément faux, et cette nuance explique pourquoi la solution passe par un widget plutôt que par une réparation du carnet d'adresses.

Nous avons examiné le daemon sur un Mac tournant sous 26.5.2. Il se trouve dans /System/Library/PrivateFrameworks/People.framework/peopled, et sa tâche launchd (/System/Library/LaunchAgents/com.apple.peopled.plist) indique ce qui le réveille. Il n'est pas chargé à la connexion — RunAtLoad est à false. Il est déclenché par des événements :

• Les flux Biome pour missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest et childState
• Deux notifications système : __ABDataBaseChangedByOtherProcessNotification (le carnet d'adresses a changé) et _CalDatabaseChangedNotification (le calendrier a changé)

Ainsi, chaque appel manqué, chaque message, chaque modification de contact et chaque changement de calendrier réveille peopled. Et que fait-il une fois réveillé ? Les chaînes de caractères de son binaire répondent directement à cette question. Parmi les noms de classes Swift :

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

et parmi ses modèles de message de journal :

Event triggered widget refresh: %{private}s, %s
Last widget suggestion date is older 24 hours, suggest widgets
Last widget suggestion date is within 24 hours, do not suggest widgets
error reading widgets configurations: %s
Failed to suggest widgets with error: %s

Il est lié au framework Contacts, au framework CallHistory et à deux frameworks Biome. Sa mission, telle que son propre code la décrit, est de décider quelles personnes mettre en avant dans le widget Contacts et dans les suggestions liées aux personnes, en utilisant vos appels et messages récents comme signal.

C'est ce qui rend le mode de défaillance logique : un daemon réveillé par chaque appel et chaque message, dont le travail est de rafraîchir un widget, et qui a besoin de lire l'historique d'appels pour le faire.

Pourquoi il boucle

Mettons les éléments du fil de discussion communautaire en regard de ce que dit le binaire.

peopled s'exécute dans un bac à sable (sandbox). Son profil, situé dans /System/Library/Sandbox/Profiles/com.apple.peopled.sb, commence par (deny default) puis ouvre des accès spécifiques. En voici deux :

(home-subpath "/Library/CallHistoryDB/")
(home-subpath "/Library/Logs/CallHistory")

Il est ainsi autorisé à lire ~/Library/Application Support/CallHistoryDB/, où macOS conserve la base de données des appels passés et reçus via votre iPhone grâce à Continuity. Ce dossier est également protégé par TCC — sur notre Mac, un ls dessus depuis Terminal renvoie Operation not permitted tant que Terminal n'a pas l'Accès complet au disque — ce qui explique pourquoi les solutions ci-dessous nécessitent cette autorisation.

Passons aux signalements. Le 21 avril, un utilisateur sur le fil de discussion communautaire d'Apple a cité le message noyau trouvé dans Console pendant que peopled tournait en boucle :

Sandbox: peopled … deny(1) file-read-data ~/Library/Application Support/CallHistoryDB

Et le 20 mai, un autre a cité :

failed to open /Users/[user]/Library/Application Support/CallHistoryDB: 1 (Operation not permitted)

L'interprétation qui colle à tout cela : un widget Contacts est installé, donc peopled reçoit l'ordre de le rafraîchir ; rafraîchir signifie récupérer l'historique d'appels ; la récupération est refusée — parce que le dossier a acquis un attribut com.apple.quarantine, ou pour une autre raison de permission que les signalements n'ont pas identifiée précisément — le rafraîchissement échoue, et l'événement suivant (ou la nouvelle tentative) le redéclenche. Un daemon censé tourner quelques millisecondes après un appel manqué tourne alors en continu.

Nous tenons à être précis sur ce qui est établi ici et ce qui ne l'est pas. Les noms de classes, les règles du sandbox et les messages de journal sont directement observables ; nous les avons lus. Que la boucle soit « rafraîchissement du widget, lecture refusée, nouvelle tentative » est une inférence qui correspond à tous les signalements que nous avons vus et aux deux solutions qui fonctionnent. Apple n'a pas confirmé ce mécanisme, et il pourrait exister un second déclencheur — un utilisateur signale que la boucle a démarré après une réorganisation du Centre de contrôle, sans qu'aucun widget Contacts ne soit présent.

Confirmez avant de toucher à quoi que ce soit

Deux minutes d'observation évitent une heure de tâtonnement, et le profil d'utilisation du CPU vous indique quelle solution privilégier.

Observez la forme de la courbe. Dans le Moniteur d'activité, sélectionnez le processus et regardez l'historique du CPU en bas de la fenêtre, ou depuis Terminal :

top -stats pid,command,cpu,time -o cpu -n 5

Un peopled qui reste à plat entre 70 et 80 % correspond à la boucle du widget. Un contactsd qui monte en pic, retombe à zéro, puis remonte une minute plus tard correspond à la boucle de synchronisation. Un CPU soutenu sur les trois daemons à la fois correspond à la variante des comptes.

Vérifiez depuis combien de temps il tourne. peopled vit normalement quelques secondes. Sur notre Mac (sain), il est résident depuis 41 jours à 0,0 % de CPU — résident mais inactif, c'est normal. Ce que vous recherchez, c'est résident et actif :

ps -axo pid,etime,pcpu,comm | grep -E "peopled|contactsd|accountsd"

Cherchez le refus. C'est le test décisif. Ouvrez une seconde fenêtre Terminal et suivez en direct le journal du daemon pendant qu'il tourne en boucle :

log stream --predicate 'process == "peopled"' --info

et, dans la première fenêtre, cherchez dans les dernières minutes la ligne du sandbox citée par les signalements de la communauté :

log show --last 10m --predicate 'eventMessage CONTAINS "Sandbox: peopled"'

Si vous voyez deny(1) file-read-data face à CallHistoryDB, vous êtes dans la variante CallHistoryDB et la Solution 2 est celle qui fonctionnera. Si vous voyez Event triggered widget refresh se répéter sans refus, commencez par la Solution 1. Si le journal est silencieux alors que le CPU est élevé, la boucle se situe dans du code qui ne journalise pas au niveau par défaut ; essayez quand même les solutions dans l'ordre.

Surveillez le système de fichiers, si vous voulez en avoir le cœur net. fs_usage affiche chaque opération de fichier tentée par un processus, y compris celles qui échouent :

sudo fs_usage -w -f filesys peopled

Un écran rempli de tentatives sur CallHistoryDB renvoyant des erreurs, c'est la boucle, visible en temps réel.

Solution 1 : supprimer le widget Contacts

C'est la solution qui a reçu le plus de confirmations, et c'est celle à essayer en premier car elle est réversible et ne nécessite pas Terminal.

Le piège, c'est qu'il existe trois endroits où un widget peut résider sur un Mac sous Tahoe, et qu'il doit disparaître des trois.

Bureau

Faites un clic secondaire (Control-clic) sur le fond d'écran et choisissez Modifier les widgets. Tout widget Contacts présent sur le bureau affiche un bouton de suppression (le signe moins dans le coin) en mode édition ; cliquez dessus. Vous pouvez aussi faire un Control-clic directement sur le widget et choisir Supprimer le widget. Cliquez sur Terminé.

Centre de notifications

Cliquez sur la date et l'heure dans la barre des menus pour ouvrir le Centre de notifications, faites défiler jusqu'en bas, cliquez sur Modifier les widgets. Supprimez-y tout widget Contacts de la même manière — Control-clic puis Supprimer le widget, ou Option-clic sur son bouton de suppression.

Centre de contrôle

C'est celui que l'on oublie le plus souvent, car Tahoe a déplacé les widgets dans le Centre de contrôle et la personnalisation ne se trouve pas dans Réglages Système. Cliquez sur l'icône du Centre de contrôle dans la barre des menus, choisissez Modifier les commandes, et faites glisser tout élément Contacts hors du Centre de contrôle. Cliquez sur Terminé.

Ensuite, redémarrez — pas seulement une déconnexion. Plusieurs résolutions confirmées sur le fil de discussion notent que le CPU n'est retombé qu'après un redémarrage complet.

Une mise en garde supplémentaire venant du même fil, signalée le 31 juillet : pour certains utilisateurs, la boucle est revenue après avoir simplement rouvert la galerie de widgets, même sans y ajouter le widget Contacts. Si vous avez rencontré ce problème, considérez l'éditeur de widgets comme quelque chose à éviter jusqu'à ce qu'Apple corrige le daemon.

Solution 2 : effacer l'indicateur de quarantaine sur CallHistoryDB

Pour les Mac sans aucun widget Contacts, ou pour lesquels sa suppression n'a rien changé, voici la solution à laquelle est arrivé le signalement le plus détaillé techniquement du fil, le 20 mai, et qu'au moins deux autres utilisateurs ont confirmée (« le processus peopled est maintenant à 0 % de consommation CPU », a écrit l'un d'eux le 26 juin).

Étape 1 : accorder l'Accès complet au disque à Terminal

Réglages Système > Confidentialité et sécurité > Accès complet au disque, ajoutez Terminal, et activez-le. Sans cela, chaque commande ci-dessous échouera avec « Operation not permitted » — ce qui, comme il se trouve, est exactement l'erreur que rencontre peopled. Redémarrez Terminal après avoir accordé l'accès.

Étape 2 : examiner le dossier

ls -lan@ "$HOME/Library/Application Support/CallHistoryDB"

L'option @ affiche les attributs étendus. Ce que vous cherchez, c'est com.apple.quarantine sur le dossier ou sur les fichiers CallHistory.storedata qu'il contient. La quarantaine est l'indicateur que macOS appose sur les fichiers téléchargés ; il n'a rien à faire sur une base de données système, et comment il y arrive n'est pas connu — une restauration depuis une sauvegarde et une migration depuis un autre Mac sont les deux pistes plausibles.

Étape 3 : le supprimer

xattr -dr com.apple.quarantine "$HOME/Library/Application Support/CallHistoryDB"

-d supprime l'attribut, -r s'applique récursivement au dossier.

Étape 4 : redémarrer les daemons

sudo killall -9 peopled CallHistorySyncHelper

Les deux seront relancés à la demande. Surveillez le Moniteur d'activité pendant quelques minutes.

Si l'indicateur revient

Un utilisateur du fil a signalé le 17 juillet que la solution avait fonctionné mais que l'indicateur de quarantaine était « réapparu » du jour au lendemain. Si cela vous arrive, quelque chose remet le dossier en quarantaine, et les suspects sont un outil de sauvegarde ou de synchronisation qui le traite comme une nouvelle donnée. Vérifiez ce qui s'exécute la nuit. Autre approche, plus radicale, adoptée par un autre utilisateur : supprimer la base de données et laisser macOS la recréer :

rm -rf ~/Library/Application\ Support/CallHistoryDB

Vous perdez la copie locale de votre historique d'appels sur le Mac. Elle se repeuple ensuite depuis l'iPhone via Continuity. C'est une mesure plus radicale que la suppression d'un attribut, et nous vous conseillons d'essayer d'abord l'attribut.

Solution 3 : basculer Contacts iCloud

Réglages Système > [votre nom] > iCloud > Enregistré sur iCloud > Contacts, désactivez. Attendez une minute, observez le CPU. S'il retombe, réactivez le réglage et voyez s'il reste bas.

Cela fonctionne pour une partie des utilisateurs et c'est le conseil habituel donné dans les fils plus anciens sur le même sujet, remontant à plusieurs années. Cela a aussi un mode d'échec rencontré par un utilisateur le 11 mai : le réglage refusait tout simplement de se désactiver. Si cela vous arrive, déconnectez-vous entièrement d'iCloud (en conservant une copie des données quand on vous le demande), redémarrez, reconnectez-vous. Notez que l'auteur du signalement sur V2EX avec la variante accountsd a essayé exactement cela, et le CPU est remonté immédiatement après la reconnexion.

Si c'est contactsd et que vous avez un compte Exchange ou Google

Celui-ci est antérieur à Tahoe et son mécanisme est plus clair.

contactsd est le daemon du framework Contacts : il possède la base de données du carnet d'adresses et la réconcilie avec chaque compte qui synchronise des contacts. Il effectue aussi une maintenance planifiée — sa tâche launchd enregistre une tâche quotidienne validate-cache qui ne s'exécute que sur alimentation secteur lorsque vous êtes inactif, ainsi qu'une activité récurrente accounts.cleanup. Un CPU bref et occasionnel de contactsd est normal.

Ce qui n'est pas normal, c'est un pic environ toutes les minutes. Un développeur a documenté exactement ce cas sur les Apple Developer Forums en décembre 2025 : sur un M1 Max sous Tahoe 26.1, un compte Office 365 avec les Contacts activés faisait grimper AddressBookManager à 81 % et contactsd à 22–59 % selon un motif répétitif toutes les 60 à 90 secondes — même avec le dossier de contacts Exchange vidé côté serveur, et reproductible sur une installation propre. Le même compte et les mêmes données ne provoquaient pas cela sur un Mac M4 ni sur iOS. Personne chez Apple n'a répondu.

Sa solution de contournement est celle qui fonctionne : supprimer le compte Exchange depuis Réglages Système > Comptes Internet, et si vous en avez besoin, utiliser Outlook, qui ne passe pas par le framework Contacts. Un signalement de février sur le forum communautaire concernant contactsd sur un MacBook Pro 2024 sous 26.3 a reçu le même conseil — arrêter de synchroniser les contacts depuis Exchange et Google, puis tester — et si vous avez à la fois iCloud et un compte Google qui synchronisent des contacts, essayez d'abord de retirer Google.

La variante accountsd

Les signalements les plus sévères — accountsd à 180 % avec contactsd et itunescloudd dans son sillage, sur un MacBook Air M5 sous 26.5.2, décrit sur V2EX en juillet — n'ont pas de solution confirmée. L'auteur du signalement a noté que le problème démarrait à la même heure chaque matin, ce qui pointe vers une tâche planifiée plutôt qu'un événement lié à un widget. Se déconnecter puis se reconnecter n'a pas aidé.

Ce que nous pouvons ajouter : accountsd est le daemon du framework Accounts, invoqué chaque fois que quelque chose a besoin d'un identifiant pour un compte connecté, et itunescloudd est le daemon de la bibliothèque iTunes Cloud (Apple Music / Store). Les trois à la fois signifient que quelque chose demande de façon répétée des identifiants de compte et échoue. Si vous êtes dans cette variante, les solutions ci-dessus valent quand même la peine d'être essayées dans l'ordre, et si aucune ne fonctionne, il vaut la peine de vérifier si un compte en particulier — une ancienne connexion Google ou Exchange, un mot de passe d'application expiré — échoue à l'authentification dans Réglages Système > Comptes Internet. Supprimez tout ce qui affiche un badge d'avertissement.

Pourquoi Tahoe, et pourquoi un widget

Les widgets existent sur Mac depuis des années, il est donc légitime de se demander pourquoi cela a commencé avec 26.4. Deux choses ont changé en même temps.

La première, c'est l'endroit où résident les widgets. Tahoe a introduit les widgets dans le Centre de contrôle, en plus du bureau et du Centre de notifications, et un widget Contacts dans le Centre de contrôle est rafraîchi selon une cadence différente de celui posé sur le bureau — les propres modèles de journal du daemon distinguent une passe quotidienne de « suggestion de widgets » (« Last widget suggestion date is older 24 hours ») des rafraîchissements déclenchés par événement (« Event triggered widget refresh »). Plus de surfaces, plus de demandes de rafraîchissement, plus d'occasions pour qu'un échec soit retenté.

La seconde, c'est que la gestion des erreurs du daemon semble retenter plutôt que temporiser. C'est une inférence que nous tirons du comportement observé, pas quelque chose que l'on peut lire dans le binaire, et c'est le véritable bug : une lecture refusée devrait être journalisée une fois et le rafraîchissement abandonné jusqu'au prochain événement réel. Au lieu de cela, une nouvelle tentative est faite, et les événements continuent d'arriver.

Aucun de ces deux points n'est quelque chose que vous pouvez modifier. Ce que vous pouvez changer, c'est si le widget existe et si la lecture est refusée, ce qui est précisément l'objet des trois solutions.

Une fois le problème réglé

Quelques précautions permettent de conserver le résultat.

Laissez l'Accès complet au disque de Terminal en place si vous avez utilisé la Solution 2, ou révoquez-le délibérément — les deux sont acceptables, mais sachez ce que vous avez choisi, car l'Accès complet au disque pour Terminal est une autorisation très large.

Évitez la galerie de widgets pendant un certain temps. Le signalement du 31 juillet sur le fil est précis : c'est le simple fait de l'ouvrir — sans rien ajouter — qui a relancé la boucle. Si vous voulez ajouter d'autres widgets, faites-le, puis vérifiez ensuite le Moniteur d'activité.

Après la prochaine mise à jour de macOS, revérifiez. Les mises à jour mineures ont réajouté des éléments par défaut du Centre de contrôle pour certains utilisateurs, et le retour discret d'un widget Contacts est la raison la plus probable d'une réapparition du problème.

Envoyez le signalement. Feedback Assistant, catégorie macOS, joignez un sysdiagnose pris pendant que le CPU est élevé (sudo sysdiagnose depuis Terminal, ou Maj-Control-Option-Commande-Point), et collez la ligne de refus du sandbox. Cinq mois de fils de discussion n'ont rien fait bouger ; quelques centaines de signalements Feedback avec la même ligne de journal pourraient y parvenir.

Est-ce corrigé, à ce jour ?

Non, autant qu'on puisse en juger. Nous avons vérifié les notes de mise à jour d'Apple pour Tahoe : 26.4.1 « apporte des corrections de bugs », 26.5 « inclut des améliorations, des corrections de bugs et des mises à jour de sécurité », 26.6 optimise l'index Spotlight, et 26.6.1 ainsi que 26.6.2 sont des versions de sécurité. Aucune ne mentionne les Contacts, les widgets ou le CPU. Sur le fil communautaire, les signalements se poursuivent sur 26.5 (« Le problème existe toujours sur Tahoe 26.5. Apple doit corriger cela au plus vite », le 15 mai) et jusqu'en juillet. Nous n'avons vu aucun signalement, dans un sens ou dans l'autre, pour la 26.6.2, sortie le 17 août.

Si vous êtes sur la bêta de macOS 27 et que vous avez, ou non, constaté ce problème, notre récapitulatif des problèmes connus de la bêta est l'endroit où nous en assurons le suivi.

Ce qui ne sert à rien d'essayer

Réinitialiser la NVRAM ou le SMC. Ni l'un ni l'autre n'a de lien avec les permissions de fichiers d'un daemon en espace utilisateur. À ignorer.

tccutil reset All. Un utilisateur l'a essayé ; cela n'a rien changé, et cela retire toutes les autorisations de confidentialité de toutes les applications du Mac, qu'il faut ensuite passer un après-midi à raccorder. Rien n'indique que TCC soit la couche fautive — le refus dans les journaux vient du sandbox, pas de TCC.

Le mode sans échec. Démarrer en mode sans échec puis revenir en mode normal vide certains caches et a apporté un soulagement temporaire à quelques utilisateurs. C'est un redémarrage avec des étapes supplémentaires, qui ne traite pas la cause.

Désactiver peopled avec launchctl. Vous pouvez faire un launchctl disable sur l'agent, et il cessera de consommer du CPU puisqu'il cessera de s'exécuter. Cela arrêtera aussi le widget Contacts, les suggestions de personnes, la mécanique « ask to buy » de Temps d'écran et tout ce qui en dépend, et sur un Mac protégé par l'intégrité du système, le changement pourrait ne pas survivre à une mise à jour. Non recommandé, sauf comme diagnostic de dernier recours.

Dépannage des problèmes courants

Le Moniteur d'activité affiche vingt copies de contactsd

Nous avons constaté cela nous-mêmes en écrivant cet article : une salve de vingt processus contactsd avec des PID consécutifs, tous enfants de launchd, tous à 0 % de CPU, disparus en moins d'une minute. C'est launchd qui crée des instances par client à la demande, et ce n'est pas le bug. Le bug, c'est un seul processus à CPU élevé qui persiste.

Le widget Contacts a disparu mais peopled reste à 80 %

Vérifiez les trois emplacements — bureau, Centre de notifications, Centre de contrôle — puis passez à la Solution 2. Si vous n'avez jamais eu de widget Contacts, passez directement à la Solution 2.

xattr indique « No such xattr: com.apple.quarantine »

Le dossier n'est pas en quarantaine, ce n'est donc pas votre déclencheur. Essayez la Solution 3, et vérifiez si vous avez un compte Exchange ou Google qui synchronise des contacts.

ls sur CallHistoryDB indique « Operation not permitted » même avec sudo

sudo ne contourne pas TCC. Terminal lui-même a besoin de l'Accès complet au disque, accordé dans Réglages Système, puis doit être relancé.

Le problème est revenu après une mise à jour de macOS

Les mises à jour peuvent réajouter le widget à la disposition par défaut du Centre de contrôle. Revérifiez les trois emplacements.

FAQ

peopled est-il un malware ?

Non. C'est un daemon Apple signé, situé dans /System/Library/PrivateFrameworks/People.framework/peopled sur le volume système scellé. Un processus portant ce nom mais s'exécutant depuis un autre emplacement mériterait d'être examiné ; celui-ci appartient bien à Apple.

Puis-je simplement le tuer ?

sudo killall peopled l'arrête jusqu'à ce que le prochain événement le réveille, ce qui sur un Mac actif se compte en secondes. C'est utile comme diagnostic — si le CPU reste bas après l'arrêt forcé, c'est que le déclencheur a disparu — mais pas comme solution.

Supprimer le widget fait-il perdre quelque chose ?

Seulement le widget. Les Contacts, l'historique d'appels et les suggestions dans Spotlight et Messages continuent tous de fonctionner ; peopled continue de s'exécuter en cas de besoin. Il cesse simplement de recevoir l'ordre de rafraîchir quelque chose qu'il ne peut pas rafraîchir.

Pourquoi le dossier CallHistoryDB nécessite-t-il l'Accès complet au disque pour être lu ?

Il contient votre journal d'appels, que macOS traite comme une donnée personnelle sensible et protège avec TCC, au même titre que Messages et Mail. Cette protection explique pourquoi Terminal a besoin de l'autorisation, et c'est aussi pourquoi un indicateur de quarantaine inattendu y est si perturbateur : le daemon dispose d'un seul chemin étroit et confiné (sandboxé) vers les données, et tout ce qui bloque ce chemin le bloque entièrement.

macOS 27 corrigera-t-il ce problème ?

Inconnu. Apple n'a pas reconnu le problème, et les notes de version de la bêta n'en disent rien. Si le mécanisme correspond à ce que suggèrent les preuves, le correctif est mineur — échouer une fois et arrêter de réessayer — et il pourrait arriver dans n'importe quelle mise à jour mineure sans être mentionné.

Conclusion

Un Mac qui chauffe sans rien faire a presque toujours un processus bloqué en boucle, et cette boucle a presque toujours une cause banale. Ici, il s'agit d'un daemon dont le travail est de garder un widget à jour, réveillé par chaque appel et chaque message, et qui ne peut pas lire l'unique base de données dont il a besoin. Supprimez le widget et les demandes cessent ; corrigez les permissions du dossier et les lectures réussissent. L'une ou l'autre solution brise la boucle.

Si vous trouvez peopled en tête du Moniteur d'activité, parcourez les trois solutions dans l'ordre en redémarrant entre chacune. S'il s'agit de contactsd avec un compte Exchange ou Google, supprimez le compte. Et si les trois processus sont concernés avec accountsd en tête, essayez tout ce qui précède, supprimez tout compte affichant un avertissement, et — puisqu'Apple garde le silence sur ce sujet depuis cinq mois — envoyez le signalement Feedback, avec la ligne de journal du sandbox, qui pourrait enfin permettre de le corriger.

Lecture complémentaire : Mac chaud et batterie qui se vide après macOS 26.6, CPU de WindowServer sur 26.5 avec Liquid Glass, l'application Contacts qui ne fonctionne pas sous Tahoe, le Moniteur d'activité de A à Z, et personnaliser les widgets sous Tahoe.