Stuxnet : du programme informatique au sabotage de Natanz

03 / 15

Juin 2010 : un échantillon ouvre une enquête

Le 17 juin 2010, VirusBlokAda signale le programme qui sera connu sous le nom de Stuxnet. Les équipes de sécurité informatique en examinent les composants. Chez Symantec, Nicolas Falliere, Liam O Murchu et Eric Chien contribueront à un dossier détaillé. L’analyse révèle une cible industrielle précise : le logiciel cherche à modifier des automates, ces appareils qui exécutent les commandes d’une installation. [1]

Le point de départ de l’enquête est un objet que l’on peut copier, désassembler et comparer. Mais sa présence sur un ordinateur ne donne pas immédiatement son objectif final. Il faut distinguer ce qui lui permet de circuler de ce qu’il est conçu pour faire une fois arrivé au bon endroit.

04 / 15

2 août 2010 : une faille corrigée, une affaire encore ouverte

Microsoft publie le bulletin MS10-046 le 2 août. Il concerne une vulnérabilité de Windows liée au traitement des icônes de raccourcis. Le correctif est classé critique. Ce document donne un repère concret dans la réponse à l’attaque : l’éditeur corrige un mécanisme qui permet l’exécution de code indésirable. [2]

La correction répond à un problème identifié. Elle ne révèle pas, à elle seule, la destination industrielle du programme. C’est ce qui donne à Stuxnet sa double histoire : pendant qu’une partie de l’enquête traite une menace informatique, une autre doit comprendre pourquoi des commandes de machines se trouvent dans le même ensemble.

05 / 15

Le programme cherche autre chose qu’un ordinateur ordinaire

Les analyses montrent que Stuxnet recherche des configurations particulières associées à Siemens Step 7, utilisé pour programmer des automates. Il peut modifier leur code et cacher ces changements. Son activation industrielle dépend de conditions précises : une infection informatique ne signifie donc pas automatiquement que des machines sont sabotées. [1]

Cette sélection explique pourquoi compter les ordinateurs infectés et compter les équipements affectés sont deux opérations distinctes. Un programme peut circuler largement tout en réservant une action particulière à un environnement étroitement défini. La carte de sa diffusion et celle de sa cible ne se superposent pas forcément.

06 / 15

Pourquoi l’enrichissement exige aussi une enquête industrielle

Ralph Langner rapproche le code du fonctionnement de Natanz. Son analyse distingue l’ordinateur par lequel le programme circule, les systèmes de commande qu’il manipule et les machines sur lesquelles il cherche à produire un effet. Les centrifugeuses deviennent alors la clé de lecture de l’attaque. [3]

Pour comprendre le but d’un ordre informatique, il faut savoir ce que l’équipement commandé est censé faire. Une instruction peut paraître abstraite sur un écran et avoir une conséquence mécanique dans une usine. L’enquête change donc d’échelle : elle doit réunir les compétences de l’analyse logicielle et celles du fonctionnement industriel.

07 / 15

Modifier une commande et masquer sa modification

Langner décrit, pour une des séquences étudiées, l’enregistrement puis la répétition de valeurs de procédé destinées à suggérer un fonctionnement normal. Cette dissimulation accompagne la manipulation du système. Elle doit être rattachée à la version et au mécanisme analysés, plutôt que transformée en scène universelle où tous les écrans de l’usine mentent de la même manière. [3]

L’idée centrale est compréhensible sans imaginer une salle de contrôle en panique. L’information utilisée pour surveiller une machine peut elle-même être compromise. Vérifier seulement ce qu’affiche l’outil de supervision ne suffit alors plus à expliquer ce qui se déroule dans l’installation.

08 / 15

2013 : un morceau plus ancien déplace le début de l’histoire

Symantec publie en 2013 une analyse de Stuxnet 0.5. Cette version est attestée dès novembre 2007, avant la découverte publique de 2010. Elle se propage par des projets Step 7 infectés et présente une stratégie industrielle différente, liée à la manipulation de vannes. Les versions suivantes étudiées cherchent notamment à modifier la vitesse de rotation des centrifugeuses. [4]

La découverte rétrospective empêche de raconter Stuxnet comme un seul programme, apparu une seule fois avec toutes ses caractéristiques définitives. Des versions se succèdent. Elles ne possèdent pas exactement les mêmes moyens de diffusion ni la même logique d’action. Certaines dates portées par les fichiers sont, en outre, jugées peu fiables par les analystes. [4]

Un échantillon ancien peut ainsi changer une chronologie sans annoncer une nouvelle attaque. La date à laquelle les chercheurs comprennent une pièce et la date à laquelle cette pièce existait appartiennent à deux histoires différentes.

09 / 15

2014 : les entreprises intermédiaires apparaissent

L’équipe GReAT de Kaspersky revient en 2014 sur les premières organisations infectées par les variantes de 2009 et 2010. Elle examine plus de deux mille échantillons. Le ver conserve des informations sur les systèmes qu’il a traversés ; ces traces permettent de reconstituer une partie de sa propagation. [5]

Parmi les organisations identifiées figure Foolad Technic Engineering, à Ispahan, active dans les systèmes industriels. Les chercheurs s’intéressent à ce type d’entreprise parce que ses activités peuvent la rapprocher des installations visées. Être présente dans cette chaîne d’infections n’établit aucune complicité : l’entreprise est ici une victime du logiciel. [5]

Le chemin vers une installation protégée devient une question d’écosystème. Les prestataires, les échanges de projets et les ordinateurs intermédiaires comptent dans l’enquête. L’analyse ne livre toutefois pas un film continu du passage de chaque copie jusqu’à sa destination finale. Elle permet de préciser des liens, avec des degrés de certitude variables.

10 / 15

Ce que le code démontre, ce que le bilan laisse incertain

Langner souligne une limite majeure : la connaissance publique des contrôleurs effectivement infectés et des conséquences précises sur le terrain reste incomplète. Des difficultés de fonctionnement signalées à Natanz ne peuvent pas toutes être automatiquement attribuées à Stuxnet. Le code renseigne plus directement sur le mécanisme et l’intention de sabotage que sur un inventaire exhaustif des dégâts. [3]

Ce dossier ne transforme donc pas un chiffre d’ordinateurs infectés en nombre de centrifugeuses détruites. Il ne donne pas non plus de durée exacte de retard au programme nucléaire. Ces affirmations demanderaient une mesure de l’activité qui aurait eu lieu sans l’attaque, ainsi qu’un relevé fiable des effets qui lui sont réellement imputables.

11 / 15

Qui se trouve derrière Stuxnet ?

En 2012, le Washington Post attribue Stuxnet aux États-Unis et à Israël. [6]

Une attribution journalistique et une analyse technique constituent des types de preuves différents. Le code aide à comprendre les capacités d’un programme et les équipements recherchés. L’identification des décideurs et des exécutants demande d’autres sources. Raconter l’enquête suppose de conserver cette distinction, même lorsque les deux démarches concernent la même attaque.

12 / 15

Le sabotage peut commencer dans le logiciel et finir dans la matière

Au fil des analyses, l’objet découvert en 2010 devient une histoire plus longue : des versions anciennes, des entreprises intermédiaires, une cible industrielle et des procédés de dissimulation. L’enquête avance par rapprochements. Elle corrige aussi les raccourcis d’un récit où une seule clé USB, un seul écran ou un seul chiffre expliquerait tout.

Stuxnet donne ainsi une forme concrète à une question durable : comment faire confiance à une machine lorsque sa commande et une partie des informations qui la décrivent peuvent être altérées ensemble ? La réponse documentaire tient dans la confrontation des traces, des versions du programme et des connaissances du procédé. Aucun dialogue ni dernier instant d’un opérateur n’est reconstitué ici.

13 / 15

La découverte ne marque pas le début de l’opération

1. Novembre 2007 — Présence attestée d’une version ancienne, identifiée rétrospectivement.
2. 17 juin 2010 — Signalement du programme par VirusBlokAda.
3. 2 août 2010 — Publication du correctif Microsoft MS10-046.
4. Février 2011 — Version 1.4 du dossier technique de Symantec.
5. 2013 — Analyse de Stuxnet 0.5 et publication du rapport de Ralph Langner.
6. 11 novembre 2014 — Kaspersky publie ses recherches sur les premières organisations infectées.

Repères issus des publications techniques : [1] [2] [4] [3] [5]

14 / 15

Trois dossiers sur les systèmes et les traces

• 28 • Anadarko Twister | La tornade monstrueuse de l’Oklahoma 🌪️ 🇺🇸 ⚙️

  Pour une autre enquête où il faut confronter des mesures, des images et les effets réellement observés.

• 12 • L’étrange incident du sous-marin Ming 361 | Sous-marins sans retour ⚓ 🇨🇳 ❓

  Un drame qui demande de comprendre le fonctionnement d’un système technique avant de raconter son enchaînement.

• 27 • Sous-marins sans retour | Les disparus des abysses ⚓ 🇦🇷 🌊

  Des enregistrements instrumentaux et une épave retrouvée : deux types de traces qui ne répondent pas seuls à toutes les questions.

15 / 15

Sources, méthode et crédits

Récit documentaire original de L’envers de l’affaire, publié le 14 septembre 2026. Les analyses techniques sont privilégiées pour les mécanismes et la chronologie. Leurs hypothèses d’introduction, de stratégie et d’impact sont distinguées des observations. Plusieurs rapports partagent des échantillons ou des résultats : leur nombre ne vaut pas autant de confirmations indépendantes.

1. Symantec — W32.Stuxnet Dossier, version 1.4

   Février 2011. Nicolas Falliere, Liam O Murchu et Eric Chien. Analyse technique primaire : chronologie de découverte, propagation, cible industrielle et dissimulation du code. Le scénario d’introduction présenté par les auteurs est explicitement hypothétique.

2. Microsoft — bulletin de sécurité MS10-046

   2 août 2010, révisé le 24 août. Bulletin primaire concernant une vulnérabilité de Windows employée dans la propagation. Cité comme document historique, sans procédure d’exploitation.

3. Ralph Langner — To Kill a Centrifuge

   Novembre 2013. Analyse technique primaire, conservée ici dans une copie d’archive. Mécanismes industriels et limites de l’évaluation des effets réels. Les interprétations stratégiques de l’auteur ne sont pas traitées comme des faits établis.

4. Symantec — Stuxnet 0.5: The Missing Link

   2013. Analyse primaire d’une version antérieure à celles rendues publiques en 2010. Différences de propagation et de stratégie industrielle ; découverte rétrospective d’échantillons anciens.

5. Kaspersky GReAT — Stuxnet: Zero victims

   11 novembre 2014. Recherche technique primaire sur les organisations initialement infectées et les traces de propagation conservées dans les échantillons. Les entreprises citées sont des victimes de l’infection.

6. Washington Post — Stuxnet

   Enquête de presse, 2012.

7. L’envers de l’affaire — épisode 29 sur Spotify

   28 juin 2026 ; 55 min 02 s. Titre exact, numéro, séparateur, émojis, durée et lien repris du catalogue enregistré, vérifié le 13 septembre 2026.

Crédit visuel : illustration générée par IA spécialement pour ce dossier : poste de commande ancien, cylindres et tuyauterie derrière une vitre, ambiance industrielle froide. Scène fictive, sans texte ni personnage ; aucune explosion ou photographie de Natanz n’est représentée. Le titre et les métadonnées Spotify sont conservés d’après le catalogue enregistré.