La réponse courte
Une architecture Salesforce de qualité ne se mesure pas au nombre de composants développés, mais à la capacité de l'organisation à intégrer une nouvelle activité, un nouveau produit ou un nouveau marché sans démanteler ce qui fonctionne déjà. Le problème le plus courant que nous rencontrons n'est pas un mauvais choix technologique, mais l'absence d'une couche décisionnelle documentée : qui est le propriétaire de chaque objet, pourquoi Flow a été choisi plutôt qu'Apex, et pourquoi existe-t-il cinq intégrations distinctes au lieu d'une couche Middleware unique.
Cet article décompose l'architecture en six couches qui doivent être conçues ensemble et non isolément : modèle de données et d'objets, partage et autorisations, automatisation, intégrations, stratégie d'Org et DevOps avec Scalabilité. Un historique détaillé sur la gestion des erreurs d'intégration est disponible dans Surveillance des intégrations Salesforce.
Modèle de données et d'objets : la fondation sur laquelle tout repose
Une erreur récurrente dans de nombreuses organisations : la création d'un Custom Object pour chaque nouvelle exigence métier, sans vérifier s'il est possible d'utiliser un champ supplémentaire sur un objet existant ou un Record Type. Le résultat, après deux ou trois ans, est une Org avec 80 à 120 objets personnalisés, certains ayant une signification redondante, et sans aucune documentation expliquant leur création.
Le principe directeur est de se poser les questions suivantes avant de créer un objet : qui est le propriétaire métier, quelle est la source de vérité (Salesforce ou un système externe), et que se passe-t-il lorsqu'un enregistrement est supprimé ou dupliqué. Les entreprises qui gèrent un catalogue de produits complexe, par exemple, ont tendance à créer un Object distinct pour chaque catégorie au lieu d'utiliser les Record Types sur Product2, ce qui génère une charge de maintenance inutile à chaque mise à niveau.
Tableau utile pour évaluer la maturité du modèle de données :
| Composant | Question de vérification | Signal d'alerte |
|---|---|---|
| Objets personnalisés | Existe-t-il un objet similaire qui pourrait être étendu ? | Deux objets ayant sensiblement les mêmes champs |
| Champs | Le champ est-il utilisé pour plus d'un processus ? | Plus de 800 champs sur un objet central |
| Relations | Master-Detail ou Lookup a-t-il été choisi délibérément ? | Master-Detail choisi "par défaut" |
| External ID | Chaque objet synchronisé possède-t-il une clé unique ? | Synchronisation basée uniquement sur le nom ou la date |
Partage et autorisations : la couche qui se brise silencieusement
Un modèle d'autorisations laxiste ne se révèle pas immédiatement ; il se manifeste lorsqu'une personne voit des données qu'elle ne devrait pas voir, ou lorsqu'un rapport de direction affiche moins de lignes que prévu parce qu'une Sharing Rule bloque l'accès. Le choix entre Role Hierarchy, Organization-Wide Defaults, Sharing Rules et Permission Sets doit découler de la structure organisationnelle réelle, et non de l'organigramme hiérarchique officiel.
Un anti-pattern fréquent : l'attribution de "View All" ou "Modify All" au niveau du profil pour "résoudre" un problème d'autorisation sous la pression du temps, sans revenir par la suite pour restreindre l'accès. Cela fonctionne à court terme et crée une exposition étendue des informations à long terme, en particulier dans les secteurs réglementés comme la finance ou la santé. Les Permission Set Groups permettent de construire des autorisations modulaires qui peuvent être ajoutées et supprimées sans modifier le profil de base, ce qui est l'approche la plus sûre pour une organisation en croissance.
Les Criteria-Based Sharing Rules sur des objets contenant des millions d'enregistrements nécessitent un test de charge avant la mise en production. Il arrive qu'une règle de partage apparemment anodine entraîne un recalcul de plusieurs heures, bloquant les processus nocturnes.
Automatisation : Flow versus Apex
La question "Flow ou Apex" n'est pas une question de préférence, mais de complexité, de volume et de durée de vie. Flow est plus lisible pour une équipe opérationnelle, est développé et maintenu rapidement, et convient à une logique métier évolutive. Apex est nécessaire pour le traitement en masse de milliers d'enregistrements en une seule transaction, pour un contrôle précis de l'ordre d'exécution par rapport à d'autres Triggers, ou lorsque des tests automatisés (Test Coverage) sont requis pour des raisons de réglementation ou de gestion formelle des changements.
Un anti-pattern courant dans les organisations en croissance : des chaînes de Flow qui s'appellent mutuellement (un Flow qui déclenche un Flow qui déclenche un Flow), sans carte centrale montrant l'ordre d'exécution. Lorsque quelque chose se brise, personne ne sait quel Flow a été exécuté en premier. Exemple concret : une organisation avec 14 Flows actifs sur Opportunity, dont trois avec la même logique de mise à jour de statut, écrits à différentes époques par différentes personnes sans vérifier ce qui existait déjà.
Règle pratique : si une logique métier comporte plus de 5 à 6 conditions complexes ou si un appel externe est requis à l'intérieur d'une boucle, Apex est préférable. Au-delà de cela, Flow est préférable car il est accessible à la maintenance même lorsque le développeur initial n'est plus dans l'entreprise.
Intégrations : du Point-to-Point à une couche gérée
Une organisation qui se connecte initialement à deux systèmes externes (ERP et système de paiement, par exemple) les intègre généralement en Point-to-Point, ce qui est acceptable à ce stade. Le problème survient lorsque de troisième, quatrième et cinquième connexions s'ajoutent, chacune avec sa propre logique de réessai, de gestion des erreurs et de mappage des champs, sans norme commune. À ce stade, toute modification du système source rompt une ou plusieurs connexions sans que personne ne le sache à l'avance.
La transition vers une couche Middleware (MuleSoft, ou une couche d'intégration personnalisée) ne doit pas être un projet gigantesque ; il est possible de commencer par la connexion la plus fragile ou la plus coûteuse à maintenir et de procéder progressivement. Principes à adopter pour toute nouvelle intégration : Idempotence (un appel en double ne crée pas d'enregistrement en double), External ID pour une identification certaine, et un journal permettant de reconstituer précisément ce qui s'est passé lors de chaque appel. Des informations complémentaires sur les modèles d'intégration sont disponibles dans Connexion de Salesforce à un ERP et Modèles d'intégration Salesforce.
Stratégie d'Org : Single Org, Multi-Org ou Segmentation par Unités Commerciales
C'est l'une des décisions les plus coûteuses à modifier a posteriori. Un Single Org avec segmentation par unités commerciales (utilisation de Record Types, Sharing et Permission Sets pour la séparation logique) convient à la plupart des organisations, car il maintient une source de vérité unique et des indicateurs de rapport consolidés. Le Multi-Org est approprié lorsque les unités commerciales nécessitent des modèles d'autorisation fondamentalement contradictoires, lorsqu'une fusion ou une acquisition apporte un Org existant, ou lorsque la charge d'autorisations réelle nuit aux performances.
Le passage d'un modèle à l'autre après que l'organisation est déjà établie est un projet lourd : fusion de données, réaffectation des autorisations et parfois perte d'historique. Une description complète des considérations décisionnelles est disponible dans Salesforce Multi Org.
DevOps et Scalabilité : comment maintenir la capacité de changement
Une organisation qui développe directement en Production, sans Sandbox organisé et sans outils CI/CD (tels que Copado, Gearset ou SFDX), se retrouve rapidement dans une situation où toute modification est risquée. Un processus DevOps correct inclut au minimum un Sandbox de développement, un Sandbox de test, un contrôle de version pour les métadonnées, et un processus de déploiement automatisé avec des tests de régression.
Tableau des décisions architecturales clés et leurs implications à long terme :
| Décision | Avantage immédiat | Implication dans 2-3 ans |
|---|---|---|
| Custom Object pour chaque exigence | Solution rapide pour un besoin ponctuel | Org avec des dizaines d'objets dupliqués, difficile à maintenir |
| Autorisations "View All" temporaires | Résout une erreur en quelques minutes | Exposition étendue des informations, difficile à détecter et à corriger |
| Flow appelant Flow | Développement rapide sans code | Chaînes difficiles à suivre et à tester |
| Intégration Point-to-Point supplémentaire | Connexion rapide entre deux systèmes | Réseau de connexions où toute modification en casse une autre |
| Développement direct en Production | Gagne du temps dans la mise en place du processus | Risque élevé pour toute modification, difficulté de restauration |
| Single Org sans séparation logique | Rapports consolidés dès le premier jour | Difficulté à ajouter une unité commerciale avec des besoins différents |
Scénario organisationnel d'exemple
Une entreprise de distribution avec trois unités commerciales a fonctionné pendant quatre ans sur un unique Org, chaque unité ajoutant ses propres objets, Flows et intégrations selon les besoins immédiats. Lorsque la direction a décidé d'ajouter une quatrième unité, il est apparu qu'aucun document n'expliquait qui était le propriétaire de chaque objet, et que trois intégrations différentes synchronisaient les clients vers le système financier avec des logiques contradictoires.
L'équipe architecturale a procédé à une cartographie complète : elle a identifié 23 objets sans propriétaire clair, six chaînes de Flow chevauchantes et deux intégrations qui créaient des enregistrements doublons en raison de l'absence d'un External ID cohérent. La solution n'a pas été une reconstruction, mais une documentation progressive, l'unification de la logique de partage sous des Permission Set Groups, et la transition des intégrations critiques vers une unique couche Middleware. En deux trimestres, le temps nécessaire pour ajouter une nouvelle unité commerciale est passé de plusieurs mois à environ six semaines.
Anti-patterns courants dans les organisations en croissance
- Custom Object pour chaque demande : création d'un nouvel objet sans vérifier si un similaire existe déjà.
- Autorisations larges "temporaires" : accordées sous la pression et jamais réellement restreintes par la suite.
- Flow-in-Flow sans cartographie : chaînes d'automatisation sans diagramme d'exécution central.
- Point-to-Point sans Gouvernance : chaque nouvelle connexion est construite séparément sans norme commune.
- Développement en Production : modifications directes sans Sandbox, tests ou contrôle de version.
- Absence d'External ID : synchronisation par nom ou e-mail créant des enregistrements dupliqués.
Liste de contrôle pour l'évaluation de la maturité architecturale
- ☐ Chaque objet personnalisé a un propriétaire métier documenté.
- ☐ Le modèle de Sharing a été testé sous une charge de données réelle.
- ☐ Une carte centrale de toutes les chaînes d'automation existe.
- ☐ Chaque intégration possède un External ID, une logique de Retry et un journal d'erreurs.
- ☐ Un processus Sandbox-to-Production ordonné avec des tests de régression est en place.
- ☐ La décision entre Single Org et Multi-Org a été prise explicitement et justifiée par écrit.
- ☐ Les Governor Limits sont vérifiés par rapport aux prévisions de croissance sur trois ans.
Lorsque l'architecture Salesforce nécessite un accompagnement professionnel plutôt qu'un cadre de travail autonome, c'est le domaine des services d'architecture CRM.
Sources professionnelles
- Modèles d'intégration Salesforce — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Guide de décision pour l'intégration de données Salesforce — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – Architecture CRM — https://hpi.pro/crm-architecture
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data