Étiquettes

,

Aujourd’hui, presque tout le monde y parvient, à moins d’avoir déjà plus de 70 ans. Mais le nouveau monde numérique, malgré tous ses avantages, présente surtout un inconvénient : il n’y a pratiquement plus de secrets. Toutes les données de ce monde sont accessibles – notamment par des personnes non autorisées…

Par Michael Hollister

Deux cyberattaques en l’espace de deux mois frappent la Commission européenne – précisément au moment où celle-ci certifie sa propre capacité de défense et impose des règles de sécurité contraignantes à tout un continent. Un constat sur le fossé entre la réglementation et la réalité.

Un outil dont la seule fonction est de détecter les failles de sécurité est lui-même devenu une faille le 19 mars 2026. Ce jour-là, la Commission européenne utilisait une version trafiquée du scanner de vulnérabilités open source Trivy – un logiciel que des organisations du monde entier utilisent pour détecter les failles de leurs systèmes avant que des pirates ne le fassent. C’est précisément grâce à cet outil que les pirates ont pu accéder à l’infrastructure cloud de la Commission. Neuf jours plus tard, environ 340 gigaoctets de données se retrouvaient sur le darknet : données à caractère personnel, correspondance interne par e-mail, clés de signature cryptographique. Il s’agissait de la deuxième violation confirmée subie par la Commission en l’espace de deux mois.

L’incident lui-même est bien documenté dans la presse spécialisée en sécurité informatique. Ce qui est remarquable, ce n’est pas l’intrusion en soi, mais le contexte dans lequel elle s’est produite. Treize jours avant le début de la première de ces deux attaques, l’organe de surveillance chargé de la cybersécurité des institutions de l’UE avait présenté son rapport annuel, dans lequel il décrivait sa propre résilience comme solide et conforme aux prévisions. Dix jours plus tard, la Commission a proposé un paquet législatif dont la pièce maîtresse était justement la protection des chaînes d’approvisionnement. Et lorsque la faille a été rendue publique, la Commission a communiqué à ce sujet d’une manière qu’elle n’aurait guère tolérée de la part d’une entreprise soumise à sa réglementation.

D’où la question que pose ce texte : que signifie le fait que l’institution qui impose à un continent des règles contraignantes en matière de cybersécurité ne les respecte pas en son sein même – et parle de cet échec d’une manière que les entités réglementées ne seraient pas autorisées à adopter ?

La faille : comment un outil de sécurité est devenu une porte d’entrée

La chaîne technique peut être retracée avec précision grâce à l’analyse du CERT-EU, le service de cybersécurité des institutions de l’Union. Le point de départ n’était pas la Commission, mais la chaîne d’approvisionnement logicielle de Trivy elle-même. Dès février 2026, un groupe de pirates baptisé TeamPCP s’était introduit dans le processus de développement du scanner via un environnement GitHub Actions mal configuré. Après un premier nettoyage incomplet, le groupe a conservé un accès résiduel.

Le 19 mars 2026, TeamPCP a exploité cet accès résiduel pour publier une version de Trivy infectée par un cheval de Troie. Le fabricant Aqua Security et les chercheurs en sécurité de Wiz et Microsoft ont reconstitué le déroulement des événements de manière concordante : un fichier binaire manipulé dans la version 0.69.4, 76 des 77 balises de version de l’action GitHub associée écrasées par du code malveillant, ainsi que les sept balises d’un deuxième composant auxiliaire remplacées. Toute personne ayant téléchargé le scanner pendant cette période a installé un « credential stealer » – un logiciel malveillant qui intercepte les variables d’environnement, les identifiants d’accès au cloud, les clés SSH et les secrets issus des pipelines de développement. L’incident a ensuite reçu le numéro d’identification CVE-2026-33634, a été classé comme critique et ajouté par l’agence américaine CISA au catalogue des vulnérabilités activement exploitées.

La Commission figurait parmi les organisations ayant utilisé une version compromise pendant cette fenêtre critique. Grâce au scanner manipulé, les attaquants ont obtenu une clé d’accès AWS qui leur a permis de prendre le contrôle d’autres comptes AWS de la Commission. Par la suite, selon le CERT-EU, ils ont utilisé l’outil TruffleHog pour détecter et valider d’autres identifiants via le Security Token Service d’Amazon. Ils ont créé une nouvelle clé d’accès qu’ils ont attribuée à un utilisateur existant – une manœuvre visant à éviter d’être détectés – et ont commencé à explorer l’environnement.

Ce qui a été divulgué

Ce n’est que le 24 mars 2026 que le Centre des opérations de cybersécurité de la Commission a tiré la sonnette d’alarme : trafic API inhabituel, indices d’un compte compromis, augmentation du trafic réseau. Cinq jours se sont écoulés entre la première intrusion et sa découverte. Le 25 mars, le CERT-UE a été informé, conformément à l’article 21 du règlement sur la cybersécurité 2023/2841, qui oblige les institutions de l’Union à signaler les incidents majeurs sans retard injustifié. Le 27 mars, la Commission a rendu l’incident public. Le 28 mars, le groupe de cybercriminels ShinyHunters a publié les données volées sur son site de fuites du darknet.

Le volume confirmé par le CERT-UE s’élève à environ 91,7 gigaoctets de données compressées, soit environ 340 gigaoctets une fois décompressées. Les sites web de jusqu’à 71 clients du service d’hébergement web Europa ont été touchés : 42 services internes de la Commission et au moins 29 autres institutions de l’Union. L’ensemble de données contenait des données à caractère personnel : noms, noms d’utilisateur, adresses e-mail. Il comprenait des clés de signature DKIM – ces clés cryptographiques permettant de certifier que les e-mails proviennent bien d’un domaine donné. Il comprenait 51 992 fichiers relatifs à la communication par e-mail sortante, pour un total de 2,22 gigaoctets. Selon le CERT-EU, la majorité d’entre eux seraient des notifications automatisées au contenu limité ; certains toutefois – appelés « messages de rebond » – pourraient contenir du contenu original soumis par des utilisateurs et ainsi divulguer des données à caractère personnel.

Les clés DKIM revêtent ici une importance plus grande qu’il n’y paraît à première vue. Elles permettent de falsifier des e-mails qui passent avec succès les contrôles d’authentification des domaines de la Commission – un outil de précision pour des attaques de phishing ciblées, par exemple contre des États membres qui se fient aux e-mails provenant d’adresses europa.eu.

L’auteur de cette publication n’est pas un inconnu. ShinyHunters s’est illustré ces dernières années comme un groupe de chantage à l’origine de nombreuses fuites de données de grande envergure ; parmi les victimes présumées figurent Ticketmaster, AT&T et des dizaines d’autres entreprises, ainsi que, plus récemment, une série d’attaques visant les comptes Salesforce de grands groupes. Sur sa page dédiée aux fuites, le groupe a décrit le butin comme totalisant plus de 350 gigaoctets, comprenant notamment des copies de sauvegarde de serveurs de messagerie, des bases de données, des documents confidentiels et des contrats ; à titre de preuve, il a mis en ligne une archive de plus de 90 gigaoctets. Les chercheurs en sécurité qui ont examiné l’ensemble des données ont signalé, au-delà des catégories confirmées par le CERT-UE, la présence de contenus provenant de la plateforme collaborative NextCloud ainsi que d’adresses administratives internes – des informations que la Commission elle-même n’a pas confirmées. En ce qui concerne la confirmation officielle, le CERT-EU s’en est tenu aux 71 clients d’hébergement et n’a pas cité nommément les 29 autres institutions de l’Union ; certains rapports secondaires ont répertorié des entités potentiellement concernées, sans que cette attribution soit validée par le service d’urgence.

En matière d’attribution, la précision s’impose, car elle est souvent négligée. Le CERT-EU attribue avec un haut degré de confiance la première intrusion à l’attaque de la chaîne d’approvisionnement Trivy, qui est publiquement attribuée à TeamPCP. C’est ShinyHunters qui s’est chargé de la publication des données. On ne sait pas encore avec certitude si TeamPCP a transmis l’accès à ShinyHunters ou si ShinyHunters s’est contenté de mener la partie chantage. Il s’agit donc d’une répartition des tâches entre deux acteurs – l’un chargé de l’intrusion, l’autre du chantage –, et non d’un seul et même auteur. Ce que le CERT-EU n’a expressément pas constaté : une propagation latérale au-delà de l’accès initial. La Commission a retiré les droits au compte compromis et désactivé les clés concernées. Les sites web et services europa.eu sont restés disponibles sur ; selon le CERT-EU, les systèmes internes n’ont pas été affectés. Amazon a également déclaré que sa plateforme n’avait subi aucun incident de sécurité – ce qui est exact : dans le modèle de responsabilité partagée, le fournisseur sécurise l’infrastructure, tandis que la gestion des comptes et des identifiants d’accès reste à la charge du client.

La première faille et le schéma qui se cache derrière

L’incident de mars n’était pas le premier. Le 30 janvier 2026, la Commission avait détecté des traces d’une attaque visant son infrastructure centrale de gestion des appareils mobiles – ce que l’on appelle la « gestion des appareils mobiles » (Mobile Device Management), grâce à laquelle les grandes organisations gèrent de manière centralisée les téléphones et tablettes professionnels. Les noms et numéros de téléphone des employés auraient pu être concernés ; selon la Commission, les appareils eux-mêmes n’ont pas été compromis. Le CERT-EU a maîtrisé l’incident en l’espace de neuf heures. Il a été rendu public le 6 février 2026.

La Commission n’a pas confirmé le vecteur d’attaque. La proximité temporelle avec deux vulnérabilités critiques du logiciel Ivanti Endpoint Manager Mobile – signalées par Ivanti le 29 janvier 2026 et répertoriées sous les identifiants CVE-2026-1281 et CVE-2026-1340 – suggère un lien. Ces failles permettaient aux attaquants d’exécuter du code à distance sans avoir besoin d’identifiants de connexion. Cet incident s’inscrivait dans une vague plus large d’attaques visant ce logiciel, qui a touché des administrations en Europe et aux États-Unis au printemps 2026.

Deux intrusions en deux mois : pour l’instant, on ne peut pas en déduire autre chose qu’une simple coïncidence, et aucun lien de causalité direct entre les deux n’a été établi. Mais l’attaque de mars s’inscrivait dans un contexte plus large. La compromission de Trivy n’était que la première vague d’une campagne menée par TeamPCP contre l’infrastructure de sécurité open source entre le 19 et le 24 mars 2026. Après Trivy, ce fut au tour du scanner d’infrastructure Checkmarx KICS d’être touché, puis de la bibliothèque LiteLLM via son pipeline de publication, et enfin de l’écosystème npm via un code malveillant auto-propagateur que les chercheurs ont baptisé « CanisterWorm ». Les identifiants de connexion dérobés lors de l’attaque contre Trivy ont servi, cinq jours plus tard, à compromettre le composant suivant. La société de sécurité Palo Alto Networks a qualifié cette opération de campagne systématique contre l’infrastructure de sécurité open source ; Mandiant, entreprise spécialisée dans l’analyse des menaces, a quantifié l’ampleur de l’attaque à plus d’un millier d’environnements cloud touchés. Le logiciel malveillant utilisé était spécialement conçu pour opérer au sein des pipelines de développement et pour extraire des informations confidentielles via plusieurs canaux : des domaines usurpés, des dépôts GitHub et des tunnels réseau camouflés. TeamPCP est connu sous plusieurs noms et est considéré comme un acteur spécialisé dans les infrastructures cloud natives ; les analyses disponibles ne permettent pas de l’attribuer à un État en particulier.

C’est là le véritable constat structurel de cet épisode : les outils avec lesquels les organisations se défendent forment eux-mêmes une chaîne d’approvisionnement – et cette chaîne d’approvisionnement constitue un point faible. Celui qui infecte le scanner n’a plus besoin de prendre d’assaut chaque forteresse ; il attend que les défenseurs apportent eux-mêmes son outil.

La contradiction dans le déroulement chronologique

C’est précisément à ce stade que la chronologie des événements devient le cœur de l’histoire. Le 20 janvier 2026 – dix jours avant la première intrusion, un peu plus de deux mois avant la seconde –, la Commission a proposé son nouveau paquet de mesures sur la cybersécurité. Celui-ci prévoit une révision de la loi sur la cybersécurité et des modifications ciblées de la directive NIS2. Son élément central déclaré : un « cadre fiable pour la sécurité de la chaîne d’approvisionnement des TIC », destiné à réduire les risques liés aux fournisseurs, y compris ceux provenant de pays tiers. De plus, le budget de l’Agence européenne de cybersécurité (ENISA) devait augmenter de plus de 75 %.

La Commission a donc présenté un cadre de protection contre les risques liés à la chaîne d’approvisionnement – et a été compromise, environ deux mois plus tard, par ce type même d’attaque. Il ne s’agit pas là d’un jugement de valeur, mais d’une chronologie. Sa force ne tient pas à l’ironie, mais à ce qui l’a précédée.

Une directive assortie d’un délai

Le paquet « cybersécurité » de janvier 2026 n’était pas la première tentative. Dès le 13 décembre 2023, le Parlement et le Conseil avaient adopté le règlement 2023/2841 – des mesures visant à garantir un niveau élevé et commun de cybersécurité au sein des institutions, organes et agences de l’Union. Il est entré en vigueur le 7 janvier 2024 et oblige chaque institution de l’Union, y compris la Commission, à prendre des mesures concrètes assorties de délais précis : un cadre interne de gestion des risques, de gouvernance et de contrôle d’ici le 8 avril 2025, des évaluations du niveau de maturité de sa propre cybersécurité, des mesures de gestion des risques et, enfin, un plan de cybersécurité dont l’objectif était fixé pour début 2026. À des fins de suivi, le règlement a institué un comité interinstitutionnel de cybersécurité, habilité à recommander des audits ou à suspendre les flux de données en cas de non-conformité persistante.

Au-delà de ces délais, le règlement exige de chaque institution qu’elle désigne un responsable local de la cybersécurité en tant que point de contact central et qu’elle évalue son propre niveau de maturité en matière de cybersécurité avant le 8 juillet 2025, puis au moins tous les deux ans. En termes de principes et de niveau d’exigence, ce règlement s’aligne sur la directive NIS 2, qui s’applique aux entreprises et aux opérateurs de services essentiels – l’Union soumet donc ses propres institutions au même niveau d’ambition qu’elle impose au reste du continent.

Ce règlement n’est pas né de rien. Il a été élaboré en réponse à une mise en garde. Le 29 mars 2022, la Cour des comptes européenne avait publié le rapport spécial n° 05/2022, intitulé : « Cybersécurité des institutions, organes et organismes de l’UE : dans l’ensemble, le niveau de préparation n’est pas adapté aux menaces ». La conclusion des auditeurs était sans équivoque : le nombre d’incidents de cybersécurité majeurs au sein des institutions de l’UE avait été multiplié par plus de dix entre 2018 et 2021 ; le niveau de préparation n’était pas adapté aux menaces ; et, les institutions étant fortement interconnectées, une faille dans l’une d’entre elles pouvait mettre les autres en danger. Plus précisément, les auditeurs ont critiqué l’absence généralisée de contrôles de sécurité essentiels, le fait que la gestion de la sécurité informatique soit souvent insuffisamment développée, que les évaluations des risques ne couvrent pas l’ensemble de l’environnement et qu’un certain nombre d’institutions investissent nettement moins dans la cybersécurité que des organisations comparables. La Cour des comptes a expressément recommandé l’introduction de règles contraignantes et l’octroi de moyens supplémentaires au CERT-UE.

Une chronologie claire se dessine ainsi : avertissement en 2022, règlement contraignant en 2023, failles en 2026. Et, avec le recul, le constat de la Cour des comptes concernant l’interconnexion apparaît comme une anticipation de l’affaire « » : à cause d’un seul service d’hébergement compromis, les données de 42 services internes et d’au moins 29 autres institutions de l’Union sont tombées entre des mains étrangères – une faille à un seul endroit qui en a exposé d’innombrables autres.

Auto-évaluation face à la réalité

Entre l’avertissement et la violation s’intercale un document qui accentue le contraste. Le 7 janvier 2026, le Comité interinstitutionnel de cybersécurité a présenté son rapport annuel pour 2025. Dans le communiqué public d’accompagnement du CERT-UE, l’année est décrite comme suit : les institutions de l’Union auraient investi beaucoup de temps et de moyens pour consolider et tester leurs cadres internes dans le respect des délais fixés par le règlement – on serait, selon la formulation du rapport de l’année précédente, « sur la bonne voie ». Le rapport de 2024 avait déjà explicitement identifié les attaques visant la chaîne d’approvisionnement comme une menace particulière.

La chronologie est donc précise. Le 7 janvier 2026, l’organe de surveillance présente son auto-évaluation, selon laquelle les cadres sont en place et respectent le calendrier prévu. Treize jours plus tard, la Commission propose son paquet de mesures sur la chaîne d’approvisionnement. Vingt-trois jours plus tard, son système de gestion des appareils est piraté. Un peu plus de deux mois plus tard, elle est victime d’une attaque visant la chaîne d’approvisionnement – précisément la menace que le rapport de l’organe de surveillance lui-même avait mise en avant comme étant particulière.

Il convient ici de faire preuve de prudence afin qu’un constat ne se transforme pas en un reproche que les faits ne corroborent pas. Dans son rapport, l’organe de surveillance n’affirme pas que les institutions sont inviolables. Il décrit que des structures de gouvernance ont été mises en place, que les délais ont été pris en compte et que des évaluations ont été réalisées. Un scanner compromis provenant d’un fournisseur tiers n’est pas un incident qu’un cadre de gouvernance peut empêcher en un clin d’œil. Le constat ne réside donc pas dans une contradiction entre l’affirmation et la vérité, mais dans la confrontation de deux niveaux : la préparation certifiée sur le papier et le résultat opérationnel quelques semaines plus tard. C’est au lecteur de tirer ses propres conclusions.

La communication : le porte-parole contre le service d’urgence

Le plus révélateur est la manière dont la Commission a évoqué sa propre faille de sécurité. Le porte-parole de la Commission, Thomas Regnier, a confirmé le 27 mars 2026 qu’une cyberattaque avait été détectée, touchant « une partie de notre infrastructure cloud » ; les systèmes internes n’auraient pas été affectés. Trois jours plus tard, devant les journalistes, il a encore affiné sa déclaration. Les domaines concernés se limiteraient aux pages publiques d’europa.eu, l’infrastructure interne n’étant « absolument pas touchée ». Concernant les données éventuellement dérobées, il a précisé qu’il s’agissait de données qui étaient « potentiellement déjà publiques de toute façon ».

C’est là qu’il convient d’opérer une distinction cruciale. L’affirmation selon laquelle les systèmes internes n’étaient pas touchés concorde avec ce que le CERT-EU a constaté par la suite : aucune propagation latérale, les services europa.eu sont intacts. Sur ce point, le service d’urgence ne contredit pas le porte-parole. La deuxième affirmation, en revanche – des données qui seraient de toute façon déjà publiques –, contredit ce que le CERT-UE a confirmé quelques jours plus tard : des données à caractère personnel en grande quantité, des clés de signature DKIM, près de 52 000 fichiers relatifs à la communication par e-mail, dont d’éventuels contenus d’utilisateurs. Les clés de signature et la correspondance interne ne sont pas des données qui sont de toute façon publiques.

Ce qui transparaissait dans la présentation est également révélateur. Dans sa longue communication écrite, la Commission a admis que des données avaient été dérobées – une formulation qui contrastait avec le résumé rassurant et qui n’a pris toute sa portée qu’à la suite de l’analyse ultérieure du CERT-EU. Les chercheurs en sécurité ont très tôt donné une dimension politique à cet incident : une faille rendue publique de cette ampleur pouvait être exploitée pour faire passer la Commission pour une institution peu sûre – avec un impact d’autant plus important qu’elle est considérée comme une pionnière dans l’établissement de règles de sécurité. Cette interprétation est une analyse, pas un constat ; elle montre toutefois pourquoi la communication sur sa propre faille est plus délicate pour un régulateur que pour une victime ordinaire.

Le média spécialisé The Register a qualifié la réaction de la Commission de « remarquablement laconique » pour une institution qui exige par ailleurs la transparence en cas d’incidents de sécurité. Et c’est précisément là que réside l’asymétrie qui fait que cet incident dépasse le simple cadre technique. En vertu de la directive NIS2 et du règlement 2023/2841, la Commission oblige les entreprises et les organismes à signaler rapidement et de manière exhaustive les incidents significatifs. Concernant sa propre violation, elle s’est d’abord montrée laconique, n’a précisé ni les types de données ni l’ampleur de la fuite, et a relativisé la sensibilité des données divulguées – jusqu’à ce que son propre service d’urgence fournisse les chiffres.

Cette asymétrie s’inscrit dans une tendance plus large, retracée dans la série « Le citoyen transparent » : l’État devient de plus en plus lisible pour le citoyen, tandis qu’il se soustrait lui-même à toute transparence. Partie 1 – « Cinq couches, un profil – Comment l’UE construit le citoyen transparent ».

La cyberfracture de la Commission est le reflet de ce mouvement. L’institution qui impose la transparence s’en est montrée réticente dans son propre cas.

La contre-argumentation

À ce stade, l’honnêteté impose de prendre au sérieux les contre-arguments – non pas pour faire bonne figure, mais parce qu’ils sont solides.

Premièrement : l’utilisation de Trivy ne relevait pas d’une négligence. Ce scanner est un outil éprouvé et largement utilisé, proposé par un éditeur réputé. Des millions de pipelines de développement y ont recours. Une organisation qui l’utilise agit correctement : elle recherche activement les vulnérabilités. Le fait que cet outil ait justement été compromis ne constitue pas une défaillance de la Commission, mais relève de la nature même d’une attaque de la chaîne d’approvisionnement.

Deuxièmement : de telles attaques touchent tout le monde. La campagne Trivy a compromis plus d’une centaine d’autres environnements ; l’Office fédéral allemand de la sécurité informatique a mis en garde, le 26 mars 2026, contre des compromissions également en Allemagne. La Commission européenne ne constitue pas un cas particulier à cet égard, mais l’une des nombreuses victimes d’un type d’attaque contre lequel aucune cible n’est totalement à l’abri.

Troisièmement : de nombreux éléments ont bien fonctionné. L’obligation de signalement prévue à l’article 21 a été respectée, le CERT-EU a été alerté, le compte compromis a été rapidement bloqué et, à ce jour, toute propagation latérale a été empêchée. Un dispositif de protection qui échoue à un seul niveau n’est pas comparable à un dispositif qui ne fonctionne pas du tout. Cependant, au cours des cinq jours qui se sont écoulés entre la première intrusion et sa découverte, c’est précisément cette exfiltration dont l’ampleur n’a été révélée que par la fuite sur le darknet qui s’est produite – la maîtrise a été rapide, mais elle est arrivée trop tard pour empêcher la fuite.

Et c’est précisément là que réside le cœur du débat. Étant donné que la faille technique initiale est universelle – car n’importe qui peut se faire piéger par un scanner corrompu –, le véritable problème ne réside pas dans le fait d’être tombé dans le piège. Il réside dans le décalage entre la position réglementaire affichée à l’extérieur et la réalité opérationnelle en interne : cinq jours avant la découverte ; des identifiants AWS à durée de validité prolongée à la portée d’un outil de scan ; et une communication qui a relativisé la faille au lieu de la divulguer telle que le propre règlement de l’entreprise l’exige des autres. Ce n’est pas le fait d’être victime qui constitue le constat, mais l’écart entre les exigences et la pratique.

Logique du pouvoir : pourquoi cela se répète

Quiconque examine les intérêts et les contraintes structurelles comprend pourquoi ce type d’incident n’est pas un accident isolé, mais un schéma récurrent.

Tout d’abord, l’économie technique de l’attaque. La chaîne d’outils de sécurité constitue un point de défaillance unique doté d’un effet de levier considérable. Un seul scanner compromis permet d’atteindre des milliers d’environnements sans que l’attaquant ait à les compromettre un par un. Ce sont les défenseurs eux-mêmes qui introduisent l’outil. Les outils de sécurité constituent une cible idéale à cet égard, car ils s’exécutent par nature avec des privilèges : un scanner a besoin d’accéder aux pipelines de développement, aux identifiants d’accès et aux comptes cloud pour pouvoir fonctionner. Quiconque en prend le contrôle hérite de ces droits d’accès. Dans le cas de la Commission, il faut ajouter qu’une clé une fois capturée ouvrait le contrôle sur d’autres comptes – ce qui indique que des identifiants d’accès de grande portée étaient à la portée d’un outil fonctionnant de manière automatisée. Le problème ne résidait pas dans l’utilisation du scanner, mais dans l’étendue de ce qu’il pouvait affecter en cas d’incident. Tant que les organisations – y compris publiques – s’appuieront sur des marqueurs de version variables plutôt que sur des sommes de contrôle cryptographiques immuables, ce levier restera en place. La solution est connue et simple : lier les composants à des sommes de contrôle fixes. Le fait qu’elle ne soit pas appliquée à grande échelle explique pourquoi cette catégorie d’attaques fonctionne.

Deuxièmement, l’économie institutionnelle. Un ensemble de règles génère des artefacts mesurables : des règlements adoptés, des comités mis en place, des délais respectés, des rapports annuels certifiant les progrès. Le renforcement face aux menaces ne produit pas de tels artefacts ; il ne se révèle qu’en cas d’urgence, et celle-ci ne peut être planifiée. L’incitation à optimiser la production réglementaire visible et l’autocertification est structurellement plus forte que celle visant à optimiser la résilience opérationnelle invisible. C’est précisément ce déséquilibre qui crée le fossé entre le « tout va bien » du rapport annuel et la rupture survenue quelques semaines plus tard.

Troisièmement, l’économie de la transparence. Pour une institution qui est à la fois régulateur et partie concernée, deux intérêts s’opposent : l’intérêt réglementaire d’une divulgation complète et son propre intérêt à limiter les dégâts. Dans son propre cas, c’est ce dernier qui l’a emporté, du moins au début. C’est humainement compréhensible – et c’est précisément pour cette raison que ce phénomène est structurellement prévisible. Quiconque concentre entre ses mains la règle et son application est tenté de se montrer plus indulgent envers lui-même qu’envers les autres.

Scénarios

Plusieurs lignes de développement découlent de cette structure.

Dans le premier scénario, la faille alimente précisément la centralisation qu’elle a mise en évidence. Le paquet de mesures sur la cybersécurité de janvier 2026 mise sur l’interdiction des fournisseurs à haut risque, sur des exigences harmonisées et sur une infrastructure commune. Une faille spectaculaire fournit l’argument pour accélérer cette centralisation : davantage de cloud commun, davantage de contrôle centralisé, davantage de pouvoirs pour les autorités de surveillance. L’humiliation liée au manque de résilience devient le moteur d’un renforcement des compétences. La question de savoir si une centralisation accrue réduit ou augmente la surface d’attaque reste ouverte, mais elle est rarement soulevée dans le débat.

Dans le deuxième scénario, le fossé entre les intentions et la réalité opérationnelle persiste. Les cadres de gouvernance continuent d’être renforcés, les rapports annuels font état de progrès, et la prochaine attaque visant la chaîne d’approvisionnement n’est pas une question de « si », mais de « quand ». La campagne TeamPCP a montré que la chaîne d’outils de sécurité est une cible de choix ; elle ne sera pas la dernière du genre.

Dans le troisième scénario, moins probable, l’UE tire des conséquences opérationnelles plutôt que réglementaires : liaison obligatoire des composants à des sommes de contrôle, tests adversariaux au lieu d’auto-évaluation, délais de détection plus courts comme critère de vérification. Cette voie génère moins d’artefacts visibles et davantage de résilience réelle – et c’est précisément pour cette raison qu’elle est la moins probable.

Conclusion

Entre le 30 janvier et le 28 mars 2026, la Commission européenne a vécu à deux reprises ce qu’elle s’engage à empêcher sur tout un continent. La deuxième de ces failles s’est produite via un outil dont le but est de détecter les vulnérabilités, au moment même où son propre organe de surveillance certifiait la résilience de l’Union et où la Commission élevait la protection des chaînes d’approvisionnement au rang de projet de loi.

Le constat n’est pas que l’UE serait plus incompétente que d’autres – elle ne l’est pas, et ce type d’attaque touche tout le monde. Le constat porte sur le fossé : entre l’alerte de 2022 et la faille de 2026, entre la certification « en bonne voie » et les cinq jours qui ont précédé la découverte, entre la transparence imposée et la réticence avec laquelle son propre cas a été évoqué. L’État, qui rend le citoyen transparent, n’a pas pu se préserver de l’opacité face à un scanner piraté – et a parlé de la fuite d’une manière qu’il n’a jamais autorisée chez ceux qu’il réglemente.

Michael Hollister a été soldat de la Bundeswehr pendant six ans (SFOR, KFOR) et jette un regard dans les coulisses des stratégies militaires. Fort de 14 ans d’expérience dans le domaine de la sécurité informatique, il analyse, à partir de sources primaires, la militarisation européenne, la politique d’intervention occidentale et les glissements de pouvoir géopolitiques. Une partie importante de son travail porte sur la région asiatique, en particulier l’Asie du Sud-Est, où il étudie les dépendances stratégiques, les zones d’influence et les architectures de sécurité. Hollister allie une vision interne opérationnelle à une critique sans concession du système – au-delà du journalisme d’opinion. Ses travaux sont publiés en deux langues sur www.michael-hollister.com ainsi que dans des médias critiques des pays germanophones et anglophones.

Petite post-scriptum de Christian Müller :
« Tempora mutantur, nos et mutamur in illis », « Les temps changent, et nous changeons avec eux ». Lorsque, au début des années 1990, j’ai dû prendre en urgence la direction du groupe de presse Ringier en République tchèque – du jour au lendemain, je me suis retrouvé responsable de deux quotidiens, d’une dizaine de magazines et d’une imprimerie, soit au total plus d’un millier de collaborateurs –, j’ai également dû emménager dans le bureau de mon prédécesseur, qui avait dû être licencié pour fraude. Que étaient donc ces petits boutons fixés sur toutes les vitres et ces fins câbles qui y étaient reliés ? Un spécialiste que j’avais fait venir m’a expliqué : sous mon bureau se trouvait un interrupteur invisible vu d’en haut. Lorsqu’on l’actionnait, toutes les vitres se mettaient à vibrer légèrement ! Le spécialiste m’a expliqué : ce dispositif servait à faire vibrer les vitres, et ces vibrations avaient pour but d’empêcher toute écoute depuis l’extérieur des conversations menées à l’intérieur du bureau ! – Qu’en reste-t-il aujourd’hui ? Aujourd’hui encore, il existe des conversations et surtout des communications électroniques qui devraient rester secrètes. Mais il semble qu’aucun moyen de protection fiable n’ait encore été inventé. Les vitres qui vibrent ne suffisent plus…

Bibliographie

Sources primaires et officielles (UE/nationales)

Sources techniques primaires (fabricants, CVE)

Presse spécialisée (incident, attribution, réaction de la Commission)

Global Bridge