Face à un besoin métier, acheter un logiciel semble accélérer le déploiement tandis que construire promet une adaptation parfaite. Cette opposition est trompeuse. Une solution du marché exige configuration, intégration, gouvernance et changement des pratiques ; un développement interne s’appuie presque toujours sur des services et composants achetés. La décision porte davantage sur la propriété des capacités critiques que sur une alternative binaire.
Le choix doit partir du processus à soutenir, de son importance stratégique et des contraintes de l’organisation. Comparer une démonstration commerciale à une estimation sommaire de développement produit une décision fragile. Il faut évaluer les scénarios sur un périmètre commun, inclure leur exploitation et préparer les conditions de sortie avant de s’engager.
Clarifier le besoin avant de comparer les solutions
Un cahier des charges rempli de fonctionnalités reproduit souvent les habitudes actuelles sans interroger leur utilité. Il vaut mieux décrire les rôles, les décisions, les données manipulées, les exceptions et les résultats attendus. Cette cartographie révèle les étapes réellement différenciantes et celles qui relèvent de pratiques standard qu’un outil existant peut couvrir.
- Décrire les résultats et décisions plutôt qu’une liste d’écrans.
- Identifier les données sensibles, leurs propriétaires et leur cycle de vie.
- Recenser les exceptions, opérations d’administration et besoins d’audit.
- Séparer les exigences indispensables des préférences historiques.
Repérer ce qui différencie réellement l’activité
Construire est plus défendable lorsque la capacité soutient un avantage propre, évolue fréquemment avec la stratégie ou incorpore une connaissance métier difficile à standardiser. Garder cette capacité en interne peut accélérer les évolutions et éviter que la feuille de route d’un fournisseur ne contraigne le produit. Cela suppose néanmoins que l’organisation sache la concevoir et l’exploiter durablement.
À l’inverse, les fonctions largement standardisées bénéficient souvent d’un achat : authentification, facturation courante, gestion documentaire générique ou outils internes répandus, selon le contexte. Les reconstruire mobilise une équipe sur des exigences invisibles mais nombreuses. Le caractère « métier » d’un outil ne prouve pas sa différenciation ; beaucoup de processus spécifiques résultent simplement de l’histoire.
Comparer les coûts sur tout le cycle de vie
Le prix de licence et le coût initial de développement ne sont que les premières lignes. Pour un achat, il faut compter intégration, paramétrage, migration, formation, support, évolutions tarifaires et éventuels modules additionnels. Pour une construction, il faut inclure discovery, sécurité, tests, hébergement, astreinte, documentation, maintenance et renouvellement des compétences.
La comparaison doit utiliser un horizon cohérent et plusieurs hypothèses d’usage. Les coûts évoluent différemment selon le nombre d’utilisateurs, le volume de données ou les besoins de personnalisation. Il faut aussi rendre visible le coût d’opportunité : l’équipe mobilisée sur l’outil ne travaille pas sur d’autres priorités. Une fourchette documentée est plus honnête qu’un total précis fondé sur des inconnues.
- Coût de mise en place et de migration initiale.
- Coût récurrent d’exploitation, support et conformité.
- Coût des changements prévisibles et des intégrations futures.
- Coût de sortie, de récupération des données et de remplacement.
- Coût d’opportunité des équipes internes mobilisées.
Tester l’adéquation au-delà de la démonstration
Une démonstration fournisseur présente un scénario maîtrisé. L’évaluation doit utiliser des cas réels, notamment les exceptions qui consomment du temps aujourd’hui. Un essai avec des données représentatives permet d’observer la configuration, les droits, les exports, les performances perçues et la capacité des utilisateurs à accomplir leur travail sans contournement.
Pour l’option interne, un prototype ou un POC doit cibler les mêmes risques. Il ne faut pas comparer un produit mature à une maquette idéale, ni une estimation de quelques écrans à la totalité d’une plateforme. Les deux scénarios doivent répondre à une grille commune et signaler ce qui reste non prouvé.
Évaluer dépendance, sécurité et réversibilité
Acheter transfère certaines responsabilités, mais pas la responsabilité finale de l’organisation sur ses données et ses opérations. Il faut examiner les modalités d’accès, la localisation, la sous-traitance, la gestion des incidents, les journaux disponibles et les engagements de service. Les réponses doivent être vérifiées dans les documents contractuels et techniques, pas déduites du discours commercial.
La réversibilité se prépare avant la signature. Quels formats d’export existent, à quelle fréquence peut-on extraire les données, et comment récupérer les pièces jointes, historiques ou règles de configuration ? Côté construction, la dépendance peut prendre une autre forme : expertise détenue par quelques personnes ou composants sans alternative. Aucun choix n’élimine le verrouillage ; il s’agit de le connaître et de le rendre gérable.
- Tester un export complet et exploitable, pas seulement consulter une promesse.
- Documenter les API, limites d’usage et mécanismes d’authentification.
- Prévoir la continuité en cas d’indisponibilité ou de fin de contrat.
- Identifier les compétences rares et dépendances critiques du scénario interne.
Assumer les options hybrides et décider par étapes
De nombreux cas trouvent une meilleure réponse dans une architecture hybride : acheter un socle standard, construire l’expérience ou les règles différenciantes, et relier les deux par une frontière maîtrisée. Cette approche réduit le périmètre interne sans abandonner la capacité stratégique. Elle exige toutefois des responsabilités claires sur les données, les incidents et les évolutions d’interface.
En conclusion
Le bon choix build vs buy ne découle ni d’une préférence pour le sur-mesure ni d’une confiance générale dans le SaaS. Il dépend de la différenciation du processus, du coût complet, de la capacité d’exploitation et du niveau de dépendance acceptable. Une comparaison sérieuse place les scénarios sur le même périmètre et teste leurs zones d’incertitude.
En préparant la réversibilité et en considérant les options hybrides, l’organisation garde davantage de marge. La décision devient alors un choix de responsabilités : ce qu’elle veut maîtriser, ce qu’elle accepte de déléguer et les preuves dont elle aura besoin pour réviser cette frontière dans le temps.
