Utiliser les journaux d'audit

Chaque requête API dans votre organisation est enregistrée pendant 365 jours - qui, quoi, quand, d'où, et sous quelle application. C'est le premier endroit à consulter quand vous devez savoir ce qui s'est passé.

Rédigé par le support Didit · Mis à jour le 19 août 2026

#Ce qui est enregistré

1234

1. Filtrez par membre, chemin, méthode ou date pour répondre à « qui a changé ceci ».
2. Method et status distinguent une lecture d'un changement qui a réellement pris effet.
3. Le membre qui a effectué l'appel.
4. D'où l'appel est venu : le détail qui transforme un journal en preuve.

Chaque requête effectuée vers la plateforme Didit au sein de votre organisation, quelle qu'en soit l'origine. Chaque entrée porte :

Les journaux sont conservés pendant 365 jours, puis supprimés automatiquement.

#À quoi ça sert vraiment

Quatre situations où c'est le bon outil :

• « Qui a modifié ce workflow ? » Un flux qui se comporte différemment d'hier a en général une modification derrière lui, et le journal nomme qui l'a faite.
• Investiguer un incident. Retracer exactement ce qui a été consulté, par qui, depuis quelle adresse, dans quel ordre.
• Déboguer une intégration. Voir les requêtes que votre propre code a réellement effectuées, plutôt que celles que vous pensez qu'il a effectuées, y compris celles qui ont produit un code 4xx.
• Prouver un contrôle d'accès. Montrer à un auditeur que l'accès aux données de vérification est attribué et vérifiable.

#Filtrer

Filtrez par utilisateur, point de terminaison ou plage de dates pour affiner une longue liste. Quand vous investiguez quelque chose de précis, partez de l'horodatage et élargissez : une requête arrive rarement seule, et les appels immédiatement autour d'elle racontent en général l'histoire.

#Les requêtes par clé API sont attribuées à l'application, pas à une personne

Une requête par clé API n'a personne à qui être attribuée, elle apparaît donc au nom de l'application. C'est la représentation honnête : la plateforme ne sait tout simplement pas lequel de vos services ou de vos ingénieurs a fait l'appel.

Conséquence pratique : une clé unique partagée entre plusieurs services rend un incident nettement plus difficile à investiguer. Si l'attribution compte pour vous, donnez à chaque consommateur sa propre application et sa propre clé.

#Ce qui est dans le journal, et ce qui n'y est pas

Le journal enregistre l'activité : qui a appelé quoi, quand, d'où, et quel statut a été renvoyé. C'est une piste de métadonnées, pas une copie des données de vérification.

Si vous devez savoir si des données personnelles de client apparaissent dans ces entrées - une question qui revient souvent lors des revues de protection des données - obtenez la réponse auprès de votre contact Didit et consignez-la, plutôt que de l'inférer d'une page d'aide. C'est exactement le genre d'affirmation que votre propre DPIA devra pouvoir prouver.

#Qui peut le voir

L'accès aux journaux d'audit suit le rôle. Compliance Officer l'inclut ; Reader n'a pas d'accès large. Les propriétaires peuvent l'accorder à un rôle personnalisé. Voir inviter des membres et définir des rôles.

Retirer un coéquipier ne supprime pas son historique du journal, et c'est précisément le but. Une piste que vous pouvez modifier n'est pas une piste.

#Les exports et rapports sont aussi journalisés

Générer un PDF de session ou un export CSV est un appel API, il apparaît donc ici avec qui l'a effectué. C'est utile quand vous devez montrer que l'accès aux preuves de vérification est contrôlé plutôt qu'ouvert. Voir télécharger un rapport de vérification.

#Si vous avez besoin de plus de 365 jours

La rétention est fixée à 365 jours. Si votre obligation dure plus longtemps, exportez ce dont vous avez besoin selon un calendrier et conservez-le dans votre propre système : le même schéma que pour conserver vous-même les preuves de session. Décider de la durée requise est une décision de conformité pour votre équipe ; ne construisez pas votre solution sur une supposition.