Il est assez banal de dire que de plus en plus d'équipements modernes sont
connectés au réseau. Cela apporte de nouvelles fonctionnalités, la possibilité
d'améliorer le produit même une fois vendu par des mises à jour mais aussi des
problèmes de confidentialité et de sécurité.
Les systèmes embarqués sont particulièrement concernés par ces
problématiques, que les industriels traitent parfois mal et dont les
consommateurs sont rarement dans le vrai également.
C'est de cette problématique dont on va parler.
Obsolescence programmée ?
Ce terme revient souvent dans ce genre de discussions. Que l'abandon du
support d'un produit, comme par exemple l'absence d'une mise à jour Android, ou
que justement la mise à jour de trop rend le système trop lent (cas de certains
iPhone) serait une pratique digne de l'obsolescence programmée.
Globalement c'est faux. L'obsolescence programmée est une pratique supposée
où un constructeur fragilise **volontairement** son produit afin de nécessiter
un remplacement régulier pour augmenter ses ventes.
Le mot clé est donc l'aspect volontaire. Qui est difficile en réalité à
constater. Et certains oublient aussi l'aspect de l'équilibre entre le prix et
la qualité. Un produit bas de gamme va minimiser la qualité des matériaux par
exemple pour que cela coûte moins cher au client. Il est donc normal que le
produit dure moins longtemps. Cette question du compromis dans la réalisation
du produit est l'essence même du travail d'un ingénieur et de la création de
différentes gammes de produits, on ne peut assimiler cela à de l'obsolescence
programmée qui consiste en un sabotage.
Je ne vais pas m'étendre beaucoup sur le sujet, il y a trois articles de
blog (ici, là et
là-bas) qui traitent bien de la question de l'obsolescence
programmée qui reste une pratique à priori confidentielle. Mais le célèbre
reportage d'Arte sur le sujet a mis en lumière cette pratique avec de mauvais
exemples et certains le voient du coup... partout.
En tout cas on ne m'a jamais demandé de saboter mon propre produit, et aucun
de mes collègues ou connaissances non plus. 
Par contre il arrive que
certains bogues ne soient jamais corrigés, faute de temps ou de ressources
financières pour les traiter.
De la question du progrès logiciel
Certains produits, comme nos ordinateurs ou téléphones portables, peuvent
vivre des années sans problèmes. Et ces outils à usage assez génériques peuvent
exécuter du logiciel conçu bien après la réalisation du produit.
Mon ordinateur portable personnel actuel date de 2011, il est passé de
Fedora 16 à 27, de Windows 7 à 10, de Firefox 7 à Firefox 56, de GNOME 3.0 à
GNOME 3.26, de Linux 3.1 à Linux 4.14, etc.
Ce sont des millions de lignes de code ajoutées depuis, le Web a beaucoup
grossi entre temps avec du JavaScript devenu omniprésent et des sites devenant
de plus en plus des applications complètes. Le contenu multimédia s’alourdit,
passant du 720p à 4K pour les vidéos ou les photos. Le chiffrement s'est
généralisé également dans les communications ou le stockage.
J'ai constaté peu à peu un ralentissement de ma machine, la consommation de
la mémoire a monté (j'ai du rajouter 4 Gio récemment) alors que mon usage,
fondamentalement n'a pas changé.
Ce phénomène n'a rien de nouveau, cela suit la loi de
Wirth.
C'est un phénomène naturel. Les logiciels évoluent pour ajouter des
fonctionnalités (pour répondre à des besoins des utilisateurs). Il est
impossible de proposer du logiciel plus moderne tout en espérant une
consommation en ressource identique indéfiniment. Soit il faut utiliser un
produit qui n'évoluera plus fonctionnellement (cas de beaucoup d'outils simples
et légers), ou alors il faudrait beaucoup de ressources financières et humaines
pour maintenir plusieurs déclinaisons du logiciel dans le temps. Ce que l'on
abordera plus tard.
Ce que la loi de Wirth n'explique pas ou mal, c'est que l'évolution du
matériel se produit de manière globale, mais localement un produit a un
matériel plutôt figé. Si le matériel évolue mais que les logiciels n'exploitent
pas cette puissance supplémentaire, ce serait du gâchis. Donc la consommation
des programmes évoluent pour bénéficier de ces ressources disponibles. Et
forcément cela se fait au détriment des machines qui accusent d'un certain âge.
Cela est encore plus visible sur les téléphones qui ont fait un saut de
performances spectaculaire en très peu d'années.
Certains veulent exploiter la machine le plus longtemps possible (donc
disons 10-15 ans) tout en bénéficiant de ces évolutions. Ce n'est pas possible
sans concession. Il faut faire des choix, en payant cher des produits pour les
maintenir longtemps, en renonçant partiellement à ce progrès, en changeant de
machine ou renoncer à des usages. Typiquement, aller sur le Web avec une
machine de 2002 doit être possible, mais cela ne doit pas être une expérience
très agréable en dehors de quelques sites très légers.
Et pour un téléphone bas de gamme, conçu pour être tout juste capable de
lancer les applications populaires de l'époque, ne peut pas soutenir la charge
d'une mise à jour des dites applications sur le long terme.
Et après toute cette explication, comment associer cela à de l'obsolescence
programmée alors que cette lourdeur progressive provient de logiciels
extérieurs à la conception du matériel ? Ce n'est pas Intel qui a rendu Firefox
plus lourd avec le temps. 
La sécurité
La sécurité est devenue depuis quelques années un sujet de premier plan pour
tout un nouveau panel de produits. Avec une connexion accessible depuis
Internet, il devient possible d'essayer d'infiltrer ces produits qui peuvent
être accessibles non stop pendant des années et sans maintenance active (il n'y
a pas un administrateur système pour surveiller le réseau domestique d'un
particulier).
Du coup, pour combler les failles, il devient nécessaire de mettre à jour le
produit. Parfois changer l'outil interne, ou le protocole employé (le MD5 n'est
plus un moyen fiable pour vérifier l'intégrité d'un fichier ou d'un
certificat).
Du coup pour améliorer la sécurité, on doit les faire évoluer. Ce qui peut
nous faire revenir sur le point précédent où le logiciel devient trop lourd
pour le matériel considéré ce qui rend compliqué la conciliation des deux.
L'autre problème est... le coût. Quand on achète un produit type téléphone,
un réfrigérateur connecté, un modem ou autre, nous achetons le produit à un
prix fixe, parfois très dérisoire car très bas de gamme. Sauf que d'assurer une
maintenance sur 10-15 ans, cela coûte très cher. Car il devient nécessaire de
maintenir plusieurs versions du logiciel (suivant l'âge du matériel et de ses
successeurs à maintenir), de tester chaque mise à jour sur chaque produit,
tester son déploiement, corriger les éventuels ratés auprès des clients,
communiquer auprès d'eux (manuels explicatifs, mise à jour d'un site Web
possiblement en plusieurs langues, courriers / courriels envoyés en
nombre).
Admettons que pour maintenir un modèle d'un téléphone portable pendant 15
ans il faut une équipe de 10 personnes à temps plein (ce qui n'est pas
irréaliste car cela demande beaucoup de travail pour corriger la moindre faille
ou les bogues découverts, sachant que le logiciel dépend également du lieu
vendu pour des raisons de contraintes légales). En admettant qu'ils ne sont pas
mal payés (et qu'il leur faut du matériel adéquat), cela peut revenir par
employé à un coût annuel pour l'employeur d'environ 100 000€. Donc 1 million
d'euros par an. Sachant qu'un modèle lambda d'un téléphone peut être vendu
auprès du million d'unités au total, cela reviendrait a un coût de 10-15
millions d'euros rien que pour la maintenance une fois le produit vendu. Pour
des téléphones à 100€, cela représente 10% du budget global du produit ! Ce
n'est clairement pas négligeable. Et je ne parle pas des cas de produits moins
vendus qui méritent pourtant la même maintenance.
Le Libre comme solution ?
Certains pensent qu'un produit embarqué, s'il est fait avec du logiciel
libre, il est aisé de le maintenir pour proposer des mises à jour du produit
pendant des années après l'abandon par son constructeur. La réalité est plus
complexe.
Pour les projets assez puissants pour accueillir un système d'exploitation
Linux (cas des téléphones par exemple), le système est rarement compilé de zéro
à la main. Pour gagner du temps, il existe des solutions comme Yocto
ou buildroot (et ses déclinaisons OpenWRT ou
ptxdist) pour compiler l'ensemble des logiciels (dont le noyau) pour
notre système afin d'obtenir une image qu'on pourra installer sur la cible. Je
les présenterais dans un autre article.
Seulement, chaque processeur ou plateforme a ses spécificités. C'est
pourquoi, les concepteurs des puces (Qualcomm, Texas Instrument, Broadcom,
Freescale / NXP et autres) fournissent les solutions citées plus haut avec les
changements nécessaires pour exploiter la plateforme. Très souvent le noyau
Linux et le chargeur de démarrage U-Boot accueillent une grande liste de
correctifs maison (plusieurs centaines).
Cela est bien, car nous n'avons pas à développer nous même les pilotes pour
exploiter les fonctions du processeur (notamment pour la couche graphique) et
dans l'essentiel cela reste du code libre. Cependant ces correctifs sont gros
et souvent… mal réalisés. Faute de temps et de ressources, les constructeurs ne
cherchent pas à concevoir des correctifs qui finiront dans le projet officiel.
Leur but est que cela fonctionne avec le noyau fourni aux développeurs /
intégrateurs. Du coup nous nous retrouvons avec un noyau et un chargeur de
démarrage figé, car Linux évolue très vite et il est très difficile de porter
ces correctifs pour une autre version. Et comme cela est trop souvent trop mal
fait (utilisation d'une pile logicielle différente que celle du noyau pour une
fonction donnée, comme le SPI ou le réseau par exemple, code spaghetti avec
lien fort entre le tronc commun et leur pilote, etc.) il est difficilement
imaginable de porter cela sur le noyau officiel directement.
Pas mal de personnes essayent pourtant de porter le nécessaire sur le noyau
officiel. Mais cela demande beaucoup de temps (aujourd'hui le support du
téléphone N900 est quasiment complet, mais il aura fallu 8 ans après sa sortie
!) et c'est souvent au prix de fonctionnalités partielles (performances
graphiques ou réseaux plus faibles, gestion de l'énergie douteuse). Sans
collaboration du fondeur, c'est une tâche globalement vouée à l'échec étant
donné le rythme de sortie des composants. Puis le fabricant de la puce bosse
déjà sur la plateforme suivante. Ils n'ont pas le temps, ni l'envie, de
s'attarder sur un produit qui n'a plus d'avenir.
Et même dans le cas où ce serait possible, il y a des sacs de nœuds dans
l'architecture du système. Si vous souhaitez profiter par exemple des dernières
tablettes Wacom sur votre machine, il faudra un noyau récent. En admettant que
vous avez un noyau LTS un peu ancien comme la 3.4, il faudra rétro-porter
cette fonctionnalité. Cela signifie récupérer le pilote mais souvent d'autres
commits sur le sous-systèmes des périphériques entrées. Mais le noyau ne fait
pas tout, il faut également que l'interface graphique propose de quoi
configurer et exploiter le matériel. Donc par exemple en récupérant du travail
effectué sur les versions récentes de GTK+ et de GNOME. Cela peut donc
représenter beaucoup de travail, sur beaucoup de composants, et il faudra
tester bien sûr du bon fonctionnement, de la sécurité et de la maintenance de
tout ceci.
Bref, l'aspect libre peut aider bien sûr à maintenir un produit plus
longtemps. D'ailleurs les initiatives du genre OpenWRT, CyanogenMod / LineageOS
permettent de maintenir à jour certains produits embarqués plus longtemps que
le support officiel du constructeur. Mais cela se fait souvent au détriment de
certaines fonctionnalités matérielles.
Solutions ?
Je pense que la solution ne peut se passer de l'aide des industriels, qui
eux-mêmes ne peuvent pas se permettre à un coût fixe d'une maintenance complexe
sur une très longue durée. Imposer légalement une durée minimale de support
conduirait à une hausse de prix d'achat inévitable de tous ces biens.
Une autre solution serait d'évoluer vers une tarification en tant que
service. À savoir payer pour une durée de maintenance souhaitée. Si
l'utilisateur souhaite 10 ans de maintenance, il le pourra, au prix d'un
abonnement ajusté en conséquence. Je pense que c'est la seule solution,
notamment pour les produits vendus à un volume moyen ou faible, d'avoir une
maintenance dans le temps à la hauteur, sans rendre le produits inutilisable ou
trop cher à l'achat.
La solution libre et gratuite me semble difficilement possible. Il suffit de
voir qu'aucune distribution purement communautaire gratuite pour x86 n'arrive à
gérer une maintenance de plus de 5 ans. Pourtant la plateforme est plus simple
et plus standard. Donc aller au delà me paraît difficile. Car ce n'est pas une
tâche aisée, ni très passionnante. Il faut en effet du savoir faire du matériel
et beaucoup de temps.
Après bien entendu, les constructeurs ont leur part à jouer, en s'impliquant
d'avantage dans le noyau officiel (qui pourrait lui également avoir une
politique plus adaptée à ces besoins, en ayant une API interne plus stable). Il
faut également réduire la surface d'attaque au maximum, n'offrir l'accès au
réseau que lorsque la plus valu est réelle. Ce genre de décisions aideraient à
avoir une meilleure sécurité dans le temps de ces plateformes.
Original post of Renault.Votez pour ce billet sur Planet Libre.
on en retrouve aussi sur 
