Chargement… Loading…
Articles · 06
Architecture, visualization, conflict handling, and multi-screen synchronization for a life trajectories app.
Pendant mon stage au Laboratoire d'Informatique de Grenoble, j'ai travaillé sur CAP2vie, une application web destinée à accompagner des enquêtes sociologiques sur les trajectoires de vie.
L'objectif était de permettre à des enquêteurs de collecter des événements et épisodes de vie, puis de les visualiser sous forme de trajectoires. Le sujet demandait de relier interface de saisie, modèle de données, visualisation temporelle et contraintes réelles d'entretien.
L'application reposait sur deux parties principales :
Une documentation Docusaurus accompagnait le projet pour expliquer l'architecture, les dossiers, le lancement, les routes et les responsabilités des différentes briques.
Le coeur du projet était la notion de trajectoire.
Une personne peut avoir des trajectoires résidentielles, professionnelles ou personnelles. Chaque trajectoire est composée d'épisodes, d'événements, de dates, de niveaux de précision et parfois d'incertitudes.
Le modèle PostgreSQL contenait notamment :
Le back-end utilisait une classe DataAdapter pour transformer les données de la base avant de les envoyer au front-end.
La partie la plus technique était la visualisation des trajectoires.
D3.js était utilisé pour construire un graphique sur mesure : axes temporels, lignes thématiques, rectangles d'épisodes, événements, tooltips, zoom, brush, couleurs par ligne, couples indéterminés et interactions avec l'interface.
Contrairement à une librairie de graphiques prête à l'emploi, D3 demandait de gérer directement les échelles, les positions, les dimensions SVG, les mises à jour et les comportements utilisateurs.
Une difficulté importante venait des conflits temporels.
Lorsqu'un nouvel épisode se chevauchait avec un épisode existant, l'application devait aider l'enquêteur à comprendre le problème et à choisir une action : modifier, raccourcir, remplacer, fusionner ou supprimer.
Plusieurs composants étaient dédiés à ce sujet : Conflict, ConflictEditor, ManualConflict, MultipleConflict, AutoResolveOption, MergeEditor.
Cette logique était essentielle, parce que la qualité scientifique des données dépendait de la cohérence des trajectoires.
L'application distinguait deux moments :
Cette séparation permettait de garder une saisie structurée au départ, puis de laisser de la flexibilité pour traiter les cas complexes.
Socket.io permettait de connecter plusieurs écrans dans une même room.
Cette fonctionnalité servait à synchroniser les données entre l'écran de l'enquêteur et l'écran du répondant. Elle rendait l'outil plus adapté à un entretien réel, où l'enquêteur pilote la saisie tout en pouvant partager une visualisation.
L'historique de développement montre un gros travail de finition :
Le projet a abouti à une version fonctionnelle avec questionnaire, visualisation D3, édition complémentaire, gestion des conflits, synchronisation multi-écrans et documentation technique.
Les vidéos intégrées dans le portfolio montrent les parcours les plus importants : création d'enquête, questionnaire séquentiel, connexion multi-écrans et résolution de conflits temporels.
Ce stage m'a appris à transformer un besoin de recherche en interface utilisable, tout en gardant une base technique lisible pour les personnes qui reprendraient le projet ensuite.