Duck Conf 2022 - Compte rendu du talk de Doctolib - "Jusqu'ici tout va bien"

lllustration par Gaëlle Bonenfant – Doctolib

La dernière fois que Doctolib est intervenu à la Duck Conf, c'était en 2019 avec un talk intitulé "L'architecture ennuyante - comment passer à l’échelle avec un monolithe" avec l’intervention de Michel Domenjoud (Staff Engineer) et Nicolas De Nayer (VP of Engineering).

29 Mars 2021 - c'est la 5ème édition de la Duck Conf et nous avons l'honneur d'accueillir une nouvelle fois Doctolib pour cette cérémonie d'ouverture.

David Gageot (Chief Architect) & Nicolas Martignole (Principal Engineer) ont intitulé le talk du jour "Jusqu'ici tout va bien"

A l’épreuve du COVID-19, comment le (gros) système Doctolib a tenu le coup en trafic face à des enjeux sociaux et techniques importants ?

Introduction : culture du pragmatisme

Rappelons les trois missions de Doctolib (2 à valence "sociale" + 1 à valence "tech")

1. Améliorer le quotidien du personnel soignant
2. Rendre l'accès aux soins rapide et égalitaire pour tous les patients
3. Constituer une équipe d'entrepreneurs avec des valeurs humanistes et ayant à cœur d'améliorer le secteur de la santé

Rétrospective

Souvenez-vous du 12 et 13 juillet 2021

(pour plus de détail - cf. le CR détaillé de Nicolas sur le Touilleur Express)

Le 12 juillet, Emmanuel Macron fait une allocution afin de lutter contre le variant Delta. Le pass vaccinal entre en vigueur.

De nombreux français se connectent sur la plateforme Doctolib pour prendre un rdv de vaccination. L’enjeu est de taille pour que le consommateur sur le site reste le moins de temps possible.

Les équipes Tech sont sur le pont et très proches du mur. Elles résistent.

A titre illustratif, il y a 10 Millions de transactions par minute réalisées sur la plateforme à plusieurs reprises.

Selon les chiffres publiés par Doctolib, en deux heures trente, 926 000 rendez-vous ont été pris ce lundi soir 12 juillet, puis 1,4 million sur la journée du mardi. Ceci a notamment été rendu possible grâce à 2 ingénieurs SRE de Doctolib.

1. Architecture : une évolution douce mais rapide

Architecture Doctolib en 2019

Architecture Doctolib en 2022

Comme vous pouvez le constater, l'architecture de Doctolib a suivi une évolution douce (mais rapide). Elle est toujours très pragmatique.

Sa valeur : « simplicité du build, simplicité du run ».

Son leitmotiv : avoir tout en 1 exemplaire.

• 1 unité de déploiement. Pour le site "Patient" mais aussi pour les "Praticiens"
• 1 monolithe pour la France, l'Allemagne et Italie
• 1 runtime simple backend Ruby on Rails, frontend JavaScript/TypeScript
• 1 application mobile
• 1 site web en mode "Web Viewer"
• 1 repository Git pour le cœur du logiciel
• 1 plateforme d'intégration continue avec 40 000 tests
• 1 unité à surveiller et à faire scaler

En résumé :

2 . Tech : simplicité, qualité et performance

Rappelons les grands piliers de la Tech chez Doctolib en 2019 - toujours valables en 2022.

• Autonomie / Équipe :
  • Un développeur chez Doctolib est full stack et développe sa user story de A à Z, de la phase de développement au suivi de la production
  • L’équipe est organisée en feature team sur un scope fonctionnel dédié et sur des utilisateurs finaux ciblés
• Combattre la complexité et optimiser les outils existants : d’abord optimiser l’outil sur le Build & Run, jusqu’à se poser la question d’une nouvelle solution technologique

Tech Radar : “c’est simple mais pas simpliste”

• Boucles de feedback courtes : dans une approche SRE, mettre en production, obtenir le plus rapidement possible des feedbacks rapides et des données, pour ainsi avoir du monitoring (*), de l’alerting, du capacity planning automatisé (sur l’axe des ordonnées le temps de réponse et sur l’axe des abscisses le débit - nombre de requêtes), …

(*) Pour être plus précis, Doctolib utilise New Relic comme APM (Application Performance Monitoring). Il s'agit d'un outil puissant pour aller détecter plus en amont une dégradation de performance et fournir des informations actuelles et historiques pour aller investiguer (performances des requêtes de la base de données, performances de rendu du navigateur web, …).

La finalité c’est que cela permet d’optimiser et d’améliorer la recherche des disponibilités (le cœur du réacteur Doctolib) des personnels de santé sur la plateforme tout en déduisant les slots déjà occupés sur une zone géographique donnée et en fonction du motif de consultation.

Doctolib reçoit chaque jour un rapport automatisé et va vérifier, sur les 7 derniers jours, tous les end points qui ont pris + 10% sur leur temps de réponse pour permettre de remonter ceux dont la performance a été dégradée.

• Plan de capacité - Court terme vs. long terme
  • > 6 mois : tout va bien
  • 3-6 mois : on y pense (“est-ce que j’introduis une nouvelle techno ?” “comment je le fais intelligemment?”)
  • < 3 mois : on prend !

Bien que l’architecture Doctolib soit un monolithe, Doctolib est en capacité d’analyser chaque point d’entrée avec une analyse fine - end point par end point.

Pour y remédier ? Une stack technique simple pour que le développeur soit en capacité d’aller un peu sur le run.

3. Organisation : mindset agile et produit tout en étant le plus factuel possible

En 2022, il y a 500 personnes côté "Produits & Tech" chez Doctolib répartis sur 3 pays - dont 4 villes (Paris, Nantes, Milan, Berlin) et 250 développeurs.

Les équipes sont modulaires et organisées en mode feature team (cf. Team topologies)

• Il y a 8 domaines organisés en stream : 5 produits (Doctolib Patient, Doctolib Practice, Doctolib Team, Patient Healthcare Platform, Sales & Marketing Performance) + 3 supports

  • Les développeurs font régulièrement des “Vie ma vie” pour comprendre les activités de l’un et de l’autre et s’approprier le même vocabulaire
  • Un moment “Tech Time” pour partager des enseignements techniques (réussites et échecs) entre les équipes

• L'organisation est bien rodée : pas de nécessité de coordination très forte

• La règle d’or : c’est être le plus factuel possible et ne négliger en aucun cas la qualité. Il faut bannir des phrases du type : “Et si jamais on doit…”, “Peut-être qu’un jour…”, “C’est plus propre de…”

• Des nouveaux métiers se sont créés :

  • Cybersécurité (crucial)

  • Doctolib est certifié HDS (Hébergeur de Données de Santé)

• Sales / Marketing

• Data Science (*)

  • Le business de Doctolib, c'est l'abonnement que payent les médecins
  • Doctolib n'utilise pas les data des patients

• 1 site de formation interne pour les nouveaux arrivants (Doctolib Academy) - au bout de 4 semaines, les développeurs sont en capacité de faire partir du code en production.

4. Demain : Du monolithe au monolithe modulaire

Quelques chiffres :

• 283 dév sur le GitHub de Doctolib (2022)
• 50 à 100 Pull requests par jour mergés dans la branche principale
• Sur chaque Pull request, 40 000 tests réalisés de bout en bout (tests de navigateurs coûteux et fragiles)
• 12 clusters Kubernetes qui vont faire tourner les tests

Plus de développeurs + plus de tests + plus de produits = les coûts de la CI augmentent de façon exponentielle.

Les challenges sont nombreux :

• Monolithe très gros
• Complexité du code
• Plus de produits
• Volume de code x2
• Charge cognitive forte (les développeurs commencent à se plaindre)

Pour vous donner une idée du cycle de mise en production chez Doctolib, c’est :

• 3 mises en production Doctolib par jour (11h / 14h / 17h)
• 3 pays (France, Italie, Allemagne) / 3 langues = 1 seul déploiement

Doctolib va pousser l'approche "monolithe modulaire" afin de rendre le monolithe plus agréable tout en restant monolithe pour :

• Avoir une meilleure maîtrise de ses impacts
• Simplifier le travail de ses développeurs

A titre illustratif, il y a une crise par jour chez Doctolib. Le processus de gestion de crises est rodé. Si un développeur a un doute ou une peur et souhaite déclencher la sonnette d’alarme, il a juste à appuyer sur un bouton rouge. Automatiquement, un SMS est envoyé à l’équipe Tech. Dans la foulée, les gestionnaires d’incidents se mobilisent et vont organiser une cellule de crise.

L’intention au niveau de l’approche est de garder une seule unité, un seul repository, une seule code base. A l’intérieur de la code base, Doctolib va essayer d’identifier plus clairement différents modules fonctionnels et différentes responsabilités. Par exemple, les développeurs vont utiliser des engines Rails en prenant plusieurs tranches d’applications qu’ils vont mettre en production en commun et ainsi obtenir l'application finale (Doctolib s’inspire du modèle Shopify). Cela permet d’avoir un core applicatif et des modules fonctionnels plus proches du découpage organisationnel.

En gardant le principe d’avoir tout en 1 exemplaire, Doctolib créé du modulaire si et seulement si c’est nécessaire.

Il est primordial d’avoir une simplicité dans le design, de faire des améliorations incrémentales et de mesurer constamment la satisfaction.

En résumé / Takeaway

• Doctolib résiste plutôt bien à la croissance et est résolument déterminé à devenir un leader de la e-santé en Europe. Mardi 15 Mars dernier, Le Monde annonce que Doctolib a fait une opération de financement de 500 millions d’euros. Elle devient désormais la start-up française la mieux valorisée - à hauteur de 5,8 milliards d’euros.
• L’architecture de Doctolib reste un monolithe, mais elle est modulaire. Pour ce faire, elle veille à toujours respecter ses principes avec beaucoup de rigueur - tout en restant ferme sur sa façon d’avancer mais pas sur sa destination.
• Choix techniques pragmatiques, évolution du système complexe pas à pas.
• Fine tuning : Doctolib s’attache toujours à utiliser la solution existante, lire le manuel, et trouver des options - avant de penser à la dernière technologie ou pattern à la mode.
• Il y a aujourd’hui 500 personnes "Tech et Produits" qui travaillent ensemble et ça fonctionne bien.
• Il faut être capable de penser produit/client plutôt que de penser technique/architecture.
• Doctolib va continuer à proposer des innovations utiles et fiables aux personnels de santé et aux patients.