Quand un ver IA traverse votre SI sans demander la permission : retour sur une crise industrielle européenne

# Quand un ver IA traverse votre SI sans demander la permission : retour sur une crise industrielle européenne

Il ne s'agissait pas d'un ransomware classique. Pas d'un phishing maladroit. Ni d'un script kiddie cherchant à faire parler de lui. Ce qui a frappé cette ETI industrielle de 800 salariés, quelque part en Europe centrale, au printemps 2026, ressemble à ce que les équipes de réponse à incident commencent à appeler entre elles un « ver cognitif » : un agent autonome capable de raisonner sur son environnement, d'adapter sa stratégie de propagation en temps réel, et de rester dormant le temps nécessaire pour ne pas déclencher d'alerte.

J'ai eu accès aux grandes lignes de cet incident via les équipes d'un intégrateur de sécurité européen impliqué dans la remédiation. Les noms sont tus. Les leçons, elles, méritent d'être dites à voix haute.

Ce qui s'est passé, concrètement

L'ETI en question fabrique des équipements mécaniques de précision. Elle a, comme beaucoup d'industriels européens de cette taille, opéré une migration progressive vers le cloud au cours des trois dernières années. Pas une transformation radicale — une accumulation de décisions pragmatiques, service par service, département par département. Résultat : un SI hybride, avec une partie des workloads hébergés chez un opérateur américain dominant, la messagerie et la gestion documentaire également côté américain, et quelques briques métier encore on-premise.

Le ver est entré par une API exposée — un connecteur entre un outil de gestion de production et une plateforme SaaS tierce. Une fois à l'intérieur, il n'a pas cherché à chiffrer ou à exfiltrer immédiatement. Il a observé. Pendant plusieurs jours, il a cartographié les flux, identifié les comptes à privilèges élevés, repéré les plages horaires de faible activité des équipes IT. Puis il a agi : escalade de privilèges, déplacement latéral, et finalement exfiltration silencieuse de données de R&D vers une infrastructure externe.

La détection n'est venue que tardivement, grâce à une anomalie de comportement réseau relevée par un analyste — pas par un outil automatisé. Le RSSI de l'entreprise me l'a dit sans détour : *« Nos outils de détection étaient calibrés pour des menaces connues. Ils n'avaient pas été conçus pour reconnaître un comportement d'exploration intelligente. »*

Le vrai problème : ce n'est pas la menace, c'est l'architecture de dépendance

On pourrait s'arrêter à la dimension technique. Ce serait une erreur. Ce que cet incident révèle, c'est un problème structurel que je pense être l'un des angles morts les plus dangereux pour les DSI européens aujourd'hui : la dépendance technologique crée des surfaces d'attaque que vous ne contrôlez pas — et sur lesquelles vous n'avez aucun levier contractuel réel.

Voici ce que l'équipe de remédiation a découvert : plusieurs des briques en cause dans la propagation du ver étaient hébergées chez des opérateurs américains. Les logs nécessaires à la reconstitution de la chronologie d'attaque étaient, pour une partie d'entre eux, soumis à des délais d'accès contractuels qui ont ralenti l'investigation de plusieurs jours. Certaines configurations de sécurité étaient verrouillées au niveau de la plateforme — impossibles à modifier sans passer par le support du fournisseur américain, avec des délais de réponse incompatibles avec une gestion de crise.

Autrement dit : l'ETI ne disposait pas de la visibilité complète sur son propre système d'information au moment où elle en avait le plus besoin.

C'est là que la question de souveraineté numérique cesse d'être un débat politique abstrait pour devenir une réalité opérationnelle brutale. Quand vous sous-traitez l'hébergement, le traitement des logs et la gestion des identités à un acteur américain, vous sous-traitez aussi une partie de votre capacité de réponse à incident. Ce n'est pas une opinion. C'est ce qui s'est passé.

Ce que les acteurs européens peuvent apporter — et ce qu'il faut leur demander

Je ne suis pas de ceux qui pensent qu'il suffit de « passer en souverain » pour régler le problème. La souveraineté numérique n'est pas un label magique. Mais je pense que cet incident illustre précisément pourquoi le choix du partenaire technologique n'est pas seulement un choix financier ou fonctionnel : c'est un choix de gouvernance.

Deux choses me semblent essentielles à retenir ici.

Première chose : la portabilité des logs et des données d'audit est un critère de sécurité, pas un détail contractuel. Lors du renouvellement ou de la sélection d'un hébergeur ou d'un éditeur SaaS, les RSSI européens doivent exiger, noir sur blanc, la capacité à exporter en temps réel l'intégralité des journaux d'événements vers un SIEM qu'ils maîtrisent. Des acteurs comme Outscale — la branche cloud souverain de Dassault Systèmes — ou d'autres opérateurs qualifiés SecNumCloud proposent des engagements contractuels sur ce point que les grands opérateurs américains ne peuvent pas offrir, ne serait-ce qu'en raison de leurs obligations légales domestiques (Cloud Act, FISA).

Deuxième chose : les outils de détection doivent évoluer vers la reconnaissance de comportements, pas seulement de signatures. Les vers autonomes de nouvelle génération ne ressemblent pas aux menaces pour lesquelles la plupart des SOC européens ont été dimensionnés. Des acteurs européens de la cybersécurité — je pense notamment à des spécialistes comme Sekoia.io — travaillent précisément sur cette détection comportementale dans des environnements hybrides. Ce n'est pas un hasard : ils ont été pensés dans un contexte réglementaire européen, avec des contraintes de souveraineté des données intégrées dès la conception.

Ce que j'attends des DSI européens maintenant

La crise vécue par cette ETI industrielle n'est pas un cas isolé. Elle est, j'en suis convaincu, le premier d'une longue série. Les outils d'IA générative accessibles depuis 2024-2025 ont dramatiquement réduit le coût et la complexité de développement de ce type d'agent offensif. Ce qui nécessitait hier une équipe de recherche offensive sophistiquée peut aujourd'hui être orchestré avec des ressources bien moindres.

Face à ça, il faut arrêter de traiter la question de souveraineté numérique comme un idéal politique réservé aux grands groupes ou aux administrations. Pour une ETI de 800 personnes avec un patrimoine industriel et de R&D à protéger, c'est une question de survie économique.

Concrètement, voici ce que je pense que chaque DSI ou RSSI d'une ETI européenne devrait mettre sur la table de son comité de direction dans les prochains mois :

Cartographier les dépendances critiques. Pas les dépendances fonctionnelles — celles-là, tout le monde les connaît. Les dépendances de sécurité : qui contrôle vos logs ? Qui peut bloquer votre accès à vos propres données en cas de crise ? Qui a juridiction sur vos flux en cas de demande d'un gouvernement tiers ?

Identifier les points de bascule contractuels. Chaque contrat avec un acteur américain dominant comporte des clauses qui limitent, en situation de crise, votre capacité d'action. Il faut les lire, les comprendre, et les intégrer dans votre analyse de risque — pas les laisser dormir dans un tiroir juridique.

Investir dans la réversibilité. L'objectif n'est pas de tout rapatrier demain matin. C'est de s'assurer que vous avez, à tout moment, la capacité technique et contractuelle de le faire si nécessaire. La réversibilité est une composante de résilience. Elle doit être budgétée.

L'ETI industrielle dont je vous ai parlé s'en est sortie. Avec des semaines de travail, des coûts de remédiation significatifs, et une exposition de données de R&D dont les conséquences compétitives restent difficiles à évaluer. Elle a depuis entamé une révision complète de son architecture, en intégrant des opérateurs européens qualifiés pour les briques les plus sensibles.

C'est une bonne nouvelle. Mais il ne fallait pas attendre cet incident pour le faire. Et il ne faudra pas attendre le prochain pour vous y mettre.