Arbre A
Camille Martin
Nom de naissance : Martin
- Naissance
- 1978
- Partenaire
- Noah Bernard
- Parent déjà rapproché
- Marie Martin
- Enfant
- Non renseigné
Conception produit · Étude de cas
Des données reliées.
Des décisions maîtrisées.
Un outil pour construire, explorer et fusionner des graphes familiaux. Un projet pour rendre les règles, les ambiguïtés et les décisions humaines explicites.
Capture locale du 6 octobre 2026 · Produit en évolution
Le domaine : la généalogie
L’enjeu : la cohérence des données
Le fil conducteur : la décision humaine
01 / L’enjeu métier
Deux arbres.
Plus qu’une addition.
Une même personne peut porter deux noms. Deux homonymes peuvent être deux personnes différentes.
Les branches sont parfois incomplètes ; les portraits ou les relations peuvent se contredire. Réunir ces travaux demande de distinguer ce qui se complète, ce qui se ressemble et ce qui exige un arbitrage.
Une suggestion ne prouve pas une identité.
Le score aide à comparer. La personne qui utilise le Studio décide du rapprochement.
02 / Un cas concret
Rapprocher sans décider à votre place.
La fusion de deux arbres indépendants sert ici de cas d’étude : chaque automatisation a une limite fonctionnelle explicite.
Simulation pédagogique · Données fictivesIdentité à examiner
Arbre B
Camille Durand
Nom de naissance : Martin
- Naissance
- 1979
- Partenaire
- Romain Durand
- Parent déjà rapproché
- Marie Martin
- Enfant
- Alex Durand
Après comparaison, que décidez-vous ?
Le nom de naissance et le parent commun sont des indices. Ils ne suffisent pas à établir une identité. Sans confirmation, les deux personnes restent distinctes.
- 1 Nom
- 2 Portrait
- 3 Date
- 4 Liens
Étape 1 sur 4
Quel nom conserver ?
Les deux noms diffèrent : le choix du nom affiché vous revient.
Tous les arbitrages sont explicites.
Le résultat reprend vos choix. Le parent commun est réunifié et la branche complémentaire d’Alex est conservée.
Ce parcours illustre les décisions du Studio sur un cas fictif. Il n’exécute pas son moteur de fusion et ne modifie aucun arbre.
- 01
Proposer
Présenter les rapprochements possibles et leurs indices.
- 02
Confirmer
Accepter ou refuser chaque identité. Garder les décisions visibles.
- 03
Arbitrer
Conserver les éléments compatibles. Choisir face aux divergences.
- 04
Contrôler
Prévisualiser et vérifier la cohérence du résultat, sans écraser les sources.
Une branche absente peut être une branche incomplète : un enfant présent dans un seul arbre est conservé par défaut. La cohérence du fichier ne certifie pas la vérité de la généalogie.
03 / La responsabilité fonctionnelle
Je conçois les règles.
Je confronte le résultat au besoin.
Je définis les concepts, les scénarios et les limites. Je formalise les décisions dans des briefs exploitables, puis je teste les comportements et révise la solution lorsque l’usage révèle un écart.
Conception & validation
Analyse du besoin, modélisation, règles métier, arbitrages, spécifications et retours après essai.
Implémentation assistée
Traduction des briefs en code, corrections et vérifications automatisées. Les décisions fonctionnelles restent sous responsabilité humaine.
04 / La méthode
Formaliser. Tester. Réviser.
Une boucle de travail documentée, du besoin au comportement observé.
- 01ClarifierBesoin & scénarios
- 02FormaliserModèle & règles
- 03Faire réaliserBrief & implémentation
- 04ConfronterTest humain & révision
Une itération réelleQuand un test change la règle de fusion
- Observation humaine. Lors d’un essai, l’ordre des cartes change et les liens complémentaires imposent trop de décisions.
- Critères précisés. Stabiliser les cartes, comparer les proches et distinguer ajout compatible et conflit réel.
- Correction assistée. Codex rapporte ces changements ; les enfants présents dans une seule source sont conservés par défaut et restent retirables.
- Vérification distincte. L’évolution est appréciée après essai ; les contrôles automatiques sont consignés. Cela ne constitue pas une recette exhaustive.
Synthèse des échanges du 24 septembre 2026 et du journal privé de décisions. Les traces détaillées restent privées.
05 / Ce que la démarche démontre
Un domaine concret.
Une méthode transférable.
La généalogie est le terrain d’application. L’analyse, la spécification et la recette sont mobilisables dans des projets de systèmes d’information, notamment ERP.
| Dans HoloGraph Studio | Compétence mobilisée |
|---|---|
| Personnes, relations et faits | Modélisation fonctionnelle |
| Règles de rapprochement | Analyse & spécification |
| Données contradictoires | Qualité & gestion des exceptions |
| Scénarios et retours d’essai | Recette fonctionnelle |
| Briefs et corrections successives | Pilotage des évolutions |
À vous d’explorer
Le produit d’abord.
La profondeur, si vous le souhaitez.
01Essayer HoloGraph StudioExplorer le produit manipulable (nouvel onglet)02Lire la documentation de conceptionNomenclature produit · Les quatre documents de référence (nouvel onglet)
03Preuves techniques & historiqueLe dépôt public GitHub du StudioLien à venir