Tables standard Dataverse et tables virtuelles : quand cesser de copier les données

By Mirko Peters · 2026-08-22

Comparez les tables standard et les tables virtuelles de Dataverse. Découvrez quand cesser de copier les données d’entreprise et mettre en place des fenêtres en temps réel sur les systèmes externes.

Automatically translated with AI from the original post. Read the English original

Choisir entre une table standard Dataverse et une table virtuelle détermine l’efficacité avec laquelle votre entreprise gère les données externes. Alors que les tables standard stockent les enregistrements directement dans Dataverse, les tables virtuelles établissent des fenêtres en temps réel sur les systèmes externes d’ERP, d’entrepôt ou de finance, ce qui élimine les tâches de synchronisation nocturnes risquées ainsi que les informations obsolètes.

Points clés

• Les tables standard Dataverse stockent les enregistrements localement de manière permanente, tandis que les tables virtuelles affichent les enregistrements en temps réel, récupérés à la demande depuis les sources externes.
• Les tables virtuelles suppriment la nécessité de tâches de synchronisation nocturnes, qui exposent les équipes commerciales à des niveaux de stock obsolètes.
• Les choix d’architecture doivent privilégier l’emplacement réel du processus métier central et de la gestion du cycle de vie des enregistrements.
• Les performances, les autorisations de sécurité et les capacités de filtrage fonctionnent différemment sur les tables virtuelles, en raison de leur dépendance aux données externes.
• Les organisations peuvent réduire le surcoût de stockage et la duplication des données en connectant directement les utilisateurs aux applications externes faisant autorité, via Dynamics 365.

Le dilemme architectural : stockage ou accès

Lors du déploiement de Microsoft Dynamics 365 ou de Power Apps personnalisées, les architectes sont constamment confrontés à une question de conception fondamentale : faut-il copier les données externes dans Dataverse ou les laisser dans leur système d’origine et construire un pont ? Pendant des années, la réponse par défaut était la réplication. Les organisations planifiaient des routines d’intégration nocturnes pour transférer les catalogues produits, les soldes de stock et l’historique des factures directement dans Dataverse, afin que les utilisateurs puissent tout consulter au même endroit.

Cette stratégie de réplication engendre toutefois des contraintes architecturales importantes. Les limites de stockage augmentent, la base de données grossit rapidement et, surtout, l’obsolescence des données introduit un risque opérationnel. Si un employé d’entrepôt expédie dix unités d’un article critique à l’heure du déjeuner, une table répliquée dans Dataverse continuera d’afficher ces dix unités jusqu’à la prochaine synchronisation planifiée. Les commerciaux proposent alors des stocks indisponibles à des clients mécontents, ce qui entraîne des annulations de commandes et une perte de confiance. Les tables standard exigent une propriété absolue des données qu’elles hébergent, ce qui en fait de mauvais choix pour les indicateurs opérationnels en évolution rapide, gérés par des systèmes d’entreprise spécialisés.

Comparaison des tables standard et des tables virtuelles

Comprendre les différences opérationnelles entre les tables standard Dataverse et les tables virtuelles permet de savoir quand déployer chaque architecture. Cette distinction dépasse largement la sémantique technique : elle détermine la propriété du système, les flux de travail des utilisateurs et la charge de maintenance.

Tables standard Dataverse

Les tables standard, comme Comptes, Contacts et Opportunités, sont des éléments natifs de l’écosystème Dataverse. Dataverse crée les tables de base de données, gère le stockage physique, applique les modèles de sécurité au niveau des tables et exécute nativement la logique métier, les plug-ins et les flux de travail sur les enregistrements. Lorsqu’un utilisateur crée ou met à jour un enregistrement, Dataverse fait autorité en dernier ressort. La couche applicative et la couche de stockage sont entièrement unifiées.

Tables virtuelles

Les tables virtuelles fonctionnent davantage comme un catalogue de bibliothèque ou un flux vidéo sécurisé. Dataverse conserve le schéma, les définitions de colonnes et les métadonnées nécessaires pour afficher une interface familière dans les applications pilotées par modèle, mais il ne stocke pas les enregistrements eux-mêmes. Lorsqu’un utilisateur ouvre une vue ou applique un filtre, Dataverse traduit la requête, interroge le système externe via un fournisseur de données et affiche la réponse en temps réel. L’application externe reste seule maîtresse du cycle de vie de l’enregistrement.

Évaluer les compromis et les limites opérationnels

Si les tables virtuelles résolvent le cauchemar de la synchronisation, elles introduisent des contraintes spécifiques que les développeurs et les administrateurs doivent évaluer avec soin. Les données sous-jacentes ne résidant pas dans Dataverse, certaines fonctionnalités de la plateforme ne se comportent pas comme avec les tables standard.

Recherche avancée, plug-ins serveur complexes, champs de cumul et flux de travail asynchrones en arrière-plan peuvent se comporter de manière imprévisible, voire échouer complètement s’ils supposent une persistance locale des données. Par ailleurs, les performances dépendent directement de l’état et de la réactivité de l’API ou de la source de données externe. Si l’application ERP ou d’entrepôt externe souffre de latence ou devient indisponible, les tables virtuelles correspondantes dans Dynamics 365 se bloqueront ou afficheront des erreurs de connexion.

La modélisation de la sécurité demande également une planification rigoureuse. Les rôles de sécurité Dataverse peuvent contrôler qui consulte ou modifie la définition de la table virtuelle, mais la sécurité au niveau des lignes doit souvent être appliquée au niveau de l’API externe ou via des fournisseurs de données personnalisés, afin que les utilisateurs n’accèdent qu’aux enregistrements autorisés.

Conclusion

Le choix entre les tables Dataverse standard et les tables virtuelles dépend en définitive de la question de savoir qui possède le cycle de vie des données, et si vos utilisateurs ont besoin d’un stockage local persistant ou d’une simple visibilité contextuelle. En cartographiant les sources de données externes plutôt qu’en les répliquant, les organisations peuvent conserver un espace de travail unique et propre dans Dynamics 365, sans transformer Dataverse en un dépotoir encombré de tables de base de données dupliquées. Pour explorer les briques fondamentales de cette approche d’intégration, n’hésitez pas à écouter l’épisode complet et à vous abonner au podcast pour découvrir d’autres analyses pratiques sur le cloud.

Questions fréquentes

Les tables virtuelles consomment-elles de la capacité de stockage Dataverse ?

Non. Les tables virtuelles ne conservent dans Dataverse que les définitions de tables, les métadonnées et les schémas, tandis que les enregistrements restent dans le système externe ; elles ne consomment donc pas la capacité de stockage de base de données Dataverse de votre organisation.

Les utilisateurs peuvent-ils modifier les enregistrements affichés via une table virtuelle ?

Oui, à condition que le fournisseur de données sous-jacent et le système externe prennent en charge les opérations d’écriture. Les fournisseurs OData v4 intégrés et les intégrations Finance et Operations peuvent prendre en charge les actions de création, de mise à jour et de suppression, même si le système externe applique toujours ses propres règles de validation.

Que se passe-t-il si la source de données externe devient indisponible ?

Si l’application externe ou son API devient indisponible, les utilisateurs consultant la table virtuelle dans Dynamics 365 verront apparaître des erreurs de chargement ou des grilles vides, car les requêtes en temps réel ne peuvent pas récupérer les enregistrements externes.

Les tables virtuelles sont-elles identiques aux entités virtuelles ?

Oui. « Entités virtuelles » est le terme historique utilisé dans les anciennes documentations et configurations Microsoft, tandis que « tables virtuelles » est la terminologie officielle actuelle. L’architecture et les concepts sous-jacents restent identiques.