Le calendrier des sorties My Comics Collection se met à jour chaque matin à 9h heure de Paris via un cron-job externe qui interroge l'API publique Metron.cloud (licence CC-BY-SA 4.0). Le système synchronise les nouvelles solicitations, met à jour les dates modifiées, télécharge les couvertures manquantes dans un cache disque local et notifie en interne les utilisateurs Premium dont la pull list est impactée.
Le calendrier des sorties repose sur une architecture en 4 couches techniques. Couche 1 : Metron.cloud, la source de données originale, une base communautaire collaborative créée en 2018 qui agrège les solicitations officielles des éditeurs avec licence CC-BY-SA 4.0. Couche 2 : un cron-job externe hébergé sur cron-job.org (service gratuit avec timeout 30s) qui appelle chaque matin à 9h00 Paris un endpoint dédié de l'API My Comics Collection. Couche 3 : l'API serveur qui récupère les nouvelles données Metron via leur REST API, met à jour la table MySQL upcoming_releases, et déclenche le téléchargement asynchrone des couvertures manquantes. Couche 4 : le frontend de l'application qui interroge cette table à chaque visite utilisateur pour afficher le calendrier à jour.
L'architecture du système : Metron → API → cache → utilisateur
Ce design en 4 couches sépare proprement les responsabilités : Metron gère la donnée source (qu'on consomme légalement via leur licence), le cron pilote la fréquence (on contrôle quand on synchronise), le serveur gère la persistance (cache MySQL + disque), et le frontend gère l'affichage. Si l'une des couches a un incident temporaire, les autres continuent — le cache MySQL garde les données précédentes même si Metron est down, ce qui évite les pages blanches.
Le cron-job quotidien : pourquoi 9h heure de Paris
Le choix de l'horaire 9h00 heure de Paris (UTC+1 ou UTC+2 en été) répond à plusieurs contraintes opérationnelles. (1) Décalage avec l'horaire US : 9h00 Paris correspond à 3h-4h heure de New York, quand les éditeurs américains ont fini leurs mises à jour nocturnes de la base Metron. À cet horaire, la donnée Metron est fraîche et stable pour les 24h à venir. (2) Charge serveur faible : 9h Paris est encore en heure creuse pour la plupart des utilisateurs My Comics Collection, ce qui évite que le cron-job ne soit en compétition avec le trafic utilisateur pic. (3) Disponibilité pour la journée : les utilisateurs francophones qui ouvrent l'application en début de journée (8h-11h) voient un calendrier fraîchement à jour, ce qui maximise la qualité perçue.
Une exception : pour les utilisateurs en Asie/Pacifique qui visitent à minuit Paris (matin chez eux), le calendrier peut afficher des données de la veille avant le sync de 9h. C'est un trade-off conscient : on optimise pour la majorité francophone EU plutôt que pour la minorité APAC.
Le timeout 30s et l'architecture async fire-and-forget
Une contrainte technique du service cron-job.org gratuit est le timeout HTTP de 30 secondes. Si le serveur My Comics Collection met plus de 30s à répondre, cron-job.org considère que c'est un échec et envoie une notification d'erreur. Or, la synchronisation Metron complète (récupération des 400+ solicitations, mise à jour MySQL, téléchargement des nouvelles couvertures) prend typiquement 2-5 minutes — bien au-delà du timeout.
La solution architecturale : l'endpoint pull_list_sync_async utilise un pattern fire-and-forget via la fonction PHP fastcgi_finish_request(). Concrètement, le serveur (1) reçoit l'appel cron, (2) valide le token X-Sync-Token, (3) répond HTTP 200 en moins de 100 ms, (4) ferme la connexion HTTP, et (5) continue le travail de synchronisation en arrière-plan. Le cron-job.org reçoit son HTTP 200 dans le timeout et est content, tandis que le serveur finit la vraie synchro à son rythme.
Ce pattern est élégant mais a une contrainte : si la synchro échoue silencieusement après le fire-and-forget (timeout MySQL, espace disque saturé pour les couvertures, etc.), le cron-job.org ne le saura pas. Pour mitiger, le serveur écrit un log dans _logs/pull_list_cron.log à chaque étape, ce qui permet de diagnostiquer post-mortem si une synchro a échoué.
Le cache disque des couvertures : pourquoi et comment
Les couvertures de comics récupérées depuis Metron sont stockées dans un cache disque local du serveur (répertoire cache/metron_covers/). Ce cache est crucial pour la fiabilité de l'affichage. Avant la mise en place du cache (sprint v5.105 fin avril 2026), les couvertures étaient référencées directement via le CDN Metron — ce qui résultait en images cassées une fois sur deux à cause des limites de hotlinking imposées par le CDN.
Avec le cache disque, le workflow est : (1) le cron de synchro déclenche le téléchargement des couvertures manquantes via une commande PHP curl ; (2) chaque couverture est stockée sous le nom {slug}.jpg à 300×450 pixels ; (3) un proxy HTTP côté serveur sert ces fichiers via l'URL /api.php?action=cover_proxy&slug=X, ce qui contourne complètement le CDN Metron une fois la couverture en cache. Résultat : taux d'affichage des couvertures > 99,5 %.
Performance : combien coûte une sync quotidienne en ressources
Pour les curieux techniques, voici les ordres de grandeur d'une sync quotidienne typique en juin 2026 : (1) requêtes Metron : 1 appel REST par publisher (~10 publishers principaux), soit 10 requêtes HTTP en moins de 5 secondes ; (2) volume données : 400-600 KB de JSON traité ; (3) requêtes MySQL : ~1 200 INSERT IGNORE (une par solicitation, idempotent) en moins de 2 secondes ; (4) téléchargement couvertures manquantes : typiquement 20-50 nouvelles couvertures par jour, soit 1-3 MB téléchargés en 30 secondes ; (5) total temps mur : 2-5 minutes par jour ; (6) coût mensuel : marginal (largement inclus dans l'hébergement OVH mutualisé existant, aucun surcoût).
Cette frugalité fait partie de la philosophie My Comics Collection : la fonctionnalité Pull List est offerte aux utilisateurs gratuits sans dégrader l'économie générale de l'application, parce que son coût marginal est négligeable. Le Premium finance la maintenance et les évolutions, pas la consultation gratuite.