Prouver sa conformité dans la durée, pas une fois

Un technicien active le MFA sur le compte Microsoft 365 d'un client, prend une capture d'écran, et la range dans le dossier de preuves. Huit mois plus tard, l'assureur cyber du client — ou son auditeur ISO 27001 — demande la preuve que le MFA a été actif en continu depuis le dernier renouvellement. La capture ne le prouve pas. Elle prouve seulement qu'à l'instant où elle a été prise, le paramètre était activé.

C'est l'écart le plus fréquent entre ce qu'un technicien appelle une preuve et ce qu'un auditeur appelle une preuve — et il coûte cher au moment précis où on le découvre, c'est-à-dire pendant l'audit.

Qu'est-ce qu'un auditeur appelle une preuve ?#

Une observation datée, répétée dans le temps, qui montre qu'un contrôle a tenu sur toute la période concernée — pas une déclaration ponctuelle qui montre qu'il fonctionnait à un instant donné. La norme ISO/IEC 27001:2022 le formalise à sa clause 9.1 : l'organisme doit surveiller et mesurer l'efficacité de ses contrôles, et conserver des informations documentées comme preuve des résultats — pas comme preuve qu'un technicien a un jour vérifié le paramètre.

Pour un technicien, la preuve répond à « est-ce que c'est activé ». Pour un auditeur, elle répond à « est-ce que c'était activé pendant toute la période sous revue, et comment le savez-vous sans être allé vérifier chaque jour ».

La profession de l'audit sépare ces deux questions depuis longtemps, et le vocabulaire est utile même si vous ne passez jamais de certification. D'un côté, la preuve de conception : le contrôle existe, il est configuré comme la politique le prévoit, quelqu'un peut le montrer à l'écran. De l'autre, la preuve d'efficacité opérationnelle : le contrôle a produit l'effet attendu, sans interruption non expliquée, pendant toute la période sous revue. Une capture d'écran répond à la première question et laisse la seconde entièrement ouverte. C'est exactement la différence entre un rapport d'attestation portant sur un instant et un rapport portant sur une période — et c'est la seconde qu'un assureur ou un client régulé finit toujours par demander.

Pourquoi une attestation ponctuelle ne suffit-elle jamais ?#

Parce qu'elle ne dit rien de ce qui s'est passé avant ou après le jour où elle a été produite. Un audit de certification ISO 27001, ou un contrôle mené par une autorité de supervision, porte sur une période — généralement l'année écoulée — pas sur l'instant de l'audit. Une attestation unique, aussi sincère soit-elle au moment où elle est signée, ne couvre littéralement qu'un seul jour sur trois cent soixante-cinq.

Le risque n'est même pas la malhonnêteté. C'est qu'une attestation ponctuelle collectée juste avant l'audit décrit exactement la période la moins représentative de l'année : celle où tout le monde vient de vérifier et de corriger ce qui ne l'était pas.

Et l'intervalle entre deux relevés se paie désormais plus cher qu'avant : la compression du délai avant exploitation fait qu'un écart resté invisible trois mois n'est plus un écart théorique.

Il y a une raison plus mécanique encore, et elle surprend beaucoup de prestataires la première fois. Un auditeur ne relit pas la période entière : il échantillonne. Il choisit des dates à l'intérieur de la période sous revue — souvent sans vous prévenir de lesquelles — et demande la preuve de l'état du contrôle à ces dates-là. Si votre dossier ne contient qu'une capture datée de la veille de l'audit, chaque date échantillonnée est un trou. Vous ne pouvez pas les combler après coup : une console de gestion affiche l'état d'aujourd'hui, pas celui du 14 mars. Le relevé du 14 mars existait ce jour-là ou il n'existe pas.

Comment un paramètre de sécurité se dérègle-t-il sans que personne ne l'ait fait exprès ?#

Par l'usage normal du système, pas par une faute. Un utilisateur se retrouve bloqué hors de son compte, un technicien désactive temporairement le MFA pour le débloquer un vendredi soir, et personne ne pense à le réactiver le lundi. Une mise à jour de la console de gestion réinitialise une stratégie de groupe à sa valeur par défaut. Un nouvel appareil rejoint le parc avant que la politique de conformité ne lui soit appliquée. Une règle de sécurité cible un groupe d'utilisateurs dont la composition change au fil des embauches et des départs, sans que personne ne resynchronise le périmètre.

Chacun de ces événements est anodin pris isolément. Additionnés sur douze mois, sur des dizaines de comptes et plusieurs outils, ils produisent exactement ce qu'un auditeur redoute : un contrôle qui était vrai le jour où on l'a vérifié, et qui ne l'est plus depuis trois mois sans que personne ne s'en soit rendu compte.

Ce qui rend ces dérives coûteuses, ce n'est pas leur gravité, c'est leur discrétion. Aucune ne déclenche d'alerte, parce qu'aucune n'est une panne : le système fonctionne exactement comme on le lui a demandé. Mises côte à côte, elles ont toutes la même signature.

La colonne de droite est la seule qui réponde à la question de l'auditeur. Les trois autres décrivent l'état d'aujourd'hui, ce qui est utile pour exploiter mais sans valeur pour prouver.

Qu'est-ce qu'une preuve doit avoir pour résister à un audit ?#

Cinq propriétés, et aucune n'est facultative : sans l'une d'elles, le dossier tombe sur la question suivante. La règle qui les résume tient en une phrase — l'absence de relevé est une absence de preuve, pas une preuve favorable.

Une preuve non datée ne prouve rien sur une période. Une preuve écrasée par la suivante — un tableau de bord qui n'affiche que le dernier relevé — perd la trace du moment où le contrôle a cessé de tenir. Et un jour sans mesure ne doit jamais être compté comme un jour conforme par défaut, parce que le premier auditeur qui s'en aperçoit remettra en cause tout le reste du dossier, y compris les parties qui étaient justes.

À quoi ressemble un relevé de preuve, concrètement ?#

À une ligne par mesure, pas à un document. Voici la forme minimale d'une série exploitable pour un seul contrôle — l'application du MFA sur les comptes Microsoft 365 d'un client — sur une poignée de jours.

Six lignes, et l'histoire complète est déjà lisible. Le 14 mars, un compte est sorti du périmètre du MFA. Le 15, la collecte n'a pas tourné — et la ligne le dit, au lieu de reconduire silencieusement la valeur de la veille. Le 16, un compte a été créé : le dénominateur passe de 52 à 53, le nouveau compte n'est pas encore couvert par la stratégie, et la couverture baisse une seconde fois sans qu'aucun réglage n'ait été modifié par qui que ce soit. Le 17, les deux écarts sont corrigés.

Une capture d'écran prise le 17 mars aurait montré 100 % et aurait été parfaitement sincère. Elle aurait aussi effacé les trois jours qui précèdent, dont celui où la collecte n'a pas tourné — le seul point du dossier qu'un auditeur consciencieux vous demandera d'expliquer.

Que fait un auditeur d'une série de relevés datés ?#

Trois choses, dans cet ordre, et il vaut mieux les avoir anticipées. Il vérifie d'abord le dénominateur : d'où sort le chiffre 52, comment le périmètre est constitué, et ce qui se passerait si un poste n'était dans aucun inventaire. Un taux de conformité calculé sur une population que vous choisissez vous-même n'a pas de valeur probante, et c'est la première chose qu'un auditeur expérimenté teste.

Il échantillonne ensuite. Il prend deux ou trois dates dans la période et vous demande de retrouver, à la source, l'état que votre relevé affirme. Si la ligne du 14 mars dit 51 sur 52, il veut savoir quel compte manquait et pourquoi. Une série de relevés qui ne permet pas de redescendre au détail ne survit pas à cette étape.

Il regarde enfin les trous et les décrochages — et c'est là que l'intuition de beaucoup de prestataires est à l'envers. Une courbe à 100 % sur trois cent soixante-cinq jours, sans un seul creux, n'inspire pas confiance : elle suggère que la mesure ne mesure pas grand-chose. Une série qui montre un décrochage le 14 mars, sa cause, et sa correction le 17, décrit un dispositif de contrôle qui fonctionne. La norme ISO/IEC 27001 prévoit d'ailleurs explicitement ce cas à sa clause 10.2 : une non-conformité constatée doit être traitée, ses causes examinées, et l'action corrective conservée comme information documentée. Un écart documenté et corrigé est un élément de conformité, pas un aveu.

Ce qui pose problème, ce n'est jamais l'écart. C'est l'écart qu'on découvre pendant l'audit parce que personne ne mesurait.

Quels contrôles peut-on relever automatiquement, et lesquels ne le seront jamais ?#

Une partie seulement, et il faut le dire franchement plutôt que de laisser croire qu'un outil remplace la gouvernance. Les contrôles dont l'état vit dans une console interrogeable se relèvent en continu ; ceux qui reposent sur un acte humain ou un document se prouvent autrement, et il n'y a pas d'automatisation honnête pour eux.

La colonne de droite n'est pas un pis-aller : c'est la même exigence appliquée à des preuves d'une autre nature. Un compte rendu de revue d'accès non daté a exactement le même défaut qu'une capture d'écran de console non datée.

Que faut-il collecter en continu plutôt que reconstituer au moment de l'audit ?#

Des relevés techniques réguliers de chaque contrôle vérifiable automatiquement — MFA appliqué, sauvegarde exécutée avec succès, agent de protection des postes présent, correctifs à jour — conservés individuellement plutôt qu'agrégés dans un seul indicateur qui écrase l'historique. La différence pratique est simple à formuler : au lieu de répondre « oui, le MFA est actif » une fois par an, vous pouvez répondre « le MFA a été appliqué sur au moins 95 % des postes pendant 91 des 92 derniers jours », avec la date du jour qui a décroché et ce qui s'est passé ce jour-là.

La seconde réponse est vérifiable. La première ne l'est pas — elle demande à l'auditeur de vous croire sur parole, ce qui n'est ni son rôle ni le vôtre de le lui demander.

Le même raisonnement vaut pour les décisions, pas seulement pour les mesures. Un registre de conformité qui n'affiche que son état actuel a le défaut du tableau de bord : il ne dit pas quand une entrée est passée de « non conforme » à « conforme ». Un historique qui conserve l'ancien statut, le nouveau statut et la date de bascule répond à une question que l'auditeur pose systématiquement — depuis combien de temps cet écart est-il ouvert, et qu'a-t-on fait entre-temps.

Combien de temps faut-il conserver ces relevés ?#

Au minimum la période que couvre l'audit, et en pratique davantage. La période sous revue d'un audit ISO 27001 est généralement l'année écoulée, mais la durée d'un cycle de certification et le contenu exact des audits de surveillance dépendent du schéma appliqué par l'organisme certificateur : c'est à lui qu'il faut demander la période à couvrir, pas à un article de blog. Côté assurance, la question se pose au renouvellement, donc chaque année, sur les douze mois précédents.

La règle pratique qui évite de se tromper : conservez une période complète de plus que celle qu'on vous demande aujourd'hui. Un dossier qui commence exactement le jour où l'audit commence donne l'impression — souvent injuste — d'avoir été constitué pour l'occasion. Et gardez les relevés au format où ils ont été produits, avec leur horodatage d'origine : un export retraité, recalculé ou reformaté au moment de l'audit perd précisément la propriété qui en faisait une preuve.

C'est le principe derrière le module de dérive continue de Vigicap : chaque relevé de connecteur est conservé, jamais écrasé, ce qui permet de restituer une couverture datée comme celle citée plus haut plutôt qu'une capture d'écran isolée. Le registre de conformité suit la même règle : chaque changement de statut d'un objectif conserve l'ancien statut, le nouveau et sa date, au lieu de remplacer la valeur précédente.