Grandir ne veut pas dire faire la même chose en plus gros. Chez Doctolib, cinq forces ont imposé des changements radicaux : le load, les pays, les builders, les produits et l'IA. Jade Vandal travaille côté patients, sur la recherche de praticiens et les pages profil. Grégoire Cacheux anime l'équipe d'architectes qui pilote la transformation technique et la gouvernance. Ils racontent chaque axe avec des exemples concrets tirés de la code base.
Sommaire9 sections
- 1.De 2013 à 2026, un changement d'échelle
- 2.Le load, scaler sans que les utilisateurs le voient
- 3.Les pays, sortir de la limite des trois
- 4.Les builders, faire grandir l'organisation et la stack ensemble
- 5.Les produits, une roadmap qui n'est pas écrite d'avance
- 6.L'IA, construire le système qui construit le système
- 7.Les valeurs derrière chaque axe
- 8.Les questions de l'audience
- 9.Le replay
1. De 2013 à 2026, un changement d'échelle
En 2013, Doctolib compte 50 professionnels de santé. Le produit couvre déjà deux usages : prendre rendez-vous avec son médecin, ou chercher une offre de soins.
En 2026, 500 000 professionnels de santé sont enregistrés. Cela représente dix mille fois plus qu'au départ.
Les patients avec un dossier chez Doctolib sont 90 millions. L'entreprise opère en France, en Allemagne, en Italie et, dans une certaine mesure, aux Pays-Bas.
Au pic d'un lundi à 11 heures, la plateforme traite 6 000 rendez-vous par minute.
La stack de 2013 était simple : un pays, une base de données, un monolithe, une stack Rails et JavaScript.
"Devenir plus gros, c'est apprendre encore et encore à transformer une chose en plusieurs et sans que ça devienne le chaos."
2. Le load, scaler sans que les utilisateurs le voient
Scale vertical, readers et autoscale
Après le Covid, deux options existaient pour scaler la base de données. La première : des machines plus grosses, un writer plus gros. La seconde : ajouter des readers.
Les readers coûtent cher. Doctolib a donc mis en place de l'autoscale pour les adapter à la charge réelle.
Cette alternance entre vertical et horizontal crée une course en avant. Les patterns de scale infini restent très horizontaux.
"Choisir, c'est renoncer, voilà."
Les limites physiques
Deux limites sont apparues. Trouver des machines plus grosses devient difficile. Garantir les temps de réplication entre writer et reader aussi.
La réponse a été l'urbanisme. Doctolib a isolé des domaines métiers et fait émerger des API internes. L'équipe a isolé des lots de tables et retravaillé les frontières transactionnelles du monolithe.
La donnée a été déplacée des bases principales vers des bases secondaires. Tout cela s'est fait en continuant à livrer des fonctionnalités.
Aujourd'hui, quatre clusters tournent derrière le monolithe principal. Ce levier compense la croissance organique des deux dernières années, mais devient de moins en moins rentable.
La résilience et les fault domains
Les praticiens utilisent Doctolib comme un outil de productivité. Un incident en journée gêne des consultations physiques.
"On ne peut pas tolérer un downtime en plein milieu de la journée."
Une migration de table côté praticiens a déjà bloqué la prise de rendez-vous côté patients. L'inverse est aussi possible.
Doctolib a donc fait émerger des fault domains et isolé physiquement des workloads. Selon Grégoire Cacheux, ces questions se posent pour les monolithes comme pour les microservices.
3. Les pays, sortir de la limite des trois
Chaque pays, un nouveau système de règles
Chaque pays gère sa santé différemment. En Italie, les praticiens ont un panel de patients fixe et une rémunération fixe. En France, ils sont payés à la consultation.
Le Royaume-Uni impose que les données soient collectées et stockées sur son territoire. C'est un défi d'architecture pour une entreprise présente uniquement en Europe.
Pourquoi les if-else ne passent pas à l'échelle
Avec l'Allemagne, le code s'est rempli de conditions : si France, telle logique, sinon autre chose. Avec l'Italie, les switch cases ont pris le relais.
Pour trois pays, la solution fonctionne. Au-delà, elle ne tient plus.
"Au bout des trois, il faut qu'on s'arrête parce qu'un switch de vingt lignes, on n'en veut pas."
La code base contient encore des fichiers de configuration par pays et des règles de calcul spécifiques. Certaines fonctionnalités sont activées dans le else par défaut. Un nouveau pays hériterait donc de ces fonctionnalités sans décision explicite.
Certains fallbacks renvoient vers la France quand le pays n'est pas trouvé. La validation du format de code postal utiliserait alors les règles françaises.
Country Features et Country Config
Doctolib a d'abord recensé toutes ces logiques pour les comprendre et les classifier. L'équipe les a appelées des country logics.
Des règles RuboCop et ESLint tournent en permanence pour les flaguer. Leur rôle principal est d'empêcher l'introduction de nouvelles country logics.
Ces logiques sont réécrites en Country Features et Country Config. Elles suivent les mêmes règles et sont stockées au même endroit.
L'objectif est d'avoir une logique agnostique des pays. Une fonction retourne si la fonctionnalité est activée pour le pays du compte connecté. Ajouter un pays revient à modifier une config, sans toucher au code.
D'autres sujets restent ouverts. Les time zones, d'abord. Les pays à plusieurs langues officielles, comme la Belgique. Puis les devises, les unités, les formats d'adresse et de téléphone.
Les JO 2024 et la séparation pays et langue
Le site était traduit en français, allemand et italien. La langue était déduite du TLD : le pays valait la langue.
Les Jeux Olympiques ont posé une nouvelle question. Comment donner accès aux soins à des patients anglophones venus du monde entier ?
Doctolib a dissocié le pays de la langue dans le code. Toutes les clés de traduction ont été retraduites en anglais par une agence spécialisée. Le travail a duré des mois.
Les motifs de consultation sont des termes médicaux techniques. Certains actes médicaux n'existent pas dans tous les pays.
Un sélecteur de langue a été ajouté. La langue de préférence est enregistrée dans le compte, puis appliquée aux SMS, push et emails.
Le projet a mobilisé une cinquantaine de personnes. Il n'était pas prévu dans la roadmap.
4. Les builders, faire grandir l'organisation et la stack ensemble
feature teams réparties en 10 domaines
Chez Doctolib, les builders désignent les product managers, les designers et les développeurs. Le grain de base reste la feature team : des développeurs, leur engineering manager et leur PM. Les designers sont en time sharing.
En 2013, il y avait trois équipes. En 2026, il y a 80 feature teams réparties en dix domaines orientés personas.
Le monde pro compte 45 équipes. Le monde patient en compte 10. La plateforme technique en compte 17 : SRE, authentification, droits d'accès, rétention de la data.
Les équipes restent full stack. Elles intègrent aussi des spécialistes : front, mobile, data scientists.
Sortir de la monoculture Rails
En 2022 et 2023, une question a émergé. Quelle sera la capacité à recruter des développeurs Rails compétents en 2028 ?
Personne n'avait la réponse. Doctolib l'a traitée comme un risque à probabilité inconnue et à impact massif.
La stratégie technique a changé. Des services back-end sur la JVM et sur Node.js ont été évalués, puis ont reçu du trafic de production. Python est arrivé avec les produits IA.
Le monolithe Rails reste une pièce maîtresse. Aujourd'hui, plus de lignes de code s'ajoutent en dehors du monolithe que dedans.
You build it, you run it
Les équipes applicatives sont autonomes et responsables de leurs services, du déploiement aux opérations.
Les équipes SRE gèrent les parties communes : réseau, clusters Kubernetes, bases de données, broker Kafka, outils de déploiement.
Les châssis
Le terme vient des châssis de voiture. Il désigne un cadre commun co-construit avec les équipes plateforme.
"Chez Docto, on a le droit d'être hyper créatif, mais par contre, la palette de couleurs, elle est fixe."
Le châssis norme l'observabilité : format de log, métriques collectées, nommage. Il norme aussi la communication entre services, jusqu'à la propagation du contexte applicatif.
Toute intégration event-driven passe par des schémas définis et stockés de façon centrale.
Les deployment descriptors, ou DD, standardisent le déploiement des services HTTP, des producteurs et des consommateurs Kafka. Les politiques d'autoscaling sont préconfigurées avec une approche t-shirt sizing.
Des load tests ciblés ajustent ensuite chaque workload. Le volume et la variété des workloads rendent un test de charge exhaustif impossible.
"Chez Docto, on n'a jamais fait et on ne fait toujours pas de la tech pour de la tech."
5. Les produits, une roadmap qui n'est pas écrite d'avance
De la prise de rendez-vous à une suite de logiciels médicaux
En 2013, le produit tenait en une page de prise de rendez-vous et un calendrier praticien. Aujourd'hui, le côté pro inclut la gestion de la patientèle, la facturation et l'assistant de consultation.
Le côté patient évolue vers un compagnon de santé : rappels de santé, carnet de santé, assistant médical.
La téléconsultation et le Covid
Début 2020, la téléconsultation émergeait tout juste. Le produit plafonnait autour de 15 000 téléconsultations.
Avec le Covid, le volume a atteint 600 000 téléconsultations. La roadmap prévue sur plusieurs quarters a été chamboulée en quelques jours.
"Jamais, jamais, jamais, on n'aurait pu anticiper que ce nouveau produit deviendrait absolument vital."
Après le Covid, le volume n'a pas baissé. La téléconsultation est devenue une habitude pour les patients et les praticiens.
L'accessibilité
En 2022, un audit a mesuré la conformité aux standards d'accessibilité. Le résultat était inférieur à 30 %.
Doctolib s'est engagé à respecter WCAG et RGAA. Ces standards s'organisent autour de quatre principes : perceptible, utilisable, compréhensible, robuste.
La formation a porté sur trois volets. L'awareness, d'abord. La pratique des screen readers et du voice control. Puis la production de code conforme.
Plus de sept équipes ont travaillé sur le sujet. Le dernier audit, en mai, dépasse 60 % sur le parcours de prise de rendez-vous côté patients.
L'objectif suivant est d'intégrer ces pratiques plus en amont, dès les phases design et produit.
Les acquisitions
L'Allemagne s'est faite en croissance organique. L'Italie s'est faite par acquisitions. Une application de messagerie vient de l'acquisition d'une entreprise néerlandaise.
6. L'IA, construire le système qui construit le système
Chaque axe multiplie la complexité des autres
Pour Grégoire Cacheux, ces axes ne s'additionnent pas. Ils se multiplient, car chaque axe complique le suivant.
Deux documents guident les itérations. La vision produit projette l'entreprise à deux ans. La stratégie technique définit le terrain de jeu technique qui la soutient.
L'IA change l'équation depuis environ un an.
L'IA pour tous les employés
La question posée chez Doctolib : comment devenir une AI native company quand on est né avant l'IA ?
Doctolib a été early adopter de Dust. Une centaine d'agents sont déployés pour des besoins internes : RH, sales, activités support.
L'usage de l'IA fait désormais partie des évaluations et des critères de recrutement.
Le scribe ambiant dans les produits
L'assistant de consultation est un scribe ambiant. Il capte l'audio d'une consultation et le transcrit avec des modèles de speech-to-text.
Il résume la consultation selon le template défini par le médecin. Il extrait aussi des entités, comme le poids ou la tension.
Ces observations structurées sont suggérées au médecin. C'est lui qui décide de les insérer dans le dossier médical.
L'IA pour les builders
Le premier outil interne était un DoctoGPT self-hosted. Il servait surtout à reformuler des emails.
Le changement a commencé avec l'inline suggestion, puis l'agentic coding. Jade Vandal a utilisé Cursor pour écrire la règle RuboCop qui repère les country logics.
Aujourd'hui, l'adoption de Claude Code approche 100 % chez les product managers et les développeurs. Le nombre de pull requests a augmenté. La code review est devenue un bottleneck.
Des refactorings jugés trop chers avant sont désormais possibles. Les équipes vont plus loin sans solliciter leur PM ou les architectes.
Vers des agents autonomes
Doctolib veut créer les conditions pour que des agents développent des features de façon autonome.
Trois ingrédients sont nécessaires. Des intentions produit claires : tickets Jira, specs. Des agents qui tournent dans des boîtes fermées, un périmètre de sécurité maîtrisé. Le stockage de toutes les interactions pour mesurer leur efficacité.
Le design system est en cours d'adaptation pour être agent-friendly. La documentation est écrite pour les agents, pas seulement pour les humains.
Deux contraintes s'ajoutent : le coût des tokens et la dépendance aux fournisseurs de modèles.
"On va devoir construire un système qui lui-même construira le système utilisé par nos utilisateurs."
7. Les valeurs derrière chaque axe
Chaque axe est associé à une valeur qui ne change pas avec l'échelle.
Le load renvoie au trust : la fiabilité du service et l'absence de downtime.
Les pays renvoient à l'adaptabilité : s'adapter au système de santé de chaque pays.
Les builders renvoient à l'ownership : you build it, you run it.
Les produits renvoient à l'inclusion : l'accès aux soins pour toutes et tous.
8. Les questions de l'audience
Hébergement et données de santé
Doctolib tourne sur AWS, avec deux régions principales : la France et Francfort. Le plan de reprise d'activité bascule la charge d'une région à l'autre.
La migration vers AWS s'est faite une fois AWS certifié HDS. Cette certification est indispensable pour héberger des données de santé.
Qui a porté le passage au multi-base ?
La prise de conscience était partagée, du CEO au CPO et au CTO. La mise en œuvre est partie du CTO et des équipes d'engineering.
Ces chantiers se négocient dans les roadmaps produit. Doctolib combine la transformation technique avec des opportunités produit.
La configuration multi-pays
Il n'existe pas encore de plateforme de paramétrage des pays. C'est l'objectif final. Aujourd'hui, la configuration tient dans des centaines de fichiers.
Pourquoi Kotlin, et pas Scala ni Go
Doctolib est parti sur Java, puis une pression interne a mené à Kotlin. Aujourd'hui, 90 % du code JVM est en Kotlin.
Scala a été écarté pour une raison de recrutement. Les choix JVM et Node visaient un bassin d'emploi large.
Python était non négociable, porté par la data science. Go a été écarté pour garder un nombre de runtimes réduit.
Le critère principal n'était pas technique. Ces technologies sont battle-tested. La question était le type de profils recrutables, et en quelle quantité.
Doctolib cherchait aussi des développeurs expérimentés en systèmes distribués, en asynchronisme et en message bus comme Kafka.
L'avenir du monolithe Rails
Il n'existe aucun plan pour éteindre le monolithe. Doctolib débranche des workflows et déplace de la data, toujours pour une intention produit claire.
"Industriellement, c'est une pure beauté."
Le choix de Claude Code
Au départ, les développeurs avaient le choix entre trois vendeurs, dont Cursor et GitHub Copilot. La condition préalable était contractuelle : aucune rétention de données.
Après quelques mois, les demandes de licences Claude ont dépassé les autres. Claude Code s'est imposé par vote populaire, il y a environ un an.
Une gateway centralise les appels vers les LLM. Elle permet de changer de modèle à la volée.
Le gros de l'investissement porte sur la gestion du contexte : informations, skills et plugins diffusés aux agents. Ce contenu est très spécifique à Doctolib.
Le bottleneck des code reviews
Chaque équipe gère le sujet différemment. Un agent de revue pourrait retirer les typos et les commentaires simples.
Un humain doit encore relire le cœur de la PR. Le temps passe moins dans l'écriture du code et plus dans la relecture et la préparation en amont.
La souveraineté des données
Dans un environnement HDS, toutes les données sont hébergées en Europe.
"Il n'y a aucun développeur qui a accès à la donnée médicale finalement."
Aucun laptop de développeur ne contient de données de patients ou de praticiens. Le risque de fuite via un assistant de code est évité par construction.
Les secrets de build et la propriété intellectuelle restent sous vigilance. Des contrats de non-rétention couvrent les fournisseurs.
Pour l'IA dans les produits, certains modèles sont auto-hébergés en environnement HDS. Avec les fournisseurs externes, les contraintes sont transposées : zéro entraînement, zéro log, processing en Europe.