Lire la vraie température du CPU sur Mac Intel et Apple Silicon

Il n'existe aucune API Apple qui vous donne directement un chiffre

Ouvrez Activity Monitor et cherchez une colonne de température CPU : elle n'existe pas. Apple n'a jamais intégré d'affichage de température dans macOS, nulle part — ni dans Activity Monitor, ni dans les Réglages Système, ni via une quelconque API publique de température. Ce n'est pas un oubli : Apple considère les données des capteurs comme un détail interne de sa propre gestion thermique, pas comme quelque chose que les apps sont censées lire directement.

Tout ce qui vous montre malgré tout un chiffre, gratuit ou payant, contourne ce vide de la même manière : en parlant au SMC, ce petit contrôleur toujours actif placé entre macOS et les capteurs thermiques et ventilateurs réels. Il n'existe pas d'appel système « lire la température du CPU » : vous demandez au SMC une clé de capteur précise sur quatre caractères (comme TC0D ou Tp01), et il renvoie une poignée d'octets bruts qui ne veulent rien dire tant que vous ne savez pas comment les décoder.

C'est ça, la vraie réponse à « comment lire la température du CPU de mon Mac » : choisir la bonne clé pour ce Mac précis, puis décoder les octets renvoyés selon le format correct pour cette puce précise. Une erreur sur l'une ou l'autre étape, et vous obtenez un chiffre faux, voire aucun chiffre du tout — ce qui explique exactement pourquoi deux outils de température sur le même Mac peuvent se contredire, et pourquoi certains lecteurs n'affichent rien sur une puce toute nouvelle.

Les deux décodeurs : sp78 sur Intel, IEEE flt sur Apple Silicon

Le SMC ne renvoie pas un type numérique universel : chaque clé porte son propre type de données, et le décodeur doit s'y adapter exactement, sinon le résultat est inexploitable. Les clés de température utilisent deux formats différents selon l'architecture du Mac.

Sur les Mac Intel, la température revient au format sp78 : un nombre signé en virgule fixe 8.8, un octet pour les degrés entiers et un octet pour la fraction. Le décodage est une simple opération arithmétique — le premier octet lu comme un entier signé, plus le second octet divisé par 256. Les octets 0x31 0x80, par exemple, donnent 49 + 128/256 = 49,5 °C.

Sur Apple Silicon, la même famille de capteurs remonte au format flt : un nombre flottant IEEE-754 standard sur 4 octets, simplement stocké en little-endian plutôt que dans l'ordre d'octets auquel on s'attendrait. C'est exactement le même format flottant 32 bits utilisé partout ailleurs en logiciel — Apple range juste les octets dans l'ordre inverse.

La vitesse des ventilateurs (RPM) a elle aussi son propre découpage d'encodage — fpe2 en virgule fixe sur les anciens Mac Intel, flt sur les Mac Intel récents et sur tous les Mac Apple Silicon — donc un lecteur conçu uniquement pour les formats numériques d'une génération de puce lira mal, voire pas du tout, le matériel de l'autre côté de la transition. LidRun vérifie le type réellement annoncé par chaque clé avant de la décoder, plutôt que de supposer un seul format pour tout le Mac.

Il n'existe pas de clé unique « température du CPU » — et elle change à chaque puce

Même une fois capable de décoder une clé, encore faut-il savoir laquelle demander — et cela change selon le modèle de Mac et, sur Apple Silicon, selon la génération de puce.

Les Mac Intel sont relativement simples : les capteurs CPU se trouvent dans la famille TC0x — TC0D (die), TC0P (proximité), TC0E et TC0F (mesures filtrées/virtuelles), TCAD (package) — et la plupart des lecteurs pour Intel se contentent de sonder cette courte liste.

Sur Apple Silicon, c'est fragmenté à dessein, parce que la puce compte bien plus de zones thermiques distinctes qu'un simple « die » unique. Le M1 expose des clés de cœurs performance comme Tp01, Tp05 et Tp0D, un cluster CPU auxiliaire sous Tc0a/Tc0b, et des clés GPU sous Tg05/Tg0D. Le M2 ajoute des clés distinctes pour les cœurs efficacité (Tp1h, Tp1t) en plus de ses cœurs performance. Puis le M3 change carrément la convention de nommage : les clés des cœurs performance et du GPU passent à un nouveau préfixe Tf (Tf04, Tf09…) et les cœurs efficacité récupèrent leur propre préfixe Te — c'est la génération qui abandonne totalement Tp pour les cœurs CPU. Le M4 ramène Tp pour les cœurs performance tout en gardant Te pour l'efficacité. Le M5 ajoute encore un niveau de « super cœurs » sous ses propres suffixes Tp.

Voilà la vraie raison pour laquelle un lecteur de température peut fonctionner parfaitement puis n'afficher plus rien sur le tout prochain Mac que vous achetez : un outil avec une liste de clés M1/M2 codée en dur ne lit rien sur un M3, parce que les clés qu'il cherche n'existent plus là-bas — elles ont changé de lettre. Ce n'est pas un bug de votre Mac, c'est une liste de clés qui n'a pas été mise à jour pour la nouvelle puce.

LidRun gère ça en deux temps : essayer d'abord une liste statique de clés connues (rapide, aucun sondage nécessaire sur les Mac déjà reconnus), et si aucune ne renvoie de mesure, énumérer une fois toute la table de clés du SMC — de quelques centaines à environ un millier de clés selon le Mac — et ne garder que ce qui se décode en une température plausible sous les préfixes de capteurs die (Tp, Te, Tf, Tg, Tc), en écartant les capteurs de peau, d'ambiance et de batterie qui sous-estimeraient la chaleur réelle de la puce. Le résultat est mis en cache, donc les lectures suivantes ne coûtent presque rien.

Les moyens gratuits et natifs de vérifier vous-même

Vous n'avez pas besoin de LidRun, ni d'aucune app payante, pour voir un vrai chiffre. Quelques options gratuites existent, chacune avec une limite réelle qu'il vaut mieux connaître avant de lui faire confiance.

La commande pmset -g therm, intégrée au Terminal, est ce qui se rapproche le plus d'une commande de température livrée par macOS — mais lisez sa sortie avec attention : la ligne CPU_Speed_Limit qu'elle affiche n'est pas une température, c'est un pourcentage de limitation. 100 signifie que la puce n'est pas du tout bridée ; un chiffre plus bas signifie que macOS plafonne activement la vitesse du CPU pour gérer la chaleur. C'est un signal réellement utile pour savoir « est-ce que mon Mac est en difficulté là, maintenant », gratuit et déjà intégré, mais il ne vous montrera jamais un nombre de degrés.

Pour un vrai chiffre, il existe des lecteurs SMC gratuits et open-source qui font exactement le travail de clé-et-décodage décrit plus haut. Stats (exelban/stats) est une app de barre de menus gratuite et open-source qui suit les changements de noms de clés d'Apple Silicon version après version. Des outils en ligne de commande comme smctemp et osx-cpu-temp font le même décodage depuis le Terminal, sans interface graphique (osx-cpu-temp précède Apple Silicon et ne couvre qu'Intel).

Les outils payants ou freemium — iStat Menus, TG Pro, Macs Fan Control — lisent les mêmes clés SMC et ajoutent du soin en plus : graphiques d'historique, alertes, et dans le cas de TG Pro et Macs Fan Control, le contrôle des ventilateurs par-dessus la lecture. Aucun d'eux n'a accès à un chiffre qu'Apple cacherait à tous les autres ; ils font le même échange avec le SMC, avec simplement plus de maintenance derrière la liste de clés et une interface plus soignée autour.

Pourquoi deux apps affichent des chiffres différents

Si un outil affiche 68 °C et un autre 74 °C sur le même Mac au même instant, aucun des deux n'est forcément dans l'erreur. Ils lisent presque certainement un capteur différent, ou combinent plusieurs capteurs en un seul chiffre d'une façon différente.

Imaginons un Mac dont les huit capteurs de cœurs affichent entre 65 °C et 75 °C à cet instant précis. Un outil qui fait la moyenne des cœurs (l'approche adoptée par Stats et smctemp, pour une « température CPU actuelle » plus lisible) pourrait afficher 70 °C. Un outil qui reporte un capteur de package spécifique pourrait afficher 72 °C. Un outil qui reporte le capteur actif le plus chaud trouvé — l'approche de LidRun — affiche 75 °C. Les trois chiffres sont des lectures réelles et honnêtes du même silicium ; ils répondent simplement à des questions légèrement différentes.

La moyenne donne un chiffre plus lisse, plus représentatif au quotidien. Reporter le maximum est le choix le plus prudent dès qu'il s'agit de sécurité, parce que la limitation se déclenche quand le capteur die le plus chaud franchit son seuil — pas quand la moyenne le franchit. Un système qui doit décider s'il faut se rétracter, et pas seulement afficher un chiffre, a donc une vraie raison de préférer le pic à la moyenne.

La leçon pratique : traitez tout chiffre de température CPU comme la lecture d'un capteur et d'une méthode choisis par cet outil précis, pas comme la valeur vraie unique de votre Mac. Ce qui compte pour juger si quelque chose ne va vraiment pas, c'est la tendance sur les dernières minutes et l'ampleur de la montée — pas que votre chiffre corresponde au degré près à celui de l'outil d'un ami.

Le risque de ne faire confiance qu'à un seul lecteur

Le problème de génération de puce évoqué plus haut n'a rien d'hypothétique — il a déjà provoqué de vraies pannes documentées. btop, le moniteur système open-source très utilisé, a livré un lecteur de température qui n'implémentait que le décodeur sp78 ; comme il ne gérait jamais flt, il n'affichait silencieusement aucune température CPU sur tous les Mac Apple Silicon (un bug que le projet a suivi sous le ticket #1653) jusqu'à sa correction. Rien ne plantait, aucune erreur n'apparaissait — le chiffre était simplement absent, ce qui ressemble à « mon Mac n'a pas de capteur de température » plutôt qu'à « le décodeur de cet outil est incomplet ».

Le même type de panne s'applique aux listes de clés obsolètes, pas seulement aux décodeurs manquants : un lecteur conçu avant la sortie du M3 et jamais mis à jour ne lira rien sur un M3, parce que les clés de cœurs performance qu'il sonde (Tp01, Tp05…) n'y existent plus — ce sont désormais Tf04, Tf09. Une liste de clés obsolète et un décodeur manquant produisent exactement le même symptôme : une lecture vide ou nulle qui ressemble à un problème matériel alors que ce n'en est pas un.

Il existe un risque distinct, plus modeste, avec les outils qui vont plus loin que la simple lecture. Macs Fan Control, TG Pro et smcFanControl installent tous un daemon d'assistance privilégié pour pouvoir écrire dans le SMC — le mécanisme légitime que le contrôle des ventilateurs exige réellement, puisque Apple impose un helper signé Developer-ID au niveau root et qu'il n'existe pas de voie plus légère. Mais cela signifie qu'un second processus en arrière-plan a désormais la capacité de maintenir vos ventilateurs sur une cible manuelle. Si vous quittez l'app sans la remettre en mode automatique, ce daemon peut continuer à tourner avec son dernier réglage manuel au lieu de rendre la main à la courbe du firmware de macOS.

Rien de tout ça ne veut dire que ces outils ne sont pas fiables — Stats, TG Pro et Macs Fan Control sont activement maintenus et continuent de suivre chaque nouvelle génération d'Apple Silicon au fil des sorties, même si le support complet accuse parfois un retard d'une version ou deux sur la sortie d'une puce. Cela veut dire qu'un chiffre de température n'est jamais plus à jour que la liste de clés et le décodeur qui le produisent — et cette liste a changé, avec de vraies conséquences, à chaque nouvelle puce lancée par Apple.

Ce qui compte vraiment comme « trop chaud »

Une fois que vous avez un vrai chiffre, la question la plus difficile est de savoir qu'en faire — et il n'existe pas de seuil de sécurité unique valable pour tous les Mac, parce qu'Apple fait volontairement tourner ses puces près de leur plafond thermique en charge soutenue. C'est un fonctionnement normal, pas un signe d'alerte.

Les puces M1 sont conçues pour tourner jusqu'à environ 100 °C en charge lourde soutenue sans se dégrader — c'est le SoC qui fonctionne comme prévu, pas un défaut. Le M2 chauffe encore plus dans les mêmes conditions, dépassant couramment les 100 °C. Les Mac Intel se situent régulièrement entre 90 et 100 °C en charge, ce qui correspond simplement au comportement de cette architecture. Le MacBook Air sans ventilateur n'a aucun ventilateur sur lequel se rabattre — il gère la chaleur uniquement par la limitation, donc une lecture soutenue de 90-100 °C sur un Air fait partie de son enveloppe de fonctionnement normale, ce n'est pas la preuve que quelque chose cloche.

La limitation elle-même — la puce qui plafonne sa propre vitesse pour gérer la chaleur — démarre généralement autour de 95-100 °C sur la plupart des Mac récents, ce qui correspond à la protection matérielle qui fait son travail, pas à un signe que votre charge de travail a cassé quelque chose.

Parce qu'un seuil unique en degrés « sûr » ne tient pas la route d'un modèle à l'autre, le signal le plus utile est celui, qualitatif, qu'Apple a réellement conçu pour ça : ProcessInfo.thermalState, une évaluation à quatre niveaux (nominal, fair, serious, critical) définie par ce que votre Mac doit faire, pas par une température. C'est le signal auquel toute app bien conçue est censée réagir, et c'est sur lui que repose la réponse de sécurité de LidRun elle-même, plutôt que sur un seuil fixe en degrés qui se déclencherait à tort sur un Mac sain, normal, en charge réelle.

Où LidRun se situe

Lire la température n'est pas une fonctionnalité payante dans LidRun — chaque installation y a accès, sur Intel comme sur Apple Silicon, avec la même approche clé-et-décodage décrite plus haut : la clé valide la plus chaude de la liste active, sp78 ou flt selon ce que le SMC annonce réellement pour cette clé.

Si LidRun la lit, ce n'est pas pour vous montrer une jauge plus jolie que ce que font déjà les outils gratuits. C'est pour que la propre réponse de sécurité de LidRun dispose d'un vrai signal pendant qu'il maintient votre Mac éveillé pour un run d'agent. La promesse centrale de LidRun est simple : agent en cours → rester éveillé ; agent terminé ou situation dangereuse → relâcher, ou dormir. Ce n'est pas un wake lock aveugle qui maintient le Mac ouvert quoi qu'il arrive — le côté « dangereux » s'appuie d'abord sur thermalState, le signal officiellement documenté, complété par la température numérique et le pourcentage de limitation CPU comme vérification secondaire. En cas de chaleur critique, LidRun relâche toujours immédiatement son maintien d'éveil, sur n'importe quel Mac, couvercle ouvert ou fermé. Si le mode Closed-Lid est activé et que le couvercle est réellement fermé — le cas où la chaleur n'a nulle part où s'évacuer — une chaleur critique soutenue fait passer d'un simple relâchement à une véritable mise en veille, puisque la prévention de sommeil propre à Closed-Lid maintiendrait sinon le Mac éveillé malgré le relâchement. Couvercle ouvert, LidRun se contente de relâcher et ne force jamais la mise en veille d'un Mac que vous utilisez activement.

Le contrôle des ventilateurs est le seul endroit où LidRun reste délibérément modeste sur ce qu'il promet, en particulier sur Apple Silicon. La vitesse des ventilateurs y est une écriture protégée par le firmware — le contrôleur thermique du SoC gère activement la courbe et peut carrément rejeter une commande manuelle, et sur plusieurs puces Apple Silicon Pro/Max, le firmware refuse tout simplement de faire tourner les ventilateurs en dessous d'environ 75-79 °C, quoi que demande n'importe quelle app. C'est un vrai plafond matériel, pas une lacune dans l'ingénierie d'un outil en particulier. Considérez donc la lecture de température comme la couche fiable et toujours active, et gardez le Mac ventilé sur une surface dure et dégagée pendant les longs runs — cela fait encore plus pour la marge thermique que ce qu'une courbe de ventilateur peut promettre à elle seule.