Un hadron est une particule composite, composée de particules subatomiques régies par l'interaction forte, nous dit Wikipédia. Si cela vous fait penser à Proton, ce n’est peut-être pas parce qu’un proton est un hadron, mais parce que Hadron, comme Proton, promet de faire tourner vos jeux (et plus) n’importe où, même sur des systèmes terreux.

Vous connaissez peut-être Proton, l’assemblage de Wine et d’autres composants libres que Valve emploie pour faire tourner des jeux Windows sous Linux pour sa plate-forme Steam. Hadron propose la même chose pour macOS.

Des jeux Windows ? Sous macOS ? Quel est le 🌀️💀️⚡️⁉️ de rapport avec LinuxFr.org et son objectif de promotion des logiciels libres ? C’est parce que Hadron est construit de briques libres du sol au plafond : Wine, FEX, Mesa, vkd3d…

Sommaire

• Pourquoi Hadron ?
• L’architecture de Hadron
  • FEX, le traducteur automatique d’instruction processeur
  • Wine, l’implémentation libre des API Windows
  • Mesa, Zink et KosmicKrisp
  • vkd3d-proton, DirectX 12 sur KosmicKrisp
  • mtld3d et DXMT, les plus anciens Direct3D sur Metal
• Win32 + Vulkan + AMD64, la plate-forme universelle ?

Le logiciel libre 7zFM pour Windows x86-64 s‘exécutant sur un Mac mini M1 sous macOS 27 sans utiliser Rosetta 2.

Le développement de Hadron est encore très jeune, confidentiel, mais très rapide et réactif. Votre serviteur a testé de faire tourner le jeu libre Unvanquished et a rencontré deux bugs (1, 2) qui ont tous deux été corrigés dans les deux jours (1, 2), et une nouvelle version incorporant les correctifs a été publiée sous cinq jours (1).

Les spéculations sur « qui est derrière Hadron » pourraient se tourner naturellement vers Valve, qui est le premier bénéficiaire économique d’un tel système, mais le README du projet Hadron est explicite : « It is unofficial. Hadron is not affiliated with or endorsed by Valve, Apple, CodeWeavers or any of the projects it builds on », « C’est un projet non officiel. Hadron n’est ni affilié à, ni approuvé par Valve, Apple, CodeWeavers ou l’un des projets sur lesquels il s’appuie ».

Il semble donc que Hadron soit simplement l’initiative de son auteur David Andrews (Broyojo), ni plus ni moins.

Au delà de la proximité de nom entre Hadron et Proton, Hadron reste délibérément focalisé sur Steam : la fenêtre qui s’affiche quand vous lancez Hadron ne sert qu’à intégrer Hadron à Steam, et les premières versions ne proposaient d’ailleurs pas d’option pour lancer un programme non-Steam (fonctionnalité ajoutée très rapidement en quelques jours aussi). Le but premier de Hadron est Steam, et quand vous rapportez un bug pour un jeu, il vous est demandé l’identifiant Steam de ce jeu (cet identifiant est heureusement optionnel).

Pourquoi Hadron ?

En 2027, Apple sortira macOS 28 et à cette occasion, a prévu de drastiquement réduire l’étendue de la compatibilité Rosetta 2. Rosetta 2 est le système de traduction automatique qui permet de faire tourner des binaires amd64 (x86-64) sur arm64 (Apple Silicon ici, dans les macs « M »). Rosetta 2 a un 2 parce que Rosetta premier du nom s’occupait de traduire les binaires PowerPC vers Intel il y a très longtemps. Par commodité nous dirons simplement Rosetta au lieu de Rosetta 2 dans la suite de l’article.

Apple a annoncé que Rosetta ne sera plus disponible pour les applications, mais qu’ils conserveront une petite sous-partie prévue uniquement pour faire tourner des vieux jeux non maintenus s'appuyant sur des bibliothèques pour Intel (« we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks » (source). C’est une affirmation super floue. Que restera-t-il de Rosetta ? Sur quoi pourra-t-on compter et ne pas compter ?

Pour Apple, décommissionner Rosetta a un intérêt : ne plus fournir toutes les bibliothèques systèmes en double, ne plus avoir à apporter de la maintenance et du code système pour l’architecture amd64, etc. Tout l’effort de migration vers arm64 est entièrement externalisé vers le développeur indépendant. Ça coûte très cher à l’échelle globale, mais rien du tout pour Apple, et leur clientèle est suffisamment captive pour que le développeur au milieu y soit contraint. Si un développeur échoue à porter son logiciel, le développeur perdra des ventes, mais pas nécessairement Apple. Ce n’est pas le problème d’Apple, surtout quand l’acquisition du logiciel a lieu probablement en dehors de leur marché. Ceci est d’autant plus vrai en dehors du jeu : un logiciel de production concurrent remplace facilement un autre s’il venait à disparaître.

Pour un consommateur de jeu, c’est insupportable : il ne veut pas perdre son jeu parce que le développeur ne le développe plus. Il y a un attachement affectif, le joueur y a investi une partie de sa vie, il peut être attaché à l’histoire, etc. Et si le jeu est encore développé, le joueur ne trouve pas d’intérêt à ce que le développeur se retrouve avec plus de travail qui ne lui apportera aucun changement en jeu. Rajouter gratuitement du travail au développeur de jeu n’apporte rien au joueur.

Et pour une plate-forme tierce de vente et de location de logiciels comme Steam et autre GOG GALAXY, c’est une catastrophe : si un développeur échoue à porter son logiciel, ou n’est plus disponible pour cette tâche, ce sont des ventes en moins pour le développeur et pour le vendeur. Un vendeur de jeux qui prend sa commission à chaque vente (et dont ce serait la première sinon la seule activité économique) a intérêt à ce que le moindre effort soit proposé aux développeurs de jeux.

L’architecture de Hadron

Ne pas confondre avec le Grand collisionneur de hadrons ! L’architecture de Hadron est très différente, mais fait aussi se rencontrer plein de particules élémentaires libres pour observer des effets très intéressants.

Diagramme de l’architecture de Hadron, telle que décrite dans la documentation du projet.

FEX, le traducteur automatique d’instruction processeur

Comme alternative à Rosetta pour traduire les instructions amd64 vers arm64 pour exécuter des logiciels, il existe au moins deux logiciels libres : FEX (dont le développement était initialement secrètement soutenu par Valve), et Box64 développé par notre ptitSeb national.

Ces deux logiciels libres ont été à la base développés pour s’exécuter sous Linux. Hadron a choisi FEX et le fait tourner sous macOS. Ainsi, plus besoin de compter sur Rosetta et d’être dépendant du bon-vouloir d’Apple !

Le choix de FEX correspond bien à l’écosystème de Valve : l’intégration de FEX peut prendre exemple sur celle déjà réalisée pour Steam sur le Steam Frame (un produit de réalité virtuelle tournant sous Linux et sur ARM), et permet d’hériter des tests déjà réalisés par Valve pour le Steam Frame.

En intégrant FEX, Hadron rend les jeux et autres logiciels indépendants de la volonté d’Apple d’abandonner la prise en charge de l’architecture x86.

Wine, l’implémentation libre des API Windows

On ne présente plus Wine, le logiciel libre qui permet de faire tourner depuis des décennies des programmes Windows sous Linux, BSD et macOS. En 2022 Arek Hiler avait prononcé la désormais célèbre phrase Win32 Is The Only Stable ABI on Linux, Win32 est la seule interface binaire de programmation qui soit stable sous Linux. Ce constat de l’ABI Win32 comme une interface très stable s’étend en fait bien au-delà des utilisateurs de Linux.

Wine est une brique fondamentale de Proton, la sous-couche de Valve pour faire tourner des jeux Windows sous Linux. Hadron fait de même pour macOS.

Hadron intègre donc FEX et Wine pour faire tourner des programmes Windows compilés pour x86 (32-bit et 64-bit) sur les macs exécutant macOS sur des processeurs ARM. L’héritage Wintel ne s’effacera donc jamais.

En intégrant Wine, Hadron rend les jeux et autres logiciels indépendants des interfaces de programmation de macOS.

Mesa, Zink et KosmicKrisp

Mesa est la collection de pilotes graphiques libres qui domine nos écosystèmes Linux et BSD. Mais Mesa propose aussi des pilotes pour d’autres plate-formes, comme Windows et macOS.

L’article Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ? posait ce constat en répondant à la question « Et pour Vulkan sur macOS ? » :

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation libre traduisant Vulkan pour l’API propriétaire Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et vous le voyez venir en mille, Hadron intègre KosmicKrisp pour fournir la prise en charge de l’API graphique Vulkan. KosmicKrisp traduit les appels Vulkan vers l’Interface de programmation (API) propriétaire Metal.

En intégrant KosmicKrisp, Hadron rend les jeux et autres logiciels indépendants de la politique d’Apple refusant de prendre en charge le standard industriel Vulkan.

Mais, et pour OpenGL ? Zink est un pilote Mesa qui implémente OpenGL au dessus de Vulkan, quel que soit le système (Zink tourne déjà sous Linux et Windows, et donc aussi macOS comme on peut le voir). Voilà, problème résolu.

En fait macOS fournit déjà OpenGL, mais ils l’ont déclaré obsolète depuis longtemps et ne fournissent qu’une ancienne version 4.1 qui date de 2010 (16 ans déjà !) qui est 7 ans plus ancienne que la dernière version d’OpenGL (4.6).

Zink implémente donc OpenGL 4.6 et en intégrant Zink, Hadron rend les jeux et autres logiciels indépendant de la volonté d’Apple d’abandonner OpenGL.

Et au passage, Zink propose la dernière version d’OpenGL et est un pilote désormais bien connu des développeurs de jeu, c’est tout bénef !

Hadron a comme politique de favoriser Zink à la place de l’implémentation OpenGL maison d’Apple. Quand un des bugs donnés comme exemple et affectant Unvanquished a été rapporté, l’expérimentation avait été réalisée avant que Hadron ne propose un moyen simple de lancer un logiciel en dehors de Steam, et donc l’expérimentation avait été faite en appelant Wine directement sans passer par le lanceur de Hadron. Le développeur Broyojo a constaté en lisant le journal du moteur de jeu Dæmon que dans ces circonstances, le jeu utilisait l’implémentation OpenGL d’Apple, chose qu’il s’est empressé de corriger fissa. Et pour le coup, ce changement est ce qui a corrigé le bug, trop facile.

L’article sur RADV et Windows indiquait :

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que — si nécessaire — le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Nous y sommes. À part que cette fois-ci, ce n’est pas Valve qui en aurait eu l’initiative.

vkd3d-proton, DirectX 12 sur KosmicKrisp

Là où Zink implémente OpenGL sur Vulkan, vkd3d-proton fait de même et implémente DirectX 12 sur Vulkan, lui-même implémenté par KosmicKrisp.

DirectX 12 est l’interface de programmation graphique propriétaire de Microsoft pour Windows, elle est similaire à Metal et Vulkan.

Un développeur de jeu libre n’en a pas besoin : il peut utiliser OpenGL ou Vulkan, mais de très nombreux jeux utilisent Direct X 12, et Hadron s’assure donc de fournir cette prise en charge.

Comme son nom l’indique, vkd3d-proton est une brique essentielle de Proton, et l’est aussi maintenant pour Hadron.

mtld3d et DXMT, les plus anciens Direct3D sur Metal

Vous connaissez peut-être le logiciel DXVK qui implémentent Direct3D 8, 9, 10 et 11 au dessus de Vulkan. Vous aviez peut-être entendu parlé de D9VK qui faisait de même pour D3D9 mais qui est désormais intégré à DXVK, ou WineD3D qui implémentait Direct3D 8, 9, 10 et 11 au dessus de OpenGL.

Proton utilise DXVK sous Linux, implémentant donc D3D sur Vulkan, et Hadron pourrait faire de même, à la façon dont c’est effectivement implémenté avec vkd3d-proton.

Mais il existe deux logiciels qui implémentent D3D sur l’API Metal directement, ce qui permet de supprimer une couche intermédiaire de traduction.

Ces deux logiciels libres sont mtld3d qui implémente D3D9 sur Metal, et dxmt qui implémente D3D10 et D3D11 sur Metal.

Pour D3D8, Hadron ne précise pas si quelque chose est prévu, mais il devrait être possible d’utiliser DXVK, ou encore d3d8to9 qui implémente D3D8 sur D3D9. Et on peut supposer que rien ne devrait techniquement empêcher d’utiliser dd7to9 et autres projets de ce type (voir dxwrapper pour plus de détails).

Win32 + Vulkan + AMD64, la plate-forme universelle ?

Pour un développeur de logiciel libre, ces APIs DirectX sont peu utiles, mais tout le reste de cet écosystème peut profiter aux développeurs de logiciels libres.

Les compilateurs libres du projet MinGW permettent de compiler pour Win32. Wine permet de faire tourner ces programmes Win32 ailleurs que sur Windows. Et en s’appuyant sur les API graphiques OpenGL ou Vulkan, et des bibliothèques comme OpenAL ou SDL pour le son, le fenêtrage et les entrées, un développeur de jeu libre peut donc produire un seul binaire entièrement libre de la tête aux pieds qui tourne partout, sous Linux, BSD, macOS ou Windows.

Alors bien évidemment, certains préféreront un programme natif à leur système, avec de bonnes raisons. Mais quand un lanceur comme Steam ou une alternative libre comme Lutris fait toute l’intégration pour vous, tout ce qui retient se réduit à un attachement affectif (et ça compte beaucoup). C’est un chagrin légitime mais il n’empêche pas de jouer.

Wine fait déjà tourner naturellement les programmes x86 sur Linux et autres BSD. FEX peut être associé à Wine pour faire tourner des programmes Windows x86 sous Linux et macOS sur les processeurs ARM. Et Box64 sait faire de même sous Linux, non-seulement sur ARM64, mais aussi sur PowerPC (en mode petit-boutiste), RISC-V et Loongson.

Certains ont pu déclarer que « AMD64 is the new Java », en réalité, c’est peut-être la triforce Win32 + Vulkan + AMD64 qui est ce nouveau Java. Vous ferez peut-être autant la grimace, mais ça ne marche pas moins.

Et avec Hadron, votre prochain environnement de développement pour macOS pourrait simplement être MinGW, trop bien !

Avec Hadron, le futur de macOS court-circuite tout macOS, et Apple ne peut rien y faire.

J’ai fait récemment deux découvertes étonnantes sur le réseau social du groupe bancaire dans lequel je travaille.

1. Il existe un groupe de veille sur l’open source et les alternatives aux Gafam ;
2. Ce groupe a récemment mis en ligne une conférence de découverte des distributions alternatives pour ordiphone, des ordiphones « différents », et enfin d’une autre manière de se procurer un ordiphone (entre autres).

Cette manière différente est de le louer à la SCIC Commown.

J’avoue que me serais plus attendu à faire cette découverte sur Linuxfr qu’au boulot… Quelques détails complémentaires dans la dépêche !

Comment ça marche ?

C’est très simple : le site de Commown propose divers matériels dégafamisés (ordiphones, pc portables ou fixes, casques audio) à louer selon différentes modalités.

Une fois le dépôt de garantie réglé, l’ordiphone vous est envoyé, à vous de régler les mensualités. Commown s’occupe de toute panne logiciel ou matérielle, en renvoyant un autre appareil au besoin.

Pourquoi ça donne envie ?

• Parce que l’offre est bien travaillée, avec notamment une dégressivité marquée de 6 % des mensualités chaque année, avec un plancher à 60 % de la mensualité d’origine, et un matériel dégafamisé.

• Parce que la démarche est vraiment très poussée et ne ressemble pas à un greenwashing quelconque. J’aime beaucoup par exemple l’incitation à ne pas forcément devenir client de suite tant qu’un changement d’appareil n'est pas nécessaire, mais
  à souscrire à un « bon de consom’action » donnant droit à une réduction dans le futur tout en asseyant la solidité financière de la coopérative.

Prêt à sauter le pas ?

Je réfléchirai sérieusement à souscrire à une de leur offre quand je serai venu à bout de mon Fairphone 3+ sous /e/OS, à moins que je ne souscrive un bon.

Et vous, que pensez-vous de ce type d’offre ?

Les 14 et 15 novembre prochain aura lieu le Capitole du Libre, la grande conférence autour du libre à Toulouse, qui existe depuis 2011.

Dans cet épisode, avec Lionel Porcheron et Guillaume Gasnier, nous retraçons l'histoire du Capitole du Libre, de ses débuts en tant qu'Ubuntu Party jusqu'à l'organisation telle que nous la connaissons de nos jours.

Nous parlons :

• de l'association Toulibre
• de sa pérennité et son financement
• de ses inspirations
• de ses transformations successives : d'un évènement local à une conférence nationale
• des impacts d'évènements extérieurs tels que le COVID et des attentats de 2015
• de ce que l'on peut attendre pour l'édition 2026 !

Venez nous rejoindre au Capitole du Libre dans quelques semaines, l'équipe de Projets Libres y sera !

Comme d'habitude, une transcription complète est disponible (merci Guillaume Gasnier pour son travail de relecture et amélioration).

PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.

Pourquoi une borne de décontamination

Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.

PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.

Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.

Sommaire

• • Une version entièrement réécrite.
  • Plusieurs moteurs de détection
  • Une image système durcie
  • Mises à jour signées et maintenance sans session
• Matériel et interface
  • État du projet
  • Essayer et contribuer

Une version entièrement réécrite.

La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.

Les principaux changements :

• les appels à pypandora sont remplacés par une chaîne de moteurs de détection intégrée ;
• le moteur Comodo, qui n'est plus maintenu sous Linux, disparaît ;
• le diaporama d'images (fim) laisse la place à une vraie interface graphique tactile ;
• les clés sont montées en lecture seule par la borne elle-même, avec des options de montage durcies ;
• les journaux passent au JSON structuré ;
• la borne n'est plus un logiciel à installer sur un système existant, mais une image système complète.

Plusieurs moteurs de détection

Chaque fichier passe par plusieurs moteurs complémentaires :

• MalwareBazaar propose des empreintes SHA-256 de logiciels malveillants connus.
• Le service CIRCL Hashlookup aide à repérer les fichiers connus grâce à un filtre de Bloom.
• ClamAV : antivirus, y compris dans les archives
• YARA-X : YARA Forge
• Heuristiques : programmes déguisés en documents (double extension, type réel différent de l'extension), PDF avec JavaScript ou actions de lancement

La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».

Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.

Une image système durcie

La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :

• chaîne de démarrage vérifiée : Secure Boot avec la clé de l'image enrôlée à la place de celles de Microsoft, image noyau unifiée (UKI) signée, système de fichiers racine EROFS en lecture seule protégé par dm-verity, noyau en mode lockdown ;
• périphériques USB filtrés : USBGuard n'autorise que le stockage de masse, ce qui bloque les clés qui se font passer pour un clavier (BadUSB), et les pilotes réseau USB, Wi-Fi et Bluetooth sont retirés de l'image ;
• aucune session : pas de compte, pas de programme login, pas de menu de démarrage ;
• un bac à sable par moteur : chaque moteur tourne dans son propre processus, avec bubblewrap, un utilisateur dédié sans privilèges, un filtre seccomp et aucun accès réseau. Un moteur compromis par un fichier piégé ne peut pas falsifier le résultat d'un autre ;
• pare-feu et réglages du noyau inspirés des recommandations de l'ANSSI pour les systèmes GNU/Linux. Lynis donne un indice de durcissement de 73, sans avertissement.

L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.

Mises à jour signées et maintenance sans session

La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :

• Les signatures : le logiciel vérifie un jeu de signatures signé Ed25519 à chaque démarrage. Il s'installe depuis une clé USB de mise à jour, qui n'est jamais analysée, ou en ligne avec le profil online de l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ;
• Le système accepte les mises à jour A/B avec systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ;
• journaux : une clé de maintenance signée récupère les journaux de la borne (journal systemd, noyau, USBGuard, matériel) sans ouvrir de session et sans rien modifier.

Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.

Matériel et interface

La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.

L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).

L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.

État du projet

Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.

Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.

Les prochaines étapes de la feuille de route :

• analyse des macros Office avec oletools et des exécutables avec capa ;
• désarmement et reconstruction de contenu (CDR) avec Dangerzone ;
• serveur central facultatif : inventaire des bornes, rapports, état des signatures ;
• modèle de menace documenté, fuzzing des points d'entrée et audit de sécurité externe ;
• correspondance avec les exigences NIS2 et ISO 27001 (mesure 7.10 « Supports de stockage »).

Essayer et contribuer

Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :

git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh                            # construit l'image
image/build-test.sh && image/vm.sh test   # la teste dans une machine virtuelle

Les contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.

(NdM : Tempo est une offre commerciale d'EDF, cette dépêche traite des API et flux de données ouverts permettant de connaître et prédire les coûts du kWh.)

En avril 2025, une dépêche faisait le point sur les sources accessibles sans jeton pour connaître la couleur Tempo du jour, après la fermeture des anciennes URL d'EDF. La saison des jours rouges reprend le 1er novembre : voici une mise à jour, avec une nouveauté, des prévisions au delà de demain en JSON et en données ouvertes. Transparence d'abord : je fais partie de l'équipe de Calendrier Tempo EDF, l'une des sources présentées plus bas.

Rappel du contexte

L'option Tempo d'EDF compte 300 jours bleus, 43 blancs et 22 rouges par saison. Les jours rouges tombent entre le 1er novembre et le 31 mars, jamais un samedi ni un dimanche, et le kWh y coûte nettement plus cher. La couleur du lendemain est fixée par RTE et annoncée la veille. Pour piloter un chauffage ou une machine à laver depuis une box domotique, il faut donc une source lisible par une machine.

La couleur officielle (aujourd'hui et demain)

• RTE : la source officielle. Son API passe par un compte et un jeton sur le portail data de RTE. Les couleurs passées sont aussi publiées en données ouvertes : Tempo Like Supply Contract sur data.gouv.fr.
• api-couleur-tempo.fr : déjà citée en 2025, toujours là. JSON simple, sans clé, très utilisé dans les forums domotiques.
• Calendrier Tempo EDF : relaie la couleur officielle (via api-couleur-tempo.fr) sur /api/today et /api/tomorrow, qui renvoie "status": "unavailable" tant que la couleur de demain n'est pas publiée. Si vous lisez déjà RTE directement, gardez cette source : c'est l'originale.

Exemple :

curl https://www.calendrier-tempo.fr/api/today
{"status": "ok", "date": "2026-10-09", "couleur": "BLEU", "code": 1}

Les prévisions (après demain)

C'est ce qui a changé depuis 2025 : on trouve maintenant des prévisions en JSON, sans compte.

• Open DPE publie un fichier de prévisions jour par jour, avec une probabilité : https://open-dpe.fr/assets/tempo_days_lite.json
• Calendrier Tempo EDF publie /api/predictions : une prévision par jour jusqu'à J+15, avec la probabilité de chaque couleur et la température moyenne prévue, recalculée chaque soir à partir des prévisions de consommation de RTE, de la météo (Open‑Meteo) et des règles officielles de Tempo. /api/remaining donne les jours restants par couleur dans la saison.

Une prévision reste une prévision, et seule la couleur publiée fait foi. Plus l'échéance est lointaine, plus c'est une tendance qu'une certitude.

Vérifier avant de faire confiance

Plusieurs fils de forums domotiques l'ont montré l'hiver dernier : des prévisions affichées sans historique, on ne sait jamais ce qu'elles valent. Chez Calendrier Tempo EDF, chaque prévision est figée au moment où elle est émise, de J‑15 à la veille, puis comparée à la couleur réelle. L'historique complet, erreurs comprises, est consultable en ligne et téléchargeable en CSV sous licence CC BY 4.0 :

• Historique des prévisions sur data.gouv.fr
• CSV mis à jour chaque jour : https://www.calendrier-tempo.fr/historique-previsions.csv

De quoi mesurer soi‑même la fiabilité par échéance, et comparer les sources cet hiver.

Côté domotique

L'API ne demande ni compte ni clé, et les réponses sont en cache deux minutes : une requête toutes les trente minutes suffit largement. Des configurations prêtes à copier pour Home Assistant (intégration installable via HACS, sous licence MIT), Jeedom et Domoticz sont réunies sur une page : intégrations domotique. Documentation de l'API : https://www.calendrier-tempo.fr/api-tempo

Pour finir

Comme en 2025 : si vous connaissez d'autres sources sans jeton, ou si vous suivez la fiabilité des prévisions de votre côté, les commentaires sont là pour ça.