🤔 Cast Rewinder — comment gérer les éléments supprimés ?

jeudi 19 juillet 2018

Deux semaines après avoir commencé à travailler sur Cast Rewinder, moins d’une semaine après sa sortie « officielle », l’outil a été cité par Lifehacker et Korben.info, c’est sympa, je suis plutôt content.

Lorsque l’auteur du billet sur Lifehacker m’a contacté pour avoir plus de détails, il m’a posé une question à laquelle je n’avais pas encore beaucoup réfléchi : comment gérer les feeds qui ne gardent pas leurs archives ? Ceux de Radio France, par exemple, restent généralement en ligne un an. Ça peut poser un problème dans certains cas. En répondant à cet email, je me suis dit que le problème était un poil plus compliqué qu’il n’en a l’air.

Le fonctionnement de Cast Rewinder

Un oncle récemment disparu avait l’habitude de dire ce qui se conçoit bien s’énonce clairement. À ça, j’ajoute que c’est dans l’exercice de l’énonciation claire que peut souvent apparaitre une solution à un problème ; les développeurs connaissent bien la technique du canard en plastique.

Voici donc comment fonctionne le site, pour les utilisateurs.

Une utilisatrice, Jeanne, veut écouter un podcast depuis le début. Elle colle dans le champ idoine l’URL du flux du podcast, choisit sa fréquence, puis valide le formulaire (1). Après un peu d’attente, la page suivante lui présente l’adresse du nouveau flux personnalisé à sa fréquence (2). Lorsqu’elle colle l’adresse de ce flux dans son navigateur, ou dans son app de podcast, celui-ci va chercher le flux (3), puis l’affiche (4). Lorsqu’elle va réactualiser le flux à la fréquence définie, elle recevra des nouveaux épisodes (5).

Et voilà ce qui se passe dans l’app :

1. L’outil reçoit l’URL d’un flux. Après avoir vérifié qu’il s’agit d’une adresse valide (et d’avoir déterminé la bonne adresse si c’est une URL iTunes ou SoundCloud), il va atteindre cette URL, puis traiter le contenu du flux ainsi récupéré. Ce traitement consiste à :
   • ajouter les information du flux (URL, auteur, description…) dans la base de donnée, dans le tableau Feed, si le flux n’y est pas déjà présent
   • pour chaque épisode du podcast, ajouter les informations de chaque épisode (titre, contenu, date de publication…) dans la base de donnée, dans le tableau Episode, si l’épisode a été publié après la date de publication du dernier épisode de ce flux présent dans la base (pour éviter d’avoir des doublons)
2. Une fois que ce processus est terminé (ça peut prendre plusieurs secondes), l’outil récupère l’identifiant du flux dans la base de donnée, et colle toutes les parties de l’adresse pour générer sa forme spécifique : https://rewind.website/<identifiant du flux>/<fréquence>/<date>
3. Lorsque ce flux personnalisé est appelé par un navigateur ou une app de podcast, l’outil va faire plusieurs choses :
   • récupérer la fréquence et la date, pour faire un catalogue de toutes les dates de parution du nouveau podcast. Si la date de début remonte à 10 jours et que la fréquence est quotidienne, il y aura 10 dates, du début à aujourd’hui. Si la fréquence est hebdo, il n’y aura que 2 dates : celle du début, et celle d’il y a 3 jours (10 - 7)
   • récupérer l’identifiant du flux et demander à la base de données les informations dans le tableau Feed
   • demander à la base de données une liste d’épisodes issus du tableau Episodes, qui sera longue comme la liste des dates (10 épisodes ou 2, si on suit l’exemple plus haut), en partant du plus ancien au plus récent
   • avec ces informations du flux et cette liste d’épisodes, l’outil génère un nouveau flux
4. Ça, c’est hors des mains de l’outil
5. Quand le flux personnalisé est rappelé par l’utilisatrice quand elle met à jour ses podcasts, c’est à nouveau l’étape 3 qui se déroule. Selon le temps qui s’est écoulé, elle verra apparaître un nouvel épisode ou plus, ou aucun

Toutes les informations qui sont envoyées à l’utilisateur sont issues de la base de donnée. Pour la maintenir à jour, l’outil va chercher les mises à jour de tous les flux au milieu de la nuit.

Sauf que la mise à jour ne se fait que dans un sens : on ajoute, mais on ne retire pas.

Prenons le cas des flux de Radio France, les épisodes sont gardés un an.

• Jeanne, l’utilisatrice, s’est abonnée à La Fabrique de l’Histoire début juillet 2018. Dans la base de donnée de l’outil, il y aura donc les épisodes qui remontent à juillet 2017.
• Camille qui veut aussi écouter le même podcast, et s’abonne en septembre 2018. Son flux va commencer par des épisodes de juillet 2017—des épisodes qui ne sont plus sur le flux de Radio France en septembre 2018, et dont les liens vers les fichiers MP3 ne marchent plus. C’est vraiment pas utile pour Camille.
• Marc est un troisième utilisateur, qui s’abonne au flux en même temps que Jeanne. Le flux a une diffusion quotidienne normalement, mais il n’a pas beaucoup de temps, il ne veut recevoir de nouveaux épisodes que toutes les semaines

Les limites de l’outil

Étant donné qu’il s’agit juste d’un service qui retranscrit des flux RSS, et non d’une app de lecture de podcasts avec des préférences, etc…, mes options sont limitées.

Les seules préférences que l’utilisateur peut soumettre à l’outil, c’est au tout début, un peu à la manière “set it and forget it”, en somme. L’outil génère une fois une URL pour l’utilisateur, et l’app de l’utilisateur va faire appel à cette même URL. L’outil n’a aucun moyen de savoir quels épisodes ont été lus, pas lus, sautés, oubliés, archivés… Si l’utilisateur veut trafiquer son URL, il faut qu’il ajoute à nouveau l’URL dans son app, qui n’aura sans doute pas gardé en mémoire quels épisodes auront été lus, etc.

Comment gérer tout ça ?

Il y a une première solution : récupérer chaque fichier MP3 et les héberger. On va oublier tout de suite. D’une part ça pose des problèmes éthiques (je ne souhaite pas héberger l’œuvre d’autrui sans leur accord). De plus, s’ils sont supprimés à un moment, c’est souvent pour des raisons de droits. Et il y a aussi l’hébergement (à 1 Mo la minute environ, une durée de 60 minutes en moyenne par épisode d’émission de France Culture, plus de 200 épisodes par an, deux podcasts de France Cul’ occupent mon espace d’hébergement de 25 Go) et la bande passante. On oublie.

Une deuxième solution : toutes les nuits, quand le flux est mis à jour, je supprime les plus anciens épisodes qui ne sont plus dans le nouveau flux. C’est pas idéal :

Jeanne s’abonne le 1er juillet au podcast d’une émission quotidienne de France Cul’ (qui ne diffuse pas le week-end).

• Au 1er juillet, le flux original contient les épisodes du 1er, 2, 3, 4, 5, 8, 9, 10… juillet 2017. Le flux de l’outil contient un épisode (celui du 1er)
• Le 2 juillet, le flux original contient les épisodes du 2, 3, 4, 5… juillet 2017. Le flux de l’outil contient deux épisodes (celui du 2 et celui du 3)
• Le 3 juillet, le flux original contient les épisodes du 3, 4, 5… juillet 2017. Le flux de l’outil contient trois épisodes (celui du 3, 4 et 5)

Au final, comme on le voit, c’est faisable mais pas pratique. L’argument « tous les jours un nouvel épisode » ne tient pas : « tous les jours une quantité de nouveaux épisodes égale à la quantité de nouveaux épisodes de la veille, plus un », c’est moyen.

Troisième solution : Lors de la mise à jour quotidienne, les épisodes présents en base de donnée mais qui ne sont plus dans le flux, sont marqués comme inactifs dans la base de donnée.

L’idée est déjà plus intéressante à première vue.

Si on suit l’exemple précédent, Jeanne aura donc le 3 juillet 2018 un flux qui contiendra l’épisode 1er juillet 2017 et l’épisode 2 juillet 2017 inactifs et l’épisode 3 juillet 2017 valide. Les épisodes du 4 et 5 juillet attendront leur heure bien sagement.

Sauf que…

Camille aura un problème. En s’abonnant en septembre 2018, l’outil générera un flux qui contiendra l’épisode du 1er juillet 2017, puis ne rajoutera que des épisodes inactifs pendant un certain temps. Vraiment pas idéal.

Il faut donc que le flux servi à Camille commence au premier épisode valide présent dans le flux. C’est possible à faire, il y a même une option qu’on peut glisser dans l’adresse du flux, comme ça : https://rewind.website/<identifiant du flux>/<fréquence>/<date>/start_at:ß où ß représente l’épisode où commencer le feed.

Quatrième solution : Cette solution reprend grosso modo la troisième solution, mais ajoute un nouvel élément.

Si Marc s’abonne à un flux original quotidien (on reste sur France Cul’), avec des préférences hebdomadaires, l’outil lui fera très rapidement un flux qui ne contiendra que des épisodes inactifs. Il faut donc que l’outil envoie à chaque mise à jour le premier épisode actif (et tous les inactifs). Ça donne tous les jours un épisode actif, c’est bien, mais pour le suivi, c’est potentiellement moins bien. Je suis sûr qu’il y a des problèmes à la longue, mais je ne les ai pas encore identifiés.

Conclusion

Je n’ai pas encore atteint de conclusion. Je suis sûr qu’il y a plusieurs autres solutions à envisager, mais je ne les ai pas encore trouvées.

J’aurai une remarque cependant : s’il vous plaît, ne tronquez pas vos flux, ne supprimez pas vos anciens éléments, même si vous êtes une radio publique. On voudrait pouvoir commencer à un point, et que ce point reste fixe, ça serait beaucoup plus facile pour tout le monde.

Si vous avez déjà résolu ce problème par le passé, si vous avez une super idée géniale, ou juste une piste… prenez contact : je suis hello@rewind.website, et mon Twitter et Mastodon sont plus bas.