Aller au contenu
OneKitly

L'export JSON garde trois choses dont le CSV n'a pas la colonne

Publié le 09/09/2026 · 3 min de lecture · Outils fichiers

Daniel Okonkwo

Daniel Okonkwo — Développeur front-end et rédacteur Tech chez OneKitly

Performance web · Formats de fichiers

Vérifié à partir de 3 sources

Voir le profil →
En bref

Les deux exports lisent le même .ics avec le même analyseur, puis divergent sur ce qu'ils savent porter. Le CSV écrit huit colonnes fixes — résumé, début, fin, lieu, description, organisateur, statut, uid — parce qu'un tableur est un rectangle et que chaque événement doit remplir le même. Le JSON écrit chaque événement en objet : un champ que seuls certains événements possèdent apparaît simplement sur ceux-là. En pratique, trois choses survivent au JSON et pas au CSV : tzid, le fuseau nommé dans lequel un début a été écrit ; allDay, le marqueur qui dit qu'une date est une journée entière et non un instant ; et rrule, la règle de récurrence. Une réunion hebdomadaire exportée en JSON revient avec "rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12" attaché, et une entrée de Noël avec "allDay": true. Ni l'un ni l'autre n'a de place dans un tableau. Prends le CSV pour lire et trier ; prends le JSON quand un script, une routine d'import ou un autre agenda va le consommer.

Même fichier, même analyseur, deux sorties. Le tableur reçoit huit colonnes ; le JSON reçoit en plus le fuseau nommé, l'indicateur de journée entière et la règle de récurrence.

Un rectangle contre une forme

Un CSV doit fixer ses colonnes avant d'écrire sa première ligne, et toutes les suivantes ont exactement celles-là. C'est une force quand tu veux trier par date de début ou compter les événements par lieu — un tableur fait cela instantanément, un nid d'objets non. Cela devient une faiblesse dès que les données sont irrégulières, et les données d'agenda le sont par nature : la plupart des événements n'ont pas de récurrence, quelques-uns en ont ; la plupart ont un fuseau, les journées entières n'en ont pas.

Il existe une seconde différence, plus discrète, à connaître quand un script lit la sortie. Dans le CSV, un champ vide est une cellule vide toujours présente ; dans le JSON, un champ facultatif sans valeur peut être absent de l'objet. Écris ton lecteur de façon qu'une clé manquante et une chaîne vide soient traitées pareil, et aucun des deux exports ne te surprendra.

Deux événements, les deux exports, côte à côte
PropriétéDans le CSVDans le JSON
Titre, début, fin, uidOui, quatre des huit colonnesOui
Fuseau nomméPas de colonne"tzid": "Europe/Paris"
Journée entière plutôt qu'un instantPas de colonne"allDay": true
Règle de récurrencePas de colonne"rrule": "FREQ=WEEKLY;BYDAY=MO;COUNT=12"
Un champ videUne cellule vide, toujours présenteUne chaîne vide, ou la clé est absente
ICS en JSONExporte des événements en JSON, chaque horodatage ICS converti en ISO-8601.Essayer l'outil →

Questions fréquentes

Puis-je retransformer le JSON en agenda ?
Pas directement ici — le sens import prend du CSV — mais le JSON est ce qu'il faut donner à un script qui écrit lui-même du .ics, justement parce qu'il porte encore le fuseau, l'indicateur de journée entière et la règle. Si tu veux seulement déplacer un agenda sans le modifier, ne passe par aucun des deux exports : la fusion de fichiers .ics garde tout et évite la question.
Le JSON déplie-t-il les événements récurrents ?
Non, et il ne devrait pas : il porte la règle à la place, ce qui est strictement plus d'information. Un objet avec un rrule de FREQ=WEEKLY;COUNT=12 t'apprend à la fois qu'il y a douze occurrences et comment elles s'espacent, là où douze objets dépliés te donneraient les dates en perdant le fait qu'elles vont ensemble. Le dépliage est le travail de ce qui consomme le fichier.
Lequel faut-il archiver ?
Le .ics lui-même. Les deux exports en sont des lectures, et une lecture laisse toujours quelque chose de côté — le JSON laisse les participants, les alarmes et les pièces jointes, tout comme le CSV laisse le fuseau et la règle. Garde l'original comme référence et génère l'export dont tu as besoin au moment où tu en as besoin.

Articles qui pourraient t'intéresser

Tous les guides →
ExplicationUn événement récurrent fait une ligne dans le CSV, pas douzeUn fichier .ics range une réunion hebdomadaire une seule fois, avec une règle attachée. À l'export CSV tu obtiens une ligne pour toute la série — c'est le fichier qui est honnête, pas le convertisseur qui perd des lignes.ExplicationLe même fichier .ics peut désigner cinq heures différentesL'iCalendar écrit une heure de début de trois façons, et une seule est sans ambiguïté. Une réunion écrite avec un fuseau nommé, convertie sur des machines à Paris, New York et Honolulu, s'est étalée sur dix-neuf heures et a changé de jour.TutorielFabriquer un agenda depuis un planning que tu as déjà dans un tableurEmplois du temps, calendriers de matchs, plannings de garde et programmes de conférence commencent tous leur vie en tableau. Quatre colonnes suffisent à en faire un fichier que toute application d'agenda sait importer.ComparatifDeux e-mails dans une cellule, ou deux chaînes dans un tableauUn contact peut avoir plusieurs numéros et plusieurs adresses. Le CSV les joint par un point médian dans une seule cellule ; le JSON les garde en liste — c'est la différence entre un script qui marche et un script qui découpe au jugé.TutorielFusionner agendas et carnets d'adresses ajoute — cela ne dédoublonne pasLes outils de fusion mettent chaque fiche de chaque fichier dans une seule sortie, dans l'ordre où tu les as donnés. C'est le bon comportement par défaut, et la seule chose à savoir avant d'y verser deux exports du même compte.ExplicationUne adresse vCard a sept morceaux, une colonne de CSV en a unNoms, adresses et sociétés sont des champs structurés dans une vCard. Aplatis-les dans un tableur : ils se lisent à l'identique tout en perdant leurs coutures — ce qui compte dès qu'on refabrique une vCard depuis ce tableur.

Outils similaires

Sources

Tu as repéré une erreur dans cet article ?