Décider d’abord du problème, pas de la technologie
L’erreur commence avec la question « construire ou acheter ». Je demanderais d’abord si cette fonction est un avantage concurrentiel. Pour une transcription typique, vous pouvez acheter. Pour des données et des règles uniques — vous aurez peut-être besoin de votre propre workflow.
L’erreur que j’éliminerais d’abord : Construire son propre système pour contrôler une tâche commodity.
Quoi préparer et quel résultat attendre
- Résultat : Vous comparez les options par coût total de possession et les validez sur un seul pilote.
- Notez les utilisateurs, le processus, les intégrations, les données, le calendrier, les contraintes obligatoires et une voie de sortie de la solution.
- Gardez les données sources et les droits d’accès séparés du résultat pour pouvoir vérifier ce que le travail de décision build-or-buy a réellement fait.
- Pour deux options, mesurez le temps jusqu’au résultat, la précision, le coût par opération, l’export des données et le remplacement du fournisseur.
Comparer acheter, construire et hybride sur un seul pilote
- Rassembler les exigences avant de choisir
Dans un seul tableau, figez tâche, utilisateurs, intégrations, classes de données, SLA, volume et interdictions dures.
Проверьте: Les exigences n’incluent pas le mot « moderne » sans sens mesurable.
Если не сработало: Remplacez un souhait par un critère : temps, précision, accès, export.
- Noter les options avec des poids
Remplissez une matrice 1–5 : adéquation 25 %, sécurité 20 %, vitesse 20 %, coût sur 3 ans 20 %, contrôle/portabilité 15 %. Score = somme(rating × poids) / 5.
Проверьте: Les poids reflètent le risque business, pas le goût personnel d’un développeur.
Если не сработало: Alignez les poids avec le propriétaire du processus et la sécurité.
- Calculer le TCO
TCO d’achat = licences + mise en œuvre + intégrations + formation + sortie. TCO de construction = analyse + développement + tests + infrastructure + support.
Проверьте: Il y a une estimation pour le support et la possession en année trois.
Если не сработало: Ajoutez une fourchette et énoncez les hypothèses explicitement.
- Lancer le même pilote
Donnez aux deux options le même échantillon d’entrée et le même critère de résultat. Vérifiez non seulement la qualité, mais aussi la facilité de corriger une erreur et d’exporter les données.
Проверьте: La décision est prise après une tâche réelle, pas une présentation.
Если не сработало: Arrêtez le pilote si vous ne pouvez pas vérifier le résultat en sécurité.
Je compare trois options
Ajoutez au tableau SaaS, API + votre propre workflow, et un système entièrement custom. Pour chacun, calculez le TCO sur 3 ans : lancement, licences, API, intégrations, personnes, sécurité, infrastructure, support et migration. Ne comparez pas un abonnement mensuel au salaire d’un développeur.
Notez vitesse de lancement 20 %, adéquation 20 %, TCO 20 %, contrôle des données 15 %, sécurité 15 % et sortie fournisseur 10 %. Score = somme(rating × poids). Avant de décider, lancez 20 cas réels et essayez d’exporter les données.
TCO = launch + licenses + API + integrations + people + security + support
Score = sum(rating * weight)Test de sortie fournisseur
Demandez un export dans un format clair, vérifiez la suppression des données, les droits d’accès, le SLA, le prix d’une croissance de volume ×10 et le calendrier de migration. Si l’entreprise ne peut pas nommer un propriétaire système après le lancement, peu importe que ce soit build ou buy — la solution n’est pas encore prête.
Un pilote qui tranche le débat
Donnez au SaaS, à un workflow API et au développement custom le même échantillon de 20 exemples réels. Pour chacun, enregistrez le temps, la précision, les correctifs manuels, le coût et si les données sources peuvent être exportées. Ne décidez pas à partir d’une démo avec une entrée parfaite.
Si un service prêt couvre 80 % d’un processus typique et que les 20 % restants peuvent rester manuels, c’est souvent mieux qu’une plateforme complète. Choisissez un système custom seulement avec un propriétaire, un budget de support et un plan de sortie — sinon le « contrôle » se termine avec un développeur parti en vacances.
Comment noter une option qui vivra trois ans
| Critère | Question | Bon signe |
|---|---|---|
| Entrée | Qu’est-ce qui entre exactement dans la décision build-or-buy ? | Notez les utilisateurs, le processus, les intégrations, les données, le calendrier, les contraintes obligatoires et une voie de sortie de la solution. |
| Action | Que le système a-t-il le droit de faire seul ? | Uniquement les actions listées à l’avance, sans accès à tout le compte |
| Vérification | Comment savoir que le résultat peut être accepté ? | Pour deux options, mesurez le temps jusqu’au résultat, la précision, le coût par opération, l’export des données et le remplacement du fournisseur. |
| Échec | Où va un cas peu clair ? | Gardez l’option que l’équipe peut supporter, même si elle impressionne moins en démo. |
Ce qui doit changer après la mise en place
Vous comparez les options par coût total de possession et les validez sur un seul pilote.
Pourquoi « on le construira nous-mêmes » est presque toujours sous-estimé
Construire son propre système pour contrôler une tâche commodity.
Acheter un outil sans API ni export de données.
Ne pas compter le support et le temps de l’équipe interne.
Comparer des fonctionnalités de démo au lieu d’une opération réelle.
Quand le choix affecte déjà l’architecture business
Faites intervenir un spécialiste lorsque le choix touche l’architecture, plusieurs systèmes, des données personnelles ou un TCO pluriannuel.
Que vérifier dans le contrat et dans le code
Quand l’hybride convient-il ?
Quand la partie de base peut être achetée et que les règles, données ou intégrations uniques restent chez vous.
Faut-il inclure le salaire du propriétaire ?
Oui. Le TCO inclut les heures de l’équipe, des prestataires et du propriétaire interne.
Quand faut-il acheter du prêt-à-l’emploi ?
Quand la tâche est typique, que la vitesse et les intégrations comptent, et que les exigences ne créent pas un fort différenciateur.
Quand faut-il construire soi-même ?
Quand le processus est unique, que les données ne peuvent pas sortir, qu’une logique spéciale est requise, ou que le coût de licence croît plus vite que le développement.
