Quitter TinyURL : ce qui migre, ce qui reste, ce qui casse

Pour migrer depuis TinyURL, triez d'abord vos liens en deux piles : les liens sur un domaine que vous possédez, et les liens sur tinyurl.com. La première pile migre proprement, car vous changez un enregistrement DNS et les anciennes URL continuent de fonctionner. La seconde pile, vous ne pouvez pas la rediriger du tout, car TinyURL possède le domaine. Vous pouvez copier les destinations dans Elido, mais chaque endroit où un lien tinyurl.com/xxxx a été publié doit être mis à jour à la main.

Deuxième chose à savoir avant de commencer : pour l'instant, la voie fiable est un fichier. Exportez via l'appel documenté GET /urls/available de TinyURL, réduisez le résultat à destination, slug, title, et chargez-le avec l'import en masse d'Elido. Elido propose aussi un importeur TinyURL en un clic, mais il appelle un endpoint absent de l'API publiée de TinyURL ; nous le considérons donc comme non vérifié jusqu'à l'arrivée d'une correction prévue. Ce guide couvre les deux voies et tout le parcours : de l'export à l'analytique, avec la bascule et le retour arrière entre les deux. Les faits sur TinyURL viennent de son propre blog et de sa spécification OpenAPI, consultés les 2026-10-01 et 2026-10-02.

Pour un verdict fonction par fonction sur l'intérêt même de changer, lisez Elido vs TinyURL ou le tour d'horizon plus large des alternatives à TinyURL.

Quels liens TinyURL peuvent migrer

La propriété du nom d'hôte décide de tout. Un lien court, c'est deux choses : un nom d'hôte et un code. Vous pouvez emporter un code n'importe où, mais vous ne pouvez faire continuer un lien à fonctionner que si vous contrôlez le nom d'hôte.

La version honnête pour les deux premières lignes : une fois que vous cessez de payer TinyURL, ces liens continuent de se résoudre tant que TinyURL les garde, et vous n'avez aucun moyen de voir les clics, de les modifier ou de les rediriger. Certaines équipes les laissent volontairement en l'état. Je pense que c'est le bon choix pour les vieux liens à faible trafic.

Étape 1 : exporter vos liens TinyURL

TinyURL vous donne une seule façon documentée de lister vos liens : l'API. Sa spécification OpenAPI (consultée le 2026-10-02) définit la liste comme GET /urls/{type}, où type vaut available ou archived, avec des datetimes from et to facultatifs et un filtre search qui accepte un préfixe alias: ou tag:. L'appel exige un jeton bearer. Le propre article de TinyURL sur la liste des liens décrit le même endpoint et dit que le type est la seule entrée obligatoire.

Ce que la spécification ne donne pas compte autant. Elle ne définit ni paramètres page ou per_page, ni limites de débit. Pour un gros compte, restreignez donc chaque requête avec des fenêtres from/to (un mois à la fois, par exemple) et écrivez chaque réponse sur disque avant de faire quoi que ce soit d'autre :

# One window at a time; inspect the first response by hand before scripting further
curl -s -H "Authorization: Bearer $TINYURL_TOKEN" \
  "https://api.tinyurl.com/urls/available?from=2025-01-01T00:00:00Z&to=2025-02-01T00:00:00Z" \
  > tinyurl-2025-01.json

Nous n'avons pas vérifié la forme de la réponse en production (la spécification laisse flou si elle contient une liste ou un objet unique) : ouvrez donc un fichier et regardez avant d'écrire un parseur. Lancez le même appel sur /urls/archived si vous voulez aussi les liens archivés.

Trois limites façonnent la suite du plan :

• Pas de compte, pas de liste. TinyURL indique que les liens créés sans connexion ne peuvent être ni gérés ni supprimés. Il n'y a pas d'enregistrement par utilisateur, donc rien à exporter.
• L'offre gratuite est en lecture seule. Selon la page de l'offre gratuite de TinyURL, la modification et la suppression de liens, l'analytique de clics, les domaines personnalisés et la création en masse sont tous réservés aux offres payantes.
• L'analytique n'est pas dans la liste. L'historique de clics est à votre charge. Faites des captures ou sortez un rapport de TinyURL avant de résilier. Nous n'avons pas trouvé de bouton d'export CSV documenté dans le centre d'aide de TinyURL, donc ce guide n'en promet pas.

Étape 2 : faire correspondre les données TinyURL à un fichier qu'Elido accepte

Quoi que vous ayez extrait de TinyURL, réduisez-le aux trois mêmes champs :

• L'URL longue de TinyURL devient destination (la cible du lien).
• L'alias TinyURL devient slug. Laissez-le vide pour les liens sur tinyurl.com pour lesquels vous voulez de nouveaux codes.
• Le titre ou la description TinyURL devient title.

TinyURL les appelle alias, Elido les appelle slugs. Même chose : les caractères après l'hôte. Si votre domaine cible est vide, les alias passent tels quels.

La page des liens d'Elido a un onglet Bulk et un onglet CSV, et tous deux lisent des lignes de la forme url, slug, title. Dans l'onglet CSV, la première ligne est ignorée si elle ne contient pas d'URL http(s)://, donc une ligne d'en-tête ne pose pas de problème. Les lignes qui commencent par # sont ignorées dans la zone de collage. Les slugs personnalisés sont des lettres, des chiffres et des traits d'union : vérifiez donc les alias contenant d'autres caractères avant d'envoyer ; les lignes en échec sont listées avec une raison.

destination,slug,title
https://acme.com/spring-sale,spring-sale,Spring Sale
https://acme.com/pricing,,Pricing page

Si vous utilisiez des tags TinyURL, gardez-les. Ils ne tiendront pas dans le CSV à trois colonnes, mais la voie API ci-dessous les accepte.

Étape 3 : importer dans Elido

Il y a deux voies d'entrée. La voie fichier fonctionne aujourd'hui. L'importeur intégré existe mais n'est pas vérifié.

La voie fiable : CSV, collage en masse ou API en masse

Les onglets Bulk et CSV du tableau de bord traitent jusqu'à 100 liens par lot : découpez donc un fichier plus gros en morceaux. La page d'aide sur l'import en masse détaille le formulaire, et le tutoriel d'import en masse depuis Google Sheets est utile si vous avez nettoyé l'export dans un tableur.

L'API de l'espace de travail accepte la même forme en JSON. POST /v1/workspaces/{workspace_id}/links/bulk accepte un domain_id et jusqu'à 100 links, chacun avec destination_url et, en option, slug, title et tags. Chaque ligne est traitée séparément, donc une ligne défectueuse ne fait pas échouer le lot, et la réponse vous dit quelles lignes ont échoué. Ajoutez vous-même un tag tel que imported:tinyurl pour pouvoir filtrer le lot plus tard. API et SDK propose les bibliothèques clientes.

L'importeur TinyURL intégré, et son bug connu

Elido a un importeur TinyURL en un clic, décrit sur la page migrer depuis TinyURL. Vous collez un jeton d'API TinyURL, choisissez le domaine Elido où les liens doivent atterrir, et choisissez une stratégie de conflit. Le problème est le premier appel HTTP. Le worker construit cette requête :

GET https://api.tinyurl.com/aliases?page=1&per_page=100
Authorization: Bearer <token>

et attend en retour {"data": [{alias, url, title, tags}], "meta": {"total", "has_more"}}. La spécification de TinyURL n'a pas de chemin /aliases ; les opérations sur les alias vivent sous /alias/{domain}/{alias}, et la liste est /urls/{type}. Ce contrat de pagination n'a donc jamais été tiré de TinyURL. Notre test unitaire sert une réponse écrite à la main dans la forme supposée et passe, ce qui prouve que le parseur correspond à notre hypothèse et ne prouve rien sur TinyURL. Nous ne l'avons pas exécuté sur un compte réel, car cela demande un jeton d'offre payante. Ne planifiez pas encore une migration autour de lui.

La correction est prévue : passer à /urls/available (avec /urls/archived derrière un indicateur), parcourir par fenêtres from/to, analyser de façon défensive, et tester contre une vraie réponse capturée. Ensuite, la pagination et la vraie limite par requête devront être remesurées sur un compte réel, puisque la spécification ne donne ni l'une ni l'autre.

La page des intégrations dans un espace de travail DEMO avec des données synthétiques. La migration TinyURL se lance d'ici.

Ce que fait l'importeur une fois qu'il a une page

Tout ce qui suit l'appel HTTP ne dépend pas de la question de l'endpoint, et cette partie nous pouvons l'énoncer d'après le code.

• Démarrage. POST avec token, target_domain_id et conflict_strategy facultatif. Le gestionnaire rejette un jeton vide, un domaine manquant et toute stratégie hors de suffix, skip, fail, puis répond 202 avec le job et exécute le worker en arrière-plan, détaché de la requête.
• Par lien. Une ligne sans URL ou sans alias compte comme échec avec une raison. Sinon l'alias devient le slug, la destination et le titre sont copiés (titre tronqué à 200 caractères), et les tags sont copiés avec imported:tinyurl ajouté.
• Progression. Les compteurs sont écrits dans la ligne du job tous les 50 liens. Au plus 1 000 lignes d'erreur sont consignées par job.
• Erreurs d'authentification et de débit. Un 401 ou 403 fait échouer le job avec un message « check the bearer token », et un 429 le fait échouer comme limité en débit. Il n'y a ni nouvelle tentative ni backoff : le job s'arrête.

Le jeton va du corps de la requête au job d'arrière-plan et nulle part ailleurs. La ligne du job n'enregistre aucun jeton, et rien n'est chiffré au repos parce que rien n'est stocké. Le corps de la requête est lu avec une limite de 4 Ko. Le code ne valide pas le jeton ni ne vérifie l'offre avant de démarrer : un mauvais jeton apparaît donc comme un job en échec après la première requête, pas comme une erreur de formulaire. Des versions antérieures de notre documentation décrivaient un contrôle préalable sur un endpoint de domaines ; cette étape n'existe pas dans le code, et la spécification de TinyURL n'a pas non plus un tel chemin.

Règles de conflit et plafonds

Avant chaque insertion, le worker fait une recherche indexée pour le couple domaine et slug :

• suffix (par défaut) essaie alias-2, alias-3, jusqu'à alias-50, et fait échouer la ligne si tous sont pris.
• skip laisse le lien Elido existant tranquille et consigne la ligne source.
• fail fait échouer le job au premier conflit.

Chaque exécution est plafonnée à 50 000 liens et 30 minutes. Deux comportements méritent d'être connus. Quand le plafond de 50 000 est atteint, la boucle s'arrête simplement et le job se termine ; il n'échoue pas : comparez donc les compteurs finaux avec votre total source. Quand le budget de 30 minutes est épuisé, le job est marqué en échec avec le nombre importé jusque-là.

La liste des liens dans un espace de travail DEMO. Les liens importés portent le tag imported:tinyurl, ce qui permet de filtrer un lot pour le relire.

Tester l'importeur sans risque

Quand l'endpoint sera corrigé, ou si vous essayez l'importeur vous-même avant, faites-le en petit. Créez un espace de travail jetable, ajoutez un domaine vide, et lancez le job avec la stratégie fail d'abord. Un domaine vide signifie aucun conflit : tout échec est donc un problème d'analyse ou d'authentification plutôt qu'une collision. Comparez ensuite trois nombres : le compte source dans TinyURL, le total que rapporte le job, et les compteurs importés plus ignorés plus en échec. Comme le worker prend meta.total dans la réponse qu'il attend, un écart entre total et votre vrai compte est le premier signe que la forme de la réponse diffère de ce que suppose le parseur. Filtrez par imported:tinyurl, ouvrez dix liens au hasard et vérifiez destination, slug et titre contre TinyURL.

Démarrer un espace de travail Elido neuf pour cela prend quelques minutes ; créez un compte gratuit et ajoutez d'abord votre domaine pour qu'il soit prêt à la fin de l'import.

Étape 4 : basculer votre domaine personnalisé

Si vous exploitez un nom d'hôte de marque sur TinyURL, vous êtes dans le cas facile. La configuration de domaine de marque de TinyURL est un CNAME ou un changement DNS similaire sur un domaine que vous possédez déjà, donc le même levier fonctionne en sens inverse. Notez que l'importeur ne crée pas le domaine pour vous ni ne lit de champ domain de TinyURL. Un nom d'hôte de marque est une étape à part.

L'ordre compte, car le DNS est la dernière étape et la seule que les visiteurs ressentent :

1. Abaissez le TTL de l'enregistrement un jour à l'avance, pour que le changement soit rapide.
2. Ajoutez le nom d'hôte à Elido sous Domains et laissez-le se vérifier. Le guide ajouter un domaine donne les enregistrements exacts, et le dépannage de la vérification DNS couvre les fautes de frappe derrière la plupart des états « Pending » bloqués.
3. Importez les alias sur ce nom d'hôte pendant que les visiteurs atteignent encore TinyURL.
4. Vérifiez par échantillon les slugs importés contre l'ancien comportement du nom d'hôte en production.
5. Changez l'enregistrement DNS. À partir de cet instant, le nom d'hôte se résout vers Elido et chaque ancienne URL dessus suit.

Gardez le nom d'hôte en DNS seul, sans proxy CDN devant, car l'émission de certificat peut échouer derrière un proxy. La mise en place plus large est dans domaines personnalisés pour liens courts et sur la page de la fonction domaines personnalisés.

Étape 5 : garder vos redirections 301 intactes

Sur votre propre domaine, l'URL ne change pas, donc il n'y a rien à relier : le même chemin répond maintenant depuis Elido. Ce que vous protégez, c'est la sémantique de redirection. Les codes de statut de redirection sont définis dans la RFC 9110 ; une redirection permanente indique aux navigateurs et aux moteurs de recherche que la cible est stable, et passer des liens de longue durée en temporaire change la façon dont ils sont mis en cache et crédités. Lisez 301 vs 302 pour le versant SEO et cache.

Pour les liens tinyurl.com, il n'y a pas de 301 que vous puissiez ajouter, car la redirection appartient à TinyURL. Le mieux que vous puissiez faire est de vous assurer que la destination derrière l'ancien lien reste en vie, et de remplacer le lien partout où vous pouvez l'atteindre. Le playbook de migration Bitly montre comment fonctionne un pont 301 quand vous possédez l'ancien nom d'hôte.

Étape 6 : vérifier la migration

La migration est terminée quand chaque emplacement d'un lien pointe vers quelque chose que vous contrôlez. Suivez cette liste dans l'ordre.

1. Gelez les nouveaux liens dans TinyURL. Créez tout le neuf dans Elido à partir de maintenant.
2. Archivez les fichiers d'export TinyURL et tous les rapports, avec la date.
3. Filtrez le lot importé dans Elido par le tag imported:tinyurl.
4. Comparez les comptes. Importés plus ignorés plus en échec doivent égaler le nombre de lignes source.
5. Corrigez les échecs. Chaque ligne en échec vient avec une raison, généralement une URL invalide ou un mauvais caractère de slug.
6. Testez les liens principaux. Prenez vos 50 liens les plus importants et demandez-les un par un :

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://go.yourbrand.com/spring-sale

7. Comparez la destination à la source pour ces 50. Faites correspondre l'URL finale, paramètres UTM compris.
8. Retestez après le DNS depuis un réseau qui n'a pas mis l'ancien enregistrement en cache.
9. Mettez à jour les emplacements tinyurl.com. Cherchez tinyurl.com dans les archives d'e-mails, les bios sociales, les plateformes publicitaires et l'imprimé, et remplacez ce que vous pouvez.

Pour les surfaces que vous ne pouvez pas atteindre, acceptez la perte. Les anciens QR codes imprimés et les posts oubliés continueront de pointer vers TinyURL, et c'est vrai de toute migration de raccourcisseur. Migrer depuis Bitly sans casser de liens propose un passage de vérification plus strict si vous en voulez un.

Étape 7 : prévoir votre retour arrière

Gardez TinyURL un mois si vous le pouvez, et guettez les retardataires avant de résilier une offre payante. Tant que TinyURL sert encore les liens de votre nom d'hôte de marque, le retour arrière est un changement DNS vers l'ancien enregistrement, et le TTL bas le rend rapide.

Dans Elido, le tag imported:tinyurl est la poignée pour annuler un lot : filtrez, puis modifiez en masse ou supprimez. Si une exécution de l'importeur meurt en route (un déploiement ou un plantage l'arrête, et un balayage toutes les cinq minutes bascule en failed les jobs sans progression depuis 30 minutes), il n'y a pas de curseur sauvegardé : vous relancez le job. Relancer est sûr avec suffix ou skip, mais suffix créera des copies -2 des liens déjà écrits par la première exécution ; préférez donc skip pour une relance.

Étape 8 : fixer les attentes côté analytique

L'historique de clics ne passe par aucune des deux voies. L'importeur ne lit que les champs de liens, et un CSV n'a pas de colonne de clics. Les nouveaux clics comptent à partir du moment où un lien est actif dans Elido, ce qui, pour un domaine personnalisé, signifie à partir du changement DNS. Attendez-vous à une courte fenêtre où certains visiteurs atteignent encore TinyURL via des enregistrements en cache.

Restent aussi derrière : le style des QR et les modèles, ainsi que tout ce qui a été créé sans compte. Si vous suivez des campagnes, reportez dès maintenant vos conventions UTM ; les paramètres UTM expliqués est un bon rappel.

Ce que vous gagnez en changeant

Vous repartez avec des liens sur un nom d'hôte que vous possédez, de sorte que la prochaine migration, s'il y en a une, est un changement DNS plutôt qu'un projet. Vous obtenez aussi une analytique qui démarre à la bascule et un tag que vous pouvez interroger. La page des tarifs liste les offres, et Elido vs TinyURL propose le face-à-face. Pour la question plus large de ce qu'il faut considérer d'autre, l'article alternatives à TinyURL compare le paysage.

À lire aussi sur le blog

• Elido vs TinyURL
• Alternatives à TinyURL
• Bitly vs TinyURL
• Migrer depuis Bitly : le playbook
• Importer en masse des liens courts depuis Google Sheets
• Domaines personnalisés pour liens courts