Notre méthodologie
Mis à jour le 2026-10-14
Check Panic Full compare la signature d'un log panic-full à 111 règles. Chaque règle cite au moins une source : wikis et Answers d'iFixit, l'étude DFRWS APAC 2025 par débranchement de modules, Repair Wiki et forums de réparation. Chaque règle a un niveau de confiance, les codes contestés montrent les deux lectures, et le résultat est toujours une pièce probable à confirmer.
Comment fonctionne l'analyse ?
Quand vous déposez un fichier panic-full, l'analyseur :
- Lit l'en-tête pour obtenir l'identifiant du modèle (
product) et la version d'iOS. - Extrait la signature du
panicString: la famille de panique, puis le code, le capteur manquant, le processus ou le composant du bus. - La compare à la base pour ce modèle précis.
- Affiche la pièce probable en 3D, avec une explication, le prochain test à faire et les pièges de réparation.
La clé d'une règle est le modèle + le type de panique + le code normalisé. C'est important, car le même code désigne des pièces différentes selon le modèle : 0x200000 est le capteur de proximité sur un iPhone 14 et la bobine de recharge sans fil sur un iPhone 15.
Quand plusieurs logs du même appareil sont analysés ensemble, le résultat montre la tendance qui s'en dégage. Une signature répétée est un indice bien plus fort qu'une panique isolée.
D'où viennent les 111 règles ?
Chaque règle cite au moins une source. Aucun diagnostic n'est écrit « de mémoire ». Les principales sources sont :
- iFixit : les wikis (dont le tableau des paniques SMC et sa référence des capteurs) et les fils Answers avec des cas résolus.
- DFRWS APAC 2025 : Song, Yang, Lee et al., A study on the recovery of damaged iPhone hardware exhibiting panic full phenomena. Les auteurs ont débranché les modules un par un sur plusieurs iPhone et relevé les codes obtenus. Ces tests contrôlés sont la source la plus fiable pour les valeurs sensor array.
- Repair Wiki et iPad Rehab : guides par modèle rédigés par des réparateurs.
- REWA et les forums de réparation (Apple Community, Apple Developer Forums, Elektroda et d'autres) pour des familles comme AOP, NAND, i2c et les watchdog timeouts.
Les sources sont indiquées sur chaque page de code.
Que signifient les niveaux de confiance ?
| Niveau | Signification |
|---|---|
| Haute | Plusieurs sources concordantes, ou un test contrôlé (DFRWS) confirmé par une autre source |
| Moyenne | Une bonne source, ou plusieurs sources avec des nuances |
| Basse | Cas isolé, source unique, extrapolation depuis un modèle proche ou modèle récent avec peu de données |
Chaque règle a aussi un statut :
- Source vérifiée : la règle vient directement d'une source citée.
- Contestée : les sources ne sont pas d'accord.
- IA, non confirmé : suggérée par une analyse IA, en attente de confirmation.
- Confirmée sur le terrain : appuyée par des cas de réparation signalés par des techniciens.
Comment les codes contestés sont-ils traités ?
Certains codes sont lus différemment selon les sources. Plutôt que d'en choisir un en silence, l'outil affiche les deux lectures et indique quelle source soutient laquelle. Quelques exemples :
- Sur un iPhone 14,
0x500000correspond au connecteur de charge + bobine de recharge sans fil selon le test de débranchement DFRWS, mais à la batterie selon iFixit et iPad Rehab. - Sur la série iPhone 13, le tableau iFixit donne
0x10000pour les capteurs avant, alors que Repair Wiki, iPad Rehab et l'exemple multi-pannes d'iFixit lui-même donnent0x1000. Le zéro en trop est probablement une coquille. - Sur un iPhone 14 Pro, iPad Rehab donne
0x10000pour la nappe power là où d'autres sources donnent0x100000.
Dans ces cas, testez les pièces dans l'ordre proposé, chacune avec une pièce connue bonne.
Que sont les cas terrain ?
Un cas terrain est une réparation signalée par un technicien : le log, la pièce remplacée, et si les paniques ont cessé. Avec le temps, les cas terrain confirment ou contredisent une règle. Quand vous réparez un appareil diagnostiqué par l'outil, nous dire ce qui a fonctionné améliore la base pour tout le monde.
Que deviennent les logs ?
Les logs sont conservés tels qu'ils sont envoyés, avec le résumé de leur diagnostic, pour améliorer les règles et reconnaître plusieurs logs d'un même appareil. Ils ne sont jamais vendus ni utilisés à des fins publicitaires. Le détail, durée de conservation comprise, figure dans la politique de confidentialité.
Quelles sont les limites ?
- Un log guide la réparation, il ne la remplace pas. L'outil donne une pièce probable. Confirmez toujours avec une pièce connue bonne avant de commander.
- La couverture est incomplète. Les modèles récents ont moins de données ; certaines familles ne sont pas encore documentées. Une signature inconnue est signalée comme telle plutôt que devinée.
- Les codes ne se transposent pas d'une génération à l'autre. Une règle valable pour un modèle n'est appliquée à un autre que si une source le dit.
- Plusieurs causes peuvent partager une même signature. Un connecteur oxydé ou une piste de carte mère peut produire le même code qu'une nappe morte.
- Les paniques logicielles existent. Un watchdog sur un processus logiciel demande souvent une restauration, pas une pièce.
Pour parcourir directement les règles, consultez le répertoire des codes ou le tableau panic full complet.