Une alternative à Macs Fan Control pour les développeurs

Pourquoi les utilisateurs de Macs Fan Control cherchent une alternative

Sur les Mac Intel, Macs Fan Control a bâti sa réputation honnêtement : relevés complets des capteurs sur le CPU, le GPU et les disques, plus des courbes de ventilateurs personnalisées capables de vraiment outrepasser le comportement conservateur d'origine d'Apple. Quand un Mac Intel chauffait sous charge soutenue, demander aux ventilateurs de tourner plus vite fonctionnait réellement.

Apple Silicon a changé la donne. Des rapports sur le tracker GitHub de l'app elle-même décrivent des MacBook Pro M3 et M4 Pro/Max où une valeur de ventilateur réglée manuellement se fait annuler en temps réel par le démon thermique de macOS, et où le firmware garde les ventilateurs complètement à l'arrêt en dessous d'environ 77-80°C, quoi que demande l'app. Crystalidea, l'éditeur de Macs Fan Control, a livré des correctifs pour des modèles précis à plusieurs reprises — une mise à jour mi-2025 aurait restauré un contrôle plus complet sur certaines configurations M3/M4 — mais l'expérience concrète reste inégale : un correctif pour une génération de puce ne se reporte pas toujours sur la suivante, et une mise à jour ponctuelle de macOS peut discrètement changer à nouveau ce qui est permis.

C'est la vraie raison pour laquelle les recherches « alternative à Macs Fan Control » existent. Ce n'est presque jamais que l'app s'est dégradée — c'est qu'Apple continue de déplacer le terrain sous ses pieds, et chercher un autre outil revient souvent, en réalité, à chercher quelque chose qui n'est pas à la merci de ça.

Les autres vraies apps de contrôle des ventilateurs : TG Pro et smcFanControl

TG Pro (de Tunabelly Software) est le remplaçant le plus direct si vous voulez une autre app payante de contrôle des ventilateurs. Elle est conçue pour les Mac Intel jusqu'aux Mac de la génération M5 actuelle, affiche la température de chaque cœur CPU individuellement sur Apple Silicon — un détail que Macs Fan Control ne fournit pas — et propose à la fois des règles automatiques et un contrôle manuel là où le matériel le permet encore.

smcFanControl est l'option gratuite, et elle ne prétend pas être autre chose que ce qu'elle est : open source, en pratique plus vraiment maintenue pour Apple Silicon, et de fait réservée aux Mac Intel. Si vous êtes encore sur un vieux MacBook Intel et ne voulez rien payer, elle fait le travail. Installez-la sur un Mac de la série M et vous obtiendrez une icône dans la barre de menu, sans réel contrôle des ventilateurs derrière.

Les deux se heurtent au même mur que Macs Fan Control sur les puces les plus récentes : sur Apple Silicon, le régime des ventilateurs (RPM) reste in fine une décision du firmware. Une app peut demander une vitesse ; que le Mac fasse effectivement tourner les ventilateurs à ce régime dépend du modèle exact, de la température et de la version de macOS — pas de l'app.

L'option gratuite et intégrée : laisser macOS gérer sa propre courbe

Vous n'avez besoin d'installer quoi que ce soit pour avoir une courbe de ventilateurs fonctionnelle — macOS en fait tourner une par défaut. C'est gratuit, ça ne demande aucune configuration, et Apple la règle de façon assez conservatrice pour qu'un laptop de développeur classique reste silencieux sous charge légère.

Ce que vous perdez sans app de monitoring, c'est la visibilité. Il n'existe aucun moyen natif de voir la température réelle de la puce ou le régime des ventilateurs, donc un build qui se fait discrètement brider ressemble, dans le Moniteur d'activité, à un build qui tourne à pleine vitesse — juste plus lent, sans cause apparente.

Cet écart pèse d'autant plus que la tâche est longue et sans surveillance. Une compilation rapide que vous surveillez, vous remarquerez si elle traîne. Un fine-tuning de plusieurs heures ou un agent IA laissé tourner toute la nuit, capot fermé, vous ne le remarquerez pas — et c'est précisément là qu'il vous faut quelque chose qui surveille le chiffre à votre place.

Le risque à courir après le contrôle des ventilateurs plutôt que de surveiller l'état thermique

Même quand le contrôle d'une app de ventilateurs fonctionne vraiment, forcer un régime plus élevé ne traite pas le vrai risque d'une longue exécution sans surveillance. Deux problèmes distincts sont souvent confondus : le Mac est bruyant ou bridé (gênant, généralement réglé par plus de flux d'air ou une courbe de ventilateurs plus agressive), et le Mac n'est pas sûr à laisser tourner (ce que forcer les ventilateurs ne règle pas — la bonne réponse, là, c'est d'arrêter, pas de pousser plus fort).

Sur Apple Silicon en particulier, puisque les commandes envoyées aux ventilateurs peuvent être discrètement annulées par le firmware en dessous de certaines températures, l'indication d'une app de ventilateurs affichant « ventilateurs à 100 % » n'est pas une garantie fiable du régime que le matériel autorise réellement. S'appuyer sur cette indication comme signal de sécurité comporte le même risque que faire confiance à n'importe quel contrôle que la plateforme peut annuler discrètement, sans prévenir.

C'est capot fermé que ça fait le plus mal. Un Mac qui génère de la chaleur sans flux d'air et sans personne pour surveiller, c'est exactement le scénario que toute app de contrôle des ventilateurs est la moins bien placée pour détecter — parce que le détecter suppose que quelqu'un regarde un graphique de capteurs, et par définition, personne ne regarde.

Où se situe LidRun — ce n'est pas un outil de ventilateurs

Pour être direct : LidRun ne contrôle pas vos ventilateurs, ni sur Apple Silicon ni sur Intel. Il n'envoie jamais de commande de ventilateur, et il ne s'attribuera pas le mérite d'un Mac plus silencieux. Ce qu'il fait, c'est surveiller le même signal thermique qu'une app de ventilateurs, et s'en servir pour décider s'il reste sûr d'empêcher votre Mac de se mettre en veille.

Concrètement, il combine la température SMC en direct et le pourcentage de throttle thermique du CPU avec l'API d'état thermique de macOS elle-même, parce que le signal au niveau OS, seul, peut prendre du retard sur la réalité — les propres tests de LidRun ont un jour surpris l'API en train de signaler un état simplement « correct » alors que la puce avait déjà chuté à 24 % de sa vitesse normale, à l'intérieur d'un sac fermé. À 98°C ou plus, ou un throttle à 50 % ou moins, LidRun considère ça comme sérieux et affiche un avis. À 100°C ou plus, ou un throttle à 30 % ou moins, c'est critique.

Ce qui se passe ensuite dépend du contexte. Avec le mode Closed-Lid actif et le Mac vraiment rangé — sur batterie, capot fermé, inactif depuis cinq minutes ou plus — LidRun laisse passer 60 secondes de pression sérieuse soutenue avant d'agir : il relâche sa prise pour laisser le Mac passer en veille clamshell tout seul si la situation est simplement sérieuse, ou force la mise en veille immédiatement, en outrepassant ce qui tourne, si elle est déjà critique. Un Mac cuit, c'est pire qu'un build perdu.

Sur secteur, avec quelqu'un présent, c'est plus doux. LidRun ne forcera pas la mise en veille d'un Mac avec le capot ouvert pendant que vous êtes au clavier — il n'intervient qu'une fois le capot vraiment fermé, ou après cinq minutes ou plus d'absence, et seulement après 120 secondes de pression soutenue, ou immédiatement si c'est critique. Le firmware garde la main sur les ventilateurs à tout moment ; LidRun est la couche au-dessus de la courbe, pas un remplacement de celle-ci.

Associer un outil de ventilateurs à LidRun pour vos longues sessions dev et IA

En pratique, utilisez TG Pro ou Macs Fan Control (ou rien du tout, sur un Mac récent) pour ce qu'ils font vraiment bien : voir les vrais chiffres et, là où le firmware le permet encore, ajuster légèrement la courbe. Utilisez LidRun pour le travail qu'aucun des deux n'a été conçu pour faire — garder Claude Code, Cursor, un build Docker ou une exécution xcodebuild en vie capot fermé, et s'effacer si la chaleur ou la batterie franchissent une limite pendant que personne ne surveille.

L'Auto-Watch de LidRun surveille les processus dont une app de ventilateurs n'a aucune raison de se soucier — claude, cursor, codex, aider, ollama, les jobs d'entraînement python et torchrun, jupyter, les builds node/npm/vite, cargo, xcodebuild, docker — en vérifiant toutes les 10 secondes par défaut, de sorte qu'il ne maintient le Mac éveillé que pendant qu'un de ces processus tourne réellement, pas indéfiniment.

Sur batterie, un plancher strict de 4 % s'applique toujours : en dessous, macOS peut ne plus avoir assez de marge pour terminer proprement sa mise en veille avant que la batterie ne s'épuise, donc LidRun force la mise en veille à ce seuil, quoi que soit réglé par ailleurs. Un second plancher, ajustable (20 % par défaut, plage de 5 à 50 %), régit spécifiquement les sessions de maintien en activité, si bien qu'une longue exécution IA peut s'arrêter d'elle-même bien avant le plancher strict, si vous préférez jouer la prudence.

Rien de tout ça ne remplace un vrai refroidissement. Un support, un ventilateur qui pousse de l'air vers les entrées d'admission, et rester sur secteur font toujours plus pour la température réelle d'un Mac Apple Silicon que n'importe quel logiciel — le rôle de LidRun est seulement d'aider à éviter qu'un incident thermique ne vous coûte aussi le travail en cours.