Un SaaS paraît souvent moins cher parce que son prix tient dans une ligne mensuelle. Une application métier paraît plus chère parce que son investissement initial est visible. Trois ans plus tard, la comparaison peut s’inverser, rester en faveur du SaaS ou révéler que les deux options ont été chiffrées sur des périmètres différents.
Le premier signal faible apparaît lorsque le budget SaaS exclut l’intégration et l’administration interne. Un autre survient quand le budget sur mesure s’arrête à la mise en ligne sans maintenance, sécurité ni évolution. Le risque n’est pas seulement financier : une mauvaise comparaison enferme l’organisation dans un outil inadapté ou finance un développement sans avantage distinctif.
Le vrai enjeu consiste à comparer deux capacités équivalentes, avec les mêmes volumes, le même niveau de service et les mêmes obligations. La méthode relie coûts visibles, temps humain, incertitude, dépendance et valeur créée. Elle permet de décider, mais aussi d’identifier une option hybride ou un périmètre plus petit lorsque ni le SaaS pur ni le sur-mesure complet ne sont justifiés.
Le développement web sur mesure n’est pertinent que s’il sert un résultat que le standard couvre mal. La démarche de développement d’application métier doit donc commencer par un modèle économique révisable, avant le backlog et l’architecture.
Comparer le même résultat opérationnel
La comparaison commence par le résultat attendu : traiter un dossier, planifier une intervention, produire un devis, suivre un contrat ou rapprocher une facture. Les fonctions sont décrites avec leurs utilisateurs, volumes, délais, règles, exceptions, données et preuves. « CRM SaaS contre application sur mesure » reste trop vague.
Chaque scénario doit atteindre un niveau de service comparable. Si le SaaS couvre 80 % du processus et renvoie le reste vers des tableurs, le coût de ces contournements appartient au scénario SaaS. Si le sur-mesure prévoit des fonctions supplémentaires, leur valeur et leur coût sont isolés au lieu d’améliorer artificiellement son dossier.
Les exigences non négociables sont séparées des préférences : droits, disponibilité, localisation des données, intégrations, audit, accessibilité, mobile, conservation et délais de reprise. Une option qui ne satisfait pas une exigence essentielle ne devient pas compétitive parce qu’elle coûte moins cher.
Le périmètre comprend enfin l’organisation. Qui administre les utilisateurs, répond aux demandes, configure les règles, teste les mises à jour et maintient les référentiels ? Le logiciel ne produit pas seul le service attendu.
Construire un horizon de trois ans cohérent
Trois ans couvrent généralement le lancement, la stabilisation et plusieurs cycles d’évolution. Cet horizon reste assez court pour limiter les hypothèses lointaines, tout en révélant les licences récurrentes et l’exploitation que le budget de première année masque.
Le mois zéro correspond à la décision, pas à l’ouverture aux utilisateurs. Les dépenses de sélection, cadrage, contractualisation, développement, migration et conduite du changement sont placées avant la bascule. Les gains commencent seulement lorsque le nouvel outil produit réellement le résultat attendu.
Les scénarios utilisent la même date de départ et la même durée. Un SaaS disponible en six mois ne se compare pas à un sur-mesure dont les bénéfices seraient comptés dès le premier mois. Le décalage de mise en service influence trésorerie et valeur captée.
Les montants sont présentés en euros constants ou avec une convention d’indexation explicite. La finance peut actualiser les flux si l’investissement est significatif. L’essentiel est de ne pas mélanger un prix SaaS indexé avec un coût de maintenance figé sans justification.
Additionner tous les coûts du scénario SaaS
Le premier poste réunit abonnements, modules, environnements, stockage, API, signature, support premium et éventuels minima contractuels. Le prix par utilisateur est appliqué aux profils réellement facturés, pas uniquement aux personnes actives chaque jour.
Le démarrage comprend sélection, paramétrage, intégration, migration, reprise documentaire, tests, formation et accompagnement par l’éditeur ou un partenaire. Une mise en œuvre « incluse » doit être décrite : nombre de jours, périmètre de configuration et livrables couverts.
L’administration interne se poursuit après la bascule. Gestion des droits, création de champs, contrôle des imports, support de premier niveau, documentation et qualification des incidents consomment une fraction d’équivalent temps plein. Ce temps reste un coût même s’il n’apparaît sur aucune facture fournisseur.
Les évolutions peuvent exiger un module supérieur, une application tierce, du conseil ou une nouvelle intégration. Le modèle distingue l’évolution prévisible du changement exceptionnel. Il conserve aussi le coût des fonctions imposées par l’éditeur mais non utilisées.
- Abonnements, options, capacité, environnements et support contractuel.
- Implémentation, migration, intégrations, tests et formation.
- Administration interne, support, gouvernance des données et contrôle des mises à jour.
- Évolutions, indexation, renouvellement, export et sortie en fin de période.
Additionner tous les coûts du scénario sur mesure
L’investissement initial couvre découverte, conception, UX, architecture, développement, qualité, sécurité, déploiement, documentation et accompagnement des utilisateurs. Une estimation uniquement fondée sur les écrans sous-évalue les règles, les interfaces et les scénarios dégradés.
L’hébergement comprend environnements, base, stockage, sauvegardes, supervision, journaux et services externes. Le coût peut rester modeste face au développement, mais les exigences de disponibilité, de reprise ou de volume le font varier. Les hypothèses techniques sont donc reliées au besoin.
La maintenance distingue correction, adaptation et évolution. Les correctifs préservent le service ; l’adaptation suit navigateurs, systèmes, dépendances et obligations ; l’évolution ajoute de la valeur. Un pourcentage annuel peut servir de repère, mais un backlog réaliste offre une meilleure lecture.
L’entreprise conserve aussi une responsabilité produit. Priorisation, validation des règles, recette, administration et support métier ne disparaissent pas après la livraison. Si aucune capacité interne ou partenaire n’est prévue, la plateforme vieillira même avec un code techniquement sain.
Chiffrer intégrations et reprise des données
Les deux scénarios ont besoin de données et d’échanges. La différence vient de la liberté disponible. Un SaaS peut proposer un connecteur rapide mais limité ; le sur-mesure peut suivre exactement le contrat souhaité au prix d’un développement et d’une maintenance supplémentaires.
Chaque interface précise source, destination, fréquence, volume, sens, traitement des erreurs et personne responsable. Les licences d’un middleware, les quotas d’API, la supervision et les reprises manuelles rejoignent le coût. Une synchronisation nominale sans gestion des rejets n’est pas une intégration terminée.
La migration couvre inventaire, mapping, nettoyage, reprise, validation et archivage. Le coût dépend davantage de la qualité et du nombre de règles que du volume brut. Des millions de lignes cohérentes peuvent être plus simples que quelques milliers de dossiers sans identifiants fiables.
La réconciliation après bascule est budgétée. Pendant plusieurs semaines, l’équipe compare comptes, statuts, documents et historiques. Ce travail existe quelle que soit l’option, mais les outils disponibles et l’accès aux données peuvent fortement changer sa durée.
Mesurer le coût des écarts au standard
Un SaaS crée de la valeur lorsque l’organisation accepte son modèle. Chaque écart peut être absorbé par un paramètre, un module, une intégration, un changement de processus ou un contournement. Le modèle financier chiffre l’option choisie au lieu de supposer que le standard sera adopté sans effort.
Changer le processus n’est pas nécessairement une perte. Le standard peut supprimer une particularité historique sans valeur. En revanche, forcer une règle générique sur un avantage métier, une obligation ou une forte volumétrie déplace la charge vers les utilisateurs.
Le sur-mesure doit justifier chaque divergence. Reproduire toutes les habitudes coûte cher et fige parfois les défauts de l’existant. Le backlog sépare capacités différenciantes, adaptations temporaires et confort. Les éléments sans résultat mesurable sont différés.
Contre-intuitivement, une solution hybride peut coûter moins que le choix apparemment simple. Un SaaS reste maître des fonctions standard, tandis qu’une petite application gère le workflow spécifique et échange par API. Ce découpage évite de reconstruire l’authentification, la facturation ou les fonctions génériques.
Budgéter support, sécurité et exploitation
Le scénario SaaS inclut le support éditeur, mais l’entreprise garde la qualification des demandes, la gestion des comptes, l’aide métier et la coordination en cas d’incident. Les niveaux de service sont traduits en conséquences : disponibilité, délai de réponse, délai de correction et accès aux preuves.
Pour le sur-mesure, l’exploitation précise astreinte éventuelle, surveillance, sauvegardes, restauration, gestion des secrets, mises à jour et réponse aux incidents. Ces responsabilités peuvent être confiées à un prestataire ; elles ne peuvent pas être omises.
La sécurité comporte des coûts dans les deux options : revue contractuelle, configuration, tests, gestion des habilitations, audit, surveillance et traitement des vulnérabilités. Une certification fournisseur réduit certains contrôles sans garantir la bonne configuration de l’entreprise ni la sécurité des intégrations.
Le coût d’un incident est traité comme un risque, pas ajouté mécaniquement au total. Le modèle estime probabilité, impact et mesures de réduction pour comparer les expositions. Une fausse précision au centime donnerait plus de poids à l’hypothèse qu’aux faits.
Inclure adoption et contournements humains
La conduite du changement comprend communication, formation, documentation, support renforcé et temps passé à apprendre. Une interface familière peut réduire cet effort ; un processus plus simple peut au contraire justifier une rupture plus forte.
Les contournements sont mesurés : doubles saisies, exports, contrôles manuels, demandes au support, fichiers locaux et corrections après traitement. Leur coût annuel correspond au temps chargé, mais aussi aux erreurs, délais et décisions retardées.
L’adoption ne se limite pas aux connexions. Une personne peut ouvrir le SaaS tout en continuant le vrai travail dans un tableur. Les indicateurs suivent la part des dossiers entièrement traités, les étapes sorties du workflow et les motifs.
Les gains de productivité restent prudents. Une minute économisée sur une tâche ne devient une heure productive que si le volume et l’organisation permettent réellement de réallouer ce temps. Les gains invérifiables sont séparés des économies budgétaires.
Valoriser le délai et le coût d’opportunité
Le SaaS peut ouvrir plus tôt lorsqu’il correspond au besoin. Les bénéfices commencent alors avant ceux d’un développement. Le modèle place les flux mois par mois afin de représenter ce décalage, plutôt que de comparer uniquement trois totaux annuels.
Le sur-mesure peut toutefois livrer un premier périmètre avant la solution complète. Une tranche ciblée sur le goulot principal produit une valeur en quelques mois, puis finance ou éclaire la suite. Le scénario doit refléter cette trajectoire réelle.
Le coût d’attente s’appuie sur une perte observable : dossiers refusés, capacité saturée, revenu retardé, risque non maîtrisé ou pénalité. Il n’est pas ajouté si aucun résultat ne peut être attribué au nouvel outil.
Le délai de sélection du SaaS compte lui aussi. Appel d’offres, sécurité, contrat, paramétrage et migration peuvent prendre plusieurs mois. Présenter l’abonnement comme disponible immédiatement sous-estime le projet nécessaire pour l’utiliser correctement.
Tester utilisateurs, volume et indexation des prix
Le coût SaaS évolue avec les utilisateurs, transactions, contacts, stockage ou appels d’API. Trois scénarios — bas, central et haut — montrent le point où le modèle change. Une hypothèse unique masque la sensibilité la plus importante.
Les utilisateurs sont classés : contributeur quotidien, valideur occasionnel, lecteur, compte externe ou administrateur. Un tarif identique pour tous peut rendre le SaaS coûteux dans une organisation étendue. À l’inverse, un modèle à l’usage peut rester très compétitif avec beaucoup de lecteurs.
L’indexation contractuelle, les remises temporaires et les paliers de volume sont documentés. Le prix de première année n’est pas prolongé automatiquement sur trente-six mois si la remise expire ou si le contrat prévoit une hausse.
Le sur-mesure possède également des coûts variables : infrastructure, support, performance et traitement des volumes. Ils évoluent souvent par paliers plutôt que par utilisateur. Le modèle identifie les seuils où une optimisation ou une nouvelle capacité devient nécessaire.
Évaluer dépendance, réversibilité et coût de sortie
La sortie SaaS comprend export des données, récupération des documents, compréhension du schéma, maintien d’un accès historique, migration, double exploitation et résiliation. Le contrat précise formats, délais, coût, assistance et disponibilité des API après préavis.
La dépendance ne vient pas seulement des données. Les automatisations, modèles, tableaux de bord, identités, liens et habitudes doivent être remplacés. Plus l’écosystème autour du SaaS grandit, plus la migration exige un inventaire.
Le sur-mesure peut aussi enfermer : code non documenté, technologie rare, fournisseur unique, infrastructure inaccessible ou règles connues d’une seule personne. La propriété du dépôt ne suffit pas. Documentation, tests, procédure de déploiement et capacité de transfert réduisent ce risque.
Le modèle place un coût de sortie réaliste à la fin de l’horizon, même si aucun départ n’est décidé. Cette convention rend la dépendance visible. Elle peut être pondérée ou présentée séparément selon les règles financières de l’entreprise.
Reconnaître la valeur résiduelle du sur-mesure
Après trois ans, une application maintenue reste un actif opérationnel : code, tests, modèle de données, intégrations, documentation et connaissance du processus. Cette valeur n’est pas égale au coût historique et ne doit pas être utilisée comme une réduction automatique du TCO.
Elle devient tangible si l’entreprise peut poursuivre l’exploitation, changer de partenaire, étendre le produit ou réutiliser des composants. Un logiciel spécifique à un processus abandonné possède peu de valeur résiduelle, même s’il a coûté cher.
Le SaaS possède une autre forme de valeur : mises à jour mutualisées, réseau de partenaires, fonctions disponibles sans nouveau projet et réduction de responsabilités techniques. Ces bénéfices qualitatifs sont décrits et, lorsque possible, reliés à un coût évité.
Le bon arbitrage ne cherche donc pas à valoriser artificiellement le code. Il demande quel contrôle, quelle vitesse de changement et quelle capacité stratégique restent disponibles au terme des trois ans.
Construire le modèle financier sans fausse précision
Le tableur contient une feuille d’hypothèses, une feuille par scénario, une synthèse et une analyse de sensibilité. Chaque montant indique source, date, personne responsable, niveau de confiance et règle d’évolution. Une cellule sans source n’est pas cachée derrière un total.
Les entrées couvrent volumes, prix, capacité interne, délais, intégrations et risques ; les sorties montrent trésorerie, coût cumulé et coût par résultat. Les dépendances entre hypothèses sont explicites. La traçabilité permet de comprendre pourquoi une nouvelle offre éditeur ou une réduction de périmètre change la décision.
Une deuxième vue relie responsabilités, seuils et calendrier de révision. La journalisation conserve les versions du modèle, tandis qu’un contrôle signale les hypothèses expirées. Le suivi ne remplace pas la décision : il empêche qu’un ancien prix ou un gain non confirmé continue de piloter le budget.
Les scénarios bas, central et haut varient seulement quelques hypothèses déterminantes : croissance des utilisateurs, délai, effort d’intégration, adoption et coût d’évolution. Modifier toutes les cellules simultanément produit des extrêmes inutiles. Le modèle doit montrer les facteurs capables d’inverser le choix.
Cas chiffré : comparer deux scénarios hypothétiques
Par exemple, considérons une organisation fictive de 60 utilisateurs. Le SaaS coûte 80 € par utilisateur et par mois, soit 172 800 € sur trente-six mois. Ajoutons 45 000 € de mise en œuvre, 30 000 € d’intégration, 36 000 € d’administration interne, 30 000 € d’évolutions et 20 000 € de sortie : le total hypothétique atteint 333 800 €.
Le sur-mesure fictif demande 210 000 € de conception et développement, 45 000 € de migration et intégration, 54 000 € d’hébergement sur trois ans, 105 000 € de maintenance, 27 000 € de pilotage interne et 45 000 € de sécurité et exploitation. Son total hypothétique atteint 486 000 €.
Dans ce scénario, le SaaS est moins coûteux de 152 200 €. Le sur-mesure ne se justifie que s’il crée une valeur supplémentaire crédible, réduit un risque important ou évite des contournements absents des hypothèses. Le simple désir de propriété ne ferme pas cet écart.
Avec 350 utilisateurs au même tarif, les seules licences SaaS atteindraient 1 008 000 € sur trois ans. Le résultat pourrait alors s’inverser, mais l’application devrait supporter ce volume et son support. Ces chiffres ne constituent pas un barème : ils montrent pourquoi utilisateurs, prix et périmètre doivent être testés avant de conclure.
Savoir pour qui la comparaison devient critique
La méthode devient prioritaire lorsque le nombre d’utilisateurs ou de transactions fait varier fortement les licences, lorsque le processus porte un avantage métier ou lorsque plusieurs intégrations rendent la sortie coûteuse. Elle est également utile avant un renouvellement pluriannuel.
Une analyse plus légère suffit pour un outil standard, peu intégré, réversible et utilisé par une petite équipe. Le coût de l’étude doit rester proportionné à la décision. Quelques hypothèses documentées et deux offres comparables peuvent alors suffire.
Les organisations très contraintes par la conformité, la disponibilité ou la donnée doivent ajouter une matrice de risques. L’option la moins chère n’est retenue que si elle répond aux exigences essentielles et si le coût de réduction des écarts est inclus.
La comparaison est enfin indispensable quand le débat devient idéologique. « Le SaaS est toujours moins cher » et « le sur-mesure finit toujours par être rentable » sont deux raccourcis. Un horizon, un périmètre et des hypothèses observables ramènent la décision au contexte réel.
Répartir les hypothèses entre finance, métier et DSI
Le métier décrit volumes, règles, contournements, qualité et valeur attendue. La finance fixe conventions de coût, horizon, indexation, actualisation et traitement des risques. La DSI estime intégration, sécurité, exploitation, maintenance et réversibilité.
Les achats vérifient les prix, paliers, engagements, indexations et conditions de sortie. Les ressources humaines ou managers qualifient les coûts de capacité et d’adoption. Aucun acteur ne possède seul toutes les hypothèses.
Une personne coordonne le modèle et protège sa cohérence. Elle ne choisit pas les valeurs à la place des responsables ; elle signale les manques, les doublons et les conventions différentes entre scénarios.
Le comité de décision examine les facteurs qui inversent le choix, pas seulement le total central. Il valide aussi les conditions de révision : nouvelle offre, changement de volume, acquisition, réglementation ou retard significatif.
Éviter les erreurs fréquentes de comparaison
- Comparer licence et développement. Les deux scénarios doivent inclure projet, intégration, exploitation, adoption et sortie.
- Donner plus de fonctions au sur-mesure. La valeur supplémentaire est isolée au lieu d’être confondue avec le coût de base.
- Oublier le temps interne. Administration, support, recette et gouvernance consomment une capacité réelle.
- Figer utilisateurs et prix. Le volume et l’indexation peuvent inverser le choix sur trois ans.
- Compter les gains dès la décision. La valeur commence à la mise en service et monte avec l’adoption.
- Présenter un ROI sans preuve. Les économies budgétaires sont séparées du temps théoriquement libéré.
- Ignorer la sortie. Données, intégrations, habitudes et continuité ont un coût dans les deux modèles.
La fausse précision constitue un dernier piège. Un total à l’euro près ne rend pas fiable une hypothèse d’adoption incertaine. Les fourchettes, niveaux de confiance et analyses de sensibilité sont plus utiles qu’une addition exacte de nombres fragiles.
Produire une décision solide en six semaines
Semaine 1 : définir capacité, périmètre et exigences
Décrivez le résultat attendu, les utilisateurs, volumes, règles, exceptions, systèmes, données et niveaux de service. Séparez exigences obligatoires, valeur différenciante et préférences. Reconstituez la situation actuelle avec licences, temps humain, incidents et délais.
La sortie est un périmètre comparable et une liste d’hypothèses manquantes. Si les scénarios ne couvrent pas la même capacité, la comparaison est suspendue. Une option hybride peut être ajoutée dès cette étape si elle paraît crédible.
Semaines 2 et 3 : collecter prix et coûts techniques
Obtenez les offres SaaS avec modules, paliers, services, indexation et sortie. Estimez le sur-mesure par lots : découverte, produit, interfaces, migration, qualité, sécurité, déploiement et exploitation. Documentez les sources et dates.
Les intégrations sont décrites par contrat, dépendances, volume et reprise d’erreur. Le support et la maintenance reçoivent des responsabilités et des seuils de service. Les coûts internes utilisent des conventions validées par la finance.
Semaines 4 et 5 : modéliser valeur, risque et sensibilité
Placez dépenses et bénéfices mois par mois. Construisez scénarios bas, central et haut. Faites varier utilisateurs, délai, effort de migration, adoption et évolution afin d’identifier les hypothèses qui changent le résultat.
La journalisation conserve chaque version du modèle, la traçabilité relie cellule et source, et le monitoring des hypothèses signale une offre expirée. Les sorties comprennent coût cumulé, trésorerie, coût par dossier et risques non chiffrés.
Semaine 6 : décider et fixer les conditions de révision
Le comité compare résultat central, fourchettes, exigences et facteurs d’inversion. Il peut choisir le SaaS, le sur-mesure, l’hybride, un pilote ou l’absence de projet. Les bénéfices incertains ne compensent pas silencieusement un coût certain.
La décision indique le périmètre, le budget, les hypothèses critiques et la prochaine revue. Un seuil d’utilisateurs, un retard, un changement de prix ou une contrainte nouvelle peut rouvrir l’arbitrage avant que l’engagement devienne difficile à corriger.
- Comparer d’abord une capacité identique avec les mêmes exigences et volumes.
- Additionner ensuite projet, intégration, exploitation, adoption, évolution et sortie pour chaque scénario.
- Tester les hypothèses capables d’inverser le choix, plutôt que multiplier les chiffres secondaires.
- Décider enfin avec une date de révision et des seuils qui permettent de corriger la trajectoire.
Guides complémentaires : build, buy, coût et automatisation
La matrice build, buy ou hybride pour un outil métier aide à sélectionner la famille de solution avant le chiffrage détaillé. Elle compare standard, low-code, intégration et développement spécifique.
Le comparatif application métier ou SaaS approfondit les différences de contrôle, de responsabilité et d’adaptation. La méthode sur le coût d’une application métier détaille ensuite les postes propres au scénario de construction.
Pour vérifier que les gains justifient l’investissement, l’évaluation de la valeur d’une automatisation relie fréquence, capacité, erreur, risque et maintenance avant d’engager le développement.
- Utiliser la matrice de solution avant de demander des offres trop détaillées.
- Utiliser le modèle sur trois ans lorsque licences, intégrations ou sortie peuvent inverser le choix.
- Utiliser l’analyse de valeur pour refuser les fonctions spécifiques dont le bénéfice reste invérifiable.
Conclusion : choisir le coût que l’entreprise sait porter
Le SaaS gagne lorsque son standard couvre le besoin, que le volume reste compatible avec son prix et que la mutualisation évite des responsabilités techniques sans déplacer trop de travail vers les équipes.
Le sur-mesure gagne lorsque la capacité différenciante, l’échelle, le contrôle ou la vitesse d’évolution justifient l’investissement et que l’organisation accepte de maintenir un produit dans la durée.
L’hybride gagne souvent lorsque les fonctions standard restent mutualisées et qu’une couche ciblée porte seulement le workflow distinctif. Dans tous les cas, la meilleure option est celle dont coûts, risques et responsabilités restent soutenables après la mise en service.
Pour construire les scénarios, éprouver les hypothèses et réaliser le périmètre retenu, Dawap accompagne les projets de développement web et d’application métier sur mesure depuis la décision d’investissement jusqu’à l’exploitation.
