• Architecture
• Conférence
• Standard
• 55 min

Le parcours de Doctolib vers une plateforme de données médicales séparée du monolithe historique

• Date mercredi
• Horaire 8h00 à 8h55
• Salle Amphi E

Description

MDP (pour Medical Data Platform) est le premier service à avoir été extrait du monolithe historique de Doctolib, marquant ainsi une transition architecturale vers une infrastructure davantage distribuée. Cette conférence détaille notre parcours de migration des données médicales, où la stabilité de l'environnement de production et l’expérience utilisateur ont été des enjeux cruciaux. Cette migration nous a permis d’améliorer l’expérience développeur, de découpler les données fonctionnelles des données médicales et de mettre en place une structure de base de données unifiée pour les données médicales saisies à la fois par les praticiens et les patients. Nous aborderons les choix techniques effectués, les défis organisationnels rencontrés liés à la mise en place de nouveaux processus de déploiement, ainsi que les obstacles rencontrés sur « le terrain ». Cela inclut des incidents en production, des débats sur la façon de valider la qualité des nouveaux services et plus globalement la transition vers la philosophie « You build it, you run it ». La présentation propose un retour honnête sur les succès et les échecs rencontrés lors de cette migration, offrant des enseignements concrets aux équipes envisageant des changements architecturaux similaires.

Orateur·ices

Samuel Lukes

Je suis staff engineer chez Doctolib, avec un parcours entre le Royaume-Uni et la France. J’ai commencé ma carrière en travaillant sur le moteur de recherche des Pages Jaunes britanniques, puis j’ai rejoint la BBC, où j’ai eu l’occasion de contribuer à des projets de streaming vidéo à grande échelle. Depuis mon arrivée chez Doctolib, je me consacre à la transformation numérique de la santé : intégration de données médicales, amélioration des parcours praticiens, et, ces deux dernières années, co-construction de la Medical Data Platform (MDP) d’abord en Rails puis en NodeJS/Nest, pour répondre à des besoins de robustesse et de scalabilité. J’interviens régulièrement en interne pour partager mon expérience lors d’ateliers d’architecture ou de présentations techniques, dans une démarche de transmission et de construction collective de la culture engineering.

Christopher Anciaux

Software engineer depuis environ 7 ans maintenant mais écrivant du (mauvais) code depuis plus de 10 ans, j'ai commencé mon parcours professionnel à Lille à l'ESN Open puis Enedis avant de rejoindre Doctolib en 2020. 👨‍⚕️ J'y ai d'abord travaillé pour améliorer le parcours d'accueil des praticiens, les imports et exports des données médicales. Depuis environ 2 ans, nous avons participé à la construction de MDP avec Sam Lukes, d'abord en créant un engine Rails séparé puis finalement en réécrivant le service en NodeJS avec Nest.

Actions rapides

🎥 Voir la vidéo mettre en favoris Ajouter à Google Calendar Télécharger le fichier ICS

Partager la session

---

Les sessions futures sur le même thème

• • Architecture
  • Conférence

  Rejouer une partie, rejouer le système de la matrice : des replays de jeux vidéo à l’event sourcing

  Dans la plupart des jeux vidéo modernes, un “replay” n’est pas une vidéo mais une simple liste d’événements : les inputs des joueurs, quelques événements système et un état initial minimal. Pour revoir une partie, le moteur ne fait “que” tout rejouer dans l’ordre et reconstruit ainsi l’intégralité de la session. 🎮📜 Côté backend, l’event sourcing applique exactement la même idée : au lieu de stocker uniquement l’état courant, on enregistre la chronologie des décisions métier (events) qui ont mené à cet état. On peut alors “remonter le temps” pour débuguer un bug tordu, auditer un comportement étrange, ou reconstruire un système sur une nouvelle architecture. Dans ce talk, on partira de cas concrets côté jeux (replays, rewind, killcams) pour expliquer pas à pas : - comment fonctionne un système de replay basé sur un log d’événements, - en quoi ce modèle diffère d’une approche CRUD classique, - ce que l’event sourcing reprend de cette idée pour nos SI. Je montrerai un mini-système de replay dans un petit jeu ainsi qu’un exemple d’event store côté backend (Java/TypeScript), sans masquer les limites : coût de relecture, complexité, tooling… 🎯 Public cible : dévs backend / fullstack, architectes, curieux d’architecture qui aiment les métaphores vidéoludiques 💾 Plan proposé 1 - “Un replay, ce n’est pas une vidéo” Comment les jeux enregistrent une partie : log d’événements + état initial. Démo simple : rejouer une partie en réinjectant les inputs dans une boucle de jeu. 2 -De la partie au système : introduction concrète à l’event sourcing Modèle CRUD vs modèle “flux d’événements rejoués”. Notions d’event store, projection/lecture, relecture d’événements. 3 - Cas d’usage réels : debug, audit, résilience Time-travel debugging, audit, reconstruction d’état / migration. 4 - Limites, pièges et conseils pragmatiques Coût de la relecture, snapshots, complexité pour les équipes, tooling et quand ne PAS utiliser l’event sourcing.

  Mercredi 15h00 à 15h55 - Amphi E
• • Architecture
  • Conférence

  Vous pensiez que la dette technique était le pire? Voici la dette de conception !

  Dans nos métiers, la dette technique est sans doute la chose la plus frustrante, éprouvante et coriace contre laquelle nous devons lutter. Bien sûr, il existe des bonnes pratiques : refactoriser, viser la simplicité avec KISS, éviter de trop anticiper avec YAGNI afin de limiter cette dette au maximum. Et pourtant, on n’y vient jamais vraiment à bout. Pire encore, elle continue de s’accumuler même lorsque nous les appliquons, comme une fatalité. Et si ces mêmes bonnes pratiques ne faisaient parfois qu’empirer le problème au lieu de le résoudre ? La dette technique peut n’être que la partie visible de quelque chose de plus profond : la dette de design accidentelle. Un problème bien plus complexe, donnant lieu à des logiciels spaghettis et à des microservices en « monolithe distribué », dont nous sommes souvent à l’origine sans même nous en rendre compte. Dans cette conférence, nous explorerons les mécanismes de la dette de design et ses impacts, conséquents sur notre architecture, nos processus, notre organisation, et même notre business. À travers des exemples concrets, nous verrons comment la détecter, analyser sa profondeur et agir avant qu’elle ne s’ancre durablement.

  Jeudi 8h30 à 9h25 - Amphi A
• • Architecture
  • Conférence

  Cache-moi si tu peux : patterns et pièges du cache en production

  "On va mettre un cache, ça ira plus vite." Cette phrase a déjà coûté des nuits blanches à bien des équipes. Le cache est souvent introduit comme une "optimisation" rapide à mettre en place. En réalité, il transforme profondément le comportement d'un système : cohérence éventuelle, données obsolètes, effets de bord distribués... et bugs impossibles à reproduire. Aujourd'hui, ces mêmes défis réapparaissent dans les architectures intégrant des LLMs, avec l'émergence de modèles comme le *semantic caching*. Partons ensemble pour un voyage pragmatique dans le monde du cache : - ce qu'est réellement un cache (et ce qu'il n'est pas), - les principaux patterns de caching et leurs compromis, - les anti-patterns classiques qui transforment une application rapide en cauchemar opérationnel, - un arbre de décision pour choisir la bonne stratégie. Cette session vous donnera les outils pour construire des systèmes rapides et prévisibles, et vous aidera à ne plus jamais considérer le cache comme un simple détail d'implémentation.

  Jeudi 11h30 à 12h25 - Amphi B