Et surtout : que faire face à cette réalité

Il existe un moment qui survient dans presque tous les projets d’analytique sur Dynamics 365 Finance.

L’équipe BI a évalué le périmètre. Le planning semble raisonnable. Les outils sont choisis.
Quelqu’un affirme : « il suffit de se connecter à la base de données et de construire le modèle ».

Trois mois plus tard, les tableaux de bord ne sont toujours pas en production.
Les données ne correspondent pas à ce qu'on voit sur l'écran.
Des chiffres qui semblent corrects s’avèrent faux dans certains cas.
Des champs visibles à l’écran n’existent dans aucune table.
Le modèle de données, censé être construit en un sprint, a consommé tout le projet.

Ce n’est pas un problème de compétence ou d’effort.
C’est un problème de gestion des attentes — plus précisément, l’idée qu’une base de données ERP se comporte comme une source de données classique.

Ce n’est pas le cas.

Cet article explique pourquoi — et surtout, comment y faire face.

Le problème fondamental : les bases de données ERP ne sont pas conçues pour l’analytique

Les bases de données relationnelles conçues pour le transactionnel et celles conçues pour l’analytique reposent sur des logiques fondamentalement différentes.

Un entrepôt de données ("data warehouse") est conçu pour la requête :
les tables sont larges, dénormalisées, optimisées pour l’agrégation.
Un événement métier correspond généralement à une seule ligne.

Une base ERP est conçue pour le transactionnel :
elle est normalisée pour garantir l’intégrité, pas la lisibilité.
Un événement métier — facture fournisseur, paiement client, écriture comptable — est réparti sur plusieurs tables, chacune capturant un aspect spécifique.

Dynamics 365 Finance ne fait pas exception.

Comprendre cet écart est le point de départ de tout projet analytique réaliste.

1. Un événement métier est réparti sur plusieurs tables

Lorsqu’une facture fournisseur est comptabilisée dans Dynamics 365 Finance, elle ne crée pas un enregistrement unique.
Elle génère des écritures dans plusieurs tables simultanément, chacune ayant un rôle précis.

La transaction fournisseur elle-même est notamment portée par VendTrans, tandis que les écritures comptables générées se retrouvent dans les structures comptables comptabilisées comme GeneralJournalEntry et GeneralJournalAccountEntry. Des données complémentaires, comme les taxes ou certaines références analytiques, sont stockées dans d’autres tables spécialisées.

Une équipe analytique qui interroge une seule de ces tables obtiendra au mieux une vision partielle — et souvent des résultats subtilement incorrects.

La logique de jointure nécessaire pour reconstruire un événement complet est complexe — et varie selon le type de transaction.

Ce n’est pas spécifique à D365.
C’est une caractéristique structurelle des ERP.

Mais le modèle de données de Dynamics 365 Finance est particulièrement riche, avec des centaines de tables impliquées dans les flux financiers.

Implication pratique :
le point de départ d’un projet analytique D365 doit être un exercice de cartographie du modèle de données — pas la construction immédiate de tableaux de bord.

→ Pour comprendre le lien entre le grand livre et l'auxiliaire :
https://www.fitgapfinance.com/grand-livre-vs-auxiliaire-d365-finance/

2. Il n’existe pas de modèle de données D365 universel

C’est probablement la complexité la plus sous-estimée.

Le modèle de données de Dynamics 365 Finance n’est pas figé.
Il dépend directement de la configuration du système.

Les dimensions financières en sont l’exemple le plus parlant.
Une organisation utilisant trois dimensions (unité commerciale, département, centre de coûts) n’a pas la même structure que celle qui en utilise six.

Les dimensions ne sont pas stockées en colonnes, mais sous forme de clé composite (LedgerDimension / DefaultDimension) pointant vers des tables d’attributs.

Une requête correcte dans un environnement peut produire des résultats incomplets ou erronés dans un autre.

Même logique pour :

• la configuration des stocks
• l’activation de fonctionnalités (catch-weight, multi-entrepôts)
• l’utilisation ou non du module projets

Chaque choix modifie les tables utilisées et leur contenu.

Implication :
il n’existe pas de modèle analytique standard réutilisable d’un client à l’autre.

Le modèle doit être reconstruit à partir de l’instance réellement configurée.

C’est pourquoi une architecture analytique conçue « sur papier » avant d’analyser le système réel nécessite presque toujours des reprises.

3. Ce que vous voyez à l’écran n’existe pas toujours en base

C’est l’un des points les plus déroutants pour les équipes BI.

De nombreuses valeurs affichées dans l’interface ne sont pas stockées en base de données.
Elles sont calculées dynamiquement par la logique applicative.

Exemples courants :

• montants nets calculés sur certaines lignes
• analyses d’ancienneté ("aging") fournisseurs/clients
• champs dérivés liés aux taxes
• soldes calculés fournisseurs / clients
• certaines valeurs dans les états financiers

Une équipe BI qui suppose qu’un champ visible correspond à une colonne va parfois avoir raison… et parfois perdre plusieurs jours à chercher un champ qui n’existe pas.

Dans certains cas, il faut reconstruire une logique métier complète côté analytique.

Approche recommandée :
valider systématiquement chaque champ dès la phase de design par rapport au schéma réel de la base.

Ce contrôle est rarement intégré dans les méthodologies BI — et explique de nombreux retards.

4. La qualité des données dépend des processus amont

Les équipes analytiques héritent souvent de problèmes qu’elles ne peuvent pas corriger seules.

Dans Dynamics 365 Finance, la qualité de l’analytique dépend directement de la discipline opérationnelle :

• écritures manuelles incohérentes
• dimensions incomplètes
• réceptions non rapprochées
• transactions intercompagnies non alignées

Ces problèmes ne sont pas visibles dans le modèle de données.
Ils sont visibles dans les données elles-mêmes.

Un modèle analytique construit sur des processus instables produit des rapports techniquement corrects… mais inutilisables.

La perte de confiance ne vient pas des dashboards — mais de la réalité opérationnelle qu’ils reflètent.

Conclusion :
ce n’est pas un problème technique.
C’est un problème de gouvernance des processus.

→ https://www.fitgapfinance.com/cout-cache-reporting-plus-rapide-erp/

5. Les suppressions ne signifient pas toujours suppression

La gestion du cycle de vie des données est plus complexe qu’elle n’y paraît.

Dans D365 :

• certaines transactions sont inversées ("reversal"), pas supprimées
• certaines lignes sont marquées comme inactives ("soft delete")
• d’autres sont réellement supprimées

Conséquences :

• double comptage
• soldes incorrects
• bruit dans les analyses

Un paiement annulé génère deux écritures opposées.
Inclure les deux donne un résultat correct.
En inclure une seule crée une erreur.

Le problème : les indicateurs de renversement ne sont pas toujours évidents.

Conclusion :
une expertise du modèle D365 en amont évite une grande partie de ces erreurs.

6. Les dimensions financières ne sont pas des colonnes

C’est souvent un choc pour les équipes BI.

Les dimensions ne sont pas stockées directement sur les transactions.
Elles sont stockées via des clés composites référencées dans d’autres tables.

Récupérer l'unité commerciale, le département ou le centre de coûts nécessite des jointures spécifiques.

Conséquences :

• complexité technique
• impacts performance
• logique fragile

De plus, l’ajout d’une dimension ne modifie pas les tables transactionnelles — mais casse silencieusement les modèles analytiques existants.

Conclusion :
la logique d’extraction des dimensions doit être conçue explicitement, pas improvisée.

Que faire concrètement

Ces difficultés ne sont pas des obstacles.
Elles imposent simplement une approche réaliste.

Principes clés :

1. Cartographier avant de construire
Le travail réel commence par la compréhension du modèle de données.

2. Intégrer une expertise D365 dès le départ
Le coût d’apprentissage sinon est systématique.

3. Traiter la qualité des données comme un sujet de gouvernance
Pas comme un problème technique à contourner.

4. Concevoir pour un système évolutif
Le modèle changera — c’est une certitude.

5. Valider les champs calculés en amont
Une heure au début évite des jours de reprise.

Conclusion

Le moment où l’équipe BI réalise que le projet est plus complexe que prévu est évitable.

Pas en simplifiant.
En comprenant la réalité des données ERP dès le départ.

Dynamics 365 Finance contient une richesse de données exceptionnelle.
Mais la valeur analytique n’est captée que par les organisations qui :

• comprennent le modèle
• maîtrisent les processus
• cadrent leurs projets sur la réalité

Pour aller plus loin

Le coût caché d’un reporting plus rapide dans les projets ERP
https://www.fitgapfinance.com/cout-cache-reporting-plus-rapide-erp/

Comment extraire des données depuis Dynamics 365 Finance
https://www.fitgapfinance.com/extraction-donnees-dynamics-365-finance-dmf-odata-excel-fabric/

Grand livre vs Auxiliaire dans D365 Finance
https://www.fitgapfinance.com/grand-livre-vs-auxiliaire-d365-finance/

La gouvernance ERP est non négociable
https://www.fitgapfinance.com/gouvernance-erp-roles-escalades-culture-d365/

🇬🇧 English version
https://www.fitgapfinance.com/d365-finance-analytics-project-complexity/

© 2026 FitGap Finance™
Réflexions pratiques ERP pour les leaders Finance