Oui, on peut en parler, mais pas automatiquement. Il faut éviter le raccourci paresseux : “plus de mises à jour = obsolescence programmée”.
En revanche, lorsqu’un objet connecté fonctionne encore physiquement mais perd ses mises à jour de sécurité, il entre dans une zone beaucoup plus dure : il peut rester allumé, mais devenir juridiquement contestable, techniquement fragile, et économiquement poussé vers le remplacement.
La vraie question n’est donc pas “est-ce que chaque fin de support est un délit”. La vraie question est : à partir de quand l’arrêt des mises à jour transforme-t-il un objet encore fonctionnel en produit artificiellement condamné ?
1) Un objet IoT peut “marcher” et être pourtant déjà obsolète
C’est le cœur du problème. Un thermostat, une caméra, une alarme, une prise connectée ou une serrure peuvent encore :
- s’allumer,
- exécuter leurs fonctions de base,
- répondre localement,
- et sembler “en état”.
Mais si le fabricant cesse :
- les correctifs de sécurité,
- la maintenance logicielle,
- les mises à jour de compatibilité,
- ou le support des services distants indispensables,
alors le produit ne devient pas forcément cassé. Il devient abandonné.
Et dans l’IoT, l’abandon logiciel est souvent plus grave qu’ailleurs, parce que l’objet reste branché, exposé, parfois accessible à distance, et dépend souvent d’un environnement réseau mouvant. Le matériel peut donc rester intact pendant que sa valeur d’usage réelle s’effondre.
2) L’arrêt des mises à jour de sécurité n’est pas neutre : il raccourcit la vie utile
Une fin de support sécurité réduit directement la durée de vie utile d’un produit connecté. Pas forcément parce que l’objet cesse immédiatement de fonctionner, mais parce que :
- de nouvelles vulnérabilités ne seront plus corrigées,
- l’objet devient un maillon faible du réseau,
- l’entreprise ou l’utilisateur prudent finit par devoir l’isoler,
- certaines applis ou services cessent progressivement de le supporter,
- et le risque juridique ou assurantiel peut augmenter.
Autrement dit : la fin des mises à jour ne tue pas toujours le matériel, mais elle peut tuer son usage acceptable.
3) Le vrai critère : arrêt de support ou stratégie délibérée ?
Il faut distinguer trois situations.
La première : fin de support annoncée, claire, limitée, cohérente.
Un fabricant peut dire : support sécurité pendant X ans, puis fin. C’est dur, mais lisible. Ce n’est pas automatiquement de l’obsolescence programmée ; cela peut relever d’une politique de cycle de vie, à condition qu’elle soit transparente et proportionnée.
La deuxième : fin de support floue ou prématurée.
Le produit est encore commercialisé, encore vendu comme “intelligent”, mais les mises à jour deviennent rares, silencieuses ou cessent très tôt. Là, on entre dans une zone problématique : pas forcément un délit établi, mais une pratique qui peut devenir trompeuse, voire abusive selon le contexte contractuel et la communication commerciale.
La troisième : dégradation logicielle volontaire.
Quand un fabricant retire, bloque, dégrade ou fragilise délibérément un produit encore matériellement sain pour accélérer son remplacement, on se rapproche beaucoup plus clairement de l’idée d’obsolescence programmée logicielle.
4) Le cas typique de l’IoT : pas de patch, donc remplacement forcé
Dans l’IoT, la pression au remplacement est souvent indirecte.
Le fabricant ne dit pas : “achetez le nouveau modèle”.
Il laisse simplement se produire ceci :
- plus de correctifs,
- appli qui évolue et supporte moins bien l’ancien appareil,
- services cloud qui changent,
- API qui ferment,
- compatibilités qui sautent,
- intégrations tierces qui cassent.
Résultat : l’objet n’est pas “mort”, mais il devient trop risqué, trop limité ou trop instable pour rester en production. Le renouvellement paraît alors naturel, alors qu’il est en réalité fabriqué par l’environnement logiciel.
C’est une forme d’obsolescence plus propre en apparence que la panne physique, mais souvent plus efficace : on pousse au remplacement sans casser le boîtier.
5) Ce que change le cadre européen : moins de place pour le “je vends puis j’abandonne”
Le cadre européen devient moins tolérant envers cette logique.
Il ne dit pas “toute fin de support est illégale”. Mais il change la pression normative : un fabricant ne peut plus prétendre sérieusement qu’un objet connecté peut être vendu comme produit moderne tout en étant abandonné logiciellement sans conséquence.
Autrement dit : la maintenance logicielle n’est plus un bonus implicite. Elle devient de plus en plus une composante normale de la vie utile du produit.
6) Alors, peut-on parler d’obsolescence programmée logicielle ?
Oui, dans certains cas, clairement. Mais il faut garder un niveau de preuve élevé.
On peut parler d’obsolescence programmée logicielle lorsque l’arrêt ou la dégradation logicielle :
- réduit la durée de vie utile d’un produit,
- pousse objectivement au remplacement,
- et semble relever d’un choix organisé, pas d’une simple limite technique honnête.
En revanche, toutes les fins de support n’entrent pas automatiquement dans cette qualification. Certaines relèvent plutôt :
- d’une politique de maintenance insuffisante,
- d’un défaut d’information,
- d’un manquement contractuel,
- d’une conception économiquement toxique,
- ou d’une obsolescence de fait, sans intention juridiquement démontrée.
La différence est importante : moralement, beaucoup de pratiques sont critiquables ; juridiquement, le mot “programmée” suppose davantage qu’un simple résultat.
Conclusion : quand le logiciel s’arrête, le matériel peut devenir un déchet fonctionnel
Dans l’IoT, la fin des mises à jour de sécurité peut condamner un objet encore parfaitement intact sur le plan matériel. Il continue d’exister, mais il cesse d’être acceptable, sûr ou durable à utiliser. C’est précisément ce qui rend l’obsolescence logicielle si puissante : elle transforme un produit encore vivant en remplacement “raisonnable”.
La bonne question n’est donc pas “est-ce qu’il s’allume encore”. La bonne question est : combien de temps un fabricant vous permet-il réellement d’utiliser l’objet en sécurité avant de transformer, par le logiciel, un matériel fonctionnel en dette ou en déchet ?
