Un portail client Business Central avec Power Pages : commandes et factures en direct, sans copier les données
Par Fred Morin ·
Aussi en anglais : A Business Central customer portal with Power Pages: live orders and invoices, no data copied
Testé le 2 octobre 2026 avec Business Central 28.5 (bac à sable, données de démonstration CRONUS) et un site Power Pages sur le modèle de données amélioré. Power Pages sur les tables virtuelles Business Central est encore une fonctionnalité en préversion : tout ceci peut changer.
Vos clients appellent pour savoir où en est leur commande. Quelqu'un ouvre Business Central, lit la réponse à l'écran et raccroche. Puis le client suivant appelle au sujet d'une facture.
Les données sont déjà là. Le client ne peut simplement pas les voir.
Je voulais savoir jusqu'où la plateforme Microsoft permet d'aller aujourd'hui sans écrire d'intégration. J'ai donc monté un petit portail : un client se connecte et voit ses commandes de vente ouvertes et ses factures enregistrées, lues en direct dans Business Central. Voici comment les pièces s'assemblent, et où ça a résisté.
Ce que fait le portail
Un contact client connecté peut :
- voir les commandes de vente ouvertes de son entreprise
- voir les factures enregistrées de son entreprise
- envoyer une demande de service, la suivre et l'annuler
Les commandes et les factures ne sont copiées nulle part. Chaque affichage de page lit Business Central à ce moment-là. Les demandes de service sont les seules données conservées hors de BC, dans une table Dataverse.

La page des commandes telle que la voit un contact client connecté. Les lignes viennent de Business Central au moment où la page se charge.
L'architecture, en quatre pièces
1. Les tables virtuelles : Business Central vu de Dataverse
Une table virtuelle est une table Dataverse qui ne contient rien. C'est une fenêtre sur un autre système. Quand on l'interroge, Dataverse appelle l'API de Business Central et renvoie les lignes.
Microsoft fournit cela sous la forme de l'application Business Central Virtual Table. Une fois l'application installée et connectée, une table BC comme Client ou Commande de vente apparaît dans Dataverse comme n'importe quelle autre table, et Power Pages peut l'afficher en liste.
2. Un lien entre l'utilisateur du portail et un client BC
La connexion à Power Pages repose sur la table Contact de Dataverse. Chaque utilisateur du portail est un contact.
La table Contact reçoit donc une colonne de plus : une recherche vers la table virtuelle Client de BC. Ce seul champ indique à quelle entreprise appartient un utilisateur du portail. Toute la sécurité en dépend.
3. Le site : des listes sur les tables virtuelles
Deux pages de liste, une sur Commande de vente et une sur Facture de vente, chacune affichant une vue Dataverse. Aucun code personnalisé pour celles-ci.
4. Les autorisations de table : seulement les lignes de votre entreprise
C'est la partie qui ne s'est pas passée comme prévu. Elle a son propre article : pourquoi l'étendue Parent échoue sur les tables virtuelles Business Central, et ce qui fonctionne.
En résumé : une relation synthétique entre le contact et chaque table de documents, avec des autorisations d'étendue Contact.
La configuration, étape par étape
Obtenir un environnement capable d'héberger un site
Mon locataire avait Business Central et rien d'autre. Deux surprises avant même d'avoir construit quoi que ce soit :
- Sans une licence Power Apps quelconque, impossible de créer un environnement Dataverse. Me connecter à Power Pages et accepter le plan Développeur a réglé le problème.
- L'environnement par défaut ne peut pas héberger de site. Il en faut un autre, avec Dataverse.
Installer l'application de tables virtuelles
On peut l'obtenir sur AppSource. Je l'ai installée avec l'interface de ligne de commande de Power Platform :
pac application install --environment <id-environnement> --application-name MicrosoftBusinessCentralVEAnchor
Sur un environnement tout neuf, la première tentative a échoué avec Unable to load plug-in assembly. J'ai attendu deux minutes, relancé la même commande, et elle a réussi.
Connecter Business Central à Dataverse
Dans Business Central, lancez la configuration assistée Configurer une connexion à Dataverse :
- Activez Activer les tables virtuelles et les événements.
- Acceptez les conditions.
- Entrez l'URL de l'environnement Dataverse et connectez-vous comme administrateur.
- Quand l'assistant propose un modèle de propriété, activez Terminer la configuration sans synchronisation.
L'étape 4 compte. L'assistant penche vers l'intégration classique, qui copie les données dans Dataverse. Si vous ne voulez que des tables virtuelles, c'est ce commutateur qui le dit.
Activer l'utilisateur d'application pour les visiteurs du portail
Vos clients n'ont pas de licence Business Central. Business Central exécute leurs requêtes sous une application Entra intégrée nommée Power Pages Authenticated External Users.
Dans BC, ouvrez Applications Microsoft Entra, ouvrez cette fiche, mettez État à Activé et attribuez des ensembles d'autorisations. J'ai utilisé LOGIN, D365 BASIC et D365 READ. C'est plus large que ce dont ce portail a besoin. Dans un vrai projet, j'écrirais un ensemble d'autorisations limité aux tables exposées.
Il existe une deuxième application pour les visiteurs anonymes. Je l'ai laissée désactivée : personne ne devrait lire des données BC sans se connecter.
Rendre les tables BC visibles
Installer l'application ne crée pas les tables virtuelles. C'est vous qui choisissez lesquelles vous voulez.
Le guide de Microsoft le fait dans l'application Business Central Configuration : ouvrez Available Tables, choisissez une table, cochez Visible. Il m'en fallait quatre : Client, Commande de vente, Ligne de commande de vente et Facture de vente.
Je l'ai plutôt fait par l'API Web de Dataverse, et j'ai rencontré une erreur qui vaut la peine d'être connue. Un simple PATCH sur la ligne du catalogue renvoyait 0x80040216 An unexpected error occurred. Un seul en-tête a réglé le problème :
PATCH /api/data/v9.2/dyn365bc_businesscentralentities(<id-ligne>)
If-Match: *
Content-Type: application/json
{ "dyn365bc_hasbeengenerated": true }
Sans If-Match: *, l'API Web traite l'appel comme un upsert, et cette table le refuse.
Les tables apparaissent avec des noms comme dyn365bc_salesorder_v2_0. Interrogez-les et vous obtenez les lignes de BC en direct.
Lier le contact au client BC
Dans la table Contact, ajoutez une colonne de recherche vers la table virtuelle Client. Dataverse a accepté sans broncher une recherche d'une table native vers une table virtuelle.
Créez ensuite vos contacts du portail et renseignez ce champ pour chacun.
Créer le site, et vérifier son modèle de données
Le guide de Microsoft demande le modèle de données amélioré. Mon nouveau site est arrivé sur le modèle standard. Je l'ai migré avant d'y construire quoi que ce soit :
pac pages migrate-datamodel --webSiteId <id-site> --mode all
pac pages migrate-datamodel --webSiteId <id-site> --updateDataModelVersion --portalId <id-portail>
Vérifiez quel modèle vous avez avant de commencer à ajouter des pages.
Construire les vues et les listes
Les vues fournies avec les tables virtuelles affichent une seule colonne, le numéro du document. J'ai créé les miennes, avec les dates, l'état et les totaux.
Deux choses m'ont surpris dans les données :
- « Facture de vente » ne contient pas que des factures enregistrées. La table correspond à l'API
salesInvoicesde BC, qui renvoie aussi les brouillons. Ma vue filtre sur l'état pour que les clients ne voient que les factures ouvertes, payées, annulées et correctives. - Les lignes de commande ne peuvent pas être listées seules. Une requête sans filtre renvoie
You must specify an Id or a Document Id to get the lines. On ne peut lire les lignes que pour une commande donnée.
Une fois les vues en place, chaque page est une liste Power Pages standard qui pointe vers une vue.

La liste des factures, avec ma propre vue : dates, état et montants, brouillons exclus, dix lignes par page.
Sécuriser le tout
Des autorisations de table d'étendue Contact, au moyen d'une relation synthétique. Le deuxième article donne les étapes, et l'erreur qui vous attend si vous essayez d'abord le modèle évident.
Ajoutez aussi des autorisations de page, pour que les visiteurs anonymes soient envoyés à la page de connexion plutôt que devant une liste vide. Les autorisations de page cachent des pages. Les autorisations de table protègent les données. Il faut les deux.
Le résultat
J'ai testé avec deux contacts, chacun lié à un client CRONUS différent.
- Chacun a vu exactement les trois commandes ouvertes de son entreprise.
- Chacun a vu les factures enregistrées de son entreprise, dix par page.
- Aucun n'a vu quoi que ce soit appartenant à l'autre.
- Une fois déconnecté, chaque page de données redirigeait vers la connexion.

Une fois déconnecté, la page des commandes renvoie à la connexion.
Les listes ne sont pas instantanées. Chaque affichage est un appel en direct à Business Central, et l'indicateur de chargement le montre.
Une bizarrerie de requête vaut la peine d'être connue. En FetchXML sur ces tables, top="10" renvoyait une seule ligne. La pagination avec count et page renvoyait les bonnes lignes. Les listes utilisent la pagination, donc elles fonctionnent. Si vous écrivez votre propre FetchXML en Liquid, utilisez aussi count et page.
Si vous construisez quelque chose de semblable aujourd'hui
- N'oubliez pas que c'est une préversion. Microsoft le dit sur la page même de la fonctionnalité. Parfait pour un projet pilote. Lisez les conditions avant d'y mettre un client.
- Décidez tôt si vous voulez des données en direct. Les tables virtuelles donnent des chiffres à jour et rien à synchroniser. Elles signifient aussi que chaque page attend Business Central, et que le portail tombe quand BC tombe.
- Comptez les utilisateurs par client. La méthode de sécurité qui fonctionne permet un seul contact par client BC. Le deuxième article explique pourquoi.
- Gardez le lien vers le client hors de portée de l'utilisateur. Cette seule recherche décide quelles données une personne voit. Elle ne doit figurer sur aucun formulaire qu'un utilisateur du portail peut modifier.
- Scriptez ce que vous pouvez. L'essentiel de cette configuration se fait avec l'interface de ligne de commande de Power Platform et l'API Web de Dataverse, ce qui la rend répétable dans l'environnement suivant.
Pas seulement pour les commandes et les factures
Le même modèle s'applique à tout ce que BC expose par son API : expéditions, devis, articles, documents fournisseurs. L'application de tables virtuelles en propose bien plus d'une centaine.
Si votre équipe passe ses journées à lire Business Central à voix haute à vos clients, parlons-en.