Salesforce et AWS EventBridge : Concevoir une architecture orientée événements en temps réel

Chaque entreprise en croissance finit par être confrontée au même goulot d'étranglement architectural : l'intégration en « toile d'araignée ». Tout commence assez simplement : un appel REST personnalisé de Salesforce vers un système de facturation externe à chaque fois qu'une opportunité est gagnée. Ensuite, une fonction AWS Lambda a besoin de savoir quand un Contact est mis à jour. Peu après, un ERP sur site requiert des mises à jour des stocks en temps réel.

Avant même que vous ne vous en rendiez compte, votre Org Salesforce se retrouve piégée dans une matrice d'appels HTTP Apex synchrones et de point à point.

En tant que Développeur/Architecte Salesforce, vous réalisez rapidement que cette approche est fondamentalement imparfaite. Elle introduit un couplage fort, augmente les temps de transaction, vous expose aux pannes des systèmes externes et consomme sans relâche vos Governor Limits.

Si vous voulez construire un écosystème d'entreprise vraiment résilient et scalable, vous devez passer d'une logique de requête-réponse à une architecture axée sur les événements (Event-Driven Architecture ou EDA). Et lorsqu'il s'agit de combler le fossé entre Salesforce et AWS, AWS EventBridge combiné aux Platform Events de Salesforce est la référence absolue.

Plongeons dans le fonctionnement de cette architecture et la manière de la concevoir correctement.

1. Pourquoi AWS EventBridge ? (Dépasser le REST traditionnel)

Dans un modèle d'intégration traditionnel, Salesforce agit comme l'orchestrateur, sollicitant directement les API externes. Si le microservice récepteur est indisponible, la transaction Salesforce échoue, ou vous devez bâtir une logique de rejeu (retry) complexe et personnalisée à l'aide d'Apex asynchrone ou de Scheduled Flows.

AWS EventBridge change complètement le paradigme en agissant comme un bus d'événements serverless. Au lieu que Salesforce sache qui a besoin des données, Salesforce crie simplement dans la pièce : « Hé, cet événement vient de se produire ! »

EventBridge écoute, filtre et achemine ce message vers le bon consommateur — qu'il s'agisse d'une fonction AWS Lambda, d'une file d'attente SQS, d'un flux Kinesis ou d'une API tierce externe.

Les bénéfices immédiats changent la donne :

• Découplage asynchrone : Salesforce déclenche l'événement et passe immédiatement à autre chose. L'interface utilisateur reste fluide et rapide car le CRM n'attend pas la réponse d'un serveur externe.

• Contournement des limites d'API : Les appels REST entrants traditionnels consomment vos limites quotidiennes d'API. Pousser les données via des événements passe plutôt par des allocations de streaming hautement scalables.

• Résilience par conception : Si un microservice de destination passe hors ligne, AWS EventBridge (ou les files d'attente SQS de type dead-letter associées) gère la logique de rejeu, pas Salesforce.

2. Le modèle natif : Event Relay pour AWS

Il y a quelques années, connecter Salesforce à AWS EventBridge nécessitait un middleware (comme MuleSoft) ou une fonction AWS Lambda personnalisée utilisant l'API Pub/Sub ou CometD pour interroger Salesforce afin de détecter les changements.

Aujourd'hui, nous disposons d'une solution native et low-code : Event Relay pour AWS.

Cette fonctionnalité native permet à Salesforce de diffuser des Platform Events ou des événements de capture de changement de données (Change Data Capture ou CDC) directement vers AWS EventBridge via un canal sécurisé et bidirectionnel géré en arrière-plan par Salesforce et AWS.

L'architecture du flux de données :

• L'événement déclencheur : Une action métier se produit dans Salesforce (par exemple, un nouveau Compte client est créé).

• Le Platform Event : Un trigger Apex, un Flow ou un CDC natif publie un Platform Event (par exemple, Cloud_Customer_Sync__e).

• L'Event Relay : Le service Event Relay natif récupère automatiquement l'événement publié sur le bus d'événements Salesforce et le transmet de manière sécurisée à AWS.

• La source d'événement partenaire (Partner Event Source) : AWS EventBridge reçoit le message via un canal dédié Partner Event Source.

• Les règles de routage : EventBridge évalue les règles configurées par votre équipe AWS et achemine le payload vers les microservices spécifiques qui s'intéressent aux données client.

3. Concevoir le payload de l'événement : Bonnes pratiques

Lors de la définition de vos Platform Events pour une intégration AWS, vous disposez de deux modèles de conception principaux : lourd en données (State Carrier) ou léger en données (Notification Only).

Option A : Lourd en données (State Carrier)

Le payload de l'événement contient toutes les données dont le système externe a besoin (par exemple, le nom du compte, l'ID, l'adresse, le numéro fiscal, les informations de facturation).

• Avantages : Les microservices externes peuvent traiter les données immédiatement sans avoir à réinterroger Salesforce.

• Inconvénients : Vous risquez d'atteindre la limite de taille du payload des Platform Events (généralement 1 Mo). Si des champs changent à l'avenir, vous devez modifier le schéma de l'événement.

Option B : Léger en données (Notification Only)

L'événement contient uniquement l'ID de l'enregistrement et le type d'action (par exemple, RecordId: 001xx00000XyZ, Action: UPDATE).

• Avantages : Léger, incroyablement rapide, et les schémas ne changent presque jamais.

• Inconvénients : Chaque microservice qui reçoit l'événement doit immédiatement faire un appel d'API REST entrant vers Salesforce pour récupérer les données dont il a besoin. Cela peut rapidement épuiser vos limites d'API entrantes si le volume d'événements est élevé.

Recommandation de l'Architecte : Visez une approche hybride. Incluez les identifiants immuables clés et les champs transactionnels essentiels dans le payload de l'événement afin de minimiser les boucles de rappel en aval (callback loops), mais évitez de placer des zones de texte entières ou des structures de relations massives dans un seul événement.

4. Les pièges du monde réel à anticiper

Le travail d'un architecte ne se limite pas à savoir comment construire un système ; il consiste aussi à savoir comment il va casser. Voici ce que vous devez concevoir dès le premier jour :

Ordre des événements

Dans un système distribué et orienté événements, ces derniers peuvent parfois arriver dans le désordre. Si un utilisateur met à jour le nom d'un Compte deux fois de suite rapidement, le Microservice A pourrait recevoir la deuxième mise à jour avant la première en raison du routage réseau.

• Solution : Incluez toujours un horodatage (timestamp) ou un indicateur de séquençage incrémentiel (comme l'heure de modification du système ou un ID de rejeu d'événement) dans votre payload pour que les systèmes externes puissent ignorer les données obsolètes.

Idempotence

Les micro-coupures réseau arrivent. Parfois, Salesforce peut envoyer un événement deux fois, ou AWS EventBridge peut le livrer deux fois à un microservice cible.

• Solution : Assurez-vous que vos microservices externes sont idempotents. Ils doivent vérifier l'UUID de l'événement entrant ou le couple ID d'enregistrement Salesforce + Timestamp avant le traitement pour s'assurer qu'ils n'exécutent pas une logique en doublon (comme la création d'une facture en double).

Verdict Final

Passer à une architecture orientée événements avec Salesforce et AWS EventBridge nécessite un changement dans votre façon de concevoir l'intégrité des données et les frontières du système. Cependant, la récompense est un écosystème moderne et incroyablement résilient, où Salesforce se concentre entièrement sur son rôle de CRM haute performance, tandis que vos microservices externes évoluent indépendamment dans le cloud.

Arrêtez de construire des ponts REST fragiles. Commencez à diffuser des événements.

Contact

Contactez-nous pour toute suggestion ou question technique.

Email

andre@theforcejournal.tech

© 2026. Tous droits réservés.