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…

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.

Donc autrement dit, pour se prémunir contre les risques de fuite, ils ont créé un point de défaillance unique. Et comme y’avait pas de backup, c’est la cata… 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…

Source

J’sais pas vous, mais moi quand je vois Claude Code ou Cursor pondre du code avec des injections SQL grosses comme des maisons, j’ai envie de pleurer. Le pire, c’est que ces assistants IA sont incapables de vérifier si leur code est bien sécurisé. La plupart du temps ils pissent de la ligne, mais ils ne voient rien en. ce qui concerne d’éventuelles failles.

Du coup la bonne nouvelle, c’est l’arrivée de cet outil génial pour résoudre ce problème : TheAuditor . En gros, c’est une plateforme SAST (Static Application Security Testing) pensée dès le départ pour fonctionner avec les assistants IA.

L’idée c’est qu’au lieu d’avoir une IA qui code dans le vide, TheAuditor lui donne des yeux pour voir ce qu’elle fait vraiment. L’outil analyse le code, trouve les failles de sécurité (il détecte le Top 10 de l’OWASP, les injections, les problèmes d’authentifications…etc), et génère des rapports optimisés pour que l’IA puisse ensuite les comprendre et corriger ses erreurs toute seule.

Et surtout, ça fonctionne avec N’IMPORTE QUEL assistant IA. Pas besoin d’intégration spéciale, pas de SDK, rien. Vous demandez juste à votre IA de lancer aud full (ou vous le lancez vous-même) et elle lit les résultats dans .pf/readthis/. Que vous utilisiez Claude, Cursor, Codex, Windsurf ou Copilot, ça marche pareil.

L’installation est super simple. Vous clonez le repo dans ton dossier d’outils (pas dans votre projet !), vous faites un

pip install -e .

et c’est parti.

Ensuite dans votre projet, vous lancez :

aud setup-claude --target .

puis vous l’initialisez avec :

aud init

et enfin :

aud full

pour avoir votre audit complet.

TheAuditor fait tourner 14 phases d’analyse en parallèle. Ça va de la détection des frameworks (Django, Flask, React…) à l’analyse des dépendances, en passant par le suivi du flux de données pour identifier les points d’injection. Il génère même des graphiques de dépendances avec Graphviz pour visualiser l’architecture de ton code.

Un truc “marrant” que le créateur mentionne dans son projet, c’est que son outil déclenche les antivirus ! Donc c’est pas la peine de m’écrire pour me dire que votre antivirus random à la période d’essai expirée a détecté un grave danger et que vous êtes vachement déçu parce que Korben.info c’est devenu de la merde, et que vous allez portez plainte parce qu’à cause de moi, y’a un virus dans votre imprimante maintenant et ce genre de conneries ^^. C’est normal en fait parce que l’outil doit détailler les vulnérabilités qu’il trouve dans la documentation. Et pour l’antivirus, écrire des patterns de vulnérabilités détectées, c’est suspect. Mais bon, c’est le prix à payer pour avoir un vrai scanner de sécurité.

Le workflow maintenant avec ce truc, ça consiste donc à demander une fonctionnalité à votre assistant IA. Lui, en bonne victime, il la code, puis lance TheAuditor automatiquement, lit ensuite le rapport, corrige les problèmes de sécurité, relance TheAuditor pour vérifier que tout est OK, et ainsi de suite jusqu’à ce que ce soit clean. Comme ça plus besoin de toucher au terminal, l’IA gère tout.

Pour les refactorings, c’est également du bonheur puisque l’outil détecte automatiquement les migrations incomplètes, les incompatibilités d’API entre frontend et backend, les changements de modèles de données mal propagés. Vous pouvez même définir vos propres règles de corrélation dans /correlations/rules/.

Voilà, si vous en avez marre que vos assistants IA génèrent du code troué et que vous voulez dormir tranquille, TheAuditor pourrait bien devenir votre meilleur pote.