Le contexte doit venir en premier, car tout le reste en dépend. L’instabilité Raptor Lake d’Intel (une catégorie de plantages, de blocages et de dégradation à long terme des puces qui touche une large partie du silicium Intel Core de 13e et 14e génération, pour ordinateurs de bureau comme pour portables) n’est pas un problème créé par Minisforum. Intel l’a causée, Intel l’a confirmée, et Intel a prolongé la garantie des références concernées après avoir identifié la cause profonde : la combinaison de l’algorithme eTVB (enhanced Thermal Velocity Boost) et d’un mécanisme de dégradation VMin Shift dans les cœurs touchés. Les acheteurs dont les puces Raptor Lake se sont comportées de façon erratique ces deux dernières années ont un grief légitime, d’abord et avant tout envers le fabricant du silicium. C’est le cadre juste.

Si cela vaut malgré tout la peine d’écrire sur Minisforum, c’est parce que, parmi toutes les manières dont un fabricant de matériel peut réagir à un bug connu en amont, sur le silicium qu’il vend, Minisforum a choisi l’une des plus discrètes, et ses clients vivent encore avec les conséquences de ce choix.

Comment le Minisforum MS-01 a été touché

Le MS-01 a été lancé avec les Core i9-13900H et Core i5-13500H d’Intel comme ses deux configurations CPU haut de gamme. Ce sont deux puces Raptor Lake de 13e génération. Toutes deux font partie des références Intel pour lesquelles le forum Intel Community a documenté des schémas d’instabilité signalés par les utilisateurs, cohérents avec la reconnaissance finale du problème eTVB / VMin Shift par l’entreprise, et que la couverture de VideoCardz en 2024 décrivait comme une enquête à l’échelle de l’industrie.

Dans le cas précis du MS-01, le problème se manifeste sous deux formes. Le test de NotebookCheck consacré au MS-01 en i9-13900H, en tant que station de travail, a constaté des plantages imprévisibles lors de passes Cinebench en boucle, soit exactement le test de charge soutenue qui fait ressortir les dérives de tension et de boost de Raptor Lake. Le fil du forum XCP-ng sur l’instabilité du MS-01 sous charge d’hyperviseur illustre l’autre forme : des machines qui semblent fonctionner normalement sous des charges de bureau, puis se bloquent ou redémarrent lorsqu’on leur confie une charge de virtualisation qui occupe de nombreux cœurs pendant de longues périodes.

Rien de tout cela ne prouve un défaut matériel propre au MS-01. Cela montre Raptor Lake atteignant les limites de son propre silicium, dans un châssis qui ne présente aucune caractéristique thermique ou électrique inhabituelle susceptible de faire se comporter le silicium autrement qu’ailleurs. À lire aussi : l’instabilité du 2.5GbE Intel i226-V sur les MS-01 et MS-A2 et la pâte thermique d’usine du MS-01.

Ce que Minisforum a fait, et ce qu’il n’a pas écrit

Minisforum a publié des mises à jour BIOS pour le MS-01 pendant la période concernée. Certaines contiennent des révisions de microcode qui, d’après les éléments disponibles en aval, correspondent au microcode fourni par Intel pour corriger le comportement de Raptor Lake. C’est la bonne moitié de l’histoire. Les propriétaires de MS-01 qui ont tenu leur BIOS à jour ont, dans l’ensemble, profité des correctifs finalement publiés en amont.

La moitié moins reluisante, c’est que les notes de version BIOS de Minisforum, au moment où l’essentiel de ces correctifs était déployé, n’en disaient rien. Un client qui lisait ces notes voyait des numéros de version, des listes de modifications formulées en termes génériques (« improved stability », « updated microcode ») et aucune mention explicite indiquant que la mise à jour corrigeait le bug CPU reconnu par Intel. Un client qui ne suivait pas l’affaire Raptor Lake à l’échelle de l’industrie n’avait aucun moyen de savoir si l’instabilité de sa machine était corrigée par la mise à jour qu’il avait sous les yeux. La décision de flasher ou non un BIOS (un acte loin d’être anodin sur un mini PC de 1,9 litre qui peut être briqué en cas d’échec) se prenait sans les informations nécessaires pour peser le pour et le contre.

Les informations dont le client avait besoin

Dans ce scénario précis, une bonne note de version BIOS aurait dit trois choses, en termes clairs :

  1. Le bug corrigé. « Cette mise à jour inclut la révision de microcode Intel XXX, qui corrige l’instabilité Raptor Lake eTVB / VMin Shift décrite par Intel dans l’avis YYY. »
  2. Les machines concernées. « Les configurations MS-01 en i9-13900H et i5-13500H sont concernées. Les configurations en i9-12900H ne sont pas touchées. »
  3. Ce à quoi l’utilisateur doit s’attendre. « Avant la mise à jour : si vous avez constaté des blocages inattendus sous charge soutenue, cette mise à jour est recommandée. Après la mise à jour : les performances sous charge soutenue peuvent différer de N % au maximum par rapport aux versions précédentes du BIOS, en raison d’un comportement de boost révisé. »

Rien de tout cela n’est apparu. Dans chaque cas, c’était au client de lire Tom’s Hardware, Ars Technica et le fil de l’Intel Community, de traduire ce qu’il avait lu en décision de mise à jour de son propre BIOS, et d’espérer que cette traduction soit juste. Certains acheteurs ont fait la bonne traduction. D’autres ont purement et simplement cessé de mettre à jour leur firmware, parce que la confiance nécessaire pour flasher le BIOS sans notes de version claires dépassait celle qu’il leur restait.

Le reproche de fond

Il est franchement injuste de reprocher à un fabricant de mini PC le bug du silicium d’Intel. Ce qu’on peut légitimement lui reprocher, c’est le rythme et la franchise de sa communication envers les clients qui ont payé ce silicium par son intermédiaire. Sur l’affaire Raptor Lake du MS-01, Minisforum a choisi de livrer le correctif sans nommer le problème, un style de communication qui fonctionne pour une clientèle qui lit chaque jour les forums de passionnés, et qui laisse tomber tous les autres clients. Deux ans après le début du cycle de vie de ces puces, certains propriétaires de MS-01 ne savent toujours pas si leur BIOS contient les correctifs Raptor Lake, parce que la documentation qui leur permettrait de le vérifier n’a jamais été rédigée. Ce silence n’est pas un bug du silicium. C’est un choix du fabricant qui leur a vendu ce silicium.