> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Journaux d'audit : suivi de l'activité API et conformité > Suivez l'activité API avec les journaux d'audit Didit. Filtrez par utilisateur, méthode, statut et période pour conformité, sécurité et débogage. Les journaux d'audit offrent un historique complet et consultable de toute l'activité de l'API au sein de votre organisation. Chaque requête adressée à la plateforme Didit, qu'elle provienne de la console, de votre intégration ou des membres de votre équipe, est automatiquement journalisée à des fins de sécurité, de conformité et de dépannage. ![Journaux d'audit dans la console Didit](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14) *** ## Pourquoi des journaux d'audit ? | Enjeu | Solution | | - | - | | Exigences de conformité réglementaire | Historique complet de toute l'activité, sur la durée que prévoit votre forfait | | Investigation suite à un incident de sécurité | Retracer précisément qui a fait quoi et quand | | Débogage des problèmes d'intégration | Consulter le chemin, le statut et le corps caviardé de chaque requête | | Responsabilité de l'équipe | Suivre les membres de l'équipe ayant accédé à telle ou telle donnée | | Suivi de l'utilisation | Comprendre les schémas de consommation de l'API | *** ## Accéder aux journaux d'audit Ouvrez Paramètres > Organisation > Journal d'audit dans la console Didit. L'interface affiche une liste chronologique de toutes les requêtes API effectuées au sein de votre organisation. Chaque entrée du journal comprend : | Champ | Description | | - | - | | **Horodatage** | Moment où la requête a été effectuée | | **Utilisateur** | Qui en est à l'origine : l'adresse e-mail du membre de l'équipe authentifié ; le nom de la clé API ayant effectué la requête, marquée **Clé API** ; ou **The Investigator**, pour une décision qu'il a prise de son propre chef | | **Méthode** | Méthode HTTP (GET, POST, PUT, DELETE) | | **Chemin** | L'endpoint API appelé | | **Statut** | Code de statut de la réponse HTTP | | **Adresse** | Adresse d'origine de la requête | | **Application** | Application à laquelle la requête était associée | ### Décisions prises par The Investigator Chaque décision que [The Investigator](https://docs.didit.me/fr/console/investigator.md) prend de son propre chef est enregistrée sous **The Investigator**, et non sous un membre ou une clé API : approbation ou refus d'une session ou demande de nouvelle soumission, définition du statut d'une transaction, et résolution d'un dossier, escalade ou demande d'informations sur celui-ci. L'entrée renvoie au rapport de The Investigator à l'origine de la décision. Lorsqu'une personne accepte ou passe outre à une recommandation de The Investigator, l'entrée est enregistrée sous le nom de cette personne. *** ## Filtrage et recherche L'interface des journaux d'audit propose des fonctions de filtrage puissantes pour vous aider à trouver exactement ce que vous cherchez. ### Recherche intelligente La barre de recherche détecte automatiquement ce que vous recherchez : | Type de recherche | Exemple | Comportement | | - | - | - | | **Chemin exact** | `/v1/organization/.../sessions/` | Retrouve les entrées ayant exactement ce chemin de requête | | **E-mail exact** | `admin@company.com` | Retrouve les entrées de cet utilisateur précis | | **IP exacte** | `192.168.1.100` | Retrouve les entrées provenant de cette adresse IP | | **Caractère générique** | `/v1/*/analytics/*` | Trouve les correspondances de motifs avec des caractères génériques | | **Texte libre** | `sessions` | Recherche approximative dans tous les champs | ### Filtres disponibles | Filtre | Description | Exemple | | - | - | - | | **Application** | Filtre par application spécifique | Sélectionner dans la liste déroulante | | **Membres et clés API** | Filtre par la clé API ayant effectué les requêtes | Sélectionner une clé de l'application choisie | | **Acteur** | Affiche uniquement les actions des membres, des clés API ou de The Investigator | **The Investigator** | | **Méthode** | Filtre par méthode HTTP | `GET`, `POST`, `PUT`, `DELETE` | | **Code de statut** | Filtre par statut de réponse | `200`, `401`, `500` | | **Plage de dates** | Filtre par période | 7 derniers jours, plage personnalisée | *** ## Conservation des données Votre forfait détermine la période pendant laquelle vous pouvez consulter le journal d'audit et si vous pouvez l'exporter : | Forfait | Durée de consultation | Export | | - | - | - | | Free | 30 jours | Non | | Growth | 1 an | Non | | Scale | 3 ans | Oui | | Enterprise | Défini par votre contrat | Oui | Un export sur un forfait qui ne le prévoit pas renvoie `403` avec `"code": "plan_limit_exceeded"`. *** ## Sécurité et confidentialité ### Ce qui est journalisé Les journaux d'audit capturent les métadonnées des requêtes API : * Horodatage et durée de la requête * Identité de l'utilisateur (e-mail, identifiant utilisateur), ou la clé API ayant effectué la requête (son nom et les premiers caractères de son secret, jamais le secret complet) * Chemin de la requête et paramètres de requête * Codes de statut des réponses * Adresse du client et agent utilisateur ### Corps des requêtes et des réponses des appels effectués avec une clé API Pour un appel effectué avec une clé API, le journal d'audit conserve également une copie caviardée du corps JSON de la requête d'écriture, ainsi que de la réponse à une écriture ou à une erreur, afin que vous puissiez comprendre pourquoi un appel a échoué. La réponse à une lecture réussie n'est pas conservée. Le caviardage fonctionne par refus par défaut : * La structure est conservée : noms des champs, imbrication, types de valeurs, longueurs des tableaux et longueurs des chaînes. * Une valeur n'est conservée que si elle est l'un des identifiants, statuts, codes, compteurs ou horodatages propres à Didit, placée dans un champ défini par Didit, et sous la forme attendue par ce champ. * Un booléen n'est conservé que dans un champ défini par Didit. * Toute autre valeur est remplacée par un marqueur indiquant son type et sa longueur, par exemple `[redacted:string:12]`, `[redacted:number:5]` ou `[redacted:boolean]`, et `null` reste `null`. * Un nom de champ qui n'est pas un identifiant simple, comme une adresse e-mail ou un numéro de téléphone utilisé comme clé, est remplacé par `[redacted:key:23]`. * Un corps qui n'est pas du JSON, comme un formulaire ou un fichier envoyé, est remplacé par une note indiquant de quoi il s'agissait. * Le contenu restant est tronqué à 4 096 caractères. Les paramètres de requête suivent le même caviardage. Seuls les en-têtes standard, comme `content-type`, `user-agent` et les en-têtes de limite de débit, sont conservés ; tout autre en-tête est supprimé avec sa valeur. Une valeur envoyée par votre propre système, par exemple dans `metadata` ou `vendor_data`, n'est jamais conservée, même lorsque son champ porte un nom similaire à l'un de ceux définis par Didit. ### Ce qui n'est PAS journalisé Pour protéger les données sensibles, les éléments suivants sont automatiquement exclus : * Jetons d'authentification et identifiants * Mots de passe et secrets * Données personnelles issues des sessions de vérification ### Contrôle d'accès Consulter le journal d'audit nécessite les autorisations de lecture et de liste `audit-logs`. Les rôles Reader, Compliance Officer, Developer, Admin et Owner les possèdent tous, et un [rôle personnalisé](https://docs.didit.me/fr/console/roles-permissions.md) les obtient en sélectionnant Journaux d'audit dans l'éditeur de rôles. *** ## Cas d'usage courants > [accordion] Audit de conformité > > Montrez aux auditeurs que vous avez une visibilité complète sur les personnes ayant accédé aux données de vérification : > > 1. Filtrez par plage de dates correspondant à la période d'audit > 2. Filtrez par des applications ou des utilisateurs spécifiques, si nécessaire > 3. Exportez les résultats ou faites-en une capture d'écran pour la documentation > [accordion] Enquête de sécurité > > Si vous soupçonnez un accès non autorisé : > > 1. Recherchez l'adresse e-mail de l'utilisateur concerné ou les adresses IP suspectes > 2. Filtrez par plage de dates autour de l'incident présumé > 3. Recherchez les schémas inhabituels : tentatives d'authentification échouées, endpoints inattendus, horaires inhabituels > [accordion] Débogage d'intégration > > Lorsque vous résolvez des problèmes d'intégration de l'API : > > 1. Recherchez le chemin de l'endpoint concerné > 2. Filtrez par codes de statut `4xx` ou `5xx` pour trouver les erreurs > 3. Relevez les horodatages pour les corréler avec les journaux de votre application > [accordion] Revue de l'activité de l'équipe > > Suivez la manière dont votre équipe utilise la plateforme : > > 1. Filtrez par les adresses e-mail spécifiques des membres de l'équipe > 2. Examinez les sessions et les fonctionnalités auxquelles ils ont accédé > 3. Vérifiez que les membres de l'équipe respectent les procédures en vigueur *** ## Bonnes pratiques 1. **Revues régulières** : examinez périodiquement les journaux d'audit pour détecter rapidement les anomalies. 2. **Affiner votre recherche** : utilisez des filtres précis pour réduire le bruit et trouver plus vite les entrées pertinentes. 3. **Plages de dates** : indiquez toujours une plage de dates pour améliorer les performances sur les grands volumes de données. 4. **Ajouter les recherches aux favoris** : enregistrez les combinaisons de filtres courantes comme marque-pages de votre navigateur pour y accéder rapidement. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.