Réalisations

Développement d'une application web de trajectoires de vie

Conception d'une application de questionnaire sociologique avec visualisation de données D3.js sur mesure au Laboratoire d'Informatique de Grenoble.

Stage (recherche universitaire)Vue.jsJavaScriptD3.jsPostgreSQLRecherche

Preuves visuelles

Captures et démonstrations issues des projets réels.

Choix du profil utilisateur
Écran d'entrée permettant de choisir entre le rôle enquêteur et le rôle enquêté.

Espace enquêteur
Interface locale de l'application CAP2vie montée depuis le dépôt de stage.

Création d'une enquête

Parcours de création d'une enquête sociologique dans l'application CAP2vie.

Questionnaire séquentiel

Interface de saisie guidée permettant aux enquêteurs de collecter les données de trajectoire.

Connexion multi-écrans

Synchronisation temps réel entre écrans via Socket.io pour faciliter la conduite d'entretien.

Gestion des conflits de dates

Exemple de résolution d'incohérences temporelles lors de la saisie des trajectoires.

Présentation

Un stage de cinq mois pour valider une formation de concepteur-développeur.
J'ai réalisé ce projet de mai à septembre 2024 dans le cadre de ma formation de Concepteur développeur d'applications. Ce titre professionnel est enregistré au Répertoire national des certifications professionnelles, ou RNCP, au niveau 6, correspondant au niveau licence ou bac +3. Le stage devait me placer en situation de concevoir une application complète et non uniquement d'exécuter une série de tâches techniques isolées. Il constituait donc à la fois une expérience professionnelle et la mise en pratique des compétences de conception, de développement et de préparation d'une première livraison acquises pendant la formation.
Un projet accueilli au Laboratoire d'Informatique de Grenoble.
Le stage s'est déroulé au Laboratoire d'Informatique de Grenoble, généralement désigné par le sigle LIG. Il s'agit d'un laboratoire de recherche en informatique rattaché notamment à l'Université Grenoble Alpes, au CNRS et à Grenoble INP. Je travaillais dans le bâtiment IMAG du domaine universitaire de Saint-Martin-d'Hères. L'IMAG est un lieu qui accueille le LIG et plusieurs de ses équipes ; ce n'était pas le nom de mon équipe. Cette distinction permet de situer correctement le projet dans un environnement de recherche universitaire sans lui attribuer une structure que je ne peux pas confirmer.
Un encadrement par une professeure-chercheuse travaillant sur les usages sociologiques.
Je travaillais sous la direction d'une professeure-chercheuse qui participait à la conception d'outils destinés aux études sociologiques. Une professeure-chercheuse partage son activité entre l'enseignement universitaire et la production de connaissances par la recherche. Son rôle dans le projet était d'apporter le besoin scientifique, la connaissance de la méthodologie d'enquête et la vision des futurs usages. Mon rôle était de transformer cette idée en un premier système interactif que des spécialistes de la sociologie pourraient observer, manipuler et critiquer.
CAP2vie, un nom construit autour du « cap de vie ».
Le nom CAP2vie évoque littéralement le cap suivi par la vie d'une personne, autrement dit la direction prise par son parcours au fil du temps. Le projet ne cherchait pas à réduire une personne à une donnée unique. Il devait représenter une histoire constituée d'événements, de changements et de relations entre plusieurs dimensions de l'existence. Le nom résume donc l'objet central de l'application : rendre une trajectoire compréhensible tout en conservant son évolution chronologique.
La trajectoire de vie comme objet d'étude.
En sociologie, une trajectoire de vie peut être comprise comme l'histoire et la direction du parcours d'une personne observées à travers plusieurs dimensions classiques. Elle peut inclure les lieux où la personne a vécu, sa scolarité et ses études, sa carrière professionnelle, sa situation familiale, les personnes importantes qu'elle a connues et ses déplacements géographiques. L'intérêt ne vient pas seulement de chaque événement pris séparément, mais de leur enchaînement : quand une étape a commencé, combien de temps elle a duré, ce qui s'est produit en parallèle et comment une transition a pu en influencer une autre.
Un outil pour comparer des parcours et éclairer des décisions.
L'objectif scientifique général était de mettre à la disposition des professeurs et des sociologues enquêteurs des outils plus modernes pour recueillir puis étudier des trajectoires. En comparant plusieurs parcours, les chercheurs peuvent rechercher des concordances, c'est-à-dire des situations ou évolutions qui se retrouvent chez plusieurs personnes, puis construire des hypothèses sur les facteurs qui les accompagnent. À titre d'illustration, une étude pourrait observer les modes de transport employés par des étudiants de 18 à 25 ans vivant à Grenoble pour rejoindre l'université, puis utiliser ces observations afin d'éclairer des politiques de mobilité. Cet exemple explique la finalité possible de la méthode ; il ne constitue pas un résultat produit par CAP2vie pendant mon stage.
Le remplacement d'un recueil principalement effectué sur papier.
Avant l'application, les informations étaient recueillies au moyen de formulaires papier. Ce support permet de conduire une enquête, mais il devient difficile à maintenir lorsque les questions évoluent et complexe à analyser lorsque plusieurs trajectoires doivent être rapprochées. Les réponses doivent être relues, retranscrites et restructurées avant de pouvoir alimenter une visualisation ou une comparaison. Le projet cherchait donc à numériser le recueil dès l'entretien et à produire une représentation organisée au fur et à mesure, sans attendre une reprise manuelle complète après chaque enquête.
Une utilisation prévue pendant des entretiens en présentiel et sur le terrain.
CAP2vie était destiné à accompagner une rencontre réelle entre un enquêteur et une personne interrogée, que l'entretien se déroule dans un environnement universitaire ou directement sur le terrain. L'application n'était pas pensée comme un questionnaire automatique rempli seul à distance. Elle devait soutenir la méthodologie du sociologue, qui adapte l'ordre ou la formulation de ses questions et peut demander des précisions. L'interface devait donc rester un outil au service de l'échange plutôt qu'imposer un parcours rigide qui remplacerait la conduite humaine de l'entretien.
Deux rôles complémentaires dans le même entretien.
L'enquêteur était le sociologue chargé de poser les questions selon sa méthodologie et d'enregistrer les éléments utiles. La personne enquêtée répondait aux questions portant sur son histoire. Cette séparation était matérialisée dans l'application par des interfaces adaptées aux deux rôles. L'enquêteur avait besoin des commandes permettant de conduire et structurer le recueil, tandis que la personne interrogée devait pouvoir comprendre la représentation de son parcours sans accéder aux fonctions de gestion de l'enquête.
Une visualisation partagée sur plusieurs écrans.
Le fonctionnement multi-écrans permettait à la personne enquêtée de voir sa trajectoire se construire pendant que le sociologue posait les questions et saisissait les réponses. Cette mise à jour simultanée transformait le graphique en support de dialogue : l'enquêté pouvait reconnaître son histoire, signaler une incompréhension ou apporter une précision lorsqu'un événement apparaissait au mauvais moment. La synchronisation devait donc transmettre les modifications de l'interface enquêteur vers l'écran de consultation sans obliger les deux personnes à manipuler le même appareil.
Des questions organisées autour du contenu et du contexte des événements.
Le questionnaire devait recueillir les éléments nécessaires pour comprendre une trajectoire : ce qui s'est produit, à quel moment, dans quel lieu, de quelle manière et pour quelle raison selon le récit de la personne. Ces questions pouvaient concerner les études, le travail, la famille, les relations importantes ou les lieux d'habitation. L'application devait conserver les réponses dans une structure exploitable tout en respectant la logique de l'entretien. Elle ne devait pas présenter une interprétation sociologique comme une vérité automatique : l'analyse restait de la responsabilité des chercheurs.
Des informations sensibles nécessitant une anonymisation après l'enquête.
Une trajectoire de vie peut révéler des informations personnelles sur la famille, les lieux fréquentés, les relations, les études ou la carrière. Le processus de recherche prévoyait donc que les données soient anonymisées après l'entretien afin que les réponses exploitées ne restent pas directement associées au nom ou au prénom de la personne. L'anonymisation consiste à retirer ou transformer les éléments permettant une identification directe. Le prototype n'automatisait toutefois pas encore cette opération dans l'application : la conception d'un mécanisme intégré, vérifiable et adapté aux données recueillies faisait partie des sujets laissés à une version ultérieure.
Un projet commencé à partir d'une idée et non d'un logiciel existant.
À mon arrivée, l'équipe disposait de l'idée de l'outil, mais pas d'une application, d'un dépôt de code ou d'un prototype que je pouvais simplement compléter. Je suis donc parti de zéro. Cette situation m'a obligé à passer d'un besoin exprimé dans le vocabulaire de la recherche à une organisation concrète des écrans, des données et des échanges entre les composants. Le prototype devait aussi rendre visibles les questions encore ouvertes : une première interface manipulable permettait aux chercheurs de préciser un besoin qui aurait été difficile à décrire entièrement avant toute réalisation.
Un périmètre transversal entre visualisation, backend et temps réel.
Le prototype était développé par une équipe de trois stagiaires. Mes deux collègues prenaient principalement en charge le formulaire et la base de données, tandis que je développais le backend, la visualisation D3.js et l'interconnexion Socket.io. Le backend reçoit les demandes et applique la logique serveur ; D3.js transforme les réponses en représentation interactive dans le navigateur ; Socket.io synchronise cette représentation entre les écrans. Mon périmètre reliait donc plusieurs couches essentielles sans pour autant inclure tous les développements du prototype.
Une stack technique choisie collectivement pour construire le premier prototype.
L'équipe de développement a sélectionné les technologies en fonction du besoin et de ses connaissances. Nuxt 3 et Vue 3 structuraient l'interface Web ; Express.js exposait les fonctions serveur ; Prisma reliait le code à PostgreSQL, le système de base de données relationnelle ; D3.js permettait de construire une visualisation de trajectoire sur mesure ; Socket.io transmettait les mises à jour entre les écrans en temps réel. Une stack technique désigne l'ensemble cohérent des outils employés pour faire fonctionner une application. Ces choix définissaient le premier socle sans prétendre qu'ils constituaient la seule architecture possible pour les versions futures.
Un prototype de recherche comme résultat attendu.
Le résultat demandé après cinq mois n'était en aucun cas un produit terminé ou prêt à être déployé à grande échelle. Il devait s'agir d'un prototype fonctionnel que la professeure-chercheuse, les enseignants et les sociologues enquêteurs pourraient essayer et présenter. Un prototype sert à vérifier une idée, observer l'usage et obtenir des premiers retours avant d'investir dans une version stabilisée. La réussite du stage dépendait donc de la capacité de l'application à matérialiser le questionnaire, la trajectoire et l'interaction multi-écrans suffisamment clairement pour alimenter la prochaine étape de la recherche.

Retour au sommaire

Objectifs, contexte et enjeux

Matérialiser une méthode de recherche dans un prototype.
L'objectif général était de transformer une idée issue de la recherche sociologique en une première application manipulable. Il ne s'agissait pas de livrer une plateforme définitive, mais de vérifier qu'un entretien, des réponses datées et une représentation de trajectoire pouvaient être réunis dans la même expérience. Ce prototype devait fournir aux enseignants et aux enquêteurs un objet suffisamment concret pour évaluer la méthode, formuler des retours et décider des développements ultérieurs.
Limiter le noyau initial à deux fonctions obligatoires.
Deux éléments devaient absolument fonctionner à la fin du stage : le formulaire d'enquête et l'affichage des trajectoires de vie sous forme de graphique. Le formulaire recueillait les événements racontés par la personne interrogée. Le graphique transformait ces réponses en une représentation chronologique. Si l'un des deux restait inutilisable, le concept ne pouvait pas être démontré : le questionnaire seul aurait reproduit un formulaire numérique classique, tandis qu'un graphique sans collecte structurée n'aurait pas pu représenter fidèlement l'entretien.
Partir d'un questionnaire défini par les chercheurs.
Le prototype utilisait un ensemble de questions fourni pour l'expérimentation. Les sociologues ne devaient pas encore créer, modifier ou versionner eux-mêmes leurs questionnaires dans l'application. Un questionnaire dynamique aurait nécessité une interface d'administration, la gestion de plusieurs types de champs et des règles permettant de faire évoluer un formulaire sans rendre les anciennes réponses incompatibles. Cette fonction était pertinente pour une version future, mais elle n'était pas nécessaire pour vérifier le principe central pendant les cinq mois.
Recueillir du texte, des dates et des périodes.
Les réponses comprenaient des descriptions textuelles ainsi que des informations temporelles. Pour un emploi, une formation, un lieu d'habitation ou un autre événement, l'enquêteur demandait notamment une date de début et une date de fin. La personne pouvait fournir des dates exactes lorsqu'elle les connaissait ou des estimations lorsqu'elle ne pouvait pas les retrouver précisément. Cette souplesse était indispensable : une trajectoire sociologique porte parfois sur plusieurs décennies et ne peut pas exiger la même précision qu'un dossier administratif récent.
Transformer chaque événement en intervalle chronologique.
Les dates recueillies permettaient de positionner un événement sur une ligne temporelle. Une période est un intervalle compris entre un début et une fin ; elle permet par exemple de représenter qu'un emploi s'est déroulé pendant qu'une personne habitait dans une ville donnée. Le graphique devait faire correspondre la longueur et la position visuelles de l'événement à la période décrite pendant l'entretien. Cette correspondance entre réponse et affichage constituait le premier critère de correction de la trajectoire.
Représenter les dimensions séparément et simultanément.
La visualisation devait proposer plusieurs lectures. Les dimensions comme les études, le travail, la famille, les relations ou les lieux d'habitation pouvaient être consultées séparément afin de rendre chaque parcours lisible. Elles pouvaient aussi être superposées ou rapprochées dans une vue commune pour observer des événements simultanés. Cette double lecture répondait au besoin sociologique : comprendre chaque domaine de la vie, puis rechercher des liens temporels entre plusieurs domaines sans les confondre.
Préserver la fidélité du récit plutôt que produire un simple graphique esthétique.
Une trajectoire était considérée comme correcte lorsque les événements affichés correspondaient aux périodes décrites par la personne interrogée. La réussite ne dépendait donc pas uniquement de la netteté ou de l'originalité de la visualisation. Le graphique devait conserver l'ordre, la durée et la dimension des événements sans suggérer une chronologie différente. L'objectif technique restait subordonné à la justesse du support de recherche.
Rendre le formulaire utilisable par l'enquêteur.
L'expérience utilisateur du formulaire faisait partie des critères de réussite. L'enquêteur devait pouvoir suivre sa méthodologie, saisir les informations sans interrompre inutilement l'échange et retrouver le contexte nécessaire pour compléter un événement. Une expérience utilisateur, ou UX, désigne ici la facilité avec laquelle une personne comprend l'interface, accomplit son objectif et corrige une erreur. Un formulaire techniquement fonctionnel mais trop lent ou confus aurait perturbé l'entretien et diminué la qualité des réponses.
Rendre la trajectoire compréhensible par la personne enquêtée.
La visualisation ne s'adressait pas uniquement aux chercheurs après l'entretien. La personne interrogée devait aussi pouvoir reconnaître son propre parcours et comprendre comment ses réponses étaient traduites à l'écran. Cette lisibilité permettait d'utiliser le graphique comme support de discussion et de relever plus tôt un événement mal positionné. Le prototype était donc évalué sur deux expériences complémentaires : la saisie du côté de l'enquêteur et la lecture du côté de l'enquêté.
Ajouter une interconnexion multi-écrans en cours de projet.
Le besoin a évolué pendant le stage. Le périmètre initial se concentrait sur le formulaire et la visualisation, puis les chercheurs ont demandé que la trajectoire puisse être affichée en direct sur un deuxième écran destiné à l'enquêté. J'ai pris en charge la conception de cette extension au moyen de Socket.io et d'une communication événementielle en temps réel. Cet ajout a transformé le prototype d'une application à interface unique en une expérience coordonnée entre deux utilisateurs.
Isoler chaque entretien dans une room de communication.
L'écran de l'enquêté rejoignait une room associée à l'écran de l'enquêteur. Dans Socket.io, une room, ou salon logique, regroupe certaines connexions afin qu'un événement ne soit transmis qu'aux participants concernés. Lorsqu'une réponse modifiait la trajectoire, le serveur pouvait ainsi envoyer la mise à jour vers le bon écran de consultation. Ce mécanisme préparait la séparation entre plusieurs entretiens, même si la gestion complète de plusieurs enquêtes et personnes ne faisait pas encore partie du prototype attendu.
Ne pas bloquer l'enquêteur si l'écran secondaire se déconnecte.
L'interconnexion devait enrichir l'entretien sans devenir une dépendance critique pour la saisie. Si l'écran de l'enquêté perdait sa connexion, la visualisation partagée pouvait cesser de se mettre à jour, mais l'enquêteur devait continuer à poser ses questions et enregistrer les réponses. Cette asymétrie était volontaire : la saisie constituait le parcours principal et l'écran secondaire une aide visuelle. Le rétablissement de la connexion pouvait être traité séparément sans faire perdre tout le déroulement de l'entretien.
Évaluer le prototype par l'usage plutôt que par un périmètre de production.
Les critères de réussite restaient concentrés sur la qualité du formulaire et de la visualisation, auxquels s'est ajoutée l'interconnexion des écrans. Les sociologues devaient pouvoir essayer ces fonctions, comprendre le parcours et formuler des retours utiles. La gestion complète de plusieurs campagnes, la création de questionnaires, l'export des réponses et l'envoi vers des plateformes d'analyse n'étaient pas nécessaires pour cette évaluation. Le résultat attendu était une preuve de concept utilisable, pas une solution déployable auprès de tous les chercheurs.
Préparer explicitement une reprise par un autre développeur.
Le prototype devait pouvoir continuer à évoluer après la fin du stage. La transmission faisait donc partie des objectifs dès le départ. En parallèle de l'application, nous avons créé un site de documentation avec Docusaurus. Docusaurus est un générateur de sites de documentation qui organise des explications écrites, des guides et des références techniques dans une interface navigable. Cette documentation devait expliquer l'installation, l'architecture et les fonctions importantes afin qu'un futur développeur ne dépende pas uniquement d'un échange oral avec l'équipe d'origine.

Retour au sommaire

Risques et mesures de maîtrise

Des besoins susceptibles d'évoluer avec le prototype.
Le projet partait d'une idée de recherche plutôt que d'un cahier des charges entièrement stabilisé. Les chercheurs pouvaient préciser leur besoin seulement après avoir vu et manipulé une première version. L'ajout du deuxième écran illustre ce risque : il n'était pas prévu dans le noyau initial, puis il est devenu suffisamment utile pour rejoindre le prototype. La maîtrise du périmètre consistait à accepter les évolutions qui renforçaient directement l'expérimentation tout en reportant l'administration des questionnaires, les exports et les intégrations externes.
Une architecture impossible à réussir entièrement du premier coup.
Partir de zéro avec un besoin encore exploratoire créait le risque de choisir une organisation du code qui ne correspondrait plus aux usages découverts ensuite. Ce risque s'est effectivement matérialisé : lorsque nous constations qu'une piste ne convenait pas, je devais revoir une partie de l'architecture. Une architecture logicielle définit la manière dont les interfaces, la logique, les données et les échanges sont séparés et reliés. Les corrections faisaient partie du processus de prototypage, mais elles consommaient du temps et confirmaient la nécessité de conserver des composants aussi indépendants que possible.
Une visualisation ne correspondant à aucun graphique standard.
Le principal risque technique était de ne pas parvenir à construire la représentation imaginée par les chercheurs. Les bibliothèques de graphiques prêtes à l'emploi proposent généralement des courbes, barres, secteurs ou nuages de points configurables, mais pas la combinaison de trajectoires temporelles et de dimensions attendue ici. D3.js a été choisi parce qu'il fournit des primitives de bas niveau pour transformer des données en éléments visuels. Cette liberté rendait le résultat possible, mais transférait vers moi la responsabilité du calcul des positions, des échelles, des formes et des interactions.
Un graphique visuellement plausible mais scientifiquement faux.
Une erreur pouvait produire une trajectoire qui semblait cohérente tout en plaçant un événement à la mauvaise date, dans la mauvaise dimension ou avec une durée inexacte. Ce risque était plus difficile à détecter qu'une erreur d'affichage évidente, car le navigateur pouvait fonctionner normalement. Je devais comparer la représentation aux réponses sources et faire vérifier le résultat par les sociologues. La validation portait donc autant sur le sens du graphique que sur son exécution technique.
Une représentation susceptible d'influencer l'interprétation.
La taille, la couleur, la superposition ou la position d'un événement peuvent lui donner une importance que la personne interrogée ou le chercheur ne lui attribue pas. Le graphique risquait ainsi de déformer le récit même lorsque les dates étaient exactes. Les itérations avec les sociologues servaient à identifier ces effets et à vérifier que la représentation correspondait à l'intention méthodologique. L'application devait soutenir l'analyse, pas produire silencieusement sa propre conclusion.
Des désaccords relevant de la méthode sociologique.
Les chercheurs partageaient globalement la manière de représenter une trajectoire, mais pouvaient être en désaccord sur la façon d'inclure certains événements dans le graphique. Ce type de débat ne pouvait pas être résolu par une préférence de développement ou par une bibliothèque JavaScript. Mon rôle était de rendre les alternatives compréhensibles et techniquement réalisables, puis de laisser les spécialistes décider de la règle adaptée à leur méthodologie. Coder trop tôt une interprétation contestée aurait rigidifié une décision scientifique encore ouverte.
Une expérience de formulaire pouvant perturber l'entretien.
Un formulaire trop lent, trop rigide ou difficile à corriger pouvait détourner l'attention de l'enquêteur et casser le rythme de la conversation. Il pouvait aussi encourager une saisie incomplète simplement parce qu'un champ était mal compris. Les démonstrations et itérations avec les sociologues permettaient de confronter l'interface à leur manière réelle de poser les questions. Le contrôle ne se limitait pas à vérifier qu'un bouton fonctionnait : il fallait s'assurer que l'outil restait compatible avec leur pratique d'enquête.
Une extension multi-écrans ajoutant un nouveau point de défaillance.
Le partage en direct a ajouté une connexion réseau et un état supplémentaire à synchroniser. Un événement pouvait être correctement enregistré par l'enquêteur sans apparaître sur l'écran de l'enquêté, ou un écran pouvait rejoindre le mauvais échange si l'association était incorrecte. Les rooms Socket.io limitaient ce risque en séparant logiquement les connexions. L'écran de consultation devait néanmoins rester secondaire afin qu'une perte de synchronisation n'empêche pas l'entretien principal de continuer.
Une interruption qui ne devait pas bloquer la saisie.
Si la connexion de l'enquêté était interrompue, cet utilisateur perdait temporairement la mise à jour de sa trajectoire. L'enquêteur devait en revanche conserver son formulaire et poursuivre l'entretien. Cette continuité réduisait l'impact d'un problème de connexion, mais le prototype ne traitait pas encore tous les scénarios de reconnexion et de resynchronisation possibles. Une version destinée à un usage régulier devrait notamment garantir que l'écran revenu en ligne récupère un état complet et à jour.
Un fonctionnement local qui ne prouvait pas la robustesse sur Internet.
Le prototype était prévu pour des entretiens en présentiel et fonctionnait dans un environnement local contrôlé. Il n'avait pas à résoudre les restrictions réseau, la latence ou les interruptions d'une utilisation distante sur Internet. Cette limite était acceptable pour démontrer l'expérience multi-écrans, mais elle empêchait de conclure que la même architecture fonctionnerait sans adaptation sur tous les terrains. Un déploiement futur devrait tester les réseaux réels, la sécurité des connexions et le comportement hors ligne ou dégradé.
La perte possible d'informations pendant un prototype.
Une enquête contient un travail difficile à reproduire : si des réponses disparaissent, il n'est pas toujours possible de demander à la personne de recommencer tout son récit. Le prototype devait permettre de tester la saisie et la visualisation, mais il ne constituait pas encore un système de production offrant toutes les garanties de sauvegarde, de reprise et de traçabilité. Cette limite imposait de l'utiliser dans un cadre expérimental et de prévoir, avant une version finale, une stratégie explicite contre la perte de données.
Une anonymisation non automatisée dans l'application.
Les données de trajectoire pouvaient être sensibles. Le processus prévoyait leur anonymisation après l'enquête, notamment en dissociant le nom et le prénom des réponses analysées. Le prototype ne réalisait toutefois pas automatiquement cette transformation. Il ne fallait donc pas présenter l'application comme une solution complète de protection des données. Une version ultérieure devrait définir quelles informations retirer ou remplacer, à quel moment, avec quels droits et comment vérifier qu'une combinaison d'événements ne permet pas une identification indirecte trop facile.
Des fonctions d'accès encore limitées par le périmètre.
La gestion complète de plusieurs enquêtes, de plusieurs personnes et de leurs autorisations était envisagée, mais ne constituait pas l'objet du prototype. Le fonctionnement local réduisait l'exposition pendant la démonstration sans remplacer une véritable politique d'accès. Une version déployée devrait authentifier les utilisateurs, séparer les études et limiter chaque chercheur aux données autorisées. Repousser ces fonctions était acceptable pour une preuve de concept, mais incompatible avec une collecte réelle à grande échelle.
Aucun export ni envoi vers une plateforme spécialisée.
La première version ne permettait pas d'exporter les réponses ou les graphiques et ne transmettait pas les données vers un outil d'analyse. Ajouter un export ne consiste pas seulement à créer un fichier : il faut définir un format stable, préserver les dates estimées, représenter les dimensions et éviter d'exposer les identifiants supprimés. Ces questions étaient laissées à la suite du projet afin de ne pas détourner les cinq mois de la validation du formulaire et de la visualisation.
Une échéance souple, mais un résultat attendu en cinq mois.
Le contexte universitaire ne créait pas une pression de mise en production comparable à celle d'un produit commercial. La limite de cinq mois ne menaçait donc pas une activité ou un lancement public. Elle restait néanmoins la durée de mon stage : un prototype devait être présentable avant mon départ. Le risque principal n'était pas un retard contractuel, mais de disperser le temps dans trop de fonctions et de terminer sans objet suffisamment cohérent pour recueillir des retours.
Une reprise future dépendante de la qualité de la transmission.
Mon départ était connu dès le début. Sans documentation, le code pouvait devenir difficile à reprendre, notamment pour la visualisation D3.js et la synchronisation entre écrans. Le site Docusaurus réduisait ce risque en rassemblant les instructions et les explications techniques. Il ne suffisait toutefois pas à lui seul : le code devait aussi rester structuré, les choix importants être justifiés et l'installation reproductible. L'objectif était de transmettre une base de travail, pas seulement une démonstration fonctionnant sur mon poste.

Retour au sommaire

Les étapes — ce que j'ai fait

Commencer par documenter le besoin.
Ma première action a été de consigner les informations nécessaires avant de développer. La professeure-chercheuse a réuni les trois développeurs du prototype afin de présenter le contexte sociologique, la méthode d'entretien et les besoins techniques envisagés. Cette réunion nous a permis de comprendre que le formulaire et la visualisation n'étaient pas deux fonctions indépendantes : les réponses devaient être structurées dès la saisie pour alimenter correctement les trajectoires. Documenter ce lien au départ évitait de traiter le projet comme un simple formulaire auquel un graphique serait ajouté à la fin.
Transformer les explications en supports de travail.
Nous avons produit un cahier des charges, des spécifications destinées aux développeurs, des tickets et des schémas. Le cahier des charges décrivait le besoin et le périmètre ; les spécifications précisaient le comportement attendu ; les tickets découpaient le travail en éléments suivis. Nous avons également repris les schémas élaborés par les chercheurs afin de conserver leur manière de décrire les trajectoires. Mon travail consistait à relier ces représentations métier aux objets que le logiciel devait stocker et afficher.
Ne pas créer de maquettes qui n'auraient pas réduit l'incertitude.
Nous n'avons pas réalisé de maquette classique avant le développement. Le formulaire reposait sur des composants d'interface connus et sa principale difficulté concernait son enchaînement, pas son apparence statique. Pour la visualisation, une image figée n'aurait pas permis d'évaluer correctement les échelles temporelles, les superpositions et les corrections interactives. Nous avons donc préféré construire rapidement une première version fonctionnelle du graphique. Le code jouait ici le rôle de prototype visuel et permettait aux chercheurs de réagir à un comportement réel.
Organiser le stage en cycles d'itération.
Les cinq mois se sont structurés autour de trois grandes activités : recueillir le besoin, choisir le socle technique, puis développer par itérations. Une itération correspondait à un cycle durant lequel nous implémentions une partie, la présentions aux parties prenantes, recueillions leurs retours et corrigions la direction avant de poursuivre. Cette organisation était adaptée à un projet de recherche, car certaines attentes ne devenaient précises qu'après l'observation du prototype. Elle nous permettait d'avancer sans prétendre que toutes les décisions étaient définitives dès la première semaine.
Choisir Nuxt et Vue à partir des compétences de l'équipe.
Nous voulions employer un framework JavaScript pour construire l'application exécutée dans le navigateur. Les options principales étudiées étaient Angular, React et Vue. L'équipe connaissait mieux l'écosystème Vue ; nous avons donc retenu Vue 3 avec Nuxt 3. Un framework fournit une structure, des conventions et des outils communs pour organiser les pages et les composants. Choisir une technologie déjà maîtrisée réduisait le temps d'apprentissage et facilitait la collaboration entre les trois développeurs pendant un stage limité à cinq mois.
Conserver un backend JavaScript simple avec Express.
Les besoins serveur restaient relativement classiques : recevoir les données du formulaire, appliquer la logique nécessaire et communiquer avec la base. Nous avons choisi Express.js, un framework minimal pour construire des routes et des API avec Node.js. Une API est l'interface par laquelle le frontend demande au serveur de lire ou de modifier des informations. Rester en JavaScript des deux côtés limitait le nombre de langages à maintenir et rendait le passage du frontend au backend plus direct pour l'équipe.
Modéliser les données avec PostgreSQL et Prisma.
PostgreSQL a été choisi comme base de données relationnelle parce que les informations formaient des entités liées entre elles et que cette technologie était connue par l'équipe. Une base relationnelle organise les données dans des tables associées au moyen d'identifiants. Prisma jouait le rôle d'ORM, ou outil de correspondance objet-relationnel : il permettait de décrire les modèles dans le code, de créer la structure de la base et de manipuler les enregistrements sans écrire chaque requête SQL manuellement. Cette combinaison simplifiait l'installation du prototype et la compréhension du modèle.
Définir les principales entités du domaine.
Le modèle distinguait notamment les enquêtes, les personnes interrogées, les questions, les réponses, les événements et les dimensions de trajectoire. Une enquête regroupait le contexte du questionnaire ; une réponse conservait l'information donnée à une question ; un événement transformait cette information en élément daté ; une dimension indiquait le domaine de vie auquel il appartenait. Cette séparation permettait de ne pas enfermer toute l'information dans un texte libre impossible à positionner sur le graphique.
Construire un formulaire unique organisé avec un stepper.
Le questionnaire occupait une page, mais il était découpé en étapes successives au moyen d'un stepper. Un stepper est un composant qui guide l'utilisateur à travers plusieurs sections tout en indiquant sa progression. Chaque étape pouvait correspondre à une dimension de la trajectoire. Cette organisation évitait d'afficher toutes les questions en même temps et permettait à l'enquêteur de se concentrer sur un domaine avant de passer au suivant.
Adapter les questions aux réponses précédentes.
Le questionnaire était dynamique. Pour la trajectoire professionnelle, il pouvait demander si la personne avait occupé un emploi, puis afficher les questions sur l'emploi et sa période seulement lorsque la réponse le justifiait. À la fin de cette saisie, il demandait si un autre emploi devait être ajouté et répétait la séquence si nécessaire. Cette logique conditionnelle permettait de recueillir un nombre variable d'événements sans imposer des champs inutiles à une personne dont le parcours était différent.
Associer chaque réponse à une dimension.
Chaque groupe de questions appartenait à une dimension connue, par exemple les études, le travail ou les lieux d'habitation. Lorsqu'une réponse décrivait un événement, l'application conservait donc à la fois son contenu et la dimension dans laquelle il devait apparaître. Cette association constituait le lien entre le formulaire et le graphique. Elle permettait à la visualisation de séparer les lignes par domaine, puis de les rapprocher lorsque l'utilisateur demandait une vue superposée.
Construire des périodes à partir de dates exactes ou estimées.
La date de début et la date de fin constituaient les informations centrales transmises au graphique. Lorsqu'une date exacte n'était pas connue, nous appliquions une règle cohérente avec la méthode d'enquête. Une date de début manquante pouvait reprendre la fin de l'événement précédent dans la même dimension ; une date de fin inconnue pouvait être prolongée jusqu'au début de l'événement suivant. Cette estimation produisait une continuité exploitable, tout en laissant à l'enquêteur et à l'enquêté la possibilité de corriger les bornes si leur échange apportait une information plus précise.
Transformer les réponses en données temporelles pour D3.js.
Avant le rendu, l'application convertissait les réponses utiles en objets comportant au minimum une date de début, une date de fin et une dimension. Le contenu descriptif complétait ensuite l'événement, mais ces trois informations déterminaient principalement sa position. Cette étape de transformation isolait la logique métier du code de dessin : D3.js recevait un format cohérent, indépendamment de l'étape du formulaire qui avait produit la réponse.
Construire le graphique avec les primitives de D3.js.
Nous avons utilisé des éléments SVG, des axes et des échelles temporelles. SVG est un format graphique vectoriel intégré aux pages Web ; ses formes restent nettes lorsqu'elles sont redimensionnées. Une échelle temporelle convertit une date en une position horizontale ou verticale dans l'espace disponible, tandis qu'un axe fournit les repères permettant de lire cette position. D3.js nous évitait de réimplémenter ces calculs de base, tout en nous laissant composer une représentation qui n'existait pas dans une bibliothèque de graphiques prêts à l'emploi.
Proposer plusieurs modes de lecture des dimensions.
Le panneau de paramètres du graphique comportait un choix permettant de basculer entre les représentations. L'utilisateur pouvait consulter les dimensions séparément pour suivre chaque domaine avec davantage de clarté, ou demander une vue superposée afin d'observer les événements qui se déroulaient pendant les mêmes périodes. Le changement de mode réutilisait les mêmes données et recalculait leur disposition ; il ne créait pas une seconde version indépendante de la trajectoire.
Faire évoluer le graphique en trois versions principales.
La première version séparait les différentes dimensions. La deuxième prenait en compte leur superposition afin de rapprocher plusieurs domaines sur une même lecture temporelle. La troisième ajoutait la correction des réponses et la mise à jour dynamique du rendu. Cette progression nous a permis de valider d'abord le positionnement fondamental, puis les comparaisons, avant d'ajouter une interaction qui modifiait les données déjà représentées.
Permettre la correction depuis le formulaire et le graphique.
Pendant ou à la fin de l'entretien, l'enquêteur pouvait revenir sur une réponse au moyen du formulaire ou ajuster les dates directement depuis la représentation. Cette fonction répondait à un usage réel : en voyant l'ensemble de sa vie, une personne peut se souvenir qu'un événement a commencé plus tôt, s'est terminé plus tard ou s'est déroulé en parallèle d'un autre. Le graphique ne devait donc pas être une image finale figée, mais un second point d'entrée vers les données de l'entretien.
Revoir l'architecture pour rendre le graphique modifiable.
L'ajout des corrections manuelles a obligé l'équipe à reprendre une partie de l'architecture initiale du graphique. Le premier fonctionnement était principalement orienté dans un seul sens : les réponses produisaient le rendu. Permettre une modification depuis le graphique imposait désormais un flux inverse, dans lequel une interaction visuelle mettait à jour les données puis recalculait la représentation. Nous avons dû mieux séparer l'état de la trajectoire de son dessin afin d'éviter qu'une modification existe uniquement dans le SVG sans être répercutée dans le reste de l'application.
Faire vérifier les périodes pendant l'entretien.
La présence simultanée du sociologue et de la personne enquêtée fournissait une validation immédiate. À chaque étape et à la fin du questionnaire, ils pouvaient comparer le graphique au récit, repérer un décalage puis modifier les dates. Cette vérification humaine était essentielle, car un algorithme pouvait contrôler qu'une date était techniquement valide sans savoir si elle correspondait au souvenir ou à l'intention de la personne. L'outil facilitait la correction, mais ne décidait pas à la place des participants.
Prendre le lead sur l'ajout de l'interconnexion.
Lorsque le besoin d'un deuxième écran est apparu, j'ai pris en charge l'implémentation de la communication en temps réel. Socket.io était alors une solution largement utilisée pour établir des échanges événementiels proches du fonctionnement WebSocket dans une application JavaScript. Un WebSocket maintient un canal bidirectionnel entre un client et un serveur afin que chacun puisse envoyer une mise à jour sans attendre une nouvelle requête de page. Cette approche convenait au partage immédiat du graphique.
Créer une room identifiée et protégée par un mot de passe.
Avant un entretien, l'enquêteur vérifiait les rooms existantes ou en créait une nouvelle avec son propre identifiant. Il définissait un mot de passe, puis transmettait l'identifiant et ce mot de passe à l'enquêté. Celui-ci ouvrait l'application sur son écran et saisissait les informations pour rejoindre le bon salon. Cette protection convenait à une démonstration locale et évitait une association accidentelle entre écrans ; elle ne remplaçait pas un système complet d'authentification et d'autorisation pour une version déployée.
Synchroniser uniquement l'état nécessaire au second écran.
L'enquêteur conservait le formulaire et sa propre représentation graphique. L'enquêté ne recevait que les données nécessaires à l'affichage de sa trajectoire. Lorsqu'une réponse ou une date modifiait le graphique, l'état correspondant était envoyé à la room puis appliqué sur l'écran secondaire. Limiter les données échangées à ce besoin rendait le flux plus simple et empêchait l'interface de l'enquêté d'exposer les commandes réservées à la conduite de l'enquête.
Prévoir une reconnexion manuelle dans le prototype.
Nous n'avons pas développé de mécanisme avancé de reprise automatique. En cas de perte de connexion, l'enquêté devait rouvrir ou rejoindre de nouveau l'application en saisissant l'identifiant et le mot de passe de la room. L'enquêteur pouvait continuer à utiliser son formulaire. Cette solution était suffisante pour l'environnement local de démonstration, mais une version de production devrait détecter la reconnexion et renvoyer automatiquement l'état complet du graphique.
Écrire des tests pour les fonctions principales.
Nous avons écrit des tests afin de vérifier le formulaire, le graphique et la synchronisation. Les tests permettaient de rejouer des comportements attendus après une modification du code et de détecter qu'une évolution du rendu cassait une fonction déjà validée. Ils étaient complétés par les démonstrations aux chercheurs, car une assertion technique ne pouvait pas déterminer seule si une trajectoire restait compréhensible ou fidèle à la méthodologie sociologique.
Présenter l'avancement chaque semaine.
Nous montrions le prototype aux sociologues toutes les semaines. Ces rendez-vous périodiques servaient à exposer les nouvelles fonctions, relever les incompréhensions et décider du travail suivant. Les tâches et anomalies étaient suivies dans Jira, tandis que la professeure-chercheuse nous guidait dans l'arbitrage des sujets liés à la méthode. La possibilité de modifier les dates après la saisie est un exemple direct de retour utilisateur devenu une évolution importante du produit.
Versionner le travail collectif dans GitLab.
Le frontend et le backend se trouvaient dans le même dépôt GitLab. Git enregistrait l'historique des modifications et GitLab hébergeait le dépôt ainsi que le travail collaboratif. Chacun des trois développeurs travaillait sur sa propre branche, c'est-à-dire une ligne d'évolution isolée, puis le code était fusionné dans une branche commune d'intégration. Cette organisation limitait les conflits directs et permettait de vérifier l'assemblage des contributions avant de considérer une version comme démontrable.
Préparer deux configurations locales de démonstration.
Une commande lançait l'application sur localhost, l'adresse par laquelle un ordinateur accède à un service exécuté sur lui-même. L'enquêteur pouvait créer ou reprendre une enquête, créer une room et définir son mot de passe. Pour une démonstration sur un seul poste équipé de deux écrans, deux fenêtres de navigateur rejoignaient les interfaces enquêteur et enquêté. Lorsque deux appareils étaient utilisés, chacun lançait le projet et l'écran enquêté rejoignait la room au moyen des informations communiquées.
Documenter l'installation et les données de démonstration.
Le site Docusaurus rassemblait les informations nécessaires pour comprendre, lancer et reprendre le projet. Le guide d'installation détaillait aussi la mise en place de la base PostgreSQL et l'exécution du seed. Un seed est un jeu de données initial injecté automatiquement afin de disposer d'exemples cohérents pour le développement ou les tests. Cette procédure permettait au développeur suivant de recréer un environnement fonctionnel sans dépendre de fichiers présents uniquement sur nos machines.
Stabiliser le prototype avant la présentation finale.
Dans la dernière phase, nous avons nettoyé le code, complété la documentation et rédigé des supports de test pour les professeurs-chercheurs. Le nettoyage ne consistait pas à ajouter de nouvelles fonctions, mais à rendre la version existante plus compréhensible et plus fiable pour la démonstration. Nous avons ainsi privilégié la capacité à présenter et reprendre le prototype plutôt qu'une dernière extension risquant de déstabiliser son noyau.
Effectuer une passation directe avec le développeur suivant.
La transmission ne s'est pas limitée au dépôt et au site Docusaurus. Nous avons rencontré la personne qui reprenait le projet pour lui présenter les objectifs, le fonctionnement de l'application, le code et la documentation. Cette passation lui permettait de poser des questions pendant que l'équipe d'origine était encore disponible. Elle clôturait le stage en transformant le prototype en base de travail transmissible plutôt qu'en réalisation dépendante de ses premiers auteurs.

Retour au sommaire

Les acteurs — les interactions

Trois développeurs stagiaires réunis sur le même prototype.
L'équipe de réalisation était composée de trois étudiants en stage, dont moi. Aucun de nous ne disposait d'un titre officiel de responsable technique. Nous devions donc organiser collectivement le développement, répartir les fonctions et faire converger nos contributions dans une version commune. Cette situation nous plaçait dans une relation d'apprentissage comparable, tout en laissant émerger des responsabilités différentes selon les compétences et les sujets pris en charge.
Une professeure-chercheuse à la fois encadrante, informaticienne et référente métier.
Notre encadrante était professeure d'informatique et développeuse, mais elle travaillait aussi sur plusieurs sujets liés aux enquêtes sociologiques. Elle ne développait donc pas quotidiennement le prototype à notre place. Son rôle principal consistait à nous expliquer le contexte scientifique, les règles que nous ne pouvions pas déduire seuls et les enjeux de l'entretien. Elle reliait ainsi notre travail d'informaticiens aux attentes des chercheurs et intervenait lorsqu'une décision nécessitait une compréhension plus approfondie de la méthode.
Une répartition des tâches selon les compétences.
Mes deux collègues s'occupaient principalement du formulaire et de la base de données. Ils construisaient l'enchaînement des questions, les conditions d'affichage et la persistance des réponses. De mon côté, je prenais en charge le backend, la visualisation sur mesure avec D3.js et la synchronisation entre les écrans avec Socket.io. Cette répartition n'isolait pas complètement les développeurs : les données produites par le formulaire devaient respecter le format attendu par mon graphique, tandis que le backend devait fonctionner avec le modèle construit dans la base.
La visualisation D3.js comme responsabilité personnelle principale.
Ma valeur ajoutée la plus importante venait de mon aisance en JavaScript. Elle m'a permis de prendre en charge la partie que nous considérions comme la plus difficile : construire une représentation de trajectoire qui n'existait pas sous forme de composant prêt à l'emploi. Je devais comprendre les règles temporelles données par les chercheurs, transformer les événements en données graphiques et faire évoluer le rendu jusqu'à permettre les superpositions et les corrections. Cette responsabilité associait résolution technique et compréhension du besoin scientifique.
Un travail quotidien facilité par un bureau partagé.
Nous travaillions ensemble tous les jours dans le même bureau. Cette proximité nous permettait de vérifier rapidement le format d'une donnée, de montrer un comportement ou de résoudre un conflit d'intégration sans attendre une réunion formelle. Une question sur le formulaire pouvait immédiatement être comparée au besoin du graphique, et une évolution du backend pouvait être expliquée aux personnes travaillant sur la base. Le bureau partagé favorisait donc des boucles de coordination courtes au sein de l'équipe technique.
Des revues de code avant chaque fusion.
Nous relisions les changements avant de les intégrer à la branche commune. Une revue de code consiste à examiner la proposition d'un autre développeur afin de repérer une erreur, vérifier sa lisibilité et s'assurer qu'elle respecte le fonctionnement attendu. J'effectuais la majorité de ces revues et décidais le plus souvent si les modifications pouvaient rejoindre la branche principale. Cette responsabilité faisait de moi un point de contrôle technique de fait, même si aucun rôle officiel de lead developer ne m'avait été attribué.
Des désaccords techniques résolus par l'analyse collective.
Lorsqu'une décision technique divisait les développeurs, nous prenions le temps d'en examiner les avantages, les limites et les conséquences sur le reste de l'application. Nous cherchions ensuite une solution commune plutôt qu'une décision fondée uniquement sur la préférence de la personne la plus insistante. Si le désaccord touchait un besoin scientifique, une contrainte que nous ne comprenions pas ou une décision difficile à départager, nous consultions la professeure-chercheuse. Cette méthode distinguait le débat d'implémentation de l'arbitrage lié au domaine.
Une priorisation guidée par la professeure-chercheuse.
Les trois stagiaires pouvaient proposer des solutions et estimer leur difficulté, mais nous demandions à notre encadrante de fixer la priorité des fonctionnalités. Elle pouvait déterminer si une évolution était indispensable à la démonstration de la méthode ou si elle pouvait attendre la suite du projet. Cette répartition était logique : nous maîtrisions l'effort technique, tandis qu'elle connaissait la valeur scientifique des fonctions. Elle limitait le risque de consacrer plusieurs semaines à une amélioration intéressante pour les développeurs mais secondaire pour l'expérimentation.
Trois chercheurs ou enseignants impliqués régulièrement.
Environ trois sociologues ou professeurs participaient aux démonstrations récurrentes. Ils ne venaient pas tous du LIG : certains appartenaient à d'autres universités françaises, notamment à Rennes. Cette diversité élargissait le retour au-delà de notre seul environnement de travail. Le prototype devait rester compréhensible pour des personnes partageant une démarche sociologique sans nécessairement connaître nos choix techniques ni avoir participé à chaque décision de développement.
Une validation fonctionnelle assurée par les spécialistes.
La professeure-chercheuse et les enseignants ou sociologues validaient le formulaire, la représentation graphique et les règles d'inclusion des événements. Les développeurs pouvaient vérifier qu'une date était correctement enregistrée ou qu'un élément SVG se trouvait à la position calculée, mais ils ne pouvaient pas décider seuls que le parcours respectait la méthode d'enquête. La validation finale du comportement appartenait donc aux personnes capables d'évaluer son sens scientifique.
Un rôle de traduction entre règles métier et prototype.
Notre responsabilité principale consistait à transformer des explications et des règles sociologiques en comportements utilisables. Pour y parvenir, nous posions des questions jusqu'à comprendre le vocabulaire, les exceptions et le résultat attendu. Lorsque le besoin restait abstrait, nous le modélisions au moyen de schémas, d'entités ou d'une première interaction. Une règle métier est une contrainte issue du domaine d'activité ; elle décrit ici la manière dont une enquête ou une trajectoire doit fonctionner, indépendamment de la technologie choisie pour l'implémenter.
Des décisions scientifiques qui ne revenaient pas aux développeurs.
Les chercheurs s'accordaient globalement sur la représentation d'une trajectoire, mais pouvaient discuter de la manière d'inclure certains événements. Lorsque leurs interprétations divergeaient, la professeure-chercheuse prenait la décision finale. Notre rôle était de rendre les options et leurs conséquences visibles, puis d'implémenter la règle retenue. Cette limite évitait qu'un choix effectué pour simplifier le code devienne involontairement une décision de méthodologie sociologique.
Des validations réalisées par simulation.
Pendant le stage, nous n'avons pas participé à de véritables entretiens avec des personnes enquêtées. Les tests d'usage étaient réalisés sous forme de simulations avec les chercheurs. Cette méthode permettait de vérifier le parcours, les questions et les réactions du graphique sans engager immédiatement des données réelles. Elle constituait cependant une limite : un entretien de recherche réel peut faire apparaître des hésitations, des récits imprévus et des contraintes de terrain qu'une simulation entre personnes connaissant déjà l'outil reproduit imparfaitement.
Une documentation alimentée par chaque développeur.
La responsabilité de Docusaurus était partagée. Chaque membre mettait à jour la documentation lorsqu'il ajoutait ou modifiait une fonction dont il avait la charge. Cette règle rapprochait l'écriture de l'explication du moment où le contexte était encore frais. Elle évitait également qu'une seule personne doive reconstituer à la fin le fonctionnement de composants qu'elle n'avait pas développés. La documentation devenait ainsi une production continue de l'équipe et non une tâche isolée ajoutée au dernier jour.
Une reprise confiée à un nouveau développeur pendant deux semaines.
La personne arrivée après notre stage avait pour mission de transformer le prototype en une véritable application et d'évaluer sa capacité à être utilisée dans des enquêtes sociologiques. La passation a duré deux semaines. Nous lui avons présenté l'ensemble du projet, le code, les procédures de lancement et la documentation. De mon côté, j'ai notamment pu expliquer les éléments dont j'étais responsable, comme le backend, D3.js et Socket.io, tout en participant à la présentation du fonctionnement global.
Une transmission qui complétait la documentation écrite.
Le handoff, ou passation, ne consistait pas seulement à fournir l'accès au dépôt. Le nouveau développeur devait comprendre pourquoi certaines décisions avaient été prises, quelles limites appartenaient volontairement au prototype et quels sujets restaient ouverts. Les échanges directs lui permettaient de poser des questions que le guide d'installation ne pouvait pas anticiper. La combinaison de la documentation et de deux semaines de disponibilité réduisait le risque qu'il interprète une simplification temporaire comme une règle définitive de l'application.
Un apprentissage de la communication entre recherche et développement.
Le projet m'a appris qu'une collaboration avec des chercheurs exige de traiter simultanément trois dimensions : la faisabilité technique, la règle métier et la communication pendant la construction. Une solution peut fonctionner sans respecter la méthode, tandis qu'une demande scientifiquement pertinente peut nécessiter plusieurs reformulations avant de devenir développable. J'ai appris à ne pas répondre uniquement par le code, mais à vérifier ce que la fonctionnalité devait permettre d'observer et pourquoi cette observation comptait.
Des itérations qui auraient pu être encore plus courtes.
Malgré les démonstrations hebdomadaires, je pense que nous aurions pu solliciter certains retours plus rapidement. Une boucle plus courte entre une première implémentation et sa validation aurait permis d'identifier plus tôt une incompréhension et d'améliorer progressivement la qualité au lieu d'accumuler plusieurs changements avant la présentation. Cette autocritique ne remet pas en cause la collaboration régulière ; elle montre qu'un sujet de recherche gagne à confronter très tôt les hypothèses techniques aux personnes qui portent la méthode.

Retour au sommaire

Les résultats

Un questionnaire utilisable du début à la fin.
À la fin du stage, l'enquêteur pouvait parcourir l'ensemble du formulaire et terminer une simulation d'entretien. Le prototype ne se limitait donc pas à quelques champs indépendants destinés à illustrer une interface. Il permettait d'enchaîner les dimensions, d'afficher les questions conditionnelles, d'ajouter plusieurs événements lorsqu'une situation se répétait et de revenir sur les réponses. Ce résultat validait le premier élément obligatoire défini au début du projet.
Cinq dimensions de trajectoire réellement disponibles.
Le questionnaire et la visualisation prenaient en charge cinq dimensions de la vie. Chaque dimension regroupait les événements appartenant à un même domaine et disposait de sa propre ligne ou zone dans la représentation. Cette séparation donnait aux chercheurs plusieurs angles de lecture sans transformer la trajectoire en une seule succession d'événements indifférenciés. Elle constituait aussi une base extensible si la méthode devait ensuite ajouter ou réorganiser des domaines.
Une vingtaine de questions principales complétées par des séquences répétables.
Le questionnaire comportait plus de vingt questions de base. Ce nombre ne représentait pas la longueur maximale d'un entretien, car certains groupes pouvaient boucler selon les réponses. La trajectoire professionnelle demandait par exemple de décrire un emploi, puis proposait d'en ajouter un autre. Une personne ayant occupé plusieurs postes générait donc plusieurs occurrences de la même séquence. Le prototype pouvait adapter la collecte à la richesse du parcours au lieu d'imposer un nombre fixe d'événements.
Une visualisation correspondant aux réponses et aux périodes.
Le second objectif obligatoire a été atteint : les réponses saisies produisaient une trajectoire graphique dans laquelle les événements apparaissaient aux périodes prévues. Les dates de début, les dates de fin et les dimensions déterminaient leur position. Le résultat pouvait être contrôlé pendant l'entretien et corrigé lorsqu'une période ne correspondait pas au récit. La visualisation n'était donc pas une capture préparée pour la démonstration, mais un rendu calculé à partir des données du formulaire.
Deux modes de lecture fonctionnels.
Les vues séparées et superposées fonctionnaient dans la version finale du prototype. La vue séparée facilitait la lecture d'une dimension à la fois, tandis que la superposition permettait d'observer des événements concomitants dans plusieurs domaines. Un événement concomitant se déroule pendant tout ou partie de la même période qu'un autre. Le passage entre les modes démontrait que la même trajectoire pouvait soutenir plusieurs questions d'analyse sans demander une nouvelle saisie.
Des corrections possibles depuis deux points d'entrée.
L'enquêteur pouvait modifier les dates depuis le formulaire et depuis le graphique. Ce résultat répondait au retour selon lequel une personne peut corriger son récit après avoir vu l'ensemble de sa trajectoire. La modification mettait à jour les données puis recalculait la représentation, plutôt que de déplacer uniquement un élément visuel sans changer la réponse enregistrée. Cette cohérence entre interface et données était nécessaire pour que le graphique reste un outil de travail et pas seulement une illustration.
Une démonstration multi-écrans opérationnelle.
La synchronisation Socket.io fonctionnait suffisamment pour les démonstrations. L'enquêteur pouvait créer une room, l'enquêté la rejoindre, puis recevoir les mises à jour de la trajectoire sur son écran. Ce résultat matérialisait l'évolution la plus importante ajoutée pendant le stage : permettre aux deux participants de partager la représentation sans partager les commandes du formulaire. Il démontrait la faisabilité de l'expérience dans l'environnement local prévu pour le prototype.
Des défauts encore connus dans la synchronisation.
La livraison n'était pas exempte de bugs. La synchronisation des données graphiques n'était pas encore parfaite et certains enchaînements pouvaient produire un retard ou un état incohérent entre les écrans. Ce constat reste compatible avec l'objectif de preuve de concept, mais empêchait de considérer la communication temps réel comme prête pour un usage de terrain sans surveillance. Le résultat est donc une interconnexion démontrée, accompagnée d'un besoin de stabilisation clairement identifié pour la suite.
Une suite de tests entièrement passante, mais incomplète.
Tous les tests écrits passaient au moment de la remise. Ils couvraient les comportements que l'équipe avait choisi d'automatiser et réduisaient le risque de casser le formulaire, le graphique ou la synchronisation pendant les dernières modifications. Avec du recul, nous aurions pu écrire davantage de scénarios, notamment autour des cas limites et des pertes de connexion. Un résultat vert ne signifie que les cas décrits sont conformes ; il ne prouve pas que tous les comportements possibles ont été testés.
Des chercheurs estimant que le projet allait dans la bonne direction.
Le retour final des professeurs et sociologues était positif : le prototype leur semblait progresser dans la direction attendue. Cette appréciation validait la pertinence générale du formulaire, de la représentation et de l'expérience partagée. Elle ne constituait pas encore une validation scientifique complète. Les chercheurs ont précisé qu'ils auraient besoin de tester l'outil dans de véritables enquêtes afin d'observer son comportement face aux récits, hésitations et contraintes du terrain.
Une méthode évaluable, mais pas encore validée en situation réelle.
Les chercheurs considéraient que le prototype était suffisamment abouti pour évaluer leur proposition. Les simulations permettaient d'examiner la chronologie, les dimensions et l'effet du graphique pendant l'entretien. Aucun résultat ne permettait toutefois encore d'affirmer que l'outil améliorait réellement une enquête conduite avec une personne extérieure au projet. Cette distinction protège la crédibilité de la réalisation : nous avons produit l'instrument nécessaire à l'expérimentation, pas les conclusions de l'expérimentation elle-même.
Une diffusion encore limitée au cercle du projet.
À ma connaissance, la version finale n'a pas été présentée pendant mon stage à un public plus large que les chercheurs et enseignants déjà impliqués. Le prototype n'a donc pas obtenu de résultat mesurable en matière d'adoption, de nombre d'utilisateurs ou de diffusion institutionnelle. Sa valeur immédiate résidait dans la qualité de la base remise et dans sa capacité à soutenir les prochaines décisions du bureau d'étude.
Une installation réussie par le développeur suivant.
La personne chargée de poursuivre le projet a réussi à installer et lancer l'application à l'aide de la documentation et de la passation. Ce résultat vérifiait concrètement une partie de la transmissibilité du prototype. Le guide d'installation, la configuration de la base et le seed n'étaient pas seulement présents : ils permettaient à quelqu'un qui n'avait pas construit la première version de recréer l'environnement.
Une reprise technique différée pour des raisons extérieures au handoff.
Le nouveau développeur n'a pas commencé à modifier CAP2vie pendant les deux semaines de passation, car il était occupé sur d'autres travaux du bureau d'étude. Cette absence d'évolution immédiate ne signifie donc pas que l'installation ou la documentation avaient échoué. Elle montre cependant une limite de ce que je peux prouver : nous avons transmis une base exécutable et expliqué son fonctionnement, mais nous n'avons pas observé pendant cette période une première fonction développée de manière autonome par le repreneur.
Une évolution après mon départ que je ne peux pas attribuer précisément.
Je ne sais pas quels composants ont finalement été conservés ou modifiés après le stage. Les données et la suite du travail sont devenues confidentielles et je n'ai plus disposé de la visibilité nécessaire. Je ne présente donc pas comme acquis un déploiement, une réutilisation ou une adoption que je n'ai pas pu vérifier. Le résultat attesté s'arrête à la livraison du prototype, à son lancement par le repreneur et à la transmission des connaissances disponibles.
Une première base technique inexistante avant le stage.
Le laboratoire et le bureau d'étude disposaient initialement d'une idée et de schémas de recherche, mais pas de l'application correspondante. À notre départ, ils disposaient d'un dépôt versionné, d'un modèle de données, d'un questionnaire dynamique, d'une visualisation sur mesure, d'une communication multi-écrans, de tests et d'un site de documentation. Même si ces éléments nécessitaient encore une stabilisation, ils réduisaient le travail nécessaire pour passer d'une réflexion théorique à de premiers essais instrumentés.
La création d'une solution sans équivalent directement réutilisable.
Le résultat technique dont je suis le plus fier est ma capacité à construire la visualisation en partant de primitives, alors qu'aucun composant trouvé en ligne ne produisait directement la représentation demandée. Ma débrouillardise a consisté à rechercher les mécanismes disponibles, comprendre leur fonctionnement puis les combiner en fonction des règles du projet. Je n'ai pas inventé D3.js ni les échelles temporelles, mais j'ai conçu avec ces briques une solution spécifique à un problème pour lequel il n'existait pas de réponse prête à intégrer.
Une compréhension plus profonde de D3.js.
Le projet m'a appris à utiliser D3.js comme une bibliothèque de construction et non comme un catalogue de graphiques. Une bibliothèque fournit des fonctions réutilisables sans imposer toute l'architecture d'un framework. J'ai appris à relier des données à des éléments SVG, à employer des échelles de temps, à calculer des positions et à mettre à jour le rendu lorsque l'état changeait. Cette approche m'a donné davantage d'autonomie pour produire une visualisation sur mesure au lieu de chercher uniquement un composant proche du besoin.
Une meilleure maîtrise des états d'une connexion temps réel.
Socket.io m'a appris qu'une connexion ne se limite pas au cas où deux écrans sont disponibles et reçoivent correctement les événements. Il faut aussi envisager la création et la fermeture d'une room, l'arrivée tardive d'un client, la perte de connexion, la reconnexion, l'ordre des messages et la resynchronisation d'un état complet. Le prototype ne traitait pas encore parfaitement tous ces cas, mais les défauts rencontrés m'ont précisément montré pourquoi une connexion stable exige une gestion explicite de chacun d'eux.
Une progression dans la lecture du code d'autrui.
La réalisation de la majorité des revues a amélioré ma capacité à comprendre rapidement le travail d'autres développeurs, identifier ses effets sur mes propres composants et formuler une demande de correction. Relire un code exige de distinguer une préférence personnelle d'un problème réel de lisibilité, de cohérence ou de comportement. Cette responsabilité m'a donné une première expérience de contrôle collectif de la qualité, même sans rôle officiel de responsable technique.
Une contribution directe à l'obtention de mon titre professionnel.
CAP2vie faisait partie des réalisations que j'ai pu présenter pour démontrer les compétences attendues dans ma formation de Concepteur développeur d'applications. Le projet apportait des preuves de conception, de développement frontend et backend, de persistance, de test, de collaboration et de transmission. Il a donc contribué directement à l'obtention du titre, sans être présenté comme son unique condition : l'évaluation reposait également sur les autres éléments et compétences du parcours.
La communication comme principale compétence humaine développée.
Les échanges avec deux autres développeurs, une professeure-chercheuse et plusieurs spécialistes de sociologie m'ont appris à adapter mon vocabulaire et à vérifier la compréhension avant de coder. Je devais expliquer une contrainte JavaScript sans noyer les chercheurs dans l'implémentation, puis reformuler une règle scientifique pour qu'elle devienne exploitable par l'équipe technique. Cette communication était indispensable pour éviter qu'une application correcte du point de vue informatique réponde à une mauvaise interprétation du besoin.
Des preuves visibles déjà intégrées au portfolio.
La page présente déjà des captures du choix de profil, des interfaces locales et du parcours de création d'une enquête. Ces éléments permettent d'observer l'existence du prototype et son fonctionnement général sans exposer les données réelles d'une personne interrogée. Les textes détaillent également les choix techniques et la contribution personnelle. Je limite les preuves à ce qui peut être publié : certains éléments du projet, du code et des évolutions postérieures restent confidentiels.
Un bénéfice consistant à rendre une expérimentation possible.
Les cinq mois ont fourni aux chercheurs un prototype permettant d'examiner comment des outils numériques pourraient moderniser le déroulement des enquêtes sociologiques. La participation de professeurs du LIG et d'autres universités, notamment Rennes, ouvrait un potentiel d'utilisation au-delà d'un seul laboratoire. Je parle néanmoins d'un potentiel à l'échelle de plusieurs équipes françaises, et non d'un déploiement national déjà réalisé. Le bénéfice prouvé était de disposer d'une base concrète pour tester cette ambition.

Retour au sommaire

Les lendemains du projet

Une mission de reprise volontairement plus large que la correction de bugs.
La personne arrivée après les trois stagiaires devait améliorer l'outil et étudier son passage d'un prototype vers une application plus complète. Sa mission ne se limitait donc pas à conserver la démonstration dans son état de septembre 2024. Elle devait comprendre les choix existants, stabiliser les fonctions utiles et décider comment traiter les limites laissées par notre périmètre. La passation et Docusaurus lui donnaient un point de départ, mais les décisions de produit et de recherche restaient à poursuivre avec les encadrants.
La synchronisation comme chantier prioritaire.
Les défauts connus dans l'échange des données graphiques devaient être corrigés après notre départ. Une communication temps réel destinée à des entretiens réguliers devait mieux gérer les pertes de connexion, les reconnexions et la remise à niveau de l'écran de l'enquêté. La priorité était cohérente avec le rôle du second écran : il ne devait toujours pas bloquer le formulaire, mais il devait redevenir fiable sans demander une intervention technique à chaque anomalie.
Aucun essai réel déjà planifié à la fin du stage.
Les chercheurs avaient indiqué qu'une validation avec de véritables personnes interrogées serait nécessaire, mais aucun calendrier d'expérimentation n'était arrêté au moment de notre départ. La prochaine étape méthodologique restait donc à organiser : définir les participants, le protocole, les conditions de consentement et les critères d'observation. Le prototype rendait cet essai possible, mais ne déterminait ni sa date ni son organisation scientifique.
Une poursuite effective que je ne peux pas confirmer.
Je ne sais pas si CAP2vie a continué à être développé officiellement après la passation. Le nouveau développeur avait réussi à installer le projet, mais travaillait alors sur d'autres missions du bureau d'étude. Je ne transforme donc pas l'intention de poursuivre en résultat vérifié. Aujourd'hui, je peux décrire la feuille de route envisagée à la fin du stage, pas l'état réel d'une version ultérieure à laquelle je n'ai plus accès.
La création de questionnaires non retenue comme priorité immédiate.
Une interface permettant aux sociologues de construire eux-mêmes leurs questionnaires avait été évoquée comme évolution possible, mais elle ne faisait pas partie des prochaines priorités annoncées. Avant d'ajouter cet éditeur, l'équipe devait consolider le fonctionnement existant. Ce choix évitait d'introduire un système complexe de types de questions, de versions et de compatibilité des réponses alors que la synchronisation et l'usage du prototype restaient encore à éprouver.
La gestion de plusieurs enquêtes et personnes comme évolution prévue.
Une version plus aboutie devait enregistrer et organiser plusieurs enquêtes ainsi que plusieurs participants. Cette fonction exigeait de séparer correctement les jeux de données, de retrouver un entretien et de conserver les relations entre questionnaire, réponses, événements et trajectoire. Elle devait transformer la structure déjà préparée dans le prototype en véritable espace de gestion, plutôt qu'en démonstration centrée sur un parcours à la fois.
Une authentification et des rôles à ajouter.
Le fonctionnement local et le mot de passe d'une room ne suffisaient pas pour administrer plusieurs études. Une future version devait identifier les utilisateurs et appliquer des rôles. L'authentification vérifie qui se connecte ; l'autorisation détermine ensuite ce que cette personne peut consulter ou modifier. Un enquêteur, un responsable d'étude et une personne visualisant sa trajectoire n'ont pas besoin des mêmes accès. Cette évolution était indispensable avant toute utilisation régulière avec des données réelles.
Une anonymisation automatique prévue dans la suite.
L'application devait finir par prendre elle-même en charge l'anonymisation des données recueillies. Cette fonction aurait permis de dissocier les informations d'identité des réponses destinées à l'analyse selon une procédure reproductible. Elle devait cependant être conçue avec les chercheurs : supprimer uniquement le nom et le prénom ne garantit pas qu'une trajectoire très particulière ne puisse pas être reconnue. La version future devait donc définir les champs concernés, le moment de la transformation et les personnes autorisées à consulter les informations avant anonymisation.
Un export CSV comme sortie envisagée.
Le format prévu pour extraire les données était le CSV. Un fichier CSV organise les informations sous forme de lignes et de colonnes séparées par un caractère, ce qui permet de l'ouvrir avec un tableur ou de l'importer dans un logiciel d'analyse. L'export devait préserver les dimensions, les dates et les événements dans une structure compréhensible. La plateforme de destination exacte n'était pas encore connue, ce qui imposait de définir un format suffisamment documenté pour rester exploitable par plusieurs outils.
Une utilisation locale conservée comme mode principal.
L'application devait rester utilisable localement dans le contexte des entretiens. Ce choix limitait la dépendance à un hébergement public et correspondait à une utilisation en présence de l'enquêteur et de l'enquêté. Il ne supprimait pas les besoins de sécurité ou de sauvegarde : des données sensibles restent sensibles lorsqu'elles sont stockées sur un poste local. Une version aboutie devait donc documenter l'installation, le stockage et la récupération sans supposer qu'un fonctionnement hors ligne protège automatiquement toutes les informations.
Une synchronisation à rendre robuste au-delà de la démonstration locale.
Même si l'application restait installée localement, la communication entre écrans devait évoluer pour supporter des conditions réseau moins idéales et éventuellement des usages distants. Cette amélioration impliquait de gérer la latence, les interruptions et la resynchronisation sans perdre l'état du graphique. La distinction est importante : le mode d'installation pouvait rester local tandis que le canal de communication devait devenir plus robuste et ne plus dépendre des conditions contrôlées du bureau.
Une qualité future évaluée par les retours des utilisateurs.
Les chercheurs prévoyaient d'apprécier l'outil au moyen des retours des enquêteurs et des personnes participant aux études. Ces retours devaient indiquer si le formulaire soutenait correctement la conversation, si la trajectoire était comprise et si sa présence aidait à corriger ou enrichir le récit. Cette évaluation qualitative était plus pertinente qu'un simple nombre de clics. Elle devait confronter l'hypothèse de recherche aux usages réels avant de généraliser l'application.
Une documentation destinée à continuer d'évoluer.
Docusaurus ne devait pas rester une photographie figée du prototype remis en septembre 2024. Les futurs développeurs étaient censés mettre à jour l'installation, l'architecture et les fonctions au fil de leurs modifications. Une documentation non maintenue peut devenir plus dangereuse qu'une absence de guide si elle décrit une commande ou une règle qui n'existe plus. La continuité du projet dépendait donc autant de l'évolution du code que de celle de son explication.
Une ambition concernant un réseau national d'universités partenaires.
À long terme, CAP2vie pouvait être mis à disposition d'un réseau d'universités partenaires en France. La présence de chercheurs du LIG et de Rennes donnait un premier cadre à cette ambition. Une diffusion nationale aurait toutefois exigé une application stabilisée, une gouvernance des données, un support et une méthode validée lors de véritables enquêtes. Je présente donc cette échelle comme la direction envisagée par le projet, et non comme une adoption déjà obtenue.
Une confidentialité qui limite volontairement mon suivi actuel.
Je n'ai aujourd'hui aucune information sur l'état du projet. Si le laboratoire me demandait de contribuer à nouveau, je pourrais intervenir, mais uniquement dans ses locaux et dans le respect de ses règles : le code, les données et les éléments confidentiels ne doivent pas sortir. Cette contrainte explique pourquoi je ne peux ni publier une version récente ni vérifier la feuille de route. Elle protège les informations de recherche et m'oblige à limiter le portfolio aux preuves dont la diffusion est autorisée.
Une compétence de visualisation déjà réutilisée en Business Intelligence.
Je n'ai pas réemployé CAP2vie dans le domaine de la sociologie, mais les connaissances acquises sur les représentations sur mesure sont directement utiles dans mon entreprise actuelle. Je les mobilise pour un service de Business Intelligence, ou BI, destiné à rendre des données opérationnelles compréhensibles. La Business Intelligence regroupe les méthodes et outils permettant de transformer des données en indicateurs et visualisations d'aide à la décision. Le contexte change, mais la démarche reste proche : structurer des données puis construire la représentation adaptée à la question posée.
Un projet professionnellement utile par ses compétences plutôt que par son domaine.
CAP2vie reste très éloigné de mon activité actuelle autour des ERP, des API et des outils métier. Je ne cherche donc pas à créer artificiellement une continuité entre la sociologie et Odoo. Sa place dans mon parcours vient des compétences transférables : concevoir à partir d'un besoin spécialisé, créer une visualisation sans solution prête à l'emploi, gérer un backend et une communication temps réel, relire du code et dialoguer avec des experts non développeurs. Ce sont ces acquis, plutôt que le sujet scientifique lui-même, qui continuent à nourrir mon profil.

Retour au sommaire

Mon regard critique

Un algorithme de résolution insuffisamment approfondi avant la première intégration.
Ma principale erreur a été de ne pas consacrer assez de temps à l'algorithme qui transformait les réponses du formulaire avant d'intégrer les premières fonctionnalités. Un algorithme de résolution désigne ici l'ensemble des règles qui interprètent les réponses, créent les événements, complètent les dates inconnues, associent une dimension et préparent les données du graphique. Tant que seuls les cas les plus simples étaient utilisés, la première version semblait correcte. Les réponses plus variées ont ensuite révélé que cette base devait être reprise.
Un bridge formulaire-graphique devenu le point le plus retravaillé.
La partie d'architecture la plus souvent modifiée était le bridge entre le formulaire, les réponses enregistrées et leur insertion dans la visualisation. Un bridge, ou pont de transformation, relie deux représentations qui n'ont pas le même rôle : le formulaire produit des réponses proches du langage de l'entretien, tandis que D3.js attend des événements structurés avec des dates et une dimension. Si ce pont mélange validation, estimation temporelle et dessin, chaque nouvelle règle oblige à modifier plusieurs couches. Nous aurions gagné à le concevoir comme un module indépendant et testable dès le départ.
Un développement probablement commencé trop rapidement.
Le cahier des charges était suffisamment précis pour définir le prototype, mais cela ne signifiait pas que l'algorithme interne était déjà résolu. Nous avons probablement commencé l'intégration trop tôt, en confondant la compréhension du besoin général avec la maîtrise de tous les cas de transformation. Cette nuance est importante : davantage de documentation métier n'aurait pas nécessairement suffi. Il fallait prendre un temps technique spécifique pour simuler plusieurs parcours, formaliser les règles et vérifier leur cohérence avant de construire les interfaces autour d'elles.
Une répartition des tâches globalement équilibrée.
Je considère que la distribution du travail entre les trois stagiaires était pertinente. Mes collègues ont pris en charge le formulaire et la base de données, tandis que j'ai travaillé sur le backend, D3.js et Socket.io. Je n'aurais pas souhaité échanger mon périmètre contre davantage de travail sur le formulaire ou la persistance : les sujets qui m'étaient attribués étaient ceux que je trouvais les plus intéressants et les plus stimulants. Le problème principal ne venait donc pas d'une mauvaise distribution des responsabilités.
Des revues de code utiles sans devenir une charge excessive.
Le fait d'effectuer la majorité des revues ne m'a pas empêché d'avancer sur mes propres tâches. L'équipe ne produisait pas un volume de commits assez important pour transformer cette responsabilité en goulot d'étranglement. Ces revues m'ont au contraire aidé à comprendre le formulaire et la base dont dépendaient mes composants. Avec une équipe ou un rythme plus importants, cette organisation aurait nécessité une rotation ou des règles plus formelles, mais elle restait proportionnée au prototype.
Des tests insuffisants sur les scénarios de réponses complexes.
La principale faiblesse de la suite de tests concernait la diversité des parcours possibles dans le questionnaire. Une réponse conditionnelle pouvait ajouter plusieurs emplois, produire une date approximative, laisser une borne inconnue ou modifier un événement après coup. Chaque combinaison pouvait influencer le bridge et la trajectoire finale. Nous avions testé le fonctionnement attendu, mais pas assez de cas particuliers ni de combinaisons. Le résultat vert de la suite masquait donc encore un espace de comportements peu explorés.
Des déconnexions et reconnexions qui auraient mérité davantage de scénarios.
Nous aurions également dû approfondir les tests de Socket.io. Il fallait vérifier ce qui se passait lorsqu'un écran rejoignait une room en retard, se déconnectait pendant une mise à jour, saisissait de mauvais identifiants ou revenait après plusieurs modifications. Ces scénarios ne concernaient pas le parcours idéal, mais ils déterminaient la stabilité perçue du partage. Le bug connu de synchronisation montrait précisément que la connexion avait été validée dans son fonctionnement principal sans couvrir suffisamment ses états dégradés.
Des périodes estimées pouvant produire une continuité artificielle.
Reprendre la fin de l'événement précédent comme début inconnu, ou prolonger un événement jusqu'au suivant, peut créer une période qui semble plus précise qu'elle ne l'est réellement. Ce risque était connu et accepté dans la méthode sociologique utilisée pour le prototype. Il ne rend donc pas l'algorithme incorrect par principe, mais exige de distinguer une estimation d'une date déclarée avec certitude. Une version plus aboutie devrait conserver cette information de précision afin que le graphique ne transforme pas une convention d'enquête en fait certain.
Une modification directe du graphique ambitieuse mais adaptée.
Je ne considère pas que l'édition des dates depuis la visualisation ait dépassé le périmètre raisonnable du stage. Elle répondait à un besoin central : permettre à la personne de corriger sa trajectoire lorsqu'elle la voyait dans son ensemble. Cette fonction a entraîné une reprise d'architecture, mais sa valeur justifiait l'effort. La leçon n'est pas de la supprimer ; elle est de prévoir plus tôt que le graphique devait être un point d'entrée interactif vers les données et non un simple résultat en lecture seule.
Socket.io comme choix toujours pertinent.
Avec du recul, Socket.io reste une solution adaptée au partage du graphique entre deux écrans. La bibliothèque fournissait les événements, les rooms et la gestion de base des connexions nécessaires au prototype JavaScript. Les défauts rencontrés ne prouvent pas que l'outil était mauvais : ils montrent que la logique de synchronisation et de reprise devait être davantage développée et testée. Remplacer la bibliothèque n'aurait pas supprimé la nécessité de gérer les mêmes états réseau.
Un fonctionnement local cohérent avec une preuve de concept.
Le choix de limiter le prototype à une exécution locale n'a pas diminué sa valeur par rapport à l'objectif fixé. Il permettait de démontrer le formulaire, le graphique et le second écran sans ajouter trop tôt un hébergement, une administration et une sécurité de production. Cette limite aurait été problématique si nous avions présenté l'outil comme prêt pour un réseau national, mais elle était adaptée à une première validation dans les locaux du laboratoire.
Une protection de room suffisante uniquement dans ce contexte contrôlé.
L'identifiant et le mot de passe d'une room apportaient une séparation acceptable pendant des simulations locales. Ils évitaient qu'un écran rejoigne facilement le mauvais entretien. Je ne considérerais pas le même dispositif comme suffisant pour un déploiement réel : il manquerait notamment une authentification des chercheurs, des droits, une gestion robuste des secrets et des protections réseau. La pertinence d'une mesure de sécurité dépend donc du niveau d'exposition et de la sensibilité de l'usage qu'elle protège.
Une anonymisation automatique correctement reportée.
Je ne pense pas que nous aurions dû traiter l'anonymisation intégrée plus tôt. Le stage devait d'abord vérifier le recueil et la représentation, tandis que les chercheurs continuaient à définir la manière appropriée de traiter les données. Ajouter trop rapidement une suppression automatique aurait pu donner une fausse impression de sécurité. Le report était raisonnable tant que le prototype restait utilisé avec des simulations et qu'il n'était pas présenté comme une plateforme prête à collecter des données réelles à grande échelle.
L'absence d'enquête réelle comme principale limite du résultat.
La restriction la plus importante ne concerne pas une bibliothèque ou un écran : aucune personne extérieure au projet n'a utilisé CAP2vie pendant un véritable entretien sociologique. Les chercheurs connaissaient la méthode et le prototype, ce qui facilitait leurs simulations. Un utilisateur réel aurait pu hésiter, interpréter différemment une question, réagir au graphique ou raconter un événement impossible à faire entrer dans nos scénarios. Tant que cette confrontation n'avait pas eu lieu, la pertinence en conditions réelles restait une hypothèse.
Des rendez-vous hebdomadaires suffisants, mais un premier retour de bout en bout trop tardif.
La fréquence d'une démonstration par semaine était correcte pour le rythme du stage. Ce que j'aurais souhaité obtenir plus tôt n'était pas nécessairement davantage de réunions, mais un retour dès que le formulaire avait été relié aux données du graphique. Cette première chaîne complète constituait le moment où les chercheurs pouvaient observer l'effet réel de leurs réponses. La montrer plus tôt aurait révélé les faiblesses du bridge avant que plusieurs fonctionnalités dépendent de sa première architecture.
Trois décisions que je prendrais différemment.
Si je recommençais, je construirais d'abord une tranche fonctionnelle complète avec quelques questions représentatives, du formulaire jusqu'au graphique. Ensuite, je formaliserais l'algorithme de résolution en recensant les cas spéciaux avant d'étendre le nombre de questions. Enfin, je demanderais aux chercheurs de tester immédiatement cette première chaîne, puis j'ajouterais les fonctions selon les défauts observés. Ces décisions concentreraient l'effort sur la solidité du cœur avant la largeur du prototype.
Une maîtrise de D3.js que j'évaluais à 6 sur 10.
À la fin du projet, j'estimais mon niveau à 6 sur 10. J'étais capable de construire une visualisation originale, d'utiliser SVG et les échelles temporelles et de mettre à jour le rendu de manière interactive. Je restais néanmoins conscient de la profondeur de D3.js. La bibliothèque couvre de nombreux mécanismes de transformation, de disposition, d'interaction et de performance que le prototype n'avait pas exigés. La réussite du graphique démontrait une maîtrise utile, pas une expertise exhaustive de tout l'écosystème.
Une maîtrise du backend et de Socket.io évaluée à 7 sur 10 à l'époque.
Je situais mon niveau de l'époque à 7 sur 10. Je pouvais concevoir les routes, relier les couches de l'application, créer les rooms et transmettre les mises à jour nécessaires. Les défauts de synchronisation montraient toutefois qu'il me restait à approfondir les scénarios de panne, la reprise d'état et la robustesse d'une application réellement exploitée. Cette note tient compte à la fois de l'autonomie obtenue et des limites observables du prototype.
Un niveau backend aujourd'hui nettement supérieur.
Depuis 2024, j'ai développé et maintenu des fonctions backend utilisées en production dans mon entreprise. Les contraintes y sont plus fortes : continuité de service, données métier, sécurité, intégrations et conséquences directes d'une erreur pour les utilisateurs. Cette expérience a amélioré ma capacité à structurer une logique, diagnostiquer un problème et prévoir les cas dégradés. Je ne donne pas une note artificielle à Socket.io aujourd'hui sans pratique récente équivalente, mais ma maîtrise générale du backend est clairement supérieure à celle de la fin du stage.
Un rendu visuel volontairement sommaire.
La partie du prototype qui me satisfaisait le moins était l'apparence du graphique. Le résultat fonctionnait et démontrait la représentation attendue, mais son design restait simple. Ce niveau de finition était cohérent avec une preuve de concept centrée sur l'algorithme et l'interaction. Il aurait néanmoins fallu un travail supplémentaire d'interface, de hiérarchie visuelle et d'accessibilité avant de le présenter comme un outil destiné à un usage régulier par un réseau d'universités.
D3.js comme choix technique que je maintiens.
Parmi les décisions prises, D3.js reste celle qui me paraît la plus pertinente. Une bibliothèque de graphiques préconstruits aurait accéléré l'affichage d'un graphique classique, mais nous aurait rapidement bloqués face aux cinq dimensions, aux périodes, aux superpositions et à l'édition. D3.js nous donnait les primitives nécessaires sans imposer une représentation incompatible. Sa profondeur augmentait l'effort d'apprentissage, mais cette complexité correspondait à la liberté dont le projet avait réellement besoin.
Accorder davantage de temps à l'architecture et à l'algorithmie.
Le principal conseil que je donnerais à une équipe travaillant sur un prototype de recherche aux besoins mouvants est de ne pas confondre vitesse de production et vitesse d'apprentissage. Avant de multiplier les écrans, il faut identifier le cœur algorithmique, lui soumettre des cas simples et extrêmes, puis construire une première chaîne de bout en bout. Une architecture n'a pas besoin d'être définitive dès le départ, mais elle doit isoler ce qui risque de changer. Le temps investi dans cette réflexion réduit ensuite les reprises qui ralentissent réellement le projet.

Retour au sommaire

Compétences rattachées

Développement Frontend (React/Next.js)Développement Backend & API Persévérance Autonomie Communication

Développement d'une application web de trajectoires de vie

Preuves visuelles

Un stage de cinq mois pour valider une formation de concepteur-développeur.

Un projet accueilli au Laboratoire d'Informatique de Grenoble.

Un encadrement par une professeure-chercheuse travaillant sur les usages sociologiques.

CAP2vie, un nom construit autour du « cap de vie ».

La trajectoire de vie comme objet d'étude.

Un outil pour comparer des parcours et éclairer des décisions.

Le remplacement d'un recueil principalement effectué sur papier.

Une utilisation prévue pendant des entretiens en présentiel et sur le terrain.

Deux rôles complémentaires dans le même entretien.

Une visualisation partagée sur plusieurs écrans.

Des questions organisées autour du contenu et du contexte des événements.

Des informations sensibles nécessitant une anonymisation après l'enquête.

Un projet commencé à partir d'une idée et non d'un logiciel existant.

Un périmètre transversal entre visualisation, backend et temps réel.

Une stack technique choisie collectivement pour construire le premier prototype.

Un prototype de recherche comme résultat attendu.

Matérialiser une méthode de recherche dans un prototype.

Limiter le noyau initial à deux fonctions obligatoires.

Partir d'un questionnaire défini par les chercheurs.

Recueillir du texte, des dates et des périodes.

Transformer chaque événement en intervalle chronologique.

Représenter les dimensions séparément et simultanément.

Préserver la fidélité du récit plutôt que produire un simple graphique esthétique.

Rendre le formulaire utilisable par l'enquêteur.

Rendre la trajectoire compréhensible par la personne enquêtée.

Ajouter une interconnexion multi-écrans en cours de projet.

Isoler chaque entretien dans une room de communication.

Ne pas bloquer l'enquêteur si l'écran secondaire se déconnecte.

Évaluer le prototype par l'usage plutôt que par un périmètre de production.

Préparer explicitement une reprise par un autre développeur.

Des besoins susceptibles d'évoluer avec le prototype.

Une architecture impossible à réussir entièrement du premier coup.

Une visualisation ne correspondant à aucun graphique standard.

Un graphique visuellement plausible mais scientifiquement faux.

Une représentation susceptible d'influencer l'interprétation.

Des désaccords relevant de la méthode sociologique.

Une expérience de formulaire pouvant perturber l'entretien.

Une extension multi-écrans ajoutant un nouveau point de défaillance.

Une interruption qui ne devait pas bloquer la saisie.

Un fonctionnement local qui ne prouvait pas la robustesse sur Internet.

La perte possible d'informations pendant un prototype.

Une anonymisation non automatisée dans l'application.

Des fonctions d'accès encore limitées par le périmètre.

Aucun export ni envoi vers une plateforme spécialisée.

Une échéance souple, mais un résultat attendu en cinq mois.

Une reprise future dépendante de la qualité de la transmission.

Commencer par documenter le besoin.

Transformer les explications en supports de travail.

Ne pas créer de maquettes qui n'auraient pas réduit l'incertitude.

Organiser le stage en cycles d'itération.

Choisir Nuxt et Vue à partir des compétences de l'équipe.

Conserver un backend JavaScript simple avec Express.

Modéliser les données avec PostgreSQL et Prisma.

Définir les principales entités du domaine.

Construire un formulaire unique organisé avec un stepper.

Adapter les questions aux réponses précédentes.

Associer chaque réponse à une dimension.

Construire des périodes à partir de dates exactes ou estimées.

Transformer les réponses en données temporelles pour D3.js.

Construire le graphique avec les primitives de D3.js.

Proposer plusieurs modes de lecture des dimensions.

Faire évoluer le graphique en trois versions principales.

Permettre la correction depuis le formulaire et le graphique.

Revoir l'architecture pour rendre le graphique modifiable.

Faire vérifier les périodes pendant l'entretien.

Prendre le lead sur l'ajout de l'interconnexion.

Créer une room identifiée et protégée par un mot de passe.

Synchroniser uniquement l'état nécessaire au second écran.

Prévoir une reconnexion manuelle dans le prototype.

Écrire des tests pour les fonctions principales.

Présenter l'avancement chaque semaine.

Versionner le travail collectif dans GitLab.

Préparer deux configurations locales de démonstration.

Documenter l'installation et les données de démonstration.

Stabiliser le prototype avant la présentation finale.

Effectuer une passation directe avec le développeur suivant.

Trois développeurs stagiaires réunis sur le même prototype.

Une professeure-chercheuse à la fois encadrante, informaticienne et référente métier.