Que font les Product Builders chez Doctolib, ces “dev’ qui prennent des décisions produit” ?

4 projets en parallèle gérés en autonomie par 4 dev’, appelés “Product Builders”. Voici l’expérimentation radicale, permise grâce à l’IA, menée par l’une des 70 features teams de Doctolib en avril dernier. Une initiative isolée mais dont les résultats concluants vont peut-être l'amener à être déployé à plus grande échelle. Analyse.

⌛ 8 min de lecture en première consultation 🩺

🎫 Les membres Premium du Ticket ont un accès intégral à cet article

 ✉️ Article issu du Ticket n°156

📌 TL;DR - Ce que tu vas apprendre dans cet article sur la notion de Product Builder chez Doctolib :  > L’expérimentation d’une feature team : 4 projets menés en parallèle par 4 dev’ appelés “Product Builder” (en s’aidant de l’IA) > Le terreau fertile des “Tech Holders” chez Doctolib, où les PM n’écrivent pas de ticket > 3 nouveaux leviers organisationnels : le framework OpenSpec, le concept des Buddy et le rituel “Way of Working” > Résultats : Nombre de tickets / dev x6 à complexité équivalente > La distinction clé entre décisions réversibles (prises par les dev) et irréversibles (réservées aux PM)

“J’avais plutôt la vision qu’un product builder était un Product Manager avec un socle de développeur”. Sur Linkedin, les réactions d’étonnement affluent en commentaire de la publication de Julien Bideau, Engineering Manager chez Doctolib. 

En juin dernier, ce dernier a en effet dressé les contours du rôle de Product Builder au sein de la licorne française spécialisée dans la prise de rendez-vous médicaux en ligne. Surprise : il ne s’agit pas de Product Manager mais plutôt d’ingénieur qui, “pour la durée de son projet, assume des décisions réversibles, mène les discussions Design en autonomie, informe au lieu de demander la permission”.

À la tech et au produit, nous voulons finalement tous “builder” le produit, je pense juste que les frontières deviennent plus floues”, explique-t-il.

Ne nous y trompons pas : l’enjeu ici n’est pas de disserter, de manière un peu stérile, sur la définition de Product Builder, une notion en pleine hype, quoiqu’un peu fourre-tout. Laissons cela aux puristes. “Product builder, product engineer, product dev… C'est finalement assez similaire. La clé, je pense, c'est de pousser la tech à faire plus de produit et non l'inverse”, reconnaît Julien.

Autrement dit, cette plongée dans les coulisses de Doctolib permet d’étudier une possible voie de réinvention de la façon dont se construit un produit à l’heure de l’IA. Certes, il ne s’agit que d’une feature team sur les 70 (!) de la boîte et cette nouvelle organisation n’a qu’un recul limité - à peine un semestre.

Malgré tout, les résultats ont été tels que d’autres équipes en interne se questionnent pour répliquer ce mode de fonctionnement. Et, à l’heure où tout le monde tâtonne, une dose d’inspiration basée sur une réalité concrète n’est jamais superflue.

Le terreau fertile des “Tech holders” chez Doctolib

Commençons par rappeler le contexte, qui a en effet son importance. Julien Bideau est Engineering Manager depuis 2 ans chez Doctolib dans une feature team basée à Nantes. 5 devs full stack, une Product Manager et lui.

Leur mission : réécrire la plateforme d’administration des clients, une sorte de CRM interne dont la version existante a été construite il y a 12 ans et qui permet de déployer le logiciel de Doctolib auprès des médecins. Par exemple, en vérifiant leur identité et en s’assurant que les praticiens sur la plateforme aient bien le droit d’exercer.

Un projet qui s’étend sur plusieurs années (600 fonctionnalités à migrer !) et dont les utilisateurs sont principalement internes (commerciaux, chargés de compte, support client, que cela soit en France, en Allemagne ou en Italie), même s’il est prévu de l’ouvrir à des chargés d'acquisition externes.

Info importante : historiquement, Céline Forestier, la Product Manager de l’équipe, n’écrit aucun ticket Jira. Doctolib fonctionne avec un système de “Tech Holder”, une norme de l’entreprise documentée depuis longtemps.

Pour chaque projet, une ou un ingé prend ce rôle tournant, similaire semble-t-il à celui de Directly Responsible Individual (DRI), concept inventé par Apple il y a une quinzaine d’années et aperçu par exemple dernièrement chez la startup Dust. Concrètement, ce “Tech Holder” part de la Discovery du ou de la Product Manager et va en prendre la responsabilité technique jusqu’à la livraison.

C’est presque un rôle de super Product Owner, confie Julien. Cela comprend la rédaction des tickets, la gestion de projet, les arbitrages tech, le reporting d’avancement et évidemment la conception”. 

Une manière de laisser plus d’initiative personnelle aux équipes tech, partie intégrante de la culture chez Doctolib. “Les devs ici ont vraiment cet état d’esprit d’ingénieur au sens large, en pensant d’abord à régler des problèmes pour les utilisateurs avant de se concentrer sur la solution technique et de simplement exécuter une vision produit”.

On insiste sur cet élément de contexte initial car il constitue, on va le voir, un terreau fertile pour l’éclosion de ces “Product Builders”. 

Un nombre de tickets par développeur multiplié par 6 en un trimestre

En début d’année, la direction de Docto décrète que ne plus écrire de code devient le nouveau mode de fonctionnement par défaut. Place à l’IA.

Un message reçu au pied de la lettre par Julien. Habituellement, son équipe traite un gros projet et un projet plus mineur par trimestre (donc géré par 2 “Tech Holders” si tu as bien suivi). Ce qui se traduit parfois par des projets trop gros qui débordent sur le trimestre suivant.

Lors de la rétro d’équipe de fin Q1, il prend une décision radicale : pour Q2, ils vont prendre 4 projets en même temps, soit quasiment un par personne ! Comment ? En déléguant les tâches de “Tech Holder” à des agents IA.

L’idée, c’était d’aller à fond dans l’agentique et prendre des risques, quitte à se planter sur certains projets. Evidemment, c’est une révolution pour tout le monde dans sa façon de travailler”, affirme-t-il.

“Julien est un EM hyper curieux qui nous pousse régulièrement à sortir de notre zone de confort”, sourit Céline, la Product Manager de l’équipe qui reconnaît avoir dit OK “de manière assez naïve sur le moment, sans avoir anticipée toutes les implications engendrées”. On y reviendra.

Cette logique de “parallélisation” permet de découper plus finement les projets, tout en gagnant en productivité. Les 4 projets, pour illustrer concrètement ?

• Créer une vingtaine de nouveaux écrans d’ouverture de la plateforme en fonction des types d’utilisateurs qui doivent y accéder

• Faire en sorte de pouvoir mettre en production une première partie de la nouvelle plateforme, donc en se rapprochant des SRE (Site Reliability Engineering)

• Faciliter la connexion des personnes avec une adresse mail Doctolib

• Et enfin, gérer le consentement des praticiens sur la plateforme (l’équivalent des cookies)

Des vrais sujets utilisateurs donc, et non des questions purement d’infrastructure. “Dans le monde d’avant, sans IA, on aurait probablement fait un projet et demi”, assure Julien.

Résultat du trimestre ? Les 4 projets terminés, une multiplication x6 du nombre de tickets traités par développeur par rapport au Q4 2025, pour une complexité moyenne équivalente, à en croire Julien !

OpenSpec, Buddy et “Way of Working” : les 3 mots clés du nouveau fonctionnement de l’équipe

Creusons encore un peu plus en analysant comment l’équipe a profondément revu ses pratiques. Avant, évidemment, d’aborder les limites et les axes d’amélioration de cette expérimentation appelée à se poursuivre, voire à s’amplifier.

Commençons par les nouvelles façons de travailler en abordant 3 changements clés :

L'exécution avec le framework OpenSpec 

Comme le relatent les ingés Yankı Sesyılmaz et Julien Tanay lors de la conférence Devoxx d’avril dernier, Doctolib a fait le choix d’utiliser le framework OpenSpec pour faire du Spec-Driven Development (SDD), qui brille par sa légèreté et sa personnalisation.

---

Découvre notre autres articles sur Doctolib et le thème des Product Builders :