Skip to main content
Le journal d’audit vous fournit un historique inviolable des actions effectuées par votre personnel sur votre compte : qui a fait quoi, sur quelle ressource, depuis où, et si l’action a réussi. Utilisez-le pour enquêter sur des changements, respecter des exigences de conformité et répondre à des questions telles que « qui a annulé cette commande ? » ou « quand cet élément de menu a-t-il été mis à jour ? ».
Le journal d’audit est réservé aux propriétaires de compte et aux administrateurs. Le personnel ayant d’autres rôles verra un message « restricted » lorsqu’il essaiera de l’ouvrir, et un administrateur dont l’accès est limité à certains magasins ne voit que les événements de ces magasins.

​
Où le trouver

1

Ouvrir Logs

Dans la barre latérale, cliquez sur Analytics pour déplier la section, puis sélectionnez Logs.
2

Ouvrir le journal d'audit

Sous l’en-tête Security, sélectionnez Audit Log.
3

Rechercher et filtrer

Les événements les plus récents se chargent automatiquement. Affinez les résultats à l’aide des filtres, ou exportez ce que vous voyez en CSV.

​
Ce qui est enregistré

Chaque entrée capture le contexte complet d’une action du personnel : Sélectionner une ligne développe un panneau de détails avec la méthode de requête, le chemin, la route, l’adresse IP, le user agent, l’ID de requête et l’ID de trace, ainsi que le type d’erreur lorsqu’une action échoue.

​
Quelles actions sont journalisées

  • Toutes les modifications sont enregistrées — tout ce qui crée, met à jour ou supprime des données (y compris des actions comme archiver, annuler, restaurer ou publier).
  • Les lectures sensibles sont enregistrées — visualiser ou télécharger des rapports, exports, factures et relevés. L’ouverture du journal d’audit lui-même est enregistrée comme une read, et son export est enregistré comme un export.
  • Les lectures de routine (parcourir des listes, ouvrir des vues de détail, polling en arrière-plan) ne sont pas enregistrées, afin de garder le journal focalisé sur l’activité significative.
Les actions effectuées par les clients passant commande et par les clés API sortent du périmètre du journal d’audit — celui-ci se concentre sur les actions du personnel dans le tableau de bord.

​
Qui a modifié un paramètre de magasin, et quand

L’enregistrement d’une page de paramètres du magasin est journalisé comme n’importe quelle autre modification : un update sur la ressource associée à cette page, attribué au membre du personnel qui a enregistré et horodaté au moment où il l’a fait. Les horaires d’ouverture en sont le cas courant. Les horaires hebdomadaires et les Special Opening Hours sont enregistrés ensemble par Save dans Stores → votre magasin → Settings → Opening Hours, ils arrivent donc comme une seule entrée avec le type de ressource hour et l’action Update.
1

Filtrer sur les modifications d'horaires

Cliquez sur Add filter, choisissez Resource type, saisissez hour et cliquez sur Apply. Ajoutez le filtre Action réglé sur Update, et le filtre Outcome réglé sur Success — les enregistrements qui ont échoué sont également journalisés et ils n’ont rien modifié.
2

Régler la plage de dates

Le journal s’ouvre sur les 30 derniers jours. Pour l’affiner, cliquez sur le bouton de plage de dates avec l’icône de calendrier à droite des filtres et choisissez un préréglage (Today, Yesterday, This month, Last month, This year, Last year, All time) ou sélectionnez les dates sur le calendrier. All time ne fera pas remonter d’éléments au-delà de votre fenêtre de rétention.
3

Lire la ligne

Time est le moment où les horaires ont été enregistrés, Actor est le membre du personnel qui les a enregistrés (nom, e-mail et rôle au moment de l’action), et Store est le magasin concerné — vous pouvez donc laisser le filtre Store de côté et lire la colonne plutôt que de chercher des IDs de magasins.
4

Développer pour le détail de la requête

Sélectionner la ligne affiche Path avec /venues/<store id>/hours, l’IP address, le User agent et le Request ID, et Fields changed avec venueHours et specialHours.
La même approche fonctionne pour d’autres modifications — filtrez par type de ressource (venue pour les paramètres propres à un magasin, et menu, product ou discount-code pour les modifications de catalogue et de promotions) et lisez les colonnes Actor et Time.

​
Ce que cela ne vous dit pas

  • Les valeurs. Le journal enregistre que les horaires ont été modifiés et quels champs étaient concernés — jamais les horaires avant et après. Il n’existe aucun moyen de consulter les horaires d’ouverture précédents dans le tableau de bord.
  • Les modifications non effectuées par un membre du personnel. Tout ce qui est fait par une clé API, une intégration POS ou de livraison, ou un client, est hors périmètre.
  • Tout ce qui est plus ancien que votre fenêtre de rétention. 30 jours par défaut (voir Rétention).
Si une modification est plus ancienne que votre fenêtre de rétention, ou a été effectuée par une intégration, le journal d’audit ne peut pas vous dire qui l’a réalisée. Contactez le support avec le magasin et la date approximative si vous souhaitez tout de même une investigation.

​
Recherche et filtrage

Le journal d’audit utilise une barre de recherche à facettes. Ajoutez un ou plusieurs filtres et cliquez sur Apply ; les filtres actifs apparaissent comme des pastilles supprimables. Facettes disponibles : Par défaut, le journal affiche les 30 derniers jours. Les résultats sont paginés — utilisez Load more pour récupérer les événements plus anciens. Vous pouvez tout effacer avec Clear all.
Combinez les facettes pour cibler un incident — par exemple, filtrez par Actor et Action: delete pour voir tout ce qu’un utilisateur précis a supprimé.

​
Exporter en CSV

Cliquez sur Export pour télécharger les résultats actuellement filtrés en fichier CSV (avec les mêmes filtres et plage de dates appliqués). Pratique pour partager avec des auditeurs ou archiver en dehors de storekit.
Les exports sont limités à 50 000 lignes. Si vous atteignez la limite, réduisez la plage de dates ou ajoutez des filtres et exportez en lots plus petits.

​
Confidentialité et traitement des données

Le journal d’audit est conçu pour enregistrer ce qui a changé sans capturer le contenu sensible :
  • Il stocke les noms des champs impliqués dans un changement (par ex. « price, availability ») — jamais les valeurs réelles soumises.
  • Les noms de champs qui semblent sensibles (mots de passe, tokens, clés, détails de cartes, PIN et similaires) sont automatiquement supprimés et jamais enregistrés.
  • Les enregistrements sont en append-only : les entrées ne sont jamais modifiées ni supprimées individuellement, l’historique reste donc fiable.

​
Rétention

Les entrées d’audit sont conservées 30 jours par défaut, et le journal s’ouvre sur cette même fenêtre de 30 jours. La rétention est définie par compte, de sorte que les comptes ayant besoin d’un historique plus long pour la conformité peuvent en demander un.
Uniquement les propriétaires de compte et les administrateurs. Les autres rôles du personnel ne peuvent pas le consulter ni l’exporter.
Le journal enregistre intentionnellement les modifications et les lectures sensibles (rapports, exports, factures, relevés) uniquement. La navigation quotidienne et les requêtes en arrière-plan sont exclues afin de garder le journal focalisé sur l’activité significative.
Non. Il enregistre les champs impliqués dans une modification, mais pas les valeurs soumises. Les noms de champs sensibles sont entièrement supprimés.
Les entrées sont conservées 30 jours par défaut. Si vous avez besoin d’une rétention plus longue pour la conformité, contactez notre équipe.
Vous pouvez exporter les résultats filtrés, jusqu’à 50 000 lignes par export. Pour des plages plus larges, découpez l’export en fenêtres de dates plus petites.