91 % de RAM utilisée. Avant d'ouvrir un seul modèle. Avant de lancer Ollama. Avant même d'ouvrir un onglet de navigateur.
C'est le chiffre que j'ai découvert en voulant simplement faire tourner un LLM en local. Je voulais économiser des tokens API, tester Qwen3 en offline, reprendre le contrôle de mes appels d'inférence. La machine a résisté. Et ce que l'audit a révélé m'a surpris : cinq instances Ollama fantômes issues de sessions précédentes, neuf programmes parasites au démarrage, et 914 Mo de bloatware Dell qui télémétrisaient en silence depuis des mois.
L'angle méta de cette histoire ne m'échappe pas : j'ai utilisé Claude Code pour diagnostiquer le PC sur lequel tourne Claude Code. L'outil était à la fois le symptôme et le remède.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le piège de l'IA locale : vous devenez votre propre infra
Il y a une illusion confortable autour de l'IA locale. On se dit : « Plus de latence cloud, plus de coût par appel, je reprends le contrôle. » C'est vrai — jusqu'au moment où la machine trahit.
Avec une API cloud, le scaling est transparent. Vous payez à l'appel, les ressources sont élastiques, la gestion hardware n'existe pas. En local, vous êtes l'infra. GPU, VRAM, CPU, RAM : des ressources figées, partagées avec tout le reste de votre stack de développement.
Et cette stack, sur un PC de développeur actif, est plus lourde qu'on ne le pense.
La « tempête parfaite » que j'ai construite sans m'en rendre compte :
- Ollama : 5,2 Go d'installation, plus 2 à 5 Go par modèle chargé en mémoire
- Docker Desktop : ~450 Mo en tâche de fond, démarrage automatique activé
- Claude Code + VSCode/Cursor : 1,5 Go combinés (1,1 Go pour Cursor, 482 Mo pour VSCode)
- Hooks de warm-up Claude Code : +2,5 Go au démarrage de session (les hooks relancent automatiquement Ollama)
- Services Dell + télémétrie Microsoft : 200 Mo de RAM + I/O disque continu en arrière-plan
En mode dev actif, cette configuration consomme 13,3 Go sur 16 Go disponibles — soit 85 % avant d'ouvrir le moindre onglet de navigateur.
Le problème invisible est là : le Gestionnaire des tâches Windows affiche une utilisation « normale ». C'est une illusion. Windows agrège cache et buffers dans le total affiché, masquant la pression réelle sur la RAM physique. Aucun processus n'apparaît comme coupable évident. Les signaux d'alerte étaient pourtant là depuis des semaines : boot Windows allongé de 60 secondes, lag Slack de 5 à 10 secondes, ventilateur GPU s'emballant au redémarrage d'Ollama.
La formulation que j'ai gardée en tête pour décrire la situation : un commit → compile → inférence LLM = swap disque, gel total. C'est là que j'ai compris que le problème n'était pas Ollama — c'était tout ce qui tournait en plus.
Diagnostic — Identifier les coupables
Étape 1 : Mesurer la RAM réelle, pas celle du Gestionnaire des tâches
Le Gestionnaire des tâches est trompeur pour une mesure précise. La commande PowerShell suivante donne la consommation réelle par processus, triée par ordre décroissant :
Get-Process | Sort-Object WorkingSet -Descending |
Select-Object -First 15 Name,
@{N='RAM(MB)';E={[math]::Round($_.WorkingSet/1MB,1)}}
Ce que j'ai trouvé : 14,9 Go utilisés sur 15,7 Go physiques. 1,5 Go libres. État critique — à ce niveau, Windows commence à utiliser le fichier d'échange sur disque, ce qui explique les gels.
Pour une mesure rapide en une ligne :
$mem = Get-CimInstance Win32_OperatingSystem $used = [math]::Round(($mem.TotalVisibleMemorySize - $mem.FreePhysicalMemory)/1MB, 1) $total = [math]::Round($mem.TotalVisibleMemorySize/1MB, 1) Write-Host "RAM : $used GB / $total GB ($([math]::Round($used/$total*100,0)) %)"
Étape 2 : Débusquer les instances Ollama zombies
Ollama ne tue pas ses daemons si une session Claude Code se ferme brutalement. C'est un comportement documenté : le hook de warm-up relance un daemon Ollama à chaque démarrage de session, mais si la session précédente s'est interrompue de façon anormale — crash, fermeture forcée, panne réseau — le daemon reste en mémoire. Multiplié par plusieurs jours de travail, le résultat est un cimetière de processus.
Détection :
Get-Process ollama | Select-Object Id, CPU,
@{N='RAM(MB)';E={[math]::Round($_.WorkingSet/1MB,1)}}
Ce que j'ai trouvé : cinq instances actives simultanément. Cinq daemons pour zéro inférence en cours. Coût : +2,4 Go de RAM consommés pour rien.
Nettoyage propre :
# Stopper les modèles chargés ollama stop <model> # Si des instances fantômes persistent Stop-Process -Name ollama -Force
Étape 3 : Auditer les programmes au démarrage
Paramètres → Applications → Démarrage (ou msconfig → onglet Démarrage). Le seuil d'alerte pour un PC de développeur : plus de six entrées activées signifient que des ressources sont consommées dès l'allumage, sans que vous ayez rien demandé.
Ce que j'ai trouvé : douze entrées actives. Steam, Discord, Teams, Docker Desktop, Ollama, Microsoft.Lists, OneDrive, Nextcloud, et quelques autres. Aucun de ces programmes n'était nécessaire au démarrage. Tous peuvent être lancés à la demande, en quelques secondes, quand on en a besoin.
La nuance importante : Ollama dans la liste de démarrage est redondant si vous utilisez Claude Code — les hooks le relancent automatiquement à l'ouverture de session. Deux mécanismes pour faire la même chose, consommant des ressources en double.
Étape 4 : Services système — le bloatware invisible
C'est la couche que la plupart des guides « optimiser Windows » ne mentionnent pas avec assez de précision. Un PC Dell récent vient avec un écosystème de services pré-installés qui s'exécutent en permanence, collectent des données, envoient des rapports, et consomment CPU et I/O disque sans vous demander la permission.
Détection des services Dell :
Get-Service -Name "*Dell*" | Select-Object Name, Status, StartType
Vue complète des services actifs (s'ouvre dans une fenêtre filtrée) :
Get-Service |
Where-Object {$_.Status -eq 'Running'} |
Sort-Object DisplayName |
Select-Object DisplayName, StartType |
Out-GridView
Ce que j'ai trouvé :
- Cinq services Dell actifs : SupportAssist (914 Mo à lui seul), TechHub, et trois services satellites. Télémétrie agressive, I/O disque continu.
- DiagTrack Microsoft : service de télémétrie Windows actif en permanence, I/O réseau silencieux.
- TeamViewer : en mode démarrage automatique — exposé 24h/24, surface d'attaque non anticipée.
914 Mo pour SupportAssist Dell seul. C'est plus qu'un onglet Chrome ouvert. Et c'est de la mémoire allouée à de la télémétrie, pas à votre travail.
Actions — Checklist phase par phase
Tous les changements décrits ici sont réversibles. Aucune désinstallation, uniquement des désactivations enregistrées dans le registre Windows. Un Set-Service -StartupType Automatic suffit à tout restaurer.
Phase 1 — Nettoyage immédiat des processus (5 min)
Gain sans redémarrage, résultat immédiat.
# Identifier les processus Ollama en cours Get-Process ollama # Stopper proprement les modèles chargés ollama stop <model> # Tuer les instances fantômes restantes Stop-Process -Name ollama -Force
Fermer également les sessions Claude Code inutiles : chaque session ouverte consomme environ 700 Mo de RAM. Deux sessions ouvertes pour un seul flux de travail = 1,4 Go de gaspillage.
Gain immédiat : +2,4 Go libérés sans redémarrage.
Phase 2 — Démarrage (10 min, réversible)
Paramètres → Applications → Démarrage. Désactiver :
- Steam, Discord, Teams (lancer à la demande)
- Docker Desktop (démarrer via CLI si un container est actif : docker start <container>)
- Ollama (redondant avec les hooks Claude Code)
- Microsoft.Lists, et tout ce qui n'est pas critique dès l'allumage
Garder : Windows Security, et OneDrive ou Nextcloud si la synchronisation est critique pour votre flux de travail.
Gain : -9 entrées de démarrage, temps de boot réduit de 30 à 40 %.
Phase 3 — Services Dell et télémétrie (10 min, PowerShell admin)
Ouvrir PowerShell en mode administrateur, puis :
# Désactiver et arrêter les services Dell
$dellServices = Get-Service -Name "*Dell*" |
Where-Object {$_.Status -eq 'Running'}
$dellServices | ForEach-Object {
Set-Service -Name $_.Name -StartupType Disabled
Stop-Service -Name $_.Name -Force
}
# Désactiver la télémétrie Microsoft
Set-Service -Name "DiagTrack" -StartupType Disabled
Stop-Service -Name "DiagTrack" -Force
# TeamViewer → Manuel (pas désactivé si accès distant nécessaire)
Set-Service -Name "TeamViewer" -StartupType Manual
Stop-Service -Name "TeamViewer" -Force
Gain : -200 Mo de RAM, suppression de l'I/O disque background, surface d'attaque réduite.
Phase 4 — Vérification après redémarrage (2 min)
$mem = Get-CimInstance Win32_OperatingSystem $used = [math]::Round(($mem.TotalVisibleMemorySize - $mem.FreePhysicalMemory)/1MB, 1) $total = [math]::Round($mem.TotalVisibleMemorySize/1MB, 1) Write-Host "RAM utilisée : $used GB / $total GB ($([math]::Round($used/$total*100,0)) %)"
Résultats mesurés — Avant / Après
Les chiffres suivants sont issus de mesures réelles, avant et après les phases d'optimisation décrites ci-dessus.
| Indicateur | Avant | Après | Gain |
|---|---|---|---|
| RAM idle utilisée | 91 % (14,9 Go) | ~66 % (~10,9 Go) | -25 pts / +3,8 Go libres |
| RAM libre en idle | 1,5 Go | ~5,3 Go | +3,8 Go |
| Instances Ollama | 5 | 1 daemon léger | -4 processus zombies |
| Entrées démarrage | 12 | 3 | -9 entrées / boot -30-40 % |
| Services Dell actifs | 5 | 0 | -5 services + sécurité |
| TeamViewer | Auto (24h/24) | Manuel | Surface d'attaque réduite |
La règle des 80/20 s'applique ici de façon très nette.
Quatre-vingts pour cent du gain vient de deux actions seulement : l'arrêt des instances Ollama fantômes (+2,4 Go récupérés immédiatement) et la désactivation des services Dell (−200 Mo + suppression de l'I/O background). Les 20 % restants proviennent des ajustements de démarrage et des mesures de sécurité.
Ce que ça change concrètement dans le flux de travail :
- Lancer ollama run qwen3:4b après un commit sans freeze
- Avoir deux instances Qwen3 en parallèle pour un A/B testing de prompts — ce qui était impossible avant
- Session Claude Code + Docker Compose + build en simultané : faisable, sans gel
Une nuance importante : ces gains sont mesurés sur une configuration spécifique (16 Go RAM, stack Ollama + Docker + Claude Code). Si votre RAM idle reste au-dessus de 75 % après avoir appliqué tout l'audit, la piste matérielle devient légitime : un upgrade à 32 Go est justifié, surtout si vous faites tourner Docker Compose avec plusieurs services simultanément.
Autre point de vigilance : Windows Update peut réactiver DiagTrack et certains services Dell après une mise à jour majeure. Un audit mensuel rapide (la commande Get-Service suffit) permet de détecter les réactivations silencieuses.
Checklist complète — Audit PC pour développeurs IA
Format priorité : CRITIQUE (< 5 min, gain maximal) → IMPORTANT (10 min, gain moyen) → OPTIONNEL (sécurité et maintenance)
CRITIQUE — Faire en premier
- [ ] Mesurer la RAM réelle : Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 15
- [ ] Détecter les instances Ollama fantômes : Get-Process ollama
- [ ] Arrêter les instances en surnombre : Stop-Process -Name ollama -Force
- [ ] Fermer les sessions IDE ou Claude Code en double
IMPORTANT — Gain démarrage
- [ ] Auditer les entrées de démarrage : Paramètres → Applications → Démarrage
- [ ] Désactiver Steam, Discord, Teams, Docker Desktop du démarrage
- [ ] Désactiver Ollama du démarrage (redondant avec les hooks Claude Code)
- [ ] Désactiver les services Dell via PowerShell admin (voir Phase 3 ci-dessus)
- [ ] Passer TeamViewer en mode Manuel : Set-Service -Name "TeamViewer" -StartupType Manual
OPTIONNEL — Sécurité et maintenance
- [ ] Désactiver DiagTrack (télémétrie Microsoft) : Set-Service -Name "DiagTrack" -StartupType Disabled
- [ ] Vérifier l'absence de McAfee WebAdvisor (conflit avec Windows Defender)
- [ ] Programmer un audit mensuel (Windows Update peut réactiver des services)
- [ ] Après chaque session dev : ollama stop <model> pour libérer la VRAM immédiatement
MONITORING CONTINU — Maintenance longue durée
- [ ] Snapshot RAM rapide : Get-CimInstance Win32_OperatingSystem
- [ ] Si RAM idle > 80 % après audit complet → évaluer upgrade 32 Go
Conclusion : l'IA locale ne pardonne pas un PC mal entretenu
En voulant installer un LLM local pour économiser des tokens, j'ai déclenché un audit que j'aurais dû faire depuis longtemps. 91 % de RAM en idle, cinq instances fantômes, neuf programmes parasites au démarrage, cinq services Dell qui télémétrisaient silencieusement. Résultat de 30 minutes de travail : +3,8 Go libérés, boot allégé de 30 à 40 %, surface d'attaque réduite — et pour la première fois depuis des mois, un ollama run qwen3:4b sans gel.
Le vrai enseignement n'est pas technique. C'est que l'IA locale révèle l'état réel de votre machine. Elle ne s'accommode pas d'un PC mal entretenu comme le ferait une API cloud derrière un CDN. Elle ralentit, freeze, plante — et vous indique précisément où chercher.
Si votre machine montre des signes de fatigue dès que vous lancez Ollama, ne cherchez pas du côté du modèle ou de la quantization. Commencez par l'audit. La checklist ci-dessus est reproductible sur n'importe quel PC Windows de développeur. Aucune désinstallation, tout est réversible. Lancez-vous — 30 minutes chrono.
Pour aller plus loin sur l'optimisation de votre flux de travail avec Claude Code, j'ai documenté comment réduire la consommation de tokens de vos sous-agents dans un article dédié — la même logique d'audit systémique, appliquée cette fois à la fenêtre de contexte.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Améliorer les performances de votre PC pour faire tourner en local des modèles ollama