L'ASUS ROG Flow Z13 : mon labo maison portable qui refusait de rester portable

L'ASUS ROG Flow Z13 n'a jamais été censé être un serveur. C'est une tablette de jeu avec un clavier détachable, une barre lumineuse RGB, et assez de GPU pour jouer aux plus gros titres avec des réglages honorables. Je l'ai achetée reconditionnée en février 2026 comme poste de travail portable — quelque chose que je pouvais glisser dans un sac, brancher sur une station d'accueil à la maison, et utiliser comme ma machine à tout faire. Pendant cinq mois, c'est exactement ce qu'elle a fait, et elle l'a fait mieux que du matériel deux fois plus imposant.

Puis elle a développé une panne d'alimentation, et elle n'a plus jamais terminé un démarrage depuis.

Fiche technique complète

Composant	Caractéristique
Modèle	ASUS ROG Flow Z13 (2025) — GZ302EA
CPU	AMD Ryzen AI Max+ 395 « Strix Halo » — 16 cœurs / 32 threads, jusqu'à 5,1 GHz, 80 Mo de cache
GPU	AMD Radeon 8060S — RDNA 3.5, intégré, 40 unités de calcul
NPU	AMD XDNA — jusqu'à 50 TOPS
RAM	128 Go LPDDR5X-8000, soudée (mémoire unifiée CPU/GPU)
Stockage	1 To NVMe PCIe 4.0, M.2 2230
Écran	13,4" 2560×1600, 180 Hz, tactile
Batterie	70 Wh
Ports	2× USB4 Type-C, 1× USB 3.2 Type-A, HDMI 2.1, microSD, jack combo 3,5 mm
Sans fil	Wi-Fi 7, Bluetooth 5.4
Poids	~1,2 kg (tablette) / ~1,5 kg (avec le clavier folio)
OS	Windows 11 à l'achat ; a fait tourner Bazzite (Fedora Atomic) toute sa vie de service
Particularité	Clavier folio détachable avec RGB par touche, barre lumineuse en bordure, prise en charge du stylet

Le chiffre marquant, c'est les 128 Go. Comme il s'agit de LPDDR5X unifiée partagée entre CPU et GPU, je pouvais en réserver 64 Go comme VRAM tout en gardant 64 Go pour le système d'exploitation. Début 2026, aucune autre machine que l'on pouvait tenir dans une main ne permettait cela.

Ce qu'elle faisait tourner, au quotidien

Un modèle de 120 milliards de paramètres, en local

La mémoire, c'était tout l'intérêt. Avec 64 Go réservés comme VRAM et ROCm pilotant l'iGPU RDNA 3.5, je faisais tourner un modèle de 120 milliards de paramètres sur cette tablette — lentement, mais réellement, à une vitesse utilisable pour du travail en arrière-plan. Les modèles plus petits étaient confortables : un MoE de 30B tournait autour de 70 jetons/seconde, ce qui convient très bien à un usage interactif.

Cette capacité a façonné toute la stack que j'ai construite dessus. Mon effectif d'agents avait un palier qui ne touchait jamais une API cloud : le broyage en masse, les passages nocturnes, et tout ce que je ne voulais pas voir sortir de la maison partait vers le modèle local, et ça ne coûtait que l'électricité. La configuration OpenClaw à huit agents et l'analyse des coûts supposent toutes deux que ce palier existe, parce que sur cette machine, il existait.

Développement et hébergement

Chaque site que je maintiens a été rédigé, construit et prévisualisé ici avant déploiement — celui-ci y compris. Les ports USB4 pilotaient un moniteur 4K et une station d'accueil, si bien que la même tablette devenait un poste de travail de bureau en environ quatre secondes.

Infrastructure toujours active

Elle faisait tourner Tailscale comme colonne vertébrale de mon réseau domestique, ainsi qu'une pile de services systemd qui maintenaient tout le monde en communication. Elle était toujours allumée, toujours branchée, et toujours sous une certaine charge. Ce dernier point compte pour la suite de cette histoire.

Ce qui a brillamment fonctionné

• 128 Go de mémoire unifiée. Cette seule caractéristique plaçait le Z13 dans une catégorie à part. Faire tourner un modèle de 120B sur une tablette reste vaguement absurde, et rien d'autre de portable n'en approchait à l'époque.
• La compatibilité Linux. Une fois passé de Windows 11 à Bazzite, tout s'est mis en place. Le protocole HID Aura d'ASUS fonctionnait via hidraw, ROCm pilotait l'iGPU, et des unités systemd remplaçaient chaque processus d'arrière-plan de Windows par quelque chose de plus propre.
• Le format. Tablette sur le canapé, bureau sur la station d'accueil, serveur headless derrière le moniteur — toujours la même machine, changée de rôle en quelques secondes. Le clavier folio était vraiment bon : course complète, aucune flexion.
• Les performances GPU. Quarante unités de calcul RDNA 3.5 géraient la CAO, l'inférence locale et un peu de jeu. Ça ne s'est jamais comporté comme des graphismes intégrés.

Ce qui n'a pas fonctionné

• La thermique sous charge soutenue. Le châssis fin n'avait qu'une seule stratégie face à la chaleur : faire tourner les ventilateurs plus fort. Une longue session d'inférence la transformait en sèche-cheveux, et le châssis devenait inconfortable à tenir.
• La délivrance d'énergie sous charge combinée. La charge se fait en USB-PD via les ports Type-C. Sous une lourde charge CPU+GPU combinée, la plateforme pouvait tirer plus que le chargeur n'était disposé à fournir, si bien que la batterie se vidait doucement même branchée — la machine se rechargeant en réalité depuis la batterie pour combler l'écart.
• L'autonomie sous Linux. Windows tenait six à huit heures grâce au réglage fin du firmware d'ASUS. Linux offrait trois à quatre heures dans le meilleur des cas, et la mise en veille/réveil avec un clavier détachable était une source récurrente d'irritation liée à udev.
• Pas réparable. La RAM est soudée et le châssis est scellé. Le SSD M.2, accessible par une trappe dans le béquille, est la seule pièce réparable par l'utilisateur dans la machine — ce qui s'est révélé être exactement ce qui m'a sauvé.

Le projet de clavier RGB

Armoury Crate d'ASUS — la seule méthode officielle pour contrôler le RGB du clavier et de la barre lumineuse — n'existe pas sous Linux. J'ai donc écrit le mien : un CLI Python parlant directement à l'interface HID Aura, un sélecteur de couleurs GTK4, et un panneau navigateur sur localhost. Environ 40 Ko en tout, et il survivait à la veille, au redémarrage et au détachement du clavier — le trio que tout autre outil RGB Linux oublie.

C'est devenu l'un des articles les plus lus de ce site. Lire l'article complet sur le clavier RGB →

Comment ça s'est terminé : une panne d'alimentation

Vers le 19-20 juillet 2026, le Z13 a cessé de terminer un démarrage. J'y ai passé deux jours avant de conclure que ce n'était pas réparable de mon côté. La panne est suffisamment précise pour mériter d'être bien documentée, parce que « il ne s'allume pas » est la phrase la moins utile de toute l'informatique — et dans ce cas, elle n'est même pas exacte. Elle s'allume très bien. Elle refuse simplement de rester éveillée.

Les symptômes, dans l'ordre

1. Le démarrage se bloque sur un logo ROG statique. Pas la version animée — une image figée. Il n'atteint jamais une invite « appuyez sur F2 », n'atteint jamais le BIOS, n'atteint jamais un chargeur de démarrage. Le point d'arrêt variait d'une tentative à l'autre : parfois un écran mort sans rétroéclairage, parfois un écran noir allumé avec les ventilateurs qui tournent, parfois le logo figé.
2. Le clavier folio est mort au démarrage. Le rétroéclairage clignote en blanc au redémarrage, puis plus rien. F2, Échap et Suppr ne réagissent jamais. Cela correspond à un défaut connu sur ce modèle, où le contrôleur du clavier reste bloqué en mode chargeur de démarrage.
3. Aucune alimentation du bus USB pendant le POST. J'ai branché un clavier RGB externe pendant que le logo était à l'écran : aucune lumière, aucune alimentation. À ce stade du POST, le port devrait être actif. Il ne l'était pas — ce qui indique que la gestion des rails d'alimentation du contrôleur embarqué est bloquée, pas que l'OS est absent.
4. Un événement thermique. J'ai trouvé la machine avec l'écran éteint, les ventilateurs à l'arrêt, sur secteur, et le châssis très chaud. Cette combinaison est l'alarmante : le SoC consommait de l'énergie en état planté, sans rien pour gouverner les ventilateurs. Après un refroidissement forcé, la température du boîtier s'est stabilisée autour de 36 °C avec un ventilateur externe braqué dessus — confirmant que la chaleur était l'anomalie, pas la normale.
5. L'indice révélateur : une LED de veille sous une image figée. Après une réinitialisation de l'EC, la LED d'alimentation s'est installée sur un clignotement lent — environ une seconde allumée, cinq secondes éteinte. Selon la spec officielle d'ASUS pour les indicateurs, ce motif signifie que l'ordinateur portable est en mode veille. Une machine ne peut pas être endormie tout en affichant simultanément un logo de POST sur son écran. Cette contradiction, c'est le diagnostic.
6. C'est reproductible. Un appui de réveil ramenait la LED en blanc fixe pendant environ 30 secondes, puis elle retombait au clignotement de veille. Démarrage à froid, réveil, démarrage à froid : mêmes 30 secondes, même résultat, à chaque fois.

La séquence est donc : le firmware se bloque tôt dans le POST, le contrôleur embarqué fait basculer la plateforme en veille moderne sous ce firmware bloqué, et le contrôleur d'affichage reste accroché à la dernière image qu'on lui a donnée. Le logo figé, ce n'est pas la machine qui réfléchit. C'est une image immobile sur un ordinateur endormi.

Ce que j'ai essayé

• Des redémarrages forcés et des réinitialisations standard, à répétition.
• Une réinitialisation matérielle EC/RTC dans les deux sens — appui de 40 secondes sur le bouton d'alimentation avec le secteur branché, puis à nouveau secteur débranché puis rebranché. Sur cette plateforme, c'est l'équivalent électrique de retirer la pile CMOS.
• Un démontage complet des périphériques : clavier détaché, microSD retirée, tous les câbles USB-C et HDMI débranchés, démarrage en tablette nue.
• Une attente de 45 à 60 minutes sans y toucher après la réinitialisation, au cas où le réentraînement de 128 Go de mémoire ou une capsule de firmware en attente aurait besoin de ce temps.
• Une entrée dans le BIOS via le folio (mort), via un clavier USB externe (port sans alimentation), et via Volume bas + alimentation.
• Un refroidissement complet, puis un nouveau test à froid.

J'ai sauté le débranchement physique de la pile CMOS : l'appui de 40 secondes effectue déjà cette réinitialisation électriquement, et ça ne répare ni un EC bloqué ni un défaut de délivrance d'énergie. J'ai aussi sauté tout ce qui touche à l'OS, pour la raison ci-dessous.

Ce que j'ai écarté, et comment

Suspect	Verdict	Pourquoi
Logiciel / OS / paramètres du noyau	Innocenté	Le blocage survient avant qu'aucun chargeur de démarrage ne se charge. Rien sur le disque ne s'exécute au point de la panne, donc aucune configuration qui s'y trouve ne peut en être la cause.
Périphérique de démarrage / SSD	Innocenté	Le rail USB mort et la signature « plantage vers la veille » se situent tous deux au-dessus de la couche de stockage. Le SSD a ensuite été retiré et est sain — il tourne dans la machine de remplacement.
Blocage thermique	Innocenté	La panne se reproduit à froid, à environ 36 °C.
Batterie à plat	Innocenté	Le clignotement est le pouls blanc de veille, pas l'indicateur orange de batterie faible.

Pas seulement mon unité

C'est une classe de panne documentée sur ce modèle, plutôt qu'une malchance sur une seule carte. Il existe un fil de discussion actif sur le forum ROG décrivant le même comportement sur le GZ302EA — des plantages répétés en écran noir et blocages durs liés à la veille moderne — et un signalement distinct, bien connu, du contrôleur du clavier folio qui reste bloqué en mode chargeur de démarrage sous Linux. Les deux correspondent exactement à ce que j'ai observé.

Si vous lisez ceci parce que votre propre Z13 est bloqué sur un logo figé : chronométrez l'intervalle avant que la LED d'alimentation ne commence son clignotement lent. Si c'est environ 30 secondes, vous avez cette panne, et aucune réinstallation n'y changera rien.

Ce que deux jours de dépannage ont vraiment rapporté

Pas une réparation. Ce que ça a rapporté, c'est une certitude — la différence entre « c'est cassé, j'ai peut-être fait quelque chose » et savoir précisément quelle couche a échoué, et qu'aucune quantité de mon temps ne le ferait bouger. Cinq faits portent cette certitude :

• Un plantage reproductible vers la veille à environ 30 secondes, aussi bien à froid qu'au réveil.
• Une LED d'état de veille affichée en même temps qu'un logo de POST figé — un état dans lequel une machine saine ne peut pas se trouver.
• Un événement thermique : châssis chaud, ventilateurs arrêtés, sur secteur, en état planté.
• Aucune alimentation du bus USB pendant le POST.
• Un fil de discussion sur un défaut spécifique à ce modèle décrivant un comportement identique sur les unités d'autres personnes.

Ce dernier point a compté le plus pour la façon dont je l'ai vécu. Quand une machine meurt, on a le réflexe de s'auditer soi-même — le paramètre du noyau qu'on a réglé, la mise à jour qu'on a lancée, la chose qu'on a laissée compiler toute la nuit. Trouver la même signature de 30 secondes décrite par des inconnus sur le forum même du fabricant a réglé cette question, et a fait d'arrêter une décision simple plutôt qu'un doute persistant.

Je n'ai jamais déposé de demande de garantie. L'unité était reconditionnée, poursuivre la démarche aurait signifié des semaines sans la machine dont j'avais réellement besoin, et j'avais déjà commandé le remplacement. Le Z13 est donc sur une étagère, moins son SSD, qui est sorti par la trappe du béquille et est allé directement dans la boîte de celle qui l'a remplacé. Cette trappe est la seule pièce de conception de cette machine qui a payé jusqu'au bout.

Ce que je dirais à quiconque fait tourner une tablette comme serveur

Je ne suis pas fâché contre le Z13. Il a fait plus qu'aucune tablette n'avait le droit de faire, et il l'a fait pendant cinq mois sans se plaindre. Mais il y a une vraie leçon dans la forme de cette panne, et ce n'est pas « le matériel grand public, c'est mauvais ».

C'est qu'une machine construite autour d'une batterie possède une machine à états de gestion d'énergie conçue pour un appareil qui se charge, se décharge, s'endort et se réveille. La faire tourner comme serveur revient à la maintenir dans un seul coin de cette machine à états — branchée, chaude, jamais endormie — pendant des mois d'affilée. Ce n'est pas la charge de travail pour laquelle le firmware a été réglé, et la panne qui a fini par arriver était une panne de gestion d'énergie, pas un CPU cassé ou un disque plein.

La version pratique : si une machine doit servir d'infrastructure toujours active, préférez-en une dont l'histoire d'alimentation se résume à un connecteur jack et un ventilateur. Et gardez vos données quelque part où la mort de la machine ne peut pas les emporter avec elle — la seule raison pour laquelle cette histoire a une fin propre, c'est que le SSD était derrière une trappe plutôt que derrière une soudure.

Ce qui l'a remplacée

La remplaçante est un CHUWI AuBox Ai365 — un petit mini PC AMD avec un Ryzen AI 9 365, du double 2,5 GbE, et un simple connecteur jack. Il a 30 Go de mémoire utilisable contre les 128 Go du Z13, ce qui m'a coûté le gros modèle local pur et simple ; ce palier fait maintenant tourner un MoE de 35B au lieu d'un 120B, et le gros du travail est parti vers une API cloud bon marché. En échange, il n'a ni batterie, ni négociation USB-PD, ni veille moderne où planter.

Lire l'article sur la configuration du CHUWI AuBox Ai365 →