Custom Software · Analyse approfondie
Sur mesure ou plateforme : la grille de décision build-vs-buy
Quand développer un logiciel sur mesure et quand acheter une plateforme : une grille de décision fondée sur l'adéquation au processus, le coût total de possession, le lock-in, la propriété de la donnée et le time-to-value.
ARCHITECTURE · BUILD-VS-BUY
Entrée · Capacités à activer
Sortie · Construire / Acheter / Composer
Cœur vs commodité (carte de valeur)
Décompose le système en ses capacités et place chacune sur l'axe core/commodité : sépare ce qui vous différencie sur le marché — et mérite du code en propre — de ce qui est devenu commodité et s'achète simplement au fournisseur le moins cher.
Adéquation au processus
Mesure à quel point votre flux est propriétaire : un processus générique avec des standards d'industrie établis pousse vers la plateforme, tandis qu'un flux qui fait partie de votre avantage pousse vers le sur-mesure, car ici les contournements imposés par une plateforme coûtent plus que du code dédié.
TCO sur 5 ans
Calcule le coût à cinq ans incluant maintenance, intégration et formation — pas seulement la licence ou le devis initial — car l'essentiel du coût d'un logiciel arrive après la mise en production, et c'est ce qui fait basculer le verdict.
Lock-in & droits de sortie
Pèse le coût de sortie avant d'entrer : contrats, portabilité de la donnée et intégrations câblées en dur déterminent si vous aurez du levier au renouvellement ou si vous vous retrouverez sans, face à un fournisseur qui le sait.
Propriété des données
Vérifie que la donnée qui vous distingue reste la vôtre, exportable dans des standards ouverts et indépendante du fournisseur : un seul élément non exportable peut faire basculer la décision, car un actif transformé en otage pèse plus que n'importe quelle économie de prix de catalogue.
Time-to-value
Met en balance l'urgence de la valeur et la durabilité de l'avantage : une solution éprouvée déjà disponible vous met en mouvement tout de suite, tandis qu'un différenciateur structurel justifie une implémentation plus longue et soutenue.
Les signes que votre ligne build-vs-buy a été tracée au mauvais endroit
La question n'est jamais « sur mesure ou plateforme ». Elle est : quelle capacité mérite du code en propre, et laquelle est une commodité à acheter. Ces symptômes signifient que la ligne a été tracée au mauvais endroit.
- Vous personnalisez une plateforme standard jusqu'à ce qu'elle ne se ressemble plus : chaque version de l'éditeur casse votre configuration, et le « prêt à l'emploi » est devenu un projet de développement permanent.
- Vous avez construit une commodité de zéro — authentification, paiements, notifications — en dépensant de la capacité d'ingénierie sur des problèmes déjà résolus par le marché, au lieu de votre avantage concurrentiel.
- La donnée qui vous distingue vit chez un fournisseur dans un format propriétaire sans export vers des standards ouverts : ce n'est plus un actif, c'est un otage.
- Personne n'a jamais calculé le chiffre à cinq ans : la décision a été prise sur un prix de licence ou un devis de développement, en ignorant la maintenance, l'intégration et la formation qui dominent le cycle de vie.
- Changer de fournisseur est impensable : contrats pluriannuels, données non portables et intégrations câblées en dur ont porté le coût de sortie à un niveau qui vous prive de tout levier au renouvellement.
Pour les CTO, COO et directions des opérations qui doivent décider où investir la capacité d'ingénierie et où s'appuyer sur le marché, avec des critères qui tiennent devant le conseil.
Achetez la commodité, construisez ce qui vous distingue
La règle d'exploitation la plus durable n'est pas financière, elle est stratégique : placer chaque capacité sur la carte de la valeur et décider selon sa position, non selon les préférences de celui qui écrit le code. Une discipline formalisée par le Wardley Mapping.
Core vs commodité, pas le goût personnel
Une capacité qui vous différencie sur le marché et évolue vite mérite du code en propre. Une capacité devenue commodité — la même pour vous et vos concurrents — est un centre de coûts : on l'achète au fournisseur le moins cher et on passe à autre chose. Construire une commodité, c'est brûler de la capacité d'ingénierie sur un problème résolu.
L'adéquation au processus est le vrai clivage
Si votre flux est générique et que l'industrie a des standards établis, une plateforme l'emporte par la vitesse. Si le flux est propriétaire et fait partie de votre avantage, la plateforme impose des contournements qui, additionnés, coûtent plus que du code dédié. Une plateforme vous plie à son modèle ; le sur-mesure plie le logiciel au vôtre.
Configurer n'est pas gratuit
Entre acheter et construire se trouve une troisième voie — configurer et intégrer — mais elle n'est pas neutre. Faire entrer une plateforme complexe dans un flux spécifique, avec migration des données et formation, comporte un coût réel avant même la première transaction. Le piège est la sur-personnalisation : partez de la configuration recommandée et itérez sur les données d'usage, ne réécrivez pas tout dès le premier jour.
Compose : le meilleur des deux, avec discipline
L'approche mature est hybride : des capacités du marché pour les fonctions standard, connectées via des API documentées, et la capacité d'ingénierie interne concentrée sur ce qui vous distingue vraiment. C'est la logique composable (microservices, API-first, cloud-native, headless) : des composants remplaçables qui changent sans faire s'effondrer tout ce qui leur est relié.
La décision doit être structurelle, pas émotionnelle
Cartographier les capacités rend le choix lisible : on voit où chaque composant se situe sur l'axe genèse-commodité, ce dont il dépend et vers où pousse l'évolution. La ligne build-vs-buy cesse d'être une préférence de service et devient une décision d'architecture défendable.
Comment nous traçons la ligne, capacité par capacité
Nous ne décidons pas « sur mesure ou plateforme » pour tout le système. Nous décomposons le système en capacités et faisons passer chacune par les mêmes gates. Le résultat est une carte, pas une opinion.
Nous décomposons le système en ses capacités et plaçons chacune sur l'axe core/commodité : ce qui vous différencie, ce qui est devenu standard. Cela sépare ce qui mérite du code en propre de ce que vous achetez simplement.
Pour chaque capacité, nous testons à quel point votre flux est propriétaire. 60-70 % standard avec des exceptions gérables : configurer. Flux qui fait partie de l'avantage : construire. Flux générique : acheter.
Nous calculons le coût à cinq ans incluant maintenance, intégration et formation — pas seulement la licence ou le devis initial. En parallèle, nous mesurons le coût de sortie : portabilité de la donnée, droits d'export, dépendance aux intégrations.
Chaque capacité reçoit un verdict — build, buy ou compose — et sa place dans l'architecture. Les commodités passent derrière des API documentées ; le différenciateur devient du code en propre, avec la donnée sous votre contrôle.
De la carte des capacités à une grille de décision défendable en quelques semaines, pas en un trimestre d'études.
Build, Buy ou Compose : les gates de décision
Chaque capacité passe par cinq leviers. Ce n'est pas un total de points : un seul levier peut faire basculer la décision (une donnée propriétaire non exportable pèse plus que n'importe quelle économie de prix de catalogue).
| Levier de décision | Pousse vers BUY / plateforme | Pousse vers BUILD / sur mesure |
|---|---|---|
| Position sur la carte | Capacité commodité, identique aux concurrents | Capacité core qui vous différencie et évolue vite |
| Adéquation au processus | Flux générique, standards d'industrie établis | Flux propriétaire ; la plateforme impose des contournements coûteux |
| TCO à 5 ans | Maintenance et risque portés par le fournisseur | Volume et durée d'usage amortissent le coût de développement |
| Lock-in & sortie | Export vers des standards ouverts, sortie par commodité, intégrations par API | La donnée critique doit rester en propre, indépendante du fournisseur |
| Time-to-value | Valeur nécessaire tout de suite ; solution éprouvée déjà disponible | L'avantage justifie une implémentation plus longue et soutenue |
Les quatre actifs que la grille met à l'abri
Une décision build-vs-buy bien menée n'optimise pas que le coût. Elle protège ce qui, une fois perdu, ne se rachète pas.
Propriété de la donnée
La donnée qui vous distingue reste la vôtre, exportable dans des formats standard et indépendante du fournisseur. Pas un otage dans un silo propriétaire, mais un actif négociable qui vous donne du levier au renouvellement.
Capacité d'ingénierie bien dépensée
Chaque heure de développement va à votre avantage concurrentiel, pas à une commodité déjà résolue par le marché. Le sur-mesure là où ça compte, le marché là où ça ne compte pas.
Droits de sortie
Portabilité de la donnée, intégrations par API documentées et aucun câblage propriétaire maintiennent le coût de bascule bas. La possibilité de partir est ce qui vous garde à des conditions équitables.
Architecture composable
Des capacités remplaçables connectées par API : un composant change sans que le reste s'effondre. Le système reste vivant dans le temps, pas un monolithe à refaire.
Construisez ce qui vous distingue, achetez ce que vous partagez avec vos concurrents.
Les questions qu'on nous pose avant de décider
Le sur-mesure est-il toujours plus cher qu'une plateforme ?
Pas sur le cycle de vie. L'essentiel du coût d'un logiciel arrive après la mise en production — maintenance, intégration, formation. Sur une commodité, la plateforme l'emporte parce qu'elle reporte ce coût sur le fournisseur. Sur une capacité core à fort volume et longue durée d'usage, le sur-mesure s'amortit tandis que le tarif d'une plateforme grimpe avec le temps. La réponse est dans le TCO à cinq ans, pas dans le prix d'entrée.
Puis-je acheter maintenant et construire plus tard ?
Oui, et c'est souvent le bon mouvement — à condition de ne pas se faire piéger. Acheter pour démarrer vite a du sens si la donnée reste exportable dans des standards ouverts et que les intégrations passent par des API documentées. Si le fournisseur détient votre donnée dans un format propriétaire, « plus tard » devient une migration coûteuse que vous ne ferez jamais. La portabilité se négocie à la signature, pas au divorce.
Comment éviter de construire ce que le marché fait mieux ?
En cartographiant chaque capacité avant d'écrire du code. Si une fonction est devenue standard — la même pour vous et vos concurrents —, la construire, c'est de la capacité d'ingénierie brûlée. Le code en propre est réservé à ce qui vous différencie et évolue ; tout le reste s'achète ou se compose via API. Cette discipline sépare un investissement d'une dépense.
Cas
Du problème au résultat — anonymisés.
La plateforme déformée
Problème Un retailer avait personnalisé une plateforme e-commerce standard jusqu'à ce qu'elle ne se ressemble plus : chaque version de l'éditeur cassait la configuration et le « prêt à l'emploi » était devenu un projet de développement permanent, avec le moteur de pricing — leur vrai différenciateur — coincé dans des contraintes qu'ils ne contrôlaient pas.
Méthode Nous avons cartographié les capacités sur l'axe core/commodité : catalogue, checkout et paiements conservés sur la plateforme comme commodités derrière des API documentées ; le moteur de pricing et de promotions, partie de l'avantage concurrentiel, extrait en service en propre câblé de façon composable.
Résultat Les versions de l'éditeur ont cessé de casser le système, la capacité d'ingénierie est revenue au pricing au lieu des contournements, et la logique qui les distingue est devenue leur propre code — remplaçable sans faire s'effondrer le reste.
La donnée prise en otage
Problème Une société de services financiers gardait la donnée client qui la distinguait chez un fournisseur, dans un format propriétaire sans export vers des standards ouverts : changer était impensable et au renouvellement le fournisseur détenait tout le levier, car la sortie était de fait verrouillée.
Méthode Nous avons appliqué les gates de lock-in et de propriété de la donnée : renégocié les droits d'export vers des formats standard à l'échéance du contrat, déplacé les intégrations critiques sur des API documentées et ramené la donnée différenciante sous contrôle interne, en laissant les fonctions commodité là où elles étaient.
Résultat Le coût de sortie a chuté au point de restaurer le levier au renouvellement, la donnée est redevenue un actif négociable au lieu d'un otage, et la possibilité de partir est ce qui les a gardés à des conditions équitables.
La commodité construite de zéro
Problème Un opérateur logistique avait construit de zéro des capacités devenues commodités — authentification, notifications, gestion des utilisateurs — brûlant de la capacité d'ingénierie sur des problèmes déjà résolus par le marché, tandis que la planification des tournées, leur vrai avantage, restait sous-investie.
Méthode Nous avons fait passer chaque capacité par la carte de la valeur et le TCO à cinq ans : retiré le sur-mesure sur les commodités au profit de services du marché derrière des API, et concentré les développeurs sur l'optimisation des tournées, où le volume et la durée d'usage amortissent le code dédié.
Résultat Chaque heure de développement est revenue au différenciateur, la maintenance des commodités est passée aux fournisseurs, et l'architecture est devenue composable — des composants remplaçables qui changent sans refaire tout le bloc.
Aller plus loin
Architecture de produit IA→
Où finit la commodité et où commence le code en propre quand le système est IA-natif.
RAG et grounding→
Achetez le modèle, construisez le grounding sur la donnée qui vous distingue.
Gouvernance de l'adoption de l'IA→
Des critères défendables devant le conseil pour décider build, buy ou compose sur l'IA.