NIS 2 en France : trois architectures sous la loupe — et pourquoi le choix du socle logiciel engage bien plus que la conformité

# NIS 2 en France : trois architectures sous la loupe — et pourquoi le choix du socle logiciel engage bien plus que la conformité

La transposition française de NIS 2 est enfin effective. Pour les DSI de PME/ETI concernées, la question n'est plus « faut-il s'y conformer ? » mais « quel socle logiciel nous permet de le faire sans nous enfermer davantage ? ». Ce n'est pas un détail : l'architecture choisie aujourd'hui pour répondre aux exigences de NIS 2 (gestion des incidents, continuité, chaîne d'approvisionnement logicielle, contrôle d'accès) va structurer votre dépendance — ou votre marge de manœuvre — pour les cinq à dix ans à venir.

Trois approches dominent les arbitrages actuels chez nos lecteurs. Aucune n'est neutre sur le plan budgétaire ou géopolitique.

Les trois approches en présence

Approche A — Hyperscaler américain comme épine dorsale de conformité

L'entreprise s'appuie sur un acteur dominant américain (Microsoft 365 / Azure Security Center, ou équivalent AWS) pour centraliser la détection d'incidents, la gestion des identités et la journalisation. La conformité NIS 2 est adressée via les modules de sécurité natifs de la plateforme.

Approche B — Socle européen certifié avec intégration outillage spécialisé

L'entreprise choisit un hébergeur qualifié SecNumCloud ou équivalent européen reconnu, et s'appuie sur des éditeurs européens spécialisés en SIEM, IAM ou gestion de crise cyber. L'intégration est plus manuelle, mais le périmètre de maîtrise est explicitement tracé.

Approche C — Architecture hybride à gouvernance contractuelle renforcée

L'entreprise conserve des outils américains pour certains flux (messagerie, bureautique) mais isole les données et processus critiques NIS 2 sur des socles européens. Elle documente contractuellement les flux, les droits d'accès tiers et les conditions de réversibilité.

Critère 1 — Architecture et maîtrise du périmètre de données

| | Approche A | Approche B | Approche C |

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

| Localisation des logs d'incidents | Datacenters US (jurisdic. américaine possible) | EU, sous droit européen | Mixte — dépend du cloisonnement |

| Contrôle sur les APIs de sécurité | Limité aux paramètres exposés par l'éditeur | Accès complet ou code source auditable | Partiel selon les briques |

| Auditabilité externe | Via outils propriétaires | Via standards ouverts (OCSF, OpenTelemetry…) | Variable |

| Réversibilité technique | Forte dépendance aux formats propriétaires | Formats interopérables favorisés | À contractualiser explicitement |

Ce que ça change pour le DSI. NIS 2 impose la capacité à notifier l'ANSSI sous 24 heures en cas d'incident significatif. Si vos logs sont dans un silo propriétaire américain, vous dépendez de l'API et du SLA de l'éditeur pour accéder à vos propres données d'incident. Ce n'est pas un risque théorique : plusieurs équipes sécurité ont découvert en situation de crise que l'export de logs en masse est throttlé ou soumis à des conditions d'usage restrictives. L'approche A expose à ce risque structurellement. L'approche B l'élimine par construction. L'approche C le neutralise à condition que le cloisonnement soit réel et documenté, pas cosmétique.

Critère 2 — Intégration dans la chaîne d'approvisionnement logicielle (supply chain cyber)

NIS 2 cible explicitement la sécurité de la chaîne d'approvisionnement. Pour une PME/ETI, cela se traduit concrètement : vous devez être capable de cartographier vos dépendances logicielles critiques, d'identifier les mises à jour de sécurité, et de démontrer que vos fournisseurs respectent des exigences minimales.

Approche A. L'acteur américain propose des tableaux de bord de conformité intégrés. C'est lisible, rapide à déployer, et souvent bien packagé commercialement. Mais la cartographie des dépendances est filtrée par l'éditeur lui-même : vous voyez ce qu'il veut bien exposer dans son écosystème. Les composants tiers hors de sa sphère sont peu ou mal couverts. Et surtout : l'éditeur est lui-même un fournisseur critique dont vous ne maîtrisez ni le code ni les sous-traitants de traitement.

Approche B. Des éditeurs comme Wallix (gestion des accès privilégiés) ou Tehtris (détection/réponse) construisent leur conformité NIS 2 sur une logique d'auditabilité native. La chaîne de dépendances est documentable indépendamment de la volonté de l'éditeur. Le DSI peut mandater un audit externe sans passer par le fournisseur. C'est ce que NIS 2 attend — et ce que l'ANSSI valorise dans ses référentiels.

Approche C. Le risque est l'illusion du contrôle. Une entreprise qui isole ses données critiques sur un hébergeur européen mais laisse tourner sa détection d'incidents sur un SIEM américain n'a pas réellement cloisonné sa chaîne cyber. L'approche C n'est solide que si la gouvernance documentaire suit rigoureusement l'architecture technique.

Critère 3 — Gouvernance et exposition au risque tarifaire

C'est le critère que les directions financières comprennent immédiatement, et que les DSI doivent porter avec des chiffres.

Les acteurs américains dominants ont démontré, ces trois dernières années, une capacité à réviser unilatéralement leurs conditions tarifaires sur les modules de sécurité. Le pattern est documenté : fonctionnalité d'abord intégrée gratuitement dans la licence de base, puis migrée vers un tier supérieur lors d'un renouvellement. Les fonctions de journalisation avancée, de gestion des identités multi-facteurs ou de détection comportementale sont désormais systématiquement dans des niveaux de licence supérieurs chez les acteurs dominants américains.

Pour une ETI de taille intermédiaire, cela signifie que le budget alloué à la conformité NIS 2 en année 1 ne préjuge pas du budget en année 3. La conformité devient une variable dépendante de la politique tarifaire d'un acteur sur lequel vous n'avez aucun levier.

Approche A. Exposition maximale. La conformité NIS 2 est adressée via des modules dont la tarification évolue indépendamment de vos contraintes réglementaires. Si l'ANSSI renforce ses exigences (ce qui est probable au fil des versions du référentiel), vous dépendez de la volonté de l'éditeur d'intégrer ces évolutions dans votre niveau de licence actuel.

Approche B. Le budget est plus prévisible parce que les contrats avec des éditeurs européens spécialisés sont plus facilement négociables sur la durée, et parce que les fonctionnalités de conformité ne sont pas des add-ons mais des fonctions cœur de métier pour ces acteurs. Le risque de dérive tarifaire n'est pas nul, mais il est contractuellement encadrable.

Approche C. Dépend entièrement de la qualité du travail contractuel en amont. Une approche hybride sans clauses de réversibilité, sans plafonnement d'évolution tarifaire sur les briques critiques, et sans exit plan documenté, offre la complexité de l'hybride sans ses bénéfices. C'est le scénario le plus fréquent chez les ETI qui ont choisi l'hybride par défaut plutôt que par stratégie.

Critère 4 — Délai de mise en conformité opérationnelle

NIS 2 est active. L'ANSSI monte en puissance sur les contrôles. Le délai n'est plus un argument pour différer.

| | Approche A | Approche B | Approche C |

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

| Délai de déploiement initial | Court (outillage déjà en place pour beaucoup) | Moyen (intégration à prévoir) | Variable |

| Effort d'intégration SI existant | Faible si déjà dans l'écosystème | Moyen à élevé | Élevé (double cohérence à maintenir) |

| Capacité à évoluer avec le référentiel ANSSI | Dépend de la roadmap de l'éditeur | Maîtrisée en interne | Partielle |

| Risque de non-conformité résiduelle | Faible à court terme, croissant à moyen terme | Faible si socle bien choisi | Modéré si gouvernance rigoureuse |

L'approche A est tentante pour sa rapidité. Mais elle crée une conformité de façade sur un point précis de NIS 2 : la maîtrise de la chaîne d'approvisionnement. Un éditeur dominant américain ne peut pas, par construction, être à la fois votre outil de conformité et un fournisseur critique auditable indépendamment. C'est une contradiction que les auditeurs de l'ANSSI commencent à pointer.

Ce que le DSI doit trancher maintenant

NIS 2 n'est pas seulement un exercice de conformité. C'est le premier texte européen qui crée une obligation légale de cartographier et maîtriser votre chaîne logicielle — y compris vos fournisseurs. C'est précisément là que se joue la souveraineté numérique au niveau opérationnel.

Le choix de l'architecture NIS 2 est donc un choix stratégique déguisé en projet technique. Choisir l'approche A pour sa facilité, c'est déléguer votre conformité réglementaire à un acteur sur lequel vous n'avez aucun levier contractuel, réglementaire ou géopolitique. C'est également accepter que votre budget sécurité soit une variable dépendante d'une politique commerciale étrangère.

L'approche B demande un effort d'intégration réel. Elle impose de travailler avec des équipes moins dotées en marketing que les acteurs dominants. Mais elle positionne le DSI comme l'architecte de sa propre conformité — ce que NIS 2, in fine, exige.

L'approche C est viable, à condition qu'elle soit le résultat d'une décision délibérée et documentée, pas d'une accumulation de compromis non assumés.

La législation a bougé. La question qui reste est simple : qui contrôle votre réponse à un incident cyber à 2h du matin — vous, ou les conditions générales d'un contrat signé à Seattle ?