Augmentation des quotas Dataverse : de 10 Go à 30 Go pour Dynamics 365 & Power Platform (Décembre 2025)

En décembre 2025, Microsoft a révisé à la hausse les quotas de stockage Dataverse inclus par défaut dans les licences Dynamics 365 et Power Platform.

https://admin.cloud.microsoft/?#/MessageCenter/:/messages/MC1181915

MC1181915 - Microsoft Dataverse, Dynamics 365 Apps – Storage capacity and entitlements update

Cette mise à jour, qui a commencé à être appliquée dès le 01 décembre 2025, répond à un besoin clair : les anciennes limites (souvent 5 GB à 10 GB) freinaient la croissance des projets low-code, l’utilisation d’IA, les workflows lourds ou encore la gestion de gros volumes de données.

📈 Les nouveaux quotas Dataverse par type de licence

Voici les changements clés concernant le stockage de base (default database capacity) par produit ou licence :

👉 Pour les clients CRM classiques, le quota passe de 10 GB à 30 GB sans coût additionnel.

📌 Le stockage de fichiers a également été doublé pour la plupart des produits (par exemple, pour Dynamics 365 CRM : de 20 GB à 40 GB).

Par contre, le stockage des logs n’a pas changé.

📌 Comment fonctionne la capacité par défaut

Un point souvent mal compris : le quota de stockage Dataverse “par défaut” ne s’ajoute pas cumulativement à chaque licence :

• Le premier produit qualifiant (Power Apps, Power Automate, Power Pages, Copilot Studio ou une licence Dynamics 365) octroie une capacité par défaut une seule fois par tenant.

• Si tu ajoutes ensuite une licence avec un quota supérieur, le tenant adopte la valeur la plus élevée.

Par exemple : si tu avais Power Apps Per App (15 GB) puis ajoutes une licence Dynamics 365 CRM, ta capacité passe à 30 GB, mais pas à 15 GB + 30 GB.

💡 Impact concret pour les organisations

🚀 1. Plus de liberté

Beaucoup de petites et moyennes organisations atteignaient rapidement le seuil de 10 GB. Avec 30 GB par défaut, les projets CRM durent plus longtemps avant de justifier l’achat de capacité additionnelle (qui reste coûteuse).

💰 2. Moins de pression financière

Avant, atteindre l’un des anciens seuils signifiait acheter des extensions à environ 40 $/GB/mois pour la base de données — un facteur de coût important.

🧠 3. Simplification et anticipation

L’unification du stockage ERP + Dataverse dans un pool unique par tenant facilite la planification de capacité, surtout dans les environnements combinant CRM et ERP.

📊 Comment vérifier si c’est déjà actif chez toi

1. Ouvre le Power Platform Admin Center.

2. Va dans Capacité > Résumé.

3. Tu y verras les quotas mis à jour pour :

   • Database

   • Files

   • Logs

👉 Ces valeurs sont automatiquement appliquées — aucune action manuelle n’est requise.

👉 Ou bien le lien direct : https://admin.powerplatform.microsoft.com/billing/licenses/Dataverse/overview

🧠 Conclusion — quelle est la vraie portée de ce changement

➡️ Cet ajustement représente l’une des plus importantes augmentations des quotas Dataverse depuis des années.

Pour les utilisateurs Dynamics 365 CRM et Power Platform, c’est un vrai coup de pouce pour :

• piloter plus de données,

• déployer davantage d’automatisations et d’apps low-code,

• supporter des scénarios IA plus lourds sans atteindre les limites rapidement.

⚠️ Attention : cela ne rend pas Dataverse illimité, et si ton organisation dépasse ces nouveaux seuils, tu devras toujours acheter des extensions.

Augmentation des prix des licences Microsoft 365 au 01 juillet 2026

📈 Microsoft augmente les prix de Microsoft 365 en 2026

Cette article est publié le 08/12/2025 suite à l’annonce Microsoft du 05/12/2025

Chaque fin d’année, une même dynamique s’installe : les entreprises révisent leurs prévisions financières et finalisent leur budget pour l’année suivante.

Cela va de même pour Microsoft qui annonce une hausse des tarifs de ses offres Microsoft 365 à partir du 1er juillet 2026.

Cette mise à jour tarifaire s'inscrit dans une stratégie plus large :

• intégrer plus de 1 100 nouvelles fonctionnalités, renforcer l’IA (notamment via Copilot),

• améliorer la sécurité et la conformité.

Dans cet article, nous revenons sur les changements annoncés, les produits concernés, et ce que les organisations doivent faire dès maintenant pour limiter l’impact financier.

📆 Quand les nouveaux tarifs entreront-ils en vigueur ?

La date officielle d’application est le 1er juillet 2026.

Tous les renouvellements à partir de cette date utiliseront les nouveaux tarifs.

Pour les entreprises en contrat annuel ou pluriannuel, il faudra vérifier la date de renouvellement : certaines pourront prolonger leurs prix actuels quelques mois de plus, tandis que celles qui renouvellent en Q3/Q4 2026 subiront immédiatement la nouvelle grille.

📦 Quels produits Microsoft 365 voient leur prix augmenter ?

Les hausses ne concernent pas toutes les offres, mais plusieurs SKU clés du marché business, enterprise et frontline.

Tableau récapitulatif des augmentations annoncées

Tableau récapitulatif des augmentations annoncées

➡️ Les offres Frontline (F1/F3) sont les plus impactées proportionnellement.
➡️ Les offres Business Basic / Standard subissent aussi une hausse notable.
➡️ Les offres Premium et certains plans Office restent inchangés.

🔍 Pourquoi cette augmentation des prix ?

Selon Microsoft, l’évolution est liée à plusieurs facteurs structurants :

1. L’intégration massive de l’IA au cœur de Microsoft 365

Copilot, copilots spécialisés, automatisation, analyse contextuelle… Ces capacités transforment la suite bureautique classique en plateforme intelligente.

2. Le renforcement continu de la sécurité cloud

Avec l’explosion des cyberattaques, Microsoft ajoute régulièrement des modules de détection, de prévention et de conformité.

3. Plus de 1 100 fonctionnalités ajoutées en quelques années

Nouvelles expériences Teams, améliorations Outlook, SharePoint Premium, automatisation Power Platform…
Le périmètre fonctionnel a considérablement évolué.

4. Une logique de réalignement avec la valeur perçue

Microsoft ajuste ses prix pour refléter les investissements réalisés — et pour se positionner face à Google Workspace, qui évolue également.

🎯 Ce que doivent faire les entreprises dès maintenant, surtout en pleine saison des budgets 2026

L’information tombe dans un moment critique : la construction des budgets IT 2026.

Pour éviter les mauvaises surprises, plusieurs actions sont recommandées :

1. Réaliser un audit des licences existantes

• Qui utilise quoi réellement ?

• Quels comptes sont inactifs ou surdimensionnés ?

• Quels services Microsoft 365 sont réellement utilisés ?

Un audit permet souvent d'économiser 10 à 25 % sans toucher au confort utilisateur.

2. Adapter les prévisions budgétaires 2026

Intégrer dès maintenant les nouveaux tarifs dans :

• le budget OPEX IT,

• les projections de coûts de croissance,

• les analyses financières multi-sites ou multi-filiales.

3. Optimiser les plans de licences

Exemples :

• passer certaines populations de E3 → Business Premium,

• adopter des licences Frontline mieux adaptées aux usages,

4. Anticiper les renouvellements

Les entreprises qui renouvellent avant juillet 2026 peuvent parfois verrouiller l’ancien tarif jusqu’à 12 mois selon leur contrat et leur mode de facturation.

🧭 Conclusion : une hausse à anticiper, pas à subir

La hausse des tarifs Microsoft 365 du 1er juillet 2026 n’a rien d’anodin, mais elle peut être maîtrisée si les organisations commencent dès maintenant à revoir :

• leur inventaire de licences,

• leur stratégie d’usage,

• leur budget 2026,

• et leurs scénarios de montée en valeur via l’IA.

Les DSI, responsables IT et directions financières ont tout intérêt à intégrer ces nouveaux tarifs dans leur feuille de route.

source : https://www.microsoft.com/en-us/microsoft-365/blog/2025/12/04/advancing-microsoft-365-new-capabilities-and-pricing-update/?msockid=2ea47271146d6ad720b9671415746be0

Changer un utilisateur de Business Unit sans perdre ses rôles dans Dynamics 365

Dans la vie d’une organisation, il est courant qu’un commercial change de division ou de pays (un VIE par exemple).

👉 Un collaborateur rejoint une nouvelle équipe.
👉 Un portefeuille client est transféré d’une BU à une autre.

Dans Dynamics 365, ce changement se traduit par une modification de la Business Unit (BU) de l’utilisateur.

Mais attention ⚠️ : si vous n’avez pas configuré correctement certains paramètres, cela peut avoir des conséquences.

Le problème

Lorsqu’on change un utilisateur de Business Unit, deux comportements “par défaut” posent souvent problème :

• Suppression des rôles de sécurité

  Dès que l’utilisateur passe dans une autre BU, tous ses rôles sont retirés.

  Résultat : l’utilisateur perd ses accès et ne peut plus travailler.*

• Migration des enregistrements vers la nouvelle BU

  Tous les enregistrements dont l’utilisateur est propriétaire (comptes, opportunités, activités…) changent également de BU.

  Cela peut casser la cohérence de la donnée et vos règles de gouvernance.

Bref, un simple changement administratif peut se transformer en cauchemar opérationnel.

La solution : deux paramètres OrgDBSettings à connaître

Heureusement, Dynamics 365 vous laisse la possibilité d’adapter ce comportement grâce aux OrgDBSettings (voir article sur OrgDBSettings).

1. Ne pas déplacer automatiquement les enregistrements

Le paramètre à modifier est :

Démarquez-vous

Quel que soit le cas, la façon dont vous racontez votre histoire en ligne peut faire toute la différence.

👉 Mettez-le à False.
Ainsi, lorsqu’un commercial change de BU, ses comptes et opportunités restent rattachés à leur BU d’origine.

2. Ne pas supprimer les rôles au changement de BU

Le paramètre à modifier est :

Démarquez-vous

Quel que soit le cas, la façon dont vous racontez votre histoire en ligne peut faire toute la différence.

👉 Mettez-le à True.
De cette façon, l’utilisateur conserve ses rôles de sécurité après le transfert.

Comment appliquer ces paramètres ?

Deux méthodes sont possibles :

• Solution Microsoft : téléchargez et installez la solution OrgDBSettings depuis le site officiel.

• XrmToolBox : utilisez le plugin OrgDBSettings Editor, qui permet de rechercher et modifier facilement les paramètres.

Recommandations pratiques

• Toujours tester en bac à sable avant de modifier un paramètre.

• Documenter les choix : certains DSI préfèrent garder le comportement par défaut (suppression des rôles = sécurité renforcée).

• Communiquer avec les équipes métiers : un changement de BU ne doit pas bloquer la productivité des collaborateurs.

Conclusion

Un changement de Business Unit est un événement courant dans la vie d’une organisation.
Mais dans Dynamics 365, sans configuration adaptée, cela peut conduire à des pertes de rôles et à des déplacements massifs de données.

Heureusement, en ajustant simplement deux paramètres OrgDBSettings :

• AlwaysMoveRecordToOwnerBusinessUnit = False

• DoNotRemoveRolesOnChangeBusinessUnit = True

… vous gardez le contrôle et évitez des tracas à vos équipes.

OrgDBSettings : les paramètres cachés de Dynamics 365

Quand on administre un environnement Dynamics 365, on se rend vite compte qu’il existe des comportements difficiles à expliquer.

👉 Pourquoi le commercial n’a plus accès ses accès lorsqu’on le change de Business Unit ?
👉 Pourquoi des comptes migrent automatiquement d’une division à une autre ?

Souvent, la réponse se trouve dans un endroit magique

Là ou se trouve beaucoup de paramétrage, cet endroit peu connu mais essentiel : OrgDBSettings.

Là où la magie opère

OrgDbSettings

Qu’est-ce qu’OrgDBSettings ?

L’OrgDBSettings (Organization Database Settings) est un ensemble de paramètres systèmes propres à votre organisation Dynamics 365.

Ils permettent de modifier le comportement par défaut de la plateforme.

Ces paramètres couvrent un large éventail de fonctionnalités :

• gestion de la sécurité et des rôles,

• comportement des Business Units,

• performance et timeouts,

• règles de synchronisation,

• et bien d’autres.

En clair : c’est une boîte noire qui contrôle la mécanique fine de Dynamics 365.

Comment y accéder ?

Il existe deux méthodes principales pour consulter et modifier les OrgDBSettings.

1. La solution officielle Microsoft

Voici comment installer OrgDbSettings sur votre environnement Power Platform

• Microsoft met à disposition une solution téléchargeable et installable directement dans votre environnement.
  ➡️ Télécharger la dernière version ici

• Importer là dans votre environnement Power Apps

• Retrouver la solution Organization Settings Editors (Dynamics 365) dans les solutions managées

• Cliquer sur la solution, dans les … aller sur "Switch to classic”

• Et voilà !

Solution Téléchargeable

On télécharge la solution en cliquant sur le .zip qui se termine en _managed

Go Power Apps et on importe la solution

Un droit d’administrateur Dynamics Power Platform est nécessaire pour y avoir accès

La solution importée, on l’ouvre

On clique simplement sur la solution

Et Switch to classic

Cela permettra d’accèder à l’outil de paramètrage

OrgDbSettings

Et voilà !

Une fois installée, vous pouvez consulter et modifier les paramètres depuis l’interface du CRM, sans outil externe.

Avantages :

• support officiel Microsoft,

• interface intégrée à Dynamics 365,

• pas besoin d’outil tiers.

Inconvénients :

• mise à jour de la solution nécessaire,

• interface un peu “brute” pour naviguer entre les paramètres.

2. L’éditeur OrgDBSettings dans XrmToolBox

Si vous êtes administrateur ou consultant, vous connaissez sûrement XrmToolBox, la boîte à outils indispensable pour Dynamics 365 et Dataverse.
Bonne nouvelle : il existe un plugin dédié appelé OrgDBSettings Editor.

Fonctionnalités :

• recherche rapide d’un paramètre,

• explications intégrées,

• modification en un clic,

• sauvegarde et documentation facilitée.

Avantages :

• interface claire et rapide,

• pas besoin d’installer de solution dans l’environnement,

• parfait pour gérer plusieurs organisations en parallèle.

Cas d’usage : pourquoi c’est utile ?

Prenons quelques exemples concrets :

• Empêcher la suppression automatique des rôles d’un utilisateur lors d’un changement de BU.

• Éviter que les enregistrements (comptes, opportunités) changent automatiquement de Business Unit avec leur propriétaire.

• Ajuster des comportements de synchronisation Outlook.

• Modifier des délais techniques (timeouts).

En résumé : l’OrgDBSettings permet d’adapter Dynamics 365 à vos règles métier et de gouvernance, sans personnalisation lourde.

🔒 Dynamics 365 – Comment filtrer les utilisateurs visibles dans un Lookup

Dans Dynamics 365, le champ Lookup vers la table Utilisateur (systemuser) est partout : attribution d’un enregistrement, responsable d’un compte, commercial en charge, etc.

Mais il souffre souvent d’un problème de pollution : tous les utilisateurs actifs s’y affichent, y compris ceux sans licence CRM, ou même des comptes techniques comme #ADSync.

👉 Dans cet article, je t’explique pourquoi c’est problématique, comment fonctionne réellement la table des utilisateurs, et surtout comment personnaliser proprement le Lookup pour n’afficher que les vrai humains.

🎯 Problématique : un champ Lookup… trop bavard

Par défaut, un champ Lookup vers la table Utilisateur (systemuser) affiche tous les utilisateurs actifs. Cela comprend :

• Des utilisateurs sans licence CRM (donc inutilisables dans la pratique),

• Des comptes synchronisés automatiquement depuis Azure AD (#ADSync, #EXT#, etc.),

• Et parfois des comptes techniques utilisés pour l’intégration ou les flux d’automatisation.

Résultat :

• Le champ est difficile à lire.

• Le risque d’erreur (attribution à un mauvais compte) est réel.

• L’expérience utilisateur est dégradée.

🧠 Mieux comprendre la table systemuser

La table Utilisateur contient tous les utilisateurs ayant été créés dans ton environnement CRM.

Mais tous ne sont pas égaux. Voici les trois grandes familles d’utilisateurs que tu peux y retrouver :

1. 👤 Les utilisateurs métier avec licence CRM

Ils ont un rôle de sécurité, une licence Dynamics, et utilisent activement le CRM. Ce sont eux que tu veux voir dans le Lookup.

2. 🛠 Les comptes techniques (#ADSync, #EXT#, etc.)

Ils sont souvent créés automatiquement par une synchronisation Azure AD (AAD Connect).

Leur nom contient un #, parfois en préfixe.

Ils n'ont pas vocation à être sélectionnés par les utilisateurs.

3. 🧟 Les utilisateurs sans licence

Certains comptes n’ont pas (ou plus) de licence CRM.

Ceux sont tes anciens collègues partis de l’entreprise par exemple

Ils peuvent être actifs dans Azure AD mais n'ont aucun accès à Dynamics. Pourtant, ils s'affichent quand même dans le Lookup.

📋 Identifier les utilisateurs "licenciés"

Le champ clé ici s’appelle “Utilisateur avec Licence” . C’est lui qui te permet de filtrer proprement les utilisateurs CRM.

👉 Il suffit donc de filtrer sur “Utilisateur avec Licence “pour ne garder que les utilisateurs réellement actifs et licenciés.

🛠 Mise en œuvre

✅ 1.Ajouter la bonne vue dans la solution

Il existe d’innombrables vues dans le CRM

Celle pour la recherche d’utilisateur s’appelle…Vue Recherche d’utilisateurs 😊

✅ 2. Ajouter le bon filtre dans la vue

On ouvre la vue dans Power Apps > Edit Filter

Et on rajoute

• Utilisateur avec licence égal à Oui

✅ 3. On enregistre et on publie…

Ou Save and Publish, ça depend de la langue de ton Power Apps

💡 Pourquoi c’est important

👉 Afficher trop d’utilisateurs dans un Lookup, c’est exposer l’utilisateur à l’erreur.

✔️ En filtrant proprement :

• Tu améliores l’expérience utilisateur,

• Tu limites les erreurs d’attribution,

• Tu professionnalises l’usage du CRM.

✍️ Conclusion

Un bon CRM ne montre que ce qui est utile.

En filtrant tes champs Lookup, tu rends le CRM plus clair, plus propre, plus efficace.

Et ça, tes utilisateurs te le rendront.

🔍Le Lookup Polymorphique dans Dynamics 365 : un champ, plusieurs entités, un monde de possibilités

Dans Dynamics 365, les lookups sont partout.

Ces champs relationnels permettent de créer des liens entre des entités.

Par exemple, relier une opportunité à un compte, ou une tâche à un contact. Mais parfois, le modèle métier impose une souplesse supplémentaire.

Prenons un exemple classique : tu veux rattacher un enregistrement à un “client”, mais ce client peut être soit une société (Compte), soit une personne physique (Contact). Un simple lookup ne suffit plus, car il ne peut référencer qu’une seule entité.
C’est là qu’intervient le lookup polymorphique.

Un autre exemple ? Ton compte peut avoir comme propriétaire un utilisateur ou une équipe.

Qu’est-ce qu’un Lookup Polymorphique ?

Un lookup polymorphique est un champ de type relation N:1 vers plusieurs entités potentielles. Il permet de faire pointer un seul champ vers des entités de types différents.

🔁 Exemples concrets déjà présent dans Dynamics 365

• Le champ Customer dans une opportunité (opportunity.customerid) est un lookup polymorphique : il peut référencer soit un account (compte), soit un contact.

• Autre exemple : Regarding dans une activité (activity.regardingobjectid). Il peut référencer quasiment n’importe quelle entité (lead, case, account, etc.), selon le contexte de l’activité.

Exemple de cas d’usage métiers

1. Application RH : Signalement

Supposons que tu crées une application RH qui permette de signaler des problèmes.

Tu as donc une entité personnalisée “Signalement” : ce signalement peut concerner un produit, un projet ou un collaborateur.

Un lookup classique ne suffira pas.

Le polymorphisme te permet d’avoir un seul champ “ Object du signalement” qui s’adapte dynamiquement.

2. Comptes dans l’industrie

Dans certains cas dans l’industrie, ton compte est géré par un commercial.

Classique et logique. C’est lui ton propriétaire.

Et il arrive aussi que tu as un deuxième propriétaire. Qui lui peut être une administratrice des ventes, voir une équipe, ou un agent externe qui ne fait pas parti de tes utilisateurs !

Comment ça s’affiche dans Dynamics ?

Techniquement, un lookup polymorphique est un champ composite qui stocke :

• un GUID

• le type d’entité cible

{ "customerid": "a234f5fa-8912-4e5b-b3b0-dedf9d73d9c3", "_customerid_type": "contact" }

Dans Power Apps ou Dynamics, l’interface détecte dynamiquement le type pour afficher l’icône, le nom, et permettre les recherches.

Comment créer un lookup polymorphique ?

Prenons comme cas pratique un deuxième propriétaire sur un compte, référençant des utilisateurs et des agents externes

Donc comment créer ce Lookup Polymorphique ?

• Lance XrmToolBox, connecte-toi à ton environnement, et ouvre l’outil Polymorphic Lookup Creator.

• À gauche :

  • Choisis la solution dans laquelle tu veux créer le champ.

  • Choisis la table cible (ici : Compte) c’est à dire l’entité sur laquelle apparaîtra ce nouveau champ.

  • Indique le nom d’affichage et le nom de schéma du champ.

  • Coche les tables que tu veux pouvoir référencer (Utilisateur et Agent dans notre cas).

• À droite :

  • Tu peux consulter les détails de chaque relation générée (et les ajuster si besoin).

• Clique sur Create Polymorphic Lookup en haut à droite.

• ➡️ Et voilà ! Le champ sera visible dans ta solution, et tu pourras l’ajouter à un formulaire.

⚠️ Attention aux subtilités

Voici ce qu’il faut savoir pour éviter les mauvaises surprises :

1. 🧱 Le portail Power Apps est trompeur

Une fois le champ créé, le Maker Portal te montrera le lookup comme s’il était relié uniquement à la première table sélectionnée. Aucune mention du polymorphisme !

👉 Pense à bien documenter ces champs et à communiquer à ton équipe leur nature réelle.

2. 🧩 Risque d’échec lors de l’import de solution

Lors de la création, l’outil ajoute automatiquement les relations et les entités référencées dans ta solution.

Mais attention : si tu n’inclus pas la métadonnée de la table (en cochant “inclure métadonnées” lors de l’ajout à la solution), l’import échouera à cause de dépendances manquantes.

👉 Solution : retire et réintègre proprement les tables concernées avec métadonnées.

3. 🔄 Modification uniquement via XrmToolBox

Tu ne pourras pas modifier les entités référencées dans ce champ via le Maker Portal. Il faudra repasser par l’outil Polymorphic Lookup Creator :

• Ouvre le champ existant

• Ajoute/supprime les tables nécessaires

• Clique sur Apply Changes

🚨 Si tu supprimes une table déjà utilisée dans des données existantes, attention aux références cassées.

4. 🔁 Power Automate : pense au contrôle Switch

Dans Power Automate, tu devras utiliser un Switch sur la propriété _lookupname@Microsoft.Dynamics.CRM.lookuplogicalname pour distinguer les types d’entités avant d'accéder à leurs données.

Limite actuelle : 25 branches. Mais honnêtement… au-delà de 5 entités, c’est déjà difficilement maintenable.

5. 🚫 Pas d’auto-référence

Tu ne peux pas référencer la table d’origine dans le champ

Exemple : un Contact ne peut pas être lié à un autre Contact via un lookup polymorphique sur la table Contact 🤯🤯

Cela provoquerait un conflit logique : la table ne peut être à la fois référente et référencée.

6. 📭 Tables vides invisibles

Si une table référencée ne contient aucun enregistrement, elle n’apparaîtra pas comme option sélectionnable dans l’interface utilisateur (jusqu’à ce qu’elle ait des données).

Conclusion

Le lookup polymorphique dans Dynamics 365 est un excellent outil pour simplifier les modèles de données sans compromettre la flexibilité.

Il est déjà utilisé en standard dans des entités comme activitypointer, opportunity, ou email.

Mais comme toute bonne chose, il faut l’utiliser avec parcimonie : il introduit une complexité dans les requêtes, les flux Power Automate, et les rapports.

Mon conseil : utilise-le quand il simplifie l’expérience utilisateur ou évite une duplication de schéma.

Mais évite-le quand les entités référencées ont des comportements trop différents, ou quand tu prévois une forte utilisation analytique.