SMF·VIMCAL
Un prompt peut-il remplacer Vimcal ?
Planification — booking links and calendar automation
Bordereau de suivi des pièces
Verdict
Le client calendrier est réalisable : l’API de Google te donne les événements, et une palette de commandes par-dessus est un travail ordinaire. Deux choses en font un projet de quinze jours plutôt qu’un week-end. Les fuseaux horaires sont vraiment difficiles une fois que tu gères les événements récurrents à travers les changements d’heure d’été, et se tromper là-dessus veut dire une réunion à la mauvaise heure, qui est le seul bug qui compte dans un calendrier. Et la vitesse de Vimcal vient d’une mise en cache locale agressive avec des écritures optimistes, ce qui est un problème de synchronisation, pas de rendu.
Pièce A — Le prompt
Reçu le31.07.2026Construis un client calendrier d’abord au clavier sur un seul compte Google Calendar, avec la gestion des fuseaux horaires comme préoccupation de premier ordre.
Authentification : un client OAuth Google Cloud avec la portée calendrier ; tokens de rafraîchissement chiffrés au repos ; un flux de reconnexion visible.
Synchro : récupère les événements avec l’API de jeton de synchro incrémentale plutôt qu’en re-récupérant une fenêtre, stocke-les dans PostgreSQL, et garde le jeton de synchro pour qu’un redémarrage reprenne plutôt que de tout re-récupérer. Les écritures sont optimistes — applique localement, envoie à Google, et réconcilie ou annule visiblement en cas d’échec. Cet optimisme est ce qui rend l’interface instantanée, et le chemin d’annulation est la partie qui doit être testée.
Gestion du temps, faite correctement. Stocke chaque événement en UTC avec son fuseau horaire d’origine enregistré séparément. Pour les événements récurrents, développe la RRULE dans le propre fuseau horaire de l’événement, pas en UTC, pour qu’une réunion hebdomadaire à 9h reste à 9h à travers un changement d’heure d’été au lieu de dériver d’une heure. Écris des tests spécifiquement pour ça, y compris une série qui traverse une frontière d’heure d’été dans un fuseau qui bascule à une date différente de celle du spectateur.
Vue par fuseau horaire, qui est la fonctionnalité différenciante : un contrôle qui décale toute la grille vers un autre fuseau, et une colonne secondaire montrant un fuseau choisi à côté du tien. Lors de la création d’un événement, tape une heure dans n’importe quel fuseau et vois-la résolue dans chaque fuseau que tu as épinglé. Montre les heures de travail de l’autre partie comme une bande ombrée pour qu’un 8h qui est 23h pour eux soit visible avant que tu envoies l’invitation.
Clavier : une palette de commandes pour tout (sauter à une date, créer un événement, changer de vue, changer de fuseau), plus des raccourcis à touche unique pour jour, semaine, mois, aujourd’hui, suivant, précédent. La souris doit être optionnelle pour chaque action.
Liens de planification : publie la disponibilité à partir des heures de travail moins le temps occupé, avec des marges et un préavis minimum. Réserve un créneau de façon transactionnelle pour que deux personnes réservant simultanément ne puissent pas gagner toutes les deux, crée l’événement calendrier, et envoie des confirmations par email avec des liens d’annulation et de report signés.
Hors périmètre : les comptes calendrier Microsoft et Apple, les applications mobiles, le routage round-robin d’équipe, les paiements, et toute intégration CRM.
L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 les comptes calendrier Outlook et Apple
- B.2 les applications natives de bureau et mobile
- B.3 la planification d’équipe : round-robin, disponibilité collective, routage
- B.4 le raffinement autour des cas limites qu’on ne rencontre que deux fois par an
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : calendar integrations and reliability
Parce qu’un calendrier qui montre la mauvaise heure une seule fois a perdu ta confiance de façon permanente, et les cas limites de fuseau horaire sont la partie que personne ne veut assumer soi-même.
Questions
Y a-t-il quelque chose à importer ?
Non, et c’est un avantage rare ici. Vimcal est un client par-dessus ton Google Calendar existant, donc les données sont déjà là où elles doivent être. Seule ta configuration de liens de planification doit être recréée.
Pourquoi la gestion des fuseaux horaires pour les événements récurrents est-elle soulignée aussi précisément ?
Parce que c’est le bug que livre chaque calendrier maison. Développer une récurrence en UTC a l’air correct en test et déplace chaque occurrence d’une heure quand les horloges changent, ce qui se manifeste par des gens qui arrivent en retard à une réunion récurrente pendant quinze jours avant que quelqu’un ne comprenne pourquoi.
Combien ça coûte à faire tourner ?
Un petit VPS avec PostgreSQL, cinq à dix dollars par mois. L’API Google Calendar est gratuite à des volumes personnels. Les emails de liens de planification ont besoin d’un expéditeur transactionnel, gratuit à faible volume chez la plupart des fournisseurs.
Quelle est la seule chose qui ne survit pas à la reconstruction ?
Lui faire confiance sans vérifier. Vimcal a des années de cas limites signalés par des gens dont les calendriers sont leur gagne-pain. Un client fait maison qui se trompe sur un fuseau décalé d’une demi-heure ou une récurrence de semaine bissextile le fera silencieusement, et tu le découvriras par la personne qui attend l’appel.
Outils proches
Récépissé