Chez Doctolib, le Product Builder n'est pas un PM qui code. C'est un développeur qui pilote un projet et prend les décisions réversibles. Il s'engage aussi sur un objectif d'impact, pas seulement sur une date de livraison. Le cadre tient en trois leviers : un buddy, une journée de scoping et un agent de code.
Sommaire12 sections
- 1.Qui sont Céline Forestier et Julien Bideau ?
- 2.Qu'est-ce qu'un Product Builder chez Doctolib ?
- 3.Pourquoi ce rôle est-il apparu au deuxième trimestre ?
- 4.Quels rituels garder quand on ne fait plus de sprint ?
- 5.Que se passe-t-il quand on lance tous les projets en parallèle ?
- 6.Comment déléguer l'ambiguïté aux développeurs ?
- 7.Pourquoi un buddy plutôt qu'un développeur seul ?
- 8.Comment une journée de scoping remplace deux semaines de tech scoping ?
- 9.Comment fonctionne l'agent Autopilot de Doctolib ?
- 10.Comment Doctolib recrute-t-il ces profils ?
- 11.Par où commencer dans votre équipe ?
- 12.Recruter des profils produit et tech qui ont ce réflexe
1. Qui sont Céline Forestier et Julien Bideau ?
Céline Forestier est Product Manager chez Doctolib depuis quatre ans. Elle cumule une quinzaine d'années d'expérience produit.
Julien Bideau a un background tech. Il est Engineering Manager depuis quatre ans, dont deux chez Doctolib.
Ils forment le binôme PM et EM de l'équipe Pika. L'équipe compte cinq développeurs et aucun Product Owner. Doctolib fonctionne avec environ 70 feature teams, chacune menée par un PM et un EM.
2. Qu'est-ce qu'un Product Builder chez Doctolib ?
Le terme recouvre des réalités très différentes selon les entreprises. Ailleurs, c'est souvent un PM qui se met à coder. Chez Doctolib, c'est l'inverse : un développeur qui prend une casquette produit.
"C'est un concept qui est assez hétérogène, finalement."
Le Product Builder porte trois casquettes. Il est d'abord développeur, et supervise désormais des agents. Il est ensuite tech holder, un rôle historique chez Doctolib. Il fait le tech scoping, soulève les dépendances et écrit les tickets. Ce rôle de Product Owner tourne d'un projet à l'autre.
La troisième casquette est nouvelle : l'ownership produit. Le développeur prend ses propres décisions à son échelle. Il mène aussi les itérations après la livraison.
Voici qui fait quoi dans l'équipe :
| Rôle | Ce qu'il porte |
|---|---|
| Product Manager | Discovery, préparation des prochains sujets, priorités de la roadmap avec l'EM |
| Engineering Manager | Cadre, coaching en one-on-one, suivi de projet, priorités avec la PM |
| Product Builder | Pilotage du projet, tech scoping, tickets, décisions réversibles, itérations après livraison |
| Buddy | Reviews du projet, relais en cas d'absence du Product Builder |
| Reste de l'équipe | 20 à 30 % du contexte du projet, sans relire forcément le code |
Rôle
Product Manager
Ce qu'il porte
Discovery, préparation des prochains sujets, priorités de la roadmap avec l'EM
Rôle
Engineering Manager
Ce qu'il porte
Cadre, coaching en one-on-one, suivi de projet, priorités avec la PM
Rôle
Product Builder
Ce qu'il porte
Pilotage du projet, tech scoping, tickets, décisions réversibles, itérations après livraison
Rôle
Buddy
Ce qu'il porte
Reviews du projet, relais en cas d'absence du Product Builder
Rôle
Reste de l'équipe
Ce qu'il porte
20 à 30 % du contexte du projet, sans relire forcément le code
3. Pourquoi ce rôle est-il apparu au deuxième trimestre ?
Au premier trimestre, les développeurs ont été augmentés par Claude et par des agents. Les tickets se traitaient beaucoup plus vite. Mais les projets ne s'enchaînaient pas plus vite.
Fin mars, le CTO a fait du deuxième trimestre un trimestre d'expérimentation. La consigne : repenser la façon de construire le produit, prendre des risques, avec le droit à l'erreur. L'équipe l'a pris au pied de la lettre.
Plusieurs prérequis ont facilité la bascule. L'équipe travaillait déjà en kanban, sans sprint. Chaque ticket devait tenir en deux jours maximum. Ce découpage fin réduisait l'ambiguïté. Il augmentait aussi le taux de réussite au premier essai des agents.
Chaque Product Builder s'engage enfin sur un objectif d'impact personnel. Par exemple, un taux d'adoption d'une nouvelle fonctionnalité. La question n'est plus "le projet s'est-il bien passé ?". Elle devient "ce qu'on a livré répond-il au problème ?". En échange, le Product Builder est libre sur le comment, y compris sur ses outils.
4. Quels rituels garder quand on ne fait plus de sprint ?
Pas de sprint ne veut pas dire pas de rituels. L'équipe en garde quatre, chacun avec un rôle précis :
Le daily, chaque matin : revue des tickets et priorité du jour de chacun.
Le weekly ways of working : astuces sur Claude, blocages, tests à lancer ensemble.
Le "two and two" : PM, EM et leurs deux managers, pour arbitrer et débloquer vite.
La revue de roadmap toutes les deux semaines, avec les développeurs, pour répartir les sujets.
Côté management, Julien Bideau insiste sur la sécurité psychologique. Le message aux développeurs : tester, se planter, en tirer des enseignements. La casquette produit ne doit pas devenir une charge de travail en plus.
5. Que se passe-t-il quand on lance tous les projets en parallèle ?
Historiquement, l'équipe menait un gros projet par trimestre, plus un projet secondaire. Ces blocs de trois mois coûtaient cher à préparer. Au deuxième trimestre, l'équipe avait quatre sujets plutôt isolés. Avec cinq développeurs, elle a donné un développeur par projet. Trois projets ont démarré en même temps, en avril.
L'objectif était de compresser le temps calendaire et de voir où le goulot se déplaçait. Ça a accéléré, puis ça a coincé à trois endroits :
La PM : quatre projets à suivre, beaucoup de context switching, des questions ouvertes en cascade.
Le développeur seul : en review, les autres ne savaient pas pourquoi tel choix avait été fait.
Le tech scoping : il prenait toujours deux à trois semaines avant le kick-off.
Chaque blocage a donné une nouvelle pratique, détaillée dans les sections suivantes.
6. Comment déléguer l'ambiguïté aux développeurs ?
Quand une question surgissait en plein développement, elle remontait tout de suite à la PM. Avec plusieurs projets en parallèle, ces questions s'accumulaient.
"L'ambiguïté, c'est un peu... ce truc flottant qui génère pas mal d'appréhension, je trouve."
L'équipe a délégué une partie de ces décisions aux développeurs, avec une règle simple. Si la décision est réversible, le Product Builder tranche. Sinon, l'équipe attend et décide ensemble. La phase d'itération après la livraison est aussi un terrain idéal. Le développeur connaît alors le sujet mieux que personne.
Concrètement, une décision réversible prend trois formes. Revert d'un commit si le choix ne tient pas. Test A/B entre deux wordings. Feature flag qu'on désactive si besoin. Les développeurs lisent aussi les données d'usage dans Amplitude pour décider des itérations suivantes.
La règle de fond : décider, puis informer, plutôt qu'attendre le retour de vacances d'un manager. En deux trimestres, l'équipe compte deux reverts.
7. Pourquoi un buddy plutôt qu'un développeur seul ?
En rétro, les développeurs ont remonté un malaise : un projet par personne, c'est se retrouver seul. En juin, deux Product Builders ont commencé à s'assigner leurs reviews nominativement. Doctolib suit les métriques DORA, dont le temps de review. Sur ces deux projets, il a nettement baissé.
L'équipe a généralisé le binôme. Le Product Builder a 100 % du contexte. Le buddy fait les reviews et peut prendre le relais en cas d'absence. Les autres développeurs n'ont que 20 à 30 % du contexte, et c'est assumé.
Entre les trimestres, les paires et les périmètres tournent. Ça limite le silotage. Ça évite aussi qu'en août, une fonctionnalité ne soit connue que de deux personnes.
8. Comment une journée de scoping remplace deux semaines de tech scoping ?
Avant, la PM rédigeait spécifications, user stories et maquettes. Le tech holder partait ensuite deux à trois semaines en tech scoping, seul. À la fin, il publiait un long document que l'équipe relisait presque ligne par ligne.
La journée de scoping réunit le Product Builder, son buddy, l'EM et la PM. Un utilisateur référent les rejoint sur un temps donné quand c'est possible. Elle se déroule en trois temps :
Le matin, la PM présente le besoin : utilisateurs, usages, problèmes, pistes éventuelles. L'équipe s'approprie le problème et soulève les questions.
Pendant le déjeuner, Claude digère le transcript de la matinée. Il produit un document avec le contexte, les user stories et les questions ouvertes.
L'après-midi, l'équipe ferme les questions ouvertes, avec l'aide de l'utilisateur référent.
En fin de journée, l'équipe tient une solution fonctionnelle et technique. Sur un projet de taille moyenne, Claude a presque découpé les tickets. Tout le monde a le même niveau de contexte. La roadmap gagne aussi en souplesse : si un projet bloque, un autre sujet préparé peut démarrer.
9. Comment fonctionne l'agent Autopilot de Doctolib ?
Au départ, l'équipe a placé Claude dans une GitHub Action. Il avait accès au code et à Jira. Il pouvait donc récupérer les tickets portant un label donné et proposer des pull requests. L'outil a depuis été généralisé chez Doctolib.
L'équipe Pika l'utilise via un canal Slack dédié, où chacun exprime une intention produit. Claude qualifie la demande : réponse à une question, ou création d'un ticket Jira. Le ticket contient le contexte, le repo cible et des critères d'acceptance. L'agent ouvre ensuite la pull request, lance la CI et corrige les tests. Il demande les reviews nécessaires et répond aux commentaires. Il joint même une capture d'écran de la fonctionnalité.
Un second agent relit le travail du premier, avec un autre harness et un autre contexte. Il est souvent plus exigeant. Le développeur intervient ensuite, par exemple pour demander un test aux limites. Il ne lit pas le code ligne par ligne. Il s'appuie sur des preuves : tests exécutés en CI, tests end-to-end, régression visuelle.
En octobre, plus de 50 % des tickets de l'équipe passent par l'agent. Depuis l'arrivée d'Opus 5, l'agent réussit plus souvent du premier coup. L'équipe lui confie désormais des user stories entières, plus seulement des tâches. Il sait les découper et poser les dépendances dans Jira. Le rôle du développeur : superviser, réorienter et développer le harness.
La PM s'en sert aussi, avec une règle simple.
"Si ça me prend autant de temps de briefer un dev, je l'envoie dans Autopilot direct."
10. Comment Doctolib recrute-t-il ces profils ?
"On n'a pas de fiche de poste Product Builder. On recrute toujours des PM, évidemment, et des software engineers."
Doctolib recrute historiquement des généralistes plutôt que des profils uniquement front ou back. Les entretiens sont comportementaux : le candidat donne des exemples concrets. Quatre compétences sont évaluées : proximité utilisateur, état d'esprit produit, compréhension du business et impact. Un développeur ne doit pas se poser en exécutant de la vision produit.
"Quand est-ce que tu as proposé une fonctionnalité qui a eu de l'impact pour un utilisateur et comment est-ce que tu as mesuré cet impact ?"
Plus le projet est gros, plus il est confié à un profil senior. Le temps gagné sur l'implémentation est réinvesti en réflexion d'équipe. Des développeurs d'abord dubitatifs se sont mis à creuser les données d'usage dans Amplitude.
11. Par où commencer dans votre équipe ?
Découper les tickets pour qu'aucun ne dépasse deux jours de travail.
Écrire la règle de décision : réversible, le dev tranche ; irréversible, l'équipe décide.
Rendre chaque décision réversible quand c'est possible : feature flag, test A/B, revert.
Fixer à chaque porteur de projet un objectif d'impact, pas seulement une date.
Associer chaque porteur de projet à un buddy chargé des reviews.
Faire tourner les paires et les périmètres à chaque trimestre.
Tester une journée de scoping sur un projet de taille moyenne.
Mesurer le temps de review avant et après.
Ouvrir un weekly dédié aux façons de travailler avec l'IA.
12. Recruter des profils produit et tech qui ont ce réflexe
Ce modèle repose sur des développeurs à fibre produit et des PM capables de lâcher une partie des décisions. Ces profils sont rares et se recrutent rarement via les jobboards. TPC accompagne les startups et scale-ups sur ces recrutements produit, tech et design. Découvrir l'accompagnement TPC.
Pour aller plus loin, lisez notre guide sur le rôle de Product Builder. Les rémunérations sont détaillées dans notre grille de salaire Product Builder.
Côté Doctolib, revoyez aussi le replay sur les cinq axes qui ont fait scaler la tech.
Questions fréquentes
Qu'est-ce qu'un Product Builder chez Doctolib ?
Un développeur qui pilote un projet de bout en bout. Il fait le tech scoping, prend les décisions réversibles et mène les itérations après la livraison. Il s'engage sur un objectif d'impact.
Le Product Builder remplace-t-il le Product Manager ?
Non. La PM garde la discovery, la préparation des prochains sujets et les priorités de roadmap. Elle délègue une partie des décisions fonctionnelles réversibles au développeur.
Quelles décisions un développeur peut-il prendre seul ?
Les décisions réversibles : celles qu'on peut annuler par un revert, un test A/B ou un feature flag. Les décisions irréversibles restent prises en équipe.
Qu'est-ce qu'une journée de scoping ?
Une journée où la PM, l'EM, le Product Builder et son buddy cadrent un projet ensemble. Claude synthétise le transcript du matin, l'après-midi sert à fermer les questions ouvertes. Elle remplace deux à trois semaines de tech scoping.
Quelle part des tickets passe par l'agent Autopilot ?
En octobre, plus de 50 % des tickets de l'équipe Pika passent par l'agent. Il va de l'intention exprimée dans Slack jusqu'à la pull request.
Et le design dans cette organisation ?
L'équipe sert des utilisateurs internes et s'appuie sur le design system. Les designers se concentrent sur les parcours médecins et patients. L'équipe envisage d'inviter un designer ou un UX writer à la journée de scoping.