Salesforce intégrations temps réel : Platform Events vs Outbound Messages vs Webhooks

Quand une organisation veut que Salesforce notifie un système externe en temps réel, ERP, MDM, outil marketing, plateforme logistique, trois patterns natifs s'offrent à elle : Platform Events, Outbound Messages et les Webhooks custom via Apex. Choisir le mauvais pattern génère des architectures fragiles, des pertes de données ou des maintenances coûteuses. Voici comment choisir.

Les 3 patterns en bref

Platform Events : le pattern moderne

Les Platform Events sont le mécanisme d'intégration événementielle natif de Salesforce, introduit dans la Spring '17. Ils s'appuient sur un bus de messages (CometD / Bayeux protocol) qui permet de découpler Salesforce du système consommateur.

Comment ça fonctionne

• On définit un objet Platform Event (comme un objet Salesforce custom, avec des champs)
• Salesforce publie un événement via Apex (EventBus.publish()) ou via un Flow
• Les abonnés, systèmes externes, autres orgs Salesforce, Apex triggers, consomment les événements en s'abonnant au channel /event/MonEvenement__e
• Les événements sont conservés 72 heures dans le bus, si le consommateur est temporairement indisponible, il peut reprendre là où il s'était arrêté

Points forts

• Découplage total, Salesforce ne sait pas qui consomme l'événement, ni si quelqu'un le consomme. Pas de dépendance à la disponibilité du système cible.
• Rétention 72h et replay, les consommateurs peuvent rejouer les événements manqués via un ReplayId
• Compatible avec les governor limits, la publication d'un Platform Event ne compte pas comme un DML dans les limits Apex
• Multi-consommateurs, plusieurs systèmes peuvent s'abonner au même événement

Limites

• Le consommateur doit maintenir une connexion CometD active ou être un système compatible (MuleSoft, Heroku, ESB…)
• Pas de garantie d'ordre des événements dans tous les cas
• Allocation d'événements mensuelle selon la licence (250 000 à plusieurs millions selon l'édition)

Outbound Messages : le pattern legacy

Les Outbound Messages existent depuis les débuts de Salesforce. Ils sont configurés via les Workflow Rules (désormais dépréciées) ou les Process Builders (également dépréciés) et envoient un message SOAP à un endpoint externe quand un enregistrement répond à des critères.

Comment ça fonctionne

• Configuration déclarative dans les Workflow Rules : "quand l'opportunité passe à Fermée Gagnée, envoyer un Outbound Message"
• Salesforce envoie automatiquement un payload SOAP avec les champs configurés vers l'endpoint
• L'endpoint doit répondre avec un Ack (accusé de réception), sinon Salesforce effectue des retry pendant 24h

Points forts

• Zéro code, configuration 100% déclarative
• Retry natif, Salesforce gère les retry automatiquement jusqu'à 24h
• Garantie de livraison, avec l'Ack, on sait que le message a bien été reçu

Limites

• Dépendant des Workflow Rules, ces dernières sont dépréciées par Salesforce. Il est déconseillé de créer de nouveaux Outbound Messages aujourd'hui.
• SOAP uniquement, peu de systèmes modernes exposent des endpoints SOAP natifs
• Payload limité, seuls les champs configurés sont envoyés, pas de logique dynamique
• Un seul endpoint par message, pas de multi-consommateurs natif

Webhooks via Apex Callout : le pattern custom

Quand ni les Platform Events ni les Outbound Messages ne conviennent, on peut réaliser un appel HTTP direct depuis Apex vers un endpoint externe, c'est ce qu'on appelle communément un "webhook Salesforce", même si Salesforce n'a pas de mécanisme webhook natif au sens strict.

Comment ça fonctionne

• Un trigger Apex, un Flow ou une action invocable appelle une méthode Apex marquée @future(callout=true) ou implémentant Queueable
• La méthode effectue un appel HTTP REST vers l'endpoint externe avec le payload souhaité
• Le endpoint répond, Salesforce reçoit la réponse mais ne la traite que si le code le prévoit

Points forts

• Flexibilité totale, payload custom, headers personnalisés, authentification OAuth, logique métier dans le payload
• Compatible REST, s'intègre avec n'importe quel endpoint HTTP moderne
• Réponse exploitable, le code peut lire la réponse et agir en conséquence (mettre à jour un champ, loguer une erreur…)

Limites

• Aucune garantie de livraison native, si l'endpoint est indisponible, le message est perdu sauf si on implémente sa propre gestion de retry
• Callout impossible dans un trigger synchrone, il faut passer par @future ou Queueable, ce qui introduit de l'asynchronisme
• Governor limits callouts, 100 callouts maximum par transaction
• Complexité de maintenance, authentification, gestion d'erreurs, retry, logs, tout est à coder

Comparatif synthétique

Comment choisir

Choisir Platform Events si…

• Vous avez un ESB, un middleware (MuleSoft, Azure Service Bus, Kafka) ou une plateforme capable de s'abonner à un channel CometD
• Plusieurs systèmes doivent consommer le même événement
• La rétention des événements et le replay sont importants pour votre cas d'usage
• Vous voulez un découplage propre entre Salesforce et les systèmes cibles

Choisir Apex Callout si…

• Le système cible expose un endpoint REST et ne peut pas s'abonner à un bus de messages
• Vous avez besoin d'une réponse synchrone exploitable (récupérer un ID externe, vérifier une disponibilité…)
• Le payload doit être construit dynamiquement avec une logique métier complexe

Ne pas choisir Outbound Messages pour du nouveau développement

Simple. Les Workflow Rules sont dépréciées, SOAP est vieillissant, et les Platform Events couvrent tous les cas d'usage des Outbound Messages avec plus de flexibilité.

Conclusion

En 2026, Platform Events est le pattern à privilégier pour les nouvelles intégrations événementielles Salesforce. Il offre découplage, rétention et multi-consommateurs, sans les compromis des Outbound Messages ou la complexité des Apex Callouts. Réservez les callouts Apex aux cas où vous avez besoin d'une réponse synchrone exploitable ou d'un payload très custom que les Platform Events ne permettent pas d'exprimer simplement.