Quand un appel stoppe la production automobile

Le 31 août 2025, les systèmes chez Jaguar Land Rover ont commencé à se comporter de façon étrange. Quelques jours plus tard, la production s’est arrêtée. Pendant cinq semaines, presque plus rien n’a fonctionné dans les usines en Angleterre, en Slovaquie et au Brésil. Ce n’est pas un robot chiffré ni un système de contrôle détourné qui en est à l’origine, mais une panne de l’IT dont dépend toute la fabrication. Ce cas montre comment une attaque contre l’IT de bureau peut paralyser toute une production et sa chaîne d’approvisionnement.

Le contexte

Jaguar Land Rover est le plus grand constructeur automobile du Royaume-Uni et fabrique sur plusieurs sites en Angleterre ainsi que dans des usines en Slovaquie et au Brésil. Comme c’est l’usage dans l’industrie automobile, la production est étroitement synchronisée et repose sur une chaîne de données continue. Les commandes, l’approvisionnement en pièces, la logistique et le pilotage des lignes de production transitent par des systèmes informatiques qui doivent être disponibles en permanence. Si cette chaîne cède en un point, la ligne s’arrête.

C’est précisément cette dépendance qui rend les constructeurs vulnérables. Un attaquant n’a pas besoin de prendre le contrôle des automates programmables d’une ligne de fabrication pour causer des dommages. Il suffit de rendre les systèmes IT inopérants, sans lesquels aucune commande n’est enregistrée et aucune pièce n’est fournie. L’attaque contre JLR est un cas d’école de cette vulnérabilité, car elle n’a pas ciblé le pilotage de la production, mais le réseau administratif, entraînant avec lui l’arrêt de la fabrication.

Le déroulement

Fin août 2025, les premières irrégularités ont été constatées sur un site britannique. Le 1er septembre, JLR a arrêté la production par précaution et renvoyé une grande partie du personnel chez lui. On parlait initialement d’une brève interruption. Mais l’analyse de l’incident et la reconstruction propre des systèmes ont pris du temps.

Le 23 septembre, l’entreprise a prolongé l’arrêt de la production jusqu’en octobre. Ce n’est qu’autour du 22 octobre que certains processus de fabrication ont redémarré, de manière progressive et contrôlée. Entre le premier arrêt et la reprise lente, il s’est écoulé environ cinq semaines. Pendant ce temps, l’un des principaux acteurs industriels du pays n’a pratiquement rien produit, avec des conséquences immédiates pour des centaines de fournisseurs qui vivent des commandes de JLR.

Comment les attaquants sont entrés

Selon des analyses de sécurité concordantes, l’attaque n’a pas commencé par une faille technique, mais par une tromperie. Il est fait état d’une campagne de vishing, c’est-à-dire d’appels téléphoniques au cours desquels les attaquants se sont fait passer pour le support informatique interne et ont incité les employés à divulguer leurs identifiants. Avec des noms d’utilisateur et mots de passe valides, ils ont ensuite accédé au réseau via le VPN.

Les analyses mentionnent également des identifiants anciens dérobés via des malwares Infostealer et l’abus de jetons d’accès permettant de contourner l’authentification multifacteur. Tous les détails ne peuvent pas être confirmés de l’extérieur de manière définitive. Le schéma est cependant clair : pas d’exploit zero-day, mais des identités valides, un accès distant et le contournement de seconds facteurs faibles. Un groupe se faisant appeler Scattered Lapsus$ Hunters a revendiqué l’attaque.

La réaction

JLR a choisi de ne pas redémarrer rapidement mais d’opter pour une reconstruction contrôlée. Les systèmes ont été analysés, nettoyés et redémarrés par étapes, plutôt que de forcer la production dans l’incertitude. Cette approche prend du temps, mais empêche les attaquants de rester dans le réseau ou que des systèmes compromis causent à nouveau des dommages.

L’ampleur de l’arrêt a dépassé l’entreprise. Comme des centaines de fournisseurs dépendent directement de JLR, toute la chaîne d’approvisionnement a été mise sous pression. Le gouvernement britannique est intervenu et a soutenu les fournisseurs pour éviter les faillites et des dommages durables à la base industrielle. Un simple incident informatique est ainsi devenu un sujet de politique économique.

Les enseignements

Le premier enseignement concerne l’identité. L’intrusion a réussi via de l’ingénierie sociale et des identifiants valides, et non par une vulnérabilité logicielle. Un helpdesk qui effectue des réinitialisations et des validations sans vérification rigoureuse de l’identité est une porte ouverte. Des méthodes résistantes au phishing comme FIDO2 et une vérification stricte auprès du support réduisent nettement ce risque, car des mots de passe volés ne suffisent alors plus à eux seuls.

Le deuxième enseignement porte sur la séparation entre l’IT et la production. Si une panne dans le réseau administratif entraîne l’arrêt de la fabrication, c’est qu’il manque de la segmentation. Les réseaux de production doivent être strictement séparés du réseau bureautique, avec des points de passage définis et un mode de secours préparé permettant aux lignes de continuer à fonctionner pendant une durée limitée sans l’IT centrale. Cette capacité détermine si un incident coûte des heures ou des semaines.

Le troisième enseignement concerne la chaîne d’approvisionnement. L’arrêt chez JLR montre à quel point un seul constructeur soutient tout un réseau de fournisseurs. C’est précisément là que NIS2 intervient avec son obligation de sécurité de la chaîne d’approvisionnement. Quiconque fait partie d’une telle chaîne doit considérer sa propre résilience comme une contribution à la résilience de l’ensemble du réseau, et non comme une question purement interne.

Questions fréquentes

Chaque question est verrouillée. Un tapotement déverrouille la réponse.

Les choix de la rédaction

À lireSüdwestfalen-IT : la leçon de l’IT communaleÀ lireMFA adaptative : levier NIS2 zéro-trust PME

Plus du réseau MBF Media

MyBusinessFutureLa surveillance de l’IA en Allemagne a maintenant une adresse