Une liste de contacts peut être à jour dans le CRM et déjà fausse pour le prochain envoi : une personne s’est désinscrite dans Sarbacane entre deux synchronisations. Si le connecteur recopie simplement la fiche commerciale, il risque de réintroduire cette adresse dans l’audience. Le premier travail consiste donc à définir quelles informations chaque système peut modifier.
Sarbacane Contacts, Campaigns et Sendkit répondent à des usages distincts. Contacts organise notamment les listes utilisées par Campaigns et Forms ; Sendkit gère ses contacts et exclusions dans son propre périmètre. Une intégration doit tenir compte de ces frontières, au lieu de supposer qu’une liste ou une clé donne accès à toute la suite.
Ce guide explique comment relier un CRM aux audiences marketing, traiter les événements et maintenir séparément les notifications transactionnelles. Les exemples sont des propositions d’architecture à adapter. Ils ne décrivent pas une réalisation client et ne remplacent pas la documentation API accessible depuis votre compte Sarbacane.
Notre accompagnement en intégration API couvre ce cadrage et la réalisation des échanges avec vos logiciels. Pour un besoin déjà identifié, l’offre d’intégration Sarbacane permet d’examiner le connecteur existant, les données à rapprocher et le premier flux à fiabiliser.
Choisir le premier échange utile avec Sarbacane
Commencez par une difficulté observable : le marketing importe un fichier avant chaque campagne, les désinscriptions ne reviennent pas dans le CRM ou le support ne retrouve pas le statut d’une notification. Ces situations appellent des échanges différents. Les regrouper dans un projet « synchroniser Sarbacane » rend le périmètre difficile à estimer et à réceptionner.
Un connecteur disponible peut suffire si les objets, le sens de synchronisation et la gestion des exclusions correspondent à votre besoin. Vérifiez d’abord sa couverture et ses limites. Une automatisation simple reste adaptée à un ajout de contact bien délimité ; un développement spécifique se justifie lorsque plusieurs sources, règles de priorité ou reprises doivent être coordonnées.
Le coût à comparer comprend aussi l’exploitation : retrouver un contact, expliquer son exclusion, corriger un champ et reprendre une opération échouée. Demandez une démonstration de ces cas avant de comparer seulement le prix du branchement initial. Un transfert automatisé qui exige encore une vérification manuelle de chaque audience peut déplacer le travail sans le réduire.
1. Distinguer Contacts, Campaigns et Sendkit
Associer chaque opération au bon produit
Dans la Suite, Contacts centralise les contacts destinés à Campaigns et Forms. Campaigns sert à préparer les campagnes et à consulter leur activité. Sendkit dispose notamment de ses clés API, paramètres SMTP, exclusions et événements. Engage et Chat ont également leur propre gestion de contacts : leur documentation ne prouve pas qu’une opération existe dans Contacts ou Campaigns.
La présentation officielle de la gestion des contacts précise ces séparations. Écrivez une correspondance courte entre votre besoin et le produit concerné : alimenter une liste, préparer une campagne, remonter une désinscription ou envoyer une notification applicative. Cette correspondance évite de développer contre la mauvaise interface.
Vérifier les accès dans le compte concerné
Les menus développeurs de Campaigns et de Contacts, ainsi que la gestion des clés de Sendkit, donnent accès aux réglages et à la documentation associés. Avant de coder, confirmez l’authentification, les droits, les opérations disponibles, les limites et les événements effectivement exposés. Conservez la date et le périmètre de cette vérification dans la documentation du projet.
Une clé reste côté serveur, hors du navigateur et des journaux applicatifs. Séparez les usages lorsque le produit le permet et limitez les accès au besoin retenu. Testez aussi une clé révoquée : le traitement doit s’arrêter avec une erreur exploitable, sans passer à une autre identité ni relancer indéfiniment l’opération. Les noms d’en-têtes et les URLs doivent venir de la documentation correspondant au compte utilisé.
2. Relier les contacts sans réactiver les exclus
Séparer identité, segmentation et exclusion
Le CRM peut être la référence pour le nom de l’entreprise, la personne affectée au compte ou un segment commercial. Cela ne lui donne pas automatiquement autorité pour réactiver une adresse exclue d’un envoi. Définissez, champ par champ, la source et les modifications permises. Une exclusion mérite une règle propre, distincte d’un changement de civilité ou de secteur.
Gardez une correspondance entre l’identifiant du CRM, celui du contact distant et les listes concernées. L’adresse email peut changer ; elle ne constitue pas toujours une clé métier suffisante. Prévoyez le cas des doublons et des contacts présents dans plusieurs listes avant une fusion. Une suppression globale peut avoir un effet plus large qu’un simple retrait d’une audience.
Préparer une synchronisation explicable
Pour chaque contact, conservez l’origine de la modification, sa date, le résultat de l’envoi et la dernière vérification réussie. Si deux systèmes proposent des états incompatibles, le connecteur doit appliquer une règle connue ou isoler le cas pour revue. Une date récente ne suffit pas à rendre une modification légitime : une mise à jour de téléphone ne doit pas effacer une désinscription.
Adaptez la fréquence des contrôles au prochain usage de la liste. Il n’existe pas ici de délai universel de sept jours. Avant une campagne, vérifiez que les exclusions nécessaires ont été prises en compte et que les éventuels retards restent acceptables selon les règles convenues. Une audience dont l’état ne peut pas être établi doit pouvoir être mise en attente sans bloquer les autres traitements.
3. Préparer une campagne avec une audience contrôlée
Séparer préparation et autorisation d’envoi
Créer une campagne ou importer des contacts ne vaut pas autorisation d’envoi. Décrivez les étapes réellement disponibles dans votre environnement : préparation de la liste, rapprochement des exclusions, contrôle des champs de personnalisation, test du message et validation par l’équipe responsable. L’automatisation doit respecter cette validation plutôt que la déduire d’un appel API réussi.
Enregistrez les identifiants retournés et le lien entre la campagne, l’audience et la version du contenu. Un statut HTTP favorable confirme une étape technique ; vérifiez ensuite l’état de l’objet lorsque l’opération se poursuit à distance. Si une réponse manque après une demande d’envoi, contrôlez ce qui s’est produit avant de répéter une action susceptible de partir deux fois.
Rendre les écarts visibles avant le départ
Le contrôle utile rapproche les contacts attendus, les contacts acceptés et les exclusions connues. Un total identique ne prouve pas qu’il s’agit des mêmes personnes. Comparez les identifiants ou un échantillon pertinent, puis rendez les refus lisibles : champ requis absent, adresse inexploitable, correspondance inconnue ou exclusion appliquée.
Le marketing doit pouvoir corriger la cause dans le bon outil. Modifier une audience à la main juste avant l’envoi sans en conserver la trace prépare le même incident à la synchronisation suivante. Décidez si la correction doit revenir au CRM, rester locale à la campagne ou faire l’objet d’une exception ponctuelle clairement identifiée.
4. Recevoir les webhooks et rapprocher les événements
Conserver l’événement avant son traitement
Les événements disponibles et leur format dépendent du produit et de sa documentation. Ne présumez pas qu’un nom de statut existe partout. Le récepteur doit vérifier les garanties d’authenticité effectivement proposées, limiter ce qu’il accepte et enregistrer les informations nécessaires au traitement avant d’en confirmer la réception. Une réponse positive trop précoce peut masquer une perte.
Préparez une déduplication avec l’identifiant d’événement fourni lorsqu’il existe, ou une règle de rapprochement documentée. Le même retour reçu deux fois ne doit pas créer deux tâches commerciales. Un événement sans contact interne doit rester visible dans une file d’anomalies ; le supprimer silencieusement rendrait le bilan artificiellement propre.
Respecter la chronologie et la portée du signal
Enregistrez séparément la date de l’événement et celle de sa réception. Un retour tardif ne doit pas rétablir un état ancien sans contrôle. Le traitement peut mettre à jour le CRM, créer une vérification ou alimenter le reporting selon la nature de l’événement. Il doit conserver le lien avec le contact, la campagne ou le message concerné.
Une ouverture ne démontre pas à elle seule une intention commerciale. Un clic demande également du contexte avant une relance. Une désinscription doit continuer à être prise en compte même lorsqu’un signal d’engagement positif arrive ensuite. Testez ces combinaisons avec le marketing pour éviter de transformer automatiquement toute activité en tâche de prospection.
5. Isoler les notifications Sendkit
Identifier le message attendu par l’application
Sendkit peut être utilisé pour les communications transactionnelles par API ou SMTP. Le guide officiel de prise en main Sendkit décrit notamment les clés, l’activité, les exclusions, les domaines et les webhooks. Vérifiez ces réglages dans le compte destiné à votre application avant de prévoir les envois.
Une confirmation de commande, une notification de livraison et un message de récupération de compte n’ont pas le même délai utile. Associez chaque envoi à une opération interne, à son motif et à son statut. Une confirmation de prise en charge par le fournisseur ne prouve pas la réception par le destinataire ; le support doit pouvoir distinguer ces étapes.
Prévoir une reprise qui reste utile
Réservez une file et des alertes adaptées aux notifications importantes. Si le traitement reprend après une interruption, vérifiez que le message a encore un sens : une ancienne alerte de disponibilité ou une notification devenue caduque ne doit pas partir mécaniquement. Définissez comment traiter une adresse exclue ou un rejet sans contourner les réglages du fournisseur.
Une campagne marketing et une notification applicative ne doivent pas partager par accident leurs règles de reprise. Conservez toutefois une vision support cohérente : opération d’origine, demande d’envoi, dernier état connu et prochaine action possible. Cette chronologie permet d’expliquer un échec sans exposer les clés ni le contenu complet des messages dans les journaux.
6. Donner une priorité explicite aux exclusions
Documentez séparément désinscription, adresse en erreur et plainte. Ces états ne décrivent pas la même situation et peuvent avoir des portées différentes selon le produit ou la liste. Évitez un unique booléen « actif » qui ferait disparaître cette information au retour dans le CRM. Conservez la source, la date, le périmètre et la raison connue.
La procédure de correction doit préciser qui intervient et quelles vérifications sont nécessaires. Un commercial qui corrige une adresse ne doit pas réactiver implicitement une préférence d’envoi. Si une réinscription est possible dans le parcours retenu, son origine doit être explicable ; une synchronisation périodique ne constitue pas en elle-même une nouvelle demande du contact.
Ces recommandations décrivent des contrôles d’intégration. Les règles applicables à vos communications, à leur conservation et aux demandes des personnes sont à définir avec les responsables concernés. Un connecteur qui transporte correctement les données ne constitue pas, à lui seul, une validation de conformité.
7. Exemple fictif : une invitation reliée au CRM
Suivre un contact de la sélection à l’exclusion
Imaginons un distributeur B2B qui prépare une invitation à une démonstration. Le CRM sélectionne les comptes concernés ; le connecteur rapproche les contacts avec une liste Sarbacane destinée à Campaigns. Avant validation, il présente les contacts retenus, les exclusions et les anomalies. L’équipe marketing teste le contenu puis autorise la campagne selon le processus convenu.
Une personne se désinscrit après l’envoi. Le traitement retrouve son identifiant interne et enregistre l’exclusion avec sa source et sa date. Le lendemain, le CRM transmet une modification de fonction professionnelle. Le test attendu est précis : cette mise à jour peut enrichir la fiche, mais ne réactive pas la personne dans l’audience concernée.
Éprouver les cas qui cassent la synchronisation
Rejouez ensuite le même événement, envoyez-le avec retard et simulez une correspondance inconnue. Le premier cas ne doit pas produire de doublon ; le deuxième doit respecter la chronologie ; le troisième doit devenir une anomalie consultable. Testez également une interruption pendant l’import et la reprise à partir d’un état connu, sans recommencer toute la liste à l’aveugle.
La preuve de recette réunit l’entrée, la transformation attendue, le résultat observé et la trace consultable par le support. Utilisez des contacts de test maîtrisés et un dispositif d’envoi convenu. Cet exemple n’implique ni un projet client Dawap existant ni une garantie de disponibilité d’un endpoint : chaque opération est à vérifier dans l’interface du produit retenu.
8. Définir un premier lot vérifiable
- Choisir un résultat : par exemple, alimenter une audience depuis le CRM sans annuler les exclusions.
- Vérifier la couverture existante : connecteur disponible, interfaces du compte, droits et limites.
- Écrire les correspondances : identifiants, champs, listes, priorités et opérations refusées.
- Préparer les erreurs : réponse perdue, doublon, contact inconnu, clé révoquée et fournisseur indisponible.
- Organiser l’exploitation : responsable de chaque anomalie, contrôle avant envoi et procédure de reprise.
Le livrable initial peut tenir dans une matrice : source, destination, objet, événement déclencheur, règle, preuve de succès et traitement de l’échec. Ajoutez les accès et interlocuteurs manquants avant l’estimation. Une demande de synchronisation bidirectionnelle mérite une justification par champ ; elle ne doit pas devenir le choix par défaut.
Reportez les statistiques secondaires et les automatisations commerciales tant que l’identité des contacts et les exclusions ne sont pas fiables. Pour examiner votre périmètre, l’offre d’intégrateur Sarbacane permet de partir d’un flux réel plutôt que de connecter toute la suite en une fois.
9. Tester la reprise et mesurer les écarts
Choisir des indicateurs liés au prochain envoi
Suivez les contacts attendus et rapprochés, les refus, les événements sans correspondance, l’ancienneté du dernier contrôle réussi et les opérations en attente. Un simple nombre d’appels API ne dit pas si la liste est exploitable. Distinguez une absence d’activité normale d’un arrêt du traitement ou d’un retard qui rend l’audience incertaine.
Fixez les délais d’alerte avec les équipes selon la fréquence des campagnes, les volumes et l’impact d’une notification tardive. Définissez aussi la décision attendue : continuer, isoler une audience, suspendre un envoi ou faire vérifier un contact. Le même seuil ne convient pas à un rapport hebdomadaire et à un message nécessaire pour poursuivre un parcours utilisateur.
Limiter les effets d’un arrêt ou d’un retour arrière
Le retour à une version précédente du connecteur ne retire pas un message déjà envoyé et n’efface pas un changement distant. Documentez ce qui peut réellement être annulé. En cas d’incident, il peut être préférable de suspendre une sortie, conserver les événements entrants et corriger les correspondances avant une reprise contrôlée.
La revue après mise en service doit examiner les anomalies et les gestes encore manuels. Si le marketing doit reconstruire chaque audience dans un tableur, recherchez la règle ou la preuve manquante. Si le support ne retrouve pas un envoi, améliorez la correspondance avec l’opération métier avant d’ajouter une nouvelle automatisation.
10. Éviter les erreurs qui rendent la base incohérente
- Confondre les produits : reprendre des exemples Engage ou Sendkit pour une opération Contacts sans vérifier leur applicabilité.
- Écraser les exclusions : recopier tout le CRM vers une audience sans règle de priorité.
- Perdre les identifiants : ne conserver que l’email et rendre une fusion ou un changement d’adresse ambigu.
- Relancer une action inconnue : répéter un envoi après une réponse perdue sans vérifier l’état distant.
- Ignorer les événements non rapprochés : afficher un traitement réussi alors que certains contacts restent sans correspondance.
- Mélanger marketing et transactionnel : retarder une notification utile dans une file de campagnes ou reprendre un message devenu caduc.
Un contrôle de fin de lot doit permettre à une personne qui n’a pas écrit le connecteur de retrouver une opération et d’expliquer son résultat. Si elle doit demander un export ou accéder aux secrets pour répondre, la documentation et les traces ne sont pas encore suffisantes. L’objectif est une intégration exploitable par vos équipes après la livraison.
Questions fréquentes sur l’API Sarbacane
Que faut-il vérifier avant de connecter Sarbacane au CRM ?
Identifiez le produit utilisé, les interfaces et droits disponibles, les listes concernées et la source de chaque champ. Définissez surtout les règles d’exclusion et les cas de reprise avant d’automatiser les échanges.
Contacts, Campaigns et Sendkit partagent-ils la même gestion de contacts ?
Contacts gère les contacts de Campaigns et Forms. Sendkit gère les siens dans son propre périmètre. Vérifiez les accès, les exclusions et la documentation de chaque produit au lieu de supposer une synchronisation globale.
Dawap peut-il reprendre un connecteur Sarbacane existant ?
Oui. Nous examinons les échanges, les correspondances de données et les incidents avec vos équipes pour définir un premier lot : correction ciblée, complément au connecteur ou intégration spécifique selon le besoin vérifié.
Sources et limites de cette analyse
Les périmètres produits ont été vérifiés le 24 octobre 2026 dans les ressources officielles de Sarbacane. Les méthodes de rapprochement, de reprise et de recette proposées ici sont des recommandations d’architecture Dawap. Les détails d’authentification, endpoints, quotas et garanties des événements doivent être confirmés dans la documentation du compte concerné avant développement.
- Sarbacane : gestion des contacts dans la Suite.
- Sarbacane : Campaigns et ses réglages développeurs.
- Sarbacane : prise en main de Sendkit.
Approfondir les échanges emailing et CRM
Comparer les besoins marketing et transactionnels
Le guide API emailing et marketing automation aide à situer les échanges avec le CRM dans un périmètre plus large, avant de retenir un fournisseur ou un connecteur.
Examiner un autre fournisseur sans transposer ses contrats
Le guide API Brevo donne un autre éclairage sur contacts, événements et messages transactionnels. Ses endpoints et règles restent propres à Brevo ; ils ne constituent pas la documentation de Sarbacane.
Définir le périmètre d’un connecteur
Notre offre d’intégration emailing et marketing automation décrit l’accompagnement pour relier ces outils au SI, répartir les responsabilités et prévoir les contrôles après mise en service.
Conclusion : commencer par un contact dont on peut expliquer l’état
Une intégration Sarbacane devient utile quand les équipes retrouvent la même explication d’un contact, d’une audience et d’un envoi. La connexion technique doit préserver les décisions prises dans chaque système, en particulier les exclusions qui ne doivent pas disparaître lors d’une mise à jour commerciale.
Choisissez un premier échange, vérifiez son interface et écrivez les cas d’échec avant d’étendre le périmètre. Une liste rapprochée, une campagne contrôlée et une procédure de reprise compréhensible donnent un meilleur point de départ qu’une synchronisation globale difficile à expliquer.
Les gains se vérifieront dans vos usages : moins de corrections manuelles, des anomalies repérées et des réponses support plus faciles à établir. Aucun volume d’appels ni statut technique ne suffit à démontrer ces résultats sans contrôle des opérations réelles.
Pour relier Sarbacane à votre CRM, votre boutique ou votre application métier, notre équipe d’intégration API peut examiner le flux existant et définir avec vous un premier lot testable, ses limites et ses conditions de maintenance.
