Étude de cas
Centre d'Excellence : 15 entités métier, une seule architecture
Architecture de gouvernance centralisée pour passer d'implémentations cloisonnées à une stratégie unifiée
Le problème
TotalEnergies exploitait quatre orgs Salesforce acquis indépendamment par les entités métier, avec des modèles de données contradictoires, aucun reporting au niveau groupe et aucun partage de connaissances. Le parc cumulait 400+ classes Apex, 1 200+ champs personnalisés et 200+ flows actifs avec des duplications significatives. Cinq autres entités arrivaient sous 18 mois, prêtes à reproduire la fragmentation à plus grande échelle.
Ce que j’ai fait
Un Centre d'Excellence a été conçu autour de trois piliers : gouvernance (Architecture Review Board, contrôle de version, revue par les pairs obligatoire), rationalisation d'architecture (bibliothèque de composants partagée, modèle Account canonique, gestion des données de référence) et montée en compétences (200+ consultants formés, parcours de certification interne). Cinq nouvelles entités intégrées dans le cadre sur 12 mois.
En un coup d'œil
- Client
- TotalEnergies
- Secteur
- Énergie
- Mission
- 12 mois
- Mon rôle
- Lead Solution Architect et Architecte du Centre d'Excellence
- Clouds Salesforce
- Sales Cloud · Service Cloud · Marketing Cloud · Experience Cloud
- Résultat
- 15 entités métier unifiées
Avant / Après
- Quatre orgs Salesforce acquis et maintenus indépendamment, aucun reporting au niveau groupe.
- 400+ classes Apex, 1 200+ champs personnalisés, 200+ flows avec duplications significatives.
- Deux orgs partageant 60 % de composants mais avec des bases de code séparées et divergentes.
- Modifications de configuration faites directement en production sur deux orgs ; un org non sauvegardé depuis 18 mois.
- 8M+ d'enregistrements modélisés de façon incohérente, aucune gestion des données de référence.
- 15 entités métier sous un cadre de gouvernance unique avec un diagramme d'architecture vivant.
- Bibliothèque Apex et composants LWC partagés ont supprimé environ 60 000 lignes de code dupliqué.
- Architecture multi-org avec métadonnées partagées déployées en packages gérés.
- Contrôle de version obligatoire, revue par les pairs, 80 % de couverture de tests, promotion Sandbox vers UAT vers Production.
- Modèle Account canonique, stratégie de gestion des données de référence sur les 8M+ d'enregistrements.
Situation
TotalEnergies avait adopté Salesforce dans plusieurs entités métier au cours des cinq dernières années. Les ventes d’énergie B2B en Europe fonctionnaient sur Sales Cloud. L’activité lubrifiants utilisait un org Salesforce séparé pour la gestion des distributeurs. Les énergies renouvelables avaient construit leur propre implémentation. Les services corporate en exploitaient encore une autre. Chaque entité métier avait acquis, construit et maintenu son implémentation Salesforce de manière indépendante, avec des contrats distincts, des administrateurs distincts et des décisions architecturales distinctes.
Le résultat : un patrimoine Salesforce composé de quatre orgs distincts, des modèles de données contradictoires, aucun partage de connaissances entre les équipes et aucune capacité de reporting au niveau du groupe sur les indicateurs Salesforce. Une question aussi simple que « combien d’utilisateurs Salesforce TotalEnergies compte-t-il au niveau mondial ? » ne pouvait trouver de réponse sans agréger manuellement les données de quatre systèmes distincts.
Le défi stratégique était amplifié par une expansion planifiée. TotalEnergies prévoyait d’intégrer cinq nouvelles entités métier à Salesforce au cours des 18 mois suivants. Sans intervention, l’architecture fragmentée se reproduirait à chaque ajout : davantage de silos, davantage de dette technique, davantage de failles de gouvernance. Les responsables d’entités n’avaient aucune visibilité sur ce que les autres avaient construit. Les équipes résolvaient les mêmes problèmes architecturaux indépendamment, facturant les mêmes travaux d’intégration à plusieurs reprises.
La direction a décidé de créer un Centre d’Excellence Salesforce pour gouverner le patrimoine existant, rationaliser là où c’était possible, et établir un cadre de gouvernance garantissant que les nouvelles implémentations seraient construites selon un standard commun.
Défi
Une évaluation technique des quatre orgs existants a révélé l’ampleur du problème. Les quatre implémentations avaient accumulé plus de 400 classes Apex actives, plus de 1 200 champs personnalisés et plus de 200 flows actifs, avec des duplications significatives entre les orgs. Deux orgs avaient été construits par le même intégrateur et partageaient 60 % de leurs composants techniques, tout en maintenant des bases de code séparées qui avaient divergé au cours de trois années de maintenance parallèle.
La gouvernance des données était absente. Aucune convention de nommage n’était appliquée, aucun standard de documentation au niveau des champs, aucune exigence de couverture de tests, et aucun processus de déploiement. Les modifications de configuration étaient effectuées directement en production dans deux des quatre orgs. Un org n’avait pas été sauvegardé depuis 18 mois.
Les 8M+ d’enregistrements clients et partenaires à travers le patrimoine étaient modélisés de manière incohérente. Un « distributeur » dans l’org lubrifiants était un Account ; dans l’org énergies renouvelables, c’était un objet personnalisé. Il n’existait aucune stratégie de gestion des données de référence, aucun processus de déduplication, et aucune source de vérité unique pour aucun type d’entité.
Pour la fondation de données nécessaire aux futurs déploiements d’Agentforce et Data Cloud, priorité déclarée dans la feuille de route Salesforce de TotalEnergies, cette architecture était inadaptée. Une automatisation intelligente inter-entités ne peut pas tourner sur quatre modèles de données fragmentés.
Ce que j'ai dit à la DSI lors de la restitution du diagnosticCinq autres entités arrivent dans 18 mois. Soit nous bâtissons le cadre maintenant et nous les intégrons à l’intérieur, soit nous serons encore en train de nettoyer dans trois ans.
Action
Le Centre d’Excellence a été conçu autour de trois piliers : gouvernance, rationalisation d’architecture et montée en compétences. Chaque pilier devait atterrir avant l’arrivée des cinq nouvelles entités, sans quoi le cadre serait un document, pas un contrôle.
Gouvernance
Architecture Review Board avec représentants IT, entités métier et CoE. Toute décision architecturale au-dessus d'un seuil de complexité défini exigeait la validation de l'ARB, avec une voie accélérée pour les demandes urgentes. Contrôle de version obligatoire (Salesforce CLI + Git), revue par les pairs pour Apex et Flow, 80 % de couverture de tests, promotion Sandbox vers UAT vers Production. Les deux orgs qui modifiaient en production directement ont été placés sous plan de remédiation.
Rationalisation d'architecture
Bibliothèque de composants partagée déployée en packages gérés : utilitaires Apex communs, LWC partagés, schémas d'intégration standardisés. Les deux orgs partageant 60 % de composants ont fusionné leur couche commune plutôt que les orgs eux-mêmes. Modèle Account canonique avec record types pour les besoins d'entités propres à chaque entité métier ; le nombre d'objets personnalisés a baissé de 40 %. Stratégie de gestion des données de référence appliquée aux 8M+ d'enregistrements.
Montée en compétences et intégration
Cinq nouvelles entités métier intégrées sur 12 mois. Chaque intégration suivait un processus structuré : évaluation architecturale des systèmes existants, mise en correspondance avec le modèle canonique, implémentation selon les standards définis, transfert aux administrateurs formés à la gouvernance du CoE. Parcours de certification interne pour les 200+ consultants à travers les partenaires intégrateurs.
Une documentation d’architecture a été créée pour chaque composant du patrimoine : dictionnaire de données, catalogue d’intégrations, registre de dette technique et diagramme d’architecture vivant mis à jour à chaque modification significative. Pour la première fois, TotalEnergies disposait d’une vue complète de son patrimoine Salesforce, portée par une fonction dotée de l’autorité de la maintenir à jour.
Résultat
TotalEnergies a consolidé 15 entités métier sous un cadre de gouvernance Salesforce unifié, avec pour la première fois 8M+ d’enregistrements gouvernés selon des standards de qualité de données cohérents. Le patrimoine fragmenté et maintenu indépendamment est devenu une plateforme gérée, documentée et suivie en continu.
L’efficacité du développement s’est améliorée significativement. Les composants partagés ont réduit la duplication : la bibliothèque Apex commune et les Lightning Web Components partagés ont supprimé environ 60 000 lignes de code dupliqué à travers le patrimoine. Les nouveaux projets d’implémentation pour les entités métier entrantes ont été déployés 40 % plus vite sur les modèles d’architecture standardisés par rapport aux constructions ad hoc.
La rationalisation d’architecture a également préparé le patrimoine à la couche suivante. Avec un modèle de données canonique, des processus de gouvernance cohérents et une fondation de données de référence propre, l’environnement Salesforce de TotalEnergies est positionné pour Data Cloud entre entités métier, ouvrant la voie à des analyses clients inter-entités, des données partenaires unifiées et un déploiement Agentforce sur une fondation capable de supporter l’IA à l’échelle de l’entreprise.
Le modèle de Centre d’Excellence est lui-même devenu une architecture de référence à l’intérieur du programme de transformation digitale plus large de TotalEnergies, avec le cadre de gouvernance et l’approche de montée en compétences appliqués à d’autres plateformes d’entreprise.
Recul
Ce motif fonctionne quand une organisation a trois entités métier ou plus sur la même plateforme Salesforce, quand la croissance est imminente et quand la direction accepte que le cadre doit atterrir avant la prochaine intégration. C’est le bon choix quand IA ou Data Cloud figurent à la feuille de route et que la fondation de données doit être pensée au niveau du groupe, pas par entité.
Cela fonctionne moins bien quand une seule entité métier est en production et qu’aucune expansion n’est prévue à court terme. Le cadre reste utile, mais le coût d’un ARB et d’une bibliothèque de composants partagée se justifie difficilement avant l’arrivée de la deuxième entité.
À faire plus tôt : le modèle Account canonique et le dictionnaire de données. Les deux sont peu coûteux à établir quand une ou deux entités sont en production, et de plus en plus coûteux à mesure que le parc grossit.
Technologies utilisées : Salesforce Sales Cloud (multi-org), Salesforce CLI, Git (contrôle de version), Managed Packages, Lightning Web Components, Apex, types de métadonnées personnalisées, pipeline de déploiement Salesforce DX
Glossaire
- Centre d'Excellence (CoE)
- Une fonction centrale qui fixe les standards d'architecture, gouverne les décisions entre plusieurs entités métier et fait monter en compétences consultants et administrateurs pour livrer à un niveau commun. Détient le dictionnaire de données, le catalogue d'intégrations et le registre de dette technique de la plateforme.
- Architecture Review Board (ARB)
- Une instance transverse de gouvernance avec représentants IT, entités métier et CoE. Revoit les décisions architecturales au-dessus d'un seuil de complexité défini. Détient l'autorité d'approuver, rejeter ou reporter les conceptions face aux standards canoniques.
- Bibliothèque de composants partagée
- Un référentiel versionné d'utilitaires Apex, de Lightning Web Components et de schémas d'intégration publié en packages gérés à tous les orgs consommateurs. Supprime la duplication de code et crée un point unique de mise à jour.
- Gestion des données de référence
- La stratégie qui garde cohérentes les entités partagées (Client, Compte, Partenaire, Produit) entre orgs et entités métier. Comprend règles de déduplication, responsables de données nommés et un modèle de scoring de qualité mesurant complétude, exactitude et fraîcheur.
Questions fréquentes
- Une fusion complète de quatre orgs divergents aurait représenté un risque et une perturbation élevés, d'autant plus avec cinq nouvelles entités à arriver dans 18 mois. L'architecture multi-org a maintenu les orgs séparés mais unifié les composants : utilitaires Apex partagés, Lightning Web Components partagés et schémas d'intégration standardisés, publiés dans un référentiel commun et déployés en packages gérés. Les orgs restent indépendants opérationnellement. L'architecture est gouvernée centralement.
- Deux choix de conception. Un seuil de complexité défini : seules les décisions architecturales au-delà d'un certain périmètre remontent à l'ARB. Les modifications de routine suivent le cycle de vie standard (contrôle de version, revue par les pairs, promotion de change sets) sans escalade. Et une voie de revue accélérée traite les demandes urgentes sous 48 heures. L'ARB n'approuve pas chaque flow ou chaque champ ; il gouverne l'architecture, pas la livraison quotidienne.
- Distributeur, client corporate, organisme public, client retail, compte wholesale B2B : chaque entité métier a des besoins légitimes mais différents. Le modèle canonique utilise les record types et les métadonnées personnalisées pour les configurations propres à chaque entité, posées sur un seul schéma Account partagé. Les champs communs sont gouvernés centralement ; les extensions propres à une entité restent avec l'entité. Cela a fait baisser le nombre d'objets personnalisés de 40 % à travers le parc.
- La plupart des consultants connaissaient Salesforce. Ce qu'ils ne connaissaient pas, c'étaient les standards TotalEnergies : modèle Account canonique, conventions de nommage, schémas d'intégration, processus de déploiement et procédure de soumission à l'ARB. Les procédures opérationnelles standard couvraient chaque pratique de travail, du nommage de champ au contrôle des modifications. Un parcours de certification interne garantissait que toute personne intervenant sur les orgs TotalEnergies pouvait démontrer sa conformité, quel que soit le partenaire intégrateur.
- Une IA à l'échelle de l'entreprise ne peut pas tourner sur quatre modèles de données fragmentés. Le modèle Account canonique, la stratégie de gestion des données de référence, les processus de gouvernance cohérents et le modèle de scoring de qualité créent ensemble la fondation dont Data Cloud a besoin pour ingérer entre entités. Les déploiements Agentforce en aval peuvent alors référencer des dossiers clients et partenaires unifiés, avec la même gouvernance que le reste du parc.
Réserver l'appel
On saura en 30 minutes
si je peux vous aider.
Pas de slides. Pas de pitch deck. Apportez le diagramme d'architecture ou décrivez le problème avec vos mots. Je vous dirai si je suis le bon profil et combien coûte la prochaine étape — avant que vous ayez fini votre café.
- Réponses sous 24 heures, toujours
- Si je ne suis pas le bon profil, je vous oriente vers quelqu'un qui l'est
- Aucune relance par email sauf si vous le demandez