Outil de gestion et de réservation pour professionnels du bien-être

Contexte du projet

J’ai participé au développement d’une plateforme de prise de rendez-vous en ligne dédiée au secteur du bien-être.

Le projet s’organisait autour d’une application mobile destinée aux utilisateurs ainsi qu’une interface web d’administration pensée pour les professionnels. Le travail s’est déroulé entièrement à distance, ce qui demandait surtout de l’auto-discipline, ainsi qu’une bonne organisation et communication avec l’équipe.

Analyse produit & cadrage

Le projet s’inspirait de plateformes comme Planity, Treatwell ou Booksy, avec l’objectif de proposer une solution de réservation plus accessible, tant pour les professionnels que pour les particuliers.

Il répondait à un besoin concret, proposer une alternative aux outils existants souvent coûteux.

Nous avons commencé par analyser les solutions du marché afin d’identifier leurs points forts, leurs limites et les usages réels. Cette étape a permis de clarifier le périmètre et d’éviter de partir dans des directions trop larges.

Certaines pistes, comme l’intégration de professionnels du domaine médical, ont été envisagées mais volontairement écartées en raison de contraintes réglementaires plus strictes et d’une complexité métier plus élevée.

Parmi les fonctionnalités prévues, on retrouvait le multilingue, les notifications, une messagerie interne ainsi que l’intégration future d’un système de paiement en ligne.

Rôle dans l’équipe

J’ai d’abord travaillé sur la modélisation des données et le développement back-end, avant de prendre en charge l’interface web d’administration.

Au fil du projet, mon rôle est devenu plus transversal. Une grande partie des entités liées aux établissements, des DTO et des services a été prise en charge, avec des validations techniques ponctuelles.

J’ai également servi de point de relais entre les différentes parties du projet, car les ajustements côté front, mobile ou maquettes impliquaient souvent des modifications en back.

Ce positionnement m’a permis de couvrir plusieurs niveaux, de la structuration technique à la logique métier, en passant par la base de données, l’API, les composants front-end, les formulaires, la validation et l’intégration.

Modélisation des données

À partir des cahiers des charges, les données nécessaires ont été identifiées et structurées, y compris celles qui n’étaient pas explicitement formulées.

Une première version d’un dictionnaire de données a été construite, puis confrontée à celles de l’équipe avant de fusionner les propositions en un modèle unique cohérent.

Le schéma a ensuite été retranscrit sur dbdiagram pour visualiser les relations entre entités, puis affiné progressivement, passant d’environ 25 à plus de 35 tables à mesure que le besoin se précisait.

Back-end & API

La partie back-end a été développée avec NestJS, TypeORM et PostgreSQL, dans un environnement Docker.

Des entités alignées avec le modèle SQL ont été mises en place, avec une attention particulière portée aux relations, aux clés étrangères, aux champs typés, aux timestamps et aux enums. Certaines options comme eager ou cascade ont été utilisées pour simplifier certaines opérations et accélérer le développement, avec des limites à prendre en compte sur des cas plus complexes.

Le travail sur les DTO, les services et les contrôleurs a permis de structurer la logique métier dans les services et les points d’entrée dans les contrôleurs.

Ce travail a également mis en évidence un problème d’alignement entre le back et le front, certaines structures n’étant pas directement exploitables côté interface, ce qui a nécessité des ajustements de typage et de gestion des données.

Côté services, des opérations classiques ont été mises en place ainsi que des traitements plus spécifiques autour des relations entre entités, en utilisant notamment le QueryBuilder de TypeORM pour construire des requêtes plus précises et éviter des incohérences.

Géolocalisation

Une fonctionnalité clé consistait à rechercher les établissements proches d’un utilisateur à partir de coordonnées GPS.

Après comparaison de plusieurs solutions, j’ai fait le choix d’utiliser Geolib, qui propose des fonctions directement exploitables pour ce type de besoin (calcul de distance, tri par proximité).

Une alternative plus précise existait, mais elle était plus lourde et davantage adaptée à des cas avancés (type navigation GPS), sans réelle valeur ajoutée pour ce projet.

Tests & fiabilisation

J’ai été chargée de tester les routes API une par une via Swagger.

Pour chaque route, je simulais des requêtes JSON, parfois avec des objets imbriqués ou des données liées à préparer en amont. En cas d’erreur, je m’appuyais sur les retours Swagger, les logs Docker et le code pour identifier puis corriger le problème.

Cette phase a permis de valider le fonctionnement de l’API avant son utilisation en front.

Interface web d’administration

Sur la partie front-end, j’ai eu une grande liberté dans mes choix techniques. L’architecture a été structurée, les constantes définies et les premiers composants réutilisables mis en place.

J’ai choisi styled-components pour garder un contrôle précis sur le style, tout en conservant une logique adaptée à React, basée sur un thème global, des styles conditionnels et des composants isolés, réutilisables et composables.

Composants & TypeScript

J’ai mis en place une base de composants pour structurer l’interface et TypeScript m’a permis de typer proprement ces derniers, en combinant mes propres props avec les attributs natifs HTML.

Dans certains cas, les éléments natifs du navigateur se sont révélés trop limités. J’ai donc recréé certains éléments pour garder un contrôle total sur leur design et leur comportement.

Responsive, hooks & i18next

J’ai développé des hooks personnalisés pour gérer le responsive et certains comportements d’interface.

Par exemple, un hook de détection du système d’exploitation permettait d’adapter l’affichage, comme masquer certaines actions lorsqu’elles ne sont pas pertinentes pour l’utilisateur.

L’interface était aussi multilingue avec i18next, avec des traductions adaptées au français et à l’anglais.

Formulaires & validation avancée

La gestion des formulaires reposait sur react-hook-form et Yup.

Certains formulaires demandaient une logique plus avancée pour gérer des données dynamiques et structurer correctement les données envoyées à l’API.

Conclusion

Ce projet m’a permis de travailler sur un cycle de développement complet, de la compréhension du besoin jusqu’à la mise en place d’une interface exploitable.

Au-delà de la technique, il a mis en évidence des problématiques concrètes liées au cadrage. Certains éléments étaient flous au départ et ont dû être clarifiés en cours de projet, ce qui a nécessité d’ajuster régulièrement les choix techniques et l’architecture.

Cette expérience a également renforcé l’autonomie et la capacité à prendre des responsabilités, tout en contribuant à la cohérence globale du projet.

Elle montre que la technique seule ne suffit pas. La qualité d’un projet dépend aussi de la clarté du besoin, de la cohérence des choix d’architecture et de la capacité à s’adapter à un contexte qui évolue en cours de projet.