Calendrier de publication du blog

Contexte

Les articles du blog développeurs d'Upsun sont rédigés et relus sous forme de pull requests GitHub, la date de publication étant portée par la pull request elle-même. Pour savoir ce qui sortait quand, il fallait ouvrir les pull requests une à une. Impossible d'avoir une vue d'ensemble, d'éviter deux articles le même jour ou de repérer un article en retard. Et chaque publication demandait que quelqu'un de l'équipe Advocacy soit là, le jour dit, pour fusionner la pull request. Il m'est arrivé de recevoir des demandes de publication en plein salon, sur le stand, en pleine démo client.

Je l'ai lancé lors du hackathon interne de fin novembre 2025, puis mis en service pour toute l'équipe.

Ce que j'ai construit

• Un calendrier mensuel des articles programmés, à côté de la liste des pull requests : date prévue, étiquettes, lien vers la pull request et vers l'aperçu de l'article.
• La planification par glisser-déposer : on déplace un article dans le calendrier, puis on synchronise, avec la possibilité d'annuler les changements avant l'envoi. La synchronisation met à jour la date dans la pull request et dans le fichier Markdown de l'article : la date choisie dans le calendrier est celle qu'affiche le blog une fois l'article publié.
• Un statut par article, avec filtres : synchronisé, à synchroniser, en retard ou en erreur, fusionné ou fermé. Un article dont la date est passée sans publication ressort en rouge.
• Les jours fériés des quatre pays de l'équipe (États-Unis, France, Allemagne, Royaume-Uni) affichés dans le calendrier, pour ne pas programmer un article un jour où son auteur ou ses relecteurs sont absents.
• Les règles de publication du marketing faciles à suivre : la vue d'ensemble permet de placer chaque article un mardi, un mercredi ou un jeudi, sans rien bloquer.
• La publication à la date prévue, sans personne de garde pour fusionner la pull request.
• Une collecte quotidienne (cron) des informations des dépôts Git, et un rechargement à la demande.
• Un message automatique dans chaque nouvelle pull request d'article, avec le lien vers le back-office : les auteurs le découvrent au bon moment, sans formation.
• Thème clair ou sombre.

Stack

Backend en TypeScript, frontend construit avec Vite 7, intégration à l'API GitHub. Il est ouvert à toute personne qui a accès au dépôt GitHub du blog technique.

Résultats

• L'équipe Advocacy a gagné trois semaines de visibilité sur les prochaines publications du blog.
• Le blog s'est ouvert aux contributions des autres équipes : un article est publié à la date voulue sans que l'Advocacy ait à être sur le pont pour le fusionner.
• Les règles de publication du marketing (mardi, mercredi ou jeudi) sont bien plus simples à respecter.
• Les retards sautent aux yeux, et les trous dans le planning aussi.
• La date reste portée par la pull request : une seule source de vérité, et l'outil ne fait que la rendre lisible et modifiable.