Dataverse : cinq erreurs de conception qui coûtent cher

Sur un projet Dataverse, les décisions les plus coûteuses sont prises dans les deux premières semaines, par quelqu’un qui n’a pas encore vu les données réelles. Elles sont bon marché à corriger le premier mois, et pratiquement impossibles à défaire après le go-live.

Voici les cinq que je rencontre le plus souvent.

1. Créer une entité personnalisée là où une entité standard suffisait

Le réflexe est compréhensible : l’entité Account standard porte 80 champs dont on n’utilise que 12, alors on crée new_client, propre et minimal.

Ce que ça coûte :

• Vous perdez les fonctionnalités natives : hiérarchies, fusion de doublons, relations standard vers les opportunités et les cas.
• Les connecteurs, les modèles Power BI et la documentation Microsoft supposent tous les entités standard.
• Chaque nouveau développeur doit apprendre votre modèle au lieu de celui qu’il connaît déjà.

Les 68 champs inutilisés ne coûtent rien : masquez-les sur le formulaire. Créez une entité personnalisée quand le concept métier n’existe pas dans le modèle standard — pas quand il existe mais vous déplaît.

2. Utiliser un champ texte au lieu d’un choix

new_statut en texte libre, parce que « la liste va changer souvent ».

Six mois plus tard, votre base contient Validé, validé, Valide, VALIDÉ (avec l’espace) et Valdié. Chaque rapport a une clause WHERE différente. Chaque flux Power Automate a raté au moins une variante.

Un choix (optionset) coûte cinq minutes à ajouter. Le nettoyage d’une colonne texte polluée coûte des jours — et il n’est jamais complet, parce que quelqu’un continue à taper à côté pendant que vous nettoyez.

Le contre-argument « la liste change souvent » ne tient pas : modifier un choix est une opération de configuration, pas de développement.

3. Confondre les rôles de sécurité et la visibilité des formulaires

« Cet utilisateur ne doit pas voir le champ Salaire » → on masque le champ sur le formulaire.

Le champ reste accessible via la vue avancée, l’export Excel, l’API Web, un rapport, ou une Canvas App. Masquer un champ sur un formulaire n’est pas de la sécurité. C’est de la mise en page.

La sécurité au niveau du champ (field-level security) existe pour ça. Elle est plus lourde à mettre en place, et c’est précisément ce qui la rend efficace : elle s’applique partout, quelle que soit la porte d’entrée.

Si la donnée est réellement sensible — RH, santé, données financières — ce n’est pas un détail de mise en page. En Belgique, c’est aussi une question RGPD.

4. Modéliser une relation N:N là où il fallait une entité intermédiaire

Une relation N:N native est séduisante : deux clics, pas de table à gérer.

Mais elle ne peut porter aucun attribut. Le jour — et ce jour arrive toujours — où le métier demande « depuis quand ce contact est-il lié à ce projet ? » ou « quel est son rôle sur ce projet ? », la relation native ne peut pas répondre.

Migrer une N:N vers une entité intermédiaire après coup implique de recréer les données, réécrire les vues, les flux et les rapports. En amont, c’est une entité de plus dans le modèle.

Ma règle : dès qu’une association a la moindre chance de porter une date, un rôle, un statut ou un commentaire, créez l’entité intermédiaire tout de suite.

5. Ne pas séparer les environnements dès le premier jour

« On est trois, on développera directement en production, on séparera plus tard. »

Plus tard n’arrive jamais. Ce qui arrive :

• Une solution non managée en production, impossible à désinstaller proprement
• Aucune trace de qui a modifié quoi, ni pourquoi
• Un correctif urgent qui casse une démo en cours
• Des données de test mélangées aux données réelles, que personne n’ose supprimer

Dev → Test → Prod, avec des solutions managées en Test et Prod, coûte une demi-journée à mettre en place au démarrage. Rétablir cette séparation sur un environnement pollué prend des semaines, et se fait toujours au pire moment.

Le point commun

Ces cinq erreurs partagent la même structure : une économie visible aujourd’hui contre un coût invisible demain. Le champ texte est plus rapide à créer. La production directe évite de configurer un pipeline. L’entité personnalisée est plus propre à regarder.

La question à poser en modélisation n’est pas « qu’est-ce qui est le plus rapide maintenant ? » mais « qu’est-ce qui sera le plus difficile à changer plus tard ? ». Ce qui est difficile à changer — le modèle de données, la sécurité, la topologie des environnements — mérite le temps qu’on y passe. Le reste peut être refait.