Pour compléter ce que j’ai écrit, je vais apporter ici quelques précisions. J’ai d’abord tenté d’exploiter l’export en GEDCOM fourni par Heredis. Mais, il était trop limité et, même avec les extensions introduites par Heredis, je perdais des informations. Comme cette migration date de 2011, je ne me souviens pas de ce qui pouvait manquer, mais il y avait beaucoup de choses. J’ai d’ailleurs regardé s’il était possible d’exploiter ce GEDCOM pour produire un fichier au format XML de Gramps et j’ai écarté cette possibilité. J’ai peut-être encore quelque part un analyseur syntaxique de GEDCOM.
Je me suis donc, à contrecœur, tourné vers la solution consistant à faire un développer un outil de conversion exploitant directement la base Heredis. Et j’ai alors découvert avec horreur que le format utilisé était totalement non standard alors que j’avais espéré quelque chose comme du SQLite.
Mon programme est écrit en Python 2. Il décode le format binaire d’une base Heredis Mac version 2 ou 3 (peut-être au delà, mais j’ai abandonné Heredis après le basculement), construit un modèle en mémoire, puis produit un fichier XML au format Gramps dans la version d’alors (DTD 1.4.0 – depuis, pas mal de choses ont changé, notamment l’apparition des citations et la structure hiérarchique des lieux).
Cela représente 3200 lignes de Python, donc ce n’est pas très gros (4100 lignes si on inclut un module permettant de produire du GEDCOM au lieu du XML – je ne me souviens plus pourquoi j’avais prévu cette fonction, peut-être au cas où j’aurais voulu basculer sur un autre logiciel travaillant en pur GEDCOM).
Le point critique, c’est effectivement le moyen de s’assurer que le résultat est correct. Malheureusement, il n’y a pas vraiment de solution. Je produisais des statistiques permettant de vérifier que tout avait été traité, mais il a fallu contrôler la validité par échantillonnage.
En pratique, on pouvait surtout craindre que certaines informations n’aient pas été traitées. Par exemple, Heredis Mac permettait de préciser si un individu sait signer. Pour ne pas perdre cette information, il a fallu définir un attribut spécifique. Incidemment, je pense maintenant que ce n’est pas la bonne solution ou, du moins, que cette information est insuffisante et devrait être modulée (sait signer, signe parfois, ne sait pas signer, utilise une marque spécifique). On pourrait aussi utiliser un événement plutôt qu’un attribut.
Je n’ai pas traité tout ce que savait faire Heredis, mais uniquement ce que j’utilisais. Je me souviens d’avoir ignoré une fonction introduite par Heredis 3 que je n’utilisais pas (j’ai oublié laquelle). Et, par exemple, lors de l’exportation j’ai ignoré le champ « rechercher l’acte » que j’avais parfois utilisé, mais que je trouvais peu pratique et ne souhaitais pas reprendre dans Gramps (je préfère gérer des listes externes d’actes à rechercher avec éventuellement un commentaire associé).
J’ai donc passé un temps certain à vérifier la généalogie obtenue après conversion. Ma première tentative (après les nombreux tests unitaires réalisés), m’a permis de trouver quelques erreurs ou omissions que j’ai corrigées. Si je me souviens bien, la seconde conversion a été la dernière. Je n’ai pas souvenir d’avoir détecté la moindre erreur ensuite, mais, comme je l’ai dit, ce n’est pas un programme compliqué. Il y a seulement plein de choses auxquelles il faut penser. Et c’est donc le travail préparatoire qui a été le plus important. Il a été facilité (si on peut dire
) par le fait que je devais analyser dans le détail la structure des enregistrements dans le fichier binaire et j’ai donc activé (unitairement) tout ce que je pouvais activer (sauf la fonction que je n’utilisais pas).
Pour information, quand j’ai fait cette migration, ma généalogie contenait environ 2000 individus. Je n’ai donc pas rencontré de problème de stockage en mémoire. Mais avec ma machine d’alors, j’avais déjà suffisamment de mémoire et je pense que j’aurais pu traiter sans problèmes une généalogie de quelques dizaines de milliers d’individus.
