Analyse de risque : 858 TB de données gouvernementales perdues en Corée du Sud

Je suis tombé sur cette info fin septembre, et j’ai failli recracher mon cappuchino.

Daejeon, Corée du Sud, 26 septembre 2025. Un datacenter gouvernemental part en fumée. Le bilan ? 858 téraoctets de données perdues. Définitivement.

191 000 fonctionnaires découvrent que jusqu’à 8 ans de travail viennent de disparaître. 96 systèmes critiques détruits, 647 autres mis hors ligne.

La cause ? Une batterie d’onduleur (UPS - le système de secours qui prend le relais en cas de coupure électrique) mal branchée pendant une maintenance de routine.

Oui, vous avez bien lu. Pas de cyberattaque sophistiquée. Pas de groupe de hackers nord-coréens. Une batterie de secours. Mal. Branchée.

Temps de récupération estimé : au moins un mois. Si récupération il y a.

Comment on passe d’un incident technique à une catastrophe nationale Link to heading

Erreur n°1 : Tout miser sur un seul datacenter Link to heading

Le G-Drive centralisait les documents de travail de milliers d’agents de l’État. Choix justifié par la sécurité et le contrôle, évidemment. Un système unique, c’est plus facile à sécuriser, à maintenir, à auditer.

Sauf que. Conséquence non anticipée (ou ignorée ?) : un point de défaillance unique pour des centaines d’organisations gouvernementales.

Le NIRS (National Information Resources Service), c’est la fondation des services e-gouvernement et du cloud gouvernemental sud-coréen. Détruire le G-Drive, c’est effacer la mémoire de travail de pans entiers de l’administration.

Le backup était là… dans le même bâtiment qui a brûlé Link to heading

Des backups existaient. Dans le même bâtiment, sur un étage différent. Conformes aux procédures pour les autres systèmes du datacenter.

Vous voyez le problème ?

Justification officielle : “la structure du système ne permettait pas de backups externes”. Le G-Drive n’avait jamais été sauvegardé en dehors du site.

Traduction : personne n’a voulu prendre la décision difficile. Entre “c’est complexe techniquement” et “on met en danger une infrastructure nationale”, quelqu’un aurait dû trancher. Personne ne l’a fait.

Batteries lithium-ion : quand la maintenance tourne au cauchemar Link to heading

L’incendie n’était pas un acte de sabotage sophistiqué. Une batterie lithium-ion mal reconnectée lors d’une relocalisation d’onduleur. Opération de maintenance standard. Erreur humaine prévisible.

Rappel technique : un onduleur (UPS), c’est la grosse batterie qui maintient les serveurs allumés pendant une coupure de courant. Le temps que les générateurs diesel démarrent, ou que les serveurs s’éteignent proprement. Dans un datacenter, c’est critique : sans UPS, une micro-coupure de 0.5 seconde peut corrompre des bases de données entières.

La séquence technique Link to heading

  1. Défaut de connexion : court-circuit, compression de cellules, mauvais contact générant une résistance élevée et chaleur, ou étincelle lors de la reconnexion sous charge.

  2. Emballement thermique : les batteries lithium-ion réagissent violemment aux défauts. La température monte rapidement (300-500°C). Les électrolytes s’évaporent et deviennent inflammables. La batterie s’auto-alimente en oxygène via réaction chimique interne. Les batteries adjacentes s’embrasent à leur tour.

  3. Incendie incontrôlable : l’eau et le CO₂ sont inefficaces. La réaction est chimique, pas une combustion classique. Les systèmes d’extinction automatique (halon, gaz inerte) ne fonctionnent pas sur ce type d’incendie. La seule méthode : refroidissement massif à l’eau sur plusieurs heures.

  4. Propagation : les UPS sont généralement placés au bas des racks ou en salles adjacentes (contrainte de poids). Un incendie d’UPS peut détruire des rangées entières de serveurs avant que la réponse incendie soit efficace.

Le point de conception critique : les datacenters modernes séparent physiquement les salles batteries des salles serveurs avec isolation coupe-feu de 2-4 heures minimum. Le NIRS ne semble pas avoir appliqué cette séparation, ou l’isolation a été insuffisante.

OVH Strasbourg, mars 2021 : déjà vu Link to heading

Quand j’ai lu les détails de l’incident NIRS, j’ai immédiatement pensé à OVH. Parce que c’est presque le même scénario.

10 mars 2021, 00h40, Strasbourg. Le datacenter SBG2 d’OVH part en fumée.

Les similitudes sont troublantes :

  • La cause : UPS entretenus le matin même par le fournisseur. Chez OVH, le technicien avait changé “beaucoup de pièces” dans l’UPS7. Quelques heures plus tard : incendie.
  • La propagation : destruction complète en quelques minutes. Le temps que les pompiers arrivent, c’était déjà trop tard.
  • L’intervention : 100 pompiers, 44 véhicules, 6 heures pour maîtriser l’incendie.
  • Les dégâts collatéraux : des milliers de sites offline. Le jeu vidéo Rust a perdu 25 serveurs EU. Perte totale, récupération impossible.

Mais il y a une différence majeure.

Chez OVH :

  • Campus de 4 datacenters (SBG1, SBG2, SBG3, SBG4)
  • SBG2 détruit, mais SBG3 et SBG4 opérationnels
  • Les clients qui avaient des backups ailleurs ? Récupération en 48-72h
  • Les clients sans plan de secours ? Perte totale

En Corée :

  • Un seul datacenter. Point.
  • Aucun backup hors-site
  • Résultat : 191 000 fonctionnaires dans le mur

L’ironie, c’est que la Corée du Sud a plusieurs datacenters gouvernementaux. Ils auraient pu faire des backups externes. Ils ne l’ont juste… pas fait.

Ce que ces deux incidents nous apprennent : la maintenance des UPS est un moment critique. OVH : intervention le matin, incendie la nuit. NIRS : relocalisation d’UPS, connexion défectueuse, incendie.

C’est pas les cyberattaques qui mettent les datacenters à genoux. C’est les opérations de routine mal exécutées.

Le défi du volume : pourquoi la restauration prend des semaines Link to heading

858 TB représentent un volume qui expose brutalement les limites de l’infrastructure :

  • Sur un seul disque HDD moderne (270 MB/s) : 40 jours de transfert continu
  • Sur un array de 30 disques HDD en parallèle (7 500 MB/s) : 32 heures en théorie
  • Dans un datacenter gouvernemental typique avec réseau 10-40 Gbps et stockage distribué : plusieurs jours à plusieurs semaines en pratique

La différence entre théorie et pratique ? Les goulets d’étranglement réseau, la contention des ressources, les vérifications d’intégrité, la reconstruction des métadonnées, et le fait qu’un datacenter ne peut pas dédier 100% de sa bande passante à une seule opération de restauration.

Un test de restauration aurait révélé cette impossibilité pratique de récupérer rapidement après sinistre majeur. À 858 TB, le temps de restauration n’est plus un détail technique, c’est un problème stratégique.

La récupération ? Partielle. Au mieux. Link to heading

Le système Onnara (intranet gouvernemental séparé) conserve certains documents officiels. Cette redondance involontaire limite les dégâts pour les rapports finaux et archives officielles. Un coup de chance.

Mais les documents de travail ? Les brouillons ? Les analyses intermédiaires ? Les échanges par email ? Perdus.

Exactement le type de données qu’on ne peut pas reconstruire. Le genre de contenu qui n’existe que dans la tête des gens et dans leurs fichiers de travail. Disparu.

Le risque était-il vraiment imprévisible ? Link to heading

Non. Et c’est ça qui me dérange.

Matrice de risque : où se situait le NIRS ? Link to heading

Si on prend une matrice de risque classique et qu’on positionne le NIRS dessus :

Probabilité d’incident UPS : MOYENNE

  • On documente 2 à 3 incendies majeurs de datacenter par an
  • OVH en 2021, NIRS en 2025, Samsung SDI…
  • Les batteries lithium-ion (qui remplacent progressivement le plomb-acide) ont un risque d’emballement thermique plus élevé
  • Les opérations de maintenance sur les UPS sont documentées comme opérations à risque

Pour 1000 datacenters, on peut s’attendre à un incident majeur tous les 5-10 ans.

Impact sans backup externe : CATASTROPHIQUE

  • 858 TB perdus définitivement
  • 191 000 utilisateurs impactés
  • 1 mois minimum de récupération
  • Services gouvernementaux critiques hors ligne
MATRICE DE RISQUE - Infrastructure critique gouvernementale

                    IMPACT
                    │ Faible │ Moyen │ Élevé │ Catastrophique
────────────────────┼────────┼───────┼───────┼───────────────
Probabilité ÉLEVÉE  │   🟡   │  🟠   │  🔴   │      🔴🔴
Probabilité MOYENNE │   🟢   │  🟡   │  🟠   │      🔴       ← NIRS ici
Probabilité FAIBLE  │   🟢   │  🟢   │  🟡   │      🟠

🟢 Risque acceptable   🟡 Risque à surveiller
🟠 Risque à mitiger    🔴 Risque inacceptable

Résultat : Probabilité MOYENNE × Impact CATASTROPHIQUE = Zone rouge

Le genre de risque qu’on ne laisse jamais traîner quand on gère une infrastructure critique. Le genre de risque qui devrait déclencher des mesures immédiates.

Pour une infrastructure gouvernementale critique, le seuil de tolérance devrait être “zone jaune” maximum.

Le NIRS opérait en zone rouge. Sans filet.

Le bilan concret Link to heading

Financier : le coût de reconstruction des données n’a pas été chiffré publiquement. Probablement parce que c’est embarrassant et aussi parce que c’est trop récent.

Opérationnel : 647 systèmes hors ligne. Des services critiques interrompus. La carte nationale de bonheur (aide aux frais de garde d’enfants) ? Offline. Les documents des PME ? Inaccessibles.

Politique : crise majeure. Démissions dans la chaîne de commandement. Le genre de catastrophe qui fait tomber des têtes.

Temps de récupération : minimum 1 mois. Pour une restauration partielle. Pas complète. Partielle.

Comment analyser ce genre de risque dans votre organisation Link to heading

Identifier vos points de défaillance uniques (SPOF) Link to heading

Un système est aussi résilient que son maillon le plus faible. Questions à poser :

  • Si ce composant disparaît cette nuit, quelles fonctions cessent immédiatement ?
  • Combien de temps pour restaurer avec les moyens actuels ? (ici : 1 mois minimum)
  • Combien d’entités dépendent de ce composant ? (ici : 647 systèmes)
  • Existe-t-il une redondance involontaire comme Onnara ?

Tester la résistance aux erreurs banales Link to heading

Le G-Drive n’a pas été détruit par une cyberattaque sophistiquée ou une catastrophe naturelle.

Une batterie mal branchée pendant une maintenance.

Si votre stratégie de résilience suppose que personne ne fera jamais d’erreur lors d’une opération de routine, vous n’avez pas de stratégie. Vous avez une prière.

Questions spécifiques pour datacenters avec batteries lithium-ion Link to heading

  • Les batteries sont-elles physiquement séparées des serveurs ?
  • L’isolation coupe-feu est-elle classée minimum 2 heures ?
  • Les systèmes d’extinction sont-ils adaptés aux incendies chimiques ?
  • Les protocoles de maintenance incluent-ils des vérifications post-intervention ?

Évaluer la résilience géographique Link to heading

La règle 3-2-1 (3 copies, 2 supports, 1 hors-site) n’est pas une best practice. C’est le minimum vital.

Distance minimale hors-site : 100 km. Après l’incident OVH Strasbourg 2021, certains secteurs ont adopté une règle de 50+ miles héritée du 11 septembre 2001 (destruction simultanée des deux tours du WTC avec backups dans la tour adjacente).

Tester la restauration, pas juste le backup Link to heading

Un backup non testé n’existe pas.

J’ai vu trop d’entreprises découvrir pendant un sinistre que leurs bandes étaient corrompues, que leurs clés de chiffrement étaient inaccessibles, ou que le temps de restauration dépassait leur fenêtre de survie économique.

La Corée du Sud vient de découvrir que restaurer 858 TB prendra au minimum un mois. Et ne sera que partiel.

Ils l’auraient su s’ils avaient testé ne serait-ce qu’une fois.

Leçons transférables Link to heading

Pour les organisations publiques Link to heading

J’entends souvent l’argument de la souveraineté des données pour justifier l’absence de redondance géographique.

La Corée du Sud dispose de plusieurs datacenters gouvernementaux domestiques. Ils auraient pu faire des backups externes sans jamais sortir les données du territoire. Ils ne l’ont pas fait.

La souveraineté des données, c’est important. Perdre 858 TB de données gouvernementales, c’est pire.

Le système Onnara (séparé par accident, pas par design) a sauvé les meubles pour les documents officiels. La redondance par conception, c’est quand même mieux que compter sur la chance.

Pour les organisations privées Link to heading

La taille ne protège pas. 858 TB de stockage matériel coûtent environ 25 000$ en équipement (disques seuls). Moins qu’un véhicule de fonction.

Le coût n’est jamais l’obstacle réel. C’est la complexité organisationnelle et l’absence d’arbitrage sur les priorités.

Et puis il y a l’effet domino. 96 systèmes détruits directement, 647 systèmes affectés. Un datacenter moderne, c’est des centaines de systèmes interdépendants. Quand l’un tombe, il n’est jamais seul.

Risque émergent : batteries lithium-ion Link to heading

Les datacenters remplacent progressivement les batteries plomb-acide par du lithium-ion. Densité énergétique supérieure, moins d’encombrement, c’est logique économiquement.

Sauf qu’on introduit un nouveau profil de risque. Les incendies de batteries lithium-ion :

  • Sont plus difficiles à détecter avant qu’il soit trop tard
  • Ne s’éteignent pas avec les systèmes traditionnels (l’eau et le CO₂ sont inefficaces)
  • Se propagent de rack en rack en quelques minutes
  • Génèrent une chaleur intense (500°C vs 200°C pour un incendie électrique classique)

La séparation physique batteries/serveurs n’est plus une bonne pratique. C’est le minimum vital.

Pour les décideurs : 5 questions qui fâchent Link to heading

  1. Vos backups sont testés quand, exactement ? Si la réponse n’est pas “au moins une fois par an, en conditions réelles”, vous n’avez pas de backup. Vous avez une copie Schrödinger : elle existe et n’existe pas tant que vous n’avez pas vérifié.

  2. Si votre site principal disparaît cette nuit, vous reprenez l’activité en combien de temps ? Si la réponse dépasse 72h, ou pire, si vous ne savez pas… vous avez un problème.

  3. Une erreur humaine pendant une maintenance peut-elle tout détruire ? Si oui : pourquoi ?

  4. Vos batteries UPS sont où, physiquement ? Si elles sont dans la même salle que vos serveurs, vous êtes à un incident NIRS de distance.

  5. Qui peut dire “non” ? Qui dans votre organisation a l’autorité pour bloquer un projet parce que la résilience est insuffisante ? Si la réponse est “personne” ou “je ne sais pas”… vous avez trouvé votre risque systémique.

Ce qui me dérange vraiment dans cette histoire Link to heading

858 téraoctets ne partent pas en fumée par manque de budget.

Un backup externe pour ce volume ? Selon la solution :

  • Cloud chiffré : 900 à 20 000$/mois
  • Second datacenter domestique : ~50 000$ initial
  • Bandes LTO-9 avec rotation hors-site : ~100 000$ première année

La Corée du Sud a des datacenters gouvernementaux disponibles. Le budget existait.

Le problème, c’est qu’à aucun moment, personne n’a dit “stop”.

Personne n’a levé la main pour dire “attendez, on est en train de jouer à la roulette russe avec une infrastructure critique nationale”. Personne n’a eu l’autorité, ou le courage, de bloquer la mise en production sans plan de backup externe.

Je vois ça régulièrement en accompagnement. Des DSI qui me disent “on n’a pas le budget pour la redondance”. Mais le budget existe toujours quand il s’agit d’acheter de nouvelles licences ou de refaire le site web corporate.

Le budget n’était pas le problème. C’était l’arbitrage qu’on n’a jamais fait.

La vraie question : dans votre organisation, qui a le pouvoir de dire “non, on ne met pas ça en prod sans plan B” ?

Et surtout : est-ce qu’ils l’exercent ?

Parce que 191 000 fonctionnaires coréens viennent d’apprendre ce qui se passe quand la réponse est “non”.

Sources Link to heading

Incident NIRS Corée du Sud (2025) Link to heading

  1. Korea JoongAng Daily (1er octobre 2025) - “NIRS fire destroys government’s cloud storage system, no backups available” https://koreajoongangdaily.joins.com/news/2025-10-01/national/socialAffairs/NIRS-fire-destroys-governments-cloud-storage-system-no-backups-available/2412936

  2. Korea Herald (article destruction) - “G Drive was among the 96 systems confirmed to have been directly destroyed” https://www.koreaherald.com/article/10588068

  3. Korea Herald (article récupération) - Cause UPS et timeline “at least a month” https://www.koreaherald.com/article/10585931

  4. Gigazine (6 octobre 2025) - “858TB of data stored” https://gigazine.net/gsc_news/en/20251006-nirs-fire-destroys-government-cloud-storage-no-backups/

Incident OVH Strasbourg (2021) Link to heading

  1. BEA-RI - Rapport officiel d’investigation (mai 2022) - “Investigation report on the fire within the OVH data storage located in Strasbourg” (MTE-BEARI-2022-005) https://regmedia.co.uk/2022/06/10/ovh_report.pdf

  2. Uptime Institute (2021) - “Learning from the OVHcloud data center fire” - Analyse technique et leçons par l’organisme de référence mondial des datacenters https://journal.uptimeinstitute.com/learning-from-the-ovhcloud-data-center-fire/

  3. DataCenter Dynamics (mars 2021) - “OVH fire: Octave Klaba says UPS systems were ablaze” - Déclarations officielles du fondateur OVH sur la cause UPS https://www.datacenterdynamics.com/en/news/ovh-fire-octave-klaba-says-ups-systems-were-ablaze/