Changer d’hébergeur de podcast sans perdre un seul abonné

Quand on change d’hébergeur, les auditeurs ne font rien, et c’est bien ce qui inquiète. Personne ne va se réabonner parce qu’on le lui demande dans un épisode. Ce sont les applications qui doivent comprendre toutes seules que l’émission a déménagé. Elles le font très bien, à condition de recevoir deux signaux précis, et de les recevoir assez longtemps.

Ce que voit l’auditeur, et ce qu’il ne doit pas voir

Apple décrit le résultat attendu en une phrase : après un changement d’hébergeur, les épisodes téléchargés restent téléchargés, l’abonnement et la progression d’écoute restent intacts (Apple, changer d’hébergeur). Tout le reste est de la tuyauterie. Quand une migration se passe mal, l’auditeur voit l’un de ces trois symptômes :

les nouveaux épisodes n’arrivent plus, parce que son application lit toujours l’ancienne adresse du flux ;
tout le catalogue réapparaît en double, parce que les épisodes ont changé d’identifiant ;
un épisode ne se lit plus, parce que le fichier a disparu de l’ancien hébergeur avant que le flux ne pointe ailleurs.

Chaque étape ci-dessous en évite un. Si vous hésitez encore sur l’endroit où héberger, notre guide technique pose les options avant de parler de déménagement.

Avant de bouger : noter ce que vous avez

Ouvrez votre flux actuel dans un lecteur de flux RSS ou dans le navigateur et gardez-en une copie. Apple conseille de comparer l’ancien et le nouveau flux avec ce genre d’outil, parce que la plupart des hébergeurs n’affichent ni les identifiants ni les adresses de fichiers dans leur tableau de bord. Trois choses à relever :

l’adresse exacte du flux, celle qui est inscrite chez Apple, Spotify et les autres ;
le <guid> de chaque épisode, l’identifiant qui ne doit jamais changer ;
les numéros de saison et d’épisode, s’il y en a. Apple explique qu’ils servent aussi à éviter les doublons.

Regardez aussi si le flux porte une balise <podcast:locked>yes</podcast:locked>. Elle demande aux hébergeurs qui la respectent de refuser l’import, pour protéger l’émission contre une copie par un tiers (documentation de la balise). Si c’est votre émission, déverrouillez-la chez votre hébergeur actuel avant de lancer l’import ailleurs.

Exportez enfin vos statistiques. L’historique reste chez l’ancien hébergeur, et vous risquez de le perdre en fermant le compte.

Les identifiants d’épisode, le point qui ne se rattrape pas

Chaque épisode a un GUID. Apple insiste : il doit rester identique même si le titre ou l’adresse du fichier changent. Le modifier peut faire apparaître des doublons chez les auditeurs, fausser les statistiques d’Apple Podcasts et, à terme, peser sur le statut de l’émission (Apple, modifier l’adresse du flux).

Un épisode sans GUID est identifié par l’adresse de son fichier. Dans ce cas, c’est cette adresse qui ne doit plus bouger, ce qui rend la migration beaucoup plus délicate.

Le jour de l’import, vérifiez dans le nouveau flux, épisode par épisode, que les GUID sont les mêmes que dans la copie gardée plus haut. Si des doublons apparaissent sur Apple Podcasts après coup, ou si les statistiques changent brutalement, Apple désigne la cause la plus probable : le nouvel hébergeur a changé les GUID pendant la migration.

La redirection : qui la pose, et combien de temps

Le nouvel hébergeur ne peut pas prévenir les applications à votre place. C’est l’ancienne adresse qui doit répondre « l’émission est ailleurs », avec une redirection permanente, dite 301.

Si l’ancien flux était chez un hébergeur, c’est lui qui la pose, en général depuis une option du type « déménager l’émission » ou « rediriger le flux ». Apple précise que la redirection posée par l’ancien hébergeur migre tous les abonnés, y compris ceux qui écoutent ailleurs que sur Apple Podcasts. Certains hébergeurs ajoutent aussi la balise <itunes:new-feed-url>. Dans ce cas, Apple ne demande aucune action de votre part dans Podcasts Connect.

Si vous gériez le flux vous-même, sur votre propre serveur, Apple demande deux choses : que le serveur réponde par une redirection 301 à toute requête sur l’ancienne adresse, et que le nouveau flux porte la balise <itunes:new-feed-url> avec sa propre adresse. On lit souvent qu’elle va dans l’ancien flux. Ce n’est pas ce qu’écrit Apple aujourd’hui, en anglais comme en français.

Dans les deux cas, Apple demande de maintenir la redirection au moins quatre semaines. Spotify, de son côté, indique qu’une redirection peut mettre jusqu’à sept jours à être prise en compte, et conseille d’attendre au moins une semaine avant de supprimer l’ancien compte (Spotify for Creators). Le délai d’Apple couvre donc celui de Spotify. Dans la pratique, gardez l’ancien compte actif et la redirection en place tant que vous n’avez pas vu les nouveaux épisodes arriver partout où vous êtes inscrit.

Si l’ancien hébergeur ne répond plus

Il arrive qu’on n’ait plus accès à l’ancien flux : compte fermé, service disparu, hébergeur qui refuse de rediriger. La redirection devient impossible, et il faut prévenir chaque annuaire à la main.

Apple Podcasts Connect permet de modifier l’adresse du flux : on ouvre l’émission, on clique sur « Modifier » à côté de l’adresse, on colle la nouvelle. Apple précise que cette méthode vise les abonnés d’Apple Podcasts.
Spotify for Creators propose la même chose dans les réglages de l’émission, pour un podcast hébergé ailleurs que chez Spotify (aide de Spotify).

Les applications qui lisent votre flux directement, sans passer par un annuaire où vous avez un compte, ne recevront jamais l’information. C’est la raison pour laquelle la redirection reste la bonne méthode chaque fois qu’elle est possible.

Les fichiers audio, l’étape qu’on oublie

Un import recopie souvent les épisodes, les textes et les pochettes, mais laisse les fichiers audio là où ils sont : le nouveau flux pointe encore vers les serveurs de l’ancien hébergeur. C’est aussi le cas de l’import de Zekast, qui fait du rapatriement des fichiers une étape séparée. Tout fonctionne le premier mois. Le jour où l’ancien compte est fermé, les fichiers disparaissent, et les épisodes ne se lisent plus.

Avant de résilier, vérifiez donc dans le nouveau flux l’adresse de chaque fichier (l’attribut url de <enclosure>). Si elle désigne encore l’ancien hébergeur, le déménagement n’est pas fini. Changer cette adresse est normal. Apple précise que le GUID doit rester le même même quand l’adresse du fichier change : c’est lui qui identifie l’épisode.

Les statistiques, pendant et après

Attendez-vous à des courbes étranges pendant quelques semaines. Apple prévient que les tableaux de bord des hébergeurs peuvent montrer des chiffres atypiques après une migration, alors que les statistiques d’Apple Podcasts, elles, restent cohérentes. Pour suivre la bascule, regardez les chiffres d’Apple Podcasts et de Spotify : leur outil de mesure reste le même quand vous changez d’hébergeur, et la comparaison avant et après y est directe.

L’ordre des étapes

Copier l’ancien flux, noter les GUID, exporter les statistiques.
Retirer <podcast:locked> si l’émission est verrouillée.
Importer le catalogue chez le nouvel hébergeur, puis comparer les GUID un par un.
Rapatrier les fichiers audio, et vérifier les adresses des <enclosure>.
Poser la redirection 301 sur l’ancienne adresse du flux.
Attendre que les nouveaux épisodes arrivent sur chaque plateforme, et au moins quatre semaines.
Seulement ensuite, fermer l’ancien compte.

Fermer l’ancien compte avant d’avoir rapatrié les fichiers, c’est-à-dire inverser les étapes 4 et 7, fait disparaître des épisodes. C’est l’erreur à ne pas faire.

Zekast importe votre catalogue en gardant les GUID d’origine, puis rapatrie les fichiers audio épisode par épisode, avant que vous ne demandiez la redirection. Voir la migration →

Vérifié le 13 septembre 2026 contre la documentation d’Apple Podcasts, de Spotify for Creators et de la balise podcast:locked. Prochaine relecture : septembre 2027.