Il y a maintenant plus de deux ans, nous sommes partis en production avec une event-driven architecture que nous avons choisi pour de multiples raisons que j’évoquerai dans cet article. Depuis, nous maintenons au quotidien cette architecture et ses outils. Il est temps de faire un premier bilan sur ses avantages et ses inconvénients.

Qu’est ce qu’une Event-Driven Architecture ?

Une architecture de type event-driven est une architecture dans laquelle un module métier va publier le résultat d’un traitement (par exemple la saisie d’une conclusion dans une consultation par un médecin) sous la forme d’un événement métier. On appelle ce module métier un publisher. Cette publication d’événement se fait au travers d’un message broker (RabbitMQ dans notre cas) dans une file d’attente.

Chaque file d’attente peut être écoutée par de multiples consommateurs. On les appelle subscribers ou event handlers. A chaque fois qu’un événement arrive dans la file d’attente, chaque event handler qui s’est abonné à l’événement est notifié et son code est appelé pour consommer l’événement.

Cela garantit un découplage parfait des responsabilités. Les modules ne se connaissent pas à l’avance et n’interagissent qu’au travers de ces événements.

Cela ouvre énormément le champ des possibles en termes d’architecture : on pourrait imaginer faire du monolithe modulaire (spoiler alert : c’est ce qu’on fait chez Primary) ou encore éclater nos modules en microservices si on en avait le besoin.

Quels sont les avantages de cette architecture ?

Notre démarche a été, dès le premier jour, de choisir une architecture event-driven. Ce choix a été fait pour de multiples raisons :

• Maintien de la simplicité des modules métier et découplage (le code de notre backend est un monolithe modulaire, autrement appelé modulith)

• Orientation métier des événements en accord avec notre démarche de conception orientée métier (Domain-Driven Design). Nous avons fait le choix d’utiliser des événements métier tels que “ConsultationTerminee” ou “BilanDePreventionValide” plutôt que des événements techniques comme par exemple “ConsultationAjoutee” ou “ConsultationModifiee”.

• Evolutivité : cela est bien plus pérenne de créer de nouveaux event handlers pour implémenter de nouvelles fonctionnalités que d’ajouter celles-ci dans du code existant.

• Scalabilité : c’est très facile pour nous d’ajouter de nouvelles instances de notre backend (scaling en un clic sur Clever Cloud) afin de répondre à des pics de charge.

• Disponibilité : le backend reste disponible même si un event handler est défaillant; de plus, il est possible de re-publier des événements après un incident. C’est le sujet dont je parle le plus dans mon lunch talk car je trouve que c’est un des plus gros avantages 🙂

Les challenges rencontrés par l’équipe

La gestion des erreurs

Je trouve que la gestion des erreurs est un des meilleurs arguments de vente de cette architecture : cela nous donne la capacité de récupérer d’une erreur après un incident. Cela rend tout simplement notre système résilient.

Pourtant, cette capacité à réessayer après une erreur a été un de nos plus gros défis.

Dans mon talk, je prends l’exemple d’une notification push que l’on envoie à nos patients sur leur app Primary lorsqu’ils prennent rendez-vous dans un de nos cabinets.

Le problème se pose si l’event handler devient défaillant : que doit-on faire ? On ne doit pas perdre le contexte d’exécution car le patient ne recevrait jamais sa notification push.

Dans ce style d’architecture, on utilise un mécanisme de files d’attente qui permettent d’isoler les événements en erreur afin de pouvoir les retraiter plus tard. Cela s’appelle des Dead Letter Queues.

Concrètement, si l’event handler fait son travail correctement, il informe le message broker de la consommation de l’événement et il peut passer à l’événement suivant dans la file d’attente. Mais s’il y a une erreur, l’événement ayant donné lieu à l’erreur sera alors re-routé vers une Dead Letter Queue afin d’être isolé pour être retraité plus tard.

Chez Primary, lorsqu’un événement part en Dead Letter Queue, on en profite pour ajouter des méta-données dans les entêtes de l’événement :

• Stacktrace et message de l’exception

• File d’attente d’origine du message (pour nous, un event handler = une file d’attente, un événement = un exchange dans RabbitMQ)

• Date à laquelle l’événement a été “refusé” pour la première fois

• Nombre de retries

• Date d’un rendez-vous rattaché potentiel, nom du cabinet de rattachement, identifiant du profil de patient concerné

• ID de la trace de notre APM

Cela nous permet de gagner énormément en observabilité.

Une fois l’incident sur l’event handler terminé, on peut alors ré-injecter l’événement dans le système dans sa file d’attente d’origine. Cette opération pourra être répétée autant de fois que nécessaire, jusqu’à ce que la consommation de l’événement par l’event handler puisse se faire 🙂.

Le traitement des erreurs en production

RabbitMQ, notre message broker, dispose de ce mécanisme de Dead Letter Queue de base, et c’est un bonheur pour garder la maîtrise des erreurs en production.
Néanmoins, la console d’administration de RabbitMQ est assez austère et ne permet pas de gérer ces files d’attente de messages en erreur.

En 2023, dans les tous premiers mois de la construction de notre backend, je prends alors le temps de faire une étude afin de savoir s’il existe des produits sur étagère qui permettent de gérer ces Dead Letter Queues comme on le souhaite. Malheureusement, cela n’existe pas, alors je décide de réaliser une webapp qui permet :

• de lister les messages qui sont en Dead Letter Queue

• de renvoyer tous les messages vers leurs files d’attente d’origine

Ce projet a été réalisé au départ en moins d’une semaine avec le minimum d’investissement, ce qui veut dire qu’il n’était pas au point lors de la première mise en production, pour de multiples raisons :

• Evénements mélangés et en grand nombre

• Evénements en doublons

• Impossibilité de renvoyer des événements de manière unitaire

• Impossibilité de supprimer un événement de la Dead Letter Queue

Pendant quelques mois, nos difficultés principales pour le traitement des erreurs en production ont été ces limitations qui nous ont fait passer beaucoup trop de temps en analyse des problèmes.

Itérer et améliorer notre “Dead Letter UI”

“Dead Letter UI”, c’est le nom que l’on donne en interne à ce projet qui nous permet de superviser la Dead Letter Queue en production (mais aussi sur notre environnement de staging).

Forts d’un atelier Kaïzen qui nous a permis de lister clairement toutes nos difficultés rencontrées, nous avons amorcé un chantier d’amélioration de cette application :

• Ajout de la possibilité de visualiser les événements en erreur par event handler

• Ajout de la possibilité de renvoyer ou supprimer un événement unitairement ou par event handler

• Ajout d’un lien vers la trace de l’exécution du code dans notre APM

• Ajout de données de production lors de la mise en Dead Letter Queue qui nous permet de savoir si un événement est lié à un rendez-vous et/ou à un patient ainsi qu’à un cabinet. En bonus, on recrée les liens vers le logiciel médecin et le logiciel qu’utilisent les équipes soignantes

Toutes ces améliorations nous ont permis de sortir la tête de l’eau. Nous avons enfin pu réagir rapidement et de manière éclairée lorsque nous avions des problèmes.

Aujourd’hui, un événement en Dead Letter Queue nous occupe en moyenne une minute. Dans ce temps, nous sommes capables de décider :

• Si c’est un événement qui a expiré (et on le supprime)

• Si c’est un problème connu (donc pas besoin d’analyse complémentaire)

• Si c’est un nouveau problème

En tout cas, nous avons une politique de traitement systématique de ces cas et lorsque notre alerting nous avertit d’une erreur, nous intervenons très rapidement pour retrouver un compteur à zéro.

Le rejeu des événements

Le rejeu systématique des événements est tentant avec un outil tel que celui que nous avons développé; néanmoins, ce n’est pas une option, car les événements que nous produisons peuvent se retrouver obsolètes très vite.

A titre d’exemple, nous envoyons une notification push sur le téléphone du patient lorsqu’il arrive au cabinet. Si une erreur se produit lors de son temps d’attente, nous ne prenons jamais le risque de rejouer ce type d’événement, car cela pourrait produire des side effects au mauvais moment (si le patient est déjà dans le box du médecin par exemple).

Par design, nous avons prévu tous nos event handlers pour qu’ils soient idempotents. De cette façon, nous savons que nous pouvons rejouer un événement si son cadre temporel est correct. L’heure du rendez-vous associé à l’événement présenté par la Dead Letter UI nous permet de prendre la décision en quelques secondes seulement.

Le rejeu des événements n’est donc clairement pas un sujet simple; nous avons choisi pour l’instant de traiter des événements rejetés manuellement; nous pourrions néanmoins automatiser ces traitements, que ce soit :

• par une expiration technique au niveau du message broker

• par une expiration calculée par nos event handlers

Nous avons pour l’instant fait le choix pragmatique de les traiter manuellement, compte tenu de notre faible volumétrie d’erreurs. Notre stratégie pourra changer bien entendu lorsque la volumétrie de la production évoluera.

Bilan et challenges à venir

Sur les deux dernières années en production, cela fait un peu plus d’une année que notre stack événementielle est suffisante pour nous permettre de gérer la production de manière sereine. Bien entendu, il reste encore des choses à améliorer :

• fiabiliser l’envoi des événements dans le message broker. RabbitMQ ne nous a jamais fait défaut en production, mais il serait fâcheux de perdre des événements

• augmenter l’observabilité pour pouvoir reconstituer des parcours fonctionnels à partir d’événements (ceux-ci sont isolés pour l’instant)

• documenter nos événements pour les futurs développeurs et développeuses qui vont nous rejoindre

• absorber la croissance de traffic lorsque nous allons ouvrir de nouveaux cabinets (nous allons doubler le nombre de cabinets en 2026, et ce n’est qu’un début)

Il y a encore énormément de sujets que j’aimerais développer à propos de l’architecture de notre backend. C’est pourquoi il se pourrait bien que vous me revoyiez en 2026 pour parler de ce sujet, plus en détail cette fois 😉.

Le sujet est sur toutes les lèvres depuis plus d'un an : comment pourrait-on profiter de l'énorme potentiel des intelligences artificielles génératives (basées sur les Large Language Models) afin de faire gagner du temps et donc de l'argent à notre entreprise ?

Chez Primary, nous n'avons pas choisi de baser notre modèle économique sur l'IA. Néanmoins, nous avons choisi de l'utiliser comme un booster, afin de faire gagner du temps à nos soignants, en remplacement de tâches chronophages qu'ils ou elles réalisaient systématiquement.

Genèse de l'IA générative chez Primary : automatiser la préparation d'une consultation

C'est lors d'une phase de discovery produit, alors que nous avions à réaliser un questionnaire dans le cadre d'une fonctionnalité de préparation de consultation par le patient depuis son app mobile, que nous avons envisagé pour la première fois d’utiliser l’IA générative.

Nous avions alors deux choix possibles :

• Réaliser une fonctionnalité de questionnaire “statique” (le patient choisit le motif principal, puis répond à des questions sur ses symptômes). Cela personnalise peu l’expérience utilisateur.

• Réaliser une fonctionnalité avec un assistant IA qui interagit avec le patient. Cela personnalise beaucoup plus l’expérience l’utilisateur.

Bien entendu, nous avons choisi la deuxième solution, car cela a permis au patient d'avoir le même ressenti que si une vraie personne lui posait les questions. Mais surtout, la synthèse issue de cet échange, générée par une IA, a une vraie plus value pour nous, car elle permet au médecin de mieux anticiper la consultation.

Voici un exemple d’échange :

Cette fonctionnalité est aujourd'hui très utilisée : elle permet aux patients de saisir de manière détaillée la raison de leur venue, même dans le cas de multi-motifs. Si l'assistante reçoit en préconsultation le patient, elle voit la synthèse générée à partir du questionnaire auquel a répondu le patient, et si le médecin reçoit le patient directement, cette synthèse est disponible dans le logiciel médecin.

Améliorer le quotidien des assistantes médicales avec l'IA

Forts de notre première expérience en prompt engineering, nous avons réfléchi à améliorer le processus des pré-consultations, réalisé par les assistantes médicales.

Voici d'abord un peu de contexte : lorsqu'elles ne sont pas surchargées par l'accueil, les tâches administratives ou encore le secrétariat, les assistantes médicales ont pour mission de réaliser une pré-consultation afin de préparer le terrain pour le médecin et lui faire gagner du temps lors de la consultation. Prise de constantes, interrogatoire de pré-anamnèse (interrogatoire médical) et actes techniques peuvent alors être effectués.

Nous souhaitions développer une fonctionnalité de saisie des pré-consultations réservée aux assistantes, mais nous ne savions pas comment faire pour réaliser une fonctionnalité qui pourrait être une vraie aide à la pré-anamnèse pour elles. L'option de réaliser le même questionnaire que dans l'application mobile pour le patient a été écartée dès le départ, car elle enlevait toute spontanéité. De plus, certaines assistantes étaient à l'aise pour réaliser cette tâche, d'autres moins. Comment faire alors pour aider nos assistantes à réaliser ces pré-anamnèses ?

C'est après de multiples itérations et ateliers que l'équipe est arrivée à une solution satisfaisante :

• L'assistante saisit sa pré-anamnèse dans un champ de texte à partir de sa discussion avec le patient

• L'IA générative lui suggère des questions à poser au patient selon ce qu'elle a déjà saisi (symptômes, ...)

• L'IA générative lui suggère des examens techniques à réaliser en fonction de l'état de santé du patient et de ses symptômes (test covid si le patient a de la fièvre et une rhinite par exemple)

• L'IA générative permet finalement de mettre en forme la pré-anamnèse afin d'obtenir un format de synthèse homogène pour les médecins (synthèse poussée ensuite dans le logiciel médecin).

Nous avons été agréablement surpris de l'engouement suscité par cette fonctionnalité de saisie de pré-anamnèse. Les assistantes médicales ont été ravies de trouver un allié d'aide à la saisie et à la mise en forme. Cela leur permet de gagner un temps fou et donc de dégager du temps pour d'autres tâches.

Fluidifier la communication entre le patient et le personnel soignant grâce à l'IA

Depuis fin 2023, le secrétariat téléphonique a été coupé et remplacé par la messagerie. Les patients peuvent initier une demande depuis la messagerie dans leur application mobile, et recevoir une réponse avec une moyenne de 30 minutes.

Les assistantes médicales et les médecins peuvent également contacter les patients via cette messagerie.

La messagerie repose aujourd’hui activement sur l’IA, et les assistantes médicales et les médecins s’appuient dessus :

• Pour assigner automatiquement un titre à la conversation avec le patient

• Pour corriger les fautes d’orthographe et reformuler une idée, via notre fonctionnalité de “Mise en forme”

Ce sont des tâches pour lesquelles les IA génératives sont faites, et qui enlèvent un poids des épaules de nos équipes, qui investissent alors mieux leur temps pour du soin de qualité.

Conclusion

L'implémentation de l'IA générative chez Primary représente une avancée significative dans l'amélioration de nos processus internes et l'optimisation du temps de travail des équipes médicales.

Bien entendu, chez Primary nous sommes très concernés par la sécurité des données de nos patients, et aucune donnée utilisée par nos fonctionnalités d’IA ne permet d’identifier nos patients.

En automatisant des tâches répétitives ou chronophages, telles que la préparation des consultations et la gestion de la communication via la messagerie, nous avons non seulement amélioré l'efficacité des soignants, mais aussi enrichi l'expérience des patients.

Cette démarche nous permet de nous concentrer sur l'essentiel : offrir des soins de qualité. L'IA ne remplace pas l'humain, elle l'accompagne, et chez Primary, nous sommes convaincus que son potentiel continuera de transformer nos pratiques pour le mieux.

Notre équipe a débuté la conception d'un outil de préparation de consultation, permettant d'obtenir un maximum d'informations sur l'état de santé du patient avant qu'il n'arrive au cabinet, et de restituer ces informations de manière claire et concise à notre équipe médicale.

C'est là qu'un Large Language Model (LLM) peut apporter de la valeur !

Nous avons décidé de nous servir d'un LLM afin de simplifier la génération d'un questionnaire de préparation à la consultation (appelé dans notre jargon pré-anamnèse), et ne pas tomber dans un arbre décisionnel très complexe, peu flexible et difficilement maintenable.

Nous avons tellement aimé les tests que nous avons fait avant de passer à l'implémentation, que nous nous sommes dit qu'il était dommage de ne pas les partager. Nous allons construire ensemble un chatbot médical :)

A vos claviers

Bien entendu, nous avons évalué différentes technologies, ce petit test porte sur l'API de l'assistant OpenAI, car elle permet une prise en mains assez simple du LLM. L'assistant OpenAI garde en mémoire les échanges sur un fil de conversation. Cette fonctionnalité peut être intéressante dans notre cas, car elle nous évite de fournir l'ensemble de l'historique de la conversation à chaque interaction.

Pré-requis à suivre : ici

• avoir python installé

• un environnement virtuel python (optionnel)

• avoir une clef valide d'API OpenAI

• installer la librairie openai

Première étape, initialiser notre modèle, dans notre fichier test assistant-test.py

from openai import OpenAI

client = OpenAI()

def create_assistant():
    assistant = client.beta.assistants.create(
        name="Mon Assistant de Test",
        instructions='Tu es un médecin généraliste.Tu demandes au patient quels sont ses symptômes et s\'il va bien. '
                     'Pose une seule question à la fois et au maximum 5 questions dans la conversation'
                     'Quand tu as terminé, écris "fin"',
        model="gpt-3.5-turbo"
    )
    return assistant


assistant = create_assistant()
print(assistant)

Bravo, vous avez initialisé votre assistant, si vous regardez bien vos logs lorsque vous lancez ce bout de code, vous verrez qu'OpenAI a conservé vos instructions, et généré un assistant avec un id. Nous allons donc nous en servir afin de discuter avec lui.

---------------
LOGS
Assistant(id='votre_id_d_assistant', created_at=1719583152, description=None, file_ids=[], instructions='Tu es un médecin généraliste.Tu demandes au patient quels sont ses symptômes et s\'il va bien.Quand tu as terminé, écris "fin"', metadata={}, model='gpt-3.5-turbo', name='Mon Assistant de Test', object='assistant', tools=[], top_p=1.0, temperature=1.0, response_format='auto')

Dans un fichier bot.py, nous allons initialiser un thread de conversation grâce à la méthode create_thread, puis associer notre fil à notre assistant.

from openai import OpenAI

client = OpenAI()

assistant_id = "votre_id_d_assistant"

def create_thread():
    return client.beta.threads.create()

Ensuite, nous allons mettre en place la logique permettant de poser une question et de lire le dernier message envoyé par l'assistant. Le principe est simple, comme dans une discussion, vous aurez le rôle "user", et l'assistant le rôle..."assistant".

def answer_to_a_question(thread_id):
    # méthode permettant de lire les réponses d'open ai
    question = read_last_message(thread_id)
    # vous allez discuter directement avec le bot
    response = input(question)
    # méthode permettant d'envoyer les réponses à open ai
    answer(response, thread_id)
    # méthode permettant de lancer l'assistant
    run_assistant(thread_id)

def answer(response, thread_id):
    client.beta.threads.messages.create(
        thread_id=thread_id,
        role="user",
        content=response
    )

# nous accédons au dernier message produit par le LLM 
# via la liste de messages du thread
def read_last_message(thread_id):
    messages = client.beta.threads.messages.list(
        thread_id=thread_id
    )
    return messages.data[0].content[0].text.value

Enfin, il faut implémenter la logique permettant de récupérer les questions de l'assistant de manière asynchrone (il faut pull les questions de l'assistant jusqu'à ce qu'elles soient présentes), mais aussi associer le thread que nous avons précédemment créé afin de lancer la conversation.

def retrieve_run_status(run_id, thread_id):
    run = client.beta.threads.runs.retrieve(
        thread_id=thread_id,
        run_id=run_id
    )
    return run.status

def run_assistant(thread_id):
    run = client.beta.threads.runs.create(
        thread_id=thread_id,
        assistant_id=assistant_id,
    )
    status = retrieve_run_status(run.id, thread_id)
    while status != "completed":
        status = retrieve_run_status(run.id, thread_id)
    return run

Lancez votre chatbot à l'aide du code ci-dessous et fournissez lui des réponses plausibles.

thread = create_thread()
run_assistant(thread.id)
tours = 0
while tours < 5:
    answer_to_a_question(thread.id)
    tours += 1

--------
Bonjour, comment je peux vous aider aujourd'hui ? Quels sont vos symptômes et comment vous sentez-vous ? 
j'ai mal à la gorge

Est-ce que vous avez également de la fièvre ?
oui

Avez-vous aussi des difficultés à avaler ?
oui comme lorsqu'on a une angine

Avez-vous des ganglions enflés au niveau du cou ? 
non

D'accord, je vous recommande de prendre un antalgique pour soulager la douleur et de boire beaucoup d'eau. Si les symptômes persistent, je vous conseille de consulter un médecin. Prenez soin de vous et reposez-vous. Si vous avez d'autres préoccupations, n'hésitez pas à me le faire savoir. Bon rétablissement ! 

Fin

Ici, nous avons sciemment bloqué le nombre de questions à 5 car le LLM n'est pas parfait :

• les questions ne sont pas idempotentes pour un ensemble de réponses donné

• même si les instructions indiquent un nombre maximal de 5 questions, le LLM peut aller plus loin, il faut le bloquer programmatiquement

• la qualité du chatbot dépend quasi-exclusivement de la qualité du prompt, il faut donc l'améliorer en réalisant plusieurs itérations, et en ajoutant des instructions. C'est un métier, cela s'appelle le prompt engineering.

• les réponses du chatbot peuvent parfois être surprenantes : il faut envisager un monitoring du bot pour s'assurer de sa qualité, notamment lors d'une montée de version.

Nous espérons que ce petit exercice de découverte du Large Language Model vous aura donné envie de creuser le sujet :-)

Révolutionner la médecine générale

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.

Un défi d'ampleur

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, ...

Des sprints d'une semaine

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.

Choix de la stack technique et de l'architecture de la plateforme

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.

Hébergement de la plateforme

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.

Intégration backend/mobile et choix techniques

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.

Sécurisation de la plateforme

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é.

Observabilité de la plateforme

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é.

Lancement de l'application en production

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 😮‍💨

Bilan

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 😉.

Nous vous exposons dans cet article les critères qui ont guidés notre choix.

Une forte attention au coût d'intégration UI

Nos écrans sont les mêmes sous Android et iOS. De très rares éléments UI sont spécifiques à un OS (par exemple certaines icônes), mais c'est anecdotique. Ce critère favorise clairement React Native et Flutter.

Un coût d'intégration des fonctionnalités natives quasi-nul

Parmi les API de géolocalisation, de bluetooth, de wifi, d'accéléromètre, nous comptons en utiliser… aucune 😅 Encore un critère qui favorise React Native et Flutter, et un peu KMM.

Seule l'API d'accéléromètre est utilisée pour une fonctionnalité cachée : l'affichage de menus cachés sur notre app de Staging.

À ce stade, pour notre business case, il nous reste à trancher entre React Native et Flutter.

Le coût de montée en compétence

Sur les quatre membres de notre équipe tech, un seul possède une expérience mobile (et ce membre n'a pas d'expérience professionnelle en Flutter). Il nous apparaît important que le framework que nous choisirons permette une montée en compétence rapide.

Quels sont les éléments d'un framework permettant une bonne montée en compétence ?

• La grammaire, la lisibilité et la verbosité du langage.

• La sécurité du langage (= la facilité de se rendre compte de l'introduction d'un bug)

• L'activité de la communauté.

• La qualité des devtools.

Si sur le premier point, Javascript et Dart sont à peu près au même niveau - et encore c'est un critère dont l'évaluation est très subjective - les trois derniers points sont plus faciles à trancher.

En effet, l'analyzer et le linter Dart sont indéniablement plus puissants que les linters et les LSP Typescript.

Ensuite, comme relevé par Marek Kalnik de BAM dans son introduction de la React Native / Flutter Connection 2023, l'intérêt pour Flutter n'a cessé d'augmenter en France depuis 2017, jusqu'à dépasser React Native au printemps 2020 👇

Enfin, le support intégré des DevTools Flutter via ses intégrations VSCode et Android Studio (ou plus globalement IntelliJ) nous apporte un confort supérieur aux outils de React Native comme Flipper. D'autant plus depuis la version 3.16 de Flutter qui apporte la capacité d'étendre les DevTools.

Rétrospective

Notre app a 6 mois aujourd'hui ! C'est un beau bébé. Il se porte à merveille.

Une qualité qui nous est apparue et qui pourtant n'était pas dans nos critères initiaux est la facilité d'opérer une stratégie monorepo tant les actions de refactos sont complètes, faciles, sécurisantes et rapides.

Nous en parlerons dans un prochain billet de blog 😃

A bientôt !