Search for a command to run...
Voici une rétrospective des premiers mois pendant lesquels nous avons lancé les développements de notre application mobile
Staff Engineer @Primary. Adepte du Domain Driven Design et de l'event driven architecture, j'utilise ces concepts au quotidien afin de maintenir à long terme la qualité des logiciels sur lesquels je travaille.
No comments yet. Be the first to comment.
Retour d'expérience après deux ans passés en production
Retour d'expérience suite à la mise en place de l'IA générative dans le cadre de nos processus internes
ou comment l'IA peut aider les médecins dans la préparation de la consultation médicale.
Pour notre application mobile à destination des patients des cabinets médicaux, nous nous sommes interrogés sur l'usage d'un framework multiplatforme.
Cela fait déjà 8 mois que l'aventure Primary Medical a commencé pour moi et il est temps de faire un premier bilan de cette superbe expérience.
Primary Medical, c'est la rencontre d'un médecin généraliste, Pierre-Henri Gorioux, d'un entrepreneur de la tech, Thibault Lanthier (ex. CEO de Mon Docteur), de Laure Némée (ex. CTO de Leetchi et Mangopay) et d'Alexis Mathieu (ex. CEO de FeetMe).
L'objectif de Primary est très clair : révolutionner le domaine de la médecine générale, en s'attaquant au fonctionnement des cabinets médicaux. Il s'agit de créer des cabinets nouvelle génération, mettant en avant la prévention afin d'apporter des soins de qualité aux patients, tout en permettant aux médecins généralistes de ces cabinets de pratiquer la médecine dans les meilleures conditions.
La première étape de Primary était de développer une application mobile compagnon afin d’apporter plus de transparence et de proximité entre le cabinet et le patient. En plus de pouvoir accéder à ses rendez-vous et ses documents médicaux, le patient a accès à un chat ouvert 6j/7 afin d’échanger facilement avec son équipe médicale et peut accéder au compte-rendu rédigé par son médecin après chaque consultation.
Cela fait quelques heures à peine que je viens d'arriver dans l'équipe Primary Medical et je dois relever mon premier défi : arriver à sortir en 3 mois à peine, non seulement un backend pour le MVP de notre application mobile mais également des intégrations avec les logiciels utilisés dans les cabinets, où sont stockées les données patients.
Il faut que l'app sorte avant la fin du mois d'octobre et le rush de l'hiver dans nos cabinets médicaux.
Créer une application de zéro est un tout autre défi que de créer des fonctionnalités sur une application existante. En plus du scope fonctionnel, il a fallu faire des choix structurants et mettre en place :
l'organisation de l’équipe et la méthodologie de delivery
la stack technique
l'intégration backend/mobile
l’hébergement
la sécurisation de la plateforme
l'observabilité de la plateforme
Autant dire qu'il a fallu faire preuve de pragmatisme dans beaucoup de nos choix : hébergement, services tiers, coûts des solutions, langages utilisés, architectures, ...
Le fait de fonctionner en sprints d'une semaine depuis le début nous a permis de nous imposer des deadlines agressives : nous avons ainsi pu réagir rapidement quand l'attendu n'était pas au rendez-vous. Aujourd'hui, je suis certain que ce mode de fonctionnement a énormément contribué à tenir ce délai de 3 mois.
Notre choix a été guidé par 2 objectifs pas forcément alignés : un enjeu très court terme de mise en production mais un objectif à long terme de scalabilité puisque l'ambition de Primary est d'ouvrir des dizaines de cabinets partout en France.
Le choix du langage Java et de Spring Boot pour supporter l'application a été le choix le plus pragmatique : c'est une stack technique stable et mature, qui nous permet de profiter d'une large communauté existante. Trouver des développeurs séniors maîtrisant ces technologies est un atout qui nous permet d'envisager l'avenir de Primary Medical sereinement.
Etant donné le périmètre fonctionnel très riche à couvrir, nous sommes partis sur un monolithe modulaire, avec pour chacun des sous modules une architecture hexagonale, ce qui permet de nous concentrer sur le métier de l'application, tout en fournissant les moyens nécessaires pour changer facilement les implémentations techniques au besoin. Ce choix là était logique au vu de la taille de l'équipe, ainsi que par rapport à nos ambitions de croissance. En effet, il sera très facile à posteriori d'extraire les sous modules en applications à part entière.
Enfin, pour construire les bases d'un backend maintenable à long terme, et le plus aligné possible avec notre métier, nous avons adopté une event driven architecture : chacun de nos use cases émet des événements métier en sortie. Ainsi, à chaque modification dans le système, d'autres sous modules peuvent s'y abonner de manière très simple. Pour que cela fonctionne, nous attachons une important particulière au nommage de nos domain events afin qu'ils soient les plus alignés avec notre métier. Je reviendrai plus en détail sur cette architecture dans d'autres billets de blog.
Cette partie est celle où il y a le plus de défi : il faut arriver à faire comprendre et utiliser les concepts du Domain-Driven Design à toute l'équipe tech de Primary, sans les assommer avec du jargon inutile. L'objectif est d'arriver à faire en sorte que le code de notre backend soit maintenable à long terme et donc le plus aligné possible avec notre métier.
Difficile d'imaginer, avec une équipe tech très petite au démarrage, de réaliser nous même l'hébergement. Le choix le plus pragmatique est donc de partir sur un hébergement de type SaaS, qui nous rend le maximum de service et nous laisse le maximum de temps pour nous concentrer sur l'essentiel, la construction de notre app.
Le choix de Clever Cloud nous est apparu comme le plus pertinent : c'est un provider français, qui fournit des zones certifiées HDS, c'est à dire des espaces informatiques spécialement conçus pour stocker des données médicales sensibles de manière sécurisée.
Nous sommes à presque 2 mois après le démarrage de l'aventure, mais aucune app mobile n'est encore commencée 🙃 ! En effet, mon collègue Thomas Pucci, développeur mobile, n'intégrera l'équipe qu'au mois d'octobre, c'est à dire le mois de la sortie de l'app. Heureusement, un freelance mobile que nous trouvons début août et qui travaillera avec nous depuis le début du mois de septembre réalisera l'exploit de développer l'ensemble des écrans ainsi que l'intégration avec le backend en l'espace d'à peine plus d'un mois.
Néanmoins, nous nous voyons avec Thomas une fois par semaine pour faire un état des lieux ainsi que pour prendre des décisions sur l'intégration entre le mobile et le backend. C'est à cette période que l'on choisit GraphQL, très utilisé dans la communauté mobile. Le choix de Flutter pour l'application mobile elle-même était un choix réalisé de longue date.
Notre authentification étant une authentification par mobile, le choix le plus évident a été de partir sur Firebase, encore une fois pour des raisons de rapidité d'intégration. Une fois ce choix entériné, il a été très simple de préparer le terrain côté backend grâce à Spring Security, qui gère nativement l'Oauth2.
Dans l'ombre, Thomas travaille déjà sur l'intégration continue mobile et le déploiement de l'app sur les stores iOS et Android. À son arrivée dans l'équipe, il se coordonne avec le développeur freelance pour la continuité de l'app, deux semaines à peine avant son lancement officiel.
Comme je l'écrivais plus haut, notre plateforme backend repose sur une event-driven architecture. Les sous modules métier de notre monolithe modulaire publient des événements dans RabbitMQ. Les processus qui s'abonnent à ces événements peuvent néanmoins générer des erreurs, ce que nous devons gérer.
Il est donc important de pouvoir corriger ces erreurs, et de pouvoir rejouer ces événements qui n'ont pas été consommés correctement.
Nous avons opté pour la mise en place d'une dead letter queue. C'est une stratégie classique employée dans le monde des message oriented middlewares comme RabbitMQ : un événement (message) qui ne peut pas être consommé correctement part alors dans une file spécialisée, nommée dead letter queue, dans le but d'être rejoué plus tard.
Quelques semaines avant la première mise en production, nous nous outillons pour pouvoir visualiser le contenu des événements rejetés, l'exception Java liée à ce rejet, ainsi que pour pouvoir renvoyer ces événements une fois le code corrigé.
Avant de partir en production, il était important que nous puissions observer ce qui se passe sur notre application.
Côté mobile, les analytics d'utilisation de nos écrans sont poussés dans Mixpanel, les erreurs dans Crashlytics.
Côté backend, notre APM Elastic nous permet d'avoir une bonne vision, avec d'une part les API servies au mobile et d'autre part nos event handlers et nos batchs. L'application de gestion de notre dead letter queue permet de compléter nos besoins en observabilité.
Malgré des délais serrés, un scope fonctionnel large et une application mobile qui n’avait pas été commencée à être développée avant début septembre, les choix techniques de l’été ont fini par payer.
Le 26 octobre 2023, toute l'équipe s'est retrouvée dans un de nos cabinets médicaux de Bordeaux pour le lancement officiel de l'application. Elle vient d'être validée par Google et Apple, nous sommes fins prêts !
L'objectif de la journée est d'assister les patients de ce premier cabinet afin de les onboarder dans l'application. Notre product manager participe activement, ainsi que les assistantes médicales, qui informent les patients sur l'app lors de leur arrivée en cabinet.
Nous recueillons le maximum de feedbacks afin de corriger les petits détails, tant visuels dans l'app que dans notre backend.
Cette journée a été un succès, mais surtout c'est l'aboutissement d'un sprint de 3 mois 😮💨
Avec des délais très serrés, nous sommes arrivés à livrer une application de qualité, majoritairement grâce au pragmatisme dont nous avons fait preuve, tant l'équipe tech, que Jean Lebas-Guenoun, notre PM, qui a su choisir les éléments à enlever du périmètre initialement prévu.
Le lancement de l'application en production, très "manuel" car il s'est fait patient par patient en face à face, a connu une courbe de démarrage très lente la première semaine. C'est normal, car aucun des patients n'avait connaissance de son existence tant qu'ils ne venaient pas au cabinet. Il a également fallu du temps aux équipes médicales pour systématiser le passage d'information.
La semaine suivant cette première mise en production, nous avons implémenté le système de notifications (mail, SMS, notifications push) qui nous a permis ensuite de connaître une croissance constante des inscriptions sur l'application. Les inscriptions se font au fil de l'eau, lorsque les patients prennent rendez-vous avec nos médecins.
Aujourd'hui, plus de 4 mois après notre lancement, 12% de notre patientèle a installé l'application et l'a déjà utilisée. Nos statistiques montrent une très bonne adhésion à l'application. La messagerie, notamment, est très utilisée en remplacement du télésecrétariat et permet à nos assistantes médicales de gagner beaucoup de temps.
Côté technique, notre bilan est très encourageant :
Le découpage de notre monolithe en sous modules métier nous a permis, malgré la pression permanente, de maîtriser la complexité grandissante du scope fonctionnel.
Nous avons pu livrer un backend de qualité avec les caractéristiques minimales pour partir sereinement en production.
Nous avons pu sortir l'application mobile à temps malgré un énorme retard au démarrage.
On a hâte d'écrire pour partager la suite des événements. Mais ça, ce sera pour un autre billet 😉.