Un développeur a montré qu’en passant par le cloud de DJI, une appli bricolée avec une IA pouvait lui donner le contrôle de milliers d’aspirateurs robots et d’autres appareils, jusqu’à voir des flux caméra et des plans d’intérieur dans 24 pays.
L’histoire commence comme une blague de geek : piloter un aspirateur DJI avec une manette. Elle finit comme un rappel froid : dès que ton objet connecté dépend du cloud, une erreur de permissions peut te rendre visible. Ici, pas besoin de “pirater” un serveur au sens hollywoodien : l’accès s’est ouvert par un mauvais contrôle côté backend. DJI a corrigé après alerte, mais le cas expose une vérité simple : la surface d’attaque, c’est la commodité.
A lire aussi :
- Cette IA chinoise fait avancer un casse tête vieux de 300 ans : le “nombre de baisers” sort enfin de l’impasse
- Cette démo IA “trop parfaite” a tourné au fiasco : Microsoft renvoie vers des livres Harry Potter piratés, le lien explose sur Hacker News, et le billet disparaît en urgence
Une idée idiote, un résultat inquiétant : la manette qui mène à la maison des autres
Un stratège IA a acheté le Romo, l’aspirateur robot récent de DJI, avec une idée légère : le conduire à la manette plutôt qu’avec l’appli officielle. Le genre d’expérimentation “pour voir”. Sauf que son application, codée rapidement avec une IA de programmation, ne s’est pas contentée d’authentifier son appareil. En se connectant aux serveurs cloud, elle a affiché l’accès à environ 6 700 appareils répartis dans 24 pays. Et comme le même backend pilotait aussi des stations d’énergie portables, le total d’objets exposés est monté au-delà de 10 000. Ce n’est plus un gadget, c’est une démonstration de risque à grande échelle. DJI, cloud, permissions.
Ce qui a été exposé : caméra, plans, localisation, et commandes comme si c’était “chez lui”
Avec cet accès, l’utilisateur pouvait envoyer des commandes aux robots, vérifier des niveaux de batterie, et récupérer des métadonnées comme des numéros de série et des adresses IP. Le point qui fait grimacer, c’est le reste : des flux caméraembarqués et des plans de maison générés par la cartographie du robot. Autrement dit, pas seulement “un objet”, mais une fenêtre sur l’intimité d’un logement. Le cas montre aussi qu’en entrant un code à 14 chiffres, il pouvait contourner le PINsur n’importe quel appareil. Même si l’intention était de prouver un problème, la mécanique révèle une chose : la séparation entre “mon compte” et “le compte des autres” n’était pas correctement verrouillée. caméra, plans, PIN.

Pourquoi le cloud est un aimant à problèmes : le confort a un prix
Contrôler un aspirateur depuis l’extérieur de son Wi-Fi local est pratique. Mais cette praticité impose un passage par des serveurs : authentification, routage des commandes, synchronisation des données. C’est là que tout se joue. Si la validation des permissions côté backend est bancale, un client peut recevoir plus que ce qu’il a demandé. Et dans un monde d’objets connectés, “plus” signifie souvent “trop”. Le cas DJI illustre le piège classique : une API pensée pour faciliter l’usage devient une API qui facilite l’accès non autorisé, sans qu’il soit nécessaire d’exécuter une attaque sophistiquée. Le cloud n’est pas le méchant, mais c’est un multiplicateur de dégâts quand l’isolation entre utilisateurs échoue. API, backend, attaque.
Le détail qui fait peur : la vulnérabilité était exploitable sans être un “hacker”
Le récit a pris une tournure quasi comique en ligne, parce que l’accès a été obtenu “trop facilement”. Et c’est précisément ce qui inquiète. Quand une faille exige un équipement rare, une connaissance avancée ou du temps, elle reste souvent cantonnée. Quand elle tombe via une appli écrite à la va-vite, elle devient accessible à n’importe qui d’assez curieux. Ici, l’utilisateur n’a pas forcé une porte avec un bélier : il a utilisé la clé que le système lui a donnée par erreur. C’est la différence entre une vulnérabilité théorique et un scénario de mass exploitation. Le fait que l’accès s’étende à des milliers d’appareils montre que le problème était structurel, pas un cas isolé. vulnérabilité, accès, échelle.

DJI a patché, mais le débat reste : chiffrement ne suffit pas si les droits sont mal gérés
DJI a fermé la brèche peu après avoir été alerté. L’entreprise a expliqué qu’elle travaillait déjà sur un correctif lié à une vulnérabilité de validation des permissions côté backend, mais que le déploiement n’était pas encore complet au moment des faits. DJI a aussi minimisé la portée, en affirmant que très peu de personnes avaient exploité le problème et que la plupart étaient des chercheurs en sécurité. Le chiffrement des communications peut être réel, mais il ne résout pas la question centrale : si le serveur te renvoie des appareils qui ne sont pas à toi, tu peux parfaitement recevoir des données “chiffrées” qui restent, au final, lisibles pour l’utilisateur authentifié. Le nerf de la guerre est l’autorisation, pas seulement le transport. patch, chiffrement, autorisation.
Une conséquence politique : l’affaire nourrit les peurs autour des objets connectés chinois
Le cas tombe dans un contexte déjà inflammable. Aux États-Unis, les débats sur la sécurité des produits connectés étrangers sont devenus agressifs, notamment autour des drones, au point d’alimenter des restrictions et interdictions. Le Romo n’est d’ailleurs pas vendu sur le marché américain, ce qui dit quelque chose du climat. Une faille de ce type, même corrigée, devient un argument dans la guerre des narratifs : “regardez, ça confirme nos craintes”. Le problème, ici, n’est pas seulement technique, il est géopolitique. Et il rappelle une règle : chaque incident de sécurité est utilisé comme munition, parfois bien au-delà de son périmètre réel. sécurité, confiance, régulation.
Les leçons pratiques : ce que tu peux faire, même si tu ne codes pas
La bonne nouvelle, c’est que l’utilisateur final n’est pas totalement impuissant. La mauvaise, c’est qu’il ne peut pas corriger une erreur de backend. Mais il peut réduire l’exposition. Première règle : tenir l’application à jour et accepter les mises à jour de firmware, surtout quand un fabricant annonce un correctif. Deuxième : activer un PIN robuste et vérifier les options de partage, même si elles semblent secondaires. Troisième : surveiller les permissions et limiter l’accès caméra quand c’est possible. Quatrième : séparer les objets connectés sur un réseau Wi-Fi invité ou un VLAN, pour éviter qu’un appareil compromis serve de tremplin. Enfin, choisir des produits où le mode local est possible, car “local-first” réduit la dépendance au cloud. Ce n’est pas une garantie, mais c’est une réduction de surface. mises à jour, réseau, confidentialité.
| Élément exposé | Ce que ça révèle | Risque principal |
| Flux caméra | Intérieur, activité | Atteinte à la vie privée |
| Plan de maison | Disposition des pièces | Ciblage, repérage |
| Métadonnées (IP, série) | Identifiants techniques | Profilage, attaques ciblées |
| Contrôle à distance | Commandes robot | Nuisance, surveillance |
Source : The Verge

