L’audit Dataverse enregistre qui a créé, modifié ou supprimé quel enregistrement, quels accès ont eu lieu et à quel moment, et constitue la piste de preuve exigée par vos obligations de conformité. La bonne pratique consiste à l’activer au niveau de l’organisation, puis à le restreindre immédiatement aux tables et champs qui ont une réelle valeur probante pour vos auditeurs.
Avant toute autre chose, vérifiez trois réglages :
- État de l’organisation : l’audit est activé au niveau environnement, mais pas nécessairement sur chaque table.
- Période de rétention : un délai défini, pas une conservation indéfinie par défaut.
- Audit d’accès en lecture (read logging) : désactivé sauf besoin explicite, car il multiplie le volume de journaux.
Conseil de pro : dès la première semaine, désactivez l’audit de lecture par défaut. Ce réglage à lui seul évite la majorité des cas de saturation de stockage observés chez les administrateurs Dynamics 365.
Points clés
Un audit Dynamics 365 efficace repose sur une activation ciblée, une rétention calibrée et un export régulier vers un stockage externe pour préserver performances et budget.
| Point | Détails |
|---|---|
| Activer sélectivement | N’auditez que les tables et champs à valeur probante, jamais l’ensemble par défaut. |
| Limiter l’audit de lecture | Réservez le read logging aux données les plus sensibles, car il augmente considérablement le volume de logs. |
| Calibrer la rétention | Fixez AuditRetentionPeriodV2 sur vos obligations réglementaires réelles, pas par excès de prudence. |
| Archiver hors Dataverse | Exportez régulièrement vers Azure Data Lake Storage pour réduire le stockage transactionnel facturable. |
| Se faire accompagner | Dynamicsconnect aide les entreprises à concevoir une stratégie d’audit conforme et maîtrisée en stockage. |
Que couvre réellement l’audit dans Dataverse ?
L’audit Dataverse distingue deux logiques bien différentes : l’audit d’écriture, qui trace les créations, modifications et suppressions d’enregistrements (les opérations CRUD), et l’audit de lecture, qui journalise chaque consultation d’un enregistrement ou d’un champ. Cette distinction entre types d’audit conditionne toute votre stratégie de configuration.
L’activation se fait à trois niveaux emboîtés : l’organisation ou l’environnement, la table (ou entité), puis la colonne (le champ). Rien ne se journalise si l’un des trois niveaux reste désactivé, même si les deux autres sont actifs.
En pratique, trois cas d’usage reviennent systématiquement chez les entreprises françaises :
- Preuve de conformité financière lors d’un contrôle comptable ou fiscal.
- Traçabilité des accès aux données RH sensibles (rémunération, contrats).
- Historique des approbations dans un processus métier critique (validation d’achat, avenant contractuel).
Comment activer l’audit au niveau de l’organisation ?
L’activation globale se pilote depuis le Power Platform admin center, dans les paramètres de l’environnement concerné. Le chemin est direct : sélectionnez l’environnement, ouvrez la section Audit and logs, puis basculez le commutateur d’activation.
Trois étapes structurent cette configuration :
- Accédez au Power Platform admin center, choisissez l’environnement cible et ouvrez les paramètres d’audit.
- Activez ou désactivez l’audit global, ce qui conditionne tout ce qui suit au niveau table et champ.
- Définissez la période de rétention via le paramètre
AuditRetentionPeriodV2, qui accepte plusieurs intervalles selon vos exigences réglementaires.
Cette configuration est détaillée dans le guide officiel de gestion des audits Dataverse, qui précise également les valeurs par défaut appliquées à chaque nouvel environnement.
Activer l’audit au niveau organisation a un effet immédiat : chaque table et chaque champ préalablement marqués comme auditables commencent à écrire des logs dès la validation du changement, sans délai de propagation notable. Sur un environnement de production déjà volumineux, cela peut générer un pic d’écriture significatif dès les premières heures.
Conseil de pro : définissez votre politique de rétention avant d’activer l’audit, pas après. Revenir sur une politique de rétention laxiste appliquée à des millions d’enregistrements impose ensuite une purge lourde et risquée.
Faut-il auditer toutes les tables ou seulement certaines ?
Non. Auditer l’ensemble des tables et champs par défaut est l’erreur la plus fréquente chez les administrateurs qui découvrent la fonctionnalité. La configuration se fait table par table, puis champ par champ, depuis le concepteur Dataverse (Power Apps → Tables → Propriétés avancées), en s’appuyant sur la propriété IsAuditEnabled décrite dans le guide développeur sur la configuration de l’audit.
La règle métier à appliquer est simple : n’auditez que les tables et les champs qui ont une valeur probante réelle pour un contrôle de conformité ou une enquête de sécurité. Excluez systématiquement les champs mis à jour en continu par des automatisations, des plugins ou des workflows Power Automate, ces champs génèrent des volumes de logs considérables sans apporter d’information exploitable.
L’option d’audit de lecture (read logging) mérite une attention particulière : elle ne doit être activée que sur un périmètre très restreint, typiquement l’accès à des données à fort enjeu comme la rémunération d’un dirigeant ou un dossier RH confidentiel. Ce type d’audit génère un volume de données nettement supérieur à l’audit d’écriture classique, ce qui en fait une option à réserver à des cas précis.
Notez enfin que certaines propriétés d’audit sont gérées via BooleanManagedProperty et deviennent verrouillées (CanBeChanged à faux) sur des solutions gérées, ce qui limite votre capacité à les modifier après déploiement.
Conseil de pro : testez toute nouvelle configuration d’audit sur un environnement sandbox et documentez par écrit les décisions d’inclusion et d’exclusion, table par table. Cette documentation devient précieuse lors d’un audit de conformité externe.
Où consulter l’historique d’audit d’un enregistrement ?
Deux vues distinctes répondent à deux besoins différents. Pour un enregistrement précis, l’onglet associé « Historique d’audit » (Audit History) accessible depuis les applications pilotées par modèle affiche chronologiquement chaque modification, avec l’utilisateur, la valeur avant et après changement.
Pour une vue agrégée sur l’ensemble de l’environnement, le résumé d’audit (Audit Summary) accessible depuis les paramètres d’environnement du Power Platform admin center permet de filtrer par table, par utilisateur ou par plage de dates.
Deux privilèges conditionnent l’accès à ces vues :
- View Audit History pour consulter l’historique d’un enregistrement individuel.
- View Audit Summary, généralement réservé aux rôles administrateur système ou auditeur dédié.
L’interface native impose des limites de filtrage qui deviennent vite frustrantes pour des recherches récurrentes. Pour vos auditeurs internes, construire des vues et des rapports Power BI connectés aux données d’audit reste la solution la plus robuste pour industrialiser ces contrôles périodiques.
Comment extraire les données d’audit via l’API Web ?
L’interface d’audit convient pour une consultation ponctuelle, mais toute stratégie d’audit sérieuse repose sur l’extraction programmatique. Trois points d’entrée structurent cette extraction.
RetrieveAuditDetails récupère les détails complets d’un enregistrement d’audit donné, y compris les valeurs avant et après modification. RetrieveRecordChangeHistory retourne l’historique complet des changements pour un enregistrement, avec pagination pour les historiques volumineux. Ces deux messages sont documentés dans le guide développeur sur la récupération des données d’audit, qui précise que les réponses distinguent plusieurs types de détails (AttributeAuditDetail pour les changements de champs, RelationshipAuditDetail pour les relations, UserAccessAuditDetail pour les accès), une nuance essentielle si vous concevez vos propres parseurs d’export.
L’action GetAuditStorageDetails complète ce dispositif en indiquant l’empreinte de stockage occupée par l’audit, table par table, ce qui en fait l’outil de diagnostic de référence avant toute décision de purge, comme le détaille la procédure officielle de suppression des journaux d’audit.
Un point technique à anticiper dans vos développements : les valeurs de champs capturées dans un enregistrement d’audit sont plafonnées à 5 Ko, ce qui peut tronquer des champs texte volumineux lors de l’extraction.
Conseil de pro : plutôt que de conserver des années d’historique dans Dataverse, automatisez un export quotidien vers un data lake au format Parquet dans Azure Data Lake Storage. Vous réduisez le stockage transactionnel tout en gardant une capacité de requête longue durée, à moindre coût.
Comment éviter que l’audit ne sature le stockage ?
L’audit consomme de l’espace de stockage facturable dans votre capacité Dataverse, et cette consommation augmente les coûts d’I/O sur les tables les plus sollicitées, une réalité documentée dans le guide de gestion du stockage Power Platform. Quatre leviers permettent de garder le contrôle.
La sélection ciblée des tables et champs reste le levier le plus efficace. Chaque table auditée inutilement, chaque champ technique journalisé sans raison, alourdit la table AuditBase sans bénéfice de traçabilité réel.
La durée de rétention doit être calibrée sur vos obligations réglementaires réelles, pas sur un réflexe de prudence excessive. Une rétention de sept ans a un sens pour des données comptables soumises à contrôle fiscal ; elle n’en a aucun pour un champ de statut interne.
L’archivage par paliers structure une stratégie de stockage à trois niveaux : les données récentes restent dans Dataverse pour consultation rapide (« hot »), les données intermédiaires migrent vers un stockage moins coûteux mais encore interrogeable (« warm »), et les données anciennes soumises à obligation légale sont archivées hors Dataverse, typiquement dans Azure Blob Storage ou Azure Data Lake Storage (« cold »).
La gouvernance des environnements évite un écueil fréquent : la copie systématique d’environnements de production vers des sandboxes, qui duplique l’historique d’audit sans en avoir besoin. Une politique de nettoyage régulier des environnements de test limite cette prolifération inutile.
Voici les points de vigilance à surveiller en priorité :
- Croissance de la table
AuditBasesur une période de trente jours glissants. - Volume disproportionné généré par l’audit de lecture sur une ou plusieurs tables spécifiques.
- Copies d’environnements conservant un historique d’audit obsolète.
- Absence de pipeline d’export automatisé vers un stockage externe.
Un exercice de réduction de stockage typique combine trois actions : analyser les index de la table d’audit pour identifier les tables les plus lourdes via GetAuditStorageDetails, supprimer les journaux devenus inutiles selon votre politique de rétention validée, puis mettre en place un archivage régulier pour éviter que le problème ne se reproduise.
Conseil de pro : exécutez GetAuditStorageDetails chaque trimestre et fixez des seuils d’alerte par table. Un seuil dépassé déclenche une revue de configuration avant que le problème ne devienne critique.
Qui a le droit de configurer et de supprimer les journaux d’audit ?
L’accès à l’audit se structure autour de quelques privilèges précis : prvReadRecordAuditHistory pour consulter l’historique d’un enregistrement, View Audit Summary pour la vue agrégée, et des droits d’administrateur système ou de personnalisateur pour modifier la configuration elle-même.
Trois rôles distincts limitent les risques de dérive :
- Administrateur d’audit : configure les paramètres d’activation et de rétention.
- Lecteur d’audit : consulte les journaux sans droit de modification, rôle adapté aux auditeurs externes.
- Opérateur de purge : seul habilité à exécuter des suppressions planifiées de journaux.
La suppression d’un journal d’audit est irréversible, un avertissement explicite qui figure dans la documentation Microsoft. Restreignez cette capacité à un nombre réduit de comptes et journalisez chaque opération de purge. Pour les exports automatisés, privilégiez des comptes de service dédiés dont l’activité reste traçable indépendamment des comptes utilisateurs.
Que faire quand les journaux d’audit posent problème ?
Trois symptômes reviennent régulièrement : une croissance rapide et inexpliquée de la table AuditBase, des formulaires qui ralentissent après l’activation de l’audit de lecture sur certaines tables sensibles ou à fort trafic, et des erreurs de délai lors d’exports API sur de gros volumes historiques.
Le diagnostic suit une séquence logique :
- Identifiez les tables les plus volumineuses avec
GetAuditStorageDetails. - Désactivez l’audit sur les champs sans valeur probante réelle, en particulier ceux mis à jour par automatisation.
- Lancez une purge contrôlée, en commençant toujours par les journaux les plus anciens.
Pour prévenir la récurrence, instaurez une revue trimestrielle de la configuration d’audit, automatisez vos exports vers un stockage externe et testez systématiquement l’impact performance de toute nouvelle activation sur un environnement sandbox avant la production.
Avant toute purge d’urgence, une checklist courte évite les erreurs irréversibles : exportez l’intégralité des données concernées, informez vos auditeurs internes de l’opération à venir, et supprimez toujours les enregistrements les plus anciens en premier.
Dynamicsconnect vous accompagne dans la mise en conformité de votre audit Dynamics 365
Configurer un audit Dynamics 365 pertinent demande d’arbitrer entre exigences de conformité, contraintes de stockage et performance utilisateur, un exercice que peu d’équipes internes ont le temps d’approfondir seules. Dynamicsconnect accompagne les PME et ETI françaises dans cette phase de cadrage, de la définition de la stratégie de rétention jusqu’à l’intégration des données d’audit dans vos outils de reporting.
Notre offre d’audit et de conseil part d’un principe simple : auditer vos processus métier existants avant de toucher à la configuration technique, pour ne journaliser que ce qui a une valeur réelle pour vos contrôles de conformité et votre sécurité. Cette approche évite l’écueil classique de l’activation générique qui sature le stockage sans apporter de traçabilité utile. Les données d’audit correctement structurées deviennent aussi un levier pour vos équipes commerciales et opérationnelles, un principe que développe cet article sur l’organisation du suivi client.
Si votre environnement Dynamics 365 ou votre projet Business Central nécessite un cadrage sur la gouvernance des données et la conformité, demandez un diagnostic Business Central auprès de nos consultants pour évaluer votre configuration actuelle et prioriser les actions correctives.
Sources
Six ressources Microsoft couvrent l’essentiel des besoins d’un administrateur Dynamics 365 sur ce sujet :
- Dataverse auditing — key concepts (Microsoft)
Questions fréquentes
Quels sont les 7 principes d’un audit ?
Les référentiels d’audit s’appuient généralement sur l’intégrité, la présentation impartiale, la conscience professionnelle, la confidentialité, l’indépendance, une approche fondée sur la preuve et une approche fondée sur les risques. Appliqués à Dynamics 365, ces principes se traduisent par une traçabilité exacte des changements et une restriction des accès aux journaux.
Que doit contenir un rapport d’audit Dynamics 365 ?
Un rapport d’audit technique complet inclut généralement le périmètre des tables et champs audités, la période de rétention appliquée, l’historique des accès sensibles, les anomalies de configuration détectées et les recommandations correctives.
Quelles sont les principales fonctionnalités de Microsoft Dynamics 365 ?
Dynamics 365 couvre la gestion commerciale (Sales), le service client (Customer Service), la gestion des interventions terrain (Field Service) et la gestion financière et opérationnelle via Business Central, l’ensemble reposant sur la même plateforme Dataverse et ses fonctions d’audit natives.
Qu’est-ce qu’un audit logiciel dans le contexte de Dynamics 365 ?
Il s’agit du mécanisme natif de Dataverse qui enregistre les créations, modifications, suppressions et, en option, les accès en lecture, sur les tables et champs configurés pour l’audit, avec conservation selon une période définie par l’administrateur.
Faut-il activer l’audit de lecture par défaut ?
Non. L’audit de lecture génère un volume de données nettement supérieur à l’audit d’écriture classique et doit rester réservé aux données à très fort enjeu de confidentialité, comme les dossiers RH ou les rémunérations.
Recommandation
- Optimisez votre chaîne logistique avec Microsoft Dynamics 365 Supply Chain Management
- 5 défis de gestion de parc résolus par Dynamics 365 Field Service
- Gestion des interventions sur le terrain avec D365 Field Service
- Optimisation de la planification des ressources | Gagnez en efficacité avec Dynamics 365 Field Service
