auditlog : savoir qui a modifié quoi dans Odoo

« Qui a changé ce prix ? » et « qui a supprimé cette facture ? » sont deux questions auxquelles Odoo ne répond pas nativement de façon complète : le chatter trace une partie des modifications, pas toutes, et jamais les lectures ni les exports.

auditlog répond aux trois. Il intercepte les méthodes de l'ORM — create, read, write, unlink, export_data — sur les modèles que vous désignez, et enregistre chaque appel avec le détail des champs touchés. C'est l'outil d'une démarche de conformité ou d'une enquête, pas un réglage à activer partout.

L'essentiel

• Règle par modèle (auditlog.rule) : vous choisissez quoi auditer, et quelles opérations parmi lecture, écriture, suppression, création, export.
• Deux niveaux de détail : « Full log » (diff complet des valeurs) ou « Fast log » (plus léger).
• Rien n'est journalisé tant qu'aucune règle n'est à l'état Subscribed.
• Les lectures sont décochées par défaut — et c'est un choix prudent : les activer sur un modèle très consulté peut dégrader les performances.
• Purge automatique disponible mais désactivée par défaut : action planifiée « Auto-vacuum audit logs », rétention de 180 jours.
• Deux groupes de droits créés : Auditlog User (lecture) et Auditlog Manager (configuration).

Ce que le module ajoute à l'instance

Zéro modèle étendu : c'est une qualité rare et un bon signe. auditlog n'ajoute aucun champ à vos objets métier — il observe de l'extérieur, en interceptant dynamiquement les méthodes de l'ORM. Désinstallé, il ne laisse donc rien derrière lui sur account.move ou res.partner.

Les deux modèles HTTP sont ce qui distingue auditlog d'un simple suivi de modifications : ils rattachent une opération à une session et à une requête, donc à un contexte — ce qui compte le jour d'une investigation.

Où le trouver dans Odoo

Le module est marqué comme application dans son manifeste : il apparaît donc aussi dans le menu des applications d'Odoo.

Et surtout, chaque règle souscrite ajoute une action View logs dans le menu Actions des fiches du modèle audité. C'est le point d'entrée réellement utilisé au quotidien : depuis un contact ou une facture, voir son historique sans passer par les écrans d'administration.

Cas d'usage

Mettre en place une règle d'audit sur un modèle métier

1. Paramètres ▸ Technique ▸ Audit ▸ Règles, puis Nouveau.
2. Name, puis Model : le modèle à auditer, par exemple « Contact ».
3. Type : « Full log » pour le diff complet des valeurs, « Fast log » pour une trace plus légère.
4. Cocher les opérations à surveiller : Log Writes, Log Deletes, Log Creates et Log Exports sont cochées par défaut ; Log Reads est décochée.
5. Facultatif mais utile : Users to Exclude et Fields to Exclude, pour écarter un compte technique ou un champ bruyant.
6. Enregistrer, puis cliquer sur Subscribe : l'état passe de Draft à Subscribed, les champs deviennent en lecture seule, et la journalisation commence.

La dernière étape est indispensable et facile à manquer : une règle enregistrée mais non souscrite ne journalise rien.

Consulter les journaux générés

1. Paramètres ▸ Technique ▸ Audit ▸ Logs.
2. Chercher par nom, modèle, identifiant d'enregistrement ou utilisateur, ou regrouper par User, Model ou Date.
3. Ouvrir un log : le groupe Fields updated liste chaque champ modifié avec son ancienne et sa nouvelle valeur.
4. Pour un log d'export, le bouton Exported Records ouvre la liste des enregistrements concernés.

Voir l'historique d'un enregistrement depuis sa fiche

1. Ouvrir la fiche d'un enregistrement d'un modèle dont une règle est souscrite.
2. Menu Actions (icône engrenage) ▸ View logs.
3. La liste s'ouvre, filtrée sur ce modèle et cet enregistrement précis.

C'est l'usage qui justifie le module auprès des utilisateurs, et celui qu'il faut leur montrer en premier : la réponse à « qui a changé ça » en deux clics, sans ticket.

Activer la purge automatique des anciens journaux

1. Paramètres ▸ Technique ▸ Automatisation ▸ Actions planifiées.
2. Chercher Auto-vacuum audit logs : désactivée par défaut, intervalle d'un jour, code model.autovacuum(180) — elle supprime les logs de plus de 180 jours.
3. Cocher Actif.
4. Facultatif : ajuster la rétention, ou passer un second paramètre chunk_size pour limiter le nombre d'enregistrements supprimés par exécution si le volume à purger est important.

La case à ne pas cocher à la légère

Log Reads. Elle paraît inoffensive et elle est la seule qui puisse réellement gêner une instance.

Journaliser les lectures d'un modèle très consulté — un catalogue d'articles, un fichier clients ouvert par cinq commerciaux toute la journée — génère un très grand nombre d'entrées, et la documentation du dépôt avertit explicitement du risque de dégradation des performances.

• Quand l'activer : sur un modèle sensible et peu consulté, pour répondre à une exigence précise — savoir qui a consulté un dossier.
• Quand s'en abstenir : partout ailleurs, et en particulier sur les modèles utilisés par les écrans de travail quotidiens.
• Si vous l'activez : activez la purge automatique dans la même séance, et surveillez la taille de la base.

Le volume de journaux est d'ailleurs l'une des causes de lenteur que nous rencontrons — voir les cinq causes réelles d'une lenteur Odoo.

Configuration et droits

1. Installer auditlog (application autonome, aucune dépendance au-delà de base).
2. Attribuer Auditlog User (lecture seule) ou Auditlog Manager (configuration complète) aux utilisateurs concernés. Les administrateurs système (base.group_system) héritent automatiquement du groupe Manager.
3. Créer et souscrire au moins une règle : sans cela, rien n'est journalisé.
4. Activer et ajuster la purge automatique pour maîtriser la croissance de la base.
5. N'activer Log Reads qu'en connaissance de cause.

Un point d'organisation qui vaut autant que le paramétrage : décidez qui consulte les journaux. Un outil d'audit auquel tout le monde a accès change la nature de la relation de travail ; un outil auquel personne ne regarde ne sert à rien. Deux ou trois personnes nommées, c'est le bon réglage.

Limites connues

Le dépôt répertorie deux limites, et elles sont importantes à connaître avant de s'appuyer sur ce module pour une exigence de conformité.

• Pas de ciblage par utilisateur : la liste des souhaits du module mentionne « journaliser seulement les opérations déclenchées par certains utilisateurs » — aujourd'hui, toutes les opérations de tous les utilisateurs sont journalisées. Le champ Users to Exclude permet d'exclure, pas de cibler.
• Les lectures ne sont pas journalisées sur tous les modèles : le dépôt indique que ce point demande investigation. Si votre exigence porte précisément sur la traçabilité des consultations, il faut le vérifier sur vos modèles avant de s'y fier.

Une troisième limite, d'usage : les journaux ne sont pas des sauvegardes. auditlog dit ce qui a changé ; il ne restaure pas. Les deux sont nécessaires et ne se remplacent pas.

Voir sauvegardes et plan de reprise : les trois chiffres.

Identité technique

Questions fréquentes

Pourquoi aucun journal n'apparaît après l'installation ?

Parce qu'aucune règle n'est souscrite. Créer la règle ne suffit pas : il faut cliquer sur Subscribe pour qu'elle passe de Draft à Subscribed. C'est à ce moment-là, et pas avant, que le module commence à intercepter les opérations.

auditlog ralentit-il l'instance ?

Pas de façon sensible sur les créations, modifications et suppressions. En revanche, activer Log Reads sur un modèle très consulté génère un très grand nombre d'entrées, et le dépôt avertit d'un risque de dégradation des performances. Cette case est décochée par défaut pour cette raison.

Peut-on auditer seulement certains utilisateurs ?

Non, pas aujourd'hui : c'est une limite répertoriée du module. Toutes les opérations de tous les utilisateurs sont journalisées. Le champ Users to Exclude permet d'exclure des comptes — typiquement un compte technique d'intégration — mais pas de cibler une personne.

Combien de temps les journaux sont-ils conservés ?

Indéfiniment par défaut, car la purge est désactivée. L'action planifiée Auto-vacuum audit logs supprime les logs de plus de 180 jours, mais il faut l'activer. Faites-le dans la même séance que la création de vos règles, sinon la base grossit sans que personne ne le décide.

auditlog laisse-t-il des traces s'il est désinstallé ?

Il n'étend aucun modèle métier : il n'ajoute aucun champ à account.move ou res.partner, et observe de l'extérieur en interceptant l'ORM. Ses sept modèles propres et les journaux accumulés disparaissent avec lui — pensez donc à exporter ce que vous devez conserver avant de le retirer.

Pour aller plus loin

• base_tier_validation : des circuits de validation
• Les droits utilisateurs dans Odoo : qui voit quoi
• Les obligations RGPD d'une PME qui héberge un ERP

En résumé

auditlog répond à « qui a modifié quoi », y compris sur les suppressions et les exports, sans toucher à vos modèles métier. Trois gestes à ne pas manquer : souscrire la règle, activer la purge automatique, et laisser Log Reads décochée sauf exigence précise. Parlons de votre traçabilité.