Migrer de TinyURL : deux chemins et ce que chacun préserve

La migration depuis Bitly a un playbook bien rodé : export API, CSV, import en masse, basculement DNS. Le guide de migration Bitly couvre chaque étape. TinyURL est différent - pas plus difficile, mais différent d'une manière qui change la façon de planifier. La distinction qui compte le plus est de savoir si vous avez un compte TinyURL Pro. Cette seule variable divise la migration en deux procédures presque sans rapport.

Cet article parcourt les deux chemins et est honnête sur ce qui ne survit pas au déplacement.

TL;DR#

• Si vous avez un compte TinyURL Pro, l'API TinyURL vous permet d'énumérer et d'exporter vos liens. Le CSV inclut le slug, la destination et les comptes de clics sur 30 jours. Vous pouvez importer dans Elido proprement.
• Si vous n'avez pas de compte - vous avez juste publié des liens tinyurl.com/<slug> au fil des ans - il n'y a pas d'export. Vous reconstruisez la carte en scrapant vos propres surfaces publiées.
• Dans aucun des cas vous ne pouvez préserver les slugs originaux tinyurl.com sur votre espace de travail Elido. TinyURL possède le domaine. Vous générerez de nouveaux slugs sur votre propre domaine de marque court.
• La note réaliste : la plupart des utilisateurs TinyURL sont sur le palier gratuit. Pour eux, la migration concerne moins la portabilité des données et plus la mise à jour de chaque endroit où apparaît un lien TinyURL.

Ce qui rend la migration TinyURL différente de Bitly#

La différence structurelle clé est le domaine. Les utilisateurs Bitly sur des plans payants sont souvent sur un domaine de marque personnalisé - links.yourbrand.com - qu'ils possèdent. Lorsqu'ils migrent, l'enregistrement DNS pour ce domaine passe à pointer vers le edge d'Elido, et chaque slug existant continue de fonctionner. L'espace de slugs est le leur.

Les utilisateurs du palier gratuit TinyURL sont sur tinyurl.com. Ils ne possèdent pas ce domaine, et ils ne peuvent pas installer une redirection 301 dessus. Quand ils quittent TinyURL, les anciens liens ne suivent pas. Ils restent vivants sur tinyurl.com aussi longtemps que TinyURL tourne, mais l'équipe migrante n'a aucun contrôle dessus, aucune capacité d'intercepter les clics, et aucune chaîne 301 à mettre en place.

TinyURL Pro offre des domaines de marque personnalisés pour 9,99 $/mois (consulté le 12/05/2026). Si vous étiez sur Pro et utilisiez votre propre domaine, le chemin de migration est beaucoup plus proche du scénario Bitly : vérifiez le domaine dans Elido, pré-provisionnez les slugs, puis basculez le CNAME DNS. La documentation des domaines personnalisés couvre le côté Elido de ce basculement.

L'autre différence structurelle est le journal d'audit. TinyURL a une visibilité limitée des données historiques même sur Pro. La comparaison elido-vs-tinyurl couvre l'écart de fonctionnalités complet. Pour la planification de migration, l'implication pratique est que vous ne pourrez pas reconstruire un historique de clics complet. Ne budgétez pas pour cela.

Chemin A : vous avez un compte TinyURL Pro#

TinyURL Pro expose une API à https://tinyurl.com/app/dev (consulté le 12/05/2026). L'API prend en charge la création et la récupération d'alias. L'énumération fonctionne via des appels GET paginés qui renvoient vos liens par lots.

Les étapes :

1. Générez votre token API depuis les paramètres de l'app TinyURL.
2. Énumérez tous les alias, en paginant jusqu'au bout. TinyURL applique des limites de débit ; la documentation API spécifie le plafond de requêtes par minute. Construisez un handler de backoff avant de commencer - un 429 en milieu d'export est agaçant mais pas destructeur de données si vous avez écrit les résultats sur disque de manière incrémentale.
3. Pour chaque alias, collectez le slug, l'URL de destination et le compte de clics sur 30 jours. L'API TinyURL n'expose pas d'événements de clics bruts ou de séries temporelles historiques. Vous obtenez un agrégat.
4. Écrivez un CSV plat : une ligne par lien, colonnes slug,target_url,clicks_30d.
5. Triez par clicks_30d décroissant. Le top 1 % des liens par volume de clics est typiquement la fraction qui compte vraiment pour les campagnes en cours ou le contenu publié. Priorisez ceux-là pour la validation et les mises à jour de surfaces. La longue traîne des liens à zéro clic peut être importée mais nécessite rarement une attention humaine.

Une fois le CSV en main, l'import vers Elido suit la même forme que toute autre migration en masse. Les mécaniques d'import en masse détaillées sont dans le playbook de migration Bitly - la forme de l'API et l'appel du SDK TypeScript sont identiques ; seules les données sources diffèrent.

La chaîne 301 pour les domaines de marque sur Pro#

Si votre compte TinyURL Pro utilisait un domaine de marque personnalisé, vous pouvez porter ce domaine vers Elido. Enregistrez-le dans votre espace de travail Elido via le flux de domaines personnalisés, pré-provisionnez tous les slugs, puis changez le CNAME :

short.yourbrand.com.  300  IN  CNAME  edge.elido.me.

La sémantique HTTP 301 s'applique ici : une fois que le CNAME se résout vers le edge d'Elido, les navigateurs et bots qui suivent les anciens liens recevront une réponse 301 Moved Permanently d'Elido pointant vers l'URL de destination. Aucun saut de redirection via TinyURL n'est requis parce que l'espace de slugs était sur votre domaine, pas sur tinyurl.com. C'est le chemin propre.

La norme pertinente est RFC 7231 §6.4.2, qui définit la sémantique 301 Moved Permanently. Le client recevant un 301 devrait mettre à jour toute URL stockée vers le nouvel emplacement. En pratique, les clients email et les plateformes sociales varient dans la rigueur avec laquelle ils suivent cela - mais la redirection elle-même est fiable pour les navigateurs web et pour les bots qui respectent la spec HTTP.

Chemin B : pas de compte, juste des liens publiés#

C'est le scénario le plus courant. Vous avez un compte TinyURL gratuit ou pas de compte, et vous avez une collection de liens tinyurl.com/<slug> publiés à travers votre archive de newsletters, vos posts sociaux, vos supports imprimés ou votre documentation. Vous n'avez pas d'accès API ni de mécanisme d'export. Les liens existent ; vous n'en avez pas de liste.

La seule façon de construire l'inventaire est de chercher dans vos propres surfaces publiées.

Trouver les liens#

Travaillez à travers chaque surface systématiquement :

• Archive email/newsletter : recherchez dans l'archive de votre plateforme email pour tinyurl.com. La plupart des plateformes vous permettent de rechercher à travers les campagnes envoyées. Exportez les correspondances.
• Réseaux sociaux : recherchez dans vos posts Twitter/X, LinkedIn et Facebook les liens tinyurl.com. La plupart des plateformes ont un export de contenu au niveau du compte. Téléchargez-le et grep-ez.
• Site web et documentation : lancez une recherche site ou un crawl. grep -r "tinyurl.com" ./content sur un repo de site statique prend des secondes.
• Liens de suivi de plateformes pub : vérifiez les liens taggés UTM dans Google Ads, Meta Ads Manager, ou partout où vous avez lancé des campagnes payantes.

Une fois que vous avez la liste des valeurs tinyurl.com/<slug>, vous avez besoin des URL de destination. Si vous avez créé les liens vous-même et pouvez vous souvenir de la destination, parfait. Sinon : suivez chaque lien manuellement ou avec un script qui émet une requête HEAD et lit l'en-tête Location. La redirection TinyURL elle-même est accessible publiquement - vous n'avez pas besoin d'un compte pour résoudre où va un lien tinyurl.com.

# Bulk-resolve TinyURL destinations from a file of slugs (one per line)
while IFS= read -r slug; do
  dest=$(curl -s -o /dev/null -w "%{redirect_url}" \
    -L --max-redirs 0 "https://tinyurl.com/${slug}" 2>/dev/null || echo "FAILED")
  echo "${slug},${dest}"
done < tinyurl-slugs.txt > slug-target-map.csv

Cela vous donne le CSV slug,target_url dont vous avez besoin pour l'import. Notez que vous importerez avec de nouveaux slugs sur votre propre domaine - plus à ce sujet ci-dessous.

Accepter ce que vous ne pouvez pas récupérer#

Pour les liens publiés dans des contextes auxquels vous n'avez plus accès - un compte social d'un emploi que vous avez quitté, un post communautaire sur une plateforme que vous avez supprimée - il n'y a pas de chemin de récupération. Ces vieux liens tinyurl.com continueront à fonctionner aussi longtemps que TinyURL restera opérationnel, mais vous n'avez aucune capacité de les mettre à jour, de les rediriger via Elido, ou d'observer qui clique dessus. Acceptez cela et passez à autre chose. Migrer ce que vous pouvez trouver est la bonne décision ; la perfection n'est pas atteignable ici.

Importer dans Elido#

Quel que soit le chemin qui a généré votre CSV, l'appel d'import est le même. La distinction clé est ce que vous mettez dans le champ slug.

Si vous avez un domaine de marque personnalisé : vous pouvez tenter de préserver les slugs du Chemin A. Enregistrez d'abord votre domaine dans Elido, puis passez slug explicitement dans le corps de l'import en masse. La forme de l'appel :

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: tinyurl-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "original-slug",
        "destination_url": "https://your-long-destination.com/path",
        "tags": ["tinyurl-migrated"]
      }
    ]
  }'

Le domain_id doit faire référence à un domaine déjà enregistré et vérifié dans votre espace de travail. L'endpoint accepte jusqu'à 100 liens par appel et renvoie un statut succès/échec par item - un conflit de slug sur une ligne n'interrompt pas le batch.

Si vous étiez sur tinyurl.com/ sans domaine personnalisé : omettez le champ slug ou passez null. Elido générera un slug pour chaque lien. Acceptez le changement de slug. Les anciens liens tinyurl.com ne redirigent pas vers vos nouveaux liens Elido - il n'y a pas de chaîne 301 que vous puissiez installer parce que vous ne possédez pas tinyurl.com. La seule façon de reconnecter le trafic est de mettre à jour chaque surface publiée qui contient l'ancien lien. C'est le travail.

La limitation de la chaîne 301 pour les liens sans marque#

Cela mérite une déclaration directe. Le guide migrate-from-bitly-without-breaking-links couvre le pattern de pont 301 en détail pour les migrations Bitly. Ce pattern suppose que vous contrôlez le domaine d'origine. Pour les liens tinyurl.com, vous ne le faites pas.

Il n'y a pas de mécanisme que TinyURL expose pour installer une redirection depuis un tinyurl.com/<slug> existant vers une nouvelle destination. Le lien continue de se résoudre là où il pointait quand vous l'avez créé. Si vous voulez que le trafic qui allait à tinyurl.com/abc123 atterrisse plutôt sur votre nouveau lien Elido, vous avez deux options :

1. Mettre à jour chaque surface publiée pour utiliser le nouveau lien Elido. C'est l'approche correcte.
2. Laisser le lien TinyURL pointer vers la destination et laisser Elido ne gérer que les liens futurs. Acceptable si les anciens liens sont peu utilisés et pas critiques pour l'activité.

L'option 2 n'est pas vraiment de la « migration » - c'est de la coexistence. Pour la plupart des équipes, la combinaison des deux a du sens : migrer entièrement la création de nouveaux liens vers Elido, mettre à jour les anciennes surfaces à plus fort trafic, et laisser la longue traîne des anciens liens TinyURL à zéro clic décliner sans effort.

Validation#

Après import, vérifiez que ce qui compte fonctionne vraiment.

Prenez votre CSV trié et tirez les 50 premières lignes par volume de clics (depuis le Chemin A) ou par date de publication et taille d'audience (depuis le Chemin B, où vous estimez l'importance). Pour chacun de ces liens :

1. Si vous étiez sur un domaine de marque personnalisé et avez préservé les slugs : testez que https://short.yourbrand.com/<slug> se résout vers la bonne destination. Le tableau de bord d'Elido montre le statut 200 vs erreur. Alternativement, lancez une vérification curl :

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://short.yourbrand.com/your-slug"

2. Si vous avez généré de nouveaux slugs : vérifiez que les URL de destination dans le tableau de bord Elido correspondent à votre CSV source. La réponse de l'import inclut un statut succès/échec par item ; examinez le journal des échecs avant de clore la migration.

3. Vérifiez vos envois de newsletter récents à forte ouverture et vos posts sociaux récents. S'ils contiennent des liens TinyURL et que vous les avez mis à jour en liens Elido, vérifiez que les liens mis à jour fonctionnent. Si vous ne les avez pas mis à jour - notez-les explicitement. Ce sont les liens les plus susceptibles d'avoir un trafic de clics actif que vous laissez hors de votre analytique.

Pour toute surface que vous avez mise à jour, confirmez que la mise à jour a effectivement atteint la version publiée. Une newsletter reprogrammée avec d'anciens liens, un tweet édité, un article d'aide mis en cache par un CDN - ce sont les endroits où la mise à jour n'atterrit pas immédiatement.

La note réaliste sur les slugs que vous ne pouvez pas garder#

La version brutale : si vous étiez sur le palier gratuit de TinyURL et publiez des liens tinyurl.com/<slug>, vous ne migrez pas un espace de slugs. Vous migrez une liste d'URL de destination et repartez à neuf sur Elido avec de nouveaux slugs sur votre propre domaine. Les anciens liens tinyurl.com existent à perpétuité sur l'infrastructure de TinyURL. Vous ne pouvez pas les mettre à jour, les rediriger, ou tirer de l'analytique d'eux après avoir cessé d'utiliser le compte.

Ce n'est pas un échec du processus de migration. C'est l'attente correcte. Le palier gratuit de TinyURL n'a jamais été une plateforme de gestion de liens - c'était un utilitaire de raccourcissement. Le quitter signifie accepter que le travail que vous y avez investi est largement irrécupérable du point de vue de la portabilité des slugs.

Ce que vous gagnez est ce qui vient après : des liens courts de marque sur un domaine que vous possédez, une analytique de clics qui ne s'arrête pas à une fenêtre de 30 jours, et un modèle de tarification qui scale sans vous surprendre. Le travail de migration est un coût ponctuel. L'outillage amélioré est continu.

Si vous évaluez si Elido est la bonne destination avant de vous engager sur le travail de migration, la comparaison elido-vs-tinyurl couvre l'écart de fonctionnalités et de conformité en détail.

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