Au premier trimestre 2026, les organisations françaises ont enregistré 54 000 incidents de sécurité, soit 37 % de plus qu'au premier trimestre 2025 (i-leadconsulting.com, données T1 2026). Entre deux audits annuels, votre périmètre exposé a changé : un nouveau prestataire intégré sans revue de sécurité, un compte d'administration resté actif après un départ, une application déployée en urgence. L'audit de l'an dernier vous indique ce qu'était votre organisation. Il ne vous indique pas ce qu'elle est.
Le modèle de l'audit annuel et ses hypothèses tacites
L'audit annuel repose sur une hypothèse implicite : le niveau de conformité constaté un jour par an est suffisamment stable pour être représentatif du reste de l'année. Cette hypothèse était défendable quand les réglementations elles-mêmes fonctionnaient sur des cycles annuels. Elle ne l'est plus.
NIS2 impose une alerte précoce sous 24 heures. DORA exige un programme de tests structuré en continu. Le RGPD pose le principe d'accountability, qui oblige le responsable de traitement à démontrer le respect des principes à tout moment. Ces trois textes ont un point commun : ils mesurent votre posture sur le temps de l'incident, pas sur le temps de l'audit. Ce décalage crée une exposition que la plupart des programmes GRC actuels ne couvrent pas.
Ce que NIS2 impose réellement
L'article 23 de la directive NIS2 impose la notification d'un incident significatif sous 24 heures (alerte précoce), 72 heures (notification complète) et un mois (rapport final). Ces délais créent une contrainte opérationnelle directe : pour notifier en 24 heures, vous devez avoir détecté l'incident en quelques heures, évalué son caractère significatif au sens du règlement d'exécution UE 2024/2690, et identifié les actifs affectés.
Ce processus suppose un état de connaissance permanent de votre périmètre. Une organisation qui a audité sa posture de sécurité en janvier et ne surveille pas activement son périmètre depuis lors ne peut pas, en pratique, tenir l'article 23. La capacité à notifier en 24 heures est une contrainte d'architecture de processus autant que de sécurité technique.
Le même raisonnement vaut pour les entités qui attendent la Loi Résilience française. L'examen du texte à l'Assemblée nationale a été reporté plusieurs fois, mais les obligations substantielles de NIS2 — notamment sur la gestion des risques cybernétiques (article 21) — sont directement invocables par l'ANSSI dans le cadre de ses pouvoirs actuels. Attendre la transposition pour adapter votre programme est une stratégie à risque croissant.
Ce que DORA impose en matière de continuité
DORA est explicite sur le caractère continu de la résilience opérationnelle numérique. L'article 3(4) définit la résilience opérationnelle numérique comme la capacité d'une entité financière à construire, garantir et revoir son intégrité et sa fiabilité opérationnelles. Les verbes sont au présent et au continu.
Les institutions soumises au règlement doivent maintenir un programme de tests continus (article 25), conduire des tests TLPT basés sur les menaces (article 26) sur un cycle de trois ans, et tenir un registre de tiers ICT mis à jour en permanence (article 28). Le premier bilan à dix-huit mois révèle que les lacunes les plus courantes ne se situent pas dans la documentation des politiques, mais dans leur actualisation au fil des changements organisationnels et technologiques (voir l'analyse des lacunes persistantes dans la gouvernance ICT sous DORA). Un registre des tiers ICT tenu à jour lors de l'audit de janvier mais jamais révisé depuis ne satisfait pas l'obligation de l'article 28. La conformité est ici une propriété dynamique, pas un état figé.
Le principe d'accountability du RGPD comme précurseur
Le RGPD avait anticipé ce changement de paradigme. L'article 5(2) pose le principe d'accountability : le responsable de traitement doit être en mesure de démontrer le respect des principes du règlement, à tout moment, à toute autorité de contrôle qui le demande. Pas au moment d'un audit planifié. À tout moment.
La sanction de 500 000 euros prononcée par la CNIL contre un hôpital du Pays de la Loire le 3 septembre 2026 pour absence d'authentification à facteurs multiples illustre cette logique. Le manquement n'a pas été révélé par un audit RGPD. Il a été révélé par un incident. Ce qui figurait probablement dans les plans de sécurité de l'établissement n'avait pas été mis en oeuvre dans les faits. L'article 32 du RGPD exige des mesures techniques appropriées. La CNIL juge le caractère approprié non sur les plans, mais sur les contrôles effectivement en place au moment où l'incident survient.
Ce que "preuve continue" signifie concrètement
La transition vers un programme de conformité continue ne suppose pas de refondre votre système d'information. Elle suppose quatre changements de pratique.
Le premier est le dépôt de preuves en flux continu, et non en campagne de fin d'année. Une politique de contrôle d'accès documentée en janvier et jamais actualisée jusqu'au prochain cycle ne prouve pas que vous avez respecté l'obligation en juillet. Chaque modification de politique, chaque revue d'accès, chaque test réalisé doit être archivé avec horodatage au moment où il est produit.
Le deuxième est la cartographie vivante de votre périmètre. Vos registres de traitement RGPD, votre inventaire d'actifs NIS2 et votre registre de tiers DORA ont besoin d'être mis à jour à chaque modification significative, et non une fois par an. La Shadow IT se constitue précisément dans les délais entre deux révisions manuelles.
Le troisième est la normalisation des alertes sur les écarts. Un programme de conformité continue génère des signaux quand un contrôle planifié n'a pas été réalisé dans les délais, quand un tiers n'a pas répondu à une demande d'évaluation, ou quand une politique approuvée n'a pas encore été déployée sur les systèmes concernés. Ces signaux indiquent que le programme fonctionne, pas qu'il est défaillant.
Le quatrième est la correspondance croisée des preuves entre référentiels. Un test de pénétration produit pour NIS2 satisfait probablement une exigence équivalente dans ISO 27001 et dans DORA. Sans correspondance explicite et gérée dans votre outil GRC, vos équipes produisent plusieurs fois la même preuve sous des formats différents. Le coût opérationnel augmente sans que la couverture réelle progresse.
Le décalage que vous devez combler
En septembre 2026, la plateforme ENISA de signalement CRA est opérationnelle depuis cinq jours. Les organisations soumises à NIS2, DORA et au CRA gèrent simultanément trois horloges de notification dont les délais les plus courts se comptent en heures. Aucune de ces horloges ne s'aligne sur le calendrier de votre prochain audit.
La question à poser à votre programme GRC n'est pas : "Passons-nous un audit si on en faisait un aujourd'hui ?" Elle est : "Pouvons-nous prouver notre conformité demain matin, si un incident nous y oblige avant dix heures ?" La réponse à cette question définit si votre programme est conçu pour votre auditeur ou pour votre résilience réelle.