Conforme et sécurisé : être ou ne pas être, telle est la question
Alors que les cyberattaques contre les services publics se multiplient, dans des systèmes pourtant audités et homologués, une question s'impose : être conforme suffit-il à être sécurisé ?
Depuis le début de l’année, les cyberattaques visant les services publics se multiplient, avec pour résultat les noms, dates de naissance, identifiants ou fichiers confidentiels de citoyens vendus au plus offrant. Les causes identifiées ? L’absence de double authentification, des mots de passe en clair dans des échanges. Pas une faille zero-day complexe, pas une opération APT de haute volée. Une hygiène de base, absente, dans des systèmes d'État soumis au RGS, audités, homologués.
On pourrait se poser une question simple : à quoi ont servi des années de conformité réglementaire, si l'on tombe sur des vulnérabilités élémentaires ? C'est cette tension, entre la conformité comme outil et la sécurité comme réalité, que cet article cherche à explorer.
Ce que la conformité a vraiment apporté
Il serait malhonnête de balayer d'un revers de main ce que les référentiels ont construit. Avant le RGS, NIS ou RGPD, le niveau de sécurité moyen des entreprises et entités publiques demeurait encore largement perfectible. Mots de passe administrateurs partagés sur post-it, serveurs exposés sans raison, droits d'administration distribués sans contrôle… étaient la norme, pas l'exception.
Les cadres réglementaires ont eu un mérite concret : mettre la sécurité à l'agenda de dirigeants qui ne voulaient pas en entendre parler. La conformité a donné aux RSSI un levier qu'ils n'avaient pas. Transformer le discours technique en obligation légale, et débloquer des budgets qui n'auraient peut-être jamais existé autrement.
Au-delà du politique, les référentiels ont instillé une discipline de base utile : gestion des actifs, patch management, journalisation, continuité d'activité. Des pratiques systématisées là où elles étaient laissées à la discrétion d'un individu ou d'un service. Et comme on ne protège pas ce qu'on ne connaît pas, la conformité a au moins forcé les organisations à se regarder en face.
Elle a aussi eu un effet structurant sur la chaîne de sous-traitance. Les exigences NIS 2, les clauses contractuelles issues du RGPD, les audits des prestataires, tout cela a progressivement élevé le niveau minimum acceptable chez les fournisseurs. Imparfaitement, certes. Mais un attaquant qui ne peut plus pénétrer directement une grande organisation cherche le maillon faible, le renforcer devenait essentiel pour réduire le risque systémique et sécuriser la chaîne de valeur.
La conformité, dans ce sens, n'est pas le problème. Il faut chercher ailleurs : comment cette conformité est appliquée dans la réalité technique.
L’envers du décor
Application technique. C'est là que les choses se compliquent.
Conforme ne signifie pas sécurisé. C'est une évidence que tout professionnel du secteur connaît, mais qui n’est pas énoncée clairement. Il est parfaitement possible d'être conforme et d'être massivement compromis.
La raison est simple : la conformité mesure des processus, pas des états. Elle vérifie qu'une politique de gestion des mots de passe existe, pas que les mots de passe sont forts. Elle valide qu'un plan de continuité est rédigé, pas qu'il fonctionnerait en conditions réelles. Elle contrôle que des procédures de gestion des incidents sont en place, pas que le SOC détecte les attaques. L'auditeur coche des cases. L'attaquant exploite des réalités.
Autour de la conformité s'est aussi développé un marché dont l'intérêt n'est pas toujours l'amélioration de la sécurité réelle. Des millions d'euros de consulting pour rédiger des politiques, préparer des audits, produire des rapports. Tout cela a un coût ; en argent, en temps, en énergie. Et le budget sécurité n'est pas extensible à l'infini. Chaque euro dépensé en documentation est un euro qui ne déploie pas correctement une application ou ne finance pas un test d'intrusion. Ce coût d'opportunité, personne ne le calcule vraiment.
Mais le plus préoccupant n'est pas financier, il est cognitif. La conformité crée parfois un sentiment de sécurité qui n'a pas lieu d'être. Quand un RSSI décroche sa certification, les mois suivants ressemblent souvent à une bataille pour défendre un budget face à des directions qui estiment que "le problème est réglé". La vigilance baisse. Les exercices de crise sont reportés. Les tests d'intrusion deviennent des formalités planifiées à l'avance. Pendant ce temps, un attaquant patient n'a pas lu la politique de sécurité, il a cartographié l'infrastructure, identifié le prestataire de maintenance avec un accès VPN permanent, et il attend.
Il y a aussi un problème structurel qu'on ne peut pas vraiment résoudre : les référentiels vivent dans le passé. Le temps qu'une directive soit rédigée, concertée, votée, transposée, il s'écoule trois à cinq ans au minimum. Les attaquants, eux, adaptent leurs techniques en semaines, parfois en heures avec l'IA générative. Les vecteurs majeurs de 2024-2025 – phishing augmenté par l'IA, attaques sur les identités cloud, compromission de la supply chain logicielle – sont adressés de manière encore partielle par les référentiels en vigueur. Se conformer strictement à la lettre d'un texte, c'est parfois construire des défenses pour les attaques d'hier. L'exemple du référentiel IPSEC DR de l'ANSSI, à peine publié et déjà challengé par les enjeux post-quantiques, illustre bien cette course impossible.
Enfin, dans les organisations les plus matures sur la conformité, on observe un paradoxe qui devrait nous alerter : les équipes les plus compétentes sont souvent celles qui produisent le plus de documents. L'analyste qui devrait chasser des menaces passe une partie de son temps à rédiger des procédures pour l'audit suivant. Les métriques de la conformité ont colonisé les métriques de la sécurité : nombre de politiques documentées plutôt que rapidité de détection des attaques (MTTD, Mean Time To Detect), taux de couverture des audits plutôt que visibilité sur les endpoints. Ces indicateurs sont compréhensibles, rassurants, présentables en comité. Ils ne mesurent pas la sécurité réelle.
Où placer le curseur
La vérité n'est ni dans la thèse ni dans l'antithèse, c'est une tension permanente à gérer, pas un problème à résoudre une bonne fois pour toutes. Mais quelques principes de bon sens méritent d'être rappelés.
La conformité devrait servir la sécurité, et non l'inverse. Elle est un chemin, pas une destination. Lorsqu'une exigence réglementaire entre en contradiction avec une décision de sécurité efficace, c'est la sécurité qui devrait primer. Combien d'organisations maintiennent des versions obsolètes et vulnérables parce qu'elles sont "certifiées" ? C'est un non-sens que la conformité devrait en théorie interdire, et qu'elle autorise parfois en pratique.
La masse documentaire improductive mériterait d'être questionnée sérieusement. La plupart des politiques de sécurité ne sont pas lues et donc pas appliquées. Les chartes signées à l'embauche sont classées sans suite. Les rapports de soixante pages n'aboutissent à aucune décision concrète. Des documents plus courts, simples mais testés dans la réalité plutôt que parfaits sur le papier, auraient probablement plus d'impact. L'ANSSI, elle-même, va dans ce sens dans ses guides récents, en mettant l'accent sur les mesures essentielles à fort impact plutôt que sur l'exhaustivité.
Les réunions de gouvernance mériteraient le même traitement. La sécurité s'est transformée, dans beaucoup d'organisations, en une production industrielle de réunions sans décision : comités de pilotage, suivis de risques, revues d'indicateurs, revues des revues. Le temps arraché aux équipes techniques est du temps soustrait à la protection réelle. Une réunion qui n'aboutit pas à une décision opérationnelle concrète est une réunion qui aurait dû être un e-mail.
Enfin, le modèle de l'audit événementiel : annuel, biannuel, est structurellement inadapté à la vitesse des menaces. La conformité doit devenir un processus en continu de support à la technique, alimenté par des données réelles, pas une photographie périodique prise dans les meilleures conditions. Les outils existent. Peu les utilisent vraiment.
Être conforme est à la portée de toute organisation qui a le bon budget et les bons consultants. Être réellement sécurisé est plus difficile, et probablement moins visible en comité de direction. Il est parfois difficile de prouver que l’on est protégé.
Ce n'est pas une critique des équipes qui font de leur mieux dans des contraintes réelles. C'est un constat sur un système qui, par construction, valorise la preuve de la conformité autant, parfois plus, que la sécurité elle-même. Les services publics récemment ciblés avaient des procédures. Ce qui a manqué, c'était l’application réelle.
La question n'est pas "conformité ou sécurité" : les deux sont nécessaires. Elle est : dans l'énergie que vous dépensez aujourd'hui, quelle part sert à prouver que vous êtes sécurisé, et quelle part à l'être vraiment ?
Il n'est pas question d'abandonner la conformité. Juste de ne plus se cacher derrière elle.