Architecture CRM
Architecture Salesforce et CRM qui supporte
votre organisation dans les deux prochaines années.
Planification complète de l'architecture — Solution, Données, Sécurité, Automatisation, Intégration et Environnement — pour que le système fonctionne aujourd'hui et puisse continuer à évoluer.
À qui ce service s'adresse-t-il ?
Quand est-il judicieux de faire appel à un architecte Salesforce ?
- Organisations planifiant une première implémentation de Salesforce.
- Systèmes existants ayant perdu leur ordre et leur architecture claire.
- Organisations planifiant des intégrations profondes avec l'ERP, la finance ou le BI.
- Équipes CRM souhaitant réduire la dette technique avant une nouvelle phase.
Problèmes résolus par le service
Les signes que le système a perdu son architecture
Champs accumulés sans modèle
Après deux ou trois ans, chaque service a ajouté ses propres champs. Résultat : des objets avec plus de 300 champs, des rapports non fiables et des automatisations défaillantes. L'architecture définit la propriété, les règles d'ajout et le cycle de vie de chaque champ.
Automatisations contradictoires
Flow, Process Builder et Trigger s'exécutant simultanément sur le même événement. Nous unifions en une seule couche d'automatisation avec un ordre d'exécution prévisible.
Permissions devenues une faille de sécurité
Profils ouverts 'temporairement' il y a deux ans et restés ouverts. Nous construisons un modèle basé sur les Permissions Sets et les rôles réels.
Intégrations sans propriétaire
Quand quelqu'un part, personne ne sait comment elles fonctionnent. L'architecture inclut la documentation, les journaux et une responsabilité claire pour chaque connexion.
Couches
Couches de l'architecture que nous concevrons
Solution Architecture
Alignement des processus métier clés de l'organisation avec les produits Salesforce, y compris la hiérarchisation de ce qui entre dans la première version et ce qui est pour les phases suivantes.
Data Architecture
Modèle d'objets et de relations, sources de données fiables, règles de qualité des données et plan de nettoyage et d'unification des enregistrements existants.
Security & Sharing
Profils, rôles, groupes publics, modèle de partage, champs protégés et politique d'accès aux informations sensibles.
Automation Architecture
Choix délibéré entre Flow, Apex et automatisations asynchrones, en évitant les automatisations parallèles sur le même événement.
Integration Architecture
Sens des flux, techniques (REST, Événements, Middleware), gestion des erreurs et journaux pour les intégrations métier critiques.
Environment & Release
Structure des Sandboxes, méthodologie de déploiement, sauvegardes, gestion des versions et opérations de maintenance continues.
Principes de travail
Principes guidant chaque décision
- Configuration avant le code — développement personnalisé uniquement s'il n'y a pas de moyen plus simple.
- Toute modification architecturale est documentée et approuvée.
- Un modèle d'autorisations simple et clair, même au prix d'une légère flexibilité.
- Il n'y a pas deux automatisations qui s'exécutent simultanément sur le même événement.
- Chaque intégration comprend un journal, une gestion des erreurs et une responsabilité claire.
- Un nouveau déploiement passe par Sandbox avant la production.
Environments
Structure d'environnement recommandée
Developer
Pour le développement quotidien, sans données réelles.
Integration / QA
Pour les tests système et les tests d'intégration entre les composants.
UAT
Une copie avec des données de type production pour les tests d'acceptation utilisateur.
Staging / Pre-Prod
Un environnement de répétition pour le passage en production (Go Live) et les corrections urgentes (Hotfix).
Production
L'environnement de production, avec un processus de déploiement ordonné uniquement.
Point de décision
Faire examiner votre architecture
Une brève conversation aide à comprendre si une nouvelle planification architecturale est nécessaire ou un Refactoring ponctuel des composants critiques.
Considérations pour la décision
Quatre décisions qui déterminent la stabilité du système
Multi-Org ou Single-Org
Quand une séparation en une organisation distincte est-elle préférable à une utilisation intelligente des Types d'enregistrements et du Partage? Une décision aux conséquences à long terme.
Master Data Management
Salesforce est-il la source de vérité pour les clients, ou la vérité est-elle dans l'ERP? La réponse détermine le sens du flux de chaque intégration.
Stratégie d'automatisation
Quand utiliser Flow, quand Apex, quand Platform Events. Un mauvais choix crée un système difficile à maintenir.
Politique des champs personnalisés
Qui est autorisé à ajouter un champ, et selon quel processus. Sans une telle politique, tout système se remplit de champs inutiles en un an.
Ce que vous obtiendrez
Livraisons de service possibles
Document d'architecture
Solution + Données + Sécurité + Intégrations, avec un niveau de détail permettant le développement.
Carte des intégrations
Sens de flux, technique, type d'événement et scénarios d'échec pour chaque connexion essentielle.
Modèle de données
Objets, relations, champs centraux et règles de qualité initiales.
Modèle d'autorisations
Profils, rôles et politique de partage adaptés à la structure organisationnelle.
Erreurs courantes
Tendances à éviter
- Permettre à chaque département d'avoir son propre modèle de données sans vision transversale de l'organisation.
- Développer des automatisations en Flow et en code simultanément pour le même événement.
- Déployer directement en Production sans passer par un Sandbox.
- Laisser des profils 'temporaires' avec 'All Modify Data' et ne pas y revenir.
- Développer une intégration ponctuelle sans la documenter — elle devient une boîte noire en quelques mois.
Guides et services associés
Explorer notre centre de connaissances
- Guide : Architecture CRM — Comment concevoir un système évolutif →
- Guide : Implémentation de Salesforce — Étapes, décisions et risques →
- Guide : Renseignements essentiels sur Salesforce Health Check : ce qu'il faut vérifier et quand le faire →
- Service : Conseil et conception Salesforce →
- Service : Intégrations et migration de données →
28. Questions fréquentes
Architecture CRM — Questions fréquentes
L'étape suivante