Journal de bord IA N° 1Publié le

J'ai ajouté de la mémoire tierce à mon HP OMEN 30L et il ne démarre plus normalement | Deux jours de diagnostic avec ChatGPT et Claude Code avant d'abandonner CFD

J'ai ajouté deux barrettes CFD de 16 Go à mon HP OMEN 30L (Core i9-10850K) pour atteindre 64 Go. Le BIOS les détectait et le test mémoire passait, mais le démarrage normal restait bloqué sur le cercle de chargement blanc sous le logo OMEN. Comment j'ai isolé le problème en deux jours avec ChatGPT et Claude Code, comment une suggestion de l'IA a empêché le POST, et pourquoi j'ai abandonné CFD.

Résultat

Avec 64 Go, le démarrage normal n'a jamais réussi : j'abandonne les barrettes CFD et j'achèterai à la place de la mémoire d'origine HP. J'ai isolé la cause à l'ajout des deux barrettes CFD, mais je ne peux pas affirmer qu'elles sont défectueuses.

Points clés

  • Le BIOS détectait les 64 Go, le test rapide (Fast Test) des diagnostics UEFI d'HP passait et le mode sans échec fonctionnait. Pourtant, les sept démarrages normaux consignés avec 64 Go ont tous échoué.
  • J'ai configuré l'accès SSH depuis mon Mac vers le PC en mode sans échec. Claude Code a croisé les journaux pour confirmer que seul le démarrage avec 32 Go avait réussi.
  • Désactiver le GPU n'a rien changé. Modifier un timing mémoire dans le BIOS sur suggestion de l'IA a empêché jusqu'au POST (récupéré en retirant la pile CMOS).
  • En revenant aux deux barrettes d'origine, le démarrage normal fonctionne et l'écran « Advanced » du BIOS disparaît. Le comportement du BIOS semble changer uniquement lorsque de la mémoire non-HP est insérée.

Outils d'IA utilisés dans cette entrée

Introduction : viser 64 Go, mais revenir aux 32 Go d’origine après deux jours

J’ai voulu passer à 64 Go sur mon HP OMEN 30L en ajoutant deux barrettes de mémoire CFD de 16 Go. Résultat : échec. Avec 64 Go, le démarrage normal de Windows n’a jamais réussi une seule fois. J’ai donc abandonné les barrettes CFD et décidé d’acheter à la place de la mémoire d’origine HP.

Le plus étrange, c’est que le BIOS reconnaissait correctement les 64 Go. Le test mémoire UEFI était validé, et en mode sans échec, la machine tournait de façon stable pendant des heures. Pourtant, en démarrage normal, le cercle de chargement blanc sous le logo OMEN restait bloqué et ne progressait pas. Avec 64 Go, le démarrage normal a échoué au moins 7 fois, selon les logs, avec 0 succès.

Je n’ai pas pu identifier la cause avec certitude. Je n’ai aucune preuve que la mémoire CFD soit défectueuse. Ce que je sais, c’est qu’ajouter les deux barrettes CFD provoque le blocage, tandis que les deux barrettes d’origine fonctionnent.

Cet article est le compte rendu de l’analyse des causes, réalisée en environ une journée et demie à l’aide de ChatGPT sur smartphone et de Claude Code sur Mac. J’y décris honnêtement, dans l’ordre chronologique, ce que j’ai essayé, les résultats obtenus, ainsi que les points où la délégation à l’IA a bien fonctionné et ceux qui étaient risqués.

Ce que vous apprendrez dans cet article :

  • L’ordre des étapes de diagnostic lorsque seul le démarrage normal est bloqué
  • Comment accéder via SSH depuis un Mac à un PC fonctionnant en mode sans échec
  • Le cas où, en suivant les suggestions de l’IA pour modifier le BIOS, je n’ai même plus réussi à passer le POST
  • Quelle mémoire choisir si vous souhaitez augmenter la capacité sur ce modèle

Le matériel et la raison pour laquelle je voulais passer à 64 Go de mémoire

La configuration de mon PC est la suivante.

ÉlémentDétails
PCHP OMEN 30L Desktop (série GT13-0xxx)
Carte mèreHP 8703 (Intel Z490)
BIOSAMI F.20 (2021-08-27)
CPUIntel Core i9-10850K (10 cœurs, 20 threads)
GPUNVIDIA GeForce RTX 3080 (10 Go de VRAM)
Mémoire d'origineModules Kingston pour HP HP32D4U8D8HD-16XR (2 x 16 Go, DDR4-3200, double rang). Je pensais qu'il s'agissait de « HyperX »
Slots libresDIMM2 et DIMM4

Selon les spécifications officielles d'HP, il y a 4 slots mémoire DDR4, avec un maximum de 64 Go (4 x 16 Go). HP lui-même expédiait des configurations en 4 x 16 Go. Autrement dit, le passage à « 64 Go » restait dans les limites des spécifications.

Cependant, la fiche technique d'HP Japon contient une note indiquant qu'« HP ne vend pas de mémoire d'origine HP en option » et que « le fonctionnement en cas d'extension par l'utilisateur est hors support ». L'extension est donc à vos risques et périls.

Pourquoi je voulais 64 Go

J'utilise ce PC pour faire tourner des LLM en local à la maison. J'y fais tourner Ollama en permanence.

Lorsque j'ai testé de grands modèles de type MoE, je les ai fait fonctionner en plaçant la partie qui ne tenait pas dans les 10 Go de VRAM dans la mémoire principale. Mais avec 32 Go, les poids ne tenaient pas entièrement en RAM, et le reste devait être lu depuis le SSD à chaque fois, ce qui était lent. Pendant les tests, la RAM libre restait collée autour de 0,1 Go.

Avec 64 Go, je m'attendais à ce que les poids tiennent entièrement en RAM et que la vitesse soit comparable à celle des modèles de classe 27B que je fais tourner sur Mac. Mais il s'agit d'une estimation ; sans passer à 64 Go, je ne pouvais pas le mesurer. Finalement, je n'ai jamais pu vérifier.

J'ai demandé à l'IA de choisir la mémoire : elle a donné des recommandations et des points « non vérifiés »

Le 12 octobre 2026, j'ai demandé à Claude Code sur mon Mac (un agent IA) de rechercher des candidats pour l'extension mémoire. La « proposition A », citée comme recommandation, est le W4U3200CS-16G de CFD Standard (2 × 16 Go). Il s'agit d'un produit DDR4-3200, CL22, 1.2V, conforme JEDEC, simple rang (puces de 16 Gbit).

Les raisons de cette recommandation étaient les suivantes.

  • Mêmes spécifications « 3200, CL22, 1.2V » que le module d'origine, donc pas besoin de XMP (paramétrage pour faire tourner la mémoire plus vite que la norme)
  • HP expédie des configurations en 4 × 16 Go
  • Le tableau de compatibilité par modèle de Kingston indique « modules de 16 Go par paires, jusqu'à 64 Go », et y figurent aussi des modèles de 16 Go simple rang
  • En stock chez les grands détaillants, avec une garantie de compatibilité de 30 jours après achat selon la mention du revendeur

Cependant, la même recherche indiquait clairement les « points non vérifiés ».

  • Le module d'origine est estimé être double rang. Ajouter des barrettes CFD simple rang ferait cohabiter double rang et simple rang dans le même canal. Le comportement avec ce BIOS n'est pas vérifié
  • Avec le BIOS F.20, il n'est pas vérifié que quatre barrettes de marques différentes fonctionnent à 3200
  • Dans la communauté HP (non officielle), on lit que « la mémoire non HP peut tomber à 2400 » et que « cette carte mère est capricieuse avec la mémoire »

La recherche elle-même précisait qu'elle ne qualifiait pas cette recommandation de « produit compatible ». Autrement dit : cela pouvait marcher, mais personne ne l'avait vérifié.

J'ai acheté le kit CFD (2 × 16 Go) sur Amazon pour environ 30 000 yens.

En y repensant, c'est précisément cette partie « non vérifiée » qui m'a fait trébucher. J'aurais dû lire la section des points non confirmés de la recherche IA, pas seulement le texte de la recommandation.

Jour 1 : Bips, pile morte et cercle de chargement blanc figé

L'après-midi du 1er novembre, j'ai inséré les deux barrettes CFD dans les slots libres DIMM2 et DIMM4, puis j'ai allumé le PC. Des bips (codes sonores) se sont fait entendre et l'écran est resté noir. Les voyants de la tour clignotaient, donnant l'impression que le système tentait de démarrer avant de s'arrêter.

D'après mes souvenirs, les bips correspondaient à « deux tons graves, trois tons aigus ». Cependant, comme je n'en suis pas certain, je ne considère pas ce code sonore comme fiable.

Après avoir retiré les barrettes CFD et réinstallé les deux barrettes d'origine, le PC a démarré. J'ai brièvement vu le message « Réinitialisation du CMOS (502) ». En consultant plus tard les journaux OMEN, j'ai constaté que l'horloge BIOS revenait systématiquement au 1er janvier 2018 à chaque débranchement du câble d'alimentation. La pile CMOS était donc déjà morte.

Avec la configuration d'origine de 32 Go, j'ai réussi trois démarrages normaux cet après-midi-là (15:19, 16:28, 17:21). Entre 15:23 et 16:28, j'ai également lancé manuellement le diagnostic mémoire Windows (test standard) : les 32 Go ont été inspectés sans aucune erreur.

Vers 22:20, j'ai remplacé la pile CMOS par une neuve et installé les quatre barrettes (64 Go). L'écran BIOS affichait « 65536MB », « DDR4 », « 3200 » et « Dual Channel ». Les quatre barrettes étaient bien reconnues à 16384 Mo chacune.

Cependant, lors des tentatives de démarrage normal vers 22:23 et 22:34, le cercle de chargement blanc (sous le logo OMEN) restait figé. J'ai attendu plus de dix minutes sans changement. Aucun écran bleu ni redémarrage intempestif n'est survenu.

À partir de 22:38, j'ai exécuté le « test rapide » mémoire via HP PC Hardware Diagnostics UEFI (outil de diagnostic accessible en appuyant sur Esc puis F2 juste après l'allumage). Le test a réussi à 23:14. La capacité testée était de 63,7 Go.

Heure (01/11)ActionRésultat
Après-midiInsertion des CFD dans DIMM2 et DIMM4, puis démarrageBips (codes sonores), pas d'affichage, voyants clignotants
Après-midiRetrait des CFD, démarrage avec les 2 barrettes d'origineDémarrage réussi (message « Réinitialisation du CMOS (502) »)
15:19 / 16:28 / 17:21Démarrage normal avec les 32 Go d'origineSuccès des 3 fois. Diagnostic mémoire réussi entre 15:23 et 16:28
Vers 22:20Remplacement de la pile CMOS, insertion des 4 barrettesBIOS affiche 65536MB, DDR4, 3200, Dual Channel
Vers 22:23 / Vers 22:34Démarrage normalCercle de chargement blanc figé (aucun changement après 10 min)
22:38–23:14Test rapide mémoire via diagnostic UEFI HPRéussi (63,7 Go testés)

Voici la situation à ce stade. Le BIOS reconnaît les 64 Go et le test mémoire est validé. « La mémoire semble saine, alors pourquoi Windows ne démarre-t-il pas ? ». Le remplacement de la pile a résolu le problème de l'horloge qui reculait (distinct de la mémoire), mais le blocage au démarrage persistait.

Le matin du deuxième jour : 64 Go fonctionnent en mode sans échec

Vers 05 h 42 le 2 novembre, la réparation automatique s'est lancée. Mais le résultat était « Impossible de réparer ». En consultant les journaux (SrtTrail.txt), j'ai constaté que les 29 tests étaient tous passés avec succès et qu'aucune cause racine n'avait été identifiée.

À 05 h 49, en sélectionnant « 4 : Activer le mode sans échec » dans les « Paramètres de démarrage » de l'écran de récupération, le système a démarré jusqu'au bureau avec les 64 Go. Le Gestionnaire des tâches affichait : mémoire 64,0 Go, DDR4, vitesse 3200 MT/s, slots utilisés 4/4, et 136 Mo réservés au matériel.

Jusqu'à présent, mon interlocuteur était ChatGPT sur smartphone. Je lui envoyais des photos de l'écran BIOS, des bips (codes sonores) et de l'écran de récupération pour qu'il les analyse, puis je lui demandais directement la prochaine étape. ChatGPT m'a même fourni un historique de consultation au format Markdown, distinguant les événements aux horaires imprécis comme « heure inconnue ».

L'essentiel est le schéma suivant : ça marche en mode sans échec, mais ça plante au démarrage normal. S'agit-il de la mémoire elle-même, ou d'un pilote chargé uniquement lors du démarrage normal ? À ce stade, je ne peux pas faire la distinction.

Pour lire correctement les journaux, je voulais que Claude Code sur mon Mac inspecte l'intérieur de l'OMEN. Mais en mode sans échec sans réseau, il n'y avait pas d'adresse IP, et le serveur SSH (sshd) était bloqué avec l'erreur « 1084 ». C'était le prochain obstacle.

Accéder à un PC en mode sans échec via SSH depuis un Mac

L’erreur 1084 signifie que « ce service ne peut pas être démarré en mode sans échec ». J’ai d’abord tenté de redémarrer avec l’option « 5 : Activer le mode sans échec et la prise en charge réseau ».

Cependant, en maintenant la touche Shift pendant le redémarrage, le système est passé au démarrage normal en cours de route et s’est à nouveau bloqué sur le cercle de chargement blanc. J’ai coupé l’alimentation, réaccédé à l’écran de récupération via F11 et réussi à démarrer en mode sans échec avec prise en charge réseau à 08:53.

Même en me connectant par SSH depuis le Mac, la connexion au port 22 expirait après 8 secondes. La commande ping passait, avec une réponse inférieure à 1 ms. Ce n’était ni un refus de connexion, ni un échec d’authentification. Le service n’était tout simplement pas à l’écoute. En mode sans échec, seuls les services listés dans la clé de registre SafeBoot\Network sont démarrés. C’est probablement la cause (inférence).

Pendant ce temps, Claude Code a reconstitué la chronologie des connexions réseau de l’OMEN à partir des journaux d’un autre processus automatique restant sur le Mac (un script qui se connectait régulièrement à l’OMEN). L’après-midi du 1er novembre, le démarrage normal a réussi trois fois. Après 21:51, la machine n’a plus jamais été visible sur le réseau jusqu’à 08:53 du matin. L’hypothèse selon laquelle « Windows continue de tourner en arrière-plan même pendant le blocage sur le cercle blanc » s’est ainsi affaiblie.

Pour y remédier, j’ai enregistré sshd comme « Service » dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network et démarré sshd. Le guide rédigé par Claude Code contenait la commande pour sauvegarder l’état initial, le détail des modifications, le périmètre d’application et la méthode de restauration. J’ai exécuté ces commandes moi-même dans l’invite de commandes administrateur de l’OMEN.

  • Sauvegarde : reg export HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network SafeBoot_Network_before.reg
  • Enregistrement : reg add HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\sshd /ve /t REG_SZ /d Service /f
  • Démarrage : sc.exe start sshd

sshd a démarré à 12:47 et la connexion SSH depuis le Mac a abouti à 13:06.

Attention : Avec ce réglage, il est possible de se connecter par SSH via le LAN même en mode sans échec. Il s’agit d’une configuration temporaire, à rétablir dès la fin des investigations.

Ce que les journaux ont révélé : le démarrage normal n’a réussi qu’avec 32 Go

Une fois la connexion SSH établie, Claude Code a créé un script de diagnostic PowerShell en lecture seule. J’ai vérifié via SHA-256 que le fichier envoyé sur l’OMEN était identique à celui du côté Mac avant de l’exécuter (durée : 1,9 minute), puis j’ai récupéré les résultats sous forme d’archive ZIP sur le Mac pour les analyser.

Voici ce que les enregistrements de la machine physique ont permis de déterminer :

ConstatFondement
Le démarrage normal n’a réussi qu’avec 32 GoLe fichier de configuration (SHIM.json) écrit par l’application NVIDIA à 17:21:54 indique « mémoire physique d’environ 32 Go » et « RAM 32768 Mo DDR4 3200 »
Les démarrages normaux interrompus n’ont laissé aucune traceAucune entrée dans le journal des événements. L’arrêt survient avant l’activation du journal des événements (phase d’initialisation du noyau et des pilotes)
Ce n’est pas un écran bleuLe « Kernel-Power 41 » du démarrage suivant affiche un code de vérification d’erreur égal à 0. C’est la signature d’un arrêt forcé via le bouton d’alimentation lors d’un démarrage bloqué
Détail de la mémoireDIMM 1 et 3 : Kingston (2 rangs) ; DIMM 2 et 4 : CFD (1 rang). Les quatre barrettes signalent « 3200 • 1,2 V »
L’horloge de l’OMEN était en retard de 32 minutes et 18 secondesAprès l’initialisation du CMOS, Windows a synchronisé l’heure sur le moment de la dernière fermeture (inférence). Ce n’est pas la cause des échecs de démarrage

L’élément décisif provient des enregistrements de l’application NVIDIA. Au moment du dernier démarrage normal réussi, à 17h21, je ne pouvais pas me souvenir si la quatrième barrette était déjà insérée. J’avais commencé à installer les barrettes CFD avant 17h00. La ligne écrite par l’application au démarrage indiquait qu’il y avait « 32 Go à ce moment-là ». Autrement dit, le démarrage normal avec 64 Go n’a jamais réussi une seule fois.

J’ai également gardé le GPU parmi les suspects. À chaque démarrage normal du 1er novembre, des erreurs PCIe corrigées sur le GPU (WHEA-Logger 17) ont été enregistrées, et il y avait eu des enregistrements d’écrans bleus liés au GPU en septembre.

Il y a eu une correction de la part de l’IA. Cette mémoire ne dispose pas d’ECC (fonction de détection et de correction d’erreurs), donc les erreurs de mémoire ne sont pas enregistrées dans WHEA par nature. Claude Code a d’abord écrit que « l’absence d’entrées WHEA mémoire » était un signe de normalité, avant de se corriger lui-même.

Le script de diagnostic lui-même a connu des échecs. Une exception s’est produite lors de la création du résumé. L’instruction pour vérifier les fichiers cachés manquait, ce qui a conduit à enregistrer par erreur « aucun » pour le fichier d’échange (pagefile) et autres. Le script n’a pas réussi à lire les séparateurs du journal de démarrage. De plus, il a collecté des informations concernant la clé de produit Windows OEM présente dans le BIOS, ce qui m’a obligé à masquer la copie côté Mac. Même en lecture seule, il faut faire attention au périmètre des données collectées.

Diagnostic : journal de démarrage, GPU et limite mémoire

Les journaux seuls ne permettent pas de déterminer si la cause est la mémoire ou un pilote. J’ai donc testé différentes configurations l’après-midi.

Action testéeObjectifRésultat
Activer le journal de démarrage et effectuer un démarrage normal (option 2 des Paramètres de démarrage)Voir jusqu’auquel pilote le système avance avant de bloquerArrêt au niveau du cercle de chargement blanc. Aucune ligne supplémentaire pour ce démarrage dans ntbtlog.txt = blocage à un stade antérieur à l’écriture du journal de démarrage. L’enregistrement du démarrage (bootstat.dat) s’interrompt lorsque le Boot Manager lit la politique de Code Integrity
Désactiver le GPU NVIDIA et effectuer un démarrage normal (pnputil)Vérifier si le pilote GPU est en causeBlocage identique. Le pilote NVIDIA est écarté des suspects. J’ai réactivé le GPU immédiatement après
Limiter la mémoire utilisée par Windows à 32 Go (truncatememory via bcdedit)Vérifier si le système peut démarrer avec seulement 32 Go, sans retirer de barrettesRefusé avec le message « Impossible de modifier car protégé par la politique Secure Boot ». Aucune modification effectuée
Commande de redémarrage vers l’écran BIOS (shutdown /r /fw)Ouvrir le BIOS à distanceIndisponible sur ce modèle (erreur 203). J’ai coupé le courant et ouvert le BIOS via la touche F10

La désactivation du GPU a été exécutée par Claude Code via SSH, après que je lui ai dit de faire aussi les tests lui-même. Une commande de restauration avait été définie avant l’exécution, et j’ai immédiatement rétabli la configuration après avoir observé le résultat.

Il ne reste que deux suspects :

  1. La configuration 4 barrettes / 64 Go est instable dès les premières étapes du démarrage normal (côté mémoire)
  2. Un composant autre que NVIDIA, chargé uniquement lors d’un démarrage normal (côté pilote)

Le système reste stable pendant des heures en mode sans échec, mais bloque toujours au même endroit lors d’un démarrage normal. Claude Code explique que cela ne permet pas d’écarter la mémoire. En effet, l’accès à la mémoire suit un ordre quasi identique à chaque démarrage initial ; ainsi, si la mémoire est instable, il est possible qu’elle bloque systématiquement au même point (inférence).

J’ai modifié le BIOS sur les conseils de l’IA, et même le POST a échoué

Ensuite, j’ai décidé d’examiner les réglages du BIOS lui-même. J’ai pris six photos de l’écran du BIOS avec mon smartphone et je les ai fait lire à ChatGPT. J’ai ensuite transmis ce résumé à Claude Code sur mon Mac. Claude Code n’a pas vu les photos elles-mêmes.

Dans la section « Advanced », il y avait un écran nommé « Memory Overclocking ». Les valeurs du « Default profile » sont les suivantes.

ParamètreValeur
DRAM Frequency1600 (= 3200 MT/s)
tCL / tRCD / tRP22 / 22 / 22
tRAS52
tRFC560
tWTR_S0
tREFI12480
NMode2
Champ de la tension mémoire1.35V

Voici l’interprétation de Claude Code (inférence). Un tRFC de 560 correspond à 350 ns en fonctionnement à 3200. C’est une valeur prévue pour des puces de 8 Gbit (les barrettes Kingston double rang). Pour des puces de 16 Gbit (les barrettes CFD simple rang), il faut 550 ns, soit 880. Il a donc proposé de « ne modifier que tRFC, de 560 à 880 ». Le message incluait aussi une procédure de retour en arrière : si l’écran ne s’affichait plus, réessayer de redémarrer plusieurs fois, et en dernier recours, retirer la batterie CMOS.

J’ai basculé sur un profil manuel et réglé tRFC à 880. Le résultat a été contre-productif. À l’allumage, j’ai entendu trois bips graves suivis de deux bips aigus, et le POST (auto-diagnostic juste après la mise sous tension) n’a même pas abouti. C’était identique à chaque tentative de redémarrage. Finalement, j’ai dû retirer la batterie CMOS pour réinitialiser les paramètres et revenir à l’état initial.

Pourquoi le POST a-t-il échoué ? Selon l’inférence de Claude Code, lors du basculement en mode manuel, il est possible que d’autres valeurs affichées à l’écran aient été appliquées telles quelles. En particulier, la valeur « 0 » pour tWTR_S est inférieure au minimum requis par la norme, qui est de 4.

Ensuite, j’ai réglé tRFC à 880 et tWTR_S à 4, la valeur minimale de la norme, en ne modifiant que ces deux paramètres. Cette fois, aucun bip n’a retenti et le POST a réussi. Cependant, le démarrage normal s’est toujours arrêté sur le cercle de chargement blanc. Il est apparu que l’écart de tRFC n’était pas, à lui seul, la cause du problème.

La leçon est claire. La proposition de l’IA était cohérente au regard des spécifications. Pourtant, elle a cassé le POST sur la machine réelle. Claude Code lui-même a consigné dans ses notes : « Modifier les timings manuellement dans le BIOS ne doit se faire que lorsqu’il n’y a pas d’autre solution ». Comme j’avais demandé la procédure de retour en arrière à l’avance, j’ai pu récupérer la situation.

L’élément décisif : en revenant aux deux barrettes d’origine, l’écran du BIOS a changé

J’ai demandé à Claude Code : « Quelle est la probabilité, en pourcentage, que la mise à jour du BIOS résolve le problème ? » La réponse était d’environ 10 à 20 %. Il s’agit d’une estimation sans base chiffrée précise. Il ne le recommande pas actuellement. Trois raisons sont avancées.

  • Le POST et les tests de mémoire passent ; ce n’est pas un cas typique résolu par une mise à jour du BIOS
  • Une écriture échouée peut rendre la machine inopérante
  • L’existence d’un BIOS plus récent (F.30 Rev.A) provient d’une publication sur le forum HP ; je ne l’ai pas vérifié sur un matériel réel

J’ai donc choisi de vérifier des points qui n’avaient pas encore été isolés. Le démarrage normal avec 32 Go a réussi uniquement avant le remplacement de la batterie. L’arrêt avec 64 Go s’est produit uniquement après ce remplacement. La « combinaison de quatre barrettes » et « l’initialisation du BIOS due au remplacement de la batterie » se sont produites simultanément.

Vers 16 h 57, j’ai retiré les deux barrettes CFD et n’ai laissé que les deux Kingston d’origine (32 Go). En ouvrant le BIOS avec F10, l’en-tête « Advanced » avait disparu. L’écran Memory Overclocking semble n’apparaître que lorsque de la mémoire non HP est insérée. Sur le forum HP, une publication indique qu’une « page de réglages d’overclocking pour mémoire non HP » a été ajoutée avec la version F.20.

J’ai ensuite tenté un démarrage normal : succès (16 h 58). Vérification via SSH : il s’agit bien d’un démarrage normal, pas du mode sans échec, et je suis connecté. Ollama fonctionne, et la capacité visible est d’environ 31,9 Go.

Cela permet de conclure ce qui suit :

  • Le remplacement de la batterie, l’initialisation du BIOS et l’état de Windows ne sont pas la cause
  • La cause est réduite à « l’ajout des deux barrettes CFD »
  • Soit le problème vient des CFD elles-mêmes (ou de la gestion par le BIOS de la mémoire non HP), soit de la combinaison des quatre barrettes de deux types différents

Pour distinguer l’un de l’autre, il faudrait démarrer avec uniquement les deux barrettes CFD. Je n’ai pas effectué cette vérification.

Conclusion : abandonner CFD et acheter à la place de la mémoire d'origine HP

Le 2 novembre à 17:04, j'ai décidé d'« abandonner CFD et d'acheter à la place de la mémoire d'origine HP ».

Les éléments pour cette décision avaient déjà été fournis par Claude Code. Même en testant uniquement avec les deux barrettes CFD, la solution est presque identique dans les deux cas de figure.

  • Si le système démarre : la cause est « le mélange de deux types ». La solution consiste à uniformiser les quatre barrettes sur un même type
  • Si le système plante : la cause est « CFD lui-même, ou la gestion par le BIOS de la mémoire non-HP ». La solution consiste à utiliser de la mémoire d'origine HP (spécifique à HP)

Dans les deux cas, uniformiser sur de la mémoire HP est la solution la plus sûre. La mise à jour du BIOS n'était pas recommandée, avec une estimation de réussite de « 10 à 20 % ».

Candidats pour la mémoire à acheter

Voici les candidats que j'ai demandé à Claude Code d'investiguer et de résumer par e-mail.

CandidatDétailsPrécautions
1er choixDeux barrettes d'occasion du même modèle Kingston pour HP que celles actuellement installées (HP32D4U8D8HD-16XR. Les numéros de modèle de révisions différentes sont acceptables)Presque introuvables neuves. Vérifier sur une photo de l'étiquette avant achat les mentions « HP32D4U8D8 » et « 2Rx8 »
2e choixAccessoire d'origine HP « HP 16GB DDR4-3200 DIMM (13L74AA) » neufSelon les informations du revendeur : double rang, 1.2V, CL22. Produit destiné aux PC professionnels ; non vérifié pour le fonctionnement sur OMEN

Il faut éviter les trois éléments suivants.

  • 16 Go en simple rang
  • Mémoire qui n'est pas de marque HP
  • Mémoire gaming qui suppose l'XMP

À la réception, je vérifierai d'abord dans le BIOS que le total est bien de 64 Go et que l'en-tête « Advanced » n'apparaît pas. S'il n'apparaît pas, on peut supposer qu'elle est traitée comme de la mémoire HP. Après cette vérification, je procéderai au démarrage normal.

Ce qui n'a pas été fait

  • Démarrage avec uniquement les deux barrettes CFD
  • Mise à jour du BIOS
  • Le Quick Test et l'Extensive Test des diagnostics UEFI d'HP
  • Vérification en réduisant la vitesse de la mémoire

À ce stade de l'article, je n'ai pas encore acheté la mémoire d'origine HP. L'OMEN fonctionne actuellement normalement avec les 32 Go d'origine.

Ce que j’ai bien fait de confier à ChatGPT et Claude Code, et ce qui a failli mal tourner

Pour cette session, la répartition des tâches était la suivante : ChatGPT sur smartphone lisait l’écran, tandis que Claude Code sur Mac inspectait l’intérieur du PC et tenait le journal. Pendant que le PC refusait de démarrer correctement, l’appareil photo du smartphone était le seul moyen de transmettre le contenu de l’écran à une IA. Les différences de compétences entre ces deux IA sont également détaillées dans la comparaison entre ChatGPT et Claude.

TâcheIA utiliséeRésultat / Évaluation
Lire une photo de l’écran et guider les étapesChatGPTJ’ai pu avancer sans hésiter sur le moment
Synthétiser l’historique des échanges par ordre chronologiqueChatGPTJ’ai pu distinguer les éléments dont l’heure était incertaine en les marquant « heure inconnue »
Restaurer les heures de présence d’OMEN sur le réseau à partir des journaux MacClaude CodeCela a affaibli l’hypothèse selon laquelle Windows tournait en arrière-plan
Rendre SSH utilisable en mode sans échecClaude CodeLe guide incluant la sauvegarde des valeurs initiales et la procédure de retour a été utile
Script de diagnostic en lecture seuleClaude CodeIl contenait un défaut et a même collecté des informations liées à la clé produit
Prouver que la mémoire était bien de 32 GoClaude CodeA retrouvé l’enregistrement décisif de l’application NVIDIA
Test avec le GPU désactivéClaude CodeExécuté après autorisation, puis rétabli immédiatement
Proposition de modification de tRFC dans le BIOSClaude CodeLe POST n’a plus abouti
Espoir de correction via une mise à jour du BIOSClaude Code« 10 à 20 % ». L’IA elle-même précisait qu’il s’agissait d’une estimation sans fondement
Choix de la mémoire en octobreClaude CodeJ’ai buté sur les points marqués « non vérifié » (coexistence, gestion par le BIOS)

La raison du succès tient au fait que j’ai demandé de séparer les types d’informations dans les rapports. Les enregistrements de la machine réelle, mes souvenirs, les informations documentaires (forums, etc.) et les inférences. J’ai exigé que ces quatre catégories ne soient pas mélangées. J’ai également corrigé le décalage horloge du PC avant de croiser les données temporelles.

Lors des modifications de paramètres, j’ai d’abord effectué une lecture. Avant tout changement, j’ai demandé de noter la valeur initiale et la méthode de retour. C’est moi qui décidais de l’exécution. Je ne modifiais qu’un seul point à la fois.

Le danger réside dans le fait que les propositions des IA sont souvent « correctes sur le plan théorique ». Elles ignorent les particularités de la machine en question, comme les bizarreries du BIOS OEM. Il est plus sûr de ne pas demander de modification irréversible.

Pour ceux qui ont les mêmes symptômes : une liste de vérification dans l'ordre

D'après mon expérience de ces deux jours, voici l'ordre dans lequel je vérifierais.

  1. Vérifier la mémoire actuelle avant d'en ajouter : consulter le numéro de modèle et le rang sur la machine réelle. La mémoire d'origine de mon OMEN était une Kingston double rang destinée à HP.
  2. Choisir sa méthode d'achat : consulter le tableau de compatibilité par modèle du fabricant et acheter chez un revendeur offrant une garantie de compatibilité.
  3. Ne pas se fier uniquement à l'affichage de la capacité dans le BIOS : même si 64 Go s'affichent, le démarrage normal n'était pas possible.
  4. Comparer le comportement en mode sans échec et au démarrage normal : si seul le mode sans échec fonctionne, suspecter à la fois la mémoire et les pilotes.
  5. Activer le journal de démarrage puis redémarrer : voir où le système se bloque. Si rien n'est écrit, cela signifie qu'il s'arrête à un stade très précoce.
  6. Écarter le pilote GPU : désactiver le périphérique, tenter un démarrage normal, puis réactiver immédiatement.
  7. Modifier manuellement les valeurs du BIOS en dernier recours : vérifier d'abord comment revenir en arrière (en retirant la batterie CMOS).
  8. Revenir à la configuration d'origine et vérifier que tout fonctionne : cela permet de restreindre la cause au composant ajouté.
  9. Vérifier aussi la batterie CMOS : si l'horloge revient à 2018 à chaque débranchement du secteur, la pile est à plat.

Ce que j'ai observé sur un OMEN 30L (carte mère 8703, BIOS F.20)

  • L'insertion d'une mémoire non HP fait apparaître « Advanced » (Memory Overclocking) dans le BIOS
  • Les valeurs par défaut de cet écran affichaient 1,35 V et une valeur de 0 pour tWTR_S
  • Avec uniquement la mémoire HP, cette section a disparu

Cependant, je ne peux pas affirmer que c'est nécessairement la cause si les symptômes sont identiques. Le comportement peut varier selon l'état de la machine et la version du BIOS.

Synthèse

Les 64 Go fonctionnaient correctement, tant dans l'affichage du BIOS que lors des tests de mémoire. Pourtant, seul le démarrage normal sous Windows échouait. Comme tout est reparti après avoir réinstallé les deux barrettes d'origine, la cause a été isolée sur l'ajout des barrettes CFD. Cela dit, on ne peut pas conclure à un défaut de ces barrettes. Je vais refaire l'extension avec de la mémoire HP.

L'IA est très rapide et précise pour croiser les journaux et reconstituer une chronologie. En revanche, sa proposition de modifier le BIOS a donné des résultats contraires sur la machine réelle. « Faire distinguer faits et inférences » et « demander d'abord comment revenir en arrière ». Ce sont ces deux points qui ont le plus porté leurs fruits cette fois-ci.

Si j'arrive à passer à 64 Go avec de la mémoire d'origine HP, j'écrirai la suite.

Autres entrées du journal

C'est la première entrée du Journal de bord IA.

Tout le Journal de bord IA →

À propos de cette entrée

A

Équipe éditoriale AIpedia

L'équipe éditoriale d'AIpedia rédige ces entrées à partir des notes de l'éditeur du site lui-même (historique des échanges avec l'IA, sorties d'écran et de commandes, photos). Ce qui n'a pas marché reste dans le texte.