Chaque iPhone embarque une « boîte noire » appelée sysdiagnose — une archive de diagnostic système que les ingénieurs d'Apple consultent en premier lorsqu'un problème survient. Appuyez sur deux boutons de volume et le bouton latéral pendant environ une seconde, et iOS en enregistre discrètement une en arrière-plan. Une fois compressée, elle représente encore des centaines de mégaoctets, remplie de ioreg, smcDiagnose, taskinfo, de rapports de crash et de données sur la chimie de la batterie.

Le problème : elle n'a jamais été conçue pour vous. Décompressée, elle contient des milliers de fichiers et des dizaines de milliers de lignes de texte brut. La valeur que vous recherchez est enterrée à la ligne 10 000 de IODeviceTree.txt ou à l'intérieur d'un nœud de contrôleur NVMe dans IOService.txt. Même un développeur expérimenté a besoin de dix minutes rien que pour la trouver.

Device Status⁺ transforme ce mur de texte en un écran de cartes lisibles — entièrement sur l'appareil, sans télécharger un seul octet. Ce guide explique comment fonctionne son Diagnostic Log Analyzer, de la capture d'un sysdiagnose à la lecture des cartes, et pourquoi cela ne fera pas planter votre téléphone.

Qu'est-ce que Device Status⁺ ?

Device Status⁺ est une application gratuite de surveillance système développée par Space-Time Transformation Technology Co., Ltd. Elle nécessite iOS 17.0+ et fonctionne sur iPhone, iPad, Mac (série M), Apple Vision Pro et Apple Watch. Parallèlement aux tableaux de bord en temps réel du CPU, de la mémoire, du stockage, de la batterie et du réseau, elle intègre un Diagnostic Log Analyzer dédié pour les archives sysdiagnose et un Battery Log Analyzer pour l'analyse quotidienne de la batterie (traité dans un guide séparé).

Tout ce qui est décrit ci-dessous se passe localement. L'écran d'importation l'indique clairement : "Tout le traitement se fait sur l'appareil. Rien n'est téléchargé."

Qu'est-ce qu'un sysdiagnose exactement ?

Un sysdiagnose est un instantané de l'ensemble du système à un instant donné. Déclenché par la combinaison de touches matérielles, il collecte :

• Vidages de l'arbre des périphériques ioreg (IODeviceTree.txt, IOService.txt)
• Relevés du SMC (System Management Controller) et smcDiagnose
• Instantanés des processus taskinfo
• Rapports de crash agrégés (.ips)
• Plists de chimie de la batterie et instantanés de l'usure du NAND
• État du réseau, du Wi-Fi et du Bluetooth

Le résultat est un fichier sysdiagnose_YYYY.MM.DD-...tar.gz qui, une fois extrait, peut contenir plus de 2 400 entrées avec des en-têtes étendus PAX. Sur un iPhone à la mémoire limitée, l'approche évidente — « tout lire en mémoire, puis décompresser » — échoue avec une erreur OOM. L'analyseur ne fait donc pas cela.

Étape 1 : Capturer le sysdiagnose

La partie la plus difficile n'est pas l'analyse. C'est l'obtention du fichier. Device Status⁺ fournit un guide illustré (LogCollectionGuideView) qui vous accompagne à chaque toucher :

1. Maintenez enfoncés les deux boutons de volume + le bouton latéral pendant environ une seconde, relâchez après le retour haptique — cela déclenche le sysdiagnose.
2. Continuez à utiliser le téléphone normalement et attendez environ 10 minutes pour que la collecte se termine.
3. Ouvrez Réglages → Confidentialité et sécurité → Analyses et améliorations → Données d'analyse et recherchez sysdiagnose.
4. Ouvrez le fichier → Partager → Enregistrer dans Fichiers → de retour dans Device Status⁺, appuyez sur + pour importer.

Pour réduire l'étape « trouver l'entrée » à néant, le guide propose deux raccourcis en un seul toucher : installer un raccourci (lien iCloud) et accéder directement au panneau Analyses et améliorations via un schéma Shortcuts.

Étape 2 : Importer sans crash de mémoire

C'est ici que l'ingénierie prouve sa valeur. Le SysdiagnoseArchiveExtractor exécute un pipeline de flux en deux étapes qui traite une archive de 800 Mo avec seulement quelques kilo-octets de mémoire tampon.

Étape 1 — gunzip. Utilisant zlib avec inflateInit2(16 + MAX_WBITS) pour un décodage prenant en charge gzip, le fichier d'entrée est mappé en mémoire via mmap (pagination à la demande, jamais résident en mémoire) et la sortie est écrite dans un .tar temporaire par blocs de 64 Ko. Le pic de mémoire correspond juste au tampon.

Étape 2 — untar. Une machine à états écrite à la main analyse les en-têtes USTAR / GNU / PAX entrée par entrée et écrit chacune sur le disque. Elle prend en charge les noms de fichiers longs GNU (type L), les en-têtes étendus PAX par entrée et globaux (x / g), et les champs de taille en base 256. L'archive n'est jamais conservée en totalité.

Les détails de robustesse ont tout autant d'importance :

• Vérification préalable de l'espace disque. Après gunzip, une fois la taille exacte du .tar connue, l'analyseur vérifie volumeAvailableCapacity pour « un tar + une marge de sécurité » avant de continuer — aucune archive à moitié extraite ne sature votre stockage.
• Sécurité des chemins. isSafeRelativePath rejette les chemins absolus, les \0 intégrés et les traversées de répertoires ... Rien n'écrit en dehors du bac à sable (sandbox).
• Contrôles d'intégrité. La validation CRC et ISIZE est laissée à zlib ; un gzip tronqué ou corrompu se manifeste par une erreur lisible (inflateFailed / truncatedArchive), et non par un blocage silencieux.
• Nettoyage systématique du .tar temporaire. Un defer le supprime, que l'opération réussisse ou échoue, ne laissant ainsi aucun déchet de centaines de mégaoctets derrière lui.

Pendant l'extraction, l'interface utilisateur affiche une superposition de progression qui distingue « décompression du gzip (décompressé N Mo) » de « N fichiers extraits » — vous donnant la certitude que cela fonctionne réellement.

Importation en un seul toucher via l'extension de partage

Vous pouvez ignorer complètement l'aller-retour via Fichiers. L'extension sharelog reconnaît un fichier sysdiagnose_*.tar.gz directement depuis la liste Données d'analyse. Fait crucial, l'extension n'effectue aucune analyse — son budget de mémoire est bien trop petit pour décompresser un sysdiagnose. Elle se contente de copier le fichier dans le conteneur App Group (ShareInbox/), d'écrire un signal en attente dans les UserDefaults de l'App Group, et de réveiller l'application hôte via le schéma d'URL devicestatus. L'hôte exécute ensuite l'extraction qui consomme beaucoup de mémoire. Le résultat donne l'impression d'une seule action.

Étape 3 : Lire l'aperçu de l'appareil

SysdiagnoseOverviewParser rassemble l'identité de l'appareil à partir de trois sources :

• Le premier bloc Properties: {…} dans remotectl_dumpstate.txt → modèle, OS, numéro de série, UDID, ChipID, plateforme SoC, code de région…
• "product-name" dans ioreg/IOService.txt → nom commercial (ex. iPhone 17), avec un repli intégré ProductType→nom.
• Le nom du dossier racine → horodatage de capture (prenant en charge à la fois le format de décalage +0800 et l'heure locale).

Chaque champ conserve à la fois sa clé brute et une étiquette conviviale (ex. ChipID / 33104), vous permettant de vérifier une carte par rapport à la ligne du journal d'origine.

Étape 4 : Explorer les sept catégories

Il s'agit de la décision produit fondamentale : aucun vidage de texte brut, uniquement les mesures clés extraites de chaque fichier sous forme de cartes. SysdiagnoseCategoryConfig mappe les milliers de fichiers dans sept catégories mutuellement exclusives, listant uniquement les fichiers qui disposent d'un extracteur dédié. C'est pourquoi le numéro du badge est égal au nombre de cartes que vous verrez réellement — vous ne cliquez jamais pour ne rien trouver.

Les détails que seul un initié saurait extraire

• Chimie de la batterie (ACAM). Il analyse com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plist en trois cartes :
  • Identité de la batterie — numéro de série de la cellule, qu'elle soit d'origine, limite de tension de charge.
  • Matériau actif — rétention du matériau actif (QLi / Qn / Qp : la fraction utilisable des ions lithium / anode / cathode).
  • Vieillissement et résistance — croissance de la SEI, pertes par fissuration / changement de phase, résistance des électrodes. Ce sont les métriques de santé microscopiques qui normalement n'existent que dans les outils internes d'Apple.
• Matériel de stockage (NVMe + NAND). À partir du nœud du contrôleur NVMe dans IOService.txt, il extrait le type de cellule (SLC / MLC / TLC / QLC), la taille de page, la version du firmware, les opérations et les erreurs de lecture/écriture. À partir de ASPSnapshots/asptool_snapshot.log, il extrait les nombres de démarrages / cycles d'alimentation du NAND, les quantités de lecture/écriture sur sa durée de vie, l'équilibrage d'usure (wear leveling) et la distribution des Bandes. En d'autres termes : quel type de cellule NAND vous possédez, combien a été écrit, et combien de durée de vie il reste.
• Identification de la puce. Le chip-id dans IODeviceTree est en hexadécimal petit-boutiste (little-endian) ; l'extracteur le convertit en « numéro T » convivial pour les ingénieurs (ex. T8130), traduisant l'hexadécimal opaque en un nom de code de silicium lisible.

Techniques d'extraction à connaître

• Les gros fichiers contournent la limite d'aperçu. taskinfo, IODeviceTree.txt, IOService.txt et asptool_snapshot.log dépassent largement la limite d'aperçu de 4 000 lignes. Les extracteurs lisent le fichier entier avant l'analyse, de sorte que le classement de consommation d'énergie, les nœuds de la puce, le contrôleur NVMe et la santé du NAND ne sont jamais manqués.
• Regroupement multi-fichiers. Les CSV quotidiens des cycles de batterie (BDC_Daily_*.csv) sont regroupés en une seule carte « cycles de batterie » (valeur la plus récente) ; chaque crash .ips est regroupé dans une seule carte agrégée « rapports de crash ».
• Corrélation entre fichiers. Le nombre de cycles est lu à la fois à partir de la valeur B0CT actuelle du SMC et de l'historique BDC, puis comparé.

Historique et persistance

Chaque importation atterrit sous Application Support/SysdiagnoseCases/<serial_timestamp>, avec des métadonnées dans SysdiagnoseHistoryStore. Réimporter la même archive réutilise l'extraction existante (dédupliquée par caseId). La liste prend en charge le balayage pour supprimer et tout effacer, et se rouvre instantanément — car elle analyse uniquement l'aperçu, sans jamais relancer l'extraction.

Trois promesses intégrées

1. Entièrement hors ligne, sur l'appareil. De la décompression à l'extraction, aucune requête réseau n'est effectuée.
2. La lisibilité avant la performance. Le résultat de chaque analyse est une carte, pas le texte brut. Les champs d'origine sont conservés pour vérification mais masqués par défaut.
3. Robustesse de niveau production :
   • Protection contre la traversée de chemins, vérification préalable de l'espace disque, validation des en-têtes tar, nettoyage garanti des fichiers temporaires.
   • Garde-fous de rendu des fichiers : SysdiagnoseFileContent plafonne le texte à 512 Ko / 4 000 lignes et les CSV à 1 000 lignes ; les extracteurs lisent les fichiers entiers en tant que solution de repli, de sorte qu'un seul fichier ne puisse jamais saturer la mémoire.
   • Traduction des erreurs lisible par l'humain (transformant inflateFailed en « l'archive est endommagée ou le téléchargement était incomplet »).
   • Compatibilité des chemins entre les lancements (gérant à la fois les nouveaux chemins relatifs et les anciens chemins absolus du bac à sable).

Réflexions finales

Le Diagnostic Log Analyzer n'essaie pas d'afficher les plus de 2 000 fichiers d'un sysdiagnose. Il répond aux questions que vous vous posez réellement — Quel matériel est en cours d'exécution ? Ma batterie est-elle en bonne santé ? Quel est le niveau d'usure de mon stockage ? Pourquoi a-t-il planté récemment ? — et vous donne des réponses claires, partageables et vérifiables.

La capture est guidée, l'importation se fait en un seul toucher, la décompression n'affame jamais la mémoire, et l'écran n'affiche que des cartes. Pour le compagnon à long terme — tendances quotidiennes de la santé de la batterie à partir des journaux Analytics — consultez le guide du Battery Log Analyzer.