Vous compressez vos fichiers Parquet avec gzip ? Ça marche, c’est trop cooool ! Vos CSV sont en Snappy ? Nickel c’est le bonheur !! Vos time-series sont dans un format custom que personne ne comprend sauf le dev qui est parti y’a deux ans sans laisser d’adresse ? Ah, merde…
Du coup, combien ça vous coûte vraiment ces histoires de compression ? Non, je ne parle pas en octets économisés, mais plutôt en temps humain perdu. Parce que Meta vient de publier un truc super cool qui s’appelle
OpenZL
et qui est un framework open source qui révèle une vérité qu’on préfère ignorer : Zuck est un reptilien euh, non… utiliser des compresseurs génériques pour tout, c’est pratique mais c’est une facture cachée qui explose !
Hé oui car les compresseurs universels comme gzip ou zstd sont géniaux, ils fonctionnent partout mais le problème c’est qu’ils ne comprennent rien à vos données. Pour eux, un CSV c’est pareil qu’un JPEG ou qu’un binaire random, du coup, vous obtenez une compression “correcte” mais rarement optimale.
Et vous vous retrouvez alors dans le cycle classique suivant : Un nouveau dataset structuré, vous tentez gzip, c’est bof. Vous essayez alors un compresseur spécialisé, mais faut l’intégrer au pipeline et franchement, la flemme. Et ça, ça vous prend combien de temps en vrai ?
Oui, je sais, vous n’en avez aucune idée mais chez Meta, ils ont évalué ça en mois de développement pour chaque nouveau type de données. Oui, des mois, pas des jours. Et après faut maintenir tout ça, gérer les versions, les dépendances, les cas particuliers…. bref.
Meta a donc fait le calcul et le partage ouvertement . Ils avaient des centaines de cas d’usage différents pour la compression de données structurées avec des fichiers Parquet, des CSV, des time-series, des tensors de machine learning, des tables de bases de données…etc et à chaque fois, soit vous prenez gzip et vous laissez de l’espace disque et de la bande passante sur la table, soit vous développez un compresseur custom et vous perdez des semaines de dev.
La solution classique consistait donc à multiplier bêtement les compresseurs spécialisés. Un pour Parquet avec Snappy, un autre pour les CSV, encore un autre pour les données numériques colonnes…etc et là ça devient vite le bordel car chaque compresseur a son décodeur, sa config, ses quirks. Vous vous retrouvez alors avec une infrastructure de compression qui ressemble à un mille-feuille de dépendances mais sans le bonheur d’une crème pâtissière de qualité.
C’est là qu’OpenZL débarque avec une approche totalement différente puisqu’au lieu de créer encore un énième compresseur spécialisé, ils ont fait un framework qui comprend la structure de vos données et génère automatiquement la meilleure stratégie de compression.
Donc en gros, vous donnez à OpenZL une description de la structure de vos données via leur Simple Data Description Language (SDDL). Ensuite leur “trainer” analyse des échantillons et trouve la séquence optimale de transformations. Ces transformations révèlent alors des patterns cachés dans vos données structurées, ce qui permet ensuite une compression beaucoup plus efficace qu’un compresseur générique aveugle.
Faut voir OpenZL comme un genre de compilateur en fait. Vous lui donnez une description haut niveau de vos données, et il génère un “plan de compression” optimisé pour ce type précis de données. Un peu comme un compilateur transforme du code haut niveau en binaire optimisé.
Et le plus beau c’est que tous les fichiers compressés par OpenZL, même avec des configs complètement différentes, se décompressent avec le même binaire. Comme ça c’est fini le casse-tête des multiples décodeurs à maintenir. Là vous avez un seul exécutable à déployer partout. Bref, c’est surtout ça la promesse de Meta avec OpenZL.
Cet outil est en prod chez eux et visiblement, comme ils le racontent sur X , il a réduit les temps de développement de mois à jours, pour des gains de compression et de vitesse systématiquement supérieurs aux compresseurs génériques. Sur des datasets Parquet par exemple, ils obtiennent des ratios de compression meilleurs que gzip tout en étant plus rapides à compresser et décompresser.
Pour vous donner un ordre de grandeur, Parquet avec gzip c’est déjà 2.37 fois plus compact qu’un CSV classique. OpenZL lui, va encore plus loin en exploitant les régularités intrinsèques des données colonnes tels que des types énumérés, des contraintes de range, des patterns temporels dans les time-series et c’est ça qui fait la différence entre un compresseur qui voit des bytes et un qui comprend la structure.
Meta considère le core d’OpenZL comme production-ready et l’utilisent en interne à large échelle depuis un petit moment. Maintenant si ça vous intéresse pour vos propres projets, sachez que le framework est sous licence BSD et dispo sur GitHub et vous avez un Quick Start guide , de la doc complète , et même un papier académique sur arXiv si vous voulez plonger dans les détails techniques du modèle graph-based qu’ils utilisent.
Voilà, si vous bossez avec des volumes importants de données structurées, si vous en avez marre de bidouiller des configs de compression, ou si vous voulez juste arrêter de payer la facture cachée des compresseurs universels, allez voir OpenZL sur GitHub .
Vous connaissez Vercel ? Cette plateforme de déploiement qui permet de mettre en ligne une app web en deux clics. Hé bien c’est super génial… mais ça ne marche qu’avec JavaScript. Du coup, si vous faites du Python, du PHP ou autre, vous êtes un peu coincé. Snif…
C’est un peu le problème que Ronan Berder, un dev de Singapour, s’est pris en pleine poire au moment où il a voulu déployer ses apps Python aussi facilement que du Next.js sur Vercel. Comme y’avait pas grand chose qui existait, il a donc créé DevPush, une alternative open source et auto-hébergeable qui fonctionne avec tous les langages de dev.
Vous connectez votre repo GitHub, vous pushez votre code, et boom, votre app est déployée, tout ça sans coupure de service, avec possibilité de retour en arrière instantané, des logs en temps réel, des environnements multiples, du SSL automatique…etc… Bref, tout ce que vous avez sur Vercel, mais sans être limité à Node.js.
DevPush supporte donc déjà Python avec Flask, Django et FastAPI et comme c’est basé sur Docker, n’importe quel langage peut tourner dessus. Node.js, PHP, Ruby, Go, Rust… ce que vous voulez. Y’a juste à créer un conteneur Docker et c’est parti.
Ce qui est cool, c’est surtout que vous pouvez l’héberger vous-même par exemple sur un VPS… Vous gardez ainsi le contrôle de vos données sans enfermement propriétaire ni mauvaises surprises sur la facture.
Pour l’installation c’est très simple puisqu’il suffit de lancer un script bash et en 5 minutes c’est en place sur votre serveur Ubuntu ou Debian. Vous créez ensuite votre premier projet, vous liez votre repo GitHub, et vous pushez. DevPush détecte alors automatiquement le framework Python, construit l’image Docker, et déploie l’app.
Chaque push sur GitHub déclenche alors un nouveau build et vous pouvez mapper des branches à des environnements différents. Par exemple, la branche main
en production, staging
en préproduction, dev
en développement et DevPush gère aussi les variables d’environnement de manière sécurisée, avec du chiffrement.
Les logs de build et de runtime sont également streamés en temps réel dans l’interface ce qui permet de voir exactement ce qui se passe pendant le déploiement. Comme ça, si une build plante, vous avez toutes les infos pour débugger et si vous voulez revenir en arrière, vous pouvez faire un rollback sur le commit précédent en 1 click !
DevPush génère aussi une URL de preview pour chaque déploiement ce qui permet de tester votre app avant de la mettre en prod, et quand vous êtes prêt, vous mappez ça avec votre domaine custom et DevPush s’occupe du certificat SSL automatiquement via Let’s Encrypt.
Évidemment, ce projet est encore jeune et le dev a prévu d’ajouter pas mal de nouvelles fonctionnalités comme la gestion de bases SQLite, le stockage persistant, le monitoring des ressources, le scaling, des tâches cron… mais encore un peu de patience…
Bref, si vous faites du Python ou autre chose et que vous en avez marre de gérer des serveurs à la main ou de payer un abonnement super cher sur une plateforme managée à la con, DevPush mérite le coup d’œil !
Putain, ils sont relous chez Microsoft ! Vous vous souvenez quand Microsoft a
supprimé la commande oobe\bypassnro
en mars dernier ? Cette petite astuce permettait tout simplement d’installer Windows 11 sans compte Microsoft et sans connexion internet. Les geeks ont alors râlé pendant 48 heures, puis quelqu’un a découvert une nouvelle parade : start ms-cxh:localonly
. C’est une commande magique qu’il suffisait de taper pendant l’installation (Shift+F10, vous connaissez la manip..) pour contourner l’obligation d’avoir un compte en ligne.
Eh bien devinez quoi ? Microsoft vient de colmater cette “faille” aussi.
Bref, dans une nouvelle build test de Windows 11 publiée le 6 octobre dernier, Amanda Langowski du Windows Insider Program a annoncé officiellement que toutes les méthodes connues pour créer un compte local pendant l’installation sont en train d’être supprimées. La raison officielle c’est que ces mécanismes contourneraient des étapes critiques de configuration et laisseraient des appareils pas complètement configurés.
Mouais, ça sent un peu le prétexte bidon pour justifier une décision déjà prise depuis longtemps, vous ne trouvez pas ?
Concrètement, si vous essayez maintenant la commande start ms-cxh:localonly
sur les nouvelles versions, elle réinitialisera simplement le processus d’installation et vous ramènera au point de départ. Bref, game over, Microsoft a gagné cette bataille.
Après vous allez me dire mais alors pourquoi tant de haine de la part des utilisateurs contre ce fichu compte Microsoft ??
Et bien déjà, il y a cette histoire débile du nom de dossier utilisateur car quand vous créez un compte Microsoft, Windows 11 génère automatiquement un nom de dossier à partir de votre adresse email. Donc c’est jamais ce qu’on veut, même si maintenant avec cette update, on peut d’après ce que j’ai compris régler ça à l’aide d’une commande un peu planquée.
Ensuite, il y a la question de contrôle car un compte Microsoft, c’est la synchronisation automatique de vos paramètres, de vos données, de votre historique. Du coup, c’est Edge qui s’impose, c’est Bing qui devient votre moteur de recherche par défaut, c’est OneDrive qui se synchronise que vous le vouliez ou non. Alors pour quelqu’un qui veut juste installer Windows proprement, sans toute cette couche de services Microsoft, c’est l’enfer !
Et je ne parle même pas des techos qui installent des dizaines de machines pour des clients. Faut se créer un compte Microsoft temporaire à chaque fois, puis le supprimer, puis reconfigurer… C’est du temps perdu pour rien. Le compte local, c’était simple, rapide, et efficace.
Mais bon Microsoft s’en fout royalement. Pour eux, Windows 11 est devenu surtout un portail vers leur écosystème de merde et plus vraiment un OS qui vous appartient vraiment. Vous payez votre licence, certes, mais la vraie valeur pour Microsoft, c’est que vous soyez connecté à leurs services. Tout ce qui est données de télémétrie, habitudes d’utilisation, publicités ciblées dans le menu Démarrer…etc, tout ça ne fonctionne qu’avec un compte en ligne.
Mais bon, rassurez-vous, il reste encore des solutions. Enfin, pour l’instant…
Rufus , l’outil de création de clés USB bootables, propose toujours des options pour créer une installation Windows 11 sans compte Microsoft. Vous pouvez aussi passer par des modifications du registre pendant l’installation, mais c’est un peu plus technique. Et si vous avez Windows 11 Pro ou Enterprise, l’option “Domain join” permet encore de créer un compte local, mais pour combien de temps ?
Pour le moment, Microsoft s’attaque aux méthodes faciles, celles que monsieur et madame tout-le-monde peuvent utiliser en suivant un tuto, mais je ne serais pas surpris que dans 6 mois, Microsoft s’attaque aussi à Rufus, à Flyoobe ou aux ISO modifiées.
C’est dommage je trouve car ce qui faisait le charme de Windows depuis toujours c’était justement de pouvoir le bidouiller jusqu’à l’os. En plus pour une boite qui se présente comme champion de l’open source depuis quelques années, c’est un move un peu bizarre… WSL pour faire tourner Linux sous Windows, VSCode qui est devenu l’éditeur de code préféré de la planète, GitHub racheté et mis à disposition gratuitement… C’est cool, mais côté Windows pur, ils font l’exact l’inverse de tout ça en verrouillant un max !
Rassurez-vous, Microsoft n’est pas le seul à suivre cette mauvaise pente… Apple aussi pousse de plus en plus iCloud sur macOS et je ne vous parle pas de Google qui rend ses services quasi-inutilisables sans compte. Bref, tout devient “service en ligne” même quand ça ne devrait pas l’être et ce PC qu’on possédait vraiment, celui sur lequel on configurait comme on voulait tout ce qu’on voulait est en train de disparaitre.
Bien sûr, vous pourrez toujours compter sur moi pour que je vous partage des astuces ou des outils pour contourner toutes ces limitations techniques à la con mais franchement, c’est fatigant. Je comprends que Linux fasse chavirer de plus en plus de cœurs…
En attendant, vous l’aurez compris, direction Rufus pour installer Windows 11 avec un compte local. Et dépêchez-vous avant que Microsoft décide que ce sera la prochaine cible à abattre !
Comme vous le savez, Redis c’est un peu le champion du cache mémoire. C’est rapide, c’est efficace, tout le monde l’utilise mais surtout, ça tourne dans 75% des environnements cloud. En gros, 3 serveurs sur 4 dans le cloud l’utilise…
Cool ? Oui sauf quand une faille critique de sécurité pointe le bout de son nez ! Et pas une petite faille, mes amis ! Une faille notée 10 sur 10 en gravité, qui permet d’exécuter du code à distance sur les serveurs.
Estampillée CVE-2025-49844, et joliment baptisée RediShell, cette faille en elle-même est assez technique puiqu’elle repose sur un bug Use-After-Free dans l’interpréteur Lua intégré à Redis. En gros, un attaquant authentifié peut envoyer un script Lua malveillant qui vient manipuler le garbage collector, provoque un accès mémoire après libération, et permet ainsi d’exécuter du code arbitraire sur le serveur.
C’est de la RCE complète salade tomates oignons, avec sauce système compromis !
Le truc, c’est que ce bug dormait dans le code depuis 13 ans dès que Redis a intégré Lua en 2012 dans la version 2.6.0. Donc pendant tout ce temps, des millions de serveurs Redis dans le monde entier avaient cette vulnérabilité activée par défaut.
Et les chiffres donnent le vertige car d’après les scans de Wiz Research, environ 330 000 instances Redis sont exposées directement sur Internet. Et sur ces 330 000, au moins 60 000 n’ont même pas d’authentification activée. Donc autant dire qu’elles sont ouvertes à tous les vents et que les serveurs qui se cachent derrière aussi…
Toute l’infrastructure cloud moderne repose sur une poignée de briques open source critiques, et ça marche tellement bien qu’on en met partout et on finit souvent par oublier à quel point c’est fragile… On l’a déjà vu par exemple avec Log4Shell qui a touché des millions de serveurs Java en 2021, puis avec Heartbleed dans OpenSSL en 2014. Et on a failli le voir avec la backdoor XZ Utils découverte in extremis en 2024.
À chaque fois, c’est le même schéma où un composant open source critique, utilisé partout, et maintenu par une équipe minuscule (souvent 1 à 5 personnes), se retrouve avec un bug qui expose des pans entiers de l’infrastructure mondiale d’Internet… Argh !
Maintenant, la bonne nouvelle , c’est que Redis a publié des patchs pour toutes les versions maintenues : 6.2.20, 7.2.11, 7.4.6, 8.0.4 et 8.2.2. Donc si vous utilisez Redis, c’est le moment de mettre à jour !! Et pendant que vous y êtes, activez aussi l’authentification avec la directive requirepass, et désactivez les commandes Lua si vous ne les utilisez pas. Vous pouvez faire ça via les ACL Redis ou simplement en révoquant les permissions de scripting.
La découverte de RediShell a été faite par Wiz Research lors du Pwn2Own de Berlin en mai 2025. Alerté, Redis a publié son bulletin de sécurité le 3 octobre dernier, et Wiz a rendu public les détails le 6 octobre. Une Timeline propre, une divulgation responsable, bref tout s’est bien passé de ce côté-là…
Maintenant pour réduire ce genre de risque à terme, je pense que ce serait cool si les géants d’Internet finançaient un peu plus directement les mainteneurs de ces briques logiciels essentielle, ainsi que des audits de l’ OpenSSF car pour le moment, on est loin du compte ! Redis est patché, heureusement, mais on sait aussi que la prochaine faille critique dans un de ces composants critiques, c’est une nouvelle fois, juste une question de temps…
Je sais pas si vous avez vu ça hier mais Google DeepMind vient de sortir CodeMender , un agent IA qui repère et corrige automatiquement les failles de sécurité dans votre code. L’outil analyse les vulnérabilités, génère les patches, vérifie qu’ils cassent rien, et soumet le tout aux mainteneurs de projets open source.
D’après leurs premiers retours, en 6 mois, CodeMender a déjà upstreamé 72 correctifs de sécurité sur des projets qui comptent jusqu’à 4,5 millions de lignes de code.
Pour bien comprendre comment ça fonctionne, CodeMender fonctionne sur deux modes. Il y a le mode réactif qui patche instantanément les nouvelles vulnérabilités découvertes, avec de l’analyse de programme avancée et un système multi-agents qui évalue la correction sous tous les angles. Et le mode proactif qui réécrit le code existant pour utiliser des structures de données et des APIs plus sécurisées, en appliquant par exemple des annotations de compilateur comme -fbounds-safety qui ajoutent des vérifications de limites automatiques.
L’outil s’appuie sur Gemini Deep Think , l’un des modèles de raisonnement avancé de Google et CodeMender combine plusieurs techniques d’analyse : static analysis pour repérer les patterns suspects dans le code source, dynamic analysis pour observer le comportement à l’exécution, fuzzing pour balancer des inputs aléatoires et voir ce qui casse, differential testing pour comparer le code modifié avec l’original, et des solveurs SMT pour vérifier formellement certaines propriétés du code.
Le truc intéressant avec CodeMender, c’est le process de validation. L’agent utilise ce qu’ils appellent un “LLM judge” qui vérifie que le patch proposé ne casse pas les fonctionnalités existantes. Le système compare l’original et la version modifiée, détecte les différences, et valide que le changement corrige bien la vulnérabilité sans y introduire des régressions. Et si un problème est détecté, CodeMender s’auto-corrige et retente sa chance.
Par exemple, CodeMender a bossé sur la libwebp , une bibliothèque de compression d’images utilisée un peu partout. L’IA ainsi après analyse, appliqué des annotations -fbounds-safety sur certaines parties du code et quand ces annotations sont présentes, le compilateur ajoute alors automatiquement des vérifications de limites qui empêchent un attaquant d’exploiter un buffer overflow ou underflow pour exécuter du code arbitraire. Ce n’est donc pas juste un patch ponctuel, mais une vraie protection structurelle contre toute une classe de vulnérabilités.
Les 72 patches déjà soumis couvrent des projets open source variés, certains vraiment massifs avec plusieurs millions de lignes et les patches générés par CodeMender passent par une review humaine avant d’être définitivement validés. Pour le moment, les chercheurs de DeepMind contactent un à un les mainteneurs des projets pour leur proposer les correctifs mais l’objectif final c’est de sortir CodeMender sous la forme d’un outil utilisable par tous les dev.
Le process de validation de CodeMender vérifie quatre critères sur chaque patch : il doit corriger la cause racine de la vulnérabilité, être fonctionnellement correct, ne provoquer aucune régression dans les tests existants, et respecter les conventions de style du projet. C’est donc pas juste du patching bourrin, car l’outil essaie de générer du code qui s’intègre proprement dans la base existante.
Ce qui différencie CodeMender d’autres outils de static analysis classiques, c’est surtout l’autonomie complète. Des outils comme Coverity ou SonarQube sont très cools car ils détectent les vulnérabilités et vous disent où elles sont, mais c’est à vous de les corriger. Alors que CodeMender va jusqu’au bout : détection, génération du patch, validation, et soumission. Le système gère aussi la complexité de très gros projets, ce qui est pas donné à tous les outils d’analyse.
Bon, évidemment, pour l’instant Google commence prudemment mais comme je vous le disais, l’idée à terme, c’est que CodeMender tourne en continu sur vos repos, détecte les nouvelles CVE qui matchent avec votre code, génère les patches, et vous les propose directement dans vos PR. Un peu comme un Dependabot mais pour les failles de sécu…
J’ai hâte que ça sorte en public !
Vous connaissez le job de payment engineer ? Ce métier n’existait même pas il y a 3 ans et aujourd’hui, les paiements en ligne sont devenus tellement complexes qu’il existe carrément une nouvelle catégorie de développeurs… Et au centre de cette petite révolution, il y a Hyperswitch , un projet open source qui est en train de servir de base à toute une génération de spécialistes des paiements.
Sorti en 2022, Hyperswitch est une plateforme d’orchestration de paiements écrite en Rust. Le pitch marketing vous dira que c’est le “Linux des paiements”, un outil modulaire, flexible, open source, mais dans les faits, ça permet surtout de connecter votre boutique en ligne à +50 processeurs de paiement différents via une seule API… Stripe, Adyen, PayPal, tout ce que vous voulez.
Le projet est développé par Juspay, une boîte indienne qui gère déjà les paiements de 400 entreprises et traite 175 millions de transactions par jour et quand ils ont décidé d’open-sourcer leur infrastructure, ils ont vraiment tapé dans le mille ! Rien que le dépôt GitHub affiche maintenant plus de 36 000 étoiles, ce qui est assez dingue pour un outil d’infrastructure B2B.
Et cela arrive au bon moment parce que les paiements en ligne sont devenus un cauchemar technique. Entre les différents processeurs, les méthodes de paiement locales (UPI en Inde, WeChat Pay en Chine, Bancontact en Belgique), les réglementations qui changent, les taux d’autorisation qui varient selon les pays, les frais cachés qui s’accumulent et les webhooks qui plantent au pire moment, il faut vraiment être un spécialiste pour s’y retrouver.
C’est un peu ce qui s’est passé avec le terme DevOps il y a 10 ans. J’sais pas si vous vous souvenez, mais au début c’était juste un buzzword. Puis Docker et Kubernetes sont arrivés, la complexité a explosé, et boom, aujourd’hui tout le monde cherche des ingés DevOps. Même délire avec les “data engineers” quand les boîtes ont commencé à avoir des pétaoctets de données à gérer.
Hé bien les paiements suivent la même trajectoire. Vous ne pouvez plus juste intégrer Stripe et oublier le problème. Si vous faites du volume, vous devez optimiser vos coûts (car les frais peuvent varier de 1 à 3% selon le processeur), améliorer vos taux d’autorisation (parfois 5 à 10 points de différence entre processeurs), gérer le retry intelligent quand une carte est refusée, faire de la réconciliation automatique…etc.
Bref, vous avez besoin d’un spécialiste.
Et c’est exactement ce que fait Hyperswitch qui indirectement forme des ingénieurs en paiement, car quand vous passez 6 mois à bidouiller Hyperswitch , à comprendre comment fonctionne le routing intelligent ou la réconciliation automatique, vous devenez au bout d’un moment spécialiste des paiements.
C’est un peu le même coup qu’a fait Red Hat avec Linux, ou HashiCorp avec Terraform. Vous créez une communauté de gens qui connaissent votre outil à fond, et les membres de cette communauté deviennent ensuite vos meilleurs ambassadeurs et des experts d’un domaine qui recrute à tour de bras. Hyperswitch surfe donc sur cette vague en proposant son outil en self hosting pour l’auto-hébergement ou du managé qu’ils gèrent pour vous. Et c’est clairement un business model qui a fait ses preuves.
Bref, si vous êtes développeur et que vous cherchez une niche où vous spécialiser, les paiements c’est visiblement un secteur qui monte. Et comme Hyperswitch est open source, vous pouvez vous former gratuitement en installant leur stack. Au pire, vous aurez appris quelques trucs utiles et au mieux, vous découvrirez un nouveau métier…
Vous vous souvenez de cette règle de base en informatique, que je vous rabâche régulièrement, et qui dit de toujours avoir plusieurs sauvegardes de vos données critiques ?
Hé bien apparemment, le gouvernement sud-coréen a zappé ce cours, car le 26 septembre dernier, un incendie s’est produit au centre de données NIRS (National Information Resources Service) à Daejeon et a cramé 858 téraoctets de fichiers gouvernementaux . Et y’a pas de backup. Nada.
Le feu a démarré pendant une opération de maintenance sur une batterie lithium-ion dans laquelle une cellule a lâché , déclenchant ce qu’on appelle un emballement thermique… En gros, la batterie s’est transformée en bombe incendiaire et le brasier s’est propagé dans la salle serveur du cinquième étage, faisant tomber 647 services en ligne gouvernementaux d’un coup. Parmi eux, 96 systèmes critiques ont été directement détruits, et 551 autres ont été coupés préventivement pour éviter que la chaleur les bousille aussi.
Le système qui a morflé le plus, c’est G-Drive, le cloud de stockage utilisé par les fonctionnaires sud-coréens depuis 2018. Environ 750 000 employés du gouvernement central peuvent stocker leurs documents de travail dessus, mais seulement 125 000 l’utilisaient vraiment. Chacun disposait d’environ 30 Go d’espace de stockage, ce qui fait qu’au total le système contenait 858 To de données de travail accumulées sur huit ans.
Snif…
Mais attendez, je ne vous ai pas encore donné la raison pour laquelle il n’y avait aucune sauvegarde externe. En fait, leur G-Drive est conçu comme un système de stockage haute capacité, mais basse performance, et ils ont des contraintes réglementaires qui imposent un stockage exclusif sur cette plateforme afin d’éviter les fuites de données.
Autrement dit, pour se prémunir contre les risques de fuite, ils ont créé un point de défaillance unique. Bravo !
Du coup, quand l’incendie a détruit les serveurs physiques, tout est parti en fumée. Huit ans de documents de travail pour certains ministères, qui ont été complètement perdus… C’est surtout le ministère de la Gestion du Personnel qui s’est pris la claque la plus violente parce qu’il avait rendu obligatoire le stockage de tous les documents sur G-Drive uniquement. D’autres organismes comme le Bureau de Coordination des Politiques Gouvernementales, qui utilisaient moins la plateforme, ont moins souffert.
Bref, les autorités essaient maintenant de récupérer ce qu’elles peuvent depuis d’autres sources. Y’a des petits bouts de fichiers sauvegardés localement sur les ordinateurs personnels des fonctionnaires le mois précédent, les emails, les documents officiels validés et les archives papier… Bref, pour tous les documents officiels passés par des processus d’approbation formels, il y a un espoir de récupération via leur système OnNara (un autre système gouvernemental qui stocke les rapports finaux), mais pour tout le reste (brouillons, fichiers de travail en cours, notes internes…etc.) c’est mort de chez mort…
Le ministère de l’Intérieur a expliqué que la plupart des systèmes du centre de Daejeon sont normalement sauvegardés quotidiennement sur des équipements séparés dans le même centre ET dans une installation de backup distante. Mais G-Drive, lui, n’avait pas, comme je vous le disais, cette possibilité.
Évidemment, cet incident a déclenché une vague de critiques acerbes sur la gestion des données gouvernementales sud-coréennes. Un système de backup en miroir en temps réel qui duplique le serveur principal pour assurer la continuité de service en cas de panne, était complètement absent de l’infrastructure et pour un système aussi critique que le stockage de documents de 750 000 fonctionnaires, c’est difficilement compréhensible.
Voilà donc le gouvernement estime qu’il faudra jusqu’à un mois pour récupérer complètement les 96 systèmes de base directement endommagés par l’incendie et pour G-Drive et ses 858 To de données, par contre, c’est une autre histoire, car sans backup, les données sont définitivement perdues.
De plus, cet incendie déclenche actuellement un genre d’examen mondial des batteries lithium-ion dans les datacenters et des architectures de plan de reprise d’activité (PRA). Les batteries lithium-ion sont en effet utilisées partout pour l’alimentation de secours, mais leur risque d’emballement thermique en cas de défaillance pose de sérieuses questions sur leur place dans des infrastructures critiques…
Bref, je souhaite bon courage aux Coréens, et j’espère que tout le monde saura tirer des enseignements de ce malheureux incendie…
Besoin d’aller voir le profil Instagram de quelqu’un en scrèd, sans que cette personne ne le sache ? Hé bien plus besoin de vous créer un faux compte grâce à ImgInn . En effet, ce site vous laisse surfer sur Instagram de manière totalement anonyme, sans même avoir besoin de vous connecter.
Vous allez sur ImgInn, vous tapez le nom d’utilisateur Instagram qui vous intéresse, et hop, vous accédez à tout son contenu public : posts, stories, Reels, highlights et même les photos de profil. Vous pouvez ainsi mater tout ça tranquillement sans laisser de traces.
En plus de la visualisation anonyme, ImgInn permet également de télécharger tout le contenu que vous voulez. Photos en résolution originale, vidéos en HD, stories qui vont disparaître dans 24 heures, vous pouvez tout récupérer en quelques clics. Par contre, ça ne fonctionne pas avec les comptes verrouillés (non publics).
Notez quand même qu’Instagram interdit formellement dans ses conditions d’utilisation le scraping de données et l’usage d’outils tiers qui imitent les fonctionnalités de la plateforme, donc sachez le, ImgInn viole clairement les règles d’Instagram.
Mais bon, quand on veut rester anonyme, notamment auprès de Meta, la question elle est vite répondue ^^. Notez aussi que même que si le site prétend garantir votre anonymat, il collecte forcément certaines données pour fonctionner comme votre adresse IP, les comptes que vous consultez, etc. Et bien sûr, rien ne garantit que ces informations restent vraiment confidentielles ou qu’elles ne soient pas partagées avec des tiers. Donc à utiliser avec parcimonie.
Et si ImgInn vous branche pas, y’a toute une ribambelle d’autres viewers du même genre. Dumpor propose par exemple une interface assez complète avec recherche par profil, localisation ou hashtag. SmiHub sépare carrément la partie visualisation et téléchargement en deux menus. Picuki va même jusqu’à intégrer des outils d’édition de photos. Pixnoy se concentre surtout sur les Reels, et Storistalker prétend même récupérer les posts supprimés.
A voir donc… Et pour me suivre sur Instagram c’est par ici !
En octobre 2016, un développeur suisse connu sous le pseudo swisskyrepo a commencé à compiler ses notes de pentester dans un dépôt GitHub. Rien de révolutionnaire au départ, juste un mec qui en avait marre de chercher la même injection SQL pour la 50ème fois dans ses notes. Mais ce qui est cool c’est qu’au fur et à mesure des années, il a structuré ça proprement avec une section par type de vulnérabilité, des README clairs, des fichiers Intruder pour Burp Suite, des exemples concrets…etc.
Ça s’appelle Payloads All The Things, et c’est accessible ici .
Ce qui était donc au départ un simple carnet de notes personnel est devenu THE référence mondiale en cybersécurité offensive avec des centaines de contributeurs qui ajoutent quotidiennement de nouvelles techniques. C’est devenu la pierre de Rosette (pas la charcuterie, renseignez-vous !! lol) de la sécurité offensive, celle qu’on cite dans tous les cours de certification OSCP, celle qu’on consulte pendant les CTF, celle qu’on recommande aux débutants…
Avant PayloadsAllTheThings, le savoir en cybersécurité offensive était soit verrouillé dans des formations hors de prix à 5 000 boules, soit éparpillé dans des recoins obscurs du web, soit jalousement gardé par des pentesters qui pètent plus haut que leur cul… Des pêt-testeurs quoi…
SwisskyRepo a d’ailleurs fait un choix radical qui est tout mettre en open source, sous licence MIT, accessible à tous. Et le contenu, c’est du lourd !
On y trouve tout ce dont un pentester peut avoir besoin : SQL Injection avec toutes les variantes possibles (MySQL, PostgreSQL, Oracle, MSSQL…), XSS avec les bypasses de filtres, SSRF avec les techniques d’exfiltration, Command Injection, OAuth Misconfiguration, GraphQL Injection, File Inclusion, Authentication Bypasses, API Key Leaks…etc… La liste est hallucinante.
Chaque section est structurée comme un cookbook technique avec le contexte de la vulnérabilité, les payloads classés par type, les bypasses pour contourner les protections, des exemples concrets, et les références vers les CVE ou les articles de recherche.
Par exemple, si vous voulez exploiter un serveur Redis mal configuré, il y a une section pour ça. Si vous voulez comprendre comment contourner un WAF, pareil ! Et si vous cherchez à pivoter dans un réseau interne après avoir compromis une machine, tout est documenté en anglais sur ce site.
Mais swisskyrepo ne s’est pas arrêté là. Son projet a muté en écosystème puisqu’il a aussi créé InternalAllTheThings , un wiki dédié au pentesting interne et aux attaques Active Directory (Certificate Services, Enumeration, Group Policies, Kerberos attacks, Hash manipulation, Roasting techniques…).
Et également HardwareAllTheThings , le même genre de wiki mais sur la sécurité hardware et IoT : JTAG, SWD, UART pour les interfaces de debug, firmware dumping et reverse engineering, Arduino, Raspberry Pi, Flipper Zero pour les gadgets, Bluetooth, CAN, WiFi, RFID/NFC pour les protocoles, SDR et GSM pour la radio, fault injection pour les attaques par canal auxiliaire…
Bref, tout ce qu’il faut savoir pour hacker des objets connectés, des cartes à puce ou des systèmes embarqués.
Du coup, avec cette famille complète de “AllTheThings”, on couvre toute la surface d’attaque moderne, le web, l’infra interne et le hardware. Un pentest complet peut donc se faire avec ces trois ressources comme base de connaissance. Chouette non ?
Bien, sûr c’est à utiliser dans un cadre légal, sinon, vous irez en prison ! C’est pas un forum de script kiddies qui échangent des zero-days volés, c’est une vraie bibliothèque technique pour les professionnels et les étudiants en cybersécurité.
Grâce à ça, un étudiant motivé peut devenir compétent en sécurité offensive en quelques mois juste avec des ressources gratuites : PayloadsAllTheThings pour les techniques, TryHackMe ou HackTheBox pour la pratique, les blogs de chercheurs pour les analyses approfondies, les conférences enregistrées (DEF CON, Black Hat) pour rester à jour.
Le savoir se libère, n’en déplaise aux relous ! Moi je trouve que c’est cool, car ça vulgarise les connaissances, ça les mets à la portée de tous et c’est tant mieux.
Donc un grand merci à SwisskyRepo d’avoir lancé ce projet !
– Article invité, rédigé par Vincent Lautier, contient des liens affiliés Amazon –
La Logitech MX Master 4 apporte quelques ajustements bien sentis à une formule déjà très aboutie. Haptique, gestes, ergonomie : tout est là pour une expérience fluide et efficace, que ce soit sur Mac ou PC. Je l’ai testé ici sur Mac, avec un constat simple : difficile de trouver mieux.
Une évolution, pas une révolution
Avec la MX Master 4 , Logitech ne bouleverse pas sa recette. Et tant mieux. Le design reste globalement le même que celui de la 3S : une souris sculptée pour les droitiers, pensée pour épouser la main sans effort. Les matériaux ont été revus : fini les revêtements soft-touch qui s’abîment vite et étaient vite sales, place à des plastiques plus bruts mais plus durables. Les clics sont encore plus silencieux, les boutons mieux positionnés, et la glisse gagne en souplesse grâce à des patins PTFE beaucoup plus larges. C’est une mise à jour maîtrisée, centrée sur l’usage et l’optimisation.
Screenshot
L’Action Ring change la donne
La vraie nouveauté, c’est l’Action Ring. Un menu circulaire qui s’affiche autour du curseur quand on presse le nouveau bouton sous le pouce, baptisé Haptic Sense Panel. On y place jusqu’à huit raccourcis personnalisés : apps, dossiers, fonctions système… Le retour haptique, ultra satisfaisant, vient valider les actions avec une petite vibration, discrète mais efficace. Le tout s’intègre parfaitement à macOS et Windows via Logi Options+, qui permet de créer des profils différents selon les applications. À l’usage, on gagne du temps. Beaucoup.
Une personnalisation très poussée
Comme les modèles précédents, la MX Master 4 mise sur la personnalisation : sept boutons configurables, deux molettes (verticale motorisée, horizontale crantée), capteur 8 000 DPI, compatibilité multi-appareils, et désormais une couche haptique ajustable.
On peut choisir l’intensité des vibrations, désactiver certaines fonctions, ou encore créer des macros avec les Smart Actions. Pour aller plus loin, un marketplace propose des plugins selon les apps : Adobe, Zoom, Excel, Figma, etc. Peu nombreux pour l’instant, mais en développement.
Screenshot
Mac vs PC : rien de majeur
La version Mac, testée ici, se distingue surtout par ses coloris exclusifs (Space Black, White Silver). Elle est livrée sans dongle USB-C (présent sur la version PC). Mais à l’usage, aucune différence en termes de performance ou de fonctions, contrairement à la MX Master 3S qui était moins performantes en Bluetooth (perso j’avais acheté le dongle à part). Dans tous les cas, la souris est pleinement compatible avec macOS ET Windows.
Une autonomie solide et une vraie réparabilité
Côté autonomie, Logitech annonce 70 jours sur une charge complète. Et bonne nouvelle : on peut recharger tout en continuant d’utiliser la souris (contrairement à la Magic Mouse…). Autre point à noter : la facilité de démontage. Pas besoin d’arracher les patins pour accéder aux vis, et des pièces comme la batterie seront disponibles en remplacement. Une rareté sur ce segment.
On en dit quoi ?
La MX Master 4 n’est pas une révolution, mais c’est clairement une des meilleures souris du marché pour un usage pro ou créatif. Confort, silence, fluidité, personnalisation : tout y est. L’Action Ring est au final un vrai plus une fois adopté, et l’intégration au système macOS est bien pensée. Même si vous avez une 3S, ça peut valoir le coup d’investir, croyez-moi ! Reste juste à espérer qu’un jour Logitech pense aux gauchers. Elle est dispo sur Amazon en cliquant ici !
Article invité publié par Vincent Lautier . Vous pouvez aussi faire un saut sur mon blog , ou lire tous les tests que je publie dans la catégorie “Gadgets Tech” , comme cette liseuse Android de dingue ou ces AirTags pour Android !