Beaucoup d’équipes hésitent entre souscrire à un SaaS reconnu et faire développer une application web métier alignée sur leurs processus. Les deux voies peuvent réussir ; l’échec arrive quand on confond time-to-value, coût total de possession, différenciation et risque fournisseur. Voici un cadre pragmatique — orienté dirigeant et product owner — pour cadrer une décision défendable devant la direction, l’IT et les métiers.
Clarifier l’objectif : automatiser, différencier ou les deux ?
Un SaaS vertical excellent résout 80 % des cas standards d’un secteur : il accélère le démarrage et mutualise la R&D. Une application sur mesure prend tout son sens quand votre avantage compétitif vit dans un processus que les éditeurs généralistes ne modélisent pas bien : règles de tarification complexes, chaîne documentaire spécifique, orchestration multi-pays, contraintes réglementaires locales. Si votre besoin est surtout « remplacer Excel et les e-mails », un SaaS bien choisi avec paramétrage suffit souvent. Si le besoin est « encoder notre savoir-faire opérationnel », le sur-mesure ou un SaaS extensible (API, webhooks, modules) mérite l’étude.
Coût total de possession : au-delà du prix par siège
Le TCO agrège licences, implémentation, intégrations, formation, support, conformité, et coût d’opportunité des délais. Un SaaS peut sembler mensualisé « raisonnable » mais gonfler quand les add-ons, l’API payante, ou les surcharges par volume s’activent. Un développement custom exige investissement initial plus visible — mais vous contrôlez la roadmap et évitez certaines hausses de tarif éditeur. Modélisez trois ans, pas trois mois : incluez les révisions légales, les montées de version, et le temps interne passé en ateliers et recette.
Délai et risque : itérations courtes vs big bang
Les SaaS mûrs livrent vite un MVP paramétré ; le risque est la dérive fonctionnelle si l’équipe tente de reproduire l’intégralité du legacy dès le jour J. Le sur-mesure permet des vertical slices métier, mais exige une gouvernance produit claire — sinon le projet gonfle en fonctionnalités « indispensables » non priorisées. Quelle que soit la voie, imposez un périmètre V1 écrit, des critères d’acceptation testables, et une fenêtre de hypercare après mise en production.
Intégrations : le point où les projets basculent
ERP, CRM, AD/LDAP, messagerie, outils de signature, passerelles de paiement : la valeur réelle naît souvent à l’interface entre systèmes. Vérifiez pour le SaaS : qualité des API, webhooks, limites de débit, sandbox, documentation, et politique de breaking changes. Pour le sur-mesure : qui possède les contrats d’interface, comment versionner, et comment journaliser les erreurs de synchronisation. Les deux approches échouent si les données sources sont sales : prévoyez un chantier d’hygiène référentielle en parallèle, pas « après ».
Sécurité, conformité et souveraineté des données
Hébergement, chiffrement au repos et en transit, gestion des rôles, traçabilité, sauvegardes, et parfois résidence des données ou clauses sectorielles : listez vos obligations avant de choisir. Un SaaS certifié réduit la charge sur certaines couches — à condition que le DPA et les sous-traitants soient acceptables. Le sur-mesure vous donne la main sur l’architecture, mais transfère la responsabilité des mises à jour et du durcissement. Il n’y a pas de réponse universelle ; il y a une matrice de risques à remplir avec juridique et RSSI.
Évolutivité : qui décide de la roadmap ?
Avec un SaaS, la roadmap est partagée avec des milliers de clients : vous bénéficiez d’innovations, mais subissez parfois des refontes imposées ou des fonctionnalités tardives. En custom, vous pilotez — au prix de budgets récurrents pour maintenir la dette et suivre les frameworks. L’hybride SaaS noyau + extensions custom via API est souvent le compromis des organisations matures : le standard pour le générique, le sur-mesure pour le différenciant.
No-code / low-code : utile, mais pas magique
Les outils visuels accélèrent prototypes et back-offices simples. Ils se heurtent vite aux règles métier complexes, aux exigences de performance sous charge, aux audits de sécurité poussés, et à la reproductibilité des environnements. Utilisez-les pour valider un parcours ; basculez vers du code structuré quand la complexité ou la criticité augmente — ou encapsulez le low-code derrière des garde-fous d’API et de tests.
Organisations, rôles et adoption
La meilleure application échoue si les métiers ne sont pas impliqués dans la définition des parcours et la recette. Désignez des référents par domaine, planifiez des démos intermédiaires, et mesurez l’adoption (connexions, tâches complétées, temps gagné) plutôt que le seul déploiement technique. Prévoyez une documentation vivante et une montée en compétence support interne — le SaaS comme le custom exigent toujours de l’humain.
Indicateurs pour trancher en comité
Posez ces questions : le besoin est-il standardisable ? Votre différenciation est-elle dans le logiciel ou ailleurs ? Avez-vous besoin de contrôle fin des données et de l’infra ? Quel est le coût d’attente d’un délai de six mois supplémentaire ? Quelle est votre capacité interne à maintenir et prioriser un backlog produit ? Si le SaaS couvre le cœur avec de bonnes API et que seuls 15 % des besoins sont spécifiques, commencez par le SaaS et encapsulez le spécifique. Si 60 % du flux valeur est atypique, un produit dédié ou un framework interne peut être plus rentable.
Cas fréquents : ce que nous observons sur le terrain
Portail partenaires avec workflows et pièces jointes sensibles : souvent mix identité entreprise + développement ciblé. Back-office de gestion de dossiers : SaaS si le modèle « cas / étapes / pièces » est classique ; custom si les règles de validation croisent plusieurs référentiels hétérogènes. E-commerce B2B avec grilles tarifaires et approbations : les plateformes matures aident ; les règles de remise multi-niveaux poussent vers des extensions. Outils internes de planification : attention au no-code qui devient « application critique » sans tests de charge ni supervision.
Après le choix : industrialiser la livraison
Quelle que soit la voie, alignez CI/CD, environnements de recette, jeux de données anonymisés, et monitoring. Même sur SaaS, automatisez ce qui peut l’être : provisioning d’utilisateurs, synchronisations, alertes sur échecs d’intégration. Sur custom, exigez revues de code, scans de dépendances, et journaux structurés — la dette de sécurité est un coût différé toujours payable.
Une feuille de route de décision en trois ateliers
En pratique, trois sessions suffisent souvent à cadrer sans paralysie : (1) cartographier les parcours critiques et les données associées ; (2) noter pour chaque besoin s’il est couvert nativement par un court-list SaaS, par configuration, ou seulement par développement ; (3) chiffrer scénarios TCO sur trois ans avec hypothèses de croissance utilisateurs et volumes d’API. Faites participer un représentant finance pour verrouiller les critères d’arbitrage avant les démos commerciales — sinon l’émotion produit l’emporte sur la rationalité budgétaire. Documentez les points de revue à six et douze mois : si les écarts d’usage par rapport aux hypothèses dépassent un seuil convenu, vous ré-ouvrez le débat SaaS / custom sans perdre face.
Synthèse exécutive
SaaS quand le standard couvre le métier critique, que l’éditeur est solide, et que les intégrations sont saines. Sur mesure quand la différenciation et les règles sont trop spécifiques pour un paramétrage rentable. Hybride dans la majorité des transformations matures : standard pour le socle, développement ciblé pour le levier compétitif. Documentez hypothèses, seuils de revue à 12 / 24 mois, et plans B fournisseur — une décision logicielle est toujours aussi une décision de risque et de gouvernance.
Vous arbitrez un portail métier, une refonte applicative ou une intégration SaaS ? Parcourir les services ou demander un échange pour cadrer architecture, sécurité et roadmap.