Un seul modèle d'audit pour toutes les applications.
OpenAuditModel est un modèle commun d'événements d'audit (audit events) pour les applications métier. Les événements sont vérifiables, et le modèle ne dépend pas du système dans lequel vous les stockez. Il définit ce qu'est un événement d'audit. Il ne dit ni où l'événement est stocké, ni comment il est transporté, ni quelle réglementation il satisfait.
Pourquoi
Presque toutes les applications enregistrent des opérations à auditer, et presque toutes inventent leur propre format pour le faire. La facture arrive plus tard. Les enregistrements ne sont vérifiés que le jour où, des années après, un défaut apparaît dans les données conservées. Les pistes d'audit de deux systèmes ne se lisent pas côte à côte sans une couche de traduction construite sur mesure. Les mêmes questions sont rediscutées à chaque nouvelle application : qui est l'acteur ? comment consigne-t-on une action faite au nom de quelqu'un d'autre ? où va l'approbation ? Et parce que personne n'a décidé de ce qui doit y figurer, les données d'audit accumulent en silence des mots de passe, des clés et des données personnelles. OpenAuditModel répond à ces questions une fois pour toutes, sous une forme qu'un validateur peut contrôler.
Un événement au plus simple
Sept champs sont obligatoires. Tout le reste est facultatif et apporte du contexte.
{
"specVersion": "1.0",
"id": "018f1b5c-6d2a-7c3e-9a1b-4f5e6d7c8b9a",
"time": "2026-03-14T09:24:31.412Z",
"event": {
"name": "data.record.update",
"category": "data-modification",
"outcome": "success"
},
"actor": {
"type": "user",
"id": "user-123"
},
"resource": {
"type": "record",
"id": "resource-123"
},
"application": {
"name": "application-service",
"environment": "production"
}
}
Essayer tout de suite
Il n'y a rien à installer et aucun dépôt à cloner. Node.js 22 ou plus récent suffit.
npx @openauditmodel/cli validate audit-event.json
npx @openauditmodel/cli lint-privacy audit-event.json
npx @openauditmodel/cli check-profile audit-event.json --profile financial-transaction-management
Le code de sortie 0 signifie qu'un verdict a été rendu et que l'événement est passé. 1 signifie qu'un verdict a été rendu et que l'événement a échoué. 2 signifie que l'outil n'a pas pu s'exécuter. 3 signifie qu'aucun verdict n'a été rendu : l'événement déclare une version de la spécification que l'outil n'implémente pas, aucune règle du profil ne couvre cet événement, ou l'entrée n'était pas un événement d'audit et n'a donc jamais été analysée. 3 n'est jamais une approbation.
Schémas canoniques
Ces URL sont les identifiants inscrits dans le $id de chaque schéma. Les adresses sont stables, et un document versionné ne change plus une fois publié. Aucun outil n'a besoin de les télécharger : la validation se fait hors ligne, et un identifiant est un nom, pas une instruction de téléchargement.
/schemas/audit-event/1.0/schema.json
/schemas/audit-event/0.1/schema.json
/schemas/profile-definition/0.1/schema.json
/schemas/checkpoint/0.1/schema.json
/schemas/proof/0.1/schema.json
Profils métier
10 profils, 127 règles : 113 règles sont appliquées comme des erreurs, 14 règles sont des recommandations. Un profil ne fait qu'ajouter des exigences au modèle de base ; aucun profil ne l'assouplit. Un événement qu'aucune règle ne couvre est signalé comme non applicable, jamais comme conforme.
Les adresses ci-dessous donnent accès au document de chaque profil. Ce sont des adresses, pas des identités : un profil porte name et version, mais pas de $id. Ne figez donc pas ces URL comme identifiants canoniques.
| Profil | Règles | Document |
|---|---|---|
| api-and-integration-management | 13 | profile.json |
| backup-and-recovery | 13 | profile.json |
| customer-and-account-management | 13 | profile.json |
| deployment-and-change-management | 13 | profile.json |
| document-management | 11 | profile.json |
| financial-transaction-management | 12 | profile.json |
| identity-and-access-management | 11 | profile.json |
| incident-management | 15 | profile.json |
| message-broker-management | 12 | profile.json |
| secrets-and-key-management | 14 | profile.json |
Comment l'adopter
Rien ici ne vous oblige à changer l'endroit où vous stockez vos données. Le chemin le plus simple est un convertisseur qui transpose les enregistrements existants dans ce format ; c'est d'ailleurs la forme que demandent les clients grands comptes :
existing audit database → mapper → OpenAuditModel NDJSON → customer, archive or SIEM
La suite va de soi : un nouveau service produit ses événements dans ce format, les fichiers d'exemple sont validés dans la CI, et les événements sont conçus avec un agent IA via le serveur MCP. Le serveur expose les mêmes moteurs déterministes en Streamable HTTP :
claude mcp add --transport http openauditmodel https://mcp.openauditmodel.org/mcp
Il s'agit d'un service distant ; le contenu des événements d'audit que vous lui envoyez quitte votre machine. Pour des données réglementées, construisez et exécutez plutôt le serveur vous-même à partir du dépôt source. Dans les deux cas, le serveur ne garde aucun état et ne conserve rien.
Ce que ce n'est pas
OpenAuditModel n'est ni un système de stockage de logs, ni une base de données, ni un SIEM, ni une plateforme GRC, ni un moteur de politiques, ni un système d'autorisation. Il ne remplace pas OpenTelemetry, CloudEvents, ECS, OCSF, CADF ou OSCAL ; il fonctionne avec eux.
