Pourquoi je l'ai construit
La plupart des outils de gouvernance s'arrêtent à une liste de cases : un contrôle est coché, et rien ne relie cette case à l'obligation qui la justifie, à la preuve qui la démontrerait, ni au risque qu'elle est censée réduire. J'ai voulu voir si toute la chaîne pouvait tenir en un seul endroit et rester honnête : une obligation, le contrôle qui y répond, la preuve collectée sur ce contrôle, le constat quand la preuve échoue, le risque qui en découle, et la décision que quelqu'un signe.
Kontrol est cette tentative : une application web que j'ai écrite en TypeScript, avec un module de système de management pour ISO/IEC 27001, un registre des risques, un hub de conformité multi-référentiels et un journal d'audit en ajout seul où chaque modification est chaînée à la précédente. Cette page le montre sur un cas complet plutôt que d'en décrire les fonctions.
Le cas : Hydria, un opérateur d'eau fictif
Hydria n'existe pas. Son nom, ses chiffres et ses personnes sont inventés, et rien ici ne provient d'une organisation où j'ai travaillé. J'ai choisi un opérateur d'eau parce qu'il réunit ce qui rend la gouvernance difficile : un service essentiel, des données personnelles à grande échelle, un réseau industriel à côté du réseau bureautique, et un centre d'opérations de sécurité qui utilise un tri assisté par IA.
| Élément | Détail |
|---|---|
| Activité | Distribution d'eau potable et facturation pour environ 410 000 clients |
| Périmètre du système de management | Le service du centre d'opérations de sécurité et le système d'information clients |
| Exclu, avec justification | Les systèmes industriels eux-mêmes (seule leur interface de journaux à sens unique est incluse), les agences, les filiales |
| Référentiels adoptés | ISO/IEC 27001:2022 pour le système de management, ISO/IEC 42001:2023 pour le pipeline de tri par IA, la loi marocaine 05-20 (cybersécurité) et la loi 09-08 (données personnelles) |
| Contexte légal | La loi 05-20 sur la cybersécurité et la loi 09-08 sur les données personnelles sont suivies article par article, chaque article relié aux contrôles qui y répondent. Hydria obtient 47 % sur la première et 27 % sur la seconde |
Le dossier, en trois étapes
Trois scripts chargent le dossier par l'interface publique de l'application : chaque enregistrement passe donc par les mêmes contrôles et le même journal d'audit que si une personne l'avait saisi. Lancés sur une base vide, ils aboutissent chaque fois au même état.
1. Le socle
Huit enjeux internes et externes ; sept parties intéressées, chacune avec ce qu'elle exige ; un périmètre avec ses limites et trois exclusions justifiées ; une politique de sécurité d'une page ; cinq objectifs, chacun avec une mesure, une cible, un responsable et une échéance. Un engagement de la politique vient de mon projet de stage : l'analyse automatisée, IA comprise, peut proposer, et une personne nommée décide.
2. Appréciation et traitement des risques
Une méthode approuvée : une matrice cinq par cinq, avec ce que signifie chaque niveau d'impact pour la confidentialité, l'intégrité et la disponibilité, et une appétence au risque fixée à « moyen ». Huit actifs valorisés sur ces trois propriétés. Quinze scénarios, chacun construit à partir d'un actif et d'une menace, de sorte que l'impact d'un scénario ne peut dépasser la valeur de l'actif concerné. L'état et le responsable de 44 contrôles. Un plan de traitement, un responsable et une date pour chaque risque réduit.
3. Le système en fonctionnement
Des rapports signés venant des systèmes de formation et de RH ; une première mesure de chaque objectif ; un incident de phishing traité jusqu'au retour d'expérience ; deux non-conformités ; le programme d'audit interne ; la première revue de direction, dont les décisions deviennent des tâches.
Le résultat
Ce que montre le dossier, y compris ce qui n'est pas terminé
Un dossier où tout est vert n'apprend rien et ne convainc personne. J'ai construit celui-ci pour qu'il ressemble à un système de management dans sa première année.
- Onze risques sur quinze restent au-dessus de l'appétence. La plupart des contrôles sont partiels ou planifiés, donc le niveau résiduel bouge peu. Kontrol le calcule à partir de l'état des contrôles ; je ne peux pas l'améliorer en saisissant un chiffre plus bas.
- Un risque est accepté au-dessus de l'appétence, pour six mois, par le directeur général, qui ne l'a ni saisi ni ne le porte, avec le motif consigné. L'application refuse cette acceptation à toute autre personne.
- Un contrôle est laissé en échec. Le rapport RH indique que deux salariés partis ont gardé un compte. La déclaration sur le cycle de vie des identités est alors plafonnée, et le rapport la liste comme une contradiction entre ce qui est attesté et ce qui est observé.
- L'incident a produit une non-conformité : le MFA n'était pas imposé sur les comptes ordinaires. Son action corrective est ouverte et dans les délais. Une seconde non-conformité a suivi tout le cycle et a été close par une autre personne que le responsable de l'action.
- La clause 9.2 est partielle exprès. L'auditeur interne n'est pas encore formé : le premier audit est planifié, aucun n'est réalisé. La liste de contrôle le dit exactement.
Les règles que l'application impose
| Règle | Pourquoi c'est important |
|---|---|
| La personne qui porte ou a saisi un risque ne peut pas l'accepter | La séparation des tâches est vérifiée par le système, pas laissée à une procédure |
| Une acceptation expire, et un risque résiduel critique ne peut pas être accepté | Un risque accepté ne devient pas permanent en silence |
| Une preuve en échec plafonne un contrôle attesté à « partiel » | Une déclaration ne peut pas l'emporter sur une observation |
| Une action corrective est vérifiée par un autre que son responsable | Clore son propre constat ne prouve rien |
| Une clause sans enregistrement est manquante, pas remplie | Un processus qui n'a jamais fonctionné n'est pas réputé efficace |
| Chaque modification s'ajoute à un journal d'audit chaîné par hachage | Supprimer ou altérer une entrée invalide toutes les empreintes suivantes |
Ce que l'utiliser m'a appris sur mon propre outil
Tant que je n'avais pas déroulé un cas complet, Kontrol n'avait vu que ses propres données d'exemple. Le dossier a trouvé ce que les tests n'avaient pas trouvé :
- Aucun actif ne pouvait être saisi à la main. Seuls les connecteurs en créaient : un service ou un fournisseur ne pouvait donc jamais être valorisé ni apprécié. La saisie et le retrait d'actifs font désormais partie du registre des risques.
- Les étapes à deux personnes ne pouvaient pas être démontrées, et l'organisation gardait le nom des données d'exemple dans tous les exports.
- Le rapport décrivait mal sa signature : il imprimait une signature Ed25519 et l'expliquait comme un HMAC. C'est en lisant mon propre PDF comme le ferait un auditeur que je l'ai vu.
- Les déclarations et les enregistrements se contredisaient. La clause sur la communication était remplie par ses enregistrements alors que le contrôle correspondant restait « non démarré ». Réconcilier les deux est précisément le travail qu'exige une déclaration d'applicabilité.
- Le droit marocain manquait. Les deux lois nationales ne pouvaient être notées que comme exigences de parties intéressées. J'ai rédigé un catalogue pour chacune à partir des textes officiels, 18 articles chacun, et relié chaque article aux contrôles unifiés. Hydria dispose maintenant d'une déclaration d'applicabilité pour chaque loi.
Limites
- Rien ici n'a été audité. Les niveaux de préparation, les vérifications de clauses et les niveaux de maturité sont mes choix de conception ; aucun audit de certification ne les a confirmés. C'est une auto-évaluation structurée, pas une prédiction du résultat d'un audit.
- Le calendrier est compressé. Chaque enregistrement est créé le jour où les scripts tournent. Un vrai système de management met des mois à produire des mesures, un incident, des actions correctives et une revue.
- Les cotations sont plausibles, pas mesurées. Vraisemblances, valeurs d'actifs et états des contrôles ont été choisis pour un opérateur crédible.
- Les collecteurs ne sont que partiellement éprouvés. Le collecteur GitHub a été lancé sur un de mes dépôts réels ; les collecteurs AWS et Okta n'ont été testés que contre des services simulés.
- La correspondance juridique est la mienne. Les liens entre les articles des lois marocaines et les contrôles sont ma lecture, pas une source publiée ; les décrets d'application sont hors des catalogues, et considérer Hydria comme infrastructure d'importance vitale est une hypothèse.
Le code source est public : github.com/omarbabba779xx/kontrol. Le dossier, ses trois scripts de chargement et ses exports (déclarations d'applicabilité, plan de traitement des risques, rapport signé) se trouvent dans examples/hydria.