Une API REST qui expose les données d’un réseau de distribution d’eau potable local relève-t-elle d’une réglementation de cybersécurité renforcée ? C’est la question posée à l’équipe technique responsable du site d’un syndicat intercommunal gérant une infrastructure d’eau, dont le site headless (WordPress en back-office, front React public) diffuse des informations sur la qualité de l’eau et les interventions en cours.
La directive NIS2, dont la transposition en droit français élargit sensiblement le périmètre des entités concernées par rapport au texte précédent, couvre notamment les secteurs d’infrastructures essentielles, dont l’eau potable fait partie. Un site qui semble n’être qu’une vitrine d’information peut ainsi se retrouver, du fait du secteur d’activité de son exploitant, soumis à des obligations qu’un simple site vitrine commercial ignore complètement.
Ce que NIS2 regarde concrètement dans ce cas
La directive ne s’intéresse pas au design du site ni à son contenu éditorial, mais à la sécurité des systèmes d’information qui soutiennent une activité jugée essentielle. Pour cette architecture headless, cela signifie que l’API REST exposée publiquement, même si elle ne renvoie que des données non sensibles en apparence, entre dans le périmètre d’analyse dès lors qu’elle appartient au système d’information de l’entité concernée.
L’obligation de notification, un changement concret de posture
Le point le plus opérationnel de NIS2 pour une équipe technique tient à l’obligation de notifier un incident significatif dans un délai contraint auprès de l’autorité compétente, avec une notification initiale attendue rapidement après la détection, suivie d’un rapport plus détaillé par la suite. Concrètement, cela impose de disposer d’une procédure déjà écrite avant qu’un incident ne survienne, plutôt que d’improviser une réponse dans l’urgence.
Ce que cela change dans la configuration de l’API
Pour ce projet, la mise en conformité a porté sur trois axes techniques directement liés à l’API REST :
- La journalisation systématique des accès à l’API, avec conservation suffisante pour permettre une analyse a posteriori en cas d’incident, via les journaux du serveur web plutôt qu’une solution tierce supplémentaire.
- La restriction des routes exposées publiquement, en désactivant explicitement toute route non nécessaire au fonctionnement du front, sur le même principe qu’une réduction de surface d’attaque classique.
- Une procédure documentée de réaction en cas d’anomalie détectée, avec les coordonnées de l’autorité à notifier déjà renseignées à l’avance, pour ne pas perdre de temps précieux le jour où un incident survient réellement.
Vérifier son propre périmètre avant de conclure
Toutes les organisations qui exploitent un site headless ne sont pas concernées par NIS2 : la directive cible des secteurs et des tailles d’entité précis, définis par la transposition française. Le syndicat intercommunal de cet exemple entrait dans le périmètre du fait de son secteur d’activité, mais un site headless de commerce classique, même à fort trafic, n’y est pas nécessairement soumis pour cette seule raison.
Ce que NIS2 ne couvre pas ici
La protection des données personnelles, qui aurait pu sembler proche du sujet, relève d’un cadre entièrement distinct et ne fait pas partie du périmètre de cette directive, centrée sur la résilience des systèmes d’information critiques plutôt que sur la vie privée des personnes.
Une obligation réglementaire découverte après un incident coûte toujours plus cher, en stress comme en conformité, qu’une procédure écrite à froid.
Ce que le syndicat a mis en place concrètement
Au terme de ce chantier, le syndicat intercommunal dispose désormais d’une fiche de procédure imprimée, conservée à la fois par l’équipe technique et par la direction, listant les coordonnées de l’autorité à contacter, les informations minimales à réunir avant la notification initiale, et le nom de la personne responsable de déclencher cette procédure en cas de doute. Cette simplicité volontaire vise à ce que la procédure reste applicable même par une personne qui découvrirait l’incident un jour où l’équipe technique habituelle serait indisponible.
En résumé
Un site headless qui semble anodin peut relever de NIS2 du seul fait du secteur d’activité de son exploitant : la vérification du périmètre applicable doit précéder toute décision technique, et la notification d’incident doit être préparée avant qu’elle ne devienne urgente.
