Achats, ops, finance, santé : vos process finissent par déborder des outils du marché. Ce guide donne une méthode pour décider quoi louer, quoi construire, et quand.
Vous hésitez entre prolonger un SaaS et financer un outil sur mesure. C'est l'arbitrage que les anglo-saxons appellent build vs buy : construire ou acheter. Le prix et la vitesse ne suffisent pas à trancher. Il faut répondre à deux questions : quel risque acceptez-vous de porter, et quel actif voulez-vous posséder à la fin ?
Le SaaS reste une excellente réponse quand le besoin est standard. Le sur-mesure devient intéressant quand le process est spécifique, différenciant, sensible ou déjà trop tordu pour rentrer proprement dans un outil du marché.
Un SaaS, c'est un produit loué. Vous gagnez de la vitesse, une maintenance incluse et un niveau de maturité impossible à atteindre seul sur des fonctions standard. En échange, vous acceptez son modèle de données, son rythme produit, ses contrats et ses limites.
Un logiciel sur mesure, ce n'est pas repartir d'une page blanche pour tout reconstruire. C'est utiliser des briques standard pour ce qui n'a aucune valeur différenciante, puis développer la couche métier que personne ne peut acheter telle quelle.
Le coût du premier build a baissé sur beaucoup de sujets. Pas parce que les projets sont devenus simples, mais parce que les outils IA et les frameworks modernes accélèrent les tâches répétitives : interfaces, tests, documentation, refactorisation, intégrations classiques.
Le goulot d'étranglement se déplace. Le danger n'est plus seulement de coder trop lentement. C'est de coder vite la mauvaise chose : mauvais périmètre, mauvaise donnée, mauvaise architecture, mauvais niveau de sécurité, mauvais contrat de maintenance.
Ces signaux ne veulent pas dire « il faut tout construire ». Ils veulent dire : le SaaS standard ne suffit peut-être plus, et l'arbitrage mérite d'être cadré sérieusement avant de signer ou de prolonger.
Signal 1
Achats, ops, finance, santé : si chaque règle métier devient un champ détourné, une note interne ou un export Excel, l'outil ne porte plus le process. Il le force.
Le signal n'est pas l'inconfort. C'est le moment où les contournements deviennent la norme.
Signal 2
Pricing, validation fournisseur, intervention terrain, contrôle qualité, suivi patient, reporting multi-sites : si ce flux joue directement sur la marge, les délais ou la qualité, il mérite mieux qu'un bricolage.
Le sur-mesure devient pertinent quand le logiciel encode un savoir-faire que vos concurrents ne peuvent pas acheter tel quel.
Signal 3
Données santé, droits fins, historique d'audit, clauses de réversibilité, données commerciales sensibles : le sujet n'est pas seulement où l'outil est hébergé, mais qui maîtrise les accès, les exports et les traces.
Plus la donnée est stratégique, plus l'architecture doit être décidée avant le choix de l'outil, pas découverte après signature.
Signal 4
Si une fonctionnalité bloquante est attendue depuis des mois, votre roadmap métier dépend déjà d'un comité produit externe qui ne travaille pas pour vous.
Le sur-mesure ne règle ce problème que si vous savez arbitrer : quoi construire, quoi acheter, quoi repousser.
Signal 5
Exports, retraitements, doubles saisies, validations par mail, contrôles manuels : ces heures ne sont presque jamais dans la ligne SaaS du budget, mais elles existent.
Quand ces contournements coûtent plus cher que l'abonnement, le débat change : vous ne comparez plus un outil à un autre, vous comparez deux modèles opérationnels.
Le tableau ne donne pas une réponse universelle. Il montre où regarder avant de signer : coût réel, vitesse de création, vitesse d'adoption, différenciation, réversibilité et risque opérationnel.
| Critère | SaaS | Sur-mesure |
|---|---|---|
| Coût de départ | Faible à moyen Le sujet est surtout le contrat, les modules et les frais de mise en place. | Plus élevé Il faut financer le cadrage, le build, la mise en production et la reprise éventuelle. |
| Coût total à 3-5 ans | Peut monter vite Sièges, modules, quotas, intégrations, migration et contournements manuels. | S'amortit sur la durée Si le périmètre est stable, utile et maintenu. Dangereux si personne ne pilote la dette. |
| Vitesse de création | Très rapide sur l'existant Si l'outil existe déjà et que vous acceptez son modèle. Plus lent dès qu'il faut beaucoup configurer ou intégrer. | Rapide sur un flux borné Avec l'IA et une stack moderne. Lent si vous essayez de faire un SI complet en version 1. |
| Déploiement / adoption | Rapide à ouvrir Pas toujours rapide à faire adopter : les équipes doivent parfois adapter leur process à l'outil. | Mieux adopté s'il colle au terrain Aussi risqué que le SaaS si l'outil est cadré loin du flux réel, des utilisateurs, de leurs droits et de leurs données. |
| Différenciation | Faible Vos concurrents peuvent acheter le même outil. | Forte Si le logiciel encode un savoir-faire métier réel. |
| Réversibilité | Dépend du contrat Des exports et de la structure de données. | Meilleure si vous possédez tout Code, accès, hébergement et documentation doivent vous appartenir vraiment. |
| Risque principal | Le lock-in Hausse tarifaire, roadmap qui ralentit, dépendance à un éditeur. | Le mauvais cadrage Prestataire opaque, dette technique, maintenance oubliée. |
Le bon terrain n'est pas « nous voulons un outil parfait ». C'est « nous avons un flux métier assez important pour justifier un actif propre ».
Sourcing, qualification fournisseur, consolidation d'exports, validation interne ou reporting multi-sites. Les suites achats du marché couvrent bien le standard. Ce sont vos règles les plus spécifiques, seuils dérogatoires, circuits d'exception, consolidations maison, qui finissent en contorsions.
Flux terrain, demandes, contrôles, planification, interventions, exceptions. Si le process vit dans Excel et des mails, le bon sujet est souvent un logiciel métier ciblé.
Contrôles, validations, provisions, rapprochements, workflows de décision. On ne remplace pas l'ERP : on construit la couche qui évite les manipulations manuelles.
Droits, traçabilité, règles de suivi, contraintes HDS ou RGPD santé. Ici, le choix SaaS ou sur-mesure doit partir de l'analyse de risque.
Achats, ops ou finance font parfois tourner un mini-SI parallèle : Excel, macros, Power BI, validations par mail. S'il porte des décisions ou du reporting multi-sites, le sur-mesure permet de reprendre la main sur les droits et la traçabilité.
Historique métier, données clients, règles de décision, reporting propriétaire : si cette donnée prend de la valeur, le sur-mesure devient un choix de propriété, pas seulement de fonctionnalité.
Si le sujet est un premier outil interne, la question n'est pas toujours « faut-il une grosse équipe ? ». Lire le décryptage sur l'outil métier en 15 jours. Deux de ces cas sont détaillés dans des guides dédiés : la consolidation des fichiers achats et la reprise en main du shadow IT face à la DSI.
Le bon arbitrage part du terrain : le flux réel, les données manipulées, les contraintes réglementaires et la capacité à maintenir l'outil dans le temps.
Étape 1
Commencez par chiffrer le temps perdu, les erreurs, les retards et les risques que l'outil doit réduire. Ce chiffre servira de référence à toutes les étapes suivantes.
Étape 2
Pour un besoin standard, commencez par regarder les SaaS du marché. Pour un besoin spécifique, étudiez le build. Pour un besoin réglementaire, vérifiez d'abord l'architecture et les risques, quel que soit le choix.
Étape 3
Un abonnement mensuel n'est pas comparable à un devis de build. Le bon calcul regarde trois à cinq ans, les contournements, les intégrations, la migration et la maintenance.
Comment calculer le coût total ?
Coût total = investissement initial + coûts récurrents + intégrations + temps humain caché + maintenance + coût de sortie
Étape 4
Cherchez ce qui casse en premier. Si le logiciel engage une garantie, le risque est juridique. Si les équipes sont réfractaires au changement, le risque est l'adoption. Si l'outil doit rester disponible 24/7, le risque est technique. Ce sont ces points qu'il faut cadrer avant de financer le reste.
Étape 5
Vous avez les gains chiffrés, la classification et le coût total. Reste une dernière question avant de trancher : ce besoin va-t-il rester stable dans le temps ?
Exemple : Un SaaS peut être le bon choix aujourd'hui pour aller vite. Si le besoin se spécialise et que l'IA continue de faire baisser le coût du build, l'arbitrage devra être rouvert. Une bonne décision aujourd'hui peut devenir la mauvaise dans trois ans.
Comment comparer les scénarios ?
ROI à 3 ans = (gains cumulés sur 3 ans - coût total sur 3 ans) / coût total sur 3 ans
Un SaaS à quelques milliers d'euros par mois paraît léger face à un devis de développement sur mesure. Sur trois à cinq ans, la discussion change. Le coût réel inclut les licences, les modules, les intégrations, le temps humain et le coût de sortie.
Coût cumulé sur 5 ans : cas fictif
SaaS : 2 000 €/mois, avec une facture qui grossit d'environ 12 % par an (sièges, modules).
Sur-mesure : 35 k€ de build, puis 12 k€/an tout compris (maintenance, évolutions, hébergement, supervision).
Écart à 5 ans : 57 k€.
Cas fictif, vos chiffres seront différents. Inversez les hypothèses (un SaaS à 500 €/mois, prix stable) et le SaaS gagne : c'est tout l'intérêt de faire le calcul.
Le bon choix pour un besoin standard, avec un éditeur solide, une réversibilité claire et peu de dépendance à une feature spécifique.
Souvent le meilleur compromis : garder Stripe, Pennylane, HubSpot ou un ERP pour le standard, et construire votre logique métier autour.
Pertinent si vous avez déjà une équipe technique et un flux qui mérite un actif propre. Le risque se déplace vers la priorisation et la maintenance.
Le réflexe classique sans équipe interne. Les points à verrouiller : périmètre écrit, propriété du code, réversibilité et maintenance après livraison.
Pertinent quand un premier flux utile peut être borné : objectif, exclusions, critères de succès, propriété du code et mise en production.
Utile quand le sujet n'est pas seulement de coder : challenger un devis, recadrer un prestataire, expliquer le risque au COMEX, prioriser une roadmap.
De mon côté, je préfère cadrer un premier build au forfait quand le périmètre peut être écrit proprement. Le client doit savoir ce qu'il achète : un flux, un prix, un délai, la propriété du code et une mise en production.
Quand le sujet est encore trop flou, je ne pousse pas un build. Le bon premier livrable est un audit, un cadrage Go/No-Go ou un rôle de CTO externalisé le temps de sécuriser l'arbitrage.
Piège 1
C'est confortable, mais faux. Il faut comparer le coût total sur plusieurs années, les contournements, la dépendance et la valeur de ce que vous possédez à la fin.
Piège 2
Refaire une paie, une comptabilité ou une signature électronique n'est pas stratégique. C'est une distraction coûteuse.
Piège 3
Un SaaS peut masquer le problème pendant six mois. Si le process métier reste flou, l'outil deviendra un nouvel endroit où ranger le flou.
Piège 4
Sans décideur accessible, le sur-mesure dérive. Les arbitrages doivent remonter vite : scope, données, droits, budget, Go/No-Go.
Piège 5
Un actif logiciel doit vivre. Correctifs, sécurité, logs, sauvegardes, dépendances et documentation doivent être prévus dès le devis.
Le SaaS est excellent pour ce qui est standard. Le sur-mesure devient sérieux quand le process est stratégique, que la donnée compte, que la roadmap externe bloque, ou que les contournements coûtent déjà plus cher que l'outil lui-même.
Le bon choix ne se résume pas à "acheter ou construire". Il consiste à décider ce que vous acceptez de louer, ce que vous devez posséder, et quel risque vous voulez vraiment réduire maintenant.
Sept termes qui reviennent dans toute discussion build vs buy, avec un DAF, un prestataire ou une DSI.
Oui. Pour un besoin standard, mature et peu différenciant, le SaaS reste souvent le meilleur choix. Le problème commence quand un process stratégique dépend d'une roadmap externe, de contournements manuels ou d'une donnée difficile à récupérer.
Souvent, oui. Tout dépend du point de comparaison. Face à un petit SaaS à quelques centaines d'euros par mois, le build coûte plus cher. Face à un module ERP hors de prix utilisé à 10 % de ses capacités, il peut être rentable dès la première année. Comparez sur 3 à 5 ans, temps humain et coût de sortie inclus.
C'est souvent la meilleure architecture. On garde des SaaS robustes pour le standard, et on ne développe que ce qui vous est propre : règles, workflows, données, reporting, contrôles.
Rarement. Recoder une comptabilité, une paie ou une gestion de stock n'apporte aucune différenciation. Le bon montage garde l'ERP pour le standard et construit autour le logiciel métier qui manque : validations, contrôles, reporting, flux terrain. Le développement sur mesure remplace les exports Excel et les modules hors de prix, pas votre ERP.
Ce n'est plus bloquant pour livrer un premier outil. Avec l'IA, les frameworks modernes et un pilotage senior, il peut être cadré, prototypé et livré sans équipe interne. Ça le reste pour le faire vivre : sans équipe, le contrat de maintenance (correctifs, sécurité, sauvegardes, réversibilité) se signe en même temps que le build, pas après.
Regardez la réversibilité, les exports, les clauses contractuelles, la dépendance à des modules payants, le support, la roadmap publique et votre capacité à sortir sans perdre vos données ou votre historique métier.
Dès que le coût d'erreur est élevé : engagement SaaS pluriannuel, refonte métier, données sensibles, devis prestataire important, migration ou process cœur de métier. Une à quatre journées d'audit suffisent souvent à poser une décision argumentée.
Pour aller plus loin : tous les décryptages, et si votre projet doit passer une DSI, le guide pour obtenir un oui.