Audit interne — extrait
SMSI · 5 — dix-sept contrôles passés en revue sur l'infrastructure qui héberge ce portfolio : ce qui est conforme, ce qui ne l'est qu'à moitié, et l'écart structurel du tableau — celui qui ne peut pas se fermer.
Un rapport d'audit où tout est conforme ne vaut rien. Il prouve seulement qu'on n'a pas cherché. Lister ses propres écarts, avec une échéance de traitement pour chacun, est ce qui rend la démarche crédible — et c'est aussi ce qui la rend désagréable à écrire.
Méthode
L'audit est mené par la même personne que celle qui exploite le système. Ce n'est pas un audit indépendant au sens de la norme, et le seul écart du tableau ci-dessous le dit à sa place. Ce qui peut être tenu malgré cette limite, et qui l'est : chaque contrôle part d'une exigence de la Déclaration d'Applicabilité, se vérifie par une observation datée sur la machine ou dans le dépôt, et se conclut par un des trois états ci-dessous.
- Conforme — la mesure est en place et son fonctionnement a été constaté, pas supposé.
- Partiel — la mesure existe mais lui manque une propriété attendue : elle est manuelle là où elle devrait être automatique, ou locale là où elle devrait être centralisée.
- Écart — la mesure n'est pas en place. Chaque écart porte une échéance ou une justification écrite de son report.
Les dix-sept contrôles
| # | Contrôle | Constat | État |
|---|---|---|---|
| C1 | Séparation des rôles RSSI / administrateur / DPO | Une seule personne cumule les trois rôles | Écart |
| C2 | Chiffrement en transit | HTTPS déployé sur le domaine, vérifié | Conforme |
| C3 | Sauvegarde des secrets applicatifs — portfolio | Sauvegarde faite et restauration testée | Conforme |
| C4 | Sauvegarde des secrets applicatifs — second service | Sauvegarde faite après détection de l'oubli | Conforme |
| C5 | Sauvegarde et instantané de la machine | La base applicative est répliquée en continu et un instantané est pris chaque nuit ; l'image de la machine elle-même reste un geste manuel, faute de politique récurrente disponible pour ce type de volume | Partiel |
| C6 | Alerte de dépassement budgétaire cloud | Alerte configurée au seuil le plus bas possible et vérifiée | Conforme |
| C7 | Supervision externe et alerte | Supervision externe active sur la disponibilité ; aucune collecte ni corrélation centralisée des journaux | Partiel |
| C8 | Protection contre les tentatives répétées sur l'accès d'administration | Bannissement automatique actif, déclenchement testé | Conforme |
| C9 | Cycle de vie de la clé d'administration | Clé remplacée le 15/09/2026 par une clé d'algorithme moderne protégée par phrase de passe ; l'ancienne était en place depuis la création de la machine et n'avait aucune protection | Conforme |
| C10 | Exposition réseau non voulue | Le service applicatif n'écoute plus que localement, derrière le frontal (corrigé, commit daté) | Conforme |
| C11 | En-têtes de sécurité HTTP | Politique de contenu stricte, HSTS, anti-cadrage, anti-sniffing, politique de référent | Conforme |
| C12 | Anonymisation des journaux (RGPD) | La troncature est appliquée par tous les sites depuis le 13/09/2026, et les journaux archivés qui portaient encore des adresses complètes ont été tronqués le 14/09/2026 — plus aucune adresse entière sur le disque, recompté à zéro | Conforme |
| C13 | Rétention des journaux | Durées bornées et explicites, rotation automatique aux deux couches | Conforme |
| C14 | Isolation des processus applicatifs | Un utilisateur dédié par service, sans shell là où il est inutile | Conforme |
| C15 | Mises à jour de sécurité | Canal de maintenance étendue attaché, mises à jour en attente appliquées | Conforme |
| C16 | Politique de montée de version | Montée de version majeure explicitement interdite et documentée — contrôle préventif | Conforme |
| C17 | Séparation du JavaScript et politique de contenu | Aucun script en ligne dans les vues, gestionnaires externalisés | Conforme |
Ce que ce tableau ne donne pas. L'état d'un contrôle se publie ; son paramétrage non. Les seuils, les chemins, les versions, les durées exactes et les noms de fichiers restent dans le rapport interne : ils ne changent rien à la lecture d'un auditeur, et ils épargnent du travail à quelqu'un qui chercherait où appuyer.
Synthèse
| État | Nombre | Lesquels |
|---|---|---|
| Conforme | 14 | C2, C3, C4, C6, C8, C9, C10, C11, C12, C13, C14, C15, C16, C17 |
| Partiel | 2 | C5 (instantané machine manuel), C7 (pas de journalisation centralisée) |
| Écart | 1 | C1 (cumul des rôles) |
Sept de ces quatorze conformités n'en étaient pas à la revue précédente : elles viennent du plan d'actions, pas d'un constat initial favorable. Deux d'entre elles, C9 et C12, ont leur histoire racontée plus bas — elle est plus instructive que les douze autres réunies.
Le seul écart qui reste, en toutes lettres
C1 — Cumul des rôles RSSI, administrateur et DPO
La même personne définit la politique, l'applique sur la machine, et contrôle qu'elle est appliquée. Il n'y a aucun regard extérieur, et l'audit lui-même en souffre : un auditeur qui a écrit la mesure qu'il vérifie ne la regarde pas avec les mêmes yeux.
État : écart structurel, accepté. Il ne se corrige pas à ce périmètre — un système personnel n'a pas trois personnes à y affecter. Ce qui est fait à la place : écrire les décisions au moment où elles sont prises plutôt qu'après coup, et publier les écarts pour que le regard extérieur manquant puisse au moins venir du lecteur.
C'est aussi le seul écart que ce dossier ne prétendra jamais refermer. Les autres se traitent ; celui-ci se déclare.
Les deux constats partiels
C5 — instantané de la machine. La donnée applicative est couverte : elle est répliquée en continu vers un stockage objet, et un instantané chiffré est pris chaque nuit. Ce qui manque, c'est l'image de la machine elle-même, qui reste un geste manuel déclenché par un rappel — la console de l'hébergeur n'offre pas de politique récurrente pour ce type de volume seul. Une mesure qui dépend d'un rappel dans un agenda n'est pas une mesure automatisée, et elle est cotée comme telle.
C7 — supervision. La disponibilité est surveillée de l'extérieur et alerte en cas de coupure. Il n'y a en revanche aucune collecte centralisée des journaux, donc aucune corrélation possible entre deux événements survenus sur deux couches différentes. Un incident visible déclenche une alerte ; un incident qui ne fait que laisser des traces, non.
C9 — l'écart refermé, et ce qu'on a trouvé en le refermant
Ce contrôle était un écart, avec une échéance au 15 octobre 2026. Il est refermé le 15 septembre, un mois avant. Ce n'est pas le calendrier qui a décidé : c'est la découverte, la veille, que la clé concernée existait en clair à plusieurs endroits.
La clé qui administrait la machine était celle créée avec elle, sans phrase de passe, jamais remplacée. Elle est désormais remplacée par une clé d'algorithme moderne protégée par phrase de passe. La procédure suivie est celle écrite dans la politique SSI — ajouter la nouvelle avant de retirer l'ancienne — et elle a été vérifiée dans les deux sens : connexion réussie avec la nouvelle clé et connexion refusée avec l'ancienne, depuis un second terminal, avant toute suppression.
Note du 15/09/2026 — l'audit de la veille avait écarté un risque qui existait. Le constat du 14/09 portait, sur les copies en clair de cette clé : « écarté par vérification : pas dans un dépôt de code, pas synchronisé vers un cloud ». La seconde moitié était fausse. Un doublon de la clé privée, sans phrase de passe, était synchronisé vers un espace de stockage en ligne grand public — donc sorti de la machine, chez un tiers, depuis une date inconnue.
Il n'a pas été trouvé en relisant le constat. Il a été trouvé parce que quelqu'un a ouvert le dossier pour agir dessus. Une vérification qui conclut « écarté » sans dire comment elle a cherché n'est pas une vérification, c'est une opinion datée. Le constat du 14/09 ne disait pas s'il avait inspecté les dossiers synchronisés ou seulement supposé qu'il n'y en avait pas ; la réponse était la seconde.
La conséquence est bornée : la clé concernée est révoquée, elle n'ouvre plus rien. La leçon ne l'est pas. Une exposition de ce type ne se mesure pas au moment où on la découvre mais à sa durée, et cette durée est inconnue — c'est précisément ce qui la rend impossible à minimiser après coup. La rotation est la seule réponse qui vaille, et c'est pour ça qu'elle est passée avant tout le reste.
Ce que la fermeture de C9 ne ferme pas. Quatre autres secrets, sans rapport avec l'infrastructure de ce site, sont toujours en clair dans le même dossier — et donc toujours synchronisés. Ils ne relèvent pas du périmètre de ce SMSI, ce qui explique qu'ils n'aient pas été traités dans la même passe, mais pas qu'ils soient acceptables. Le geste d'hygiène qui reste à faire est plus large que le contrôle qui vient d'être refermé, et l'écrire ici est la seule façon de ne pas le perdre de vue.
C12 — le contrôle qui a fait l'aller-retour
Ce contrôle était coté conforme. Il est passé partiel le 13/09/2026, puis est redevenu conforme le 14/09. Les deux notes ci-dessous sont conservées dans l'ordre où elles ont été écrites : elles sont l'histoire du contrôle, pas son état. Les effacer reviendrait à corriger en silence.
Note du 13/09/2026 — C12 recoté conforme → partiel. La troncature de l'adresse IP était bien appliquée par le site principal, et par lui seul : deux autres sites du périmètre écrivaient l'adresse complète dans le même fichier de journal. La mesure existait, elle ne couvrait qu'un tiers de ce qu'elle annonçait couvrir — c'est la définition du partiel.
La cause est une règle de lecture du frontal, pas un oubli : le format de journal anonymisé était défini dans le fichier de configuration du site principal, donc lu après les autres. Un format de journal défini plus bas qu'il n'est utilisé est invisible, et le frontal retombe silencieusement sur son format par défaut, qui écrit l'adresse entière. Aucune erreur au démarrage, aucune alerte : deux sites écrivaient en clair dans le fichier que le troisième anonymisait.
Ce qui a été corrigé : la définition du format a été sortie du fichier du site pour être lue avant tout le reste, et les deux sites concernés nomment désormais ce format explicitement. La correction a été vérifiée sur une requête réelle, avant et après, pas sur la lecture de la configuration.
Ce que cette recotation dit de l'audit précédent : le contrôle avait été vérifié en lisant la configuration du site principal, pas en lisant le journal produit. Un contrôle se vérifie sur sa sortie. C'est le même enseignement que la correction de durée du 12/09 sur le registre — une mesure écrite n'est pas une mesure appliquée — et il tombe cette fois du mauvais côté. Le format exact d'une ligne de journal, et ce qu'il laisse subsister, sont publiés à la section 5 du registre.
Note du 14/09/2026 — C12 recoté partiel → conforme. La note de la veille se terminait par une raison de rester partiel : les journaux déjà écrits gardaient leurs adresses complètes jusqu'à la fin de leur rétention, le 27/09. Cette raison a été supprimée plutôt qu'attendue.
15 310 lignes portant une adresse complète, réparties sur 15 fichiers archivés et compressés, ont été tronquées. Recompte indépendant après traitement : zéro. Le traitement a été fait sur copie, vérifié, puis la copie a remplacé l'original en préservant droits et propriétaire ; le fichier en cours d'écriture n'a pas été touché, il était déjà propre. Rotation, configuration du frontal et service ont été recontrôlés ensuite.
Pourquoi ne pas avoir attendu le 27. L'article 5.1.c du RGPD impose de minimiser, pas d'attendre que le surplus expire. Une donnée collectée en trop reste une donnée collectée en trop pendant qu'elle dort sur un disque, et « j'ai laissé la rotation faire » n'est pas une mesure de conformité : c'est le passage du temps. Treize jours d'attente auraient suffi à refermer le contrôle sans rien faire — c'est précisément pour ça qu'il fallait faire quelque chose.
Le plan d'actions
Huit actions ont été ouvertes à la revue précédente. Les huit sont soldées, dont quatre avant leur échéance — la dernière étant C9, refermé un mois avant le terme qu'il s'était donné.
Trois écarts nouveaux ont été identifiés pendant cet audit, c'est-à-dire qu'ils ne figuraient dans aucun plan précédent. Deux étaient encore ouverts à la date de l'audit et sont publiés sur la fiche du projet : la continuité n'avait jamais été testée depuis la suppression de la machine de secours, et aucun scan de vulnérabilités ne tournait en continu. Depuis, une restauration de la base depuis la sauvegarde hors machine a été rejouée (7 octobre 2026) et un contrôle hebdomadaire des dépendances et des secrets tourne en intégration continue ; la restauration d'une machine entière reste non testée et le dit. Le troisième — l'absence de sauvegarde dédiée de la base applicative — a été traité depuis, et c'est ce qui fait passer C5 d'écart à partiel.
Journal des incidents
Le SMSI tient un journal des incidents (Annexe A, A.5.24 à A.5.28). Il compte onze entrées depuis août 2026, dont trois ajoutées le 13 septembre 2026, une le 14 et une le 15. Chacune enregistre la date, l'impact réel, la cause, la correction et la leçon — la leçon étant la seule colonne qui serve à quelque chose une fois l'incident clos.
Le journal complet n'est pas publié : plusieurs entrées décrivent la configuration de la machine au moment où elle était fautive. En voici deux en entier, choisies parce que leurs leçons portent sur la chaîne de vérification elle-même.
| Rubrique | Contenu |
|---|---|
| Date | 12 septembre 2026, 16:09 → 16:26 UTC (17 minutes) |
| Impact | Le site a été servi sans aucune feuille de style. Il répondait normalement pendant toute la durée : c'est un incident de présentation, pas de disponibilité. |
| Cause | Deux sessions de travail automatisées écrivaient sur la même branche. L'une poussait encore des commits quand l'autre a fusionné la demande de tirage, figeant son contenu sur un commit intermédiaire fautif où la feuille de style principale avait été remplacée par un mot-témoin. Le commit correctif n'a jamais été inclus. |
| Cause aggravante | La chaîne d'intégration continue est passée verte sur ses sept étapes — tests, contraste, captures d'écran, débordement, erreurs console — alors que le site n'avait plus de style. Aucune étape ne regardait si les fichiers servis contenaient encore quelque chose. |
| Détection | Visuelle, par une personne, sur une capture d'écran. Aucune alerte automatique ne s'est déclenchée. |
| Correction | Feuilles restaurées en 17 minutes. Puis deux mesures : un garde-fou ajouté à la chaîne d'intégration, qui refuse tout fichier de style ou de script vidé et impose un plancher de taille aux deux feuilles structurantes ; et une règle de gouvernance — une seule session par branche, et pas de fusion tant qu'une session écrit encore dessus. |
| Leçon | Une chaîne de vérification qui ne contrôle que le comportement peut être entièrement verte sur un livrable vide. Il faut au moins un contrôle d'intégrité sur les artefacts eux-mêmes. |
| Rattachement | A.8.32 — Gestion des changements, jusque-là cotée partielle : c'est précisément l'absence de processus formel de changement qui est en cause. Le volet disponibilité n'est pas engagé, le service n'a pas été interrompu ; l'y rattacher serait une fausse certitude. |
Un second incident, sur la page qui prouve les autres
Le 13 septembre 2026, la page des preuves a affiché pendant une vingtaine de minutes un faux vert : la ligne « cloisonnement de l'origine » annonçait que l'adresse d'origine ne répondait pas, donc que le site n'était joignable qu'à travers le filtrage. Aucune exposition réelle, aucune donnée en jeu — mais une affirmation de sécurité publiée sans qu'aucune mesure ne l'établisse.
La sonde tourne sur la machine d'origine elle-même. Une machine virtuelle ne joint pas sa propre adresse publique : la requête échoue toujours, quel que soit l'état réel du filtrage. La sonde prenait cette absence de réponse pour une preuve de cloisonnement, alors qu'elle ne prouvait que sa propre position. Le garde-fou prévu pour ce cas — détecter qu'on s'exécute sur la machine d'origine — ne pouvait pas fonctionner : l'interface réseau n'y porte que l'adresse privée, la publique étant traduite plus loin.
Corrigé le jour même : le point de vue est désormais établi positivement avant toute conclusion, avec une asymétrie assumée — une réponse prouve l'exposition depuis n'importe où, une absence de réponse ne prouve rien tant qu'on ne sait pas d'où l'on regarde. Depuis le 14/09, la mesure est en outre produite par un exécutant tiers, extérieur au réseau de la machine : c'est la seule position d'où la question a un sens.
Une preuve qui ne sait pas d'où elle regarde ne prouve rien. C'est le défaut le plus grave que cette page pouvait porter : il ne produit pas une fausse alerte, il produit une fausse assurance — et il l'aurait produite même après une exposition réelle. La règle « une sonde qui échoue rend non mesuré, pas en défaut » était écrite et tenue ; celle qui manquait est « une sonde qui n'a pas établi son point de vue ne rend pas vert ».
Le cloisonnement, lui, n'a jamais été en défaut : mesurée depuis l'extérieur, l'origine ne répond pas. C'est la méthode qui était aveugle, pas la défense.
L'incident du 12 septembre a été causé par une manœuvre d'administration, pas par un tiers. C'est la source de risque que l'analyse de risques désigne comme la plus probable des quatre — la cotation s'est vérifiée toute seule, trois semaines après avoir été écrite.
Ce qui n'est pas publié
Le rapport d'audit complet — le détail de configuration derrière chaque constat, les neuf autres entrées du journal des incidents, et les preuves collectées sur la machine. Communicable sur demande, dans un cadre d'entretien, selon la même doctrine de publication qui s'applique à l'analyse de risques et à la Déclaration d'Applicabilité : ce qui est constaté se publie, ce qui décrit comment la machine est faite ne se publie pas.