Chaque action, signée cryptographiquement. Pour toujours.

Chaque action significative dans OPTIMa (création, modification, suppression d'un OT, d'une intervention, d'un équipement ou d'une pièce, mais aussi connexions et déconnexions) génère une entrée dans la table des audit logs. Chaque entrée contient le timestamp UTC, l'identifiant utilisateur, l'action, le type et l'ID d'entité, un JSON complet des données avant et après modification, l'IP et le user agent. Cette entrée est ensuite signée par un hash SHA-256 qui inclut le hash de l'entrée précédente - formant ainsi une chaîne cryptographique infalsifiable.

Trois mécanismes combinés. D'abord, la table audit est immutable au niveau base de données : les triggers bloquent toute tentative d'UPDATE ou de DELETE, même par un administrateur DBA. Ensuite, chaque entrée est hashée en SHA-256 incluant le hash de l'entrée précédente : modifier une entrée casse toute la chaîne suivante, détection immédiate. Enfin, une fonction de vérification recalcule toute la chaîne et détecte en millisecondes toute incohérence. Même un accès root à la base ne permet pas de falsifier un historique sans laisser de trace.

OPTIMa expose une fonction de vérification (VerifyChainIntegrityAsync côté backend, bouton côté interface) qui parcourt la chaîne par lots de 1000 entrées, recalcule le hash attendu pour chaque entrée à partir de ses données et de l'entrée précédente, et compare avec le hash stocké. Le résultat donne : chaîne valide ou non, nombre d'entrées vérifiées, et si invalide, l'ID de la première entrée problématique. Typiquement 412 ms pour vérifier 3 000 entrées.

Toutes les actions CRUD sur les entités critiques : équipements, ordres de travail, demandes d'intervention, pièces, utilisateurs et profils. Plus les événements de sécurité : connexion réussie (LOGIN), déconnexion (LOGOUT), tentative échouée (LOGIN_FAILED). Pour chaque modification, le JSON complet des données avant et après est conservé - vous savez exactement ce qui a changé, pas seulement qu'il y a eu une modification.

Export CSV en un clic depuis l'interface Administration > Audit logs. Le CSV est encodé UTF-8 avec BOM (compatible Excel français), séparateur point-virgule, colonnes : ID, Timestamp, Utilisateur, Type d'entité, ID d'entité, Libellé d'entité, Action, IP, Hash. Vous pouvez filtrer par période, par utilisateur, par type d'entité (uniquement les OT par exemple), par action, ou par recherche libre. L'export inclut le hash pour vérification ultérieure par l'auditeur.

Oui, directement ou indirectement. ISO 9001 exige la traçabilité des processus, ISO 55000 impose un historique infalsifiable des actifs, HACCP demande la traçabilité des actions sur les équipements en contact avec les denrées, IFS Food et BRC vont plus loin avec des exigences explicites sur la documentation et l'archivage. Sans audit logs natifs, vous devez reconstituer ces informations à la main avant chaque audit - plusieurs jours de travail. Avec OPTIMa, l'export est instantané.

Non - c'est précisément le point. La configuration du système d'audit (quelles entités sont tracées, quelles actions, comment la chaîne est construite) n'est pas modifiable par l'administrateur. Les triggers DB sont verrouillés en écriture. La clé de chaînage est déterministe et reproductible. Cela garantit qu'aucun utilisateur, même administrateur, ne peut désactiver temporairement le logging pour cacher une action.

Par défaut, les audit logs sont conservés indéfiniment. OPTIMa étant hébergé en France sur OVH Gravelines/Roubaix, vous êtes conforme aux obligations RGPD pour la conservation des journaux. Pour les organisations avec des politiques de rétention spécifiques (suppression des logs de plus de X années pour raisons légales), une purge programmée peut être configurée en préservant l'intégrité de la chaîne résiduelle.