Qu’est-ce qu’un fichier ICS ?

ICS est un format texte que n’importe quel éditeur ouvre. Il est utilisé pour l’échange entre programmes.

L’extension est .ics et le nom complet iCalendar. L’un et l’autre comptent moins que ce que le fichier peut contenir, et c’est le sujet du reste de cette page.

Il remonte à 1998. La spécification est RFC 5545.

À un format resté lisible aussi longtemps, on peut confier quelque chose qu’on veut retrouver dans dix ans.

Elle est publiée intégralement : n’importe qui peut l’implémenter à partir du document plutôt qu’en l’observant, et c’est pourquoi ce format apparaît dans tant de programmes et pourquoi des fichiers écrits il y a vingt ans s’ouvrent encore. Une spécification publiée n’est pas pour autant libre de redevances : quand un format enveloppe un codec, les brevets sont une question à part, que la norme ne tranche pas.

ICS enregistre son contenu à l’identique. Le réenregistrer ne change rien : vous pouvez l’ouvrir, le modifier et le réenregistrer autant de fois que vous voulez sans accumuler de dégâts, et c’est ce qui en fait un format de travail plutôt qu’un format de livraison.

Google Calendar, Apple Calendar et Microsoft Outlook le lisent, comme la plupart des programmes du même genre.

Quand un fichier ne s’ouvre pas, le format est rarement en cause : le plus souvent, c’est le programme qui est plus ancien que lui. Convertir vers quelque chose de plus ancien est le contournement fiable, et c’est à cela que sert le reste de ce site.

Aucun navigateur ne le lit.

C’est de loin la raison la plus fréquente de le convertir : non pas que le format soit mauvais, mais que l’endroit où vous voulez montrer le fichier ne sache pas le lire.

ICS est fait pour être ouvert et modifié. Gardez le fichier dans ce format tant que le travail dure, et exportez depuis lui chaque fois qu’une version finie est nécessaire.

Un fichier ICS est soit une invitation qu’on vous a envoyée, soit un calendrier auquel vous vous abonnez, et presque tous les problèmes avec ce format commencent par les confondre.

Le premier est l’invitation jointe à un courriel. Il décrit un rendez-vous — ou une petite série — et il est destiné à être ouvert une fois puis importé. Le second est un flux à une adresse web qu’une application d’agenda va chercher de manière répétée : un emploi du temps, un calendrier de matchs, un planning, un calendrier de jours fériés. La structure du fichier est la même dans les deux cas, et la différence d’usage est totale. Un abonnement téléchargé puis importé devient une copie figée qui ne se mettra jamais à jour, ce qui est l’erreur la plus fréquente.

Du texte brut, dans une structure suffisamment ancienne pour en avoir l’air : une propriété par ligne, en majuscules, pliée à 75 caractères avec une convention de continuation qui place une espace au début de la ligne suivante. Chaque événement est encadré par des marqueurs BEGIN et END, avec un début, une fin, un résumé, en général une description et un lieu, ainsi qu’un identifiant unique.

Cet identifiant est l’élément qui se comporte d’une manière que les gens n’attendent pas. C’est par lui qu’un agenda reconnaît une mise à jour comme appartenant à un rendez-vous existant plutôt qu’à un nouveau, donc renvoyer une invitation avec le même identifiant déplace l’original au lieu de créer un doublon. Envoyez-le avec un identifiant neuf et tout le monde a maintenant deux réunions.

Un événement peut enregistrer son heure de trois façons, et elles se comportent différemment. Une heure locale sans fuseau signifie « dix heures là où vous êtes », ce qui convient pour un anniversaire et pas pour une réunion. Une heure en UTC, marquée d’un Z final, est un moment fixe que chaque agenda convertit dans le fuseau du lecteur. Une heure avec un fuseau nommé embarque une définition complète de ce fuseau dans le fichier, de sorte que la conversion reste correcte même au passage à l’heure d’été.

Un rendez-vous qui arrive avec une heure de décalage pour certains participants et pas pour d’autres est presque toujours cela : un événement écrit en heure locale par un système qui supposait tout le monde dans le même pays. Un rendez-vous qui était correct jusqu’au changement d’heure est la même faute à un niveau de plus — un décalage fixe a été enregistré là où un fuseau nommé aurait dû l’être.

La répétition est décrite par une règle plutôt que par l’écriture de chaque occurrence : tous les deux mardis, le dernier vendredi du mois, chaque jour de semaine jusqu’à une date. C’est compact et exact, et c’est la raison pour laquelle un an de stand-ups quotidiens tient en quelques centaines d’octets.

Ce qui complique les choses, ce sont les exceptions. Une occurrence annulée et une réunion déplacée à un autre jour sont toutes deux stockées comme des amendements à la série, et les applications les implémentent avec un degré variable d’exhaustivité. C’est pourquoi déplacer une seule occurrence d’une réunion récurrente déplace parfois toutes les occurrences dans l’agenda de quelqu’un — la règle a survécu au voyage et l’exception non.

Pour un fichier ponctuel, les trois font la même chose : un import qui copie les événements en une fois. Dans Google Agenda, c’est sous Paramètres, Importer et exporter ; dans Outlook, c’est Fichier, Ouvrir et Exporter ; sur Mac, c’est Fichier, Importer. Choisissez l’agenda qui reçoit les événements avant de confirmer, car les séparer ensuite est fastidieux.

Pour un flux, utilisez l’option d’abonnement et donnez-lui l’adresse plutôt qu’un fichier téléchargé. Google l’appelle « Depuis une URL », Apple l’appelle abonnement à un calendrier, Outlook l’appelle « S’abonner depuis le web ». L’agenda va alors le récupérer selon son propre calendrier, que Google et Outlook mesurent en heures et ne vous laissent pas configurer ; Apple expose un menu d’actualisation automatique sur l’abonnement qui descend jusqu’à cinq minutes. Un changement à la source n’est pas visible immédiatement, et c’est normal, pas défaillant.

Tout système qui réserve quelque chose — une plateforme de billetterie, un formulaire de réservation, une inscription à une formation — finit par avoir besoin de joindre un ICS pour que le client puisse le mettre dans son agenda. Trois détails séparent une invitation qui fonctionne d’une qui génère des tickets de support.

Utilisez un fuseau nommé plutôt qu’une heure locale nue, ou un instant UTC si l’événement a un moment unique. Gardez l’identifiant unique stable entre la confirmation, le rappel et l’avis de modification, pour que les mises à jour touchent le rendez-vous existant. Et joignez le fichier avec le bon type MIME — envoyé en pièce jointe binaire générique, les clients de messagerie le montrent comme un fichier à télécharger plutôt que comme une invitation à accepter.

C’est du texte, donc n’importe quel éditeur l’ouvre, et pour un événement unique c’est souvent la manière la plus rapide de voir ce que l’agenda reçoit réellement. La convention de repli de ligne est la seule chose à respecter : une ligne continuée commence par une espace, et retirer cette espace modifie silencieusement la propriété.

L’édition se justifie pour un dépannage rapide — une date erronée, une faute de frappe dans le titre, un résumé à anonymiser avant partage. Pour tout ce qui est structurel, et surtout pour les règles de récurrence, laissez une application d’agenda l’écrire. La syntaxe des règles est précise, le mode d’échec est un événement qui apparaît sur les mauvais jours pendant un an, et personne ne s’en rend compte avant qu’une réunion soit ratée.