Build / Buy / Bake
Construire, acheter ou adapter ? Le framework de décision pour arbitrer chaque capacité produit sans gaspiller budget ni énergie.
Description
Le framework Build / Buy / Bake est un outil de décision qui structure l'arbitrage entre trois options pour développer une capacité produit ou technique : la construire en interne (Build), acheter une solution du marché (Buy), ou adopter et personnaliser une base open source ou un standard existant (Bake). Sa finalité : sortir du débat instinctif "on fait tout maison" pour poser un choix explicite, tracé et défendable. Sans cadre partagé, la décision build vs buy se prend au feeling, sous influence du dernier avis entendu ou du budget du moment. L'équipe tech pousse à construire pour maîtriser la stack, le CPO veut acheter pour accélérer, et l'option Bake, adopter une fondation open source et la "cuire à sa sauce", reste invisible faute d'être nommée. Geoffrey Moore a posé le principe fondateur dans Core vs Context : seules les capacités qui constituent un avantage concurrentiel direct justifient un investissement Build. Tout le reste peut et doit être acheté ou adapté. Comme un chef qui ne fabrique pas lui-même sa farine quand son avantage est dans la recette, l'équipe produit doit concentrer son énergie là où elle crée de la valeur irremplaçable. Le coût total de possession (TCO) sur 3 à 5 ans, la vitesse de livraison, le niveau de différenciation et la capacité de maintenance interne sont les quatre leviers qui font basculer la décision. ThoughtWorks a formalisé ce type de cadre dans ses pratiques de conseil : les équipes qui l'appliquent systématiquement réduisent la dette décisionnelle et concentrent leurs ressources sur leur coeur de métier.
Objectifs
- Identifier les problèmes
- Prioriser le travail
- Structurer le développement
- Assurer l'alignement stratégique
- Assurer l'alignement stratégique
Utilisé par
- -Amazon (choix Build documentés sur les capacités coeur comme le moteur de recommandation, Buy sur les services périphériques)
- -Netflix (Build sur l'algorithme de recommandation et le player, Bake sur l'infrastructure avec des fondations open source comme Cassandra et Kafka)
- -Spotify (décisions explicites Build vs Buy sur la data et la monétisation publiquement documentées dans leurs engineering blogs)
Avantages
- **Décisions traçables et défendables.** Chaque choix repose sur des critères explicites : plus de "on a toujours fait comme ça" face au board ou aux investisseurs.
- **Focus sur le coeur de métier.** En identifiant systématiquement ce qui différencie vraiment, les équipes arrêtent de dépenser de l'énergie ingénieur sur des commodités.
- **Réduction de la dette décisionnelle.** Les choix build vs buy pris au fil de l'eau sans cadre s'accumulent en incohérences architecturales coûteuses. Ce framework impose une logique commune.
- **L'option Bake comme accélérateur sous-estimé.** Adopter et personnaliser une fondation open source mature réduit de 40 à 60 % le time to market sur les capacités non différenciantes, sans dépendance vendor.
Limites
- **Requiert une analyse TCO honnête.** Si les équipes sous-estiment le coût de maintenance d'un Build pour défendre leur option favorite, le cadre produit de mauvaises décisions. La qualité de l'input détermine la qualité de l'output.
- **Difficile à appliquer sous pression temporelle.** En mode urgence ou pivot rapide, ce framework ralentit. Réservez-le aux décisions structurantes avec un horizon de 12 mois minimum.
- **Biaisé par la culture de l'équipe.** Une équipe engineering forte aura tendance à surévaluer le Build. Un CPO orienté SaaS surpondèrera le Buy. Introduire un tiers externe pour challenger le scoring sur les décisions critiques.
- **L'option Bake exige une expertise open source réelle.** "Bake" n'est pas gratuit : personnaliser Keycloak ou monter un cluster Kubernetes demande des compétences spécifiques. Surestimer cette capacité interne transforme un Bake en Build déguisé.
Comment appliquer Build / Buy / Bake
- 1
Nommer précisément la capacité à décider
Décrivez la capacité en une phrase : "authentification utilisateur", "moteur de recommandation", "pipeline de données". Plus la définition est floue, plus la décision sera contestée. Output : 1 énoncé de capacité validé par l'équipe.
- 2
Évaluer le caractère différenciant (Core vs Context)
Posez la question : si un concurrent achetait exactement la même solution, perdriez-vous un avantage compétitif ? Si non, la capacité est contextuelle. Seules les capacités coeur de métier justifient un Build systématique. Output : classification Core ou Context.
- 3
Calculer le TCO sur 3 à 5 ans pour chaque option
Estimez les coûts initiaux, la maintenance, les intégrations, les montées en version et le coût d'opportunité (temps ingénieur mobilisé). Un Build sous-estimé à 6 mois peut peser 3 ans de charges cachées. Output : tableau TCO comparatif à 3 colonnes (Build / Buy / Bake).
- 4
Recenser les options Buy disponibles
Identifiez 2 à 4 solutions SaaS ou éditeurs qui couvrent le besoin. Évaluez : couverture fonctionnelle, dépendance vendor (lock-in), intégration API, roadmap publique. Output : shortlist Buy avec scoring.
- 5
Recenser les options Bake disponibles
Identifiez les fondations open source, standards communautaires ou plateformes configurables qui couvrent 60 à 80 % du besoin. Évaluez la maturité, la communauté et l'effort de personnalisation. Exemples : PostgreSQL, Kubernetes, Keycloak. Output : shortlist Bake avec effort estimé.
- 6
Scorer les trois options sur 4 critères
Notez Build, Buy et Bake sur : différenciation concurrentielle (1-5), time to market (1-5), TCO à 3 ans (1-5, inversé), capacité de maintenance interne (1-5). Pondérez selon le contexte de l'entreprise. Output : matrice de scoring à 3 lignes, décision orientée.
- 7
Valider avec les parties prenantes techniques et métier
Présentez la matrice au CTO, au CPO et aux équipes impactées. L'objectif n'est pas le consensus, c'est la transparence des hypothèses. Documentez les désaccords et les conditions de révision. Output : décision formalisée avec hypothèses et conditions de revue.
- 8
Planifier la mise en oeuvre et les sorties de contrat
Pour un Buy ou un Bake, anticipez les clauses de sortie, les exports de données et les scénarios de migration. Pour un Build, définissez les jalons de validation avant de scaler l'investissement. Output : plan de transition avec jalons et conditions de réversibilité.