Chaque requête API de votre organisation est gardée 365 jours, avec qui, quoi, quand, d'où et sous quelle application. Le journal à consulter en cas de doute.
Chaque requête API de votre organisation est journalisée automatiquement et conservée pendant 365 jours - depuis la console, votre intégration, comme depuis vos coéquipiers. Retrouvez-la sous Paramètres → Journal d'audit. Chaque décision que l'Enquêteur prend de lui-même y est aussi journalisée, au nom de L'enquêteur.
#Ce qui est enregistré

Chaque requête effectuée vers la plateforme Didit au sein de votre organisation, quelle qu'en soit l'origine. Chaque entrée porte :
| Champ | Détail |
|---|---|
| Timestamp | Quand la requête a été effectuée |
| User | Qui l'a fait : le membre qui a effectué la requête ; pour une requête par clé API, le nom de la clé avec une étiquette Clé API ; Didit pour ce que Didit fait de lui-même ; et L'enquêteur pour une décision qu'il prend de lui-même |
| Method | GET, POST, PUT, DELETE |
| Path | Le point de terminaison appelé |
| Status | Le statut de la réponse HTTP |
| IP address | D'où venait la requête |
| Application | À quelle application elle appartenait |
Les journaux sont conservés pendant 365 jours, puis supprimés automatiquement.
Un journal d'audit repensé, qui décrit chaque modification en toutes lettres et peut exporter ce que vous consultez, est en cours de déploiement. En attendant qu'il soit disponible pour votre organisation, la page affiche le journal des requêtes décrit ici.
#À 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 (un membre, une clé API, Didit ou L'enquêteur), 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 à la clé, pas à une personne
Une requête par clé API n'a personne à qui être attribuée, elle affiche donc le nom de la clé à la place. 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 service sa propre clé. Voir gérer vos clés API.
#Les décisions propres de l'Enquêteur sont attribuées à l'Enquêteur
Quand l'Enquêteur décide de lui-même, dans les limites de l'autonomie que vous lui avez donnée, l'entrée indique L'enquêteur, et non une personne ou une clé. Cela couvre chaque décision qu'il prend : approuver ou refuser une session ou demander à l'utilisateur de la soumettre à nouveau, définir le statut d'une transaction, et résoudre un dossier, l'escalader ou y demander des informations. Chacune de ces entrées renvoie au rapport de l'Enquêteur à l'origine de la décision, pour que vous voyiez ce qu'il a trouvé et quelle règle de votre politique il a appliquée.
Quand une personne décide sur un rapport de l'Enquêteur, en acceptant sa recommandation ou en la remplaçant, l'entrée est attribuée à cette personne, comme tout autre changement qu'elle effectue. La piste complète de l'Enquêteur, avec ses rapports, ses questions et ses garde-fous, reste dans son propre journal Activité. Voir Contrôler et superviser l'Enquêteur.
#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.
La rétention des journaux d'audit et la rétention des données de vérification sont deux réglages distincts. Configurer une fenêtre de rétention courte pour les données de session ne raccourcit pas le journal d'audit, et l'inverse est vrai aussi. Voir comment Didit protège les données de vos utilisateurs.
Toujours bloqué ? Parlez à un humain.
Indiquez l'ID de votre organisation et l'ID de la session concernée.
