Quand l'ANSSI documente les failles, qui choisit les fondations ?

# Quand l'ANSSI documente les failles, qui choisit les fondations ?

> En 2026, les recommandations de l'ANSSI sur l'adaptation des stacks logiciels aux méthodes d'attaque contemporaines ne sont pas seulement un guide technique. Elles posent, en creux, une question que peu d'organisations européennes ont encore tranchée : peut-on sécuriser durablement un système d'information dont les couches fondamentales restent sous juridiction américaine ?

Ce que l'ANSSI observe — et ce qu'elle ne dit pas explicitement

Les publications récentes de l'Agence nationale de la sécurité des systèmes d'information décrivent avec une précision croissante l'évolution des vecteurs d'attaque : compromission des identités numériques, mouvement latéral dans les environnements hybrides, exploitation des connecteurs entre outils SaaS, attaques sur les pipelines de développement logiciel. Le tableau est cohérent avec ce que les équipes de réponse à incident européennes observent sur le terrain depuis deux à trois ans.

Ce que l'ANSSI formule avec prudence — parce que son mandat institutionnel l'y oblige — les DSI et RSSI de PME/ETI doivent le lire entre les lignes : une part significative de la surface d'attaque documentée se concentre précisément là où les organisations européennes ont le moins de visibilité et le moins de contrôle. C'est-à-dire dans les couches intermédiaires de leur stack : les suites collaboratives hébergées hors de l'Union européenne, les outils de gestion des identités dont les conditions d'accès aux données peuvent évoluer unilatéralement, les environnements d'exécution cloud soumis à des législations extraterritoriales.

L'agence recommande d'adapter le stack logiciel. La question que cet article pose est plus précise : adapter en direction de quoi, et selon quels critères de souveraineté ?

Le Cloud Act et NIS2 : deux logiques irréconciliables dans un même SI

L'entrée en vigueur de la directive NIS2 et, pour les entités du secteur financier, du règlement DORA, a formellement élevé les exigences de contrôle des chaînes de dépendance logicielle. Ces textes imposent aux organisations de cartographier leurs fournisseurs critiques, d'évaluer les risques de concentration, et de démontrer leur capacité à maintenir les opérations en cas de défaillance ou de coupure d'accès.

Parallèlement, le Cloud Act américain de 2018 reste en vigueur sans modification substantielle. Il autorise les autorités fédérales américaines à requérir l'accès aux données stockées par des entreprises américaines, y compris lorsque ces données sont hébergées physiquement en Europe. La clarification juridique attendue par les acteurs européens depuis plusieurs années n'est pas venue. Les accords-cadres successifs entre l'Union européenne et les États-Unis sur les transferts de données ont certes évolué, mais ils ne résolvent pas la question fondamentale de l'accès gouvernemental aux données en dehors de tout cadre judiciaire européen.

Pour un RSSI qui doit simultanément satisfaire aux exigences de NIS2 — démontrer la maîtrise de ses données et de ses tiers critiques — et opérer sur une infrastructure partiellement soumise au Cloud Act, la contradiction n'est pas théorique. Elle est opérationnelle. Elle se manifeste concrètement lors des audits, lors des analyses d'impact relatives à la protection des données (AIPD), et lors des exercices de continuité d'activité.

L'ANSSI, dans ses travaux sur le visa de sécurité et le référentiel SecNumCloud, a d'ailleurs formalisé ce point : une qualification SecNumCloud implique notamment que le prestataire soit immunisé contre les législations extraeuropéennes susceptibles de donner accès aux données traitées. Ce critère exclut de facto les filiales européennes d'acteurs américains, même lorsqu'elles hébergent les données sur le sol de l'Union.

Les méthodes d'attaque de 2026 exploitent précisément les zones de dépendance

La convergence entre l'évolution des tactiques offensives et la géographie des dépendances logicielles n'est pas fortuite. Les groupes d'attaquants — qu'ils opèrent pour le compte d'États ou dans une logique criminelle économique — ont depuis longtemps intégré que les environnements hybrides des organisations européennes présentent des jointures exploitables.

Plusieurs typologies d'attaque documentées par l'ANSSI et par ses homologues européens (BSI en Allemagne, NCSC aux Pays-Bas, CCN-CERT en Espagne) convergent sur ce constat :

La compromission des fournisseurs d'identité est devenue un vecteur d'entrée privilégié. Lorsqu'une organisation délègue la gestion de ses identités à un service opéré hors de l'Union européenne, elle transfère de facto une partie du contrôle de son périmètre de sécurité à un tiers dont elle ne maîtrise ni les pratiques internes ni les obligations légales dans leur intégralité.

L'exploitation des connecteurs entre outils SaaS constitue une surface d'attaque qui s'est considérablement élargie avec la prolifération des intégrations. Chaque flux de données entre un outil de productivité, une plateforme de communication et un système de gestion interne représente un point d'entrée potentiel. La visibilité sur ces flux est souvent partielle, notamment lorsque les outils concernés n'offrent pas de journalisation complète accessible à l'organisation cliente.

Les attaques sur les pipelines de développement ciblent les environnements où du code est produit, testé et déployé. Les chaînes CI/CD qui reposent sur des services cloud américains introduisent des dépendances dont la sécurité n'est pas entièrement vérifiable par l'organisation européenne qui les utilise.

Dans chacun de ces cas, la recommandation générique d'« adapter son stack » se heurte à une réalité concrète : les alternatives existent, mais le chemin de migration est rarement trivial, et les arbitrages entre sécurité opérationnelle immédiate et réduction des dépendances à moyen terme sont structurellement complexes pour une PME ou une ETI.

Ce que signifie concrètement « adapter son stack » dans un cadre souverain

La formulation de l'ANSSI invite à une lecture fonctionnelle : il ne s'agit pas de remplacer mécaniquement un outil par un autre, mais d'évaluer chaque composant du système d'information à l'aune de la surface d'attaque qu'il génère et du niveau de contrôle que l'organisation conserve.

Dans cette logique, plusieurs acteurs européens ont construit des offres qui méritent d'être évaluées sérieusement — non pas comme des alternatives par défaut, mais comme des options dont les propriétés de souveraineté constituent un argument technique à part entière.

Sur le segment de la messagerie et de la collaboration, **Infomaniak**, opérateur suisse indépendant, propose une suite dont l'hébergement est intégralement en Suisse, sous législation suisse, sans actionnariat américain. Pour des organisations dont les données sont sensibles mais qui n'atteignent pas le niveau de qualification SecNumCloud, c'est une option de réduction du risque d'extraterritorialité qui mérite une évaluation sérieuse. L'absence de dépendance à des investisseurs de croissance américains est, dans ce contexte, un critère de stabilité juridique, pas seulement éthique.

Sur le segment de la gestion des identités et des accès — l'un des vecteurs d'attaque les plus documentés —, Wallix, éditeur français coté, propose des solutions de gestion des accès privilégiés et de contrôle des identités dont l'architecture peut être déployée en environnement on-premise ou sur infrastructure qualifiée. Dans un contexte où la compromission des fournisseurs d'identité est un vecteur d'entrée prioritaire, disposer d'une solution dont le code, l'hébergement et les équipes de support sont soumis à la juridiction européenne constitue une réduction de risque mesurable.

Ces exemples ne constituent pas une liste exhaustive, et l'article ne prétend pas à l'exhaustivité. L'objectif est de démontrer que le spectre des alternatives européennes qualifiées s'est élargi au point de rendre intenable l'argument selon lequel « il n'existe pas d'alternative crédible ». Cet argument était discutable en 2020. En 2026, il est simplement inexact.

Pour les DSI et RSSI européens : cadrer la décision, pas improviser la migration

La tentation, face aux recommandations de l'ANSSI et à la pression réglementaire cumulée de NIS2, DORA et du RGPD, est d'entrer dans une logique de conformité réactive : cocher des cases, produire des documents, et continuer à opérer sur le même stack en ajoutant des couches de contrôle compensatoires.

Cette approche a une cohérence à court terme. Elle en a très peu à moyen terme, pour trois raisons.

Premièrement, les régulateurs européens — et l'ANSSI en tête — ont clairement indiqué que la conformité documentaire ne dispense pas d'une évaluation substantielle des risques liés aux prestataires. Les contrôles NIS2 qui commencent à monter en puissance dans les États membres ne se contentent pas d'auditer des politiques : ils examinent les chaînes de dépendance réelles.

Deuxièmement, le coût d'une migration subie — c'est-à-dire contrainte par un incident de sécurité, une décision réglementaire ou une modification unilatérale des conditions d'un prestataire américain — est systématiquement supérieur au coût d'une migration planifiée. Les DSI qui ont traversé des ruptures de service imposées par des éditeurs en période de restructuration le savent de première main.

Troisièmement, et c'est peut-être le point le moins souvent articulé : la dépendance technologique a une dimension stratégique qui dépasse la sécurité au sens strict. Une organisation dont le système d'information repose structurellement sur des acteurs américains n'a pas les mêmes options de négociation, les mêmes marges d'adaptation réglementaire, ni la même capacité à répondre à des évolutions géopolitiques rapides qu'une organisation qui a diversifié ses dépendances en faveur d'acteurs soumis à la juridiction européenne.

L'adaptation du stack logiciel aux méthodes d'attaque actuelles est donc, au fond, une question de gouvernance autant que de technique. Elle impose aux DSI et RSSI de PME/ETI d'inscrire les décisions d'infrastructure dans un cadre d'analyse qui intègre explicitement la dimension de souveraineté — pas comme un principe abstrait, mais comme un critère opérationnel avec des implications concrètes sur la surface d'attaque, la conformité réglementaire et la résilience à long terme.

L'ANSSI a documenté le problème avec une rigueur croissante. Le choix des fondations reste, lui, entre les mains des organisations européennes.

*Sources mobilisées : publications publiques de l'ANSSI (rapports sur l'état de la menace, référentiel SecNumCloud), directive NIS2 (UE 2022/2555), règlement DORA (UE 2022/2554), Cloud Act (US, 2018), travaux publics du BSI et du NCSC néerlandais sur les environnements hybrides.*