Ce changement avait avait fait dégoupiller une bonne partie de la communauté Firefox. La nouvelle mise à jour du navigateur web permet désormais de garder ou non les outils d'IA dans le logiciel.
On en sait un peu plus sur les soucis qui ont causé une évacuation d'urgence à bord de la Station spatiale internationale. Mike Fincke avait besoin de matériel d'imagerie qu'on ne trouve que sur Terre, et les expériences en cours de Sophie Adenot portent justement sur ces technologies.
Un développeur vient de prendre le contrôle de plus de 10 000 appareils DJI (dont 7 000 robots aspirateurs Romo - lien affilié) répartis dans 24 pays... en voulant juste piloter le sien avec une manette PS5.
Oui oui c'est un grand malade ^^.
À la base, Sammy Azdoufal, responsable IA chez Emerald Stay, voulait juste s'amuser avec son aspi alors il a d'abord essayé d'y connecter sa manette DualSense en Bluetooth, et puis il a fini par utiliser Claude Code pour décompiler l'appli mobile DJI (version Android) et reverse-engineerer les protocoles MQTT de DJI. Bien sûr, il lui fallait un token d'auth pour prouver qu'il était bien proprio du Romo et jusque-là, rien de méchant...
Sauf que le broker MQTT de DJI n'avait AUCUN contrôle d'accès au niveau des topics (c'est la chaîne de caractères qui sert d'adresse pour router les messages entre les publishers et les subscribers). Du coup, avec un seul token TLS, il voyait le trafic de tous les appareils en clair sur le broker cloud de DJI. Pas de brute force, pas d'exploit sophistiqué mais juste un pauvre token et un client MQTT.
Et hop, le voilà avec les flux vidéo des caméras embarquées, les micros, les plans 2D des maisons, les adresses IP et les numéros de série de milliers de machines. Un journaliste de The Verge lui a même filé son numéro de série, et depuis Barcelone, Azdoufal a pris le contrôle de son Romo, a pu voir qu'il était à 80% de batterie et en train de nettoyer le salon, pour finir par générer le plan de l'appart. Flippant hein ??
En gros, DJI avait un problème de validation de permissions côté backend. Ils l'ont patché début février sauf que... Azdoufal a trouvé une DEUXIÈME faille (un bypass du PIN caméra) qui serait toujours pas corrigée. Et c'est pas fini, le bonhomme aurait encore 2 autres vulnérabilités majeures sous le coude qu'il n'a pas divulguées publiquement et sur lesquelles DJI bosse activement pour les corriger. Cerise sur le gâteau, les batteries DJI Power étaient aussi accessibles via cette archi MQTT. Ce sont de grosses batteries portables qu'on garde chez soit pour avoir un peu de jus en cas de coupure de courant ou quand on est off the grid..
Attention par contre, si vous avez un Romo, vérifiez bien que le firmware est à jour. Vous vous en doutez, DJI a d'abord nié le problème avant de finalement patcher mais bon, moi aussi j'ai une caméra sur mon aspi robot et comme j'adore me balader en slip chez moi, je plains le hacker qui passera par là... Et je vous raconte pas quand on aura des robots humanoïdes comme ce qu'on a vu avec la faille des robots Unitree , tiens...
Le Pentagone et la société Anthropic renégocient l’accès au chatbot Claude sur les réseaux classifiés de l’armée, alors que le ministère américain de la Défense presse les acteurs de l'intelligence artificielle d’assouplir leurs garde-fous.
Arrivée le 14 février 2026 à bord de l'ISS, Sophie Adenot a bouclé sa première semaine complète dans l'espace. Entre la mise en route de la mission Epsilon, l'adaptation physique et les premières expériences scientifiques, le rythme est déjà intense pour l'astronaute française.
Le Pentagone et la société Anthropic renégocient l’accès au chatbot Claude sur les réseaux classifiés de l’armée, alors que le ministère américain de la Défense presse les acteurs de l'intelligence artificielle d’assouplir leurs garde-fous.
Arrivée le 14 février 2026 à bord de l'ISS, Sophie Adenot a bouclé sa première semaine complète dans l'espace. Entre la mise en route de la mission Epsilon, l'adaptation physique et les premières expériences scientifiques, le rythme est déjà intense pour l'astronaute française.
Ce 24 février 2026, une affaire retient l’attention sur X : celle de Sammy Azdoufal, un ingénieur ayant découvert involontairement une faille de sécurité affectant les aspirateurs de la marque chinoise DJI.
Ce 24 février 2026, une affaire retient l’attention sur X : celle de Sammy Azdoufal, un ingénieur ayant découvert involontairement une faille de sécurité affectant les aspirateurs de la marque chinoise DJI.
Sous pression du régulateur californien, Tesla a préféré supprimer son Autopilot plutôt que de le renommer et de modifier sa manière de le promouvoir. Les clients sont incités à s’orienter vers l’option payante du FSD, à 99 dollars par mois.
À cause d'un bug, l'IA Copilot a contourné les politiques DLP de Microsoft 365, exposant ainsi le contenu de mails pourtant classés comme confidentiels.
Le post IA : ce bug a permis à Microsoft Copilot de lire des e-mails confidentiels a été publié sur IT-Connect.
Dans un article publié le 14 février 2026, le média américain The Verge revient sur la découverte involontaire d'une faille de sécurité affectant les appareils de la marque chinoise DJI. En bidouillant son aspirateur connecté pour le piloter avec une manette PlayStation, un utilisateur a pu accéder à des données de milliers d'appareils à travers le monde.
Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ?
Hé bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution basée sur systemd (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif déjà installé qui permet de diagnostiquer tout ça : systemd-analyze
Ce truc c'est un peu le médecin légiste de votre démarrage système. Il dissèque chaque étape, identifie les unités qui traînent la patte, et vous permet de comprendre où part votre précieux temps. Pour ceux qui débarquent, systemd est le système d'initialisation adopté par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parallèle pour gagner du temps.
Pour commencer, la commande de base c'est tout simplement :
Connexionsystemd-analyze time
Elle vous sort un récapitulatif du temps passé dans chaque phase, généralement le kernel, l'initrd (le RAM disk initial), et l'espace utilisateur. Selon votre configuration, vous pourriez aussi voir passer le firmware ou le bootloader. Ça donne un truc du genre "Startup finished in 2.5s (kernel) + 19s (initrd) + 47s (userspace)". Déjà là, vous savez si le problème vient de votre noyau ou de vos services.
Mais le truc vraiment cool pour fouiller un peu plus dans le détail, c'est :
systemd-analyze blame
Cette commande vous balance la liste des unités systemd, triées par le temps qu'elles ont mis à s'initialiser. C'est un peu comme un classement des cancres de la Ve République. Vous voyez direct qui sont les boulets qui ralentissent tout le monde. Genre ce service réseau qui attend 20 secondes une connexion qui n'arrivera jamais, ou ce truc de logs qui prend son temps pour se réveiller.
Attention quand même, y'a un petit piège car un service qui met 10 secondes à démarrer ne signifie pas forcément que votre boot est rallongé de 10 secondes. Pourquoi me diriez-vous ? Hé bien parce que systemd lance plein de trucs en parallèle. Un service peut donc prendre son temps tranquille pendant que d'autres bossent en même temps sans bloquer personne.
Pour vraiment piger ce qui coince sur le chemin critique, lancez plutôt :
systemd-analyze critical-chain
Ça, c'est le top car ça vous montre la chaîne critique, c'est-à-dire la séquence exacte d'événements qui détermine vraiment votre temps de démarrage final. Vous voyez exactement quelles unités sont sur le chemin et lesquelles attendent les autres. Le temps après le "@" indique quand l'unité est devenue active, et le temps après le "+" montre combien de temps elle a pris pour démarrer. C'est bien plus fiable que blame pour identifier les vrais goulots d'étranglement.
Et si vous êtes du genre visuel, y'a même :
systemd-analyze plot > boot.svg
Et avec ça, hop, ça génèrera un magnifique graphique SVG qui représentera la chronologie de votre séquence de boot. Vous pourrez ensuite l'ouvrir dans votre navigateur et voir en un coup d'oeil ce qui démarre quand et combien de temps ça dure. C'est super pratique pour épater la galerie ou juste visualiser l'ordre de lancement.
Maintenant, une fois que vous avez identifié les coupables, comment on fait pour accélérer tout ça ?
Déjà, vous pouvez désactiver les services dont vous n'avez pas besoin avec :
sudo systemctl disable nom-du-service
Gardez en tête que disable supprime seulement le lancement automatique au boot, mais n'empêche pas une activation indirecte via une dépendance ou un socket. Si vous voulez vraiment qu'un service ne démarre plus jamais, utilisez mask. Et surtout, ne désactivez pas n'importe quoi comme un bourrin, hein ! Je vous connais ! Non, non, avant de toucher à un service, vérifiez d'abord ce qui en dépend :
systemctl list-dependencies nom-du-service
Car si vous cassez un truc important, votre système risque de ne plus démarrer correctement. Donc si vous n'êtes pas sûr, gardez vos mimines dans vos poches. D'ailleurs, si vous bidouillez vos fichiers d'unité (comme pour automatiser Shiori par exemple), sachez que vous pouvez aussi les vérifier pour débusquer les erreurs avec :
systemd-analyze verify /chemin/vers/unite.service
C'est super pratique pour éviter les mauvaises surprises au prochain redémarrage. Voilà et si vous cherchez d'autres astuces pour optimiser votre machine Linux , n'hésitez pas à jeter un oeil à mon article sur TLP.
Ah j'oubliais, y'a aussi la commande systemd-analyze security qui permet d'analyser le niveau d'exposition sécurité de vos services. Elle attribue un score heuristique d'exposition basé sur les options de durcissement (hardening) actives. Plus le score est bas, mieux le service est protégé contre d'éventuelles failles. C'est donc un excellent point de départ pour identifier les services qui mériteraient un peu plus de love côté isolation.
Bref, cet analyseur de démarrage c'est vraiment l'outil indispensable pour qui veut comprendre et optimiser son boot Linux. C'est natif, c'est puissant, et ça vous évite de passer des heures à chercher pourquoi votre machine met autant de temps que vous à se réveiller le matin ^^.
