CSV, iCalendar, vCard, PDF et liens : choisir un format qui reste compréhensible

Un format ouvert ne suffit pas : il faut un contrat de sens

Un format documenté améliore l’interopérabilité parce que plusieurs outils peuvent en lire la syntaxe. Il ne définit pas automatiquement le sens des colonnes, la source d’une date, les droits d’accès ni la règle de suppression. Deux exports CSV valides peuvent employer des noms de champs, identifiants et statuts incompatibles.

Le contrat de sens indique version, encodage, colonnes, unités, valeurs autorisées, fuseau, identifiants et relations. Il précise aussi quelles données sont absentes. Une valeur vide peut signifier inconnu, sans objet, supprimé ou non exporté ; ces états ne doivent pas être fusionnés.

Pour un foyer, une notice lisible accompagne l’export. Elle explique comment ouvrir les fichiers, reconstruire les liens et distinguer les données personnelles des références publiques.

• Version du schéma et date d’export
• Encodage et séparateur déclarés
• Dictionnaire des champs
• Fuseau et forme des dates
• Identifiants stables et non secrets
• Valeurs absentes qualifiées
• Pièces et droits décrits séparément

CSV : pratique pour les lignes, fragile pour les relations

La RFC 4180 documente un format courant de valeurs séparées par des virgules et enregistre le type `text/csv`. Elle décrit notamment la ligne d’en-tête facultative, les retours à la ligne et l’usage de guillemets pour les champs contenant virgule, guillemet ou saut de ligne. Elle précise aussi qu’il existe des différences d’interprétation entre implémentations.

Le CSV convient à une table de tâches, contrats ou dépenses lorsque chaque ligne possède un identifiant, des colonnes documentées et des valeurs simples. Il représente mal les pièces jointes, commentaires structurés, droits, relations multiples et historiques. Il faut souvent plusieurs fichiers reliés par des identifiants.

Un tableur peut interpréter une valeur comme formule, transformer un identifiant en nombre ou modifier une date. L’ouverture visuelle n’est donc pas un test suffisant : importez une copie, vérifiez types et accents, puis réexportez pour comparer les valeurs significatives.

iCalendar : échanger des dates sans confondre fichier et synchronisation

La RFC 5545 définit iCalendar pour représenter et échanger événements, tâches, journaux et disponibilités indépendamment d’un service de calendrier. Le format porte des composants, identifiants, dates, durées, règles de récurrence et fuseaux. Un fichier `.ics` peut être importé ou publié ; cela ne signifie pas qu’une synchronisation bidirectionnelle existe.

Pour une échéance administrative, conservez le type de date dans le titre ou une propriété documentée : date d’effet, préavis, action recommandée, rendez-vous ou révision. Un rappel calculé n’est pas la source de la règle. Le lien vers le contrat ou la fiche officielle doit rester distinct et ne contenir aucun jeton secret.

Les récurrences et fuseaux sont des sources fréquentes d’erreurs. Testez une échéance en hiver et en été, une journée entière, une exception et une modification. Lors d’un import, vérifiez si l’outil crée une copie indépendante ou conserve un abonnement actualisable.

vCard : transmettre un contact sans transmettre tout le carnet

La RFC 6350 définit le format vCard pour des fiches de contact. Il peut porter nom, organisation, téléphone, courriel, adresse et URI. Cette richesse ne signifie pas qu’il faut exporter tous les champs. Un contact utile à un contrat peut se limiter à l’organisation, au canal officiel et à une référence de dossier séparée.

Un carnet mélange souvent proches, professionnels, organismes et personnes intervenant dans une démarche. Avant un partage, filtrez la fiche et ouvrez le fichier dans un éditeur de texte pour repérer notes, adresses privées, photos ou identifiants ajoutés automatiquement.

La mise à jour n’est pas automatique après import. Deux copies peuvent diverger. Notez la provenance et la date de vérification du contact, ou préférez un lien vers l’annuaire officiel lorsque sa disponibilité est suffisante.

• Exporter une seule fiche nécessaire
• Retirer notes et champs sans rapport
• Vérifier l’encodage des noms
• Distinguer organisation et personne
• Documenter la date de vérification
• Prévoir la révocation d’un accès partagé

PDF, image et original : préserver lisibilité, provenance et valeur utile

Le PDF est adapté à une vue humaine stable, mais il ne garantit ni l’authenticité, ni la recherche, ni la reprise structurée. Une image peut conserver l’apparence d’un papier tout en perdant texte, signatures vérifiables et métadonnées. Service-Public.fr rappelle qu’une numérisation ou photocopie d’un original papier n’est qu’une copie dans les cas visés par sa fiche.

Conservez l’original selon la catégorie et la règle applicable. Pour un document reçu électroniquement, gardez le fichier fourni et la provenance plutôt qu’une simple capture d’écran. Si le document est signé, ne supposez pas qu’une impression conserve la possibilité de vérifier la signature.

L’accessibilité fait partie de la continuité : un PDF image sans texte peut être impossible à rechercher ou à lire avec une technologie d’assistance. Un nom de fichier explicite et un index séparé améliorent la retrouvabilité sans modifier l’original.

URLs, identifiants et HTTP : référencer sans exposer

La RFC 9110 distingue une ressource de sa représentation et décrit les URI, types de contenu et validateurs comme ETag. Une URL peut identifier une fiche publique ou une ressource privée ; elle ne doit pas devenir un emplacement commode pour un mot de passe, une donnée de santé, un numéro de contrat complet ou un jeton durable.

Un lien vers un portail peut expirer ou exiger une session. Conservez à côté un libellé humain, l’organisme, l’identifiant minimal autorisé et le chemin de reprise. Un code HTTP 200 indique qu’une représentation a été servie, pas que la donnée est à jour ni que l’action métier est terminée.

Les ETag et dates de modification peuvent éviter de retélécharger une représentation inchangée. Ils ne remplacent pas la version métier d’un export ni la preuve qu’une donnée privée a été supprimée.

Nommer, versionner et vérifier sans inventer un système complexe

Un nom de fichier doit aider un humain sans exposer plus d’information que nécessaire. Une structure simple associe catégorie, date pertinente, libellé court et version lorsque plusieurs états doivent coexister. Les dates utilisent une forme non ambiguë, par exemple année-mois-jour, mais le type de date reste documenté.

Un hash peut confirmer que deux fichiers sont identiques octet par octet. Il ne confirme ni l’auteur, ni l’exactitude, ni l’absence de logiciel malveillant. Une signature, une provenance ou un canal officiel répondent à d’autres questions.

Le versionnage doit éviter les chaînes `final-v2-vraiment-final`. Pour un dossier domestique, un registre minimal peut conserver identifiant, version, date, source et statut actuel. L’ancienne version reste archivée seulement si elle est utile ou requise.

Tester un export comme un plan de sortie

Un bouton Export n’établit pas la réversibilité. Le test doit se dérouler sur un petit dossier représentatif comprenant texte accentué, date, récurrence, montant, contact, pièce et relation entre deux objets. Il vérifie l’ouverture sans le fournisseur, la compréhension par un tiers autorisé et la reprise dans un autre outil lorsque c’est nécessaire.

Le résultat peut combiner plusieurs formats : CSV pour les lignes, iCalendar pour les dates, vCard pour quelques contacts, fichiers originaux pour les pièces et notice pour les relations. Un dossier compressé n’est pas auto-descriptif si ses chemins ne sont pas documentés.

Après l’essai, vérifiez aussi la sortie côté service : arrêt de synchronisation, révocation des accès, suppression ou conservation conforme, et récupération possible de la preuve.

1. Choisir un échantillon fictif ou expurgé.
2. Exporter sans modifier les originaux.
3. Contrôler inventaire, version et encodage.
4. Ouvrir chaque format avec un outil indépendant.
5. Reconstituer action, date, pièce, responsable et preuve.
6. Tester un import ou une reprise bornée.
7. Documenter les pertes et décider si elles sont acceptables.
8. Vérifier révocation, conservation et suppression côté service.

Sauvegarder signifie pouvoir restaurer

L’ANSSI recommande d’identifier les données critiques, de définir une politique de sauvegarde et de considérer la sensibilité des copies. Pour un foyer, la proportion reste différente de celle d’une organisation, mais le principe tient : une copie inutilisable ou jamais restaurée ne constitue pas une continuité démontrée.

Séparez l’original actif de la sauvegarde, protégez les supports selon la sensibilité et évitez qu’une suppression ou un logiciel malveillant atteigne toutes les copies simultanément. Une synchronisation instantanée réplique aussi certaines erreurs ; elle n’est pas toujours une sauvegarde versionnée.

Le test de restauration commence par quelques fichiers et leur index. Il vérifie noms, dates, relations, droits et lisibilité avant d’élargir. La fréquence dépend de la vitesse de changement et du coût acceptable de perte.

Sécurité et confidentialité pendant les échanges

Un export rassemble souvent plus de données qu’un écran. Il faut le produire dans un environnement maîtrisé, le transmettre par un canal adapté, limiter ses destinataires et le supprimer des emplacements temporaires. Un fichier CSV ou vCard peut révéler des informations privées même s’il semble être du simple texte.

Les habilitations suivent le besoin réel : consulter une échéance ne donne pas automatiquement accès au contrat complet ; remplacer une personne pendant une semaine ne justifie pas un accès permanent. La CNIL recommande de gérer les habilitations et de les revoir lorsque le besoin change.

La portabilité d’un programme de fidélité concerne des données personnelles dans un cadre défini. Elle ne justifie pas de publier les achats, ni de partager un compte. Le guide courses détaille la séparation entre liste commune, carte et historique.

• Utiliser des données fictives pour tester.
• Chiffrer ou protéger selon le risque.
• Retirer les champs inutiles avant partage.
• Éviter secret et donnée personnelle dans l’URL.
• Révoquer le destinataire après le besoin.
• Supprimer les copies temporaires contrôlées.

MAJORDHOM : ce que le format pourrait permettre, et ce qui manque aujourd’hui

Une future version pourrait relier documents, tâches, dates, contacts et preuves à l’aide d’identifiants stables et d’exports documentés. Cette possibilité constitue un critère de conception, pas une capacité publique actuelle.

La démonstration MAJORDHOM n’importe ni n’exporte de données, ne stocke aucun document réel, ne synchronise aucun calendrier et ne restaure aucune sauvegarde. Elle ne permet donc pas d’exécuter les tests décrits dans ce guide. Les écrans fictifs servent uniquement à comprendre les objets et leurs relations.

Dernière révision humaine : 25 août 2026. Les RFC citées décrivent des formats ou protocoles ; elles ne validentent aucune implémentation MAJORDHOM. Les recommandations de sécurité et les fiches documentaires doivent être adaptées au risque et au document concret.