Building the AI factory: the operating-model shifts behind Doctolib's AI products

Every company is racing to put AI into its products. Far fewer are solving the harder problem underneath: making AI products something every team can build reliably, safely, and at scale. In our case that happens in healthcare, where 90M patients and 500k healthcare professionals depend on what we ship.

As Product Manager of the ML Platform at Doctolib, I spent the last two years on that problem, from the launch of our first AI-native product to the foundations of an "AI factory". This is a field report told from the ML platform's seat, the internal team supporting the feature teams building those AI products. It covers the five operating-model shifts it took, and what we learned from each:

1. From fragmented to unified platforms. Merging Data, ML, and Engineering platforms, and why the org change was harder than the tech.
2. From technical enabler to platform-as-a-product. Treating dozens of internal feature teams as customers, and how prioritization breaks when you go from two customers to many.
3. From production-ready to optimized AI products. Evaluation-driven development (teams now run hundreds of eval experiments a day), a GenAI gateway, and the model strategy: serverless foundation models as v1, post-trained open-source models as v2.
4. From capabilities to accelerators. The abstraction layer that took AI products from several quarters to weeks (three weeks from zero to beta in production, at our last hackathon).
5. From zero to ~100% AI-coding adoption. And how building the platform for agents changed our operating model again.

I'll share real numbers (adoption, velocity, eval volume), the decisions we got wrong, including a painful framework migration caused by not deciding, and the tensions that never go away: golden paths vs. team autonomy, delivery pressure vs. long-horizon platform work.

You'll leave with a concrete map of the operating-model decisions behind scaling AI products that made sense within Doctolib's context, and the order in which to make them when your platform capacity is limited.