coreboot 26.09 : le Framework Laptop 12 gagne un firmware ouvert… et les IA doivent désormais signer leurs copies

coreboot continue de grignoter le BIOS propriétaire

coreboot ne cherche pas vraiment à reproduire intégralement le BIOS ou l’UEFI fourni par le constructeur. Sa philosophie consiste plutôt à initialiser le strict nécessaire — processeur, mémoire, chipset, périphériques essentiels — puis à transmettre rapidement la main à un autre composant appelé payload. Celui-ci peut ensuite être SeaBIOS, GRUB, EDK2 ou même Linux. Le projet se définit comme une plateforme de firmware open source conçue pour être rapide, sécurisée et auditable , avec une quantité de code exécuté au démarrage volontairement réduite par rapport aux firmwares traditionnels.

La version coreboot 26.09 publiée le 1er octobre illustre bien cette philosophie. En trois mois, 112 auteurs ont fusionné 1 251 commits, dont 28 contributeurs envoyant leur premier patch. Cette fois, le projet insiste moins sur l’arrivée massive de nouveaux processeurs que sur le durcissement du code existant : validation de certaines fenêtres LPC dès la compilation, nettoyage du stockage EFI, audit de parseurs manipulant des formats externes, migration d’une grande partie du firmware et des outils hôte vers le standard C23 et refonte de plusieurs vieilles tables audio rendues enfin lisibles par un être humain normalement constitué.

Le genre de travail dont personne ne fera une vidéo YouTube avec des flammes autour du titre, mais qui devient nettement plus intéressant lorsqu’il s’agit du code exécuté avant même que votre système d’exploitation ait commencé à démarrer.

Le Framework Laptop 12 rejoint officiellement la liste

La nouveauté la plus visible pour le grand public est l’arrivée du Framework Laptop 12 équipé des processeurs Intel Core de 13e génération dans l’arbre principal de coreboot. Le support de cette carte mère fait partie des nouveaux modèles ajoutés dans 26.09, aux côtés d’un mélange assez savoureux comprenant des cartes ASUS Z87/Z97, un Lenovo ThinkPad X380 Yoga, un vieux Apple iMac4,1, un Intel NUC, le NVIDIA Jetson Nano et même plusieurs plateformes serveur.

L’ajout est particulièrement cohérent avec la philosophie Framework. Les ordinateurs de la marque sont conçus autour de la réparabilité, de composants interchangeables et d’une documentation matérielle nettement plus accessible que celle de la majorité des portables. Pouvoir désormais trouver le Laptop 12 directement dans l’upstream coreboot rapproche encore un peu plus la machine d’un écosystème où le firmware peut être étudié, recompilé et adapté au lieu de rester uniquement un fichier binaire mystérieux téléchargé depuis la page du constructeur.

Il faut néanmoins éviter le raccourci « Framework Laptop 12 fonctionne désormais officiellement sous coreboot en un clic ». Ajouter une carte à coreboot ne signifie pas que Framework remplace immédiatement son BIOS officiel par ce firmware. La page de support actuelle du Laptop 12 propose toujours le BIOS Framework traditionnel — la version 3.09 étant affichée comme stable au moment où nous écrivons ces lignes. coreboot lui-même rappelle qu’il distribue avant tout du code source, pas une image universelle prête à flasher, et recommande une certaine mentalité de développeur firmware avant de se lancer.

En langage moins diplomatique : si la perspective de brancher un programmateur SPI sur une puce parce que votre portable ne démarre plus provoque chez vous une légère transpiration, attendez les outils et images destinés aux utilisateurs finaux.

Un firmware ouvert ne signifie d’ailleurs pas forcément 100 % sans blob

Autre nuance importante : coreboot est open source, mais cela ne signifie pas automatiquement qu’un PC moderne équipé de coreboot fonctionne uniquement avec du code libre. Les processeurs et chipsets récents dépendent souvent de composants binaires provenant des fabricants de silicium, par exemple pour initialiser certaines parties extrêmement spécifiques de la plateforme.

La documentation de coreboot sur sa politique concernant les blobs est assez transparente sur ce sujet : l’objectif reste de proposer autant que possible une solution FOSS sur x86, ARM ou RISC-V, mais le projet accepte certains composants propriétaires lorsqu’aucune implémentation ouverte réaliste n’existe encore. L’alternative serait tout simplement d’abandonner le support d’une grande partie du matériel moderne.

Cela reste toutefois très différent d’un firmware entièrement opaque. La logique d’initialisation de la carte, une grande partie des pilotes et de nombreux mécanismes de sécurité peuvent être inspectés publiquement. Et surtout, une amélioration apportée à une plateforme peut remonter dans le projet commun au lieu de rester enfouie dans une branche propriétaire que personne ne reverra après le prochain modèle.

AMD EPYC Turin commence lui aussi à entrer dans la danse

coreboot 26.09 ne se contente pas des laptops. Le travail autour des processeurs serveur AMD EPYC Turin continue de progresser, avec notamment le premier port d’une véritable carte mère serveur : la GIGABYTE MZ33-AR1. Le support apporte la topologie PCIe et MCIO, différentes descriptions ACPI, la gestion de fonctions liées à CXL et divers travaux autour du firmware AMD et d’openSIL.

C’est un développement important parce que coreboot ne concerne pas uniquement les geeks qui flashent de vieux ThinkPad pendant le week-end. Le projet est déjà utilisé dans de nombreux Chromebooks et environnements serveurs, et son approche minimaliste devient particulièrement intéressante dans les datacenters, où quelques secondes ou minutes économisées sur le démarrage de centaines de machines commencent à représenter autre chose qu’un benchmark pour forum. Le site officiel de coreboot rappelle d’ailleurs son utilisation sur des millions d’appareils et dans des infrastructures de datacenter. coreboot.org

L’arrivée progressive des EPYC Turin montre aussi qu’un firmware ouvert n’est pas condamné à suivre les plateformes commerciales avec dix ans de retard. C’est probablement la condition indispensable pour que coreboot reste une alternative crédible plutôt qu’un musée très sympathique consacré aux chipsets Intel de 2012.

Et puis coreboot a dû écrire une règle spéciale pour les robots

La partie la plus délicieusement 2026 de cette version ne concerne pourtant aucun processeur. coreboot vient d’adopter une véritable politique pour les commentaires de revue de code générés par IA .

Les agents peuvent être utilisés pour analyser un patch et proposer des remarques, mais le projet impose plusieurs règles assez strictes. Chaque commentaire issu d’une IA doit commencer exactement par [AI-generated] . Un humain doit relire chaque remarque avant de la publier, vérifier qu’elle concerne bien le patch et s’assurer qu’il soutient réellement le commentaire envoyé en son nom. L’IA ne doit pas répondre directement aux commentaires humains et doit se limiter à soulever de nouveaux problèmes au niveau principal de la revue.

Et surtout : un agent IA n’a pas le droit d’attribuer une note de revue ni de déclencher une action Gerrit comme la fusion d’un patch. Un humain peut parfaitement valider le code au même moment, mais cette décision doit venir de lui et non être automatisée par le modèle.

On obtient donc une règle assez simple : ChatGPT, Claude ou le prochain SuperMegaCodeAgent 9000 peut regarder le firmware de votre PC et dire « je pense qu’il y a un problème ici ». Il ne peut pas ensuite répondre lui-même « excellent travail », appuyer sur Merge et partir déjeuner.

Ce qui semble raisonnable lorsqu’on parle du code chargé d’initialiser votre RAM avant même que Linux puisse venir réparer les dégâts.

AGENTS.md : le panneau « veuillez lire ceci » destiné aux machines

coreboot ne s’est pas contenté d’écrire ces règles dans une page destinée aux humains. La version 26.09 ajoute également un fichier AGENTS.md à la racine du projet afin que les coding agents puissent récupérer directement les instructions qui les concernent. Les règles de revue, le style de code attendu et différentes contraintes du projet peuvent ainsi faire partie du contexte fourni automatiquement aux outils de développement.

C’est un petit changement mais il raconte quelque chose de beaucoup plus large sur le développement logiciel actuel. Les dépôts possédaient déjà des fichiers README, CONTRIBUTING, des linters et des règles pour les humains. Ils commencent maintenant à accumuler des instructions spécifiquement conçues pour les agents qui lisent, modifient et analysent le code.

On arrive donc progressivement à des projets contenant une documentation pour les développeurs, une autre pour les utilisateurs et un petit panneau pour les robots disant : « merci de ne pas fusionner le BIOS tout seul ».

Le futur est formidable.

L’IA n’est pas bannie, elle doit simplement assumer ce qu’elle écrit

La position de coreboot est intéressante parce qu’elle évite les deux extrêmes. Le projet ne décrète pas que tout code ou toute analyse provenant d’un LLM est forcément inutile. Mais il ne considère pas non plus qu’un commentaire généré automatiquement possède la même valeur qu’une revue humaine simplement parce qu’il est formulé avec beaucoup d’assurance et trois paragraphes sur les risques de débordement d’entier.

L’obligation d’étiqueter les commentaires IA offre déjà une information essentielle au mainteneur : il sait immédiatement de quel type de contenu il s’agit. La relecture humaine obligatoire déplace ensuite la responsabilité vers la personne qui décide réellement de publier la remarque.

Cette approche devient particulièrement pertinente après plusieurs mois durant lesquels des projets open source ont dû gérer une explosion de rapports, patches et commentaires produits automatiquement. Le problème n’est pas que l’IA soit incapable de trouver un vrai bug. Elle peut parfaitement en trouver. Le problème est qu’elle peut aussi produire vingt remarques plausibles pour chaque problème utile, et laisser les mainteneurs effectuer gratuitement le tri.

coreboot répond donc avec une règle assez saine : utilisez votre robot si vous voulez, mais vous restez responsable de ce qu’il raconte.

coreboot 26.09 modernise aussi un projet qui approche tranquillement des trois décennies

Au-delà de Framework et de l’IA, cette version continue un travail de fond assez massif. Le passage à C23 modernise le langage utilisé pour construire le firmware, l’infrastructure EFI gagne le support des capsules stockées sur disque, la pile audio abandonne plusieurs tables cryptiques au profit de descriptions structurées, le support des menus de configuration CFR continue d’évoluer et plusieurs validations sont désormais effectuées au moment de la compilation plutôt que de laisser une mauvaise valeur atteindre la machine.

La liste des nouvelles cartes est également assez amusante parce qu’elle mélange du matériel extrêmement récent et des machines franchement anciennes : Framework Laptop 12, AMD EPYC Turin, Jetson Nano, Apple iMac4,1, ThinkPad X380 Yoga, cartes ASUS Maximus VI et VII, ASRock Z97, Intel NUC Ivy Bridge… Le firmware open source possède manifestement une notion assez flexible du mot « génération ».

Et c’est précisément l’une de ses forces. Lorsqu’un constructeur arrête de maintenir un BIOS, le code propriétaire devient généralement une impasse. Lorsqu’une plateforme entre dans coreboot, une communauté peut théoriquement continuer à la corriger ou à l’adapter aussi longtemps que quelqu’un dispose encore de la machine et de suffisamment de patience.

N’installez quand même pas ça dimanche soir avant une réunion lundi

L’arrivée d’une carte dans coreboot donne toujours envie aux amateurs de bidouille de chercher immédiatement comment flasher le firmware. C’est précisément le moment où il faut rappeler qu’un BIOS cassé possède une particularité légèrement agaçante : contrairement à une distribution Linux ratée, il peut vous empêcher d’atteindre la clé USB censée réparer le problème.

La documentation de coreboot sur le flash du firmware décrit aussi bien les méthodes internes que les procédures externes avec programmateur. Et lorsque tout va vraiment mal, la documentation va jusqu’à expliquer comment intervenir directement sur la puce SPI, voire la dessouder.

Ce n’est donc pas encore le genre de projet où l’on télécharge coreboot-installer.exe, clique trois fois sur « Suivant » puis redémarre joyeusement.

Sur le Framework Laptop 12, l’intérêt immédiat réside surtout dans le fait que le support existe désormais upstream. Des distributions de firmware, fabricants ou utilisateurs expérimentés peuvent partir de cette base sans maintenir éternellement un fork isolé. Pour les propriétaires moins aventureux, la meilleure fonctionnalité reste probablement de pouvoir observer le projet progresser tout en laissant le BIOS officiel tranquillement installé.

Le firmware devient enfin un peu moins invisible

Le BIOS est l’un des derniers endroits du PC grand public où l’opacité reste largement considérée comme normale. On peut choisir son système d’exploitation, compiler son noyau, remplacer son navigateur ou installer un gestionnaire de fenêtres dont le fichier de configuration fait 4 000 lignes, mais la première couche de logiciel exécutée par la machine reste souvent un énorme bloc fourni par le constructeur.

coreboot ne résout pas magiquement ce problème. Les blobs existent encore, le support matériel reste difficile et flasher soi-même un firmware demeure une opération nettement moins accueillante qu’une mise à jour Flatpak. Mais chaque nouvelle plateforme supportée réduit un peu plus la quantité de matériel pour lequel « le BIOS est fermé parce que c’est comme ça » constitue l’unique réponse possible.

Avec la version 26.09, le Framework Laptop 12 rejoint ce mouvement, les serveurs EPYC Turin avancent et même les agents IA trouvent désormais une petite place dans la procédure de développement — à condition de porter leur badge [AI-generated] et de ne toucher à aucun bouton important.

Finalement, l’open source vient peut-être de résoudre un problème que beaucoup d’entreprises découvriront bientôt elles aussi : si vous laissez une IA participer à une réunion, commencez par lui expliquer qu’elle n’est pas la personne qui signe le contrat.