Piratages d'État : trois approches de cyber-souveraineté, et pourquoi le choix n'est plus neutre

# Piratages d'État : trois approches de cyber-souveraineté, et pourquoi le choix n'est plus neutre

En 2026, le piratage d'État n'est plus une menace abstraite réservée aux ministères et aux opérateurs d'importance vitale. Il frappe des PME sous-traitantes, des ETI industrielles, des cabinets d'ingénierie. Et dans la majorité des post-mortems, on retrouve le même constat silencieux : l'entreprise avait externalisé l'essentiel de sa posture cyber chez un acteur américain dont elle ne maîtrisait ni les accès, ni les logs, ni les conditions d'intervention. Ce n'est pas une fatalité. C'est un choix — que beaucoup n'ont pas assumé consciemment.

Cet article ne liste pas des outils. Il compare trois postures organisationnelles et architecturales face à la menace étatique, avec un prisme clair : celui d'une entreprise européenne qui décide de reprendre la main sur sa sécurité, plutôt que de la déléguer à des acteurs soumis au Cloud Act, au FISA ou aux injonctions discrètes de juridictions étrangères.

Pourquoi la menace étatique change tout

Les attaques étatiques — ou sponsorisées par des États — ne ressemblent pas aux ransomwares opportunistes. Elles sont patientes, ciblées, et exploitent précisément les angles morts des architectures hybrides cloud américain. Elles savent où chercher les clés de chiffrement, comment traverser les pipelines d'identité fédérés, et parfois — c'est là que ça devient inconfortable — elles bénéficient d'accès légaux que les fournisseurs ne peuvent pas refuser et ne peuvent pas divulguer.

Face à ça, la question n'est pas "quel outil de détection acheter ?" La question est : quelle architecture me permet de savoir ce qui se passe sur mon SI, sans dépendre d'un tiers qui peut être contraint par une puissance étrangère ?

Trois approches coexistent aujourd'hui chez les ETI et PME européennes les plus avancées. Aucune n'est parfaite. Mais elles ne se valent pas.

Approche 1 : la délégation managed security (MSSP américain)

Ce que c'est

L'entreprise confie sa détection, sa réponse à incident et souvent sa gestion des identités à un MSSP — Managed Security Service Provider — dont les SOC sont opérés depuis les États-Unis ou via des filiales européennes juridiquement rattachées à une maison mère américaine.

Architecture

Les logs centralisés remontent vers des plateformes SIEM hébergées hors d'Europe ou dans des régions cloud américaines. La corrélation des événements, la threat intelligence et les playbooks de réponse sont propriétaires, opaques, non auditables par le client. L'entreprise voit des alertes. Elle ne voit pas le raisonnement.

Intégration

Rapide. C'est précisément le piège. En six semaines, le MSSP est branché sur l'Active Directory, les endpoints, les flux réseau. L'intégration est fluide parce qu'elle est conçue pour créer une dépendance profonde et coûteuse à défaire.

Gouvernance

Formellement, l'entreprise reste responsable de sa sécurité. Dans les faits, elle n'a plus les compétences internes pour contester une analyse, auditer un playbook ou changer de prestataire sans rupture opérationnelle. Le RSSI devient un interlocuteur commercial, pas un architecte.

Impact organisationnel

C'est là que le bilan est le plus sévère. Les équipes internes s'atrophient. Les profils analysts tier-1 disparaissent. Quand l'incident arrive — et il arrive — l'entreprise est dépendante d'une chaîne d'escalade qu'elle ne contrôle pas, vers des équipes qui peuvent être soumises à des obligations légales qu'elles ne peuvent pas lui communiquer.

Je pense que ce modèle est structurellement incompatible avec une posture souveraine. Il peut convenir à une phase transitoire. Il ne peut pas être une destination.

Approche 2 : la souveraineté partielle — SOC hybride avec ancrage européen

Ce que c'est

L'entreprise maintient un noyau de compétences internes (un ou deux analystes, un RSSI opérationnel) et s'appuie sur un MSSP européen qualifié — idéalement référencé ANSSI ou son équivalent dans son pays — pour les niveaux d'escalade et la threat intelligence.

Des acteurs comme Sekoia.io (France) ou WithSecure (Finlande) incarnent cette catégorie : des plateformes de détection souveraines, des équipes basées en Europe, des données qui ne transitent pas par des juridictions américaines.

Architecture

Le SIEM ou la plateforme XDR est hébergée dans un cloud souverain européen ou on-premise. Les règles de détection sont accessibles, modifiables, auditables par l'équipe interne. La threat intelligence est enrichie mais pas enfermée dans une boîte noire.

Intégration

Plus exigeante que la délégation totale. Elle suppose que l'entreprise maintienne des compétences d'intégration : savoir connecter une source de logs, comprendre un schéma de données, valider une règle de corrélation. Ce n'est pas anodin pour une ETI de taille moyenne — mais c'est précisément ce qui crée la résilience.

Gouvernance

L'entreprise peut auditer ce que fait son prestataire. Elle peut changer de plateforme sans tout perdre. Elle comprend ses propres alertes. Le RSSI retrouve un rôle technique réel.

Impact organisationnel

C'est le modèle qui exige le plus d'investissement RH à court terme — et qui en demande le moins à long terme. Il faut former, ou recruter, un profil d'analyste SOC capable de travailler en autonomie sur la plateforme. Il faut que le RSSI soit en mesure de dialoguer techniquement avec le prestataire, pas seulement de valider des rapports PowerPoint.

Mais c'est aussi le modèle qui préserve la capacité à réagir seul lors d'un incident majeur — quand les lignes d'escalade externe sont saturées ou indisponibles.

Approche 3 : la souveraineté totale — SOC internalisé sur stack ouverte

Ce que c'est

L'entreprise opère son propre SOC, sur des briques open source auditables — SIEM, SOAR, threat intelligence — hébergées on-premise ou dans un cloud souverain européen sous son contrôle exclusif. Aucune dépendance externe pour la détection ou la réponse.

Architecture

Elastic Security, Wazuh, OpenCTI : des plateformes dont le code est auditable, les données restent dans le périmètre de l'entreprise, et les règles de détection sont entièrement maîtrisées. L'entreprise sait exactement ce qu'elle cherche, pourquoi, et comment.

Intégration

Longue et complexe. C'est le prix de l'indépendance totale. Sans équipe interne expérimentée ou accompagnement d'un intégrateur européen spécialisé, le risque est de déployer des outils sous-configurés qui créent une fausse impression de sécurité.

Gouvernance

Maximale. L'entreprise est souveraine sur ses données, ses règles, ses incidents. Elle n'a aucune obligation de reporting à un tiers, aucun risque de fuite d'informations sensibles vers une chaîne d'escalade externe. En cas d'incident impliquant un partenaire ou un concurrent, la confidentialité est totale.

Impact organisationnel

C'est le modèle le plus exigeant en compétences. Il suppose une équipe dédiée, une culture de documentation rigoureuse, et une veille permanente sur les nouvelles menaces. Pour une ETI sans DSI technique solide, il est prématuré. Pour une entreprise industrielle avec des données stratégiques sensibles — propriété intellectuelle, contrats d'État, R&D — il est probablement le seul modèle cohérent avec le niveau de risque réel.

Tableau comparatif

| Critère | Délégation MSSP américain | SOC hybride européen | SOC internalisé open source |

|---|---|---|---|

| Maîtrise de l'architecture | Faible | Partielle | Totale |

| Audibilité des règles de détection | Nulle | Partielle | Totale |

| Juridiction des données | Risque élevé (Cloud Act) | Maîtrisée | Maîtrisée |

| Compétences internes requises | Faibles | Moyennes | Élevées |

| Résilience en cas de rupture prestataire | Très faible | Moyenne | Totale |

| Délai de mise en œuvre | Court | Moyen | Long |

| Gouvernance incident | Déléguée | Partagée | Internalisée |

Ce que ça implique concrètement pour votre organisation

Il faut arrêter de traiter la cyber-souveraineté comme un sujet de conformité réglementaire. C'est un sujet de capacité opérationnelle. La question n'est pas "sommes-nous conformes NIS2 ?" La question est : si nous subissons une attaque étatique demain matin, qui comprend ce qui se passe, qui décide, et qui peut agir — sans attendre l'autorisation d'un prestataire américain sous injonction ?

Les compétences à développer ou à recruter en priorité ne sont pas spectaculaires. Ce sont des profils d'analystes SOC capables de lire des logs bruts, de comprendre une règle SIGMA, d'investiguer un endpoint sans interface graphique rassurante. Ce sont des RSSI qui savent lire un schéma d'architecture réseau et dialoguer avec un intégrateur en égaux, pas en clients.

Ces profils existent en Europe. Ils sont formés dans nos universités et nos écoles d'ingénieurs. Mais trop d'ETI continuent de sous-traiter cette compétence plutôt que de la capitaliser, parce que le ROI à court terme semble plus favorable. C'est une erreur de calcul — qui ne se révèle que le jour de l'incident.

La cyber-souveraineté n'est pas un projet informatique. C'est une décision stratégique sur le niveau de dépendance que l'entreprise accepte vis-à-vis de puissances étrangères. En 2026, cette décision ne peut plus être différée.