4 points par GN⁺ 2026-01-15 | 1 commentaires | Partager sur WhatsApp
  • Lorsque un produit matériel arrive en fin de vie (EOL), les entreprises devraient être tenues de publier le logiciel en open source
  • Le mouvement Right to Repair a progressé, mais il est proposé qu’au niveau de l’Union européenne, la publication du logiciel au moment de l’EOL soit imposée par la loi
  • Sont cités en exemple le cas d’une balance connectée qui a perdu ses fonctions après l’arrêt du support de l’application, ainsi que celui du Car Thing de Spotify, devenu un déchet électronique après son abandon
  • Les entreprises n’ont pas besoin de publier l’ensemble de leur base de code ; elles devraient seulement rendre publics les spécifications matérielles et les protocoles de connexion afin que la communauté puisse développer ses propres applications
  • Pour la durabilité et les droits des utilisateurs, une approche open source permettant de redonner vie à du matériel abandonné est indispensable

Fin de vie du matériel et nécessité de l’open source

  • Lorsqu’un produit matériel atteint l’état EOL (End of Life), les entreprises devraient publier leur logiciel en open source

    • Le texte pointe le problème de produits abandonnés qui restent physiquement fonctionnels, mais deviennent inutiles en raison de l’arrêt du support logiciel
    • Il soutient qu’une contrainte légale est nécessaire pour éviter ce type de situation
  • Le mouvement Right to Repair a déjà renforcé les droits des consommateurs, mais la proposition va plus loin : l’Union européenne (UE) devrait rendre obligatoire la publication du logiciel au moment de l’EOL

    • La Commission européenne (European Commission) devrait, selon cette position, imposer aux entreprises de publier le logiciel lorsqu’un produit est abandonné

Expérience personnelle et cas problématiques

  • Dans le cas d’une balance connectée, le matériel fonctionne normalement, mais l’application ayant été arrêtée, la fonction d’enregistrement des données a disparu

    • La connexion Bluetooth reste possible, mais comme l’application n’est plus développée, le produit est devenu de fait inutilisable
    • Le texte exprime sa frustration face au gaspillage provoqué par un matériel parfaitement fonctionnel « mort » à cause de l’arrêt du support par l’entreprise
  • Le cas de l’abandon du Car Thing de Spotify est également mentionné

    • Avec l’arrêt du service fin 2024, un matériel à 200 dollars est devenu du jour au lendemain un déchet électronique
    • Le fait que Bose ait publié en open source ses enceintes SoundTouch avant leur EOL est évalué positivement, mais cela reste une exception rare

Une alternative réaliste

  • Les entreprises n’ont pas besoin de publier l’intégralité de leur base de code

    • Il suffirait plutôt de publier sur un dépôt GitHub les spécifications matérielles et les protocoles de connexion
    • La communauté pourrait alors développer ses propres applications sur cette base
  • Avec de nouvelles approches de développement comme le vibe-coding, même les non-spécialistes peuvent participer facilement

    • Nous sommes entrés dans une époque où les utilisateurs ordinaires peuvent eux aussi manipuler et améliorer directement leur matériel

Durabilité et droits des utilisateurs

  • Une approche open source capable de redonner vie à du matériel abandonné est nécessaire sur les plans environnemental et éthique
    • Elle permet de réduire la production inutile de déchets électroniques et de préserver un écosystème technologique durable
    • Si un matériel est déjà devenu une « brique », le mieux est encore de publier le logiciel afin de donner à la communauté une chance de le réutiliser

1 commentaires

 
GN⁺ 2026-01-15
Avis de Hacker News
  • Le moyen le plus sûr de faire passer un projet EOL (End-of-Life) en open source est de commencer en open source dès le départ
    Les promesses du type « on publiera une fois l’objectif atteint » ou « on le publiera si l’entreprise fait faillite » ne valent rien
    Il faut partir en open source pour que les investisseurs et la communauté puissent faire confiance au projet
    Il faut dépenser son argent auprès d’entreprises qui fabriquent des produits open source et du matériel, et soutenir les artistes qui diffusent librement leurs œuvres
    Critiquer les entreprises qui ne publient pas après l’EOL n’est au fond qu’un geste de façade

    • Il faut aussi prendre en compte le fait que le matériel grand public n’est pas simplement un marché de niche pour passionnés
    • Si les consommateurs se coordonnent pour voter avec leur portefeuille, ils peuvent changer le marché
      Même les grandes entreprises ont du mal à résister à une demande unifiée des consommateurs
      Comme la FSF a contribué à généraliser le logiciel libre, il faut de l’éducation des consommateurs et un changement culturel
      Il faut créer une culture de communautés de consommateurs où les avis d’experts circulent rapidement
      Mieux vaut produire un changement réel qu’adopter une attitude cynique
    • Mais dans la réalité, le marché récompense les modèles à code source fermé
      La seule pression des consommateurs ne suffira pas, il faut de la régulation
  • La plupart des systèmes reposent sur une chaîne de signature de code et fonctionnent en mode fail closed
    Mais quand l’entité signataire d’origine disparaît, il faut une architecture fail open permettant de déléguer le droit de signature à une nouvelle entité

  • La simple proposition de publier les spécifications matérielles et les protocoles est peu réaliste
    La plupart des appareils ne se réduisent pas à un simple protocole de connexion, et l’analyse du PCB permet souvent déjà de retrouver les spécifications

    • L’essentiel est de fournir le minimum d’informations nécessaire à la réutilisation
      Publier la méthode de flash du firmware et un firmware minimal peut déjà suffire
      Mais comme chaque produit est différent, il faut une approche au cas par cas
  • Pour les appareils comme les routeurs, où le secure boot est gravé dans un e-fuse, une simple publication en open source ne résout pas le problème
    Dans ce cas, le fabricant devrait conserver les clés de signature sous forme d’escrow afin de permettre l’exécution de nouveaux logiciels même après l’EOL

    • Mais rendre publiques les clés de signature pourrait être une catastrophe de sécurité
      Un attaquant qui récupère un domaine expiré pourrait par exemple monter un botnet
      Il faudrait plutôt une procédure, comme une manipulation d’un bouton physique, par laquelle l’utilisateur approuve explicitement l’installation d’un firmware tiers
    • Cela montre que l’approche consistant à « ne publier que le protocole » ne suffit pas pour tous les appareils
    • Certains estiment qu’il faudrait tout simplement interdire le verrouillage du bootloader
      L’utilisateur devrait avoir le droit de modifier son propre appareil sans l’autorisation du fabricant
    • On pourrait aussi autoriser l’enregistrement de clés via un bouton physique
  • Moi aussi, je trouve frustrant de devoir jeter du matériel encore utilisable à cause de l’EOL
    Mais une approche du type « rendons illégale la production de déchets électroniques » manque de réalisme

    • Même sans solution parfaite, une loi simple imposant par exemple un remboursement en cas de perte de fonction pourrait déjà améliorer les choses
      Exemple : si le produit ne peut plus remplir sa fonction principale, remboursement intégral, sauf si le fabricant place le logiciel nécessaire dans le domaine public
      Une telle loi pourrait freiner les grands groupes comme Google lorsqu’ils neutralisent des produits en coupant leurs serveurs
    • Mais selon cette logique, faudrait-il aussi publier un Windows en fin de vie ?
      Passer Windows 10 en open source ruinerait la stratégie de long terme de Microsoft
  • Cette idée est intéressante, peut-être même davantage que l’« open source » en lui-même
    Par exemple, si UBNT publiait sa chaîne de démarrage EOL et permettait à Cambium d’utiliser ce firmware,
    on pourrait aboutir non pas à un support communautaire, mais à une concurrence perpétuelle sur les mises à jour produit

    • Dans la pratique, un open source complet est difficile, et les fabricants n’ont pas le droit de divulguer de l’IP de tiers
      À minima, ils ne devraient pas empêcher l’exécution de logiciels alternatifs choisis par l’utilisateur
    • Mais même cela ne suffit pas
      La plupart des utilisateurs, si les serveurs disparaissent, ne réinstallent pas le firmware : ils jettent simplement l’appareil
      Il faut donc des conceptions sans dépendance à des serveurs externes
      Par exemple, une enceinte intelligente devrait prendre en charge le streaming sur réseau local, et une ampoule l’appairage via des protocoles standard
      Heureusement, des standards comme Matter over Thread évoluent dans cette direction
  • Le Google Nest Thermostat de 1re et 2e génération en est un exemple typique
    Le projet No Longer Evil a redonné vie à ces appareils avec un firmware open source
    Il supprime la dépendance au cloud de Google et permet à l’utilisateur d’héberger lui-même le serveur ou de contrôler l’appareil de manière autonome
    Grâce à cela, un matériel coûteux retrouve une seconde vie

  • J’ai l’impression qu’on traverse en ce moment une sorte d’âge sombre
    Autrefois, une chaudière fonctionnait en mettant simplement une broche à la masse, mais les modèles suivants sont passés à des protocoles fermés, rendant l’accès plus difficile
    Les modèles les plus récents prennent toutefois de nouveau en charge le standard OpenTherm, ce qui les rend plus faciles à bidouiller
    Aujourd’hui, il existe beaucoup de matériel ouvert basé sur ESP32 ou Raspberry Pi, et je crée moi-même des interfaces avec ESPHome + LVGL pour les intégrer à la domotique
    Le résultat était si abouti que mes amis pensaient qu’il s’agissait d’un produit de marque

  • Je pense que « cela n’arrivera pas »
    Heureusement, grâce à l’IA et Android, le reverse engineering des protocoles devient plus facile
    Rien qu’en analysant un APK, on peut obtenir beaucoup d’informations, au point que je développe moi-même une app et un serveur pour le Limitless Pendant acheté avant son rachat par Meta
    Je n’ai pas écrit une seule ligne de code moi-même

  • Personne n’attend un support à vie
    Mais il est difficile d’accepter qu’on fasse aussi disparaître les fonctions de base simplement parce que le backend de l’application ou la roadmap ont disparu
    Si l’appareil est encore en bon état électrique et mécanique, un usage minimal devrait au moins être garanti