L’API qui continuait de s’éloigner

Il y a quelques années, j’avais obtenu une clé d’API développeur. L’idée était d’écrire un client minimal pour cocher des épisodes sans jamais toucher l’interface de l’app. J’ai fait quelques requêtes, ça marchait, mais la lenteur venait de l’API et non de l’app — un client maison ne réglerait rien. J’ai laissé tomber. Quelques mois plus tard, les requêtes étaient de toute façon bloquées — je n’ai jamais su si ma clé avait été révoquée en silence ou si l’API avait changé sans prévenir.

TVTime est une application gratuite sans modèle de monétisation évident — que l’API soit la première victime d’une réduction de coûts d’infrastructure, c’était compréhensible. J’ai continué à utiliser l’app, à attendre.

Quelques années plus tard, je commençais à jouer avec Home Assistant et l’idée d’un dashboard de mes épisodes en cours me paraissait évidente. J’ai renvoyé une demande d’accès API en mentionnant ce cas d’usage. Cette fois la réponse était claire : plus de clé d’API pour le public.

Second échec. Et en y repensant, TVTime n’avait pas vraiment évolué depuis des années — si tant est qu’il n’avait pas régressé.

Le dimanche qui a rompu l’habitude

Le troisième signal est arrivé un dimanche après-midi. Spinner. Erreur. Spinner. J’ai fermé l’app et j’ai pensé qu’il était temps de la remplacer.

Je suivais trois choses : des animés, des séries télévisées et des films. Les animés étaient la priorité — j’en regarde davantage, le calendrier de diffusion est fragmenté sur plusieurs plateformes, et savoir ce qui sort dans la semaine est vraiment utile. Deux exigences rendraient un remplacement réellement utilisable : un calendrier hebdomadaire des sorties et une synchronisation multi-appareils (téléphone et ordinateur, au minimum).

Je me suis donné un week-end pour faire un POC. La stack sur laquelle je me suis appuyé : React 19, TypeScript, Vite, Firebase Auth et Firestore. Pas parce que c’est une combinaison à la mode, mais parce qu’elle résout le problème de synchronisation sans faire tourner un backend. Firestore fournit un document store en temps réel ; Firebase Auth gère la connexion entre les appareils ; le navigateur fait le reste. Je préférais payer la latence des lectures Firestore plutôt que de construire et maintenir un serveur API pour un projet personnel avec exactement un utilisateur.

Le projet s’appelle Miru. En japonais, ça signifie « regarder ».

Trois formats, trois API

La première vraie décision portait sur les API à utiliser. Les animés, les séries et les films vivent dans des écosystèmes de données séparés, et faire semblant du contraire m’aurait coûté des semaines.

Pour les animés, AniList s’impose. Il expose une API GraphQL, couvre l’essentiel du medium et inclut directement les calendriers de diffusion. Une seule requête avec une plage de dates retourne les prochains épisodes pour une liste d’identifiants. Un seul appel réseau pour toute la semaine. Je ne m’attendais pas à ce que ce soit aussi propre.

Pour les séries et les films, TMDB est la référence. Son API REST v3 est bien documentée, stable, et couvre le catalogue international que d’autres bases de données ratent. La contrepartie : pas d’endpoint de planning par lot. J’appelle l’endpoint de saison par série, je filtre sur la semaine en cours, et je collecte les résultats.

Les titres d’épisodes pour les animés viennent d’une troisième source : Jikan , qui agrège MyAnimeList. AniList n’a pas toujours les titres d’épisodes, surtout pour les séries plus anciennes. Quand un item suivi dispose d’un MAL ID (qu’AniList expose), je récupère la liste des épisodes depuis Jikan et j’injecte les titres. C’est un enrichissement optionnel — le calendrier fonctionne sans, mais la différence entre « Épisode 7 » et « La Troisième Trahison » vaut bien quelques requêtes supplémentaires.

Une requête pour toute la semaine

Le calendrier hebdomadaire est la fonctionnalité qui justifie le projet. Chaque dimanche, je veux voir ce qui sort dans les sept prochains jours dans tout ce que je regarde, sans ouvrir quatre applications différentes.

Côté AniList, c’est efficace. Une seule requête GraphQL prend la liste des identifiants AniList de mes animés en cours et une plage de dates, et retourne tous les épisodes prévus dans cette fenêtre. Une requête, toutes les données.

query AiringSchedule($ids: [Int], $start: Int, $end: Int) {
  Page {
    airingSchedules(
      mediaId_in: $ids
      airingAt_greater: $start
      airingAt_lesser: $end
    ) {
      mediaId
      episode
      airingAt
    }
  }
}

Côté TMDB, c’est moins élégant. Pas d’endpoint de planning par lot, donc j’appelle l’endpoint de saison par série et je filtre localement. Pour dix séries en cours, ça fait dix requêtes en parallèle — tolérable, et les limites de débit de TMDB sont suffisamment généreuses pour ne pas s’en préoccuper.

L’enrichissement Jikan tourne en dernier, après l’assemblage des données AniList. Pour chaque épisode planifié où j’ai un MAL ID, je récupère la liste depuis Jikan et j’injecte le titre. Je mets ces données en cache par session pour éviter de récupérer la même liste deux fois.

Pas de serveur, pas d’ops

Firestore est l’élément qui rend ce projet viable. Ma bibliothèque — quelles séries je suis, où j’en suis, quels épisodes j’ai cochés — tient dans un seul document Firestore par utilisateur. Il se charge à l’authentification, se sauvegarde à chaque modification avec un debounce d'1,5 seconde pour ne pas saturer le quota gratuit, et se synchronise automatiquement entre les appareils.

Les règles de sécurité tiennent en deux lignes : lecture et écriture autorisées uniquement si request.auth.uid == userId. Pas de backend, pas de middleware d’autorisation, pas de rotation de token à gérer.

L’hébergement suit la même logique : l’app est déployée sur Vercel , connectée au dépôt GitHub. Chaque push sur main déclenche un build et une mise en production automatique. Zéro configuration serveur, zéro pipeline à maintenir.

La seule chose que Firestore ne résout pas, c’est le cold start. Le premier chargement sur un nouvel appareil attend l’initialisation du SDK Firebase et l’arrivée du document. Sur une bonne connexion, moins d’une seconde. Sur un réseau mobile, ça se sent. J’accepte ce compromis — un tracker personnel n’a pas besoin de l’architecture d’une plateforme de streaming. Le jour où il y aurait davantage d’utilisateurs, les choix faits ici mériteraient d’être ré-étudiés : backend dédié, cache, séparation des responsabilités. Mais ce jour-là n’est pas aujourd’hui.

L’extension qui a rendu la migration possible

Ce que je redoutais le plus en remplaçant TVTime, c’était l’import initial. J’avais quelques centaines d’entrées suivies sur plusieurs années. Migrer ça manuellement, non merci.

La solution : une extension de navigateur — pas pour un usage courant, mais pour la migration unique. Des scripts de contenu injectés sur les pages AniList , MyAnimeList et Crunchyroll détectent le titre du media depuis le slug d’URL, ajoutent un petit bouton « Ajouter à Miru » dans l’interface existante, et transmettent le titre à l’app au clic. L’extension pré-remplit le dialogue de recherche. On clique, on vérifie, on confirme.

J’ai migré ma liste AniList en vingt minutes environ. Mieux que prévu. Les séries et les films, j’ai dû les faire à la main, mais ces listes étaient plus courtes et la recherche est assez rapide pour que ce ne soit pas pénible.

L’extension est un build IIFE Manifest V3 — trois scripts de contenu séparés, un par plateforme, packagés pour Chrome et Firefox. Rien de complexe, mais ça a résolu le vrai point de friction qui sépare une migration qui se fait de celle qui ne se fait pas.

Ce que c’est devenu

Miru tourne en bêta depuis environ une semaine. Le calendrier hebdomadaire fonctionne. La page de stats est brute mais fonctionnelle. La recherche dans la bibliothèque est rapide. J’ai ouvert TVTime deux fois depuis lors, par réflexe, et refermé immédiatement les deux fois.

Ce que j’avais sous-estimé, c’est la valeur de posséder les données. Le document Firestore est le mien. Je peux l’exporter, le migrer, l’interroger, le brancher sur Home Assistant. C’était l’objectif d’il y a deux ans — une API fermée plus tard, je l’ai enfin.

Ce que j’avais surestimé, c’est la complexité des intégrations. AniList et TMDB sont de vraiment bonnes API. Leur documentation correspond au comportement réel, les réponses d’erreur disent quelque chose d’utile, et les limites de débit sont difficiles à atteindre en usage personnel. Trois heures d’expérimentation ont suffi pour construire des clients fonctionnels pour les deux.

L’extension m’a surpris. Je m’attendais à ce que ce soit la partie pénible. C’est finalement la plus satisfaisante : injecter un bouton, extraire un titre, fermer un onglet. Périmètre réduit, résultat immédiat. Le genre d’outil qui n’a besoin de fonctionner qu’une seule fois mais qui fait la différence entre une migration qui se fait et une qui ne se fait pas.