CRM sur mesure multisite : droits et clients partagés

Une fiche client commune peut contenir son identité et les coordonnées professionnelles nécessaires. Une relation locale indique la succursale qui le suit. Un dossier commercial porte une proposition, des notes et ses responsables. Si ces objets sont confondus, changer la succursale du client peut déplacer tout son historique ou rendre invisibles des dossiers encore actifs. Décidez de ces effets avant de dessiner le tableau de bord.

Un CRM et ERP sur mesure permet de représenter ces responsabilités selon vos opérations. Écrivez séparément le droit de consulter, de modifier, d’approuver et d’exporter. La personne responsable d’un dossier n’a pas forcément le droit d’approuver sa propre remise. Le siège peut avoir besoin d’indicateurs consolidés sans avoir accès à chaque note locale. Chaque permission doit correspondre à une tâche définie.

Cette grille est une proposition de conception, pas une règle universelle. Confirmez les exceptions avec les équipes. La documentation Dataverse décrit des mécanismes d’unités commerciales, de rôles et d’équipes; elle montre que plusieurs dimensions peuvent intervenir dans les droits. Un développement personnalisé doit implémenter et vérifier ses propres règles. Reprendre les noms d’un produit ne reproduit pas automatiquement son modèle de sécurité.

Prenons un scénario fictif : Léa quitte la succursale de Laval pour celle de Québec. Elle conserve deux dossiers en cours à Laval pendant une période de transition décidée par l’entreprise. Ses nouveaux dossiers appartiennent à Québec. Une règle fondée uniquement sur sa succursale actuelle lui retirerait trop tôt certains accès; une règle conservant tous les accès historiques laisserait une exposition inutile.

L’équipe choisit donc, dans cet exemple, une attribution temporaire sur les deux dossiers. Le directeur de Laval reste responsable de leur suivi. Une personne désignée reçoit la tâche de retirer le partage à la fin du transfert. Ce fonctionnement est hypothétique et ne décrit pas un client Daillac. L’entreprise doit choisir la durée et les conditions selon son organisation, sans laisser un accès temporaire sans date de réexamen.

Testez aussi les effets moins visibles : recherches, pièces jointes, notifications, exports et liens enregistrés. Une fiche refusée à l’écran ne doit pas rester disponible par une nouvelle demande d’export ou un ancien lien de téléchargement encore servi par l’application. Le retrait des droits ne supprime pas une copie déjà téléchargée. Les contrôles d’accès doivent s’appliquer côté serveur aux objets concernés. La fiche OWASP sur l’autorisation recommande notamment le refus par défaut et la vérification des permissions sur chaque requête; l’interface seule ne suffit pas à établir le droit.

Dans un second cas fictif, Laval et Québec créent chacun une fiche pour la même entreprise. Les deux dossiers commerciaux restent légitimes. La fusion de l’identité client doit préserver leur provenance, leurs propriétaires et leurs historiques. Évitez de traiter la fusion comme un simple remplacement d’identifiant. Une erreur peut rattacher une proposition confidentielle à un périmètre plus large que prévu.

Prévoyez une proposition de rapprochement, un examen par une personne autorisée et un aperçu des conséquences avant confirmation. Conservez l’identifiant des anciennes fiches dans la trace de fusion. Les coordonnées en conflit demandent une décision explicite : quelle valeur sera conservée et quelle preuve justifie ce choix? L’entreprise doit pouvoir comprendre la décision après le départ de la personne qui l’a prise.

Pour les modifications simultanées, définissez un comportement visible. Une mise à jour peut être refusée si une autre version a déjà été enregistrée; l’utilisateur relit alors le changement avant de recommencer. Le développeur choisira le mécanisme approprié, mais le métier doit décider si une écriture peut remplacer silencieusement une autre. Une application web sur mesure doit présenter cette règle de façon compréhensible aux équipes.

Notez pour chaque scénario les comptes utilisés, l’état initial et le résultat observé. Incluez les chemins secondaires : accès par URL directe, recherche globale et fichiers attachés. Répétez les cas touchés lorsqu’un rôle ou une intégration change. Les exemples ci-dessus constituent une grille de départ; aucun test n’a été exécuté pour cet article.

Une automatisation CRM et ERP agit souvent avec un compte de service. Attribuez-lui le périmètre nécessaire et consignez le dossier visé ainsi que l’origine de la demande. Un traitement de synchronisation ne devrait pas transformer un partage local en accès généralisé. Vérifiez la réaction à une suppression de droit pendant qu’une tâche attend dans une file.

Confiez la matrice à un responsable métier et faites valider les changements d’organisation avant leur mise en service. Conservez un registre des exceptions avec leur motif et leur réexamen. La réussite du projet se vérifie dans des situations concrètes : chacun termine son travail, les refus attendus tiennent et les décisions restent explicables lorsqu’un dossier traverse plusieurs succursales.