Cette approche est plus exigeante que le marketing habituel, mais elle colle mieux aux référentiels sérieux. ETSI pose une base commune pour les objets connectés grand public ; le NCSC détaille des principes de conception plus profonds ; NIST a travaillé sur des critères destinés à structurer l’évaluation et l’étiquetage des produits IoT grand public. (etsi.org)
Le premier critère : le cloud est-il obligatoire ou simplement pratique ?
C’est souvent le critère le plus révélateur. Un produit qui ne fonctionne que si vous créez un compte, reste connecté en permanence à un service distant et dépend du cloud pour des fonctions de base mérite immédiatement plus de méfiance qu’un produit qui conserve une vraie autonomie locale. Ce point n’apparaît pas toujours formulé ainsi dans les standards, mais il découle directement de plusieurs de leurs exigences : limitation de l’exposition, contrôle de l’architecture, robustesse de gestion, minimisation des dépendances et meilleure maîtrise du cycle de vie.
En pratique, la bonne question à poser est simple :
si Internet tombe, ou si le service du fabricant disparaît, que reste-t-il du produit ?
Plus la réponse est “pas grand-chose”, plus l’objet est susceptible d’être intrusif, fragile ou frustrant à long terme.
Le deuxième critère : le compte utilisateur est-il réellement nécessaire ?
Tous les comptes ne sont pas abusifs. Certains servent à la synchronisation multi-appareils, à la sauvegarde ou à l’administration distante. Mais un compte obligatoire pour allumer une ampoule, regarder une caméra en local ou piloter un appareil qui pourrait fonctionner sur le LAN est un signal faible de bon design.
Ce critère compte parce qu’un compte ajoute de la persistance : identifiants, historique, corrélations, récupération distante, dépendance à l’application, rattachement à une politique de conservation qui vous échappe. Le RFC 6973 insiste sur les risques liés aux identifiants persistants et à la corrélation d’événements. Ton critère d’évaluation peut donc être brutal mais juste :
si le compte semble surtout utile au fabricant, pas à l’utilisateur, il faut le considérer comme un coût de vie privée. Pour comprendre comment ces signaux s’accumulent dans le temps, il faut aussi regarder ce que la télémétrie domestique peut révéler. (rfc-editor.org)
Le troisième critère : les mises à jour sont-elles claires, vérifiées et durables ?
C’est l’un des critères les moins glamour, mais l’un des plus décisifs. ETSI met explicitement les mises à jour logicielles dans ses priorités de base, et le NCSC consacre un principe entier aux mises à jour sécurisées, avec vérification de l’authenticité et protection contre l’altération. (etsi.org, ncsc.gov.uk)
Ce qu’il faut chercher :
- une politique de mise à jour visible,
- une indication sur la durée de support,
- un mécanisme de vérification des mises à jour,
- un historique crédible de correctifs.
Ce qu’il faut craindre :
- aucune date,
- aucune politique publique,
- un produit “vivant” seulement tant qu’il est vendu,
- des mises à jour dont on ne comprend ni la fréquence ni la provenance.
Un objet connecté sans horizon de support clair n’est pas seulement un objet fragile ; c’est un objet qui peut devenir envahissant et abandonné.
Le quatrième critère : le fabricant accepte-t-il d’être contredit ?
C’est un critère rarement mis en avant par les comparatifs, et pourtant il est central. ETSI fait de la vulnerability disclosure policy une de ses priorités explicites, et le NCSC encourage lui aussi des réponses publiques et documentées sur la manière dont les risques sont pris en compte. (etsi.org)
En clair : un fabricant sérieux doit offrir un moyen de signaler une faille, expliquer comment il traite ces signalements et montrer qu’il ne considère pas la recherche de vulnérabilités comme une agression illégitime.
Un produit sans politique de divulgation, sans documentation sécurité, sans canal clair de remontée, mérite un malus immédiat.
Le cinquième critère : les privilèges sont-ils limités ou expansifs ?
Le NCSC insiste sur la réduction des privilèges et de la portée des applications, ainsi que sur la contrainte des interfaces. Ce point est décisif pour l’évaluation d’un objet connecté : demande-t-il plus de permissions qu’il n’en faut ? Expose-t-il trop d’interfaces ? Ouvre-t-il des fonctions qui dépassent son usage réel ? (ncsc.gov.uk)
Côté lecteur, cela se traduit par des questions très concrètes :
- l’application demande-t-elle un accès large au téléphone pour des fonctions secondaires ?
- l’objet expose-t-il trop de ports, de fonctions d’administration ou de capacités réseau ?
- la logique produit semble-t-elle “ouvrir large puis on verra”, au lieu de “donner juste le nécessaire” ?
Un objet discret est souvent un objet qui demande moins, pas un objet qui promet plus.
Le sixième critère : le fonctionnement local existe-t-il vraiment ?
C’est un critère crucial pour ton angle éditorial. Beaucoup de produits revendiquent un “contrôle local” alors qu’il s’agit en pratique d’un compromis partiel ou d’un mode dégradé. Il faut donc distinguer :
- contrôle local réel,
- fonctions locales accessoires,
- local affiché mais cloud central dans les faits.
Ce critère est important parce qu’il change tout : résilience, dépendance, lisibilité du trafic, possibilité de segmentation utile, et capacité à garder l’objet fonctionnel sans remettre tout le pouvoir au fabricant. Il prolonge directement les logiques d’architecture sobre et de réduction de dépendance que soutiennent les référentiels sérieux, même quand ils ne l’énoncent pas sous cette formule exacte.
Le septième critère : le produit documente-t-il son état et son comportement ?
Le NCSC parle explicitement de transparency of device health. C’est un très bon critère de tri, parce qu’il dépasse la simple communication marketing. Un objet correctement documenté devrait au minimum permettre de comprendre :
- son état logiciel,
- ses mises à jour,
- certains événements de sécurité,
- une partie de ses comportements attendus.
Un produit opaque ne devient pas meilleur parce qu’il a une jolie interface.
Un lecteur sérieux doit regarder si le fabricant explique réellement ce que l’appareil fait, ce qu’il journalise, comment il se met à jour, comment il récupère après incident, et comment il communique sur sa sécurité.
Le huitième critère : la sécurité est-elle testable ou seulement proclamée ?
C’est ici qu’il faut éviter le fétichisme du badge. ETSI ne propose pas seulement un texte de principe ; l’écosystème autour d’EN 303 645 comprend aussi une spécification d’évaluation, TS 103 701, destinée à tester la conformité de produits aux provisions du standard. ETSI précise d’ailleurs que ce cadre sert déjà de base à plusieurs schémas d’assurance et de certification. (etsi.org)
Cela ne veut pas dire qu’un logo suffit. Mais cela veut dire qu’un produit qui peut être évalué contre des critères publics et structurés mérite plus d’attention qu’un produit qui se contente d’affirmations marketing vagues du type “military-grade” ou “privacy-first”.
Le neuvième critère : la récupération et la fin de vie sont-elles prises au sérieux ?
Le NCSC inclut aussi la capacité à retrouver un known good state. C’est un critère sous-estimé. Un appareil connecté peut être mal configuré, partiellement compromis, ou simplement rendu instable par une mise à jour ratée. S’il n’existe aucun mécanisme raisonnable de récupération, le produit devient plus risqué, plus opaque et souvent plus vite jetable. (ncsc.gov.uk)
De la même manière, l’utilisateur devrait pouvoir savoir ce qu’il se passe en fin de support :
- le produit continue-t-il à fonctionner ?
- dans quelles limites ?
- devient-il un simple déchet numérique dépendant d’un service qui s’éteint ?
Un bon produit n’est pas seulement celui qui démarre bien ; c’est aussi celui qui vieillit sans devenir une boîte noire cassée.
Le dixième critère : le marketing est-il plus fort que l’architecture ?
C’est ton critère de clôture, et il est probablement le plus humain. Un objet connecté qui multiplie les promesses vagues mais documente mal sa sécurité, son support, ses flux, ses dépendances, ses interfaces et son cycle de vie doit être pénalisé.
À l’inverse, un produit moins sexy, mais plus clair sur :
- ses mises à jour,
- sa politique de vulnérabilité,
- son mode local,
- ses limites,
- son support,
mérite souvent une meilleure note.
Autrement dit :
plus le discours est large, plus la preuve doit être précise.
Une grille simple pour juger avant d’acheter
Tu peux proposer au lecteur une grille courte :
- Compte obligatoire : non / partiel / oui
- Cloud obligatoire : non / partiel / oui
- Contrôle local réel : oui / limité / non
- Politique de mises à jour : claire / floue / absente
- Durée de support : annoncée / probable / inconnue
- Divulgation de vulnérabilités : oui / difficile à trouver / absente
- Permissions de l’application : limitées / discutables / excessives
- Transparence sur l’état du produit : bonne / moyenne / faible
- Récupération / reset sain : documenté / partiel / flou
- Promesses marketing vs preuves : cohérentes / inégales / creuses
Ce type de grille est beaucoup plus utile qu’un simple “bon produit / mauvais produit”.