dasd et appstoreagent : forte charge CPU la nuit sur macOS 27, la solution

Vous fermez l'écran avec une batterie en bon état et, le lendemain matin, le Mac est tiède, les ventilateurs ont visiblement travaillé, et la charge a baissé bien plus qu'une nuit de veille ne devrait le permettre. Si cela a commencé juste après votre mise à niveau vers macOS 27 Golden Gate, il existe un suspect précis et bien documenté : deux processus d'arrière-plan, dasd et appstoreagent, enfermés dans une boucle serrée, d'après les signalements chaque nuit à partir de minuit. Ce guide explique ce que sont ces deux processus, comment le planificateur d'arrière-plan d'Apple décide de leur exécution, comment prouver que c'est bien ce bug que vous observez (et non l'une des nombreuses autres causes qui échauffent un Mac la nuit), quel est le contournement exact de la communauté et comment l'annuler, et enfin ce que nous pouvons et ne pouvons pas affirmer quant à une éventuelle correction dans macOS 27.0.1. Tout ce qui suit provient de signalements publics et de documentation ; lorsqu'un point n'est pas confirmé, nous le disons.

Points clés

• Le bug est signalé, reproductible par plusieurs personnes, et pas encore reconnu par Apple. Un fil MacRumors ouvert le 27 septembre décrit des pics de appstoreagent et dasd à minuit sur deux MacBook, et d'autres membres rapportent la même chose sur un Mac Studio et un MacBook Pro. Apple n'a publié aucun problème connu à ce sujet.
• La cause signalée est une tâche Apple Arcade qui ne repousse jamais sa propre échéance. Des articles indépendants indiquent qu'une préférence nommée ArcadePayoutResetDate dans com.apple.appstored reste bloquée dans le passé, de sorte que le planificateur relance sans cesse la tâche, d'après les signalements 70 à 100 fois par seconde.
• Vous pouvez le confirmer en deux minutes sans rien modifier. Triez les processus par CPU, lisez la préférence et jetez un œil au journal unifié avec un prédicat. Si la date est dans le passé et que le journal est saturé, c'est votre bug.
• Le correctif de la communauté tient en un defaults write suivi de killall appstoreagent. Il repousse la date dans le futur. C'est un contournement, il est réversible, et il tiendrait aussi longtemps que la date choisie, par exemple sept jours.
• Nous n'avons pas pu vérifier que la version 27.0.1 le corrige. La mise à jour 27.0.1 d'Apple (build 26A434) est décrite comme corrigeant des bugs non précisés. Personne n'a encore publié de résultat confirmé pour ce problème : testez donc sur votre propre Mac plutôt que de le supposer.
• Écartez d'abord les causes banales. L'analyse de Spotlight et de Photos après une mise à niveau, Time Machine, la synchronisation iCloud et les réglages de réactivation réseau produisent tous de la chaleur nocturne, et le tableau de décision ci-dessous indique quel nom de processus renvoie à quelle cause.

Le symptôme : un Mac chaud et une batterie à plat à 9 h

L'auteur du message initial du fil MacRumors donne la description la plus claire de ce que cela donne. Depuis l'installation de macOS 27, il constate un pic d'utilisation du CPU « exactement à minuit », avec appstoreagent et dasd comme coupables, à la fois sur un MacBook Pro et sur un MacBook Air. La deuxième fois, il a laissé les deux machines allumées toute la nuit avec iStat Menus ouvert, et la charge est retombée à 9 h. Un membre possédant un Mac Studio et un MacBook Pro a confirmé le même comportement, et un troisième a ajouté une remarque utile : on peut ne jamais remarquer la charge CPU si l'on n'utilise pas de moniteur système, « mais on remarquera à coup sûr que la batterie se vide plus vite ».

Quelques précisions à garder en tête, toutes issues d'observations d'utilisateurs et non de la documentation d'Apple :

• L'horaire signalé est minuit, heure locale. Un intervenant du fil indique que la charge s'est arrêtée à 9 h. Un autre article décrit l'horodatage bloqué comme « aujourd'hui à 00:00:00 » dans le fuseau horaire de l'auteur. Ni l'un ni l'autre ne relève de la documentation Apple ; ce sont des observations d'utilisateurs.
• Ce n'est pas une nouveauté de la version finale. L'auteur du fil note que des personnes l'avaient déjà constaté dans les premières bêtas, et un article en chinois du 24 juin décrit appstoreagent à plus de 100 % de CPU sur une bêta développeur de macOS 27. Il s'agit donc d'un bug ancien qui a été livré, et non d'une régression fraîche de la version finale.

Si cela correspond à votre Mac, poursuivez la lecture. Si vos symptômes sont de la chaleur en journée, ou de la chaleur qui dure plusieurs jours après la mise à niveau et pas seulement la nuit, passez directement à la section sur les autres causes, car le même correctif ne vous aidera pas.

Ce que sont réellement dasd et appstoreagent

Avant d'exécuter des commandes trouvées sur Internet, il est utile de savoir ce que vous manipulez.

appstoreagent : l'assistant d'arrière-plan de l'App Store

appstoreagent est un agent d'arrière-plan propre à chaque utilisateur, qui fait partie de la mécanique de l'App Store. Il recherche les mises à jour d'apps, gère les téléchargements automatiques, vérifie les licences et maintient l'état de l'App Store synchronisé. Il est normalement invisible et normalement proche de 0 % de CPU. Il s'occupe aussi, et c'est ce qui nous intéresse ici, de la comptabilité d'Apple Arcade, ce qui explique pourquoi une préférence liée à Arcade apparaît dans son domaine (com.apple.appstored).

dasd : le Duet Activity Scheduler

dasd est le démon Duet Activity Scheduler, DAS en abrégé, et c'est l'un des processus d'arrière-plan les plus importants d'un Mac. Howard Oakley, de The Eclectic Light Company, dont les articles constituent la meilleure documentation publique sur ce sous-système, le décrit ainsi : DAS tient une liste d'activités planifiées et les évalue fréquemment pour déterminer laquelle doit s'exécuter ensuite. Lorsque le score combiné d'une activité dépasse un seuil, DAS décide de l'exécuter et demande à Centralized Task Scheduling, CTS, de la lancer via XPC, le mécanisme léger de communication entre processus d'Apple.

Les sauvegardes Time Machine, le nettoyage des mises à jour logicielles, les analyses de sécurité, les passes de synchronisation et des dizaines de tâches de maintenance courantes passent toutes par ce pipeline. Dans une analyse de juillet 2026, Oakley a dénombré au moins 701 activités distinctes soumises à DAS dans la minute qui suit un démarrage sous macOS 26.5.2, et note que DAS et CTS sont désormais largement responsables du travail effectué par les cœurs d'efficacité sur les Mac Apple silicon. En d'autres termes, dasd est un standard téléphonique. Quand il consomme du CPU, c'est généralement que quelque chose lui envoie du travail, ou lui envoie le même travail en boucle.

Comment le planificateur décide : scores, conditions et seuils

L'article d'Oakley énumère les facteurs que DAS intègre dans son score. Ils comprennent le niveau de batterie, la présence d'un chargeur, le budget énergétique, l'utilisation du CPU, la pression mémoire, l'état thermique, la qualité du réseau, le fait que le Mac soit ou non en état Power Nap, et si l'utilisateur se sert activement d'une app. Les activités portent leurs propres critères, par exemple « ne pas s'exécuter pendant 300 secondes après le démarrage » pour une première sauvegarde Time Machine, et DAS journalise ses décisions. Il montre des entrées de la forme « Decision: Can Proceed » et « Decision: Must Not Proceed » accompagnées d'un score et d'un score seuil.

Deux propriétés de cette conception comptent pour notre bug :

1. DAS exécute le travail selon une échéance autant que selon des conditions. Une activité peut être marquée comme due à un moment donné. Si elle est en retard et que ses conditions sont réunies, elle s'exécute.
2. L'activité se réenregistre par l'intermédiaire de son propriétaire. Une fois l'activité exécutée, le processus qui la possède, ici appstoreagent, indique au planificateur quand il souhaite la relancer. C'est là qu'une date erronée fait des dégâts.

Les identifiants d'activité dans le journal ressemblent à 0:com.apple.softwareupdated.logs-cleanup:A2BBC8 : un identifiant d'utilisateur, le nom de l'activité et un court suffixe hexadécimal attribué par DAS. Les noms de sous-systèmes à connaître sont com.apple.duetactivityscheduler pour DAS et com.apple.xpc.activity pour CTS. Vous utiliserez bientôt le premier.

La cause signalée : une échéance qui n'avance jamais

Plusieurs personnes ont remonté indépendamment le problème au même endroit. L'article public le plus détaillé est l'issue 82 d'un dépôt nix-config, qui cite le développeur chinois dont le billet de blog était lié dans la réponse MacRumors. Son récit, en résumé :

• La tâche concernée est com.apple.appstored.ArcadeResetPO, que l'article décrit comme une tâche de réinitialisation des versements aux développeurs Apple Arcade.
• Une fois exécutée, une préférence du domaine com.apple.appstored, ArcadePayoutResetDate, devrait avancer au cycle suivant. Au lieu de cela, elle reste figée sur un horodatage passé.
• dasd voit donc la tâche comme en retard et l'exécute immédiatement. appstoreagent la réenregistre avec la même heure expirée. Le cycle se répète à raison d'environ 70 à 100 fois par seconde.
• Le résultat : un cœur saturé, une journalisation unifiée intense, de la chaleur et une décharge de la batterie.

Le dépôt de script phobox360, écrit par un membre de MacRumors qui affirme avoir trouvé le bug de son côté, décrit le même mécanisme : une tâche d'arrière-plan Apple Arcade nommée ArcadeResetPO se planifie à répétition dans le passé. Deux personnes indépendantes parviennent ainsi à la même conclusion, ce qui est plus qu'une simple anecdote mais ne constitue pas encore une déclaration d'Apple.

Un signalement distinct, plus ancien, datant de juin, décrit une variante de l'époque des bêtas. Il incrimine des erreurs de base de données dans le code d'Arcade (une colonne manquante dans une table SQLite et une ligne de journal indiquant la mise à jour d'une tâche déjà en cours d'exécution) ainsi qu'une boucle serrée de recherches d'interfaces réseau. Il est surtout utile comme preuve que le problème précède la version finale. Son remède, geler le processus avec kill -STOP, désactive les mises à jour de l'App Store tant que le processus est gelé et n'est pas ce que l'on recommande aujourd'hui.

Comment confirmer que c'est bien votre problème

Suivez ces étapes dans l'ordre. Rien dans cette section ne modifie de réglage. Idéalement, exécutez les deux premières pendant que le Mac se comporte mal, c'est-à-dire peu après minuit ou dès le matin avant de faire quoi que ce soit d'autre.

Étape 1 : consulter le Moniteur d'activité

Ouvrez le Moniteur d'activité depuis Applications > Utilitaires, cliquez sur l'onglet CPU et triez par la colonne % CPU. Vous cherchez dasd et appstoreagent tous deux en haut de la liste avec un CPU soutenu, idéalement avec un grand Temps CPU cumulé. Sur un Mac touché par ce bug, les signalements évoquent un cœur entier : une valeur proche de 100 % pour un seul processus sur une machine multicœur est donc le motif typique. dasd s'exécute en tant que root ; si vous ne voyez que vos propres processus, choisissez Présentation > Tous les processus.

Si le Mac est resté inactif toute la nuit, un énorme Temps CPU à côté de appstoreagent est un indice fort même après la fin du pic, car cette colonne cumule. L'article de juin montre une ligne top avec appstoreagent à 126,7 % et un temps d'exécution de plus de 284 minutes.

Étape 2 : confirmer depuis le Terminal avec top

Le Moniteur d'activité convient, mais le Terminal vous donne du texte que vous pouvez coller dans un fil de discussion. Le premier échantillon affiché par top est une moyenne depuis le démarrage : demandez donc deux échantillons et lisez le second :

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu trie par CPU, -n 10 limite la liste à dix processus, -l 2 prend deux échantillons et -stats choisit les colonnes. Lisez le second bloc. Si dasd et appstoreagent figurent tous deux parmi les premiers et qu'aucun n'est proche de zéro alors que le Mac est par ailleurs inactif, cela concorde avec le bug. En version plus courte, ps -axo pid,pcpu,time,comm -r | head liste les processus les plus gourmands en CPU selon l'utilisation actuelle.

Étape 3 : lire la date Arcade

C'est le test décisif, car il vérifie la cause signalée et non le symptôme. La discussion du projet phobox360 identifie une méthode indépendante de la langue pour lire la valeur. La clé se trouve dans le domaine com.apple.appstored, et la valeur est renvoyée au format ISO 8601 lorsqu'on la lit avec plutil :

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

La première commande affiche la date stockée sous la forme 2026-09-26T22:00:00Z. La deuxième affiche la même chose selon vos réglages régionaux, ce qui est plus facile à lire mais, comme l'ont constaté les auteurs du script, peut être rendu différemment sur les langues à format 12 heures ; utilisez donc la première si vous comptez comparer par programme. La troisième affiche l'heure actuelle dans le même format pour que vous puissiez comparer à l'œil.

Comment interpréter le résultat :

• La date stockée est dans le passé (antérieure à l'heure UTC actuelle) alors que dasd et appstoreagent sont actifs : cela correspond au bug signalé.
• La date stockée est dans le futur et les processus sont calmes : ce bug n'est pas ce qui vous arrive.
• La date stockée est dans le futur et les processus sont toujours actifs : autre chose se passe, ou la boucle a une cause qui n'a pas été décrite publiquement. Servez-vous du tableau des processus plus bas.
• La clé n'existe pas : l'app ne l'a pas encore créée, ce qui n'est une preuve ni dans un sens ni dans l'autre. Un Mac qui n'a jamais lancé l'App Store ni Apple Arcade peut ne pas l'avoir.

Enregistrez ce résultat avant de modifier quoi que ce soit. C'est votre trace de la valeur d'origine.

Étape 4 : examiner le journal unifié avec un prédicat précis

C'est dans le journal que l'affirmation « 70 à 100 fois par seconde » peut être vérifiée. La commande macOS log accepte un filtre NSPredicate, et la forme abrégée process == "name" est documentée dans la page de manuel de log. Pour voir les dernières minutes de dasd dans un format compact sur une ligne :

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

Pour compter le nombre de lignes écrites en une seule minute, ce qui donne un débit approximatif :

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

Sur un Mac sain, ce nombre est modeste. Si le bug est actif, attendez-vous à un déluge ; le rapport indique que la boucle provoque une journalisation unifiée intense. Vous pouvez aussi filtrer sur le sous-système du planificateur, ou rechercher directement le nom de la tâche :

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

Le filtre sur le nom de la tâche est le plus précis. Si ArcadeResetPO apparaît des dizaines de fois par minute, vous avez confirmé le bug signalé. Pour l'observer en direct plutôt qu'après coup, utilisez log stream avec le même prédicat :

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

Appuyez sur Control-C pour arrêter. Deux mises en garde. Premièrement, n'exécutez pas log show sur plusieurs heures avec un prédicat trop large sur un Mac touché par ce bug, car le journal peut être énorme et la commande sera très lente. Gardez une fenêtre courte. Deuxièmement, nous vous donnons ici une syntaxe documentée, pas la transcription de ce que contiendra votre journal. Le libellé des messages peut différer d'une build à l'autre : si le premier filtre ne renvoie rien, essayez le filtre par processus avant de conclure que le bug est absent.

Étape 5 : vérifier ce qui a maintenu le Mac éveillé

Si la boucle tourne, vous voulez aussi savoir si le Mac était éveillé pour elle ou s'il s'est réveillé à cause d'elle. Deux lectures avec pmset aident.

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

La première affiche les assertions d'alimentation en cours, c'est-à-dire ce qui empêche actuellement la mise en veille, comme une tâche d'arrière-plan ou un processus qui maintient l'écran allumé. La seconde affiche l'historique des réveils issu du journal d'alimentation ; chaque ligne de réveil comporte une raison « due to », et un DarkWake est un réveil partiel pendant lequel le Mac reste sombre pendant qu'il exécute des tâches d'arrière-plan. La page de manuel décrit -g log comme un historique des mises en veille, des réveils et d'autres événements de gestion de l'alimentation destiné aux administrateurs et au débogage. Une série de DarkWake pendant la nuit, chacun déclenché par le réseau ou par une raison de maintenance, désigne le chemin de planification. Une longue période de réveil complet et ininterrompu désigne quelque chose qui maintient le Mac éveillé. Notre guide des problèmes de veille du Mac explique en détail comment lire ces lignes.

Le tableau de décision : quel processus renvoie à quelle cause

Ce bug prête à confusion parce qu'une demi-douzaine de tâches sans rapport apparaissent elles aussi comme du CPU d'arrière-plan la nuit. Ce tableau associe ce que vous voyez dans le Moniteur d'activité à l'explication la plus probable. C'est une aide au diagnostic construite à partir de la documentation Apple et des sources citées dans cet article, pas une garantie.

Ce que vous voyez en haut du CPU	Cause la plus probable	Normal ou problème ?	Première vérification
dasd et appstoreagent, tous deux actifs, souvent à partir de minuit	La boucle de date Arcade signalée	Problème (bug signalé)	Étape 3 : ArcadePayoutResetDate est-elle dans le passé ?
mds, mds_stores, mdworker_shared	Indexation Spotlight	Normal pendant quelques heures à quelques jours après une mise à niveau ; problème si cela ne se calme jamais	Notre guide sur la réindexation Spotlight
photoanalysisd, mediaanalysisd	Photos analyse votre photothèque (visages, scènes, objets)	Normal après une mise à niveau ou un gros import, surtout sur secteur	Ouvrez Photos et vérifiez l'état de l'analyse dans la photothèque
backupd, backupd-helper, diskarbitrationd	Sauvegarde Time Machine	Normal toutes les heures ; problème si elle ne se termine jamais	Réglages Système > Général > Time Machine, et notre guide de dépannage Time Machine
bird, cloudd, fileproviderd	iCloud Drive ou un autre fournisseur de fichiers en cours de synchronisation	Normal pendant une grosse synchronisation ; problème si elle boucle	Vérifiez l'état d'iCloud Drive et la taille des changements récents
powerd, kernel_task élevés au repos	Gestion thermique ou assertion d'alimentation	Variable ; souvent un symptôme plutôt qu'une cause	Étape 5 et liste des assertions
dasd seul, mémoire croissante jusqu'à plusieurs gigaoctets	Un autre problème de mémoire de dasd, signalé sur les bêtas de macOS 27 par un blog tiers citant des témoignages d'utilisateurs	Problème, mais différent, et le correctif de date ne s'applique pas	Onglet Mémoire du Moniteur d'activité
contactsd, peopled	Le widget Contacts et la base de données de l'historique des appels	Problème connu de l'ère Tahoe	Notre guide sur peopled et contactsd
Une app tierce ou son processus d'assistance	L'app elle-même	Problème propre à cette app	Quittez-la ; vérifiez s'il existe une mise à jour

Deux règles pratiques se dégagent de ce tableau. Premièrement, l'association compte : dasd seul est un planificateur qui distribue beaucoup de travail, et le CPU est souvent dépensé par le processus auquel il confie ce travail. dasd plus appstoreagent ensemble, à heure fixe, est le motif décrit dans les signalements. Deuxièmement, l'horaire compte : l'indexation et l'analyse des photos sont les plus intenses juste après la mise à niveau puis s'estompent, alors qu'une boucle liée à minuit devrait se reproduire chaque nuit.

Le contournement de la communauté, expliqué ligne par ligne

Le correctif sur lequel les membres de MacRumors et les articles ont convergé est un simple changement de préférence. Le voici sous la forme publiée dans le fil, avec l'explication que le fil ne vous donne pas.

Avant de modifier quoi que ce soit : enregistrer la valeur d'origine

Faites une copie de l'existant afin de pouvoir le remettre. Aucune de ces deux commandes ne modifie quoi que ce soit.

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

La première écrit la date actuelle dans un fichier texte. La seconde exporte tout le domaine de préférences com.apple.appstored vers une liste de propriétés sur votre Bureau. Si la première commande affiche « does not exist », la clé est absente et vous pouvez ignorer la première ligne.

La commande

Telle que publiée sur MacRumors et reprise dans l'issue nix-config, la version à sept jours est :

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

Décortiquons-la :

• defaults write com.apple.appstored ArcadePayoutResetDate -date "..." écrit une valeur de type date dans la clé ArcadePayoutResetDate des préférences de l'agent App Store. L'option -date indique à defaults que la valeur est une date et non une chaîne.
• $(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ") est le shell qui calcule cette date. date -v+7d est le date BSD (celui de macOS) qui avance l'heure actuelle de sept jours, -u utilise UTC, et la chaîne de format produit un horodatage ISO 8601 se terminant par Z. Le date GNU de coreutils via Homebrew utilise d'autres options : si vous avez remplacé le date du système dans votre chemin, exécutez-le sous la forme /bin/date.
• && n'exécute la suite que si l'écriture a réussi.
• killall appstoreagent termine l'appstoreagent en cours pour qu'il redémarre et lise la nouvelle préférence. Le système le relance à la demande, ce n'est donc pas un arrêt définitif. Si l'App Store est en train de télécharger ou de mettre à jour quelque chose, cela l'interrompra : essayez de le faire lorsqu'aucune mise à jour n'est en cours.

Exécutez-la avec votre utilisateur habituel, sans sudo. La préférence appartient à votre compte, et le projet phobox360 demande explicitement à ses utilisateurs de l'exécuter sans sudo. Écrire des préférences en tant que root créerait un fichier que l'agent risque de ne pas lire.

Ce que vous devriez observer : quelques secondes après le redémarrage, dasd et appstoreagent devraient retomber près de zéro dans le Moniteur d'activité. L'article qui a documenté la commande en premier indique que le correctif prend effet immédiatement. C'est le résultat rapporté par un utilisateur, pas quelque chose que nous pouvons vous promettre pour votre Mac.

Ce que cela change et ne change pas

• Cela change une seule date. Rien n'est supprimé, aucun fichier système n'est touché, aucune protection n'est désactivée. com.apple.appstored est un domaine de préférences ordinaire propre à l'utilisateur.
• Cela ne corrige pas le bug qui a rendu la date périmée. Cela repousse l'échéance hors d'atteinte pour que le planificateur cesse de voir la tâche comme en retard. Les auteurs des signalements le décrivent comme un contournement en attendant qu'Apple publie un vrai correctif.
• On ne sait pas s'il affecte votre abonnement Apple Arcade ou vos jeux. La tâche concernée est décrite comme une réinitialisation de versement aux développeurs. Mais personne n'a publié de test de ce qui se passe dans la comptabilité d'Arcade lorsque la date est repoussée très loin. L'auteur du script le dit lui-même à propos de l'option plus agressive de 2035. Si vous utilisez beaucoup Arcade, préférez la fenêtre courte de sept jours.

Choisir une date : sept jours ou des années

L'article nix-config utilise 2099-01-01T00:00:00Z, ce qui range la tâche pratiquement pour toujours :

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

Cela évite de répéter le correctif chaque semaine et serait censé mettre la tâche de côté à long terme « sans casser les fonctionnalités de l'App Store », mais cette description est celle de son auteur, et non quelque chose qu'Apple a confirmé. Le mode durable optionnel du script phobox360 utilise 2035 et s'accompagne d'un avertissement explicite : son effet sur la comptabilité d'Arcade n'a pas été établi de façon indépendante. Notre recommandation, qui est un jugement et non un fait documenté : commencez par sept jours. Si cela fonctionne, vous aurez appris à faible risque que le diagnostic était juste, et vous pourrez décider plus tard d'aller plus loin ou non.

Comment l'annuler

Il existe deux façons de revenir en arrière, et il vaut mieux les connaître toutes les deux avant d'en avoir besoin.

Restaurer la valeur enregistrée. Si vous avez enregistré la date d'origine et qu'il s'agissait d'une date passée valide, la réécrire vous ramène à l'état précédent, qui est bien sûr l'état avec la boucle. En pratique, vous ne le faites que pour tester ou pour transmettre un état propre à Apple dans un rapport de bug. Utilisez la chaîne ISO de votre fichier texte :

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

Remplacez la date d'exemple par votre propre valeur enregistrée.

Supprimer la clé. Cela retire votre modification et laisse l'agent démarrer sans valeur stockée :

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

Supprimer une clé est la manière standard, avec defaults, de ramener un réglage à sa valeur par défaut. Ce que fait l'agent App Store lorsque la clé est absente sous macOS 27 n'est pas documenté : il peut recréer une date neuve et valide, ou la date défectueuse. Si la boucle revient après la suppression de la clé, appliquez de nouveau le contournement.

L'option du script, et le crédit à lui accorder

Le dépôt dasd-arcade-loop-fix enveloppe le même changement dans un script avec exécution à blanc, invite de confirmation, sauvegarde automatique de la valeur d'origine et commande de retour arrière. Au moment de la rédaction, c'est un petit projet avec presque aucune étoile ni fork, donc peu relu. La lecture raisonnable est de lire le script avant de l'exécuter, ou simplement d'utiliser la commande d'une ligne ci-dessus, qui fait la même chose sous une forme que vous voyez en entier. Si vous utilisez le script, ses options documentées sont une exécution à blanc, le report par défaut d'une semaine et --rollback. Une pull request a corrigé un abandon sur les langues à format 12 heures causé par la façon dont defaults read affiche les dates, ce qui rappelle utilement que les scripts shell qui analysent la sortie des préférences sont fragiles.

Ce qu'il ne faut pas faire

• Ne tuez pas dasd. Il appartient à root, launchd le relance immédiatement, et on ne répare pas un planificateur en le tuant. Cela ne corrige pas non plus la raison pour laquelle la tâche est en retard.
• Ne faites pas de kill -STOP ni ne déchargez appstoreagent à titre de mesure permanente. L'article de juin a utilisé kill -STOP parce que rien d'autre ne tenait sur une bêta. Cela suspend le processus : les mises à jour de l'App Store, les téléchargements et les vérifications de licence s'arrêtent jusqu'à ce que vous le repreniez avec kill -CONT.
• Ne désactivez pas la protection de l'intégrité du système (SIP) et ne modifiez pas les fichiers de /System. Aucun signalement n'en a besoin.
• Ne désactivez pas les mises à jour automatiques comme seul remède en déclarant le problème réglé. Une réponse MacRumors le suggère, et cela peut réduire la fréquence de réveil de l'agent, mais cela ne traite pas la cause signalée : la tâche est une réinitialisation de versement Arcade, pas une recherche de mises à jour. Cela vous prive aussi des mises à jour de sécurité automatiques pour les apps de l'App Store. Si vous la désactivez pour tester, réactivez-la ensuite.

Pourquoi cela revient, et que faire

Si vous avez utilisé la commande à sept jours, la date que vous avez écrite est désormais une vraie date valide, et le planificateur est satisfait jusqu'à ce que ce jour passe. Quand c'est le cas, la condition de date périmée redevient possible. Les signalements indiquent que la boucle peut réapparaître après environ une semaine. Le mécanisme est celui que l'on prédirait à partir de la description du bug : le correctif repousse l'échéance, et le bug qui empêche de la faire avancer correctement est toujours là.

Vous avez deux options.

1. Répéter la commande chaque semaine. Mettez un rappel dans Calendrier. C'est peu coûteux et cela garde l'état de votre Arcade proche de la normale.
2. Utiliser une date beaucoup plus lointaine. La forme 2099 supprime la corvée. Le compromis est celui déjà décrit : un terrain moins testé pour la comptabilité d'Arcade.

macOS 27.0.1 le corrige-t-il ?

Nous ne le savons pas, et nous préférons vous le dire plutôt que de deviner.

Ce que nous pouvons vérifier : Apple a publié macOS 27.0.1 le 28 septembre. Selon l'article de The Eclectic Light Company, le nouveau numéro de build est 26A434, la mise à jour « corrige apparemment des bugs non précisés, ainsi qu'un bug affectant Platform SingleSignOn », et il n'existe pas de notes de version de sécurité publiques. Cet article ne dit rien du CPU, de la batterie, de l'App Store ni d'Apple Arcade.

Ce que montre le fil : après la sortie de la 27.0.1, l'auteur du message initial a écrit « I wonder if this is fixed now in macOS 27.0.1 » (je me demande si c'est corrigé dans macOS 27.0.1). La réponse qui a suivi portait sur un autre bug, un problème d'autorisation du réseau local pour les extensions de fichiers, et confirmait que celui-là n'était pas corrigé. Personne dans le fil ne rapporte de résultat avant/après pour la boucle Arcade.

La position honnête est donc que c'est non vérifié dans les deux sens. Notez aussi que les notes de version vagues sont courantes : un correctif peut donc être présent sans être listé.

Comment le savoir sur votre propre Mac de façon à produire des preuves utiles :

1. Mettez à jour vers la 27.0.1 (Réglages Système > Général > Mise à jour de logiciels).
2. Avant d'appliquer un contournement, exécutez l'étape 3 pour lire ArcadePayoutResetDate.
3. Si vous avez déjà appliqué le contournement, attendez que la date que vous avez fixée soit passée, ou supprimez la clé comme décrit plus haut et redémarrez, puis observez pendant le passage de minuit.
4. Regardez top ou le Moniteur d'activité le lendemain matin, et lisez le journal avec le prédicat sur le nom de la tâche.
5. Publiez ce que vous constatez dans le fil MacRumors. Les personnes qui le lisent sont celles qui ont besoin de la réponse.

Autres causes de chaleur et de décharge nocturnes à écarter

Même si votre dasd est coupable, il n'est peut-être pas seul. Les mises à niveau déclenchent un empilement de tâches de rattrapage, et il est courant d'avoir plusieurs problèmes à la fois. Passez en revue les points suivants avant de conclure que la boucle Arcade explique tout.

Indexation Spotlight et Siri après la mise à niveau

Après une mise à niveau majeure, macOS reconstruit une partie de son index de recherche, ce qui se traduit par mds, mds_stores et mdworker_shared. Les conseils d'Apple sur les réveils inattendus précisent que si Spotlight indexe votre disque, votre Mac ne se mettra pas en veille, et un Mac qui ne peut pas se mettre en veille chauffe et vide sa batterie pendant la nuit. L'indexation est finie : elle travaille intensément pendant des heures, parfois un jour ou deux sur un gros disque, puis se calme. La boucle Arcade, elle, ne se calme pas. Notre guide sur la réindexation Spotlight après macOS 27 explique comment distinguer « toujours en cours » de « bloqué », et le signalement précédent sur macOS 26.6 montre le même motif avec l'index de Siri.

Analyse de Photos

photoanalysisd et mediaanalysisd analysent votre photothèque à la recherche de personnes, de scènes et d'objets. Ils sont les plus actifs après une mise à niveau ou un import, et ils finissent ; il n'existe aucune heure d'horloge à laquelle ils démarrent. Laissez le Mac branché toute la nuit et voyez si la charge s'estompe au fil de quelques nuits.

Time Machine

Les sauvegardes Time Machine passent par le même planificateur. L'article d'Oakley montre DAS refusant une sauvegarde dans les premières secondes après le démarrage parce que l'activité exige une attente de cinq minutes, ce qui illustre des critères à l'œuvre. Une première sauvegarde après une mise à niveau, ou une sauvegarde vers une destination réseau lente, peut durer des heures et chauffer le Mac. Si backupd est le processus actif, le guide de dépannage Time Machine est le bon endroit, et l'article d'Oakley sur la planification et l'envoi des sauvegardes explique pourquoi une sauvegarde peut démarrer à des moments étranges.

Power Nap et réactivation pour l'accès au réseau

La page d'Apple sur les réglages de veille et de réactivation indique que Power Nap permet au Mac de se mettre à jour pendant la veille, et que « Réactivation pour l'accès au réseau » lui permet de se réveiller brièvement pour que d'autres utilisateurs accèdent aux services partagés. Sur un portable, les deux se trouvent dans Réglages Système > Batterie > Options. La page d'Apple sur les réveils inattendus range parmi ses suggestions la désactivation de la réactivation pour l'accès au réseau et l'arrêt des services de partage. La page de manuel de pmset indique que womp est l'équivalent Terminal de « Réactivation pour l'accès au réseau » et que powernap s'applique aux machines compatibles. La disponibilité de Power Nap varie selon les modèles : ne soyez donc pas surpris de ne pas la voir.

Pour vérifier vos valeurs actuelles sans rien changer :

pmset -g | grep -E "powernap|womp"

Désactiver les deux est une expérience raisonnable si votre pmset -g log montre des DarkWake réguliers pendant la nuit. Cela ne réglera pas la boucle Arcade, qui se produit pendant que le Mac est éveillé ou pendant un réveil de maintenance, mais cela retire du bruit de votre diagnostic. Ne faites qu'un changement à la fois pour savoir ce qui a aidé.

Dépannage des problèmes courants

Les processus sont toujours actifs après la commande

Symptômes : vous avez exécuté defaults write et killall, mais dasd et appstoreagent restent en haut du Moniteur d'activité.

Cause : plusieurs possibilités. Le killall n'a peut-être pas trouvé de correspondance, si bien que l'ancien processus tourne toujours avec l'ancienne date en cache. L'écriture a peut-être échoué silencieusement, par exemple à cause d'une faute de frappe dans le domaine. Vous observez peut-être une tout autre cause.

Solution :

1. Relisez la valeur avec plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist et confirmez qu'elle est dans le futur.
2. Exécutez de nouveau killall appstoreagent, puis vérifiez dans le Moniteur d'activité si le processus a redémarré avec un nouveau PID.
3. Relancez le prédicat de journal sur le nom de la tâche pendant une minute. Si ArcadeResetPO n'apparaît plus mais que le CPU reste élevé, la cause est ailleurs, et le tableau des processus ci-dessus est votre prochaine étape.

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

Si cela ne fonctionne pas : redémarrez le Mac une fois. Un redémarrage vide les préférences en cache et tout état bloqué du planificateur. Si la date est toujours valide après le redémarrage et que la charge persiste, considérez qu'il s'agit d'un autre bug et rassemblez les résultats des étapes 2 et 4 avant de demander de l'aide.

La boucle revient une semaine plus tard

Symptômes : une semaine calme, puis le pic de minuit revient.

Cause : votre date à sept jours est passée et le bug sous-jacent est toujours présent.

Solution : réexécutez la commande, ou choisissez une date plus lointaine comme indiqué plus haut. Si vous préférez ne pas la répéter, optez en connaissance de cause pour une fenêtre plus longue, en vous rappelant que son effet sur la comptabilité d'Arcade n'est pas documenté.

Le Mac se vide toujours la nuit mais les processus semblent calmes

Symptômes : dasd et appstoreagent sont à zéro et la batterie baisse quand même.

Cause : la chaleur et la décharge pendant la veille viennent souvent des réveils et des assertions, pas du CPU.

Solution : lisez pmset -g log pour la plage horaire de la nuit et voyez combien de fois le Mac s'est réveillé et pourquoi. Vérifiez avec pmset -g assertions s'il y a quelque chose qui empêche la veille. Notre guide des problèmes de veille du Mac et le guide de la décharge de batterie sous macOS Tahoe passent en revue les coupables habituels, et le guide de diagnostic avancé de la batterie explique plus en profondeur comment lire les données de batterie.

FAQ

Pourquoi dasd et appstoreagent utilisent-ils autant de CPU sous macOS 27 ?

Des membres de MacRumors et des articles indépendants indiquent qu'une tâche Apple Arcade, ArcadeResetPO, garde une date stockée dans le passé, de sorte que le planificateur la relance constamment, peut-être 70 à 100 fois par seconde. Apple ne l'a pas confirmé. Le motif est un cœur saturé, souvent à partir de minuit, avec de la chaleur et une décharge plus rapide de la batterie.

Est-il sûr d'exécuter la commande defaults write pour ArcadePayoutResetDate ?

Elle modifie une seule préférence propre à l'utilisateur et ne touche à aucun fichier système, et elle peut être annulée en supprimant la clé ou en restaurant une valeur enregistrée. C'est un contournement de la communauté, pas une consigne d'Apple, et son effet sur la comptabilité d'Arcade sur de longues périodes n'est pas documenté. Enregistrez d'abord la valeur d'origine et préférez une fenêtre courte.

macOS 27.0.1 corrige-t-il la boucle dasd et appstoreagent ?

Nous n'avons pas pu le vérifier. La mise à jour 27.0.1 d'Apple, build 26A434, est signalée comme corrigeant des bugs non précisés et un problème de Platform SSO, sans mention de celui-ci. Le seul message MacRumors qui posait la question a obtenu une réponse sur un autre bug. Testez sur votre propre Mac en lisant la date à travers minuit.

Comment savoir que c'est ce bug et non Spotlight ou Photos ?

Lisez la date stockée avec plutil et comparez-la à l'heure UTC actuelle. Si elle est dans le passé alors que dasd et appstoreagent sont actifs, et que le journal montre la tâche ArcadeResetPO se répétant, c'est ce bug. Spotlight apparaît sous forme de processus mds, et Photos sous forme de photoanalysisd, sans heure de départ fixe à minuit.

Pourquoi le problème revient-il après une semaine ?

Le contournement repousse la date de réinitialisation d'une semaine. Quand cette date passe, le bug sous-jacent qui l'empêche d'avancer peut frapper de nouveau, et la boucle revient. Les auteurs des signalements décrivent une réapparition après environ une semaine. Vous pouvez répéter la commande chaque semaine ou choisir une date plus lointaine, en acceptant que les dates lointaines soient moins testées.

Désactiver les mises à jour automatiques de l'App Store l'arrêtera-t-il ?

Une réponse MacRumors dit que cela calme les processus, mais cela ne traite pas la cause signalée, qui est une tâche de versement Arcade et non une recherche de mises à jour. Cela signifie aussi que vous cessez de recevoir les mises à jour automatiques des apps de l'App Store. Considérez-le comme un compromis à tester, pas comme un correctif, et réactivez les mises à jour si cela n'aide pas.

Puis-je simplement tuer dasd ou appstoreagent ?

Tuer appstoreagent arrête brièvement le pic, mais le système le relance à la demande et la date périmée demeure, donc la boucle reprend. dasd est un planificateur appartenant à root que launchd relance aussitôt. Geler appstoreagent avec kill -STOP fonctionne mais arrête les mises à jour de l'App Store et les vérifications de licence jusqu'à ce que vous le repreniez.

Le correctif affecte-t-il mes jeux ou mon abonnement Apple Arcade ?

Rien dans les signalements publics ne l'indique. La tâche est décrite comme une réinitialisation de versement aux développeurs, et le contournement ne change qu'une date. Mais personne n'a publié de test consistant à la repousser de plusieurs années, et l'auteur du script précise explicitement que l'effet sur la comptabilité d'Arcade n'a pas été établi. Utilisez une fenêtre courte si vous jouez à Arcade.

Conclusion

Le motif derrière un Mac qui chauffe et se vide pendant la nuit sous macOS 27 est, dans un nombre croissant de signalements, une boucle du planificateur : dasd qui distribue, et appstoreagent qui réenregistre, une tâche Apple Arcade dont la date n'avance jamais. Il est peu coûteux de le confirmer sans rien modifier : lisez la date stockée, comparez-la à UTC et cherchez le nom de la tâche dans le journal. Si la date est dans le passé, le contournement communautaire en une ligne serait capable d'arrêter la boucle aussitôt, et il est facile à annuler.

Gardez des attentes réalistes. C'est un contournement qu'il faut répéter à moins d'accepter une date plus lointaine, Apple ne l'a pas reconnu, et nous ne pouvons pas vous dire que la 27.0.1 ou une mise à jour ultérieure le corrige. Si la vérification de la date revient propre, ne forcez pas le diagnostic ; passez en revue Spotlight, Photos, Time Machine, iCloud et les réglages de réveil, un par un, à l'aide du tableau de décision ci-dessus.

Pour aller plus loin, notre guide sur la réindexation Spotlight couvre la cause légitime la plus courante d'un Mac chaud après une mise à niveau, et le guide des problèmes de veille du Mac traite des problèmes de réveil et d'assertions. Si un autre processus est votre coupable, le guide sur peopled et contactsd pourrait correspondre. Et si vous découvrez si la 27.0.1 a changé quelque chose sur votre Mac, dites-le aux participants du fil MacRumors.

Vous avez des questions ou des astuces à partager ? Nous serions ravis de connaître votre expérience dans les commentaires ci-dessous.

À lire aussi : Réindexation Spotlight après macOS 27, Mac chaud et batterie qui se vide après macOS 26.6, Guide complet de correction de la décharge de batterie sous macOS Tahoe, Guide de mise à jour du jour de sortie de macOS 27 Golden Gate