L’import paraît simple : un CSV, un bouton “Importer”, et c’est parti. Dans la réalité, c’est l’opération la plus risquée pour ta délivrabilité. Un seul lot mal préparé peut injecter des milliers d’adresses invalides, créer des doublons silencieux, déclencher des hard bounces en série et faire dérailler votre score expéditeur pendant des semaines.

Depuis des années, j’ai affiné une trame simple pour que les imports cessent d’être une loterie : Collecte (préparer la qualité à la source), Contrôle (vérifier avant d’appuyer sur “Importer”), Cadence (démarrer sans violenter les FAI). À chaque fois que je m’y tiens, le taux de bounces reste sous contrôle, la réputation ne dévisse pas, et les revenus ne font plus les montagnes russes.

Ce guide est volontairement pratique : je vous emmène du avant (préparer), au pendant (exécuter), puis à l’après (suivre et corriger), avec des cas concrets.

1. Pourquoi l’import est le moment le plus risqué de l’emailing

On a tous vécu ce scénario : un CSV “bien rempli”, un import le vendredi, une campagne le lundi… et ensuite des hard bounces en rafale, des softs (4.7.0) chez des FAI, quelques plaintes, puis un doute généralisé sur la base. Ce n’était pas “la faute du contenu”. C’était l’import.

Un import mal préparé ne “crée” pas que des bounces. Il contamine aussi la réputation d’expéditeur (IP + domaine), provoque des ralentissements (throttling), dilue l’engagement et rogne le chiffre. L’inverse est vrai : un import propre augmente la part d’emails qui atteignent la boîte de réception, stabilise les KPI et rend vos prévisions moins nerveuses.

2. Collecte – la qualité à la source (pour importer sereinement)

Un import propre commence… bien avant le fichier. Si la collecte est floue, l’import devient une loterie. Voici le minimum vital qui change tout :

Prendre les bonnes métadonnées (traçables et utiles)

Pour chaque email, je garde toujours :

  • Source d’acquisition (formulaire, partenaire X, événement Y).
  • Preuve d’opt-in (timestamp, IP, page d’origine ou ref).
  • Type d’opt-in (simple / double).
  • Pays / langue (utile pour politiques FAI et futures communications).

Ces champs ne sont pas là pour faire joli. Ils servent à couper vite une source qui “fuit”, à prouver le consentement si besoin, et à piloter l’exposition des nouveaux arrivants.

Valider au moment de la saisie

Je bloque à la source ce qui deviendra un hard bounce demain :

  • Syntaxe (RFC, pas la regex “jouet”).
  • Domaine + MX (le domaine sait-il recevoir des mails ?).
  • Typos courantes (proposer “gmail.com ?”).
  • Jetables (domaines temporaires).
  • Honeypot / limite de vitesse (bots).
  • Politique role-based (info@, contact@…) : autorisés ? parcours spécifique ? refusés ?

Cadrer les partenaires

  • Preuve d’opt-in obligatoire, formatée.
  • Seuil d’invalides tolérés (ex. <1 %), au-delà, on refuse le lot.
  • Vérification à la source côté partenaire (via API si possible).

Par expérience, quand la collecte est cadrée ainsi, vous enlevez 60–70 % des sources de hard bounces avant même d’ouvrir un CSV.

3. Contrôle – vérifier avant d’appuyer sur “Importer”

On arrive au fichier. L’erreur la plus fréquente que je vois : “on importera et on verra”. Mauvais plan. Je fais toujours un preflight simple, qui tient en trois gestes.

1. Le “triage” en trois statuts

Je passe le fichier dans un outil de vérification (BounceStrike par exemple 🙄) et j’obtiens pour chaque adresse :

  • Valide
  • Risqué (catch-all, réputation douteuse, signaux faibles)
  • Invalide (typo irrécupérable, domaine sans MX, user unknown déjà connu, jetable strict)

Décision :

  • Valide → prêt à importer.
  • Risqué → je bascule en parcours de confirmation (ou j’impose une cadence très limitée pour la première exposition).
  • Invalide → je n’importe pas.

2. Un échantillon test (100–500 adresses)

Avant de charger 50 000 contacts : j’en teste 100–500. Je vérifie :

  • qu’ils reçoivent bien,
  • que les softs ne montent pas (throttling),
  • que les plaintes restent bas.

S’il y a un problème, je le vois à petite échelle.

3. Une restitution lisible (pas du jargon)

Je veux un mini-rapport que le marketing comprend :

  • % invalides, % risqués, top raisons (typo, domaine inexistant, jetable…),
  • répartition par domaine (Gmail/Outlook/Yahoo + top domaines B2B),
  • recommandations (cadence conseillée au démarrage, proposition de reconfirmation pour les risqués).

À ce stade, je n’ai pas parlé CRM, tables ni mappings. On reste dans l’opérationnel marketing : trier, décider, tester.

4. Cadence – démarrer sans froisser les FAI

Beaucoup d’imports “propres” finissent mal parce qu’on part trop vite. Or tous les FAI n’absorbent pas au même rythme. La troisième clé, c’est la cadence.

Plafonds par domaine

Je ne tire jamais plein pot. Je limite par exemple :

  • Gmail : 10–20k/h au démarrage, puis ramp-up si tout va bien.
  • Outlook / Yahoo : souvent plus sensibles → je démarre plus bas.
  • Gros domaines B2B : j’observe, puis j’augmente par paliers.

Étaler dans le temps

Plutôt que tout envoyer en 1 h, j’étale sur 4–6 h (ou plus). Lissée, la courbe de remise évite les vagues de 4.7.0 (soft “try again later”) et les files d’attente qui s’emballent.

Passer en gabarit léger au démarrage

Premiers envois = contenu sobre (pas de pièces jointes, images compressées, tracking propre). Inutile d’ajouter une contrainte technique à un moment sensible.

Surveiller en live ce qui compte

Pendant le premier tir :

  • Softs 4.7.0 par domaine (si > seuil, je baisse ce domaine, pas toute la campagne).
  • Hard (signe de lot douteux, ou d’un partenaire flou).
  • Latence de remise (files qui s’allongent = signal faible de throttling).

La Cadence transforme un import propre en montée en puissance maîtrisée, au lieu d’un crash-test.

5. Ce qui crée des bounces à l’import

Si je synthétise l’essentiel, côté import :

  • Adresses invalides (typos, domaines sans MX) → hard immédiats.
  • Comptes fermés (turnover B2B, boîtes abandonnées) → hard.
  • Jetables → finissent en hard et diluent l’engagement.
  • Lots partenaires sans preuve d’opt-in → plaintes et risque de spamtraps.
  • Démarrage plein gaz → softs 4.7.0 et réputation qui se tend.
  • Gabarit lourd au premier envoi → refus “message too large” chez des domaines stricts.

Chaque point se prévient par Collecte / Contrôle / Cadence. Si vous en avez déjà marre, ce n’est pas grave, cette trame des 3 C doit devenir un réflexe.

6. Mini-cas concrets (avant/après)

Partenaire “propre” mais non prouvable

Avant : 80 000 adresses, 0,8 % d’invalides mais aucune preuve d’opt-in. Premier envoi : plaintes à 0,35 % sur un FAI.
Après : on a exigé la preuve (formatée), placé la première exposition en parcours de reconfirmation, plafonné la cadence. Résultat : plaintes < 0,1 %, reputation stable.

Fichier historique “de retour”

Avant : relance d’un vieux fichier de 300 000 → hard 2,5 %, softs et throttling toute la matinée.
Après : preflight (tri valide/risqué/invalide), test sur 500, ramp-up par domaine, gabarit léger. Hard 0,7 %, softs résiduels, plus de throttle.

Import “nickel” mais gabarit trop lourd

Avant : lot validé, mais email de lancement à 1,8 Mo. Résultat : rejets “message too large” sur des domaines stricts.
Après : même lot, email 430 Ko, images compressées, pas de PJ → plus de rejet taille, et meilleures ouvertures.

7. Les 5 KPI à suivre les 72 premières heures (post-import)

Je m’impose une petite routine, ultra lisible :

  1. Hard bounces (objectif < 1 %)
  2. Softs 4.7.0 par domaine (si ça grimpe : on baisse la cadence pour ce domaine)
  3. Spam rate (plaintes) < 0,3 % absolu ; cible < 0,1 %
  4. Inbox rate (placement) — l’indicateur qui “paye” tout le reste
  5. CA / 1000 inboxés — la métrique business qui relie qualité d’import → revenu

Avec ces 5-là, on sait quoi faire : nettoyer, ralentir, alléger, ou… continuer tranquillement.

8. Côté technique, un process pour sécuriser l’essentiel

Promis, je reste light, mais ces points vous éviteront 80 % des galères “invisibles”.

1. Format & parsing du fichier

  • UTF-8 (refuser le reste).
  • Séparateur unique (, ou ;), guillemets échappés proprement.
  • Pas de retours chariot “cachés” dans les colonnes (sinon, colonnes décalées = emails cassés).
  • Schéma minimal obligatoire : email, source, optin_type, optin_at.

2. Normalisation de l’email (sans fantaisie)

  • Trim + suppression des espaces invisibles.
  • Lowercase du domaine (et de la locale si votre politique le décide).
  • IDN → punycode si besoin (accents dans les domaines).
  • Jamais de correction silencieuse : conservez l’original + la version normalisée.

3. Canonicalisation “provider-aware”

  • Gmail : les points dans la partie locale ne comptent pas, et +tag est ignoré à la remise. Vous pouvez canonicaliser pour éviter les doublons (ex : jean.dupont+promo → jeandupont).
  • Autres fournisseurs : ne supposez rien. Contentez-vous de normaliser proprement.

4. Triage automatique (valide / risqué / invalide)

  • Valide : passe en route principale.
  • Risqué : reconfirmation / cadence limitée.
  • Invalide : on n’importe pas.
  • Historique local : une adresse déjà hard-bouncée chez vous ne revient pas “par erreur”.

C’est tout. Le reste (mappings, rollback, etc.) relève de l’outillage interne : pas besoin d’en faire une usine à gaz pour importer proprement.

9. Ma checklists prêtes à l’emploi (spécial import)

Avant d’importer :

  •  Le fichier respecte un schéma minimal (email, source, opt-in, date).
  •  Preflight effectué → tri valide/risqué/invalide + rapport par domaine.
  •  Test sur 100–500 adresses OK.
  •  Cadence planifiée par FAI (plafonds, étalement).
  •  Gabarit léger pour le premier envoi.

Pendant le premier envoi :

  •  Suivi soft 4.7.0 par domaine, hard global, latence de remise.
  •  Si un domaine passe au rouge → baisse de sa cadence (pas globalement).
  •  Aucune pièce jointe, tracking simple.

72 h après :

  •  Hard < 1 % ; soft 4.7.0 stabilisés ; plaintes < 0,3 %.
  •  Inbox rate en hausse ou stable.
  •  Rapport par source : si un partenaire “fuit”, on agit maintenant (et on documente).
  •  CA / 1000 inboxés suivi (pour raconter l’impact business).

10. Comment l’API BounceStrike peut aider précisément sur l’import

L’API n’est disponible pour le moment uniquement en version « Real-Time ». Mais pour dérouler la méthode 3C sans friction je peux vous fournir rapidement, sur demande, un script pour automatiser les vérifications des CSV.

En clair : l’API vous permet de prévenir (Collecte), trier (Contrôle) et les clés pour piloter (Cadence) sans lever le petit doigt côté infra. Si vous voulez, on peut la brancher sur votre prochain lot pilote (ex. 30–50k adresses) en mode dry-run : vous aurez un rapport clair “avant/après” avec invalides bloqués, risqués en reconfirmation et la rampe conseillée par FAI pour le lancement.

Importer proprement, c’est appliquer les 3C

Quand je résume un plan d’import, je reviens toujours à ça :

  • Collecte : prouver l’opt-in, valider à la source, cadrer les partenaires.
  • Contrôle : trier avant d’ingérer (valide/risqué/invalide), tester à petite échelle.
  • Cadence : démarrer par domaine, étaler, envoyer léger, surveiller les 72 h.

Campagne après campagne, vos hard bounces vont retomber sous les seuils sains, vos softs se lisser, les plaintes se taire, l’inbox remonter. Et surtout : vous aurez un process prévisible, qui protège vos équipes et les revenus.