Medicalib
Medicalib est une plateforme SaaS et mobile dédiée aux professionnels de santé travaillant à domicile. Son objectif ? Faciliter la mise en relation entre les patients et les soignants, tout en gérant l’ensemble des tournées médicales de manière efficace.
Contexte & projet
Les patients peuvent créer une demande de soins via une interface dédiée, puis un algorithme se charge de sélectionner les professionnels de santé disponibles, qui reçoivent alors la demande par SMS. De cette façon, chacun peut optimiser ses tournées et ses déplacements.
À mon arrivée, il y avait deux grandes missions :
- Éliminer le legacy PHP Laravel pour passer à une infrastructure serverless AWS et un fonctionnement piloté par les événements (event-driven).
- Transformer le pricing model pour s’adapter aux besoins de l’entreprise et des utilisateurs finaux.
Le principal défi résidait dans la modernisation complète de la plateforme sans interrompre le service et sans pertes de demandes de soins.
Technologies
Voici les outils et services clés utilisés :
| Category | Tech/Services |
|---|---|
| Langages |  |
| Runtime & Infra |    |
| Databases |   |
| Front & Mobile |   |
| Payment & Billing |  |
| Infra as Code & CI/CD |   |
Challenges
-
Pas de downtime
La plateforme ne devait jamais être interrompue, sous peine de perdre définitivement des demandes de soins. -
Refonte complète du legacy
La transition de PHP Laravel vers une approche serverless s’est faite sans arrêt de service et sans régression fonctionnelle. -
Calendrier et gestion de tournées
Mise en place d’un système de calendrier pour permettre aux professionnels de santé de gérer leurs tournées.Un défi complexe, souvent sous-estimé, car la notion de calendrier doit prendre en compte de nombreux cas d’utilisation.
Réussites
-
CI/CD zéro interruption
Infrastructure automatisée via Terraform et déploiements orchestrés via GitLab pour assurer zéro downtime. -
Remplacement du legacy
Tout le code hérité a été totalement retiré et remplacé par une architecture serverless AWS sans pertes ni régressions, validant la robustesse du nouveau système.
Échecs
- Calendrier peu intuitif
Malgré des avertissements répétés sur la complexité, la nouvelle interface de gestion de tournées est demeurée trop éloignée des standards (comme Google ou Apple). Les utilisateurs ont eu du mal à s’y retrouver.
Leçons
-
Refactoring & Legacy
“Tuer” un code existant prend du temps. Avant de supprimer un module, il faut avoir entièrement recréé toutes les briques fonctionnelles nécessaires. -
Complexité du calendrier
La conception d’un système de calendrier n’est jamais simple. Il demande une énorme réflexion produit et UX, car sa moindre faille compromet lourdement l’adoption de la solution. -
Microservice from scratch
Créer un service à partir de zéro est souvent plus facile et plus rapide que de mettre à jour un système déjà en place. Mais cela nécessite de la rigueur pour éviter la fragmentation et maintenir la cohérence globale.
En définitive, cette expérience m’a permis de conforter mes connaissances en architectures serverless et en migrations sans interruption de service. J’ai également touché du doigt l’importance d’une vision produit claire pour éviter de se lancer dans des projets too big (comme un calendrier) sans y être pleinement préparé.
Merci pour votre lecture !