Comment concevoir une architecture ETRM moderne

On discute souvent d'« architecture ETRM moderne » comme s'il s'agissait de choisir la bonne plateforme unique. D'après notre expérience, le choix de la plateforme compte moins que la qualité de conception de l'ensemble des briques qui l'entourent - données, intégration, analytique - et de leur façon de fonctionner ensemble. Un environnement bien architecturé autour d'une plateforme centrale plus ancienne surpassera généralement une plateforme moderne greffée sur un paysage de données fragmenté.

Partir du cycle de vie complet, pas seulement de l'ETRM

L'ETRM lui-même couvre généralement de la saisie des deals jusqu'au P&L. Mais une architecture complète doit tenir compte de ce qui se passe avant (les données pré-trade) et autour (logistique, règlement, reporting) - et, de plus en plus, d'une couche analytique distincte qui consomme les données de l'ETRM sans dépendre de ses propres outils de reporting.

Principe 1 : séparer les charges transactionnelles et analytiques

Les plateformes ETRM sont optimisées pour l'intégrité transactionnelle - saisir et traiter correctement les deals - non pour l'interrogation analytique ad hoc sur des années d'historique. Vouloir forcer les deux charges sur le même système produit généralement une plateforme médiocre sur les deux plans. Une plateforme de données cloud distincte (voir notre service Data engineering ETRM) pour l'analytique, alimentée par une extraction planifiée depuis l'ETRM, résout ce point sans perturber la production.

Principe 2 : construire une vraie couche de données pré-trade

Comme évoqué dans Les données pré-trade : la couche manquante, les données de marché et de référence doivent être validées et normalisées avant d'atteindre l'ETRM, et non après. Cette seule décision évite une large part des problèmes de P&L et de risque d'origine qualité des données qui seraient sinon découverts en aval.

Principe 3 : concevoir l'intégration comme un modèle, pas comme une série de cas particuliers

Chaque nouvelle connexion - vers l'ERP, la comptabilité, le risque, la BI - est plus simple et plus fiable lorsqu'elle suit un modèle d'intégration cohérent (API en priorité lorsque c'est possible, repli fichier clairement défini sinon) plutôt que d'être développée comme un script spécifique à chaque fois. Cela rend aussi les nouvelles intégrations nettement plus rapides à construire une fois le modèle établi.

Principe 4 : rendre la qualité des données et les rapprochements visibles, non silencieux

La logique de repli, la gestion des données périmées et les contrôles de rapprochement doivent être visibles pour celles et ceux qui s'appuient sur les chiffres, et non enfouis dans un paramétrage dont plus personne ne se souvient. Un tableau de bord montrant la santé du pipeline et les données signalées représente un investissement modeste au regard du coût d'une défaillance silencieuse atteignant un rapport de P&L ou de risque.

Principe 5 : concevoir pour la plateforme que vous exploiterez réellement, pas pour celle de la démonstration

Les décisions d'architecture doivent tenir compte de la capacité réelle de vos équipes à maintenir et à faire évoluer le système - son langage de script, son modèle de personnalisation, sa complexité d'exploitation - et pas seulement de ses capacités théoriques. L'architecture la plus sophistiquée ne vaut que par la capacité de l'équipe à la faire tourner.