Ce qu’un VPN change réellement
La première chose qu’un VPN change, c’est le trajet visible du trafic sortant. Au lieu de voir un appareil communiquer directement avec Internet depuis l’adresse IP publique du foyer, le fournisseur d’accès ou l’observateur placé sur ce segment voit avant tout un tunnel chiffré vers le fournisseur VPN. C’est le cœur même du principe : un VPN protège les données en transit sur un réseau non maîtrisé en créant une connexion chiffrée entre un client et un point distant. C’est pour cela qu’il peut avoir un intérêt réel quand on veut limiter une partie de l’observabilité du trafic sortant.
Il peut aussi déplacer la confiance. C’est un point important, souvent mal formulé. Le VPN ne supprime pas le problème de confiance ; il le déplace. CISA l’exprime très clairement dans ses recommandations récentes pour les mobiles : un VPN personnel peut simplement déplacer une partie du risque résiduel du fournisseur d’accès vers le fournisseur VPN, avec parfois une surface d’attaque supplémentaire. Cette remarque vise un autre contexte, mais le principe vaut ici aussi : un VPN ne fait pas disparaître l’intermédiaire, il change surtout quel intermédiaire voit quoi. (cisa.gov)
Enfin, dans certains cas, un VPN peut aussi réduire l’exposition de certaines requêtes DNS sur le trajet local ou chez le FAI, surtout si la résolution passe elle aussi dans le tunnel ou s’appuie sur des mécanismes de DNS chiffré. Le RFC 7858 rappelle que DNS-over-TLS vise précisément à réduire l’écoute et l’altération en transit des requêtes DNS ; cela ne règle pas tout, mais cela montre bien qu’une partie du sujet se joue au niveau du chemin réseau, pas seulement de l’application. (datatracker.ietf.org)
Ce qu’un VPN ne change pas
C’est ici que beaucoup de contenus deviennent trompeurs. Un VPN ne modifie pas la logique native de l’objet connecté. Si un appareil a été conçu pour dialoguer régulièrement avec le cloud du fabricant, pour envoyer de la télémétrie, pour exiger un compte centralisé ou pour dépendre d’API distantes afin de fonctionner normalement, le VPN ne supprime rien de cela. Il peut masquer une partie du chemin, mais il ne réécrit pas l’architecture du produit. L’IETF insiste justement sur le fait que les approches de partitionnement de la vie privée ne sont pas une panacée et qu’elles doivent être évaluées dans le cadre d’une analyse holistique du système. (datatracker.ietf.org)
Il ne supprime pas non plus les signaux locaux. Un objet connecté peut continuer à parler sur le réseau local via des mécanismes comme mDNS, qui sert explicitement à faire des opérations de type DNS sur le lien local sans serveur DNS classique. Le RFC 6762 est très clair : Multicast DNS opère sur le lien local, avec des adresses multicast locales dédiées, et les réponses sont censées venir du même lien. En clair : un VPN peut protéger une partie du trafic sortant, mais il ne fait pas disparaître par magie les échanges de découverte locale. (datatracker.ietf.org)
Il ne corrige pas non plus les permissions excessives de l’application compagnon, la mauvaise qualité du support logiciel, l’absence de mises à jour sérieuses ou la dépendance à un écosystème opaque. Là encore, le NCSC rappelle dans ses principes de sécurité pour les appareils connectés qu’il faut juger l’ensemble du design, du support et de la gestion des mises à jour, pas seulement le transport chiffré. (ncsc.gov.uk)
VPN sur routeur, sur appareil ou par application : ce n’est pas la même chose
C’est probablement la distinction la plus importante pour ne pas raconter n’importe quoi.
Un VPN configuré par application ne protège que le trafic de l’application concernée. Apple le dit noir sur blanc dans sa documentation de déploiement : une configuration de per-app VPN tunnelise le trafic de l’app à laquelle elle est assignée. Cela veut dire qu’un “VPN” présent quelque part dans un écosystème ne garantit absolument pas que tout le trafic d’un appareil ou d’un objet passe par lui. (support.apple.com)
Même au niveau d’un appareil, le comportement n’est pas forcément absolu. Android documente explicitement le split tunneling : certains flux passent dans le VPN, d’autres non. Le système précise même qu’il est possible de router tout le trafic vers le VPN sauf certains préfixes, ou inversement de ne router vers le VPN qu’une partie du trafic. Là encore, la leçon est simple : “avoir un VPN” ne veut pas forcément dire “tout passe dedans”. (source.android.com)
À l’échelle du foyer, la logique routeur change la portée du dispositif. La FTC rappelle que, dans le monde de l’IoT domestique, le routeur est la pièce centrale par laquelle les appareils connectés accèdent à Internet. On peut donc raisonnablement en déduire qu’un VPN placé au niveau du routeur peut couvrir les équipements qui utilisent effectivement ce routeur comme passerelle vers Internet. Mais cette couverture reste architecturale, pas magique : elle dépend du routage réel, des exceptions éventuelles, et du fait que certains échanges locaux ou certaines conceptions applicatives restent hors sujet. Cette phrase comporte une part d’inférence technique, mais elle s’appuie directement sur le rôle central du routeur rappelé par la FTC. (consumer.ftc.gov)
Les faux espoirs les plus fréquents
Le premier faux espoir, c’est de croire qu’un VPN empêche le fabricant de savoir que son appareil est utilisé. C’est faux dès lors que l’objet continue à se connecter aux serveurs du fabricant avec ses propres identifiants, ses propres certificats, ses propres jetons ou son propre compte utilisateur. Le VPN peut masquer ou déplacer une partie de l’observation réseau, pas faire oublier à un service distant qu’il est en train de parler à son propre produit. Cette conclusion découle de la nature même d’un tunnel VPN et de l’analyse holistique recommandée par l’IETF.
Le deuxième faux espoir, c’est de croire qu’un VPN rend un objet “anonyme”. Là encore, le mot est trop fort. L’IETF rappelle que même lorsque certaines informations sont partitionnées ou mieux protégées, des canaux indirects comme l’analyse de trafic ou l’analyse temporelle restent possibles. Le VPN peut compliquer certaines observations, pas abolir les métadonnées ni les corrélations possibles.
Le troisième faux espoir, c’est de croire que toutes les requêtes DNS sont forcément “sauvées” par le VPN. Cela dépend de la configuration réelle : tunnel complet ou non, DNS dans le tunnel ou non, comportement applicatif, résolveur imposé, exceptions de routage. Les RFC sur la confidentialité DNS montrent bien que la protection du DNS dépend elle aussi de choix techniques explicites, pas d’une simple étiquette “VPN activé”.
Quand un VPN est réellement utile pour des objets connectés
Un VPN devient pertinent quand le problème principal est bien celui du trajet réseau sortant. Par exemple, si l’on veut éviter que le fournisseur d’accès voie directement quelles destinations sont contactées depuis le foyer, ou si l’on veut homogénéiser la sortie réseau d’un ensemble d’appareils derrière un même point de sortie, le VPN peut avoir une vraie utilité. Dans ce cadre, il joue pleinement son rôle de tunnel chiffré entre un environnement local et un point distant.
Il peut aussi être utile dans une logique de cohérence réseau : un routeur correctement configuré, qui concentre déjà le trafic d’un ensemble d’objets connectés, offre un point de contrôle plus logique qu’une juxtaposition d’applications VPN éparses sur des terminaux individuels. La FTC rappelle justement que le routeur est le point central de l’IoT domestique, ce qui renforce la pertinence d’une réflexion architecturale plutôt qu’appareil par appareil.
Enfin, il peut être utile comme complément, jamais comme réponse unique. C’est probablement la formulation la plus honnête : un VPN peut améliorer une partie de la posture de confidentialité, mais uniquement s’il s’inscrit dans un ensemble plus large comprenant le choix du produit, la segmentation du réseau, la maîtrise du DNS et une certaine lucidité sur la dépendance au cloud. L’IETF recommande précisément cette lecture globale plutôt qu’une confiance excessive dans une seule brique.
Quand un VPN n’est pas la bonne réponse centrale
Si le vrai problème est qu’un objet connecté dépend trop du cloud du fabricant, qu’il ne fonctionne pas sans compte, qu’il reçoit mal ses mises à jour ou qu’il parle trop librement au réseau local, alors le VPN n’est pas le levier principal. Le levier principal devient le choix du produit, puis l’architecture du réseau. La FTC met le routeur au centre de la protection des objets connectés domestiques, et le NCSC insiste sur le design, les mises à jour, les privilèges et la gestion du produit dans le temps.
En d’autres termes : un VPN est utile contre une partie de l’exposition en transit ; il est médiocre contre une mauvaise conception par défaut. Confondre les deux, c’est précisément ce qui produit les articles trop flatteurs ou trop simplistes sur les VPN.