Portable i7, lent comme une patate : quand les limites d’alimentation se moquent des acheteurs

Ce que vous avez acheté vs ce que vous avez reçu : l’illusion i7

« i7 » est un niveau de marque, pas une garantie de performance. Sur les portables, le même badge peut couvrir des siliciums très différents : nombre de cœurs variable, enveloppes de puissance soutenue différentes, et systèmes de refroidissement distincts. Même au sein d’un même modèle de CPU, les fabricants de portables définissent leurs propres limites. Deux CPU identiques dans deux châssis différents peuvent se comporter comme deux produits différents.

Voici la vérité gênante : pour les charges soutenues (compilation, rendu, exécution de VMs, traitement de données), vous achetez surtout le refroidissement et le budget d’alimentation. Le CPU est du voyage.

Le turbo boost existe pour vous donner un pic rapide. Le marketing adore les chiffres en rafale. Votre vie réelle préfère la soutenue. Si le portable est configuré pour des ventilateurs discrets, un châssis fin ou une longue autonomie, le CPU atteindra une limite de puissance, puis réduira sa fréquence vers quelque chose qui paraît offensant sur le papier.

Une blague sèche, parce que ça colle : Un i7 dans un portable fin, c’est comme une voiture de sport avec une pompe à vélo pour la conduite—super sur la brochure, étrange sur l’autoroute.

En tant que SRE, je me fiche du pic et je m’intéresse à la performance sous contrainte. Le monde des portables est une superposition de contraintes : limites de l’adaptateur secteur, limites du VRM, thermique, comportement de charge de la batterie, politiques d’alimentation OS, et parfois des « mises à jour de sécurité » qui modifient le comportement de boost du CPU. Vous avez besoin d’une méthodologie, pas d’intuitions.

Faits & histoire : comment on en est arrivé là (et pourquoi ce n’est pas nouveau)

Un peu de contexte aide, car ce problème de « mon CPU cher est lent » n’a pas commencé hier. Les réglages se sont juste complexifiés.

1. Intel Turbo Boost (ère 2008) a normalisé le « pic au-dessus de la fréquence de base », rendant la fréquence de base moins pertinente pour les tâches courtes et plus pertinente pour les tâches soutenues.
2. RAPL (Running Average Power Limit) a introduit un bridage de puissance appliqué par le matériel, permettant au firmware et à l’OS d’imposer des budgets de puissance package avec de vraies répercussions.
3. Le format thin-and-light est devenu la norme dans les années 2010 ; beaucoup de châssis ne peuvent pas dissiper 35–45W de façon soutenue sans produire un bruit de ventilateur que les vendeurs ne veulent pas.
4. Le tuning PL1/PL2/Tau est passé dans le domaine OEM : les constructeurs expédient différentes tables de puissance par SKU, parfois par version de BIOS, sans vous prévenir.
5. USB-C PD et des adaptateurs plus petits ont rendu courant le fait d’exécuter des CPU haut de gamme sur des adaptateurs « suffisants » pour charger mais pas pour charger-plus-charge complète.
6. Les ordonnanceurs modernes sont devenus topo­logie‑conscients (design big.LITTLE/hybride) ; les « cœurs rapides » vs « cœurs efficaces » peuvent amplifier l’effet des limites d’alimentation si le travail est réparti de façon inappropriée.
7. Les atténuations de sécurité ont modifié les profils de performance au fil des ans ; certaines charges en sont plus sensibles, et « c’était plus rapide l’année dernière » peut être vrai.
8. Les courbes de ventilateurs sont devenues un argument produit : le « mode silencieux » signifie souvent « limiter PL1 », pas seulement « démarrer les ventilateurs plus tard ».
9. Les politiques de santé de la batterie (seuils de charge, modes de conservation) modifient parfois à quel point le système puise dans l’AC vs la batterie lors des pics.

Aucun de ces éléments n’est un « bug » isolé. Combinés, ils expliquent comment votre i7 devient une patate tout en respectant techniquement la spécification.

Mode d’emploi de diagnostic rapide (vérifs 1/2/3)

Si vous voulez de la vitesse, il faut identifier quel mur vous frappe : puissance CPU, thermique CPU, puissance GPU, pression mémoire, IO de stockage, ou une « politique d’alimentation » qui est en fait un gouverneur rancunier.

Premier : confirmez que vous êtes en throttling (puissance vs thermique)

• Windows : Vérifiez « Thermal throttling » / « Power limit exceeded » dans HWiNFO (capteurs). Vérifiez aussi l’horloge CPU vs la base sous charge dans le Gestionnaire des tâches.
• Linux : Observez le comportement des fréquences, les compteurs de throttling et la consommation RAPL.

Deuxième : vérifiez les contraintes externes évidentes

• Adaptateur de puissance de mauvaise puissance, négociation USB-C PD défaillante, ou câble endommagé.
• Stations d’accueil qui limitent la distribution d’énergie sous charge.
• Fonctionnement en « silencieux » ou « économiseur de batterie » alors que le portable est branché (oui, ça arrive).

Troisième : identifiez le domaine limitant

• La puissance package CPU stagne près d’un plafond bas (par ex. 10–15W) → cap PL1, profil OEM, ou limite de l’adaptateur.
• Les températures montent à ~95–100°C puis les horloges chutent → throttling thermique, pâte thermique mauvaise, poussière, courbe de ventilateur, ou caloduc partagé avec le GPU.
• Le CPU a l’air correct, mais le système reste lent → échange sur disque (swap), latence de stockage, chiffrement/indexation en arrière-plan, ou tempête de pilotes/interruptions.

Quatrième : décidez de votre stratégie

• Si le châssis ne peut pas le refroidir, optimisez la soutenue par undervolting (là où c’est possible), améliorez le flux d’air, et appliquez des plans d’alimentation sensés.
• Si c’est une contrainte d’alimentation, corrigez la situation adaptateur/dock ou acceptez une performance soutenue inférieure.
• Si c’est une politique OS, ne laissez pas « équilibré » signifier « lent ».

Tâches pratiques : commandes, sorties, décisions (Windows & Linux)

On ne corrige pas ça en devinant. On le corrige en mesurant, en changeant une variable, et en re-mesurant. Ci‑dessous des tâches pratiques que j’exécuterais sur une machine réelle. Chaque élément inclut : commande, ce que la sortie signifie, et la décision à prendre.

Tâches Linux (ordinateurs Intel/AMD)

Tâche 1 : Identifier le modèle CPU et la topologie

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU op-mode(s):           32-bit, 64-bit
CPU(s):                   16
Model name:               13th Gen Intel(R) Core(TM) i7-1360P
Thread(s) per core:       2
Core(s) per socket:       12
Socket(s):                1

Ce que cela signifie : Confirme quel CPU vous avez réellement (et s’il s’agit d’un modèle de type P/U/H), ainsi que le nombre de cœurs/threads.

Décision : Si c’est un CPU basse consommation (souvent P/U), cessez d’attendre un comportement soutenu de type H à moins que le châssis ne soit exceptionnel.

Tâche 2 : Surveiller la fréquence CPU en direct et les indices de throttling

cr0x@server:~$ sudo turbostat --Summary --interval 2
turbostat version 2023.03.20 - Len Brown <lenb@kernel.org>
Summary: PkgWatt  12.34  CorWatt  7.89  GFXWatt  0.20  Totl%C0  65.12  Avg_MHz  1398
Summary: PkgWatt  12.10  CorWatt  7.55  GFXWatt  0.18  Totl%C0  64.88  Avg_MHz  1405

Ce que cela signifie : Sous charge, une puissance package (PkgWatt) autour de ~12W avec une faible Avg_MHz est un signe classique de « PL1 est bas ».

Décision : Si PkgWatt plafonne de manière suspecte alors que la charge est CPU-bound, enquêtez sur les limites de puissance et le plan d’alimentation avant d’accuser un « mauvais CPU ».

Tâche 3 : Vérifier le pilote de politique de fréquence CPU

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

Ce que cela signifie : Confirme quel pilote régit la fréquence. intel_pstate se comporte différemment d’acpi-cpufreq.

Décision : Si vous ajustez le comportement, sachez quel pilote vous avez ; les conseils varient.

Tâche 4 : Inspecter EPP (Energy Performance Preference) d’Intel P-state

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance_power

Ce que cela signifie : « balance_power » favorise l’efficacité ; cela peut rendre les charges en rafales moins réactives.

Décision : Sur l’AC, pour un travail sensible à la performance, envisagez de régler EPP sur « balance_performance » ou « performance ».

Tâche 5 : Mettre EPP en performance (temporaire)

cr0x@server:~$ echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
performance

Ce que cela signifie : Force une préférence de performance agressive. Si votre portable « se réveille » soudainement, la politique était un contributeur majeur.

Décision : Si cela améliore la réactivité, implémentez une règle udev/systemd AC plutôt que de laisser cela ad hoc.

Tâche 6 : Vérifier le governor actuel (le cas échéant)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Ce que cela signifie : Sous intel_pstate, « powersave » ne signifie pas automatiquement « lent », mais avec certaines configurations de distribution cela peut corréler avec un comportement conservateur.

Décision : Si le système est lent sur AC, envisagez de modifier la politique via power-profiles-daemon ou tuned plutôt que de forcer manuellement les governors.

Tâche 7 : Vérifier l’état AC vs batterie (oui, ça compte)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/line_power_AC
  native-path:          AC
  power supply:         yes
  online:               yes

Ce que cela signifie : Confirme que l’OS vous croit sur AC. Certains docks/câbles provoquent des oscillations qui vous maintiennent en politique basse consommation.

Décision : Si « online: no » alors que vous êtes branché, réparez d’abord le chemin d’alimentation (adaptateur, câble, dock).

Tâche 8 : Inspecter les limites RAPL (Intel)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone: intel-rapl:0 (enabled)
  Power consumption: 11.92 W
  Constraint 0 (long_term):
    Power limit: 12.00 W
    Time window: 28.00 s
  Constraint 1 (short_term):
    Power limit: 35.00 W
    Time window: 0.00 s

Ce que cela signifie : Une limite de puissance long terme à 12W signifie que les charges soutenues ne dépasseront jamais ce que 12W peut fournir.

Décision : Si la puissance long terme est déraisonnablement basse sur AC, vérifiez les modes de performance OEM/BIOS. Changer cela par logiciel peut être bloqué ou dangereux.

Tâche 9 : Capturer les signaux de throttling thermique dans les logs du noyau

cr0x@server:~$ sudo dmesg | egrep -i 'throttl|thermal|powercap' | tail -n 8
[  912.441] intel_rapl_common: RAPL package 0 domain package locked by BIOS
[  918.102] thermal thermal_zone0: critical temperature reached
[  918.103] CPU0: Core temperature above threshold, cpu clock throttled

Ce que cela signifie : « locked by BIOS » signifie que vous ne pouvez pas surcharger les limites de puissance depuis l’OS. Un message critique thermal indique un vrai problème de chaleur.

Décision : Si le BIOS verrouille la puissance et que vous êtes en throttling thermique, concentrez-vous sur le refroidissement et les profils OEM plutôt que de combattre le noyau.

Tâche 10 : Vérifier la pression mémoire et le swapping (le tueur silencieux)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            16Gi        14Gi       410Mi       1.2Gi       1.6Gi       820Mi
Swap:           8Gi        6.5Gi       1.5Gi

Ce que cela signifie : Un usage intensif du swap rend tout lent « comme si le CPU était lent » car les tâches bloquent sur l’IO et les défauts de page.

Décision : Si le swap est actif pendant un travail normal, ajoutez de la RAM, réduisez les applis/VMs en arrière-plan, ou ajustez swappiness et la charge de travail.

Tâche 11 : Mesurer la latence du disque sous charge (NVMe peut encore être le goulot)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    3.00   18.20    0.00   66.70

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await  aqu-sz  %util
nvme0n1          45.0   3800.0     0.0    0.00   22.50    84.4     30.0   6400.0   35.10    1.90   99.00

Ce que cela signifie : Un %util élevé et de grands temps d’attente indiquent une saturation du stockage. Si votre build est I/O-heavy, le CPU peut sembler sous-utilisé.

Décision : Si le NVMe est saturé, examinez le throttling thermique du SSD, l’indexation en arrière-plan, ou un mauvais motif de filesystem/charge de travail.

Tâche 12 : Vérifier la santé et la température NVMe

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
temperature                             : 79 C
available_spare                         : 100%
percentage_used                         : 3%
media_errors                            : 0
num_err_log_entries                     : 0

Ce que cela signifie : 79°C est élevé pour un SSD. Beaucoup throttlent dans la gamme 70–80°C, plongeant les performances au milieu d’une tâche.

Décision : Si les températures du SSD sont élevées, améliorez le flux d’air, ajoutez un pad thermique/heatsink (si possible), et évitez les écritures soutenues sur des surfaces molles.

Tâches Windows (PowerShell et outils intégrés)

Windows a une excellente télémétrie si vous la demandez correctement. Utilisez PowerShell et les outils intégrés avant d’installer une ménagerie d’outils-tweak.

Tâche 13 : Voir votre schéma d’alimentation actif et s’il vous sabote

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Ce que cela signifie : Balanced n’est pas automatiquement mauvais, mais les OEM le modifient souvent de façon agressive.

Décision : Si vous effectuez un travail soutenu sur AC, testez High performance / Ultimate Performance (quand disponible) et comparez les fréquences soutenues.

Tâche 14 : Générer un rapport d’énergie pour des mauvaises configurations évidentes

cr0x@server:~$ powercfg /energy /duration 60
Enabling tracing for 60 seconds...
Energy efficiency problems were found.
19 Informational warnings were found.
See C:\Windows\system32\energy-report.html for more details.

Ce que cela signifie : Le rapport signale les périphériques empêchant la mise en veille, les pilotes défaillants et les bizarreries de politique d’alimentation.

Décision : Si le rapport pointe des réglages de gestion d’alimentation du processeur ou des problèmes de timer plateforme, corrigez-les en priorité—faible effort, fort impact.

Tâche 15 : Vérifier si le système se croit en économiseur de batterie

cr0x@server:~$ powercfg /requests
DISPLAY:
None.

SYSTEM:
None.

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
[PROCESS] \Device\HarddiskVolume3\Windows\System32\SearchIndexer.exe

Ce que cela signifie : Pas un flag direct d’économiseur de batterie, mais montre les requêtes actives et peut indiquer des tâches d’arrière-plan volant les fenêtres de pic.

Décision : Si l’indexation est constamment active pendant les périodes « lentes », laissez-la finir, planifiez-la, ou réduisez les emplacements indexés.

Tâche 16 : Surveiller la fréquence CPU et les compteurs de throttling (PerfMon via logman)

cr0x@server:~$ logman query counters | findstr /i "processor performance"
\Processor Information(_Total)\% Processor Performance
\Processor Information(_Total)\Processor Frequency
\Processor Information(_Total)\% of Maximum Frequency

Ce que cela signifie : Ces compteurs vous permettent de corréler « lent » avec « CPU plafonné à 40% de la fréquence max ».

Décision : Si % of Maximum Frequency est bas sous charge, vous êtes limité par la politique ou l’alimentation, pas par un « CPU faible ».

Tâche 17 : Valider l’état de l’adaptateur et de la batterie (sanity check rapide)

cr0x@server:~$ powercfg /batteryreport
Battery life report saved to file path C:\Windows\system32\battery-report.html.

Ce que cela signifie : Le rapport peut montrer le comportement récent de charge/décharge ; des décharges fréquentes sur AC sous charge indiquent un adaptateur sous-alimenté.

Décision : Si le portable se décharge alors qu’il est branché sous charge, arrêtez tout et réparez la livraison d’énergie (adaptateur de bonne puissance, câble, dock).

Tâche 18 : Vérification rapide des problèmes de « pile de pilotes incorrecte » (PowerShell)

cr0x@server:~$ pnputil /enum-drivers | findstr /i "intel amd chipset"
Published Name : oem42.inf
Driver Package Provider : Intel
Class : System
Driver Version : 10.1.20020.8623

Ce que cela signifie : Confirme que des drivers chipset/système existent et sont relativement récents. De mauvais drivers chipset peuvent casser la gestion d’énergie moderne.

Décision : Si les drivers chipset sont anciens ou manquants, installez le package OEM ou du fournisseur de plateforme avant d’essayer des réglages exotiques.

Deuxième blague, courte et pertinente : les vendeurs de portables traitent les limites d’alimentation comme les compagnies aériennes traitent l’espace pour les jambes—techniquement présent, fonctionnellement négocié.

PL1, PL2, Tau, EPP : les réglages qui décident de votre sort

Si vous ne retenez qu’une chose : les portables sont gouvernés davantage par des budgets d’alimentation dans le temps que par les GHz annoncés. Ce sont PL1/PL2/Tau en termes Intel, et des concepts similaires existent ailleurs.

PL1 : votre vitesse soutenue

PL1 est la limite de puissance long terme. C’est l’indicateur le plus honnête de la vitesse que votre portable peut maintenir pendant des minutes sans violer sa propre politique. Si PL1 est à 12W, vous pouvez avoir un i7, un i9, ou une patate cérémonielle—le calcul soutenu ressemblera à 12W.

PL1 est souvent lié à la thermique et aux objectifs de nuisance sonore. Les vendeurs le réglent pour garder le châssis confortable et les ventilateurs discrets. Ce n’est pas de la malveillance ; c’est du design produit. Mais c’est aussi pourquoi les acheteurs se sentent trompés.

PL2 : le sprint

PL2 est la limite de puissance court terme. C’est ainsi que votre portable obtient de gros scores de benchmark : il monte fort pendant une courte fenêtre, puis redescend. Si vos tâches sont en rafales (ouverture d’applis, petites éditions), PL2 compte. Si vous compilez une grosse base, PL1 est votre patron.

Tau : combien de temps dure le sprint

Tau (fenêtre temporelle) contrôle la durée du maintien de PL2 avant que le système ne se stabilise vers PL1. Les OEM jouent fortement sur Tau. Un long Tau fait que le portable semble « rapide » lors des démos. Un court Tau le rend « consistant » mais plus lent.

EPP / Speed Shift : à quel point le CPU est prompt

EPP (Energy Performance Preference) et les réglages Intel Speed Shift influencent la rapidité de montée en fréquence du CPU et la manière dont il échange performance contre énergie. Sur certaines configurations, un EPP conservateur rend le système lent même si les limites de puissance sont généreuses. C’est de la politique, pas de la physique.

Le verrouillage firmware : « le BIOS gère maintenant »

Beaucoup de portables verrouillent les limites de puissance dans le firmware. Vous verrez des indices comme « locked by BIOS ». Cela signifie :

• Les ajustements logiciels peuvent ne pas tenir.
• Les mises à jour BIOS peuvent modifier le comportement du jour au lendemain.
• Votre meilleur levier peut être le profil de performance OEM (Quiet/Balance/Performance), pas un outil tiers.

L’angle fiabilité (et la citation)

Les opérations préfèrent en général des systèmes prévisibles plutôt que des systèmes avec des pointes. La gestion d’alimentation est censée créer de la prévisibilité, mais sur les portables elle crée souvent des surprises.

« L’espoir n’est pas une stratégie. » — Gene Kranz

C’est pourquoi nous mesurons, journalisons et validons les changements. Votre portable mérite le même respect que vous accordez à une machine de production—simplement avec plus d’empreintes digitales.

Stockage et « réalité SRE » : quand ce n’est pas le CPU (mais ça y ressemble)

En tant qu’ingénieur stockage, j’ai vu des « le CPU est lent » se révéler être : throttling thermique du SSD, schémas de fragmentation du filesystem, antivirus scannant chaque fichier objet, ou un job de chiffrement en arrière-plan qui explose la profondeur de queue NVMe.

Les limites d’alimentation peuvent rendre les goulots de stockage plus difficiles à repérer parce que tout s’étire : les compilations prennent plus de temps, vous rencontrez plus de tâches d’arrière-plan ; le système passe plus de temps en états mixtes CPU+IO ; et les ventilateurs tournent de façon imprévisible car les sources de chaleur varient.

Indicateurs typiques de « fausse lenteur CPU »

• Haut iowait sur Linux, ou faible utilisation CPU sur Windows alors que le système semble figé.
• Pauses intermittentes plutôt qu’un calcul constamment lent.
• Effondrements de performance pendant de gros écrits (téléchargements, mises à jour, images VM) et récupération ensuite.

Que faire quand le stockage est le goulot

• Vérifier la température et le throttling du SSD (journaux SMART NVMe).
• Vérifier l’espace disponible ; les disques presque pleins peuvent mal se comporter selon le contrôleur et le filesystem.
• Valider que votre « SSD rapide » n’est pas un QLC bas de gamme avec un petit cache SLC vidé par des écritures soutenues.

C’est là que les tests de portables aident rarement : ils exécutent des benchs propres sur des systèmes neufs. Votre portable, après six mois de vie, est une machine différente.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise où j’ai travaillé a standardisé sur un « portable développeur premium ». La fiche technique semblait parfaite : i7, 32Go RAM, NVMe, toute la liste de courses corporate. L’hypothèse était simple : plus cher = plus rapide = moins de plaintes.

Puis les temps de build ont commencé à dériver. D’abord quelques ingénieurs. Puis la plupart d’une équipe. L’histoire qu’on se racontait était « le repo a grossi » ou « le CI est lent ». Mais la douleur se produisait sur les machines locales : latence de frappe dans les IDE pendant les builds, ventilateurs discrets, et CPUs flottant à des horloges suspectement basses.

Nous avons mesuré. Sous compilation soutenue, la puissance package se stabilisait à un plafond bas. Les machines étaient sur des docks USB-C qui annonçaient une forte puissance mais négociaient moins sous certaines charges périphériques. Les portables compensaient en puisant dans la batterie pour les pics, puis se repliaient pour protéger la santé de la batterie. Le résultat était une dent de scie de performance : brèves montées, longs creux.

La mauvaise hypothèse était que « branché » soit binaire. En réalité, la distribution d’énergie est un contrat négocié, et les docks sont ce genre de manager intermédiaire qui dit oui en réunion et non sur le terrain.

Correctif : certifier un combo adaptateur/dock par modèle et l’imposer. Ce n’était pas glamour. Les plaintes ont disparu et les temps de build se sont stabilisés. Pas de hacks firmware. Juste une hygiène d’alimentation basique.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait des portables plus silencieux. Open-space, appels à répétition, et un VP convaincu que le bruit des ventilateurs était de « l’électricité gaspillée ». Ils ont déployé un profil « quiet » OEM via l’outil de management. Le profil abaissait les courbes de ventilateur et réduisait les limites de puissance pour garder les surfaces fraîches.

Ça a fonctionné—en quelque sorte. Les portables étaient silencieux. Mais les ingénieurs ont commencé à voir des échecs de test sporadiques et des lenteurs. Les échecs étaient subtils : timeouts dans des tests d’intégration, automatisations UI flaky, et des conteneurs locaux qui mettaient une éternité à démarrer. Personne n’a relié ça à la politique ventilateur parce que « pourquoi des réglages ventilateurs briseraient-ils des tests ? »

Voici comment : le profil silencieux clouait PL1 bas. Les longues exécutions de tests prenaient plus de temps. Certains tests avaient des timeouts codés en dur optimisés pour d’anciennes durées. En plus, la puissance soutenue moindre faisait passer le CPU plus souvent dans des fréquences intermédiaires où certains seuils thermiques déclenchaient des micro-throttles. Pas catastrophique—juste assez de variation pour créer de la flaky.

L’optimisation visait à « réduire le bruit », et elle a produit « réduire la déterminisme ». Dans les organisations d’ingénierie, la déterminisme est une fonctionnalité. Les ventilateurs silencieux sont une préférence.

Correctif : proposer le mode silencieux en option, pas par défaut sur toute la flotte ; et pour les builds/tests, standardiser un profil performance sur AC. Aussi : arrêtez de coder des timeouts serrés sauf si vous aimez les pannes mystères auto-infligées.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une troisième entreprise a eu un résultat étonnamment bon, et ce n’était pas parce qu’ils avaient des portables magiques. Ils avaient une règle ennuyeuse : chaque modèle de matériel passait par une mise en service de deux semaines avec des charges standardisées—boucles de compilation, builds de conteneurs, appels vidéo, usage d’écran externe, et cycles de batterie.

Ils journalisaient de la télémétrie basique : fréquence CPU soutenue sous une charge fixe, consommation package, températures SSD, et état de la source d’alimentation. Rien d’invasif. Pas de surveillance intrusive. Juste des données d’ingénierie sur le comportement de la machine en conditions réalistes.

Pendant une de ces périodes, une nouvelle version de BIOS a réduit silencieusement les limites de puissance soutenue pour atteindre un objectif de conformité thermique. Les benchmarks restaient corrects, car la fenêtre turbo n’avait pas changé. Mais leur test de soak a détecté immédiatement la baisse soutenue : même charge, fréquence d’équilibre plus basse et variance de runtime plus élevée.

Ils ont gelé ce BIOS pour les machines développeur jusqu’à ce que le fabricant fournisse une option de tuning corrigée. Cela les a sauvés d’un mois entier de « pourquoi tout est plus lent ? ». La pratique était ennuyeuse. C’était aussi la chose la plus proche d’une exploitation professionnelle de portables que j’ai vue en production.

Erreurs courantes : symptôme → cause racine → correctif

C’est la partie où on arrête de se battre avec les impressions et où l’on cartographie les symptômes aux vrais modes de défaillance.

1) « Le CPU bloqué à 0,8–1,6 GHz même sous charge »

• Cause racine : PL1 bas sur AC, mode OEM silencieux, ou politique OS qui bride la perf max.
• Correctif : Passer au profil performance sur AC ; vérifier PL1 via RAPL/turbostat ; mettre à jour le BIOS ; s’assurer de l’adaptateur de bonne puissance.

2) « Rapide pendant 20–60 secondes, puis chute brutale »

• Cause racine : Fenêtre de boost PL2 (Tau) qui se termine ; le système redescend sur un PL1 bas ; ou soak thermique déclenche le throttling.
• Correctif : Améliorer le refroidissement (nettoyer ventilateurs, surélever l’arrière, repaster si justifié) ; choisir le mode performance ; accepter que les châssis fins ont des limites.

3) « Lent uniquement quand branché à un dock »

• Cause racine : Négociation USB-C PD qui bride la puissance ; le dock réserve de l’énergie pour les périphériques ; le câble ne supporte pas la puissance annoncée.
• Correctif : Utiliser l’adaptateur OEM directement ; remplacer le câble par un certifié haute puissance ; mettre à jour le firmware du dock ; vérifier via le rapport batterie que la machine ne se décharge pas sur AC.

4) « Les ventilateurs sont discrets mais la perf est nulle »

• Cause racine : Le profil silencieux abaisse PL1 et retarde la montée en régime des ventilateurs, forçant le throttling pour maintenir la température des surfaces.
• Correctif : Utiliser le profil balanced/performance pour les sessions de travail ; ne pas confondre acoustique et efficacité.

5) « La perf chute après une mise à jour Windows / BIOS »

• Cause racine : Tables de puissance modifiées, microcode, tuning du scheduler, ou utilitaire OEM qui réinitialise les profils.
• Correctif : Re-vérifier le plan d’alimentation actif ; revoir les modes thermiques/performance OEM ; si un BIOS a changé PL1, revenir en arrière (si sûr) ou demander un correctif au fournisseur.

6) « Le CPU a l’air correct, mais tout saccade pendant les builds »

• Cause racine : Throttling thermique SSD ou IO d’arrière-plan intense (indexation, antivirus, sync).
• Correctif : Vérifier la température SMART du NVMe ; réduire la portée de l’indexation ; suspendre la sync pendant les builds ; assurer suffisamment d’espace libre.

7) « Le portable se décharge en étant branché sous charge »

• Cause racine : Adaptateur sous-alimenté, cap du dock, ou politique santé batterie qui limite la prise.
• Correctif : Utiliser l’adaptateur de bonne puissance ; éviter d’alimenter des périphériques lourds depuis le même dock ; vérifier les tendances du rapport batterie ; remplacer adaptateur/câble défaillant.

8) « Linux semble plus lent que Windows sur le même matériel »

• Cause racine : EPP conservateur par défaut, drivers plateforme manquants, ou power-profiles-daemon réglé sur power saver.
• Correctif : Confirmer intel_pstate et EPP ; régler le mode performance sur AC ; installer les paquets kernel/firmware appropriés ; vérifier que les limites thermiques et de puissance ne sont pas verrouillées par le BIOS à des valeurs basses.

Checklists / plan étape par étape

Voici le parcours pragmatique que je recommanderais à un ami, un collègue, ou à mon moi passé avant d’avoir appris mieux.

Étape 1 : Établir une ligne de base du problème (15 minutes)

1. Brancher l’adaptateur OEM directement (pas de dock).
2. Fermer les applis lourdes en arrière-plan (outils de sync, VMs) pour le test.
3. Exécuter une charge soutenue pendant 5–10 minutes (build, rendu, stress test).
4. Consigner : fréquence CPU soutenue, puissance package, température CPU, et si la performance chute après une minute.

Résultat : Vous déterminez si vous êtes limité par la puissance, la thermique, ou l’IO.

Étape 2 : Corriger le plus grand goulot d’abord

• Si limité par la puissance : vérifier la puissance de l’adaptateur ; désactiver le mode silencieux ; passer à un plan performance ; mettre à jour BIOS et utilitaire OEM.
• Si limité par la thermique : nettoyer les entrées/sorties d’air/ventilateurs ; utiliser une surface dure ; surélever l’arrière ; envisager une repaste si les températures sont extrêmes et que la garantie le permet.
• Si limité par l’IO : vérifier la température du SSD ; réduire l’indexation/scan en arrière-plan ; assurer de l’espace libre ; envisager un SSD meilleur si c’est un modèle bas de gamme.

Étape 3 : Valider avec la même charge

Même charge, même durée, même source d’alimentation. Comparez la puissance package soutenue et la fréquence d’équilibre. Si vous ne pouvez pas reproduire, vous ne pouvez pas réparer.

Étape 4 : Rendre cela durable (pour éviter une régression la semaine suivante)

• Définir explicitement les profils AC vs batterie.
• Documenter quel dock/adaptateur/câble est approuvé.
• Après les mises à jour BIOS, relancer votre test de référence.

Étape 5 : Savoir quand s’arrêter

Si le refroidissement de votre portable fin dissipe 15–20W silencieusement, c’est la réalité. Vous pouvez tuner autour, mais vous ne pouvez pas négocier avec la physique. À ce stade, achetez pour le châssis et le refroidissement, pas pour les labels de gamme CPU.

FAQ

1) Pourquoi mon i7 tourne en dessous de sa fréquence de base ?

La fréquence de base n’est pas une garantie dans toutes les conditions ; elle suppose un certain budget de puissance/thermique. Si le portable est contraint en puissance ou en thermique, il peut descendre sous la base pour rester dans les limites.

2) Que sont PL1 et PL2 en langage courant ?

PL2 est « à quel point il peut sprinter ». PL1 est « à quel point il peut travailler toute la journée ». Pour les compilations et tâches longues, PL1 est le chiffre que vous ressentez.

3) Mon portable est branché—pourquoi est-il encore limité en puissance ?

Parce que « branché » ne signifie pas « suffisamment de watts livrés ». La négociation USB-C PD, les docks et les câbles peuvent plafonner la puissance. De plus, les profils OEM peuvent imposer des limites basses même sur AC.

4) L’undervolting est‑il sûr ?

L’undervolting peut être sûr s’il est fait de façon conservative et testé, mais le support plateforme varie et certains systèmes le bloquent. L’instabilité se manifeste par des plantages, des gels, ou des erreurs de calcul silencieuses—donc il faut stress tester. Si vous ne pouvez pas valider la stabilité, ne le faites pas.

5) Pourquoi le portable est rapide juste après le boot, puis lent plus tard ?

Soak thermique et tâches d’arrière-plan. Au démarrage : système froid, plein turbo. Dix minutes plus tard : le châssis se réchauffe, les ventilateurs atteignent leur courbe, PL1 et les limites thermiques prennent le relais, et l’indexation/sync commence à consommer des ressources.

6) Un SSD peut‑il faire paraître un i7 « lent » ?

Oui. Le throttling thermique du SSD ou une IO saturée peuvent bloquer tout le système. Votre CPU peut attendre le stockage tout en semblant sous-utilisé.

7) Dois‑je utiliser High performance / Ultimate Performance sur Windows ?

Pour un travail soutenu sur AC, c’est un bon diagnostic et souvent une solution pratique. Si l’autonomie et le bruit importent plus, utilisez Balanced mais assurez-vous que les logiciels OEM ne brident pas secrètement le CPU.

8) Sur Linux, quel est le gain le plus rapide pour la réactivité ?

Vérifier EPP et les profils d’alimentation sur AC. Si vous êtes en « power saver » ou que EPP est « balance_power », passer en performance sur AC peut rendre le système nettement plus réactif.

9) La pâte thermique est‑elle vraiment la coupable ?

Parfois, surtout après un ou deux ans ou avec une application d’usine « juste correcte ». Mais ne commencez pas par là. Si vous êtes limité en puissance à 12–15W, la repaste ne débloquera pas une perf de 45W.

10) Comment éviter d’acheter un autre portable « i7 lent » ?

Achetez pour la performance soutenue : des tests qui incluent des runs longs, le bruit des ventilateurs sous charge, et la puissance package en état stable. Priorisez l’épaisseur du châssis et le refroidissement plutôt que le niveau de badge. Demandez la puissance de l’adaptateur et s’il existe des modes de performance.

Conclusion : prochaines étapes qui fonctionnent vraiment

Si votre portable i7 est lent, partez du principe qu’il est contraint, pas maudit. Faites le diagnostic rapide : confirmez le throttling, validez le chemin d’alimentation, puis identifiez si vous heurtezz la puissance, le thermique ou l’IO.

Prochaines étapes pratiques :

• Testez directement avec l’adaptateur OEM et confirmez que vous êtes vraiment sur AC.
• Mesurez la puissance package soutenue et la température sous une charge constante.
• Passez à un profil performance sur AC ; sur Linux, corrigez EPP/profil d’alimentation.
• Si la thermique est le mur : nettoyez, surélevez, et envisagez un service/repaste en respectant la garantie.
• Si le stockage est le mur : vérifiez la température SSD et la saturation IO ; stoppez la churn en arrière-plan pendant les travaux lourds.
• Rendez votre correctif durable : documentez les réglages, re-testez après les mises à jour BIOS/OS, et ne laissez pas un dock renégocier silencieusement votre productivité.

Les acheteurs méritent des chiffres de performance soutenue sur la boîte. Jusqu’à ce jour, vous devrez gérer votre portable comme une petite machine de production : mesurer, changer un réglage, mesurer encore.