google-calendar-sync

Google Calendar Sync est un service auto-hébergé qui maintient un calendrier de destination synchronisé en tant que projection d'un calendrier source. Chaque règle observe exactement un calendrier source et gère exactement un calendrier de destination, et la source et la destination peuvent appartenir à des identités Google différentes. Le projet est explicitement étiqueté pré-alpha : l'architecture, le moteur de synchronisation, l'API authentifiée, l'adaptateur Google et l'interface Web forment une première tranche verticale fonctionnelle, mais les tests d'endurance sur compte réel et l'examen de préparation à la production ne sont pas terminés, donc des calendriers de test et des sauvegardes sont conseillés. Points de conception clés décrits dans le README : - Règles directionnelles : une source, une destination, avec comportement autoritaire de la source. Les modifications de destination, les projections manquantes et les annulations de source sont réparées pendant la synchronisation et la réconciliation. - Confidentialité par défaut : les nouvelles règles sont par défaut en projection Occupé ; la copie des détails est facultative et ne copie jamais les participants, l'identité de l'organisateur, les données de conférence, les pièces jointes ou les invitations. - Activation sécurisée : une règle doit passer un aperçu sans effet de bord avant de pouvoir être activée. - Déploiement autonome : SQLite, planification, API et interface Web fonctionnent comme un seul service léger, fourni en tant qu'image Docker et service Compose pour linux/amd64 et linux/arm64. - Aucune télémétrie : une installation fonctionnelle ne communique qu'avec les API Google nécessaires à la synchronisation et tout point de terminaison de notification configuré par l'opérateur. Les capacités listées incluent les événements programmés et toute la journée, les séries récurrentes, les modifications et annulations d'occurrence unique ; les politiques occupé-uniquement ou copie de détails avec inclusion toute la journée par règle ; le sondage incrémental toutes les cinq minutes plus Sync Now manuel ; une passe de réconciliation complète quotidienne plus Reconcile Now avec rapport de dérive ; la prévention de boucle via des métadonnées d'origine gérées privées ; des clés de fonctionnement stables, la persistance du dernier curseur, le backoff de nouvelle tentative et les échecs de règle isolés ; une vue d'activité authentifiée avec déduplication et livraison d'incident SMTP ou webhook facultative ; un mot de passe administrateur local avec des identifiants OAuth Google chiffrés ; et des thèmes clair/sombre. La configuration nécessite un projet Google Cloud avec l'API Calendar activée, un client d'application Web OAuth 2.0 et l'URI de redirection exact http://localhost:8000/api/v1/oauth/google/callback. Les secrets locaux sont configurés via un fichier .env, y compris une clé maîtresse 256 bits qui chiffre les identifiants Google stockés avec AES-256-GCM. Le README note que perdre la clé maîtresse rend les identifiants de compte connectés illisibles, et que les déploiements sur hôte LAN nécessitent une gestion spéciale car Google rejette les URI de redirection HTTP en clair autres que localhost. Comportement de synchronisation : la première exécution lit les événements source se terminant au plus tôt 30 jours avant l'exécution, observe la destination et enregistre les jetons incrémentaux de Google pour les deux points de terminaison. Les exécutions ultérieures consomment les deux flux de modifications, donc les modifications ou suppressions uniquement côté destination sont réparées sans analyses complètes. Pour chaque événement source pertinent, le domaine choisit Créer, Mettre à jour, Supprimer, Ignorer ou Conflit ; l'identité ou la propriété ambiguë n'est pas devinée. Les curseurs n'avancent qu'après le succès complet d'un lot, et les écritures du fournisseur portent des clés de fonctionnement stables afin que les nouvelles tentatives ne dupliquent pas les projections. Notes de confidentialité et de sécurité : les titres, descriptions et emplacements d'événements sont traités en mémoire et non stockés dans SQLite ou les entrées d'audit ; les mappages conservent les ID de fournisseur, les révisions et une empreinte non réversible ; la déconnexion d'un compte supprime les identifiants stockés sans supprimer les règles, mappages ou projections gérées ; les écritures Google utilisent sendUpdates=none ; l'interface Web et l'API opérationnelle nécessitent la session administrateur locale, tandis que /health reste public et minimal. L'architecture est un monolithe modulaire avec des frontières ports-adaptateurs ; le domaine de synchronisation n'a aucune dépendance FastAPI, SQLite, SDK Google, React, OAuth ou Docker. Le développement backend utilise Python 3.12 et FastAPI, le frontend utilise Node.js 22+, React, TypeScript, Vite et Tailwind CSS. Les contrôles qualité incluent ruff, mypy, pytest avec un plancher de couverture de 80 %, le typecheck/lint/test/build du frontend et des constructions Docker multiplateformes. Google Agenda est le seul fournisseur dans la version initiale ; Outlook et CalDAV sont décrits comme des possibilités architecturales, pas des fonctionnalités prises en charge. Le projet vise la version 0.1.0 sous licence MIT.