Sécurité

Journal d'audit intégrateur

Chaque action mutante que vous ou vos techniciens effectuez est tracée dans un journal infalsifiable, insert-only et chaîné cryptographiquement. Voici ce qui y figure, ce qui n'y figure jamais, et comment le consulter.

Lecture 5 min

1. Ce qui est tracé

Elark journalise automatiquement toute requête qui modifie des données (création, modification, suppression) effectuée par un compte authentifié intégrateur ou technicien managé : en pratique, toute requête POST, PUT, PATCH ou DELETE sur les routes métier de l’application (installations, clients, prestations, tickets SAV, bons d’intervention, contrats de maintenance, blocs de planning, matériel, fournisseurs, règles d’alerte, agents Edge, centrales d’alarme, techniciens, etc.). La connexion à votre compte est également tracée.

Cette capture est structurelle : elle s’applique automatiquement à toute nouvelle route de l’application, sans qu’un développeur ait besoin d’y penser à chaque fonctionnalité — rien ne peut donc être « oublié » au fil des évolutions du produit.

Chaque ligne enregistre : qui a agi (email, rôle), l’action (libellé en français, ex. « Création — Bon d’intervention’»), la ressource concernée, l’installation dans laquelle l’action a eu lieu, le code de statut HTTP de la réponse, une adresse IP tronquée (minimisation RGPD) et l’horodatage exact.

Les simples lectures (GET) ne sont pas journalisées : seules les actions qui changent quelque chose le sont.

2. Ce qui n’y figure jamais

Le journal ne contient jamais de mot de passe, de secret, de clé ou de contenu de formulaire — uniquement des métadonnées factuelles sur l’action (qui, quoi, où, quand, résultat). Une modification de mot de passe ou de clé apparaît comme un événement (« Modification — … »), jamais avec la valeur.

3. Chaînage cryptographique et vérification

Le journal est insert-only : une ligne, une fois écrite, ne peut plus être modifiée ni supprimée individuellement par l’application (toute tentative échoue au niveau du code). Chaque ligne porte en plus un hash SHA-256 calculé à partir de son contenu factuel et du hash de la ligne précédente : c’est un chaînage, comme les blocs d’une chaîne de confiance — modifier ou retirer une seule ligne au milieu de l’historique casse le chaînage de toutes les lignes suivantes, ce qui rend une falsification détectable.

En interne, l’équipe Elark peut relancer à tout moment une commande de vérification qui recalcule la chaîne entière depuis la plus ancienne ligne conservée et signale la première rupture détectée, le cas échéant.

4. Périmètre strict par intégrateur

Vous ne voyez que le journal de votre périmètre — vos propres actions et celles de vos techniciens managés, jamais celles d’un autre intégrateur. Un compte technicien managé n’a de son côté aucun accès au journal, même limité à ses propres actions : c’est un outil réservé à l’intégrateur.

5. Rétention RGPD

Les lignes du journal sont conservées 365 jours par défaut, puis purgées automatiquement chaque nuit — conformément au principe de minimisation des données du RGPD. Cette purge n’est pas considérée comme une falsification : la vérification de chaîne (section 3) prend simplement la ligne la plus ancienne restante comme nouveau point de départ de confiance.

6. Où le consulter et filtres disponibles

Rendez-vous dans Journal d’audit (menu latéral). Vous pouvez filtrer par :

Recherche — texte libre sur l’action, la cible ou la route.
Installation — limite l’affichage à une installation précise.
Depuis — borne de date de début.
Acteur — vous-même ou l’un de vos techniciens (visible dès que vous en avez au moins un).

Le résultat est présenté par pages de 50 lignes (quand, acteur, action, cible, installation, statut), triées de la plus récente à la plus ancienne.