Le 5 août, un Framework Laptop 13 qui fonctionnait depuis environ trois ans a cessé d'être un ordinateur portable. Il est devenu un projet d'électronique sur établi.
Son propriétaire, Guanzhong Chen, venait de lancer le flash du BIOS 3.20 avec fwupdmgr. La machine redémarre dans l'outil de flash ; l'écran affiche alors un motif triangulaire corrompu et n'avance plus. Chen attend. Rien ne repart. Après la décharge complète de la batterie, le portable ne démarre plus normalement.1
Ce serait déjà une bonne histoire pour rappeler qu'écrire un firmware reste une opération à risque. Ce qui la rend plus intéressante, c'est la machine concernée.
Chen explique avoir choisi Framework en partie pour sa réparabilité et son évolutivité. Le récit montre vite la différence : RAM et SSD choisis séparément, ports interchangeables, pièces accessibles, et sous Linux le firmware arrive par le Linux Vendor Firmware Service plutôt que par un utilitaire Windows sorti d'un tiroir.16
Après l'échec du BIOS, la nature de la réparation change brutalement. Le support Framework fait passer plusieurs procédures de réinitialisation et de diagnostic. Chen rapporte qu'une fois ces pistes épuisées, et sa garantie terminée, l'option proposée devient le remplacement de la carte mère, à un tarif dépassant 500 dollars canadiens.1
Il choisit autre chose. Pour environ 20 dollars US d'outils achetés, il reprogramme directement la puce flash qui contient le BIOS.1
La version facile de l'histoire serait donc : un propriétaire bat le constructeur avec un programmateur bon marché.
C'est précisément la version la moins intéressante.
Réécrire une flash n'a rien de nouveau, les réparateurs font ça depuis longtemps. Ce qui frappe ici, c'est le grand écart demandé au propriétaire : il avait acheté un portable où un tournevis suffit pour changer des modules, puis le voilà à identifier une flash SPI 1,8 V, vérifier des niveaux électriques, extraire une image BIOS et maintenir une sonde pogo sur une puce minuscule.1
La réparabilité n'avait pas disparu. Elle avait changé d'interface.
Et cette nouvelle interface ressemblait davantage à un banc d'électronique qu'à une procédure destinée au propriétaire de la machine.
Une carte mère remplaçable n'est pas une carte mère récupérable
Le récit de Chen montre bien ce que Framework change physiquement. Il achète sa RAM et son SSD séparément, utilise des ports interchangeables, et le support lui propose plus tard la carte mère comme une pièce distincte.1 C'est très différent d'un portable où stockage, mémoire et connectique sont considérés comme des choix définitifs.
Cette modularité compte, mais elle pousse vite vers une définition un peu courte de la réparation. Si vous pouvez isoler la pièce, l'acheter et la remplacer, vous avez l'impression que le problème est réglé.
Le firmware casse ce modèle.
Rien n'a visiblement brûlé sur la carte de Chen et le processeur n'a aucune raison d'être remplacé. Quelques minutes plus tôt, le portable fonctionnait assez bien pour lancer le flash ; c'est pendant cette écriture que disparaît la petite couche de logiciel chargée de réveiller correctement tout le reste de la machine.
Les deux fils de la communauté Framework ouverts pendant ce run montrent la même frontière.
En juillet 2026, plusieurs propriétaires d'un Framework 13 AMD Ryzen 7040 racontent que le passage du BIOS 3.18 au 3.20 s'est figé pendant le flash.2 Un autre fil, publié en mars 2025, décrit un passage de 3.05 à 3.07 qui se termine par un écran corrompu, puis une machine qui ne démarre plus. Après plusieurs échanges avec le support, son propriétaire, lui aussi hors garantie, raconte qu'on lui indique qu'il faudra acheter une nouvelle carte mère.3
Il la récupère malgré tout.
Sa méthode est plus brutale que celle de Chen : des fils soudés sur les broches de la flash SPI, un convertisseur de niveau, une alimentation externe et un Raspberry Pi configuré pour communiquer en SPI. Il commence par relire plusieurs fois la puce, histoire de vérifier qu'il n'est pas en train de travailler sur une connexion bancale, puis extrait la ROM de la capsule Framework et l'écrit directement dans la flash.3
Deux récupérations de ce type ne donnent évidemment pas un taux de panne. Vous ne pouvez pas en déduire que toutes les cartes AMD 7040 ont le même défaut, ni que Framework ne possède aucun mécanisme de secours ailleurs dans sa gamme.
Elles établissent quelque chose de beaucoup plus précis : dans ces deux cas documentés, les procédures normales n'ont pas restauré la machine, alors qu'une programmation externe de la flash a fonctionné.13
C'est assez pour poser une question de conception.
Une carte mère peut être très facile à retirer du châssis et rester inutilement difficile à récupérer.
La distribution du firmware a, elle, beaucoup progressé
Le flash raté ne venait pas d'un exécutable obscur récupéré dans une archive de forum.
Framework publie ses versions de BIOS et de pilotes pour les machines AMD Ryzen 7040 dans sa base de connaissances.4 Sous Linux, Chen utilisait fwupdmgr, l'outil en ligne de commande associé à fwupd.1
L'infrastructure derrière cette expérience est plutôt bonne.
Le Linux Vendor Firmware Service se décrit comme un portail sécurisé où les fabricants peuvent publier leurs firmwares avec des métadonnées, afin que des clients comme fwupdmgr ou GNOME Software les distribuent dans les différentes distributions Linux.6
Cela supprime une vieille absurdité : avoir besoin d'un Windows précis, d'une image de démarrage exotique ou d'un utilitaire constructeur particulier simplement pour mettre à jour un composant que l'on possède.
Mais distribuer et récupérer sont deux problèmes différents.
Le chemin normal répond à une question assez simple : comment faire parvenir la nouvelle image jusqu'à la machine ?
Un bon chemin de récupération répond à : que se passe-t-il si cette opération s'arrête au milieu ?
Tant que tout fonctionne, les deux semblent ne former qu'une seule opération. Le portable redémarre, applique la capsule, puis revient à la vie. Le propriétaire n'a aucune raison de savoir quelle zone de flash a été écrite ou quel composant exécute les premières instructions au démarrage.
Quand la procédure échoue, cette architecture cachée devient soudain le manuel de réparation.
LVFS réussit à rendre le firmware plus proche d'un logiciel ordinaire. Un BIOS briqué rappelle qu'il reste du logiciel enfermé dans un système électrique dont il faut réussir à exécuter les toutes premières instructions avant d'avoir accès à presque tous les autres outils de secours.
Il faut encore un peu d'ordinateur pour réparer l'ordinateur
Beaucoup de pannes logicielles sont récupérables parce qu'une couche inférieure reste vivante.
Une application cassée peut être réinstallée par le système. Un système cassé peut être réparé depuis un support de démarrage. Un disque peut être inspecté depuis un environnement de secours. Chaque couche compte sur quelque chose, en dessous, qui fonctionne encore assez pour charger des outils.
Le firmware est presque au fond de cette pile, et c'est là que les ennuis deviennent moins confortables.
Si le code chargé d'initialiser la mémoire, les périphériques et les supports de démarrage est suffisamment endommagé, conseiller de « télécharger l'installateur » devient une blague assez cruelle. Il faut soit un mécanisme de récupération plus petit et protégé qui survive à la panne, soit apporter la réparation depuis l'extérieur.
Dell documente par exemple une récupération BIOS sur les systèmes compatibles. La procédure peut utiliser un fichier de récupération déjà stocké sur le disque, avec une clé USB préparée comme solution de repli. La documentation vise explicitement les cas de firmware BIOS corrompu, d'écran noir ou d'échec du POST.7
Cela ne permet évidemment pas de conclure que tous les Dell sont « plus réparables » que tous les Framework. La réparabilité d'un portable ne se résume pas à une seule page de support.
La comparaison prouve simplement une chose : une récupération BIOS accessible au propriétaire est un choix de conception possible sur un PC.
Chen rappelle lui-même avoir connu sur une ancienne carte mère ASUS un mécanisme capable de chercher une image de firmware après un mauvais flash.1 Les implémentations changent. L'idée reste la même : conserver un chemin qui ne dépend pas de la zone de firmware que l'on est justement en train de modifier.
Sans ce chemin, vous descendez encore d'un étage et vous arrivez directement sur la puce.
Le BIOS est aussi un petit objet électrique
Le mot « BIOS » fait vite oublier qu'à un moment les octets sont stockés dans un composant physique.
Sur la carte AMD 7040, Chen identifie une flash série Winbond, son format de boîtier et sa tension de fonctionnement.1 La puce utilise un petit boîtier WSON. Elle communique en SPI. Elle fonctionne à 1,8 V, et non aux 3,3 V fréquents dans le matériel de programmation destiné aux amateurs.1
Ces détails décident si la réparation récupère la machine ou lui offre une deuxième panne gratuite.
Sur le papier, le programmateur ne fait pas grand-chose : vous identifiez la puce, vous lisez son contenu, vous effacez, vous écrivez, puis vous vérifiez. flashrom, l'outil libre utilisé par Chen, documente précisément ces opérations sur des puces BIOS/EFI et d'autres firmwares, en interne ou avec des programmateurs externes. Sa documentation cite également la reprogrammation comme technique de récupération.5
La simplicité s'arrête au bord du schéma électrique.
Les programmateurs CH341A sont très répandus parce qu'ils transforment pour quelques euros un port USB en outil SPI utile. Chen mesure cependant sur un modèle qu'il envisage une tension qui ne convient pas à sa flash 1,8 V sans adaptation. Il finit par utiliser un programmateur à base de CH347, un convertisseur vers 1,8 V et une sonde pogo WSON8.1
C'est le genre de réparation où un adaptateur à quelques dollars peut être plus important que la carte à plusieurs centaines de dollars sur laquelle on le branche.
C'est aussi pour cela que « réparé avec 20 dollars d'outils » ne veut pas dire « réparation facile à 20 dollars ».
Les outils sont bon marché. La connaissance, beaucoup moins.
Une sonde pogo évite la soudure, pas la complexité
Dans la récupération de mars 2025, le propriétaire avait soudé des fils directement sur les connexions de la flash.3 Chen cherche à éviter cette modification de la carte.
La pièce clé de son montage est une sonde munie de contacts pogo adaptés au boîtier WSON.1
Une opération difficile disparaît, mais ne vous imaginez pas pour autant un câble USB magique.
Il faut déconnecter la batterie. Positionner correctement la sonde. Respecter les tensions. Comprendre qu'un programmateur peut alimenter d'autres parties du circuit autour de la flash. Obtenir plusieurs lectures cohérentes avant de faire confiance à une écriture. Et, surtout, disposer de la bonne image dans le bon format pour la bonne zone de mémoire.13
L'accessibilité physique du Framework aide réellement ici. Chen peut exposer la carte et atteindre la puce sans détruire le châssis. C'est bien une forme de réparabilité.
Mais accéder au composant et accéder à une procédure de récupération sont deux choses différentes.
La première est mécanique. La seconde est électrique et informationnelle.
Un objet réellement maintenable doit finir par s'occuper des deux.
Le fichier constructeur et l'image réellement écrite dans la puce
Même une fois la flash atteinte, Chen ne dispose pas encore d'un simple fichier brut à écrire.
Les paquets firmware des constructeurs servent d'abord à leurs outils d'installation. Ils peuvent contenir des capsules, métadonnées, signatures, plusieurs régions ou une organisation différente de la mémoire physique.
Chen utilise un outil d'extraction InsydeH2O, puis le modifie pour obtenir depuis le paquet Framework l'image nécessaire à son programmateur.1
Ce détail est discret. Il est pourtant central.
Dire qu'un firmware est « disponible » peut vouloir dire au moins six choses différentes :
- l'utilitaire d'installation existe ;
- une capsule signée existe ;
- le code source existe ;
- un binaire brut adapté à un programmateur existe ;
- les anciennes versions restent téléchargeables ;
- la documentation explique où et comment écrire les octets.
Ces niveaux ne sont pas interchangeables.
Un constructeur peut proposer un excellent système automatique tout en laissant la récupération bas niveau dépendre d'une extraction ou d'un reverse engineering. Et l'inverse n'est pas plus satisfaisant : une ROM brute disponible quelque part ne remplace pas un mécanisme d'installation sûr.
La réparabilité a besoin des deux directions : un chemin confortable quand la machine fonctionne, et une sortie documentée quand elle ne fonctionne plus.
Cette sortie ne doit pas forcément transformer chaque propriétaire en électronicien. Elle peut prendre la forme d'une partition protégée, d'une seconde banque de firmware, d'un mode de récupération USB ou d'un connecteur de service documenté.
Le critère est finalement assez simple : pour réparer une couche qui peut disparaître, le secours doit vivre plus bas qu'elle.
La redondance paraît inutile jusqu'au jour où la copie principale meurt
Un mécanisme de récupération ressemble facilement à du gaspillage quand le démarrage fonctionne.
Une deuxième copie de firmware prend de la place. Un contrôleur de secours ajoute des composants. Une combinaison de touches doit être testée. Un connecteur de service occupe de la surface. Les fichiers de récupération doivent rester disponibles et correctement signés.
Tout cela coûte pour un événement que la majorité des propriétaires ne verra jamais.
La réparabilité est pleine de ce genre de dépenses « inutiles ».
Une vis prend plus de place qu'une goutte de colle. Un connecteur coûte plus qu'une soudure permanente. Une batterie remplaçable réclame une interface mécanique. Un fichier de secours dort pendant presque toute la vie du produit.
Son intérêt n'apparaît qu'au moment de la panne.
C'est pour cela que mesurer la réparabilité seulement à partir d'un démontage peut être trompeur. Un appareil peut s'ouvrir parfaitement et conserver des points de rupture catastrophiques dans son firmware, son authentification, ses calibrations ou ses services distants.
Les meilleures fonctions de réparation sont souvent des interfaces latentes : invisibles pendant des années, puis soudain décisives entre une procédure et un remplacement complet.
La sûreté des mises à jour fait partie de la durabilité matérielle
Un nouveau BIOS est généralement présenté comme de la maintenance logicielle et de sécurité. Le BIOS 3.20 existe parce que le firmware continue d'évoluer, et Chen rapporte que Framework recommandait de rester à jour pour la sécurité, la stabilité et les performances.14
Cela crée une tension assez nette.
Une machine durable doit continuer à recevoir des correctifs, car les vulnérabilités ne prennent évidemment pas leur retraite avec la garantie. Le problème, c'est que chaque flash réécrit aussi une couche nécessaire au démarrage.
Si vous apprenez qu'un correctif peut transformer votre carte encore saine en pièce à plusieurs centaines de dollars, la tentation de ne plus toucher au BIOS devient assez rationnelle.
Mauvais résultat pour la sécurité. Mauvais résultat pour la longévité.
Un vrai mécanisme de secours change complètement ce calcul. Installer le nouveau firmware ressemble moins à un pari à sens unique lorsqu'une route plus basse permet encore de revenir en arrière si l'écriture, l'alimentation ou l'outil plante.
C'est là que la récupération firmware cesse d'être une curiosité réservée aux passionnés de BIOS. Elle devient une partie de la durabilité physique.
Un portable capable de rester mécaniquement utile huit ans a aussi besoin d'un processus de maintenance firmware suffisamment sûr pour être encore utilisé la sixième année.
Sinon, l'opération conçue pour prolonger le support sécurisé peut raccourcir la vie du matériel.
Le prix de la réparation n'est pas celui du programmateur
La liste d'achats de Chen est réjouissante parce qu'elle met côte à côte quelques composants à bas prix et une carte mère à plus de 500 dollars canadiens.1
Mais si vous confondez le prix du matériel avec le coût de la réparation, vous ratez toute la partie diagnostic.
Chen passe du temps à lire des retours de forum, identifier la flash, comparer des programmateurs, mesurer les tensions, extraire le firmware, attendre les pièces, vérifier le contact et répéter les lectures avant de risquer une écriture.1
Le propriétaire du cas de 2025 avait besoin de soudure, d'une alimentation externe, d'un convertisseur, d'un Raspberry Pi et de suffisamment d'expérience pour remarquer que le rail alimenté consommait bien plus que la flash seule ne devrait consommer.3
C'est du travail. Surtout, c'est du diagnostic sous incertitude.
La réparation paraît peu chère parce que ces propriétaires possèdent déjà, ou acceptent d'acquérir, des compétences qu'un service professionnel devrait facturer.
La documentation fait donc partie de l'outillage, même si elle ne tient pas dans la boîte à outils.
Si le fabricant donne l'identité de la puce, sa tension, le format de l'image, les broches du connecteur ou des pads de service et une procédure de vérification, la même intervention physique devient beaucoup moins coûteuse sans changer une seule vis.
La connaissance réduit la partie la plus chère : l'incertitude.
La réparation existe aussi parce que quelqu'un l'a documentée
Il y a une autre pièce dans cette réparation, sauf qu'elle n'est pas soudée sur la carte mère. Chen publie un billet très détaillé avec des photos de la puce, du programmateur, du convertisseur de niveau et de la sonde pogo. Le propriétaire du cas de 2025 laisse de son côté un récit séparé sur le forum Framework, avec son Raspberry Pi, ses fils soudés et les problèmes électriques rencontrés en route.13
Ajoutez la documentation de flashrom et vous obtenez presque un manuel de service officieux construit en public.5 La personne qui arrive demain avec le même portable mort ne repart pas de zéro : elle peut comparer les références du composant, voir où se trouve la flash sur les photos, comprendre le problème de tension, retrouver les commandes utilisées et lire ce qui a échoué avant elle.
Ça ne remplace évidemment pas une procédure constructeur. Un forum peut fermer, un site personnel peut disparaître et le succès d'un utilisateur ne garantit rien pour la machine suivante. Mais ces notes changent déjà le prix réel de la réparation, car elles enlèvent une partie de l'incertitude qui coûtait le plus cher au premier passage.
Le programmateur lui-même vaut peu de chose. Ce qui prend du temps, c'est de découvrir lequel est sûr, quelle image peut être écrite, pourquoi la consommation paraît bizarre ou si une mauvaise lecture vient de la puce, du contact pogo ou du reste de la carte alimenté par le rail de flash. Une photo, une mesure et quelques lignes bien notées transforment un débogage privé en expérience que quelqu'un d'autre peut vérifier.
La connaissance de réparation ressemble finalement à une pièce détachée : il faut encore pouvoir la trouver lorsque la machine devient assez vieille pour en avoir besoin. Si l'information utile reste enfermée dans un ticket support, elle n'existe pratiquement pas pour le propriétaire suivant.
Un produit réparable devrait exposer son échelle de secours
Vous pouvez lire les deux récupérations Framework comme une échelle de secours.
Tout en haut : les actions ordinaires accessibles à n'importe quel propriétaire. Attendre, redémarrer, réinitialiser, réessayer.
En dessous : les modes de secours pris en charge par le constructeur. Deuxième copie de firmware, partition de récupération, image USB, démarrage spécial.
Encore en dessous : les procédures de service. Connecteur de diagnostic, programmateur externe, points de test documentés.
Tout en bas : les méthodes invasives. Souder des fils, retirer des composants, tracer les bus, reconstruire l'organisation d'un firmware.
Un bon produit réparable n'a pas besoin de faire disparaître la dernière marche, il y aura toujours des pannes étranges. En revanche, si vous pouvez garder les pannes courantes beaucoup plus haut sur l'échelle, vous évitez de transformer chaque incident en séance d'électronique.
Dans le cas de Chen, la route qui réussit arrive très bas sur cette échelle alors même que la machine physique a été conçue pour être ouverte.1
C'est ce décalage qui mérite l'attention.
L'architecture modulaire dit : « vous pouvez entrer dans cette machine ».
Dans ces cas précis, la récupération firmware répond plutôt : « pas ici ».
Ce que Framework fait bien rend le manque plus visible
Il serait facile de transformer cet incident en preuve que la promesse de réparabilité de Framework est fausse. Ce serait aussi superficiel que de l'ignorer.
Si Chen peut réaliser cette intervention sans détruire la machine, c'est aussi parce que la carte est physiquement accessible. Et si l'incident est intéressant, c'est justement parce que Framework a relevé le niveau d'attente sur ce que signifie posséder et maintenir un portable.
Une machine totalement scellée dont la procédure officielle est toujours « changez la carte mère » ne fait que se comporter comme prévu.
Une machine modulaire autorise une meilleure question : pourquoi l'interface de récupération du firmware ne suit-elle pas la même philosophie que l'interface matérielle ?
La bonne réponse n'est évidemment pas d'offrir un CH347 avec chaque portable. Le meilleur résultat, c'est que vous puissiez récupérer la machine sans jamais apprendre le nom de ce composant.
Cela peut passer par une stratégie à deux banques, un environnement de récupération protégé, un connecteur documenté ou des images de secours exploitables en atelier. L'architecture exacte dépend de contraintes de sécurité, de coût et de place sur la carte.
Mais l'objectif produit est facile à formuler : une opération de maintenance ratée ne devrait pas rendre une carte mère physiquement saine économiquement équivalente à une carte morte.
La réparabilité inclut le code qui décide si la matière peut se réveiller
Nous aimons séparer des choses qui, dans les objets modernes, sont collées ensemble.
On aime bien ranger les choses : le hardware d'un côté, le logiciel de l'autre, la réparation avec les tournevis et la maintenance avec les fichiers à télécharger.
Un BIOS briqué mélange tout.
La carte est physiquement intacte, mais du logiciel l'empêche de redevenir un ordinateur. Ici, réparer revient à intervenir électriquement sur la carte pour changer le firmware. Une maintenance routinière crée le besoin d'un banc d'électronique.
C'est pour cela que cette histoire Framework a sa place à côté des vis, des languettes de batterie et des catalogues de pièces lorsque l'on parle de réparabilité.
Il faut alors poser une deuxième question : quelle route reste disponible lorsque le composant fonctionne mais que sa couche de démarrage ne répond plus ?
Il faut aussi savoir si l'objet offre une route de récupération à travers les couches qui permettent à ces composants de fonctionner ensemble.
Chen a finalement récupéré son portable en posant des pointes à ressort sur une minuscule flash et en la réécrivant depuis l'extérieur.1 La performance est impressionnante.
Elle devrait aussi paraître légèrement absurde.
Un ordinateur réparable peut être fier qu'un tel sauvetage soit possible.
Il devrait être encore plus fier lorsque personne n'est obligé de le faire.