Intégration Salesforce Brevo : concevoir une architecture interopérable
Dernière mise à jour : 9 oct.
Une page de dons, un CRM et une plateforme d’e-mailing peuvent fonctionner chacun correctement tout en produisant un parcours incohérent. Ex. : Un soutien reçoit deux remerciements, son don manque dans le CRM ou son désabonnement disparaît à lors d'une synchro ultérieure.
L’intégration doit traiter ces situations dès sa conception.
Intégration Salesforce Brevo : attribuer une responsabilité à chaque brique
Prenons une association fictive qui utilise une page de dons, un prestataire de paiement, Salesforce Nonprofit Cloud et Brevo.
La page présente le formulaire.
Le prestataire confirme les événements de paiement.
Salesforce rassemble la relation et les données de collecte.
Brevo gère les envois et les exclusions liées aux communications.
Un retour du navigateur vers une page « Merci » ne doit pas être la seule preuve d’un paiement. L’utilisateur doit pouvoir fermer son onglet, et son paiement doit pouvoir rester en attente jusqu'à ce qu'il le rouvre. Le traitement doit s’appuyer sur un événement serveur vérifié ou une interrogation fiable du prestataire, selon ses possibilités documentées.
Du formulaire au parcours donateur
Page de dons Présenter la campagne et recueillir les informations nécessaires. |
↓ |
Prestataire de paiement Confirmer l’état du paiement par un événement serveur vérifié ou une interrogation fiable. |
↓ |
Intégration Identifier l’événement, éviter les doublons et traiter les erreurs. |
↓ |
CRM et communications Salesforce suit la relation et la collecte ; Brevo gère les envois et leurs exclusions. |
Le désabonnement doit aussi remonter vers le CRM, et ce, pour éviter qu'un nouvel import de données ne réactive une personne désabonnée.
Écrire un contrat de données
Avant de connecter les applications, définissez les éléments échangés : référence externe de transaction, type d’événement, montant, devise, état du paiement, campagne et horodatage. Les données personnelles sont limitées au nécessaire. L’architecture n’a pas besoin de transporter les numéros complets de cartes bancaires.
La référence de campagne doit être définie avant lancement. Sinon, le paiement arrive certes, mais l’équipe ne sait plus à quelle opération l’attribuer. Définissez également le comportement lorsqu’un identifiant de campagne est inconnu : une exception à traiter, plutôt qu’une affectation arbitraire.
Chaque champ a une origine et une autorité. Une correction d’adresse dans le CRM ne devrait pas être écrasée par un événement ancien. Les mises à jour doivent tenir compte du type de donnée, du statut et de la chronologie.
Traiter les doublons et les incidents
Les événements peuvent être retransmis. Une intégration robuste doit être idempotente : traiter à nouveau le même événement ne crée pas une seconde transaction. Une clé de traitement identifie l’événement ; une autre référence peut identifier la transaction concernée. Ces deux notions sont liées, mais distinctes.
L’orchestrateur enregistre le statut de traitement, applique les transformations et route les erreurs. Il peut s’agir d’une plateforme d’intégration ou d’un développement adapté au volume et aux contraintes. Make constitue une option, pas une obligation. Les règles internes simples peuvent rester dans Salesforce Flow.
Supposons que Salesforce soit indisponible au moment du paiement. Le don ne doit pas disparaître : l’événement est conservé dans une file durable ou récupérable, puis repris. La réémission doit conserver ses identifiants. Une reprise manuelle documentée est préférable à une correction directe dont personne ne connaît les conséquences.
Faire circuler les exclusions dans le bon sens
Brevo expose des événements marketing par webhooks, notamment le désabonnement. Leur exploitation permet de remonter des changements au CRM. Elle ne dispense pas de décider le périmètre exact de l’exclusion : newsletter, campagne, canal ou opposition plus large.
Une règle de conception protège le soutien : un import destiné à actualiser des coordonnées ne réactive jamais à lui seul une personne désabonnée. La préférence la plus récente et le périmètre de l’opposition doivent être respectés. Si les événements sont contradictoires, l’envoi concerné est suspendu jusqu’à résolution.
Séparez les messages de service des sollicitations de collecte et examinez leur fondement avec le référent compétent. Une ouverture d’e-mail ou un clic n’établit pas un consentement à une nouvelle catégorie de messages.
Tester le parcours de bout en bout
La recette comprend un paiement réussi, un paiement retardé, un événement dupliqué, un remboursement et un désabonnement suivi d’un nouvel import. Elle couvre aussi un webhook non autorisé : vérifiez l’authentification ou la signature selon les capacités documentées du fournisseur, sans supposer que tous proposent le même mécanisme.
Pour chaque cas, contrôlez le CRM, le système de paiement et les exclusions Brevo. Une supervision expose les erreurs en attente avec un responsable et un délai de traitement. C’est cette exploitation quotidienne qui transforme une connexion en service fiable.
Pour avancer : faites rejouer deux fois le même événement sur des données de test. Si votre recette ne prévoit pas ce cas, commencez par lui. Découvrez l’accompagnement GenerosIT.
Références
Mots-clés : intégration Salesforce–Brevo · architecture CRM interopérable · pages de dons · synchronisation des données · parcours donateur.
Mots-clés : Salesforce Brevo · architecture CRM interopérable · pages de dons · synchronisation des données · parcours donateur.
Commentaires