Événements de plate-forme Salesforce : fin du volume standard

Si votre org Salesforce utilise encore des événements de plate-forme créés avant 2019, une échéance ferme approche. La fin des événements de plate-forme Salesforce à volume standard prend effet le 15 décembre 2026. À partir de cette date, Salesforce indique que les utilisateurs ne peuvent plus publier ni s'abonner à ces événements : tout flow, déclencheur Apex ou intégration externe qui en dépend cessera tout simplement de recevoir des messages. Ce guide explique ce qui change, comment savoir si vous êtes concerné et comment migrer sereinement avant l'échéance.

Ce que change la fin des événements de plate-forme à volume standard

Les événements de plate-forme sont la couche de messagerie publication-abonnement de Salesforce : un système publie un événement (une commande expédiée, un lead réattribué) et un ou plusieurs abonnés y réagissent. Deux modèles ont coexisté. Le modèle historique à volume standard est déprécié depuis Spring '19 et, depuis, toute nouvelle définition d'événement est à volume élevé par défaut.

D'après la note officielle de retrait dans l'aide Salesforce, mise à jour en octobre 2026 :

• Jusqu'au 15 décembre 2026 : les événements à volume standard existants sont encore publiés et distribués, mais ne sont plus pris en charge. Salesforce refuse les demandes de support les concernant et ne livre aucun correctif.
• À partir du 15 décembre 2026 : la publication et l'abonnement aux événements à volume standard ne fonctionnent plus.

Certaines pages plus anciennes de la documentation développeur mentionnent encore des versions ultérieures pour ce retrait. Considérez l'article d'aide comme la référence et planifiez pour le 15 décembre.

Bonne nouvelle : la solution de remplacement existe déjà dans votre org. Le guide développeur des événements de plate-forme (en anglais) précise que les événements à volume élevé sont conçus pour traiter des millions d'événements, conservent les messages 72 heures au lieu de 24 heures pour l'ancien modèle et sont publiés de façon asynchrone avec des tentatives automatiques.

Qui est concerné

Vous êtes concerné uniquement si votre org contient des événements de plate-forme personnalisés créés en volume standard, c'est-à-dire en pratique définis avant Spring '19. Profils typiques :

• Orgs en production depuis plus de sept ans : les premières intégrations événementielles avec un ERP, un prestataire logistique ou un outil de facturation sont les premières suspectes.
• Équipes ayant hérité d'intégrations : un ancien partenaire ou développeur a construit une synchronisation par événements que personne n'a retouchée depuis.
• Orgs avec automatisations déclenchées par événement : déclencheurs Apex, flows déclenchés par un événement de plate-forme ou anciens processus abonnés à un ancien événement.
• Abonnés externes : middleware ou applications sur mesure qui écoutent un ancien canal via la Streaming API.

Si tous vos événements de plate-forme ont été créés après 2019, vous n'avez rien à migrer, mais une vérification de dix minutes reste utile pour le confirmer.

Trois options de migration

Salesforce documente trois façons de passer du volume standard au volume élevé. Choisissez celle qui correspond à la taille et au niveau de risque de votre configuration.

1. Migration en libre-service dans Configuration (recommandée par Salesforce). Sur la page Événements de plate-forme de Configuration, un bouton de migration convertit tous vos événements à volume standard en une seule fois. Il est disponible depuis Winter '27. Selon Salesforce, l'opération prend généralement une quinzaine de minutes mais peut durer jusqu'à 24 heures, et vous recevez un e-mail pour chaque événement migré.
2. Migration scriptée avec la Metadata API. Le type de métadonnées PlatformEventMigration (en anglais) permet aux développeurs de migrer les événements un par un depuis un pipeline. L'objet Tooling API correspondant (en anglais) expose un statut de migration pour suivre l'avancement. Attention : une migration lancée ne peut pas être annulée.
3. Reconstruction manuelle. Créez un nouvel événement à volume élevé, arrêtez de publier l'ancien, laissez les messages restants être traités ou expirer, désactivez les anciens abonnements, puis faites pointer chaque flow, déclencheur et client Streaming API vers le nouvel événement.

Quelle que soit l'option, prévoyez une fenêtre de maintenance : pendant la migration en libre-service, la publication est indisponible et vous ne pouvez pas créer de déclencheurs ou de flows sur les événements en cours de migration.

Que faire maintenant : le plan pas à pas avant le 15 décembre

Cinq semaines suffisent si vous commencez cette semaine. Voici l'ordre que nous recommandons aux administrateurs et aux responsables d'intégration.

1. Inventorier vos événements. Dans Configuration, ouvrez Événements de plate-forme et listez chaque événement personnalisé, sa date de création et ses abonnés. Reportez la liste dans votre outil de suivi de projet.
2. Cartographier publieurs et abonnés. Pour chaque événement, notez qui publie (Apex, flow, système externe) et qui écoute (déclencheurs, flows, middleware, applications). C'est l'étape la plus souvent oubliée, et celle qui évite les mauvaises surprises.
3. Lancer d'abord la migration dans une sandbox complète ou partielle. Utilisez le bouton en libre-service ou un script Metadata API, puis rejouez un scénario métier réaliste de bout en bout.
4. Tester explicitement les abonnés externes. Demandez à chaque responsable d'intégration de confirmer que son client se reconnecte et reçoit les messages après migration. Vérifiez le comportement de relecture, car la durée de conservation diffère entre les deux modèles.
5. Planifier la production sur un créneau calme. Gelez les modifications des flows et déclencheurs concernés, prévenez les utilisateurs métier que les synchronisations événementielles peuvent s'interrompre et surveillez les e-mails de confirmation.
6. Surveiller pendant une semaine. Suivez les journaux d'erreurs, les tableaux de bord d'intégration et les flows qui utilisent des chemins d'erreur pour gérer les échecs. Ne clôturez le changement qu'une fois chaque abonné confirmé opérationnel.

Check-list de préparation avant de lancer la migration :

• Chaque événement à volume standard et son responsable sont identifiés.
• La migration en sandbox est terminée et le scénario métier testé.
• Les responsables des intégrations externes ont validé.
• Une fenêtre de production et un plan de communication en cas de retour arrière sont convenus.

Intégrer cette échéance à votre plan de versions

Ce retrait tombe juste avant le cycle de version Spring '27, qui comporte déjà d'autres changements liés aux intégrations. Si vous revoyez vos applications connectées et vos méthodes d'authentification, notre article sur les échéances d'authentification Salesforce pour vos intégrations couvre les dates de 2027, et notre liste des mises à jour de version à traiter avant Spring '27 vous aide à regrouper les tests. Traiter ces changements dans une seule revue d'intégration coûte généralement moins cher que de les gérer un par un.

Conclusion

La fin des événements de plate-forme à volume standard est un changement ciblé mais tranchant : pour les orgs concernées, les intégrations événementielles s'arrêtent le 15 décembre 2026, sans support de secours. La correction est bien documentée et demande souvent moins d'une journée de travail effectif, à condition de savoir quels événements existent et qui en dépend.

Si vous souhaitez de l'aide pour auditer vos intégrations événementielles ou planifier la migration, ASC Digital peut mener l'inventaire et les tests en sandbox avec votre équipe dans le cadre de nos services Salesforce Sales Cloud ou de nos services Salesforce Service Cloud.