Illustration générée par IA — visuel conceptuel.
Routeur, caméra IP, sonnette vidéo, capteur, hub domotique… Un objet connecté n’est pas seulement un « produit » : c’est aussi un logiciel exposé au réseau, qui devra être maintenu (mises à jour), administré (comptes), et qui peut traiter des données sensibles (images, audio, présence, habitudes).
Cette check-list propose une lecture pratique de l’ETSI EN 303 645 (exigences de base de cybersécurité pour les objets connectés grand public) afin de mieux acheter — sans recommander de marque, et sans prétendre à une obligation légale au Maroc. L’objectif est simple : vous donner des questions testables à poser au fabricant / vendeur et des indices concrets à chercher dans la documentation.
ETSI EN 303 645 : à quoi ça sert (et ce que ce n’est pas)
L’ETSI EN 303 645 définit des provisions (dispositions) de cybersécurité et de protection des données pour des objets connectés « grand public » (consumer IoT) connectés à Internet / à un réseau domestique (caméras, capteurs, hubs, etc.).
La norme utilise des verbes normatifs (« shall », « should », « may », etc.). Leur portée n’est pas une « règle propre » à EN 303 645 : elle renvoie explicitement aux ETSI Drafting Rules, via la section Modal verbs terminology du PDF. Autrement dit, EN 303 645 s’appuie sur la convention de rédaction ETSI pour exprimer des obligations, recommandations ou permissions, sans redéfinir elle‑même ces niveaux.
Pour une lecture opérationnelle (achat / contractualisation), l’Annexe B (ICS) est particulièrement utile : elle repère les dispositions en Mandatory (M) et Recommended (R). En pratique, cela aide à distinguer un socle minimal à exiger systématiquement (M) et des exigences renforcées (R) que vous pouvez décider d’imposer selon votre contexte (exposition Internet, sensibilité des données, volumétrie de déploiement, etc.). Enfin, l’introduction indique que de futures révisions pourraient rendre obligatoires des dispositions actuellement recommandées. Source : ETSI EN 303 645 v2.1.1 (PDF).
Important (version) : une version plus récente existe (ETSI EN 303 645 v3.1.3). Sur le portail ETSI (Work Item), le statut affiché est « Publication (2024-09-24) ». Le PDF v3.1.3 indique « V3.1.3 (2024-09) » et mentionne, dans le foreword, une date d’adoption au 11 septembre 2024. Dans le reste de cet article, les renvois numérotés de type “5.3‑13” correspondent à l’ETSI EN 303 645 v2.1.1 (2020‑06). Si votre appel d’offres, votre assureur, ou votre politique interne cite une version précise, partez de cette référence et évitez les ambiguïtés. Sources : ETSI Work Item (portail) ; ETSI EN 303 645 v3.1.3 (PDF).
Comment utiliser cette check-list avant d’acheter
Mode d’emploi (simple)
- Choisissez l’objet (caméra IP, routeur, capteur, hub…) et identifiez son mode d’usage : local (LAN) ou cloud, application mobile obligatoire ou non, stockage local ou cloud, accès à distance ou non.
- Demandez les preuves documentaires : manuel, guide d’admin, note de sécurité, page « security » du fabricant, procédure d’update, politique de divulgation des vulnérabilités.
- Transformez les réponses en critères d’achat : si un point est flou (« mises à jour quand nécessaire », « sécurité de niveau bancaire »…), demandez une formulation opérationnelle (période de support définie, mécanisme de mise à jour, contact sécurité, effacement, etc.).
- Gardez une trace (mail, fiche produit, capture de page) : utile pour votre dossier de projet, votre exploitation, et vos arbitrages.
Ce que cette check-list ne remplace pas
- Elle ne remplace pas une analyse de risque (site, exposition, sensibilité des données, contraintes d’exploitation).
- Elle ne remplace pas l’architecture réseau (segmentation, règles firewall, isolation) qui limite l’impact d’un objet compromis.
Si vous voulez aller plus loin côté projet (exigences « device » + exigences « fabricant/support »), vous pouvez compléter avec notre méthode orientée cahier des charges : Cahier des charges IoT : transformer NIST SP 800-213 en exigences concrètes.
La check-list d’achat « sécurisé par conception » (ETSI EN 303 645)
Note de référence (éviter l’ambiguïté de version) : les numéros de dispositions cités dans cette check-list (ex. 5.3‑13) se réfèrent à l’ETSI EN 303 645 v2.1.1 (2020‑06). L’ETSI EN 303 645 v3.1.3 (2024‑09) existe également : si votre politique interne exige la dernière version, vérifiez la correspondance des numéros et des formulations avant de figer un achat ou un cahier des charges.
Identifiants & accès : éviter le piège des mots de passe par défaut
- Mot de passe unique par appareil (ou défini par l’utilisateur) ?
À vérifier : le fabricant indique explicitement l’absence de mot de passe universel par défaut et précise le parcours de première configuration. (ETSI 5.1-1 — v2.1.1 PDF) - Peut-on changer facilement la valeur d’authentification (mot de passe, PIN, biométrie…) ?
À vérifier : interface claire (web/app), pas de contournement « obligatoirement cloud », pas de limite artificielle qui bloque la rotation. (ETSI 5.1-4 — v2.1.1 PDF) - Accès d’administration : peut-on séparer “compte admin” et “compte usage” ?
Lecture pratique : même si l’ETSI formule des exigences générales, en achat vous cherchez surtout à éviter l’admin partagé et l’admin “par défaut”. Si la documentation est muette, considérez cela comme un signal de risque et demandez clarification.
Mises à jour & durée de support : la question la plus déterminante à l’achat
- Existe-t-il un mécanisme de mise à jour permettant l’installation sécurisée des updates ?
À vérifier : procédure d’update officielle, mécanisme prévu côté produit (ETSI 5.3-2 — v2.1.1 PDF, pour les appareils non « constrained » ; la norme traite à part les « constrained devices », à ressources limitées). - La mise à jour est-elle simple à appliquer (et réaliste en exploitation) ?
À vérifier : update automatique / via service associé / via interface locale, et explication claire. (ETSI 5.3-3 — v2.1.1 PDF) - Le fabricant publie-t-il une période de support définie pour les mises à jour ?
À vérifier : mention explicite « support period » / fin de support / EoL, et périmètre couvert (firmware, app mobile, cloud). (ETSI 5.3-13 — v2.1.1 PDF) - Authenticité et intégrité des mises à jour : le produit vérifie-t-il ce qu’il installe ?
À vérifier : la documentation mentionne une vérification d’authenticité/intégrité via une relation de confiance (ex. signature, chaîne de confiance). (ETSI 5.3-10 — v2.1.1 PDF) - Cas des objets “non mises à jour” : le fabricant est-il transparent ?
À vérifier : justification, méthode de support (remplacement), période de support définie — présenté clairement. (ETSI 5.3-14 — recommandation, v2.1.1 PDF) - Le modèle est-il clairement identifiable ?
À vérifier : référence/modèle lisible sur l’appareil ou accessible localement, pour suivre les correctifs et le support. (ETSI 5.3-16 — v2.1.1 PDF)
Signalement des failles : le fabricant sait-il recevoir et traiter une vulnérabilité ?
- Politique de divulgation des vulnérabilités publique ?
À vérifier : page “Vulnerability Disclosure Policy” / “Security” avec un contact de signalement et des engagements minimaux de suivi (accusé de réception, mises à jour de statut). (ETSI 5.2-1 — v2.1.1 PDF) - Indicateur simple : si vous ne trouvez aucun contact sécurité (et seulement un formulaire commercial), exigez une réponse écrite avant achat, surtout pour une caméra IP exposée à Internet ou un routeur.
Données & vie privée : ce que la caméra (ou le capteur) collecte vraiment
- Chiffrement approprié pour les données personnelles sensibles en transit ?
À vérifier : le fabricant indique comment les données sensibles (ex. vidéo/audio) sont protégées lors des communications entre l’objet et ses services associés. (ETSI 5.8-2 — v2.1.1 PDF) - Capacités de capteurs externes documentées ?
À vérifier : la fiche produit / manuel décrit clairement ce que le produit capte (optique, acoustique…), et dans quelles conditions. (ETSI 5.8-3 — v2.1.1 PDF) - Transparence sur les données traitées et leurs finalités ?
À vérifier : documentation claire sur quelles données sont collectées, pour quel usage, par quels acteurs. (ETSI 6-1 — v2.1.1 PDF) - Si consentement : opt-in valide et retrait possible ?
À vérifier : contrôle réel dans l’app/service, et retrait du consentement possible à tout moment. (ETSI 6-2 et 6-3 — v2.1.1 PDF) - Télémétrie : l’utilisateur est-il informé ?
À vérifier : le fabricant indique ce qui est remonté, pourquoi, à qui, et à quelles fins. (ETSI 6-5 — v2.1.1 PDF). Pour l’achat, c’est un bon révélateur du niveau de maturité du fournisseur.
Pour les projets où l’objet connecté filme/enregistre (caméra, interphonie, contrôle d’accès), la dimension « données personnelles » devient structurante. En contexte marocain, voici un repère utile côté projet (sans constituer un avis juridique) : Caméras, accès et Wi‑Fi invités : points de protection des données à vérifier au Maroc.
Réseau & exposition : limiter la surface d’attaque
- Le produit utilise-t-il une cryptographie de bonne pratique pour sécuriser ses communications ?
À vérifier : mention explicite de chiffrement pour les communications réseau sensibles, et cohérence (ex. accès admin, flux vidéo, API). (ETSI 5.5-1 — v2.1.1 PDF) - Les paramètres de sécurité critiques transmis à distance sont-ils protégés en confidentialité ?
À vérifier : pas d’authentifiants exposés, pas de secrets transmis en clair, cohérence des parcours (ex. provisioning, appairage). (ETSI 5.5-7 — v2.1.1 PDF) - Interfaces inutilisées désactivées ?
À vérifier : le fabricant indique qu’il désactive les interfaces réseau/logiques inutiles (ou qu’elles sont désactivables), et que les interfaces de debug physiquement accessibles sont désactivées en logiciel. (ETSI 5.6-1 et 5.6-4 — v2.1.1 PDF)
Conseil d’achat (caméra IP / routeur) : demandez au vendeur si le produit peut fonctionner en local (LAN) sans exposition Internet directe, et quels flux sortants sont nécessaires (cloud, notifications, accès à distance). Un produit qui impose un accès cloud permanent augmente mécaniquement votre dépendance à l’éditeur (support, continuité, conditions de service).
Et si votre sujet est une caméra (au-delà de la cybersécurité), la qualité de l’image dépend aussi du capteur, de l’optique et des fonctions adaptées au site : Caméra IP : comment choisir capteur, optique et fonctions selon le site ?.
Secrets & clés : un bon produit évite les « secrets codés en dur »
- Stockage sécurisé des paramètres sensibles ?
À vérifier : la documentation sécurité (quand elle existe) ou les engagements du fabricant mentionnent la protection des paramètres sensibles stockés en persistant. (ETSI 5.4-1 — v2.1.1 PDF) - Pas de paramètres de sécurité critiques codés en dur ?
À vérifier : engagement du fabricant (rarement visible en fiche produit). En pratique, c’est une question à poser pour départager des fournisseurs, surtout si l’objet est massivement déployé. (ETSI 5.4-3 — v2.1.1 PDF)
Fin de vie & effacement : pouvoir sortir proprement (vente, déménagement, revente, remplacement)
- Effacement simple des données utilisateur (y compris secrets) ?
À vérifier : procédure de “factory reset”/effacement documentée et accessible, couvrant configuration, données personnelles et matière cryptographique (mots de passe/clefs). (ETSI 5.11-1 — v2.1.1 PDF) - Question pratique : l’effacement coupe-t-il bien le lien à un compte cloud (déprovisionnement) ? Si ce point n’est pas documenté, exigez une procédure claire : c’est critique pour une caméra ou un hub.
Pour les projets plus « infrastructure » (baies réseau, GTB, équipements d’exploitation), la logique de sortie de parc est proche : inventaire, rotation des accès, effacement, révocations. À adapter au résidentiel, mais utile en méthode : Mettre hors service une baie réseau ou une GTB : check-list d’effacement et rotation des accès.
Mini-grille de décision : que faire si un point clé est “non” ou “inconnu” ?
- Inconnu sur la durée de support : à traiter comme un risque d’obsolescence (produit potentiellement “jetable”). Demandez une réponse écrite avant achat.
- Pas de politique de divulgation des vulnérabilités : signal faible de maturité ; si l’objet est exposé (caméra/routeur), privilégiez un fournisseur plus transparent.
- Mises à jour peu claires ou impossibles : prévoyez un plan de remplacement, ou choisissez un autre produit.
- Effacement non documenté : risque de revente/déménagement compliqué, et risque résiduel sur les comptes cloud.
Transformer la check-list en exigences de projet (architecte, BET, MOA)
Pour un projet (villa, immeuble, résidence, commerce), le plus efficace est de transformer ces questions en exigences contractuelles : documents à fournir (politique vulnérabilités, support, procédure d’update), capacités attendues, et critères de réception.
Si vous souhaitez une version “cahier des charges / consultation” adaptée à votre périmètre (caméras, routeur, interphonie, capteurs, smart home), vous pouvez nous contacter : l’objectif est d’obtenir des réponses vérifiables avant commande et des livrables utiles à l’exploitation.
