Quand on change d'outil, la première question est toujours la même : comment je transfère ce qu'il y a dedans. C'est la mauvaise question. Je viens de déplacer l'emailing de Grabloop vers un autre outil, et la décision qui a tout débloqué a été de ne presque rien reprendre. Pas par paresse. Parce que la migration était exactement ce qui allait reproduire ce que je cherchais à quitter.
Importer l'existant, c'est importer la dette
Un outil qu'on veut quitter contient rarement un patrimoine. Il contient des couches : des tags créés un soir pour un test, des segments dont personne ne sait plus ce qu'ils filtrent, deux automatisations à moitié branchées qu'on n'ose pas couper, des contacts qui n'ont rien ouvert depuis des mois.
Tout ça, tu ne le vois plus. C'est le propre de ce qu'on a construit par couches : ça devient le décor. Mais une migration le rend visible d'un coup, et tu passes tes premières semaines dans le nouvel outil à arbitrer des choix que tu as faits il y a deux ans dans un contexte qui n'existe plus.
Le résultat est assez prévisible : trois semaines après la bascule, le nouvel outil ressemble à l'ancien. Tu as payé l'abonnement, le temps de la migration, et tu as gardé le problème.
Ce qui se migre, ce qui reste
La ligne de partage n'est pas « important » ou « pas important ». Elle est plus simple que ça.
Tu emportes :
- Ce que la loi ou la compta t'oblige à conserver — factures, contrats, historiques de commande. Ça ne se discute pas.
- Ce qui produit de la valeur maintenant. La séquence qui convertit cette semaine, le modèle que tu utilises à chaque envoi. Pas celle que tu comptes réactiver un jour.
- Les données brutes que tu ne peux pas reconstruire. Un historique client, une base de contenus, un corpus. Ce sont des actifs, pas des réglages.
Tu laisses :
- Les tags, segments et étiquettes. Ce sont des interprétations, pas des données. Elles se refont en dix minutes sur des critères à jour.
- Les automatisations. Un scénario est lié à l'outil qui l'exécute. Le recopier, c'est traduire mot à mot : tu obtiens quelque chose qui tourne et que personne ne comprend.
- Les archives « je nettoierai plus tard ». Plus tard n'arrive jamais, et surtout pas pendant une migration.
Une liste d'emails n'est pas un fichier, c'est un consentement
C'est le cas où reprendre l'existant fait le plus de dégâts, et celui où on y pense le moins.
Importer une liste dans un nouvel expéditeur ne transfère pas l'engagement. Tu arrives avec un domaine qui n'a pas d'historique, une adresse d'envoi que personne n'a jamais vue, et une base dont une partie a oublié jusqu'à son inscription. Les premiers envois décident de ta réputation d'expéditeur pour longtemps.
Ce que j'ai retenu : reconstituer vaut mieux que transférer. Une liste par source, et un premier message qui dit d'où tu as leurs coordonnées et ce que tu comptes envoyer, avec une sortie évidente. Ceux qui restent sont une base vivante. Ceux qui partent allaient de toute façon ne jamais ouvrir, et t'auraient coûté bien plus cher en délivrabilité qu'en volume.
Mieux vaut une liste trois fois plus petite dont chaque adresse a dit oui à cet envoi-là.
Sur le volet réglementaire, le consentement se rattache à une finalité et à un responsable de traitement, pas à un outil : changer de prestataire ne te dispense pas de vérifier sur quelle base tu écris. Je te le donne comme repère général, ce n'est pas un avis juridique.
Repartir de zéro ne veut pas dire repartir sans rien
Ce qui se transfère vraiment dans un changement d'outil, ce ne sont pas les objets. Ce sont les décisions.
Avant d'ouvrir le nouvel outil, écris trois choses : la promesse de ce que tu envoies, la structure des listes que tu veux vraiment, et les conventions de nommage. Une page suffit. Sans ça, tu vas recréer l'arborescence de l'ancien outil par simple habitude de la main.
Deux garde-fous qui m'ont servi :
- Ne ferme pas l'ancien outil, rétrograde-le. La plupart ont un palier gratuit qui garde l'accès en lecture. Tu récupères au cas par cas pendant quelques semaines, au lieu de tout rapatrier par peur de perdre quelque chose.
- Mets une date de fin à cette période. Un double accès sans échéance, ce sont deux outils en service et plus aucune source de vérité.
Le test à faire avant de cliquer sur « Importer »
Pour chaque chose que tu t'apprêtes à migrer, pose une seule question : si elle n'existait pas, est-ce que je la recréerais aujourd'hui, telle quelle ?
Si la réponse est non, elle ne passe pas. Tu n'es pas en train de la perdre, tu es en train de refuser de la payer une deuxième fois.
Et cette question ne vaut pas que pour un changement d'outil. Un CRM qu'on reprend d'un prédécesseur, un Notion hérité, une arborescence de dossiers qui traîne depuis trois ans : à chaque fois, le vrai travail n'est pas de transférer. C'est de décider ce qui mérite de continuer.