Une télévision apparemment en veille contacte régulièrement plusieurs serveurs. Une montre synchronise son activité, sa localisation et ses diagnostics. Une caméra transmet des séquences vidéo vers le cloud, tandis qu’un thermostat envoie des relevés de température, des commandes et des informations sur son état technique.
Ces échanges sont rarement présentés clairement à l’utilisateur. La fiche commerciale décrit les fonctionnalités, pas l’architecture réseau nécessaire à leur fonctionnement. L’application indique parfois quelles catégories de données personnelles sont traitées, mais rarement le volume quotidien transmis, la liste des domaines contactés ou la fréquence exacte des communications.
Il faut néanmoins corriger une impression trompeuse : le trafic des objets connectés « n’explose » pas uniformément. Une caméra enregistrant dans le cloud peut consommer beaucoup de bande passante. Un détecteur d’ouverture peut transmettre très peu de données, tout en révélant des informations sensibles sur les horaires d’occupation d’un logement. Le volume ne mesure donc ni la légitimité du traitement ni son niveau d’intrusion.
Des communications qui dépassent largement la fonction visible
Un objet connecté ne transmet pas uniquement les données nécessaires à la fonction que l’utilisateur pense avoir achetée.
Une balance peut envoyer le poids mesuré, mais aussi l’identifiant de l’appareil, l’heure, la version du firmware, l’état de la batterie et des informations sur la réussite de la synchronisation. Une caméra peut transmettre son flux vidéo, des miniatures, des événements de mouvement, des journaux techniques et des informations permettant de mesurer l’utilisation de certaines fonctions.
Ces communications peuvent être regroupées en plusieurs catégories.
La première correspond au service principal : transmettre une alerte, synchroniser une mesure, recevoir une commande ou sauvegarder un enregistrement.
La deuxième relève de la télémétrie technique : état de la batterie, température interne, erreurs, performances du réseau, redémarrages ou échecs de connexion. Ces informations peuvent être utiles pour détecter les pannes et améliorer le produit.
La troisième concerne les mises à jour, la configuration, la vérification des certificats et la synchronisation de l’heure. Même un appareil peu utilisé doit parfois contacter plusieurs infrastructures pour rester sécurisé.
La quatrième comprend l’analyse d’usage : fréquence d’activation d’une fonction, navigation dans l’application, caractéristiques de l’environnement ou interactions avec les notifications. Selon sa précision et son association à un compte, cette télémétrie peut devenir une donnée personnelle.
Enfin, le produit peut communiquer avec des prestataires tiers : hébergeur cloud, service de notifications, outil d’analyse, réseau de distribution de contenu ou infrastructure de diagnostic. L’utilisateur a alors l’impression que son appareil parle uniquement au fabricant, alors que plusieurs organisations techniques interviennent.
La CNIL rappelle que les objets connectés peuvent fonctionner directement avec Internet ou passer par un smartphone servant de relais. Dans les deux cas, les données peuvent être rendues accessibles sur l’application ou sur le service web de l’éditeur. Cette architecture multiplie les composants à examiner : objet, application, compte, cloud et éventuels sous-traitants.
Pourquoi les transmissions restent-elles invisibles ?
La première raison est physique : les appareils communiquent sans interface détaillée. Un ordinateur affiche parfois l’activité d’une application. Une ampoule ou un interphone ne possède aucun écran permettant de montrer qu’il vient de contacter un serveur.
La deuxième est organisationnelle. Les fabricants documentent généralement les données selon des catégories juridiques — informations de compte, diagnostics, localisation ou données d’utilisation — plutôt que sous la forme d’un journal réseau compréhensible. Or une politique de confidentialité ne répond pas nécessairement à des questions concrètes : à quelle fréquence l’appareil communique-t-il ? Quels domaines contacte-t-il lorsqu’il est inactif ? Que se passe-t-il lorsque la collecte facultative est désactivée ?
La troisième raison est le chiffrement. Lorsqu’un appareil utilise correctement HTTPS ou un autre protocole chiffré, un observateur du réseau peut généralement voir qu’une connexion existe, sa durée, son volume et certaines informations sur sa destination. Il ne peut pas lire directement le contenu transmis.
Ce chiffrement est indispensable à la sécurité, mais il complique l’audit externe. Voir qu’une caméra a envoyé 50 mégaoctets vers une infrastructure cloud ne permet pas de déterminer avec certitude s’il s’agissait d’une mise à jour, d’un enregistrement vidéo ou d’un diagnostic.
La quatrième raison est l’utilisation d’infrastructures mutualisées. Un nom de domaine ou une adresse IP peut appartenir à un grand hébergeur utilisé par des milliers de services. Identifier le propriétaire du serveur ne permet donc pas toujours d’identifier la finalité du traitement. À l’inverse, une destination située dans un pays donné ne prouve pas que les données y seront durablement stockées.
L’intelligence artificielle augmente-t-elle systématiquement le trafic ?
L’IA peut augmenter les communications lorsqu’elle est exécutée dans le cloud. Un assistant vocal peut transmettre un enregistrement, son contexte et des métadonnées afin que le serveur produise une transcription ou une réponse. Une caméra peut envoyer des images pour classifier une personne, un colis ou un véhicule.
La CNIL souligne que la transmission d’un enregistrement vocal peut être accompagnée d’identifiants directs ou indirects, comme l’adresse IP, le numéro d’équipement, le pseudonyme ou les données du compte. Le fichier principal ne constitue donc qu’une partie de l’information transmise.
Mais l’IA peut aussi réduire le trafic. Une caméra exécutant localement un modèle de détection peut envoyer uniquement une alerte au lieu de transférer un flux continu. Un capteur industriel peut résumer des milliers de mesures en un indicateur d’anomalie.
La mention « intelligence artificielle » ne permet donc pas de conclure. Il faut savoir où le modèle est exécuté, quelles données lui sont fournies et ce qui quitte réellement l’appareil.
Comment mesurer ce que transmet un appareil ?
La première étape consiste à identifier précisément l’équipement. Dans un logement comme dans une entreprise, il faut associer chaque adresse réseau à un produit, un modèle, une application et un propriétaire. Un appareil inconnu dans la liste du routeur doit être traité comme un problème d’inventaire avant d’être analysé comme un problème de confidentialité.
La deuxième étape est de placer les objets sur un réseau séparé : réseau invité, segment réservé aux appareils connectés ou VLAN dans une installation professionnelle. Cette séparation facilite la mesure et limite les communications avec les ordinateurs, téléphones et serveurs internes.
La troisième étape consiste à établir un profil de référence. Il faut mesurer le trafic pendant plusieurs situations : appareil inactif, utilisation normale, activation d’une fonction sensible, mise à jour, redémarrage et perte temporaire de connexion.
Le NIST recommande précisément de caractériser l’ensemble des comportements réseau d’un objet selon différents cas d’usage et différentes conditions. Une capture effectuée pendant cinq minutes immédiatement après l’installation ne suffit pas : certains échanges ne se produisent qu’une fois par jour, après une mise à jour ou lors d’un événement particulier.
La quatrième étape consiste à examiner les informations accessibles sur le routeur ou le pare-feu : volumes envoyés et reçus, horaires, domaines demandés par le DNS et connexions sortantes. Les routeurs grand public ne fournissent pas tous ce niveau de détail. Dans une entreprise, un pare-feu correctement configuré peut produire une vision plus exploitable.
Il faut toutefois résister à une interprétation excessive. Un domaine contacté toutes les minutes peut correspondre à une synchronisation légitime, à une vérification de disponibilité ou à une télémétrie disproportionnée. Le trafic révèle un comportement, pas automatiquement son objectif.
La cinquième étape est expérimentale : bloquer temporairement l’accès Internet de l’objet et observer ce qui cesse de fonctionner. Cette méthode permet de distinguer les fonctions locales des fonctions dépendantes du cloud. Elle ne prouve pas quelles données étaient transmises, mais elle révèle le degré de dépendance au serveur du fabricant.
Un appareil qui perd son service principal dès que le cloud est inaccessible présente un risque de continuité. Un appareil qui continue à fonctionner mais ne peut plus être administré à distance possède une architecture différente. Ces distinctions devraient être connues avant l’achat.
Jusqu’où peut aller un audit technique ?
Un utilisateur avancé peut enregistrer les paquets réseau depuis une passerelle ou un point d’accès dédié. Il pourra alors analyser les protocoles utilisés, les tailles de messages, les destinations, les tentatives de connexion et les communications non chiffrées.
Il ne faut cependant pas promettre une transparence totale. Le contenu protégé par TLS restera illisible sans interception particulière. Installer de faux certificats ou contourner la validation TLS pour déchiffrer le trafic peut réduire la sécurité, enfreindre des règles internes et ne fonctionne pas lorsque l’application utilise l’épinglage de certificat. Cette technique doit rester réservée à des audits autorisés et maîtrisés.
Pour le grand public, la démarche la plus réaliste consiste à croiser plusieurs indices : activité relevée par le routeur, permissions accordées à l’application, paramètres de confidentialité, historique du compte, documents du fabricant et fonctionnement observé lorsque certaines autorisations sont retirées.
Les permissions du téléphone apportent un contrôle utile sur la localisation, le microphone, la caméra ou les appareils proches. Elles ne montrent toutefois pas tout ce que l’objet lui-même mesure ni les données dérivées par le service cloud. La CNIL distingue d’ailleurs les permissions techniques du consentement juridique : autoriser techniquement l’accès à une donnée ne suffit pas, à lui seul, à justifier tous les usages qui peuvent en être faits.
Ce que le droit européen commence à changer
Le RGPD impose déjà transparence, limitation des finalités et minimisation lorsque des données personnelles sont traitées. La CNIL rappelle que les personnes doivent pouvoir comprendre pourquoi leurs données sont collectées, comment elles seront utilisées et comment exercer leurs droits.
Le Data Act ajoute des exigences plus spécifiques aux objets connectés. Depuis son application générale, le 12 septembre 2025, certaines informations doivent être fournies avant la conclusion du contrat, notamment le type, le format et le volume estimé des données générées, leur éventuelle production continue, leur stockage et les moyens permettant d’y accéder. Pour les services associés, le texte demande également d’indiquer la nature, le volume estimé et la fréquence de collecte des données obtenues par le détenteur.
À compter du 12 septembre 2026, les produits et services associés nouvellement mis sur le marché devront également être conçus pour rendre leurs données accessibles par défaut, de manière sécurisée et exploitable, lorsque les conditions prévues par le règlement sont réunies.
Cette évolution améliore la transparence juridique, mais elle ne remplacera pas un véritable tableau de bord technique. Un volume « estimé » ne montre pas nécessairement les variations après une mise à jour, les communications avec chaque prestataire ni la différence entre trafic indispensable et télémétrie facultative.
Reprendre le contrôle exige une visibilité continue
Le problème n’est pas que tout objet transmet des données. Sans communication, un objet connecté perdrait une partie de sa fonction. Le problème est l’impossibilité fréquente de relier chaque transmission à une finalité compréhensible et désactivable.
Un produit réellement transparent devrait fournir un historique simple : données envoyées, fréquence, destinataires, finalité, durée de conservation et réglage correspondant. Il devrait également distinguer clairement ce qui est indispensable au service, nécessaire à la sécurité et facultatif pour l’analyse ou l’amélioration du produit.
En attendant que cette transparence devienne la norme, la seule méthode fiable consiste à combiner documentation, paramètres et observation réseau. Le résultat ne révélera pas toujours le contenu exact des transmissions chiffrées. Il permettra néanmoins de répondre aux questions essentielles : l’appareil communique-t-il lorsqu’il devrait être inactif ? Avec combien de services ? Dans quels volumes ? Et que perd-on réellement lorsque ces communications sont bloquées ?
