Cœur de Famille : arbre généalogique ou souvenirs, quelle navigation choisir ?

Dans une application familiale qui associe arbre généalogique et souvenirs, la navigation est déjà un choix de produit : faut-il commencer par les liens entre les personnes ou par les moments racontés ? Un arbre aide à situer quelqu’un dans une famille. Un fil de souvenirs invite plutôt à retrouver une photo, un récit ou une période. Les deux entrées peuvent coexister, mais elles ne doivent pas se faire concurrence ni promettre la même chose.

Pour un projet comme Cœur de Famille, mieux vaut donc comparer ces modèles à partir des tâches des utilisateurs, puis décider comment passer de l’un à l’autre. L’enjeu est concret : éviter qu’un visiteur qui cherche une personne se perde dans des souvenirs, ou qu’un récit soit difficile à retrouver parce qu’il est enfoui dans une structure généalogique.

Une navigation par arbre : partir des personnes et des liens

L’arbre généalogique convient lorsque l’utilisateur sait qui il cherche, ou veut comprendre comment plusieurs personnes sont liées. Il rend visibles des relations qui seraient moins faciles à parcourir dans une suite de pages : parents, enfants, fratries ou branches familiales. Il donne ainsi une structure stable à l’exploration.

Cette logique a toutefois un coût d’usage. Une personne peut ne pas connaître les noms, les liens exacts ou la génération à consulter. Un arbre très étendu devient aussi difficile à parcourir sur un petit écran. Enfin, si chaque élément n’est accessible qu’en ouvrant des branches successives, la navigation peut sembler laborieuse pour quelqu’un qui veut simplement retrouver un souvenir partagé.

Cette entrée fonctionne donc mieux quand les relations entre personnes sont fiables, compréhensibles et suffisamment renseignées. Si les données sont incomplètes, l’interface doit le rendre clair : une branche vide ne devrait pas donner l’impression que l’utilisateur a mal cherché.

Une navigation par souvenirs : partir d’un moment ou d’un récit

Un fil chronologique, une collection thématique ou une recherche dans les souvenirs répond à une autre intention : retrouver un événement, parcourir une période ou découvrir des récits sans connaître à l’avance toute la structure familiale. Cette porte d’entrée peut convenir à un utilisateur qui se rappelle une fête, un lieu ou une époque, mais ignore quelle personne ou quelle branche ouvrir.

Le risque est inverse. Un souvenir peut être difficile à retrouver si sa date, ses personnes associées ou son thème ne sont pas renseignés de façon cohérente. Une chronologie n’est pas forcément complète, et l’ordre des contenus ne suffit pas toujours à expliquer qui apparaît dans un récit. Il faut donc prévoir des repères : personnes associées, dates approximatives lorsqu’elles sont connues, thèmes ou lieux, sans présenter une information incertaine comme un fait établi.

Cette option demande aussi de cadrer les règles de contribution et de visibilité. Qui peut ajouter ou corriger un souvenir ? Comment distinguer une information vérifiée d’un récit transmis par un membre ? Ces questions touchent à la confiance autant qu’à l’interface.

Une scène fictive pour tester les deux parcours

Imaginons, à titre d’exemple fictif, qu’une personne veuille retrouver le récit d’un repas de famille, sans se rappeler l’année ni savoir quelle branche de l’arbre consulter. Dans une navigation uniquement généalogique, elle doit d’abord identifier une personne, puis explorer les contenus qui lui sont associés. Si elle se souvient surtout d’un lieu ou d’une période, le point de départ risque de ne pas correspondre à sa mémoire.

Dans une navigation uniquement chronologique, elle peut parcourir les souvenirs par période, mais devra peut-être examiner de nombreux contenus avant de reconnaître les personnes concernées. Un modèle combiné permettrait de commencer par le souvenir, puis d’ouvrir la fiche d’une personne associée, ou de partir d’une personne et de filtrer ses souvenirs. Ce scénario ne prouve pas qu’un parcours hybride sera toujours le meilleur : il fournit un cas précis à tester avec des utilisateurs représentatifs.

Comparer les modèles selon les tâches, pas selon leur apparence

Avant de choisir une navigation, l’équipe peut comparer les options sur des tâches observables. Une maquette suffit à faire discuter les parcours ; elle ne remplace pas les retours de personnes qui correspondent aux usages visés.

• Retrouver une personne connue : l’arbre, une recherche par nom ou une liste de personnes sont-ils plus directs ?
• Explorer une relation : peut-on comprendre le lien sans devoir interpréter des symboles ou des abréviations ?
• Revenir à un souvenir : peut-on chercher par période, thème ou personne associée, si ces informations existent ?
• Parcourir sans objectif précis : l’interface propose-t-elle une exploration compréhensible sans imposer une longue suite d’actions ?
• Comprendre les incertitudes : les dates approximatives et les liens à confirmer sont-ils signalés sans ambiguïté ?
• Utiliser l’interface sur différents écrans : l’arbre reste-t-il lisible sur mobile, ou faut-il proposer une vue alternative ?

Cette comparaison aide à éviter un faux arbitrage entre deux représentations séduisantes. La bonne question est plutôt : quelle entrée réduit l’effort pour chaque tâche, et quelle information doit rester accessible quel que soit le parcours ?

Le modèle hybride : utile si les passerelles sont explicites

Proposer deux entrées ne suffit pas à créer une navigation cohérente. Les transitions doivent être visibles et prévisibles : depuis un souvenir, rejoindre les personnes qui y sont associées ; depuis une personne, consulter ses souvenirs ; depuis une relation, comprendre pourquoi elle est affichée. Chaque retour doit préserver le contexte afin que l’utilisateur ne reparte pas de zéro.

Il faut également décider ce qui se passe quand une donnée manque. Un souvenir sans date précise peut rester accessible par son thème ou ses personnes associées. Une relation non confirmée peut être présentée comme telle, ou ne pas être affichée comme certaine. Ces règles appartiennent au fonctionnement du produit, pas seulement à son habillage visuel.

La portée du projet et les coûts à estimer découlent de ces choix. Une recherche multicritère, la gestion des contributions, les droits de visibilité, l’édition des relations et la compatibilité mobile ajoutent des besoins de conception, de développement et de validation.

Pour cadrer ces arbitrages, un cahier des charges informatique utile peut distinguer les besoins indispensables des pistes à tester, sans figer trop tôt une solution technique.

Les livrables à demander avant de valider la navigation

Une équipe ou un prestataire devrait rendre ses choix discutables et vérifiables. Le livrable attendu n’est pas seulement un écran : il doit montrer comment la navigation répond aux tâches, aux données incomplètes et aux différents supports.

• Une liste de tâches prioritaires, formulées du point de vue des utilisateurs.
• Des maquettes des entrées par arbre et par souvenirs, avec leurs principales passerelles.
• Des règles explicites pour les dates incertaines, les liens manquants et les corrections.
• Un prototype permettant d’essayer les parcours sur ordinateur et sur mobile.
• Un compte rendu des retours recueillis, avec les limites de l’évaluation.
• Une estimation séparant conception, réalisation, recherche, gestion des contributions et maintenance.

La qualité des parcours dépend aussi de la diversité des situations prises en compte. Les retours d’utilisateurs peuvent révéler des obstacles de vocabulaire, de lisibilité ou de compréhension ; le dossier sur l’inclusion dans les projets numériques donne des repères pour intégrer ces enjeux au pilotage.

Pour Cœur de Famille, l’arbre et les souvenirs sont donc deux portes d’entrée complémentaires, à condition que chaque tâche ait un chemin clair et que les passerelles expliquent les liens entre les contenus. Commencez par décider ce que l’utilisateur vient faire, puis comparez les parcours sur des scénarios concrets. Le choix de l’interface pourra ensuite s’appuyer sur des besoins explicites plutôt que sur une préférence esthétique.