Migrer de Rebrandly : transfert de domaine de marque sans perte de slug

Rebrandly est construit autour d'une seule abstraction centrale : le domaine de marque. Les slashtags, les taxonomies de tags et les règles Traffic Routing sont tous suspendus à elle. Ce choix de conception est ce qui fait de Rebrandly un produit cohérent, et c'est aussi ce qui rend la migration différente de tout autre déplacement de raccourcisseur.

Lorsque vous quittez Rebrandly, vous ne migrez pas principalement des liens. Vous migrez un domaine. Les liens suivent au passage, et les détails de la façon dont vous les préservez dépendent presque entièrement de ce que vous décidez de faire avec le domaine.

Cet article couvre les deux chemins réalistes, la forme de l'export depuis l'API Rebrandly, l'appel d'import en masse vers Elido et le processus de validation avant d'annoncer le basculement.

TL;DR#

• L'abstraction centrale de Rebrandly est le domaine de marque. La migration est d'abord un transfert DNS, ensuite une préservation des liens.
• Chemin A : le domaine reste le même, seul le raccourcisseur change. Pré-provisionnez les slugs sur Elido, basculez le CNAME, c'est fini.
• Chemin B : le domaine change aussi. Vous avez besoin soit d'une chaîne 301 depuis l'ancien domaine (palier Rebrandly Pro), soit vous acceptez un changement de slug sur le nouveau domaine.
• Les tags Rebrandly se mappent proprement aux tags Elido. Les catégories Rebrandly nécessitent un mapping manuel - elles n'ont pas d'équivalent direct.

Ce que vous devez inventorier d'abord#

Avant de vous engager sur l'un ou l'autre chemin, faites l'état des lieux de quatre choses.

Domaine ou domaines de marque. Le modèle d'espace de travail de Rebrandly permet plusieurs domaines personnalisés par compte. Sur un espace de travail agence ou multi-marques, chaque domaine est une unité de migration distincte. Énumérez-les avant de planifier les fenêtres de basculement - un domaine par nuit est un calendrier plus sûr que tous d'un coup.

Liens actifs. Utilisez l'API REST Rebrandly (consultée le 12/05/2026) plutôt que l'export CSV pour les grands inventaires. L'endpoint /v1/links pagine avec les paramètres de requête last et limit et renvoie l'objet lien complet incluant le slashtag, la destination, le nom de domaine, le jeu de tags et createdAt. L'export CSV depuis le panneau des paramètres de l'espace de travail convient pour quelques centaines de liens mais tronque les champs de manière incohérente sur les exports plus grands.

Intégrations. Si votre équipe crée des liens via des workflows Zapier, Make ou Workato, ces connecteurs pointent vers l'API Rebrandly. Chacun doit être repointé. C'est une tâche distincte de la migration des liens avec sa propre fenêtre de grâce. Couvrez-la après le basculement DNS, pas avant.

Taxonomie des tags et catégories. Rebrandly prend en charge à la fois les tags libres et les catégories structurées. Les tags se mappent un-pour-un aux tags Elido. Les catégories n'ont pas d'équivalent direct dans Elido - le mapping le plus proche est un préfixe de tag réservé (cat:campaign, cat:region) que vous appliquez lors de l'import. Convenez du mapping avant de lancer le script, pas après.

Chemin A : le domaine reste, le raccourcisseur change#

C'est la migration la plus propre. Vous gardez go.acme.com (ou quel que soit votre domaine de marque court). Vous pré-provisionnez chaque slug sur Elido sous ce même domaine, puis basculez le CNAME. Du point de vue du clic du lien, rien ne change - le slug se résout vers la même URL de destination, juste via un edge différent.

Étape 1 : exporter depuis Rebrandly#

Parcourez l'API Rebrandly /v1/links paginée. Les objets de réponse incluent slashtag, destination, domain.fullName, tags[], category.name et createdAt. Persistez en JSONL.

Deux choses à gérer soigneusement. Premièrement, domain.fullName - si votre espace de travail a plus d'un domaine, filtrez vers celui que vous migrez dans ce passage. Deuxièmement, les paliers de tarification Rebrandly (consultés le 12/05/2026) régulent combien de liens et combien de domaines personnalisés sont actifs par compte. L'API renvoie tous les liens indépendamment ; votre inventaire peut inclure des liens sur des domaines que vous avez déjà retirés. Filtrez-les avant l'import.

Étape 2 : pré-provisionner sur Elido#

Enregistrez le domaine dans votre espace de travail Elido via le flux de domaines personnalisés avant de toucher au DNS. Le domaine n'a pas besoin d'être en service. Elido valide la propriété du domaine via un enregistrement TXT DNS ; vous pouvez accomplir cela sans perturber le CNAME existant pointant vers Rebrandly.

Une fois le domaine enregistré, importez en masse les liens. L'endpoint POST /v1/links/bulk accepte jusqu'à 100 liens par appel et renvoie un statut succès/échec par item, donc un conflit de slug sur une ligne n'interrompt pas le batch. Passez slug explicitement pour préserver le slashtag Rebrandly. Mappez les tags[] Rebrandly directement aux tags[] Elido. Passez created_at pour préserver l'horodatage de création d'origine pour le tri historique.

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rebrandly-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "summer-promo",
        "destination_url": "https://acme.example/summer",
        "tags": ["campaign", "q3", "rebrandly-migrated"],
        "created_at": "2025-07-01T09:00:00Z"
      },
      {
        "slug": "hero-cta",
        "destination_url": "https://acme.example/hero",
        "tags": ["homepage", "rebrandly-migrated"],
        "created_at": "2025-03-15T14:30:00Z"
      }
    ]
  }'

Le tag rebrandly-migrated est utile pour le filtrage analytique après basculement - vous pouvez segmenter les liens pré-migration des liens créés nativement sur Elido et comparer les tendances de clics sur les 30 premiers jours.

Pour le mapping de la taxonomie des catégories : si summer-promo vivait dans une catégorie Rebrandly nommée Campaigns, ajoutez cat:campaigns au tableau tags. Ce n'est pas sémantiquement équivalent, mais cela vous donne un filtre dans l'analytique et les vues de tableau de bord d'Elido. Documentez le mapping dans vos notes de migration.

Faites d'abord un dry-run. La plupart des équipes lancent l'import en masse contre un espace de travail de staging ou avec un petit échantillon (10-20 liens) avant d'envoyer l'inventaire complet. La surface de réponse par item dans l'endpoint en masse montrera tous les conflits de slug ou erreurs de validation de destination proprement avant que vous ne vous engagiez sur tout l'export.

Étape 3 : basculement DNS#

C'est le moment. Avant d'arriver ici, vérifiez ce qui suit :

• Tous les slugs dans l'import en masse ont renvoyé un statut succès. Aucun échec en suspens.
• Le domaine est enregistré et TLS est provisionné dans votre espace de travail Elido. Testez un slug directement contre le edge Elido en ajoutant temporairement le CNAME à un sous-domaine de test, pas votre production.
• Le TTL CNAME Rebrandly existant a été abaissé. La page tarifaire Rebrandly (consultée le 12/05/2026) montre que la configuration DNS est disponible à partir du palier Free - vous pouvez abaisser le TTL sans monter en gamme. Abaissez-le à 300 secondes au moins 24 heures avant la fenêtre de basculement.

Quand la fenêtre s'ouvre, échangez la cible du CNAME :

go.acme.com.  300  IN  CNAME  edge.elido.me.

Le edge d'Elido utilise le TLS automatique à la demande. Si TLS a déjà été provisionné lors de la pré-validation (recommandé), la première requête après propagation DNS est rapide. Sinon, le cert se provisionne à la première requête - typiquement 1-3 secondes, puis le certificat met en cache et les requêtes suivantes sont servies à un p95 sous 15ms depuis le edge en région UE.

Vérifiez depuis plusieurs résolveurs avant de fermer la fenêtre de changement. Un contrôle de propagation depuis votre bureau ne confirme que votre résolveur. Des outils comme dig @8.8.8.8 go.acme.com CNAME et dig @1.1.1.1 go.acme.com CNAME attrapent la divergence courante.

Chemin B : le domaine change aussi#

Certaines équipes profitent de la migration pour renommer le domaine de marque - de brand.ly (un sous-domaine attribué par Rebrandly) à quelque chose qu'elles possèdent pleinement, ou d'un domaine de marque à un autre après un rebranding. D'autres étaient sur le sous-domaine Rebrandly (yourname.rebrandly.com) et n'ont jamais configuré de domaine personnalisé du tout.

Dans les deux cas, l'espace de slugs change. La question est de savoir si vous pouvez installer une chaîne 301 depuis l'ancien domaine pour minimiser la casse des liens.

Option B1 : chaîne 301 depuis l'ancien domaine Rebrandly#

La fonctionnalité Traffic Routing de Rebrandly - disponible sur le palier Pro - vous permet de rediriger un domaine entier vers une nouvelle URL de base. Si vous possédez l'ancien domaine et voulez transférer le trafic, vous pouvez configurer une redirection wildcard dans Rebrandly qui transfère toutes les requêtes go.old-domain.com/* vers go.new-domain.com/* avec correspondance de slug.

RFC 7231 §6.4.2 définit la sémantique 301 Moved Permanently : les clients qui reçoivent un 301 doivent mettre à jour toute URL stockée vers le nouvel emplacement. En pratique, cela signifie que les codes QR existants, les supports imprimés et les liens publiés redirigeront correctement pendant la période de chevauchement. C'est le plus près que vous puissiez vous approcher d'une migration transparente lorsque le domaine change.

Les mécaniques : gardez l'ancien domaine en service sur Rebrandly pendant la période de chevauchement, configuré comme redirecteur pass-through. Faites tourner le nouveau domaine sur Elido depuis le jour un de la migration. Après 30-90 jours (selon la durée pendant laquelle vos supports publiés restent en circulation), désactivez l'ancien domaine sur Rebrandly.

Option B2 : accepter le changement de slug#

Si l'ancien domaine était un sous-domaine attribué par Rebrandly (yourname.rebrandly.com) ou un domaine sur lequel vous n'avez plus le contrôle DNS, aucune chaîne 301 n'est disponible. Les liens sur l'ancien domaine continueront de fonctionner aussi longtemps que Rebrandly tournera et que vous garderez le compte actif. Le trafic sur ces vieux liens ne passe pas par Elido ; vous perdez la couverture analytique dessus.

L'approche pratique : migrer la liste de liens vers Elido sur un nouveau domaine, créer de nouveaux slugs pour les liens à plus fort trafic et mettre à jour les surfaces publiées qui comptent, et laisser la longue traîne des anciens liens à faible trafic décliner sur Rebrandly. Le migrate-from-bitly-playbook couvre le même cadre de décision pour les migrations Bitly - le raisonnement s'applique ici.

Pour les équipes qui décident entre l'option B1 et B2, le calcul est : combien de surfaces publiées contiennent les anciens liens, à quel point sont-elles difficiles à mettre à jour, et combien de temps le trafic continuera-t-il d'arriver sur ces surfaces. Les liens d'archive email à fort trafic et les supports imprimés plaident pour B1. Quelques documents internes plaident pour B2.

Export Rebrandly : ce que vous obtenez et ce que vous n'obtenez pas#

L'API Rebrandly (consultée le 12/05/2026) exporte les champs suivants par lien via /v1/links :

• id - l'ID interne du lien Rebrandly (pas nécessaire à l'import mais utile comme clé d'idempotence)
• slashtag - le slug à préserver
• destination - l'URL de destination complète incluant les paramètres UTM
• domain.fullName - le nom d'hôte du domaine personnalisé
• tags[] - tags libres ; se mappent directement aux tags Elido
• category.name - étiquette de catégorie ; à mapper manuellement à un préfixe de tag
• createdAt, updatedAt - horodatages ; passez createdAt au champ created_at d'Elido
• clicks.total - compte de clics à vie ; pas importable dans l'analytique Elido, mais à stocker dans un tag (clicks-baseline-1234) ou dans votre propre couche de données

Ce que l'API n'exporte pas :

• Événements de clics bruts. Rebrandly n'expose pas d'enregistrements par clic - vous n'obtenez que des comptes agrégés. L'horloge analytique repart à zéro sur Elido à partir du jour du basculement.
• Règles de Traffic Routing. Si vous avez configuré des redirections conditionnelles sur certains liens (routage par appareil ou géo), ces règles doivent être recréées manuellement dans l'éditeur de smart link d'Elido après import. Il n'y a pas d'import en masse des règles de routage.
• Permissions des membres de l'équipe. L'accès à l'espace de travail doit être ré-invité sur Elido.

L'absence d'événements de clics bruts est la même contrainte que vous rencontrez en migrant de Bitly sans casser les liens. Le pattern pour la gérer est le même : stocker le compteur à vie de Rebrandly, suivre les clics Elido à partir du basculement, et les combiner lors du reporting des totaux historiques.

Recâblage des webhooks : Zapier, Make, Workato#

Si l'un de vos workflows d'automatisation crée des liens Rebrandly, ceux-ci doivent être repointés : un déclencheur CRM qui frappe un lien de suivi par prospect, un Zap qui raccourcit des liens depuis une feuille de calcul, un scénario Make qui génère des codes QR pour des événements.

Le mécanisme diffère par plateforme. Sur Zapier, trouvez chaque Zap qui utilise l'app Rebrandly et remplacez l'étape d'action soit par l'app Zapier Elido (vérifiez la disponibilité au lancement), soit par une action Webhook qui appelle directement POST /v1/links. Sur Make et Workato, la même substitution s'applique.

Deux choses à séquencer correctement ici. Premièrement, ne repointez pas les automatisations avant que le basculement DNS et l'import en masse soient confirmés. Faire tourner les automatisations contre Elido avant que le pré-provisionnement ne soit terminé crée des conflits de slug doublons. Deuxièmement, ajoutez la clé API Elido au magasin d'identifiants de chaque plateforme d'automatisation avant le basculement - faites-le à l'avance, pas pendant la fenêtre de basculement.

La fenêtre de grâce : pour toute automatisation qui crée des liens à faible fréquence (quelques par semaine), la laisser sur Rebrandly pendant 1 à 2 semaines après le basculement DNS est à faible risque. Les liens qu'elle crée seront sur l'ancienne plateforme mais le DNS est déjà basculé, donc ces liens se résoudront via Elido. Pour les automatisations à haute fréquence créant des dizaines de liens par jour, migrez-les au jour du basculement.

Pour l'API et les SDK disponibles d'Elido, la page tarifaire couvre les limites de plan, et la référence API complète est à /help. Les SDK TypeScript, Python et Go sont disponibles.

Validation avant d'annoncer le basculement#

N'annoncez pas la fin de migration tant que vous n'avez pas fait un spot-check structuré. Deux choses cassent silencieusement : les URL de destination qui avaient des problèmes d'encodage dans l'export, et les slugs qui sont entrés en collision pendant l'import en masse et ont été sautés.

Vérification des 100 premiers slugs#

Triez votre liste de liens exportée par clicks.total décroissant. Prenez les 100 premiers. Pour chacun, émettez une requête HEAD contre l'URL hébergée sur Elido et vérifiez que l'en-tête Location correspond à la destination attendue :

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://go.acme.com/summer-promo"

Une réponse 301 avec l'URL de destination correcte confirme que le slug fonctionne. Un 404 signifie soit que le slug n'a pas été pré-provisionné (vérifiez le journal de réponse de l'import en masse), soit qu'il y a eu un décalage de sensibilité à la casse. Les slashtags Rebrandly sont insensibles à la casse à la résolution ; les slugs Elido sont sensibles à la casse à la création. Si votre export a des slashtags en casse mixte, normalisez en minuscules avant l'import.

Plan de rollback de 30 jours#

Gardez le compte Rebrandly actif pendant 30 jours après le basculement DNS. Le changement DNS est entièrement réversible à tout moment pendant cette fenêtre - pointez le CNAME vers le edge de Rebrandly et les anciens liens fonctionnent à nouveau. Après 30 jours, si l'analytique ne montre aucune anomalie dans le taux de succès des redirections et que la vérification des slugs est passée, le compte Rebrandly peut être rétrogradé ou annulé en toute sécurité.

Pour le domaine : ne transférez pas le registrar du domaine ailleurs qu'où il est actuellement pendant la fenêtre de migration. Le changement de CNAME est la seule chirurgie DNS requise. Un transfert de registrar ajoute un risque de propagation inutile pendant le basculement.

Contexte de migration interne#

Les mécaniques de cette migration parallèlent le playbook Bitly. Les patterns DNS, le timing du TTL et l'approche de préservation des slugs sont les mêmes. Si vous évaluez le déplacement au niveau des fonctionnalités avant de vous engager sur le travail de migration, la comparaison elido-vs-rebrandly couvre les différences de modèle de tarification et l'écart de résidence UE en détail. La documentation de configuration des domaines personnalisés à /features/custom-domains couvre le côté Elido de la vérification DNS et du provisionnement TLS. Et /pricing a les limites de palier actuelles - pré-provisionner un grand inventaire Rebrandly exige le bon plan avant de commencer à importer.

---

Citations : Documentation API Rebrandly consultée le 12/05/2026. Page tarifaire Rebrandly consultée le 12/05/2026. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.