Export et migration des données Brevo : comment faire entrer ou sortir vos données

Le volume de recherche sur des expressions comme « brevo data export migration to another platform » traduit une seule inquiétude : que les données accumulées soient plus faciles à faire entrer qu’à faire sortir. La réponse honnête pour Brevo tient en trois points : l’essentiel sort proprement, une partie sort dans une forme qu’il faut reconstruire, et une part réduite mais importante ne peut pas bouger du tout.

Ce guide couvre les deux sens. Il liste exactement ce qui s’exporte, ce qui ne s’exporte pas, les appels d’API pour les comptes trop volumineux pour l’interface, et une liste de contrôle de migration qui traite les listes de suppression et la réputation d’envoi comme des sujets de premier plan plutôt que comme des détails de fin de projet.

Ce que vous pouvez réellement exporter depuis Brevo

Contacts et attributs

Le chemin dans l’interface est CRM, puis Contacts. Pour exporter toute la base, vérifiez qu’aucune liste ni aucun segment n’est chargé et qu’aucun filtre n’est appliqué. Pour exporter une seule liste ou un seul segment, cliquez d’abord sur « Charger une liste ou un segment » et sélectionnez-le.

Vous choisissez ensuite les attributs standard et personnalisés à inclure. EMAIL, la date de dernière modification et la date de création sont sélectionnés par défaut, et c’est à vous d’ajouter le reste : c’est l’étape que l’on rate le plus souvent. Choisissez votre séparateur de champ CSV, point-virgule ou virgule, et activez éventuellement « Envoyer l’export par e-mail » pour qu’un lien de téléchargement parte vers l’adresse du propriétaire du compte. Cliquez sur « Démarrer l’export », puis téléchargez le fichier depuis la cloche de notifications située à côté du nom de votre compte.

Listes et segments

Les listes s’exportent sous forme d’appartenance : lancez un export par liste, ou incluez les métadonnées _listIds dans un unique export complet et découpez le fichier ensuite. GET /v3/contacts/lists vous donne les noms de listes, les identifiants et les identifiants de dossier pour recréer la structure de l’autre côté.

Les segments, c’est autre chose, et c’est le premier vrai manque. GET /v3/contacts/segments ne renvoie que id, segmentName, categoryName et updatedAt. Les conditions de filtrage qui définissent un segment ne sont pas exposées. Vous pouvez exporter les membres d’un segment à un instant donné, mais la règle qui les a produits doit être relevée à l’écran et reconstruite à la main dans le nouvel outil. Faites une capture d’écran de chaque segment avant de résilier le compte.

Statistiques de campagne

Depuis un rapport de campagne, vous pouvez exporter les données en CSV, et les rapports e-mail et SMS proposent aussi une version PDF à partager ou imprimer. Pour une récupération historique complète, GET /v3/emailCampaigns accepte un paramètre statistics avec les valeurs globalStats, linksStats ou statsByDomain, ainsi qu’un couple startDate et endDate couvrant une plage allant jusqu’à deux ans.

Journaux transactionnels

Deux chemins, avec des fenêtres différentes.

GET /v3/smtp/statistics/events renvoie les événements individuels filtrés par type (delivered, opened, clicks, hardBounces, spam, unsubscribed et d’autres). La plage de dates ne peut pas dépasser 90 jours, et elle porte par défaut sur les 30 derniers jours si vous ne passez ni plage ni paramètre days.

Pour le volume, POST /v3/webhooks/export crée une tâche d’export sur les 7 derniers jours d’événements bruts, plafonnée à 20 tâches d’export par période de 7 jours. Elle renvoie un processId, appelle votre URL de notification une fois terminée et livre un CSV avec des colonnes dont date, email, event, message-id, reason, sending_ip, subject, tag et template_id. Les gros volumes arrivent sous forme d’archive compressée de plusieurs fichiers CSV.

La conséquence pratique : si vous voulez plus de 90 jours d’historique transactionnel, il fallait l’exporter régulièrement depuis le début. Mettez cette tâche en place maintenant, pas la semaine où vous décidez de partir.

Ce qui ne vous suit pas

C’est la partie que la plupart des guides de migration passent sous silence.

• La structure des scénarios d’automation. L’API peut déclencher des automations via des événements, mais aucun endpoint documenté ne permet de relire les branches, les délais et les conditions d’un scénario. Chaque scénario se reconstruit manuellement dans la nouvelle plateforme.
• Les définitions de filtres de segment. Comme ci-dessus, seuls les noms et les membres actuels sont récupérables.
• L’historique d’engagement complet par contact. Vous pouvez exporter les personnes qui ont ouvert, cliqué, pas ouvert, se sont désabonnées, ou les rebonds durs et souples d’une campagne précise grâce au customContactFilter de l’endpoint d’export. Ce que vous ne pouvez pas obtenir, c’est un fichier unique et propre listant « toutes les ouvertures et tous les clics de ce contact », parce que les endpoints d’événements bruts sont bornés à 90 jours.
• La fidélité de rendu des modèles. htmlContent s’exporte proprement, mais les blocs glisser-déposer, la syntaxe des balises de fusion et les emplacements de lien de désinscription sont propres à chaque plateforme. Le HTML que vous exportez est un point de départ, pas un modèle fini. Prévoyez du temps pour retester chaque modèle dans le nouvel éditeur.
• La réputation de délivrabilité. La réputation d’expéditeur vit sur les adresses IP d’envoi et le domaine authentifié. Nouvelle plateforme, nouveau pool d’IP, nouvelle montée en charge. Garder le même domaine et la même configuration DKIM préserve le volet domaine de la réputation, ce qui aide vraiment, mais ne transporte pas le volet IP.
• Les identifiants de formulaires, de landing pages et de suivi. Les formulaires d’inscription, les landing pages et le script de suivi ont tous des identifiants propres à la plateforme. Tout ce qui est intégré sur votre site doit être remplacé, et toute analyse liée à ces identifiants casse au moment de la bascule.

Export scripté pour les gros comptes

Au-delà d’environ 100 000 contacts, l’export via l’interface devient lent et pénible, et vous voulez de toute façon une tâche reproductible. L’endpoint d’export des contacts est asynchrone : il accepte un filtre, renvoie un identifiant de processus, et vous remet un CSV une fois terminé.

curl --request POST \
  --url https://api.brevo.com/v3/contacts/export \
  --header 'accept: application/json' \
  --header 'content-type: application/json' \
  --header 'api-key: YOUR_API_KEY' \
  --data '{
    "customContactFilter": { "actionForContacts": "allContacts" },
    "exportMandatoryAttributes": true,
    "exportAttributes": ["FIRSTNAME", "LASTNAME", "SMS", "COUNTRY"],
    "exportMetadata": ["_listIds", "ADDED_TIME", "MODIFIED_TIME"],
    "exportSubscriptionStatus": ["email_marketing", "sms_marketing"],
    "exportDateInUTC": true,
    "notifyUrl": "https://example.com/hooks/brevo-export"
  }'

Un appel réussi renvoie un code HTTP 202 et un corps contenant un processId. exportMandatoryAttributes vaut true par défaut et couvre EMAIL, ADDED_TIME et MODIFIED_TIME : c’est donc dans exportAttributes que vous nommez vos champs personnalisés. Renseigner exportSubscriptionStatus est ce qui fait figurer l’état du consentement marketing pour l’e-mail et le SMS dans le fichier, et l’omettre est la façon la plus courante de produire un export inutilisable pour une migration conforme.

Si vous préférez parcourir les enregistrements plutôt qu’attendre une tâche, GET /v3/contacts accepte un limit allant jusqu’à 1000 avec un offset, plus modifiedSince et createdSince pour les récupérations incrémentales. Chaque contact revient avec emailBlacklisted, smsBlacklisted, listIds, listUnsubscribed et consentGroups, soit tout ce qu’il faut pour reconstituer l’état du consentement.

Surveillez les limites de débit pendant que vous scriptez tout cela. Les endpoints de contacts autorisent 36 000 requêtes par heure et 10 par seconde sur les forfaits standard, le double sur les niveaux Professional et Enterprise, tandis que la plupart des autres endpoints plafonnent à 100 requêtes par heure. Parcourir un million de contacts par pages de 1000 représente 1000 requêtes, confortablement dans le budget des contacts, mais marteler les endpoints de campagne ou de modèles en boucle, non.

Pourquoi votre liste de suppression doit migrer en premier

Déplacez les désinscriptions avant tout le reste.

L’argument juridique est simple. Un contact qui s’est désabonné a retiré son consentement à votre marque. Ce retrait ne se réinitialise pas parce que vous changez de prestataire. Au regard du RGPD, la conservation de la preuve du consentement et de son retrait est votre obligation en tant que responsable de traitement, et au regard du CAN-SPAM une désinscription doit être honorée dans les dix jours ouvrés et le reste indéfiniment. Perdre la liste au cours d’une migration n’est pas un accident technique, c’est un manquement à la conformité avec une trace écrite qui pointe vers vous.

L’argument de délivrabilité est encore plus lourd en pratique. Les adresses supprimées appartiennent de façon disproportionnée à des personnes qui ont porté plainte, qui ont généré un rebond dur ou qui voulaient activement partir. Leur écrire depuis une IP toute neuve sans réputation est le moyen connu le plus rapide de faire brider ou bloquer une nouvelle configuration d’envoi dès sa première semaine. Quelques milliers de pièges à spam recyclés et de plaignants peuvent annuler un mois de montée en charge soignée.

Exportez donc explicitement les cohortes supprimées plutôt que d’espérer qu’elles soient implicites. Sur l’endpoint d’export, actionForContacts accepte unsubscribed pour les contacts blacklistés par un moyen quelconque et unsubscribedPerList pour les contacts désinscrits d’une liste précise. Faites une passe distincte pour hardBounces par campagne. À l’arrivée dans une nouvelle plateforme, importez ce fichier dans sa liste de suppression, pas dans une liste contactable.

Brevo gère aussi le cas inverse : il prend en charge l’import d’une liste de contacts blacklistés, et l’API d’import accepte les booléens emailBlacklist et smsBlacklist pour qu’un fichier importé arrive en statut supprimé. Notez l’asymétrie que Brevo a raison d’imposer : les contacts ne peuvent pas être retirés de la blacklist en masse, parce que réabonner en masse une personne qui a demandé qu’on la laisse tranquille serait illégal. La suppression est facile à ajouter et délibérément difficile à retirer. Voyez-y le bon comportement, pas un obstacle.

Liste de contrôle de migration, au départ de Brevo

1. Audit. Comptez les contacts, les listes, les segments, les automations actives, les modèles et les intégrations. Notez quelles intégrations écrivent dans Brevo, car ce sont les tuyaux qu’il faudra rebrancher.
2. Export. Contacts avec tous les attributs et le statut d’abonnement, un fichier par liste ou un fichier unique portant _listIds, cohortes de suppression dans des fichiers séparés, statistiques de campagne, événements transactionnels aussi loin que la fenêtre de 90 jours le permet, et code HTML des modèles.
3. Archivez ce qui expire. Tout ce qui est borné dans le temps (événements bruts, journaux) disparaît dès que la fenêtre défile. Stockez-le dès maintenant dans votre propre entrepôt ou stockage objet.
4. Nettoyez et faites correspondre. Dédoublonnez, normalisez les formats de date et de téléphone, et rédigez une correspondance explicite entre colonnes et champs pour la nouvelle plateforme. C’est aussi le moment naturel pour écarter les adresses inactives depuis un an, ce qui coûte moins cher que de payer pour réchauffer du poids mort. Notre guide de nettoyage de liste e-mail donne les seuils.
5. Chargez la suppression en premier. Importez les désinscriptions et les rebonds durs dans la liste de suppression de la nouvelle plateforme, vérifiez que les comptes correspondent à votre export, et seulement ensuite chargez les contacts contactables.
6. Montez en charge. Commencez par votre segment le plus engagé, augmentez le volume progressivement, et surveillez chaque jour les taux de rebond et de plainte. Notre guide de la délivrabilité e-mail détaille la séquence.
7. Fonctionnez en parallèle. Gardez Brevo actif et en charge de vos e-mails transactionnels critiques pendant que la nouvelle plateforme prend une part croissante des envois marketing. Ne basculez pas les deux en même temps.
8. Vérifiez. Réconciliez les nombres de contacts, contrôlez vingt contacts champ par champ, confirmez que les contacts supprimés le sont réellement en tentant un envoi de test, et comparez une semaine de volume d’envoi avec l’ancienne plateforme.
9. Basculez en gardant un retour arrière. Modifiez le DNS et les endpoints d’intégration sur un créneau où quelqu’un surveille. Gardez le compte Brevo actif et payé pendant au moins un cycle de facturation complet après la bascule, avec les fichiers exportés stockés en dehors des deux plateformes. C’est cela, et non la promesse d’un éditeur, votre véritable plan de retour arrière.

Migrer vers Brevo depuis une autre plateforme

La même liste de contrôle s’applique en sens inverse, avec trois remarques propres à Brevo.

Obtenez un vrai export de la plateforme sortante. La plupart des plateformes vous donneront les contacts et leurs champs personnalisés en CSV. Demandez explicitement la liste de suppression et la liste des rebonds, souvent placées dans un export séparé que l’on oublie de réclamer. Si vous venez d’un modèle tarifaire par contact, comparez ce que vous paierez réellement à l’arrivée avec notre guide des tarifs Brevo.

Faites correspondre les champs avant de charger. Les attributs Brevo ont des types (texte, nombre, date, booléen, catégorie), et une date qui atterrit dans un attribut texte ne sera pas filtrable ensuite. Créez d’abord les attributs avec les bons types, puis importez.

Importez via l’API pour tout ce qui a du volume. POST /v3/contacts/import accepte un CSV en ligne dans fileBody, un tableau JSON dans jsonBody, tous deux plafonnés autour de 10 Mo, ou un fichier distant via fileUrl, plus des listIds ou un objet newList. updateExistingContacts vaut true par défaut et fait la correspondance sur l’e-mail. Lancez un premier import avec emailBlacklist à true pour votre fichier de suppression, puis un second import pour les contacts contactables. Les scripts complets se trouvent dans notre guide pour importer des contacts CSV dans Brevo avec un script.

Reconstruisez ensuite ce qui ne s’est pas transféré : automations, segments, formulaires et modèles. Envoyez un test à une poignée de fournisseurs de messagerie avant d’écrire à qui que ce soit de réel.

Ne laissez pas la prochaine migration devenir une falaise

Si une migration de plateforme ressemble à une falaise, c’est que la plateforme est devenue le système de référence. L’historique de commandes, l’état des abonnés et les résultats de campagne vivent chez un seul éditeur, et les déplacer revient à organiser une évacuation.

L’alternative consiste à garder votre propre source de vérité et à faire de la plateforme d’envoi une destination plutôt qu’un coffre-fort. Si les données de votre boutique, l’état du consentement et les événements d’engagement sont synchronisés en continu vers vos propres systèmes, changer de canal ou en ajouter un devient un changement de configuration plutôt qu’un projet. C’est le travail que Tajo accomplit entre Brevo et la stack d’un marchand : faire circuler les données dans les deux sens pour que la plateforme ne soit jamais la seule copie.

Dans tous les cas, les tâches d’export décrites ci-dessus méritent d’être planifiées dès maintenant, que vous prévoyiez de partir ou non. La migration la moins coûteuse est celle où les données sont déjà en dehors de la plateforme au moment où vous prenez la décision.