Vos événements récurrents disparaissent à l'import.

Vous exportez votre agenda, vous l’importez dans le nouveau compte, et là : votre point d’équipe hebdomadaire n’apparaît qu’une seule fois. Ou pas du tout. Ou bien il est là, mais la réunion que vous aviez déplacée le 24 août est revenue à son ancien créneau. Les événements récurrents sont, de loin, ce qui casse le plus souvent dans une migration d’agenda Google. Voici précisément pourquoi — et ce qu’il faut faire à la place.

Un événement récurrent n’est pas ce que vous croyez

Quand vous voyez « tous les lundis à 10h » dans Google Agenda, votre cerveau imagine 52 petites cases identiques posées sur l’année. Le format d’agenda, lui, ne stocke jamais ces 52 occurrences. Il stocke une seule chose : un événement-maître, plus une règle. Cette règle, dans le standard iCalendar (RFC 5545), s’appelle une RRULE.

BEGIN:VEVENT
UID:point-equipe@workspace-a.com
DTSTART;TZID=Europe/Paris:20260105T100000
SUMMARY:Point équipe
RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=52
END:VEVENT

Tant que la série est « propre » comme ci-dessus, presque tous les outils s’en sortent. Le problème commence dès que la vraie vie s’en mêle : une occurrence annulée, une réunion décalée, un horaire modifié pour une seule semaine. C’est là que le format introduit deux mécanismes autrement plus fragiles.

Les exceptions : EXDATE et RECURRENCE-ID

Deux choses peuvent arriver à une occurrence individuelle :

• Elle est supprimée. Le format ajoute alors une ligne EXDATE au maître : « la règle s’applique, sauf à cette date ».
• Elle est modifiée (déplacée, renommée, ré-horairée). Le format crée alors un deuxième VEVENT, qui réutilise le même UID que le maître mais ajoute un RECURRENCE-ID pointant vers l’occurrence d’origine. C’est ce qu’on appelle une « exception » (ou override).

BEGIN:VEVENT
UID:point-equipe@workspace-a.com
DTSTART;TZID=Europe/Paris:20260105T100000
RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=52
EXDATE;TZID=Europe/Paris:20260817T100000   <-- semaine sautée
SUMMARY:Point équipe
END:VEVENT

BEGIN:VEVENT
UID:point-equipe@workspace-a.com           <-- même UID
RECURRENCE-ID;TZID=Europe/Paris:20260824T100000
DTSTART;TZID=Europe/Paris:20260824T140000  <-- déplacé à 14h
SUMMARY:Point équipe (exceptionnellement l'après-midi)
END:VEVENT

Vous voyez le piège se dessiner ? La cohérence de toute la série repose sur trois liens invisibles : l’UID partagé, le RECURRENCE-ID qui doit retomber exactement sur une date produite par la règle, et le fuseau (TZID) qui doit être défini quelque part dans le fichier. Cassez l’un des trois, et la série se disloque.

Pourquoi l’import Google les perd

L’import par fichier .ics lit le fichier sans mémoire fiable de l’ordre ni des relations entre événements. Quatre choses tournent mal, en pratique.

1. L’exception arrive avant son maître

Si l’exception (le VEVENT avec RECURRENCE-ID) est lue avant le maître, l’importeur ne trouve aucune série à laquelle la rattacher. Résultat : soit il la jette, soit il la crée comme un événement isolé. Votre réunion déplacée devient un doublon orphelin.

2. La définition du fuseau manque

Les dates référencent TZID=Europe/Paris, mais le bloc VTIMEZONE qui définit ce fuseau a sauté à l’export (c’est fréquent quand on passe par un outil tiers). L’importeur retombe sur UTC, les dates de RECURRENCE-ID ne correspondent plus exactement aux dates générées par la RRULE, et le rattachement échoue silencieusement.

3. La récurrence « sans fin » est tronquée

Une RRULE sans COUNT ni UNTIL est infinie. Si un outil de migration a « aplati » la série en événements individuels avant l’import (une erreur courante), vous perdez la règle elle-même : l’agenda cible ne sait plus prolonger la série dans le futur.

4. La limite du 1 Mo coupe au milieu d’une série

Google plafonne l’import ICS à 1 Mo par fichier. Quand on découpe manuellement un gros export pour passer sous la barre, la coupure peut tomber entre un maître et ses exceptions — qui se retrouvent dans deux fichiers différents. Le lien est définitivement rompu.

Le contournement manuel (et pourquoi il épuise)

La méthode « à la main » que tout le monde finit par tenter ressemble à ça :

• Exporter, ouvrir le .ics dans un éditeur de texte, vérifier que chaque VTIMEZONE est présente.
• Réordonner les VEVENT pour que chaque maître précède ses exceptions.
• Découper en fichiers de moins de 1 Mo sans séparer une série de ses exceptions.
• Importer, puis vérifier à l’œil, série par série, que les exceptions ont bien suivi.

Sur dix événements, c’est faisable. Sur un agenda réel de plusieurs centaines de séries, avec des années d’exceptions accumulées, c’est plusieurs heures de travail minutieux — et une seule inattention suffit à laisser passer une occurrence fantôme.

Comment SoftHop le résout

La cause racine de tous ces problèmes, c’est l’aller-retour par fichier : exporter en ICS, puis ré-importer en ICS. Chaque conversion perd un peu d’information de structure. SoftHop ne passe jamais par un fichier.

On lit la série directement via l’API Google Agenda, où le maître, sa règle de récurrence et chacune de ses exceptions sont des objets liés et explicites. On recrée d’abord tous les maîtres sur le compte cible, puis on réapplique chaque exception sur l’occurrence correspondante de la série recréée : modifiée si elle avait été déplacée ou renommée, annulée si elle avait été supprimée. Les cas limites — une occurrence passée d’un horaire à « toute la journée », par exemple — sont traités à part plutôt qu’ignorés.

Les événements récurrents sont le test ultime d’un outil de migration : c’est exactement là que les exports ICS bricolés montrent leurs limites. Si votre agenda contient des séries avec des années d’exceptions, ne les confiez pas à un copier-coller de fichier.