8. Échanger des données

8.1. Format GEDCOM

8.1.1. Bases

Un fichier GEDCOM est un fichier pour les échanges de données généalogiques.

C'est un fichier de texte brut, lisible par n'importe quel éditeur de texte.  Le fichier est donc lisible par un humain, mais ce n'est pas le but car il est fait pour être relu par un autre logiciel de généalogie.  Voici un fichier typique avec quelques fiches:
0 HEAD
1 SOUR PAF
2 NAME Personal Ancestral File
2 VERS 4.0.4.18
2 CORP The Church of Jesus Christ of Latter-day Saints
3 ADDR 50 East North Temple Street
4 CONT Salt Lake City, UT 84150
1 DEST PAF
1 DATE 1 MAR 2006
2 TIME 16:30:18
1 FILE exemple.ged
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR ANSEL
1 LANG French
1 SUBM @SUB1@
 En-tête du fichier
0 @SUB1@ SUBM
1 NAME Denis Beauregard
1 ADDR Ligne 1
2 CONT Ligne 2		 Soumis par
0 @I1@ INDI
1 NAME Zacharie /Cloutier/
2 GIVN Zacharie
2 SURN Cloutier
1 SEX M
1 BIRT
2 DATE ABT 1590
2 PLAC Mortagne-au-Perche,Orne,61293,France
1 DEAT
2 DATE 17 SEP 1677
1 BURI
2 DATE 18 SEP 1677
2 PLAC ChÒateau-Richer,QuÔebec
1 FAMS @F1@
1 CHAN
2 DATE 1 MAR 2006
3 TIME 16:28:33		 Individu no 1
0 @I2@ INDI
1 NAME Sainte /Dupont/
2 GIVN Sainte
2 SURN Dupont
1 SEX F
1 FAMS @F1@
1 CHAN
2 DATE 1 MAR 2006
3 TIME 16:29:07		 Individu no 2
0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 DATE 18 JUL 1616
2 PLAC Mortagne-au-Perche,Orne,61293,France		 Famille no 1
0 TRLR Fin du fichier

Exemple de fichier Gedcom avec explications

8.1.2. Problèmes avec le français

La norme GEDCOM évolue avec les années.  Elle est associée au logiciel PAF et les deux proviennent des Mormons (église de Jésus-Christ des Saints du Dernier Jour, SDJ ou LDS en anglais).  Comme la grande majorité des Mormons est anglophone, PAF a été conçu en fonction de l'anglais jusqu'à la version 4 qui a été la première à permettre des accents.  La norme GEDCOM a évolué en parallèle.  La version courante (5.5)  permet les accents à condition de définir le jeu de caractères utilisé, soit ANSEL ou ANSI.  Pendant longtemps, on a aussi accepté le jeu DOS (ou PC-DOS) jusqu'à ce qu'on s'aperçoive lors d'un échange entre un Québécois et un Polonais dans une liste spécialisée que DOS avait des jeux de caractères différents selon la langue.  En d'autres mots, un caractère comme le é peut devenir autre chose si le même fichier est lu sur un ordinateur polonais.  Le gestionnaire de la norme a alors retiré le jeu des caractères DOS.

Si deux logiciels suivent la dernière version de la norme, en théorie, il n'y a aucun problème et les accents vont suivre.  Mais il arrive souvent que les programmeurs aient une opinion bien personnelle sur la façon de gérer les accents ou oublient de moderniser leur logiciel.  Il s'en suit que parfois le fichier date de quelques années et que les accents se perdent.  La solution est alors de lire le fichier avec un éditeur de texte et de s'en servir pour convertir les accents.  Ainsi, on peut le lire avec un vieux Word 6 (mais pas Word 97) en choisissant les accents DOS, puis l'enregistrer en format Word, puis l'enregistrer une 2e fois en format texte brut avec les accents Windows (qui sont près des accents ANSI).  Il faut ensuite remplacer la ligne [1 CHAR] pour avoir [1 CHAR ANSEL].

Un autre problème est celui des dates.  La vraie norme GEDCOM dit que la date doit avoir le format 2 DATE 1 JAN 2006.  En d'autres mots, un ou deux chiffres, le mois en anglais et en majuscules et l'année au complet.  Certains logiciels mal conçus utilisent le mois en français et même l'accent, comme 2 DATE 1 fév 2006, ce qui est contraire à la norme.  Si le logiciel de réception n'est pas prévu, il faut alors modifier les dates à la main en éditant le fichier GEDCOM.

8.1.3. Autres problèmes typiques

Il y a des centaines de logiciels de généalogie et sans doute beaucoup de façon de produire ou de lire un fichier GEDCOM.  Certains définissent leurs propres sous-structures (comme une pierre tombale ou une description médicale).  D'autres vont placer à la suite des fichiers ou images.  D'autres peuvent redéfinir certaines étiquettes, par exemple MARC au lieu de CMAR pour les contrats de mariage.  La liste est assez longue et l'on pourrait faire un musée des horreurs avec toutes ces particularités.  Le mieux est de se rappeler qu'un export GEDCOM n'est pas toujours complet (certaines données ne seront pas enregistrées) et qu'un import GEDCOM est rarement parfait.  Pour les données les plus critiques, comme une explication un peu longue d'une filiation compliquée, il est préférable d'avoir un texte à l'extérieur du ficheir.

8.1.4. Utilités du format GEDCOM

Le GEDCOM étant imparfait, il a tout de même un certain nombre d'utilités.  Ainsi, il permet l'emploi de logiciels indépendants pour la saisie des données, l'impression de livres, la recherche et la génération d'un site web.  Même si la plupart des logiciels récents offrent toutes ces fonctionnalités, plusieurs préfèrent tel ou tel logiciel spécialisé où la saisie est plus facile ou encore dont les rapports sont plus près de ce que l'on recherche.  Dans ce contexte, le GEDCOM remplit son rôle de fichier d'échanges de données.

Certains logiciels ont maintenant recours à d'autres moyens pour récupérer les données d'un autre logiciel.  Ainsi, TMG (The Master Genealogist) a développé une telle technologie (GenBridge) pour pouvoir récupérer des données provenant de Family Gathering™, Family Origins™, Family Tree Maker™, Generations™, Legacy™, Personal Ancestral File™, Personal Ancestral File™, Roots IV™, Roots V™, Ultimate Family Tree™ et Visual Roots™.  Voir cette page pour un exemple de données perdues si on utilisait plutôt un fichier GEDCOM.

8.2. Formats propriétaires et personnels

Il y a beaucoup de raisons pour échanger des informations dans le domaine de la généalogie et il ne s'agit pas toujours de données généalogiques reliées.  Ainsi, on peut envoyer une liste de villes ou des actes de mariage qui ne sont pas interreliés.  Pour un envoi de données d'une base de données à une autre, il est préférable d'utiliser un format non-propriétaire.

Pour lire une base de données Access, il faut le logiciel Access.  De même, pour lire un fichier Excel, il faut le logiciel Excel.  Il en va de même pour Filemaker Pro, mySQL, etc.  Chaque format a ses caractéristiques, même si parfois un logiciel permet de lire des données fournies dans un autre format.  Un format propriétaire est un format qui appartient à un logiciel (ou plus précisément aux concepteurs d'un logiciel).  Quand le logiciel évolue, il est difficile ou impossible de revenir en arrière.  Ainsi, Excel 5, limité à des fichiers de 8192 lignes, ne peut pas lire un fichier de Excel 97 avec 32768 lignes.  Par contre, avec Excel 97, on peut générer un fichier avec le format Excel 5, ce qui peut entraîner la perte de certaines informations (en général, la mise en page).

Quand on envoie des données à quelqu'un d'autre, il faut s'assurer au préalable que le récipiendaire pourra lire ces données.  Quelqu'un utilisant Windows 98 ou Linux ne pourra pas lire un fichier en format Filemaker Pro 7.  Et dans 10 ans, il est même possible que plus personne ne pourra lire certains formats car en évoluant, les logiciels ne conservent pas toujours de compatibilité avec toutes leurs versions antérieures.  Ainsi, des sauvegardes faites sur des disquettes de 8 pouces ne sont plus accessibles et des textes en Wordstar donnent un bon mal de tête à celui qui veut les relire depuis Windows XP.

C'est pourquoi il est préférable d'éviter les formats propriétaires (et personnels) quand on envoie des données et d'utiliser le plus bas dénominateur commun.  En général, cela signifie qu'il faudra envoyer des fichiers de bases de données sous la forme de texte tabulé (les champs sont séparés par des tabulateurs) ou parfois en CSV (les champs sont séparés par les points-virgules).  De cette façon, les données seront toujours lisibles.  La seule ombre, c'est le jeu de caractères et dans cette optique, on choisit en général la norme ISO 8859-1 (ou 8859-15), ou sinon Windows 1252 (celle par défaut sur les ordinateurs Windows récents),  8859-15 définit le caractère Euro alors que Windows 1252 a quelques petites différences avec 8859-1.

La situation est similaire pour des textes.  Ainsi, pour discuter du contenu d'un article, on peut coller le texte directement dans le message (au lieu de l'attacher) et chaque collaborateur pourra corriger le texte sans utiliser de logiciel externe.  Si vous envoyez un article pour informer un correspondant, il est donc préférable de coller le texte dans le message.  Par contre, s'il s'agit d'une présentation un peu plus sophistiquée, un texte avec des caractères en gras par exemple, il faut réfléchir un peu.  Si ce texte est pour une publication (sur le web ou dans une revue), on préférera un fichier attaché dans le format le plus universel (qui est en ce moment du Word 97 ou du RTF).  Si c'est pour donner une information qui ne sera pas republiée, le format PDF est préférable.  Finalement, si on travaille sur un site web et qu'on veut publier à cet endroit, le format HTML sera choisi.  Dans tous les cas, il faut se rappeler que certains filtres anti-virus peuvent refuser un fichier attaché.