Livrer cinq applications cohérentes sans multiplier les coûts par cinq

Un acteur de la santé connectée avait besoin de cinq applications : un portail patient, un portail praticien, un back-office administrateur, une application mobile, et une bibliothèque de composants partagée. Cinq projets distincts auraient signifié cinq équipes, cinq budgets, et cinq sources d'incohérences. On a livré le tout depuis une seule codebase.

Le contexte

Notre client lançait une marketplace de mise en relation entre praticiens du bien-être et patients. Le produit devait être accessible sur cinq interfaces différentes dès le lancement :

• Les patients avaient besoin d'un portail web pour chercher un praticien, réserver et payer — et d'une application mobile pour la même chose en déplacement.
• Les praticiens avaient besoin d'un espace professionnel complet : agenda, gestion des cabinets, tarifs, clients, collaborateurs, abonnement.
• Les administrateurs avaient besoin d'un tableau de bord pour valider les inscriptions, suivre les paiements et superviser la plateforme.
• Les développeurs avaient besoin d'une bibliothèque de composants réutilisables pour que les cinq applications aient la même apparence et le même comportement.

Cinq interfaces, quatre publics différents, mais un seul budget et un seul planning.

Le défi

1. Maintenir la cohérence entre cinq applications. Un bouton, un champ de date, un tableau — ces éléments apparaissent dans les cinq applications. Si le design du bouton change, il doit changer partout. Si un bug est corrigé dans le sélecteur de date, la correction doit se propager à toutes les interfaces. Avec cinq projets séparés, ce genre de synchronisation devient un cauchemar.

2. Partager la logique métier sans la dupliquer. Les cinq applications consomment la même API. Les types de données (un rendez-vous, un praticien, un paiement) sont les mêmes partout. Dupliquer ces définitions dans chaque projet, c'est garantir qu'elles divergeront à la première modification.

3. Permettre le développement parallèle. Pendant qu'un développeur travaille sur le portail praticien, un autre doit pouvoir avancer sur l'application mobile sans être bloqué. Les cinq applications doivent pouvoir évoluer indépendamment, tout en partageant un socle commun.

4. Couvrir web et mobile avec une équipe réduite. Le portail patient existe en version web et en version mobile native (iOS et Android). Développer et maintenir deux technologies complètement différentes pour le même parcours utilisateur aurait doublé l'effort.

Notre approche

Une bibliothèque de composants partagée

Le premier chantier a été de construire une bibliothèque de 36 composants réutilisables : champs de texte, sélecteurs de date et d'heure, boutons, modales, tableaux, onglets, menus, systèmes de pagination, formulaires d'upload d'images, barres de recherche, notifications...

Cette bibliothèque est le socle visuel et fonctionnel de toutes les applications web. Quand on ajoute la gestion des erreurs sur un champ de formulaire, c'est ajouté partout. Quand on optimise le composant de tableau pour les grands volumes de données, toutes les applications en bénéficient.

Résultat concret : les trois portails web (patient, praticien, administrateur) ont été développés deux à trois fois plus vite que s'ils avaient chacun leur propre bibliothèque de composants.

Trois portails web, un seul cadre technique

Les trois applications web partagent le même cadre technique, les mêmes conventions de code, et la même structure de projet. Un développeur qui termine une fonctionnalité sur le portail praticien peut immédiatement passer au portail administrateur sans temps d'adaptation. Les patterns sont les mêmes : même façon de gérer l'authentification, même façon d'appeler l'API, même façon de structurer les pages.

Mais chaque portail reste indépendant. On peut déployer le portail praticien sans toucher au portail patient. On peut ajouter une page au back-office sans impacter les deux autres interfaces.

Une application mobile qui partage le socle

Pour la version mobile, on a utilisé une technologie qui permet de produire des applications iOS et Android à partir d'une seule base de code. L'application mobile partage les mêmes types de données et les mêmes appels API que les portails web — quand l'API évolue, les types sont mis à jour une seule fois et propagés partout.

Une API centrale comme source de vérité

Les cinq applications consomment une seule API, qui expose 102 fonctionnalités. Chaque interface n'utilise que les fonctionnalités dont elle a besoin :

• Le portail patient utilise la recherche de praticiens, la réservation, le paiement et l'historique
• Le portail praticien utilise la gestion d'agenda, de cabinets, de tarifs, de clients et d'abonnement
• Le back-office utilise la validation de comptes, le suivi des paiements et la gestion des utilisateurs
• L'application mobile utilise un sous-ensemble du portail patient, optimisé pour l'écran tactile

Un seul point de vérité pour les données. Pas de risque de divergence entre ce que le patient voit sur le web et ce qu'il voit sur le mobile.

Le résultat

Livré et en production :

• 5 applications depuis une seule codebase : 3 portails web + 1 application mobile + 1 bibliothèque partagée
• 36 composants réutilisables partagés entre les trois portails web
• 102 fonctionnalités API consommées par les cinq applications
• 51 pages au total (14 côté patient, 30 côté praticien, 7 côté administrateur)
• 110 composants métier spécifiques aux différents portails, construits sur la bibliothèque partagée
• Déploiement indépendant de chaque application — mettre à jour le portail praticien ne nécessite pas de redéployer le portail patient
• Une seule correction de bug sur un composant partagé se propage à toutes les interfaces

Lire aussi : Construire une marketplace de services de santé de A à Z — l'étude de cas complète de ce projet côté produit et business.

Ce qu'il faut retenir :

• Cinq applications ne signifient pas cinq fois le budget. Une bibliothèque de composants partagée et un cadre technique commun permettent de mutualiser l'effort de développement
• La cohérence visuelle et fonctionnelle n'est pas un luxe — c'est ce qui fait qu'un produit multi-interfaces paraît professionnel plutôt que bricolé
• Séparer les applications tout en partageant le socle permet de livrer vite sans sacrifier la maintenabilité à long terme

Technologies : NestJS, Next.js, React Native, PostgreSQL, Stripe, Google Meet API, Mailjet, Twilio