Doctolib accélère la productivité des développeurs grâce à Claude Code

Adapter la revue de code au rythme de production du code

Doctolib a d'abord adopté Claude Code pour décharger ses ingénieurs des tâches répétitives. La documentation, les tests, l'examen des pull requests et la dette technique détournaient sans cesse les développeurs des problèmes les plus importants pour une plateforme de santé. « Les ingénieurs passaient un temps précieux sur des tâches répétitives au lieu de relever les défis complexes du secteur de la santé », explique Jean-Claude Kuo, Staff Product Manager chez Doctolib.

Ce déploiement a porté ses fruits, mais il a déplacé le goulot d'étranglement. Une fois l'écriture du code accélérée, la partie difficile est devenue tout ce qui l'entoure : examiner chaque modification avec le soin qu'exigent les logiciels de santé, vérifier les risques en matière de confidentialité et de sécurité, et s'assurer de son bon fonctionnement une fois déployée. Ces contrôles protègent 580 000 professionnels de santé et leurs patients ; il n'a donc jamais été question de bâcler le travail. Effectuer manuellement chaque vérification à chaque modification n’était pas non plus réaliste. « Notre objectif est de mettre en place des vérifications exhaustives que les humains ne peuvent pas effectuer de manière systématique en raison des contraintes de temps », explique Nicolas Klarman, ingénieur principal chez Doctolib.

Opus 5.5 pour les tâches où la qualité n'est pas négociable

Les fondations étaient déjà en place. Après un projet pilote avec 30 ingénieurs, Doctolib a déployé Claude Code auprès de l'ensemble de son équipe de développement, et les ingénieurs s'auto-intègrent en moins de cinq minutes depuis VS Code, JetBrains ou la ligne de commande. L'équipe plateforme gère un référentiel partagé de prompts, de commandes personnalisées et de sous-agents que chaque ingénieur récupère lors de sa configuration. Aujourd'hui, environ 90 % des quelque 900 collaborateurs tech et produit de Doctolib utilisent Claude quotidiennement, et Claude Code reste l'outil IA le plus utilisé au sein de l'ingénierie de Doctolib.

L'équipe réexamine sa configuration par défaut à mesure que de nouveaux modèles arrivent. « Le mode plan d'Opus offre actuellement la meilleure configuration possible entre la qualité des résultats et l'optimisation des coûts », souligne Klarman.

La décision la plus importante concernait les agents de codage à distance de Doctolib, qui prennent en charge les revues de pull requests, l'analyse des risques, les contrôles de sécurité, les vérifications post-fusion et l'implémentation. « Pour ces tâches, la qualité du résultat final n'est pas négociable », déclare Kuo. « Nous voulons faire en sorte que les agents distants deviennent la nouvelle référence par défaut pour la livraison. »

Pour choisir le modèle qui les alimente, l'équipe a effectué des tests A/B sur un ensemble de tâches réelles. Opus 5.5 a produit des résultats nettement meilleurs que Sonnet 5.0, le modèle utilisé par défaut jusqu’ici par les agents, pour un coût par pull request 2,5 fois inférieur. Doctolib a fait d'Opus 5.5 le modèle par défaut de ses agents distants et privilégie désormais ce modèle pour les tâches à fort impact.

Des agents qui mènent un ticket de la première modification jusqu'à la vérification en production

Les agents distants propres à Doctolib s’exécutent sur Claude Code en mode headless via GitHub Actions, et fonctionnent comme un système interconnecté plutôt que comme un ensemble de bots dédiés à une seule tâche. À partir d’un seul ticket, ils génèrent une modification de code avec le contexte approprié, mettent à jour la pull request, traitent les retours laissés dans les commentaires de revue et effectuent une vérification complète une fois le code en production. Leur champ d'action couvre la revue de code, l'évaluation des risques, la documentation et la résolution des bugs. Ils représentent désormais 10 % de l'ensemble des pull requests chez Doctolib, et pour chaque bug identifié, un agent propose un correctif. La moitié de ces correctifs sont acceptés et fusionnés par l'équipe responsable du produit concerné.

La révision change elle aussi de forme. Au lieu d'un seul agent de revue, Doctolib met en place un cadre d'évaluation des risques multi-agents, avec des agents couvrant la confidentialité, la sécurité et d'autres dimensions critiques, afin de déterminer le niveau d'attention que requiert chaque modification. « Cette approche nous permet de recueillir des preuves concrètes de ce qui fonctionne en pratique, tout en renforçant progressivement la sécurité et la fiabilité de l'ensemble de notre système », explique Klarman.

Les agents s'appuient sur des flux de travail en place depuis plus d'un an. Une tâche planifiée met à jour la documentation technique à chaque modification du code, et des revues automatisées par Claude s’exécutent sur le principal dépôt d’infrastructure de Doctolib. Dès le début, l'équipe a utilisé Claude Code pour remplacer l'ensemble de son infrastructure de tests de régression visuelle existante. « Nous avons effectué la migration en quelques heures au lieu de plusieurs semaines », explique Klarman.

Les équipes étendent également la livraison aux personnes extérieures à l'ingénierie. Comme une pull request n'a plus besoin d'appartenir à la personne qui écrit le code, les chefs de produit et les designers peuvent livrer des modifications simplement en exprimant clairement ce qu'ils veulent. L'agent décompose le travail et ajuste les exigences pour les adapter à la base de code, aux bonnes pratiques et aux garde-fous. Il ouvre la pull request, la tient à jour et intègre les retours des relecteurs humains et des agents de revue. Une fois la modification approuvée, l'agent la fusionne et exécute des vérifications pour confirmer le résultat.