Les 8 cœurs suffisent-ils encore pour tout le monde en 2026 ? La réponse honnête

La réponse honnête : qui est encore couvert par 8 cœurs (et qui ne l’est pas)

8 cœurs ne couvrent « tout le monde » que si votre définition de tout le monde est figée en 2018. En 2026, un CPU 8 cœurs peut être excellent. Il peut aussi être un goulot silencieux qui gaspille de coûteux GPU, ralentit les pipelines CI et fait tomber des nœuds de production au pire moment.

8 cœurs suffisent encore pour :

• Travail de bureau typique (navigateur, documents, Slack, visioconférences), même avec quelques onglets « chargés ». La mémoire compte plus que les cœurs ici.
• Gaming à paramètres raisonnables, surtout si le moteur du jeu dépend encore principalement de quelques threads chauds. Une bonne performance par cœur compte plus que 16 cœurs médiocres.
• Travail créatif léger (retouche photo occasionnelle, petits projets dans une station audio, montages vidéo amateurs) si vous n’exécutez pas plusieurs applications lourdes en même temps.
• La plupart des services de home lab (DNS, Home Assistant, quelques conteneurs, petit NAS) à condition que votre stockage n’effectue pas de compression/chiffrement inline lourds sur le CPU.
• Développement en nœud unique si votre flux de travail n’implique pas de recompilations constantes de gros dépôts ou l’exécution de plusieurs bases de données en local.

8 cœurs sont souvent insuffisants pour :

• Compilations sérieuses (monorépos C++, gros projets Rust, builds Android). Vous pouvez paralléliser les builds, mais vous ne pouvez pas paralléliser l’absence de cœurs sans payer en temps.
• Runners CI où la concurrence coûte de l’argent. Sous-dimensionnez vos runners et votre « équipe rapide » devient une expérience de théorie des files d’attente.
• La réalité moderne du « poste de travail développeur » : un IDE, navigateur, Kubernetes local, plusieurs serveurs de langage, quelques bases de données, plus des agents de sécurité. C’est la charge « mort par mille threads ».
• Hôtes fortement virtualisés (plusieurs VM faisant un vrai travail). L’overcommit est un outil, pas un style de vie.
• Piles de stockage qui travaillent réellement (déduplication, compression, chiffrement, checksum à haut débit). Le stockage peut solliciter fortement le CPU, surtout si vous voulez à la fois vitesse et intégrité.
• Nœuds de production pour services sensibles à la latence quand vous avez un grand nombre de connexions, TLS partout, et des tâches en arrière-plan (GC, compactage, indexation) qui ne demandent pas la permission.

Ce que je dis aux gens qui veulent une règle en une ligne : si vous pouvez décrire votre journée par « j’exécute une chose principale à la fois », 8 cœurs peuvent être excellents. Si votre journée est « j’exécute dix choses et chacune se croit principale », achetez plus de cœurs ou vous passerez votre vie à attendre.

Le nombre de cœurs n’est pas une identité de performance (et « 8 cœurs » n’est même pas un nombre)

« 8 cœurs » sonne comme une spécification. En pratique, c’est une impression. Le nombre de cœurs sans contexte, c’est comme dire qu’un camion a « quatre roues » en s’attendant à savoir s’il peut transporter du gravier.

Les quatre axes de performance que l’on confond constamment

1. Performance mono-thread : fréquence sous charge, IPC, hiérarchie de caches, prédiction de branchements. C’est pourquoi certains processeurs 8 cœurs semblent plus réactifs que certains 16 cœurs.
2. Débit parallèle : combien de travail vous pouvez effectuer quand la charge s’échelonne réellement sur les cœurs. Compilateurs, moteurs de rendu, encodeurs, CI, certaines tâches de base de données.
3. Capacité et bande passante mémoire : les cœurs n’aident pas si vous paginez ou si tous les cœurs se battent pour la bande passante RAM.
4. Latence et débit I/O : stockage, réseau, comportement du système de fichiers et le pattern I/O de l’application. Beaucoup de « problèmes CPU » sont des problèmes I/O déguisés en CPU.

En 2026, 8 cœurs peut signifier des choses très différentes. Il existe des CPU où 8 cœurs « gros » sont des monstres, et d’autres où 8 cœurs sont un mélange de cœurs performance et efficients avec un comportement d’ordonnancement très différent. Il y a aussi des systèmes où le CPU est majoritairement inactif parce que vous êtes bloqué sur la latence NVMe, la latence réseau ou la contention de verrous.

Une chose de plus : votre OS et vos runtimes comptent. Conteneurs, cgroups, affinité de VM, gouverneurs d’échelle de fréquence CPU et effets de voisin bruyant peuvent faire que « 8 cœurs » se comporte comme « 5 cœurs le mardi ».

Blague #1 : Si vous avez déjà dit « mais il a 8 cœurs » lors d’un post-mortem de performance, félicitations — vous avez rencontré la version adulte de « mais je l’ai redémarré ».

Faits et historique qui expliquent pourquoi cela a semé la confusion

Un peu de contexte aide parce que « 8 cœurs » est devenu un défaut culturel pour des raisons qui avaient du sens à l’époque.

• Fait 1 : Pendant des années, les CPU grand public se sont stabilisés autour de 4 cœurs, en grande partie parce que les gains mono-thread continuaient et que beaucoup de charges ne se parallélisaient pas bien. Puis le nombre de cœurs a rapidement augmenté quand les processus et la dynamique du marché ont changé.
• Fait 2 : L’hyper-threading (SMT) a embrouillé les gens qui ont cru que « threads = cœurs ». SMT aide le débit sur certaines charges, aide à peine sur d’autres, et peut nuire à la latence de queue dans certains cas de forte contention.
• Fait 3 : Vers la fin des années 2010 et début 2020, 8 cœurs est devenu le « sweet spot » parce que le gaming et l’usage desktop général bénéficiaient davantage d’une forte performance par cœur et d’une parallélisation décente que d’un plus grand nombre de cœurs.
• Fait 4 : La généralisation du TLS (HTTPS partout, service mesh, mTLS) a augmenté le travail CPU par requête. Les services modernes font plus de cryptographie et de parsing que les stacks anciens.
• Fait 5 : Le NVMe a réduit la latence de stockage et augmenté le débit, ce qui a exposé des surcoûts CPU là où on ne les attendait pas — checksums, compression, overhead du noyau, housekeeping du système de fichiers et des bases de données.
• Fait 6 : Les « microservices » n’ont pas seulement changé l’architecture ; ils ont changé le développement local et les tests. Exécuter « juste le service » signifie souvent exécuter une petite ville de dépendances.
• Fait 7 : Les CPU modernes sont devenus parfois plus asymétriques dans certaines gammes (cœurs performance vs cœurs efficients). Un « nombre de cœurs » brut peut cacher que vos 8 cœurs ne sont pas égaux.
• Fait 8 : L’économie du cloud a poussé les équipes à plus consolider. Une consolidation plus élevée augmente le risque d’interférence et rend les erreurs de dimensionnement CPU plus coûteuses.
• Fait 9 : L’observabilité s’est améliorée, mais est aussi devenue plus lourde. Metrics, tracing et logging peuvent consommer du CPU — surtout en situation d’incident quand vous activez « juste un peu plus de détails ».

Quand les gens demandent « 8 cœurs suffisent-ils », ce qu’ils demandent vraiment est : « ce système sera-t-il réactif lors de ma pire journée ? » Ce n’est pas une question de spécification. C’est une question de charge de travail.

Une matrice de décision que vous pouvez réellement utiliser

Voici la version directe. Commencez par votre charge principale, puis ajustez pour la concurrence et la « réalité en arrière-plan ».

Choisir 8 cœurs en 2026 si :

• Vous priorisez la réactivité pour un seul utilisateur et votre CPU a une forte performance par cœur.
• Vos tâches lourdes sont par intermittence (compilation occasionnelle, export occasionnel) et vous pouvez tolérer d’attendre parfois.
• Vous n’exécutez pas plusieurs services lourds en local et vous ne virtualisez pas beaucoup de VM.
• Votre stockage est rapide et simple (NVMe, pas de crypto/compression inline lourde à l’échelle NAS).

Achetez 12–16+ cœurs si :

• Vous faites des compilations, rendus, encodages plus qu’occasionnellement.
• Vous privilégiez le débit plutôt que la « sensation réactive » (CI, jobs batch, traitement de données, hôtes conteneurisés).
• Vous exécutez Kubernetes local ou beaucoup de conteneurs et voulez qu’ils soient rapides simultanément.
• Vous exécutez des VM qui font un travail réel et voulez de l’isolation sans contention CPU permanente.
• Vous exécutez des bases de données localement avec des jeux de données réalistes et voulez une latence prévisible en faisant d’autres travaux.

Ne décidez pas uniquement sur le nombre de cœurs

Deux CPU 8 cœurs peuvent différer massivement en fréquences soutenues toutes-coeurs, cache et bande passante mémoire. De plus : le refroidissement et les limites d’alimentation comptent. Un laptop « 8 cœurs » qui bride sous compilation soutenue n’est pas la même chose qu’un 8 cœurs desktop avec marge.

Mon biais opérationnel : si vous pouvez vous le permettre, achetez assez de cœurs pour garder 30–40% de marge en pic normal. La marge absorbe les pics de déploiement, les compactages en arrière-plan, les scans antivirus et le travail « surprise » que quelqu’un lancera en plein incident.

Tâches pratiques : commandes qui vous disent si 8 cœurs suffisent

Ci-dessous des tâches réelles à exécuter sur des serveurs et postes Linux. Chaque point inclut : une commande, ce que signifie la sortie et la décision à prendre. C’est comme ça que vous arrêtez de deviner.

Tâche 1 : Confirmer ce que « 8 cœurs » signifie sur cette machine

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
Model name:                           ExampleCPU 8-Core Processor

Sens : Vous avez 8 cœurs physiques et SMT activé, donc 16 CPU logiques. « 8 cœurs » ici sont des cœurs physiques, pas du marketing.

Décision : Pour les services sensibles à la latence, considérez les threads SMT comme une capacité partielle. Pour les charges de débit, SMT peut aider. Validez avec des tests de charge.

Tâche 2 : Vérifier le comportement de fréquence sous charge (le throttling est un tueur silencieux)

cr0x@server:~$ grep -E "cpu MHz" /proc/cpuinfo | head
cpu MHz         : 3592.000
cpu MHz         : 3610.123
cpu MHz         : 3588.765

Sens : Les horloges actuelles sont proches du boost attendu. Si vous voyez les horloges s’effondrer sous charge soutenue, vos 8 cœurs peuvent se comporter comme 6.

Décision : Si les fréquences chutent fortement lors d’une compilation soutenue ou d’un encodage, améliorez le refroidissement/limites d’alimentation ou choisissez un CPU avec une meilleure performance toutes-coeurs soutenue.

Tâche 3 : Identifier saturation CPU vs pression de la file exécutable

cr0x@server:~$ uptime
 14:22:10 up 12 days,  3:18,  2 users,  load average: 12.45, 10.80, 9.92

Sens : Une charge moyenne ~12 sur un système 16 threads n’est pas automatiquement « mauvaise », mais suggère de la file d’attente. Sur une machine 8 cœurs/16 threads, une charge soutenue > 16 signifie souvent contention ou I/O bloquante comptée comme exécutable.

Décision : Si la charge moyenne est élevée et la latence mauvaise, approfondissez (file d’attente, iowait, et principaux consommateurs). N’achetez pas de cœurs avant de confirmer que c’est lié au CPU.

Tâche 4 : Voir si vous êtes CPU-bound ou en attente d’I/O

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server)  01/10/2026  _x86_64_  (16 CPU)

01:22:11 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %steal  %idle
01:22:12 PM  all  62.00   0.00  12.00    0.50   0.00   1.20    0.00  24.30
01:22:13 PM  all  64.50   0.00  11.20    0.40   0.00   1.10    0.00  22.80

Sens : Un %usr élevé avec %iowait faible suggère du travail CPU. Un %iowait élevé suggère un goulet de stockage ou des I/O bloquants.

Décision : Si vous êtes CPU-bound, plus de cœurs ou une meilleure performance par cœur peuvent aider. Si l’iowait est élevé, concentrez-vous sur le stockage avant de changer le CPU.

Tâche 5 : Trouver les processus gourmands CPU (et vérifier s’ils se scalent)

cr0x@server:~$ top -b -n 1 | head -20
top - 14:22:40 up 12 days,  3:19,  2 users,  load average: 12.10, 10.90, 10.05
Tasks: 312 total,   3 running, 309 sleeping,   0 stopped,   0 zombie
%Cpu(s): 63.2 us, 11.4 sy,  0.0 ni, 24.7 id,  0.5 wa,  0.0 hi,  0.2 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
18422 app       20   0 2316828 221340  36204 R  690.0   1.3  12:10.12 java
 9912 db        20   0 4010320 820112  52320 S  220.0   4.8  41:22.90 postgres

Sens : Un processus à 690% CPU utilise environ 7 cœurs de calcul. C’est une vraie parallélisation. Si c’est votre chemin critique, 8 cœurs peuvent rapidement manquer.

Décision : Pour des consommateurs multicœurs soutenus (JVM, builds, encodage), ajoutez des cœurs ou isolez les charges via cgroups/conteneurs/VM.

Tâche 6 : Vérifier la pression mémoire (le paging imite le « CPU lent »)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        27Gi       1.2Gi       1.1Gi       3.8Gi       3.1Gi
Swap:          8.0Gi       2.4Gi       5.6Gi

Sens : Peu de mémoire disponible plus un usage swap non négligeable est un risque de performance. Un upgrade CPU ne vous sauvera pas si vous swappez.

Décision : Ajoutez de la RAM ou réduisez l’empreinte mémoire avant d’acheter plus de cœurs. Si vous ne pouvez pas éviter le swap, vos « 8 cœurs » font l’administration disque, pas du travail utile.

Tâche 7 : Confirmer l’activité réelle d’échange (swap) (pas seulement la swap allouée)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0 248576 1184300  92160 2998200   0    0    15    40 1100 2200 61 12 26  1  0
 9  1 248576  954200  92160 2970000  80   120   600   980 1800 4200 35 10 45 10  0

Sens : Un si/so non nul indique un échange actif vers/depuis le swap. Cela peut détruire la latence en queue.

Décision : Si le swap se produit en charge normale, traitez-le comme un incident de capacité. Ajoutez de la RAM, réduisez la concurrence ou corrigez les fuites mémoire avant de débattre 8 vs 16 cœurs.

Tâche 8 : Détecter les pics de latence stockage (classique « CPU idle mais c’est lent »)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server)  01/10/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.12    0.00    8.10    9.80    0.00   41.98

Device            r/s     w/s   rMB/s   wMB/s  await  svctm  %util
nvme0n1          220.0   140.0   55.2    21.1   8.60   0.20  74.0

Sens : await est le temps moyen par I/O. S’il est élevé (pour NVMe, « élevé » peut être quelques millisecondes sous charge selon le pattern), vous êtes bloqué sur le stockage.

Décision : Si await et %util sont élevés, corrigez le chemin de stockage (profondeur de file, système de fichiers, paramètres de la base, voisin bruyant) avant d’ajouter des cœurs CPU.

Tâche 9 : Vérifier l’espace disque et l’épuisement des inodes (oui, ça arrive)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  810G   45G  95% /

cr0x@server:~$ df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2  5900000 5800000 100000   99% /

Sens : Systèmes de fichiers remplis à 95% et épuisement d’inodes peuvent rendre les opérations douloureusement lentes et casser les applications de façon étrange.

Décision : Corrigez la pression disque d’abord. Une mise à niveau de 8 à 16 cœurs ne rendra pas « plus d’espace disque » plus optimiste.

Tâche 10 : Mesurer la saturation réseau et les pertes (le CPU peut être innocent)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       1200     0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  2456789  0       800      0       0

Sens : Des paquets perdus sous charge peuvent provoquer des retransmissions et de la latence. Ce « service lent » peut être la file NIC ou la congestion en amont, pas votre nombre de cœurs.

Décision : Si les pertes augmentent avec le trafic, ajustez qdisc, les buffers NIC ou la capacité. Un upgrade CPU ne réparera pas la perte de paquets.

Tâche 11 : Vérifier le throttling CPU des conteneurs (les cœurs existent, mais vous n’avez pas le droit de les utiliser)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 12873422340
user_usec 10122344000
system_usec 2751078340
nr_periods 90321
nr_throttled 18200
throttled_usec 9234000000

Sens : Un nr_throttled et un throttled_usec élevés signifient que les cgroups limitent le CPU. Le nœud peut avoir 64 cœurs ; votre conteneur vit peut-être avec un régime.

Décision : Si le throttling corrèle avec la latence, augmentez les limites/requests CPU, ajustez les quotas ou répartissez les charges. Ne blâmez pas « 8 cœurs » si vous avez configuré 2.

Tâche 12 : Vérifier le CPU allocatable du nœud Kubernetes vs requests (détection d’illusion de capacité)

cr0x@server:~$ kubectl describe node worker-01 | sed -n '1,120p'
Name:               worker-01
Capacity:
  cpu:                16
Allocatable:
  cpu:                15500m
Non-terminated Pods:          (22 in total)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests      Limits
  cpu                14000m (90%)  22000m (141%)

Sens : Des requests à 90% signifient que le scheduler considère le nœud presque plein. Des limits à 141% signifient que vous êtes surcommit et pariez sur le fait que tout le monde ne sera pas occupé en même temps.

Décision : Si vous observez du throttling fréquent ou des pics de latence, réduisez l’overcommit ou passez à plus de cœurs par nœud (ou plus de nœuds).

Tâche 13 : Trouver les « tempêtes de context switch » (trop de threads exécutables)

cr0x@server:~$ pidstat -w 1 3
Linux 6.8.0 (server)  01/10/2026  _x86_64_  (16 CPU)

14:25:01   UID       PID   cswch/s nvcswch/s  Command
14:25:02  1001     18422   1200.00   8500.00  java
14:25:02  999       9912    800.00   2200.00  postgres

Sens : De nombreux context switches non volontaires (nvcswch/s) suggèrent que des threads sont préemptés — souvent par contention CPU, parfois par contention de verrous.

Décision : Si la préemption est élevée et la latence mauvaise, ajoutez des cœurs ou réduisez les threads exécutables (réglez les pools de threads, la concurrence, le GC, les tâches en arrière-plan).

Tâche 14 : Vérifier le steal CPU en virtuel (quelqu’un d’autre utilise « vos » cœurs)

cr0x@server:~$ mpstat 1 3 | tail -n +4
01:28:01 PM  all  48.00   0.00  10.00    0.20   0.00   0.90    6.50  34.40
01:28:02 PM  all  50.10   0.00  10.40    0.30   0.00   0.80    7.20  31.20

Sens : Un %steal autour de 6–7% signifie que l’hyperviseur ne vous donne pas tout le temps CPU. Votre instance peut sembler « correcte » mais sous-performer.

Décision : Si le steal est persistant, passez à une instance plus grande, des hôtes dédiés ou réduisez la consolidation. Acheter plus de cœurs dans la VM ne servira à rien si l’hôte est survendu.

Tâche 15 : Mesurer le parallélisme réel d’une compilation (vérif réalité développeur)

cr0x@server:~$ /usr/bin/time -v make -j8
        Command being timed: "make -j8"
        User time (seconds): 742.12
        System time (seconds): 91.44
        Percent of CPU this job got: 765%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:48.92

Sens : ~765% CPU signifie que la build a utilisé ~7.6 cœurs efficacement. Sur un système 8 cœurs, vous êtes proche du plafond ; tout autre travail se battra pour le CPU.

Décision : Si les builds sont une douleur quotidienne, passez à 12–16+ cœurs ou répartissez les builds. C’est l’un des cas les plus clairs où « plus de cœurs » résout le problème.

C’est le schéma : ne demandez pas « 8 suffisent ? » Demandez « où est-ce que je bloque, et quel est le coût ? » Puis dimensionnez en conséquence.

Guide de diagnostic rapide : trouver le goulet sans s’attacher à une théorie

Voici l’ordre que j’utilise quand un système « semble lent » et que quelqu’un veut acheter un CPU plus puissant. C’est volontairement ennuyeux. L’ennuyeux est rapide.

Premier : identifier si vous êtes CPU-bound, mémoire-bound ou I/O-bound

1. Vue rapide CPU : mpstat -P ALL 1 3 et uptime. Si %idle est bas et la charge élevée, la pression CPU est réelle.
2. Vue rapide mémoire : free -h et vmstat 1 5. Tout swap actif est un signal rouge pour la réactivité et la latence en queue.
3. Vue rapide I/O : iostat -xz 1 3. Si await monte et %util est élevé, les cœurs ne sont pas le problème.

Deuxième : localiser le principal coupable et le classer

1. Niveau process : top ou ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head pour identifier le consommateur dominant.
2. Niveau thread (si nécessaire) : des context switches élevés (pidstat -w) peuvent révéler de la contention, une explosion de pools de threads ou du thrashing GC.
3. Niveau conteneur : vérifiez le throttling cgroup (/sys/fs/cgroup/cpu.stat) avant d’accuser le matériel.

Troisième : valider avec une petite expérience

• Réduire la concurrence (baisser le nombre de workers) et voir si la latence s’améliore. Si oui, quelque chose est saturé.
• Pin et isoler (déplacer le job bruyant sur un autre nœud/VM) et voir si le service revient. Si oui, vous avez besoin soit de plus de cœurs soit d’une meilleure isolation.
• Changer le pattern I/O (writes en batch, ajuster les checkpoints DB, désactiver un log debug pathologique) et voir si await baisse.

Ce n’est qu’après cela que vous décidez si 8 cœurs sont insuffisants. Le but est d’acheter la bonne correction, pas la correction réconfortante.

Trois mini-récits d’entreprise (anonymisés, plausibles et douloureux)

Mini-récit 1 : L’incident causé par une fausse hypothèse (« 8 cœurs suffisent pour un nœud cache »)

Une entreprise de taille moyenne exploitait une API interne populaire derrière une couche cache. Ils migraient vers de nouvelles instances et standardisèrent sur « 8 cœurs, RAM décente » pour les nœuds cache car le cache stockait surtout des données chaudes et ne faisait pas beaucoup de calcul. Du moins, telle était la logique.

La migration coïncida avec deux autres changements : activation du TLS entre services (mTLS) et activation de la compression des payloads pour certaines grosses réponses. Aucun n’était controversé. Chacun était raisonnable. Ensemble, sur une couche cache 8 cœurs en pic, ils créèrent la tempête parfaite : chiffrement, compression et un agent d’observabilité étonnamment bavard se partageant le même budget CPU.

Pendant un pic de semaine normale, la latence p95 doubla. Puis le p99 devint non linéaire. Le hit rate du cache ne changea pas beaucoup, ce qui induisit en erreur le triage initial. Les graphiques CPU montraient « seulement » 70–80% d’utilisation, ce qui paraissait correct aux managers. Mais la file exécutable était élevée, les context switches étaient fous, et le système passait trop de temps à jongler avec des threads qui voulaient tous faire de petites tâches.

La correction ne fut pas un réglage magique du noyau. Ils augmentèrent le nombre de cœurs à 16 sur les nœuds cache et réduisirent l’overhead par requête en groupant certaines métriques. La latence revint. La leçon fut gênante : quand vous ajoutez des fonctionnalités coûteuses en CPU (TLS, compression, tracing), votre couche « simple » cesse d’être simple.

Par la suite, ils mirent à jour leur template de capacity planning : tout service qui termine TLS à hautes QPS est testé pour le CPU par requête avec un jeu de chiffrement et un profil de logging réalistes. Pas théorique. Réel.

Mini-récit 2 : L’optimisation qui a échoué (tout rendre « plus parallèle » sur 8 cœurs)

Une autre organisation avait un service d’ingestion de données « trop lent ». Un ingénieur fit ce que font les bons ingénieurs : il augmenta la concurrence. Plus de threads. Plus de goroutines. Des pools plus grands. Le service faisait surtout de petites transformations et écrivait dans une base. Cela semblait un candidat parfait pour la parallélisation.

Sur les hôtes 8 cœurs, le débit s’améliora dans des tests synthétiques. En production, la latence partit en vrille. L’utilisation CPU n’était pas saturée à 100%, mais la latence en queue devint mauvaise. L’équipe base de données se plaignit du churn de connexions. Les SREs observèrent des context switches élevés et de la contention de verrous à l’intérieur du runtime applicatif. L’iowait disque monta car la base recevait des écritures en rafale et effectuait plus fréquemment des fsync.

Ils avaient optimisé le mauvais niveau : le système n’était pas « sous-parallèle », il était sous-contrôlé. Huit cœurs n’étaient pas le vrai problème ; la concurrence non contrôlée l’était. L’optimisation contre-productive transforma un flux fluide en contention.

La correction finale fut une combinaison : plafonner la concurrence pour correspondre à la capacité CPU et DB réelle, introduire une file avec backpressure, et regrouper les écritures. Après cela, les mêmes boxes 8 cœurs firent mieux que la version « optimisée » jamais ne l’avait fait.

Blague #2 : Augmenter la concurrence sans backpressure, c’est comme ajouter des voies à une autoroute en peignant des lignes sur le capot de votre voiture.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (marge et isolation)

Une équipe de services financiers exécutait un ensemble de services sur Kubernetes. Leur type de nœud par défaut était 16 cœurs, mais ils gardaient un pool de nœuds 8 cœurs pour le « petit » et les environnements dev. La pratique ennuyeuse : ils appliquaient des requests reflétant la réalité, gardaient de la marge CPU et utilisaient des pod disruption budgets pensés.

Un après-midi, un job batch censé s’exécuter hebdomadairement fut déclenché plusieurs fois à cause d’un bug de scheduler en amont. Il atterrit sur le pool de petits nœuds parce que le job « semblait petit » sur le papier. Il n’était pas petit : il faisait de la compression lourde et des checksums sur des fichiers multi-gigaoctets, puis expédiait les résultats sur le réseau.

La différence avec les récits précédents fut la discipline. Les nœuds avaient de la marge et le job avait une limite CPU qui l’empêcha de tout accaparer. Le job s’exécuta plus lentement, certes. Mais les services orientés client ne tombèrent pas. Les alertes se déclenchèrent, des humains intervinrent, et ils déplacèrent le job vers le pool grand pendant qu’ils corrigeaient le bug de scheduler.

Le résumé post-incident n’était pas héroïque. Il était presque agaçant de normalité : « les requests étaient exactes, le throttling a empêché l’étouffement, et la marge a gardé la plateforme stable. » C’est le genre d’ennuyeux que vous voulez en production.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom : le CPU est « seulement » à 60–70%, mais la latence est terrible

Cause racine : file exécutable, contention de verrous ou throttling cgroup. Le %CPU masque la mise en file d’attente et l’ordonnancement.

Correctif : vérifiez la charge (uptime), pidstat -w pour les context switches, et cpu.stat des cgroups pour le throttling. Réduisez la concurrence, ajustez les pools de threads, ou augmentez les limites CPU.

2) Symptom : le système « saccade » toutes les quelques minutes

Cause racine : travaux en arrière-plan périodiques : cycles GC, checkpoints DB, compactage, scans antivirus ou rotation de logs avec compression.

Correctif : planifiez les tâches lourdes hors-pic, réglez les checkpoints/compactages, isolez les jobs en arrière-plan ou ajoutez des cœurs si vous ne pouvez pas déplacer le travail.

3) Symptom : le poste interactif semble lent, mais les benchs sont bons

Cause racine : scaling de fréquence, thermal throttling, ou trop de services d’arrière-plan se battant pour le CPU en rafales courtes.

Correctif : validez les horloges soutenues, ajustez le profil d’alimentation/gouverneur, améliorez le refroidissement et évitez d’exécuter Kubernetes local plus trois bases sur un laptop 8 cœurs si vous voulez du « snappy ».

4) Symptom : la base de données chauffe après activation de la compression/chiffrement

Cause racine : le surcoût est déplacé du stockage au compute. La compression peut échanger I/O contre CPU ; le chiffrement ajoute souvent un coût par page/par connexion.

Correctif : mesurez le CPU par requête et l’iowait. Envisagez l’accélération matérielle, ajustez le niveau de compression, ou augmentez les cœurs. Validez avec des requêtes réelles, pas des microbenchmarks.

5) Symptom : la VM a des performances incohérentes entre instances « 8 cœurs » identiques

Cause racine : steal CPU dû à la contention de l’hôte ou aux voisins bruyants.

Correctif : vérifiez le %steal. Passez à des hôtes dédiés, réduisez la surallocation ou choisissez des types d’instances avec de meilleures garanties.

6) Symptom : le pipeline CI ralentit à mesure que l’équipe grandit

Cause racine : la concurrence de build a dépassé les cœurs des runners ; la mise en file domine. Autre cas courant : caches partagés sur stockage lent.

Correctif : ajoutez des cœurs aux runners et augmentez le débit de stockage, ou segmentez les pipelines. Si vous gardez des runners 8 cœurs, ajoutez plus de runners et isolez les jobs lourds.

7) Symptom : « Nous sommes passés à 16 cœurs et rien n’a changé »

Cause racine : le goulet était la mémoire, la latence stockage, des verrous DB ou des pertes réseau. Ou l’application ne se parallélise pas.

Correctif : exécutez le guide de diagnostic rapide. Identifiez si la charge s’échelle avec le CPU. Ne payez pas pour des cœurs que votre charge ne peut pas utiliser.

8) Symptom : le CPU du serveur de stockage est chaud pendant les sauvegardes

Cause racine : overhead checksum/compression/chiffrement ou I/O aléatoire petits blocs provoquant des overheads noyau et système de fichiers.

Correctif : ajustez les tailles d’enregistrement/bloc où approprié, réglez la compression, déplacez le chiffrement, ou augmentez les cœurs. Vérifiez aussi que le stockage n’est pas saturé (await/%util).

Listes de vérification / plan pas à pas (ce que je ferais avec mon argent et mon pager)

Checklist A : Acheter un CPU pour un poste de travail en 2026

1. Listez vos 3 charges soutenues principales (compilation, encodage, cluster local, VMs). « Navigation web » n’est pas une charge soutenue sauf si vous travaillez dans la publicité en ligne.
2. Estimez la concurrence que vous exécutez réellement : nombre de VM, conteneurs, tâches IDE, agents d’arrière-plan.
3. Décidez ce que vous optimisez : interactivité (mono-thread) ou débit (multi-cœur). Vous ne pouvez pas optimiser les deux au maximum avec tous les budgets.
4. Fixez un objectif de marge : visez un pic normal ≤ 70% CPU. Si vous êtes toujours à 90%, vous vivez sur la timeline d’incident.
5. Ne lésinez pas sur la RAM : si vous débattez 8 vs 16 cœurs en ayant 16 Go de RAM, vous optimisez la mauvaise partie.
6. Validez le stockage : un NVMe rapide avec une latence stable rendra un système 8 cœurs plus agréable qu’un système 16 cœurs attaché à un stockage triste.

Checklist B : Dimensionner un nœud serveur (hôte VM, worker Kubernetes, box base de données)

1. Mesurez le CPU par unité de travail : requêtes par seconde, jobs par minute, builds par heure. « %CPU » n’est pas une unité de travail.
2. Trouvez le comportement p95 et p99 : la moyenne d’utilisation ment. La latence tail est là où apparaissent paging et contention.
3. Vérifiez le steal time (virtualisé) : si vous avez du steal, votre nombre de cœurs est de la fiction.
4. Confirmez la latence I/O : si l’await stockage monte, ajouter du CPU accélère la durée d’attente.
5. Planifiez l’isolation : séparez les jobs batch bruyants des services sensibles à la latence via des pools de nœuds, cgroups ou instances dédiées.
6. Capacity planifiez pour les fonctionnalités : TLS, compression, tracing, migrations de schéma, construction d’index. Ce n’est pas gratuit.

Checklist C : Si vous devez garder 8 cœurs, comment faire fonctionner le tout

1. Réduisez la concurrence non contrôlée : pools de threads, nombre de workers, fan-out asynchrone.
2. Faites respecter le backpressure : files limitées, timeouts, coupe-circuits.
3. Batch I/O : moins de fsync, moins de petites écritures, moins d’appels système réseau.
4. Pinnez le lourd : séparez les CPUs ou isolez avec cgroups pour protéger le chemin critique.
5. Gardez la mémoire saine : évitez le swap en charge stable.
6. Ne lancez pas tout partout : les stacks dev locaux nécessitent de la discipline (ou plus de cœurs).

Il y a un principe de fiabilité caché dans les trois listes : la performance est un problème de capacity planning, pas un système de croyances.

Citation (idée paraphrasée) : Werner Vogels a répété l’idée que « tout échoue, tout le temps », donc concevez et opérez en tenant compte des défaillances et de la variabilité.

FAQ

1) 8 cœurs suffisent-ils pour jouer en 2026 ?

Souvent oui — si ces 8 cœurs ont une forte performance mono-thread et que vous avez assez de RAM. Beaucoup de jeux sont encore limités par quelques threads principaux. Si vous streamez, exécutez la voix/vidéo et gardez un zoo d’onglets, des cœurs supplémentaires aident la fluidité.

2) 8 cœurs suffisent-ils pour le développement logiciel ?

Pour des projets petits à moyens, oui. Pour de gros codebases, des builds fréquents, plusieurs serveurs de langage, conteneurs locaux et une base de données, 8 cœurs deviennent le palier « pourquoi mon ventilateur hurle ». Si les builds sont quotidiens, 12–16+ cœurs rentabilisent le temps.

3) Pourquoi mon CPU 8 cœurs montre 16 CPUs sous Linux ?

Parce que SMT/hyper-threading expose deux threads logiques par cœur. Cela peut améliorer le débit, mais ne double pas la performance. Considérez-le comme un bonus, pas un remplacement des vrais cœurs.

4) Si l’utilisation CPU est faible, pourquoi le système est lent ?

Parce que vous pouvez être bloqué en I/O, attendre des verrous, throttlé par des cgroups, ou subir une pression mémoire. Utilisez iostat, vmstat et les métriques de context switch pour trouver le vrai limiteur.

5) Dois-je choisir moins de cœurs plus rapides ou plus de cœurs plus lents ?

Les charges interactives et sensibles à la latence préfèrent souvent des cœurs plus rapides et du cache. Les charges de débit et parallèles préfèrent plus de cœurs. Si vous exécutez des charges mixtes, achetez plus de cœurs et évitez une faible performance par cœur — sinon vous obtenez le pire des deux.

6) Plus de cœurs améliorent-ils toujours les bases de données ?

Non. Beaucoup de charges DB bottleneck sur la latence stockage, les verrous ou la mémoire. Certaines tâches (compression, certaines requêtes, maintenance en arrière-plan) s’échelonnent bien ; d’autres non. Mesurez : temps CPU par requête, iowait et contention.

7) Passer de 8 à 16 cœurs aide-t-il les conteneurs ?

Seulement si vos conteneurs sont autorisés à les utiliser. Les limites et quotas CPU peuvent vous throttler. De plus, si vous manquez de mémoire ou êtes I/O-bound, plus de cœurs ne résoudront pas le problème.

8) 8 cœurs suffisent-ils pour un NAS domestique ?

Pour un simple partage de fichiers, oui. Si vous activez la compression lourde, le chiffrement, exécutez du transcodage média et hébergez beaucoup de services, 8 cœurs peuvent devenir justes. Les fonctions d’intégrité stockage peuvent être gourmandes en CPU à haut débit.

9) Quel est le signe le plus simple que j’ai vraiment besoin de plus de 8 cœurs ?

Une pression CPU soutenue pendant vos workflows critiques plus la preuve que la charge s’échelle avec la parallélisation (par ex. builds montrant régulièrement 700–800% CPU, ou runners CI qui se mettent en file).

10) Et si je suis dans le cloud et ne peux pas « acheter un CPU » ?

Vous louez toujours des cœurs. Validez le %steal, assurez-vous de ne pas être throttlé, et choisissez les familles d’instances selon la charge : compute-optimized pour CPU-bound, memory-optimized pour cache lourd, storage-optimized quand l’I/O domine.

Conclusion : étapes pratiques suivantes (pas d’héroïsme requis)

Les 8 cœurs couvrent-ils encore tout le monde en 2026 ? Non. Ils couvrent beaucoup de personnes, et ils les couvrent bien — quand le reste du système (RAM, latence stockage, thermiques, limites du scheduler) est sain et que la charge est majoritairement mono-utilisateur.

Mais « tout le monde » comprend désormais des développeurs exécutant de mini-productions sur leurs laptops, des équipes qui construisent continuellement d’énormes codebases, et des services faisant de la cryptographie et de l’observabilité par défaut. Dans ce monde, 8 cœurs ne sont pas une réponse universelle. C’est un point de départ.

Que faire cette semaine

1. Exécutez le guide de diagnostic rapide sur votre système le plus lent ou votre pipeline le plus coûteux. Identifiez CPU vs mémoire vs I/O.
2. Capturez une semaine de réalité : pic CPU, activité swap, await stockage et throttling/steal. Ne basez pas le dimensionnement sur un mardi calme.
3. Choisissez une cible : si vous avez besoin d’interactivité, priorisez la performance par cœur et évitez le throttling thermique. Si vous avez besoin de débit, achetez des cœurs et gardez de la marge.
4. Corrigez d’abord les goulots peu coûteux : swap, latence I/O, throttling, concurrence incontrôlée. Puis décidez si vous avez encore besoin de plus de cœurs.

Si vous faites tout cela et que 8 cœurs restent suffisants, profitez-en. Sinon, upgradez en toute confiance — et arrêtez de traiter le nombre de cœurs comme un trait de personnalité.