Blog Disphere

Logiciel sur mesure ou SaaS : comment faire le bon choix ?

Abonnement, intégration, adaptations et maintenance : comparez le coût complet des options et vérifiez lesquelles respectent vraiment votre fonctionnement métier.

Disphere

Vous avez identifié un besoin : suivre des interventions, centraliser des demandes, produire des devis ou donner de la visibilité à vos clients. Plusieurs logiciels promettent de le couvrir. En parallèle, un développement sur mesure permettrait de reprendre exactement votre vocabulaire et vos règles.

Le choix ne se résume pas à « payer un abonnement ou posséder son logiciel ». Un SaaS peut demander une intégration importante. Un logiciel sur mesure demande de l’exploitation et des évolutions. Une solution hybride peut éviter de reconstruire des fonctions déjà bien couvertes.

Comparez les options à partir du travail à accomplir, de leurs limites concrètes et de leur coût complet. La préférence pour une technologie ou un mode de facturation vient après.

Définir ce qui est standard et ce qui fait votre différence

Une entreprise peut avoir des habitudes spécifiques sans avoir besoin d’un logiciel spécifique. Avant de demander une reproduction fidèle du fonctionnement actuel, posez une question : cette particularité améliore-t-elle réellement le service, ou vient-elle d’une contrainte historique ?

Un formulaire à douze étapes existe peut-être parce que trois anciens outils communiquaient mal. Reproduire ces étapes dans une application neuve préserverait le problème.

À l’inverse, certaines règles sont essentielles : un mode de calcul contractuel, une organisation des droits par établissement, un enchaînement de validations ou une information qui doit rester disponible sur le terrain. Il ne suffit pas qu’une solution affiche une case « personnalisation » pour les prendre en charge correctement.

Séparez donc vos exigences en trois catégories :

  • Indispensables : leur absence empêche le service ou crée un risque inacceptable.
  • Utiles : elles améliorent l’efficacité, mais un contournement reste possible.
  • Habitudes à réexaminer : elles méritent une discussion avant de devenir des spécifications.

Cette liste doit être discutée avec les utilisateurs et la personne responsable du processus. Un besoin jugé secondaire en comité de direction peut représenter vingt manipulations supplémentaires pour l’équipe qui travaille dans l’outil.

Évaluer un SaaS avec vos propres scénarios

Une démonstration commerciale montre le parcours prévu par l’éditeur. Pour évaluer l’adéquation à votre métier, préparez un dossier représentatif et demandez à le traiter de bout en bout.

Prenons un exemple fictif : une société de maintenance cherche un outil de suivi des interventions. Le scénario ne doit pas s’arrêter à la création d’un ticket. Il peut inclure :

  1. une demande provenant d’un client qui gère plusieurs sites ;
  2. une attribution à un technicien disposant d’un accès limité ;
  3. l’ajout de photos et d’un compte rendu depuis un mobile ;
  4. une intervention reportée faute de pièce disponible ;
  5. la validation par le responsable du site ;
  6. l’export des éléments nécessaires à la facturation.

Observez ce qui fonctionne directement, ce qui exige du paramétrage et ce qui nécessite du code externe. Vérifiez aussi le traitement d’une erreur : un site mal sélectionné, un doublon ou une intervention clôturée trop tôt.

Demandez quels éléments sont inclus dans l’offre réellement envisagée. Une API, des droits avancés, un environnement de test ou un export complet peuvent dépendre du forfait. Le budget doit correspondre à cette configuration, pas au tarif d’appel.

Comparer le coût complet sur une même période

Choisissez un horizon commun, par exemple trois ans, et utilisez les mêmes hypothèses de volume pour toutes les options. Il ne s’agit pas de prévoir parfaitement l’avenir, mais de rendre les différences visibles.

Pour un SaaS

Additionnez les abonnements, les éventuelles facturations à l’usage, le paramétrage, la migration des données, les intégrations et l’accompagnement des utilisateurs.

Ajoutez les coûts internes qui resteront nécessaires : vérifier les synchronisations, traiter les exports, administrer les accès ou compenser une fonction manquante. Un contournement manuel quotidien peut peser davantage que l’écart entre deux abonnements.

Pour un développement sur mesure

Incluez le cadrage, la conception, le développement, les tests et le déploiement. Prévoyez ensuite l’hébergement, la supervision, les sauvegardes, les mises à jour, le support et les évolutions métier.

Clarifiez ce que couvre la maintenance proposée. Corriger un défaut, adapter une intégration qui change et développer une nouvelle fonctionnalité sont trois prestations différentes. Une ligne « maintenance incluse » ne suffit pas à les distinguer.

Pour les deux options

Faites varier les hypothèses : deux fois plus d’utilisateurs, davantage de dossiers, une nouvelle filiale, une intégration supplémentaire. Examinez aussi un scénario moins favorable où l’adoption est lente.

Un coût élevé par utilisateur ne rend pas automatiquement le sur-mesure plus rentable. Le développement d’un outil inutilisé reste une mauvaise dépense, même si son coût marginal d’ajout d’un compte est faible.

Examiner les intégrations avant de signer

La présence d’une API est un début, pas une garantie que le parcours sera simple. Vérifiez les opérations dont vous avez réellement besoin : lire, créer, modifier, exporter et recevoir les changements.

Quelques questions permettent d’éviter des surprises :

  • Peut-on récupérer les données avec un identifiant stable ?
  • Les événements sont-ils transmis par webhook ou faut-il interroger régulièrement l’API ?
  • Quelles limites de débit et quelles restrictions de forfait s’appliquent ?
  • Comment détecter une synchronisation incomplète ou rejouer un traitement ?
  • Existe-t-il un environnement de test ?
  • Qui prend en charge une évolution de l’API ?

Ces questions valent aussi pour un logiciel développé à façon. Une interface spécifique ne supprime pas les contraintes des systèmes auxquels elle se connecte.

Si le besoin consiste surtout à faire circuler des informations entre des outils existants, une automatisation métier ciblée peut être plus pertinente qu’une nouvelle application complète.

Préparer la sortie dès le départ

Avec un SaaS, vérifiez le format et l’étendue des exports : les pièces jointes, les historiques, les relations entre objets et les droits sont-ils récupérables ? Demandez ce qui reste accessible à la fin de l’abonnement et dans quel délai les données sont supprimées.

Avec du sur-mesure, précisez les droits sur le code et les livrables, mais aussi leur accessibilité pratique. Le dépôt, les comptes d’hébergement, les configurations, les procédures de déploiement et les sauvegardes doivent pouvoir être repris selon les modalités convenues.

Avoir le code ne signifie pas automatiquement pouvoir exploiter le produit. La documentation, la connaissance du métier et l’état des dépendances comptent aussi. Demandez comment une autre équipe pourrait diagnostiquer un incident ou livrer une modification.

La réversibilité est une capacité à organiser, pas une propriété exclusive de l’une des deux approches.

Considérer une solution hybride

Il est souvent inutile de reconstruire une messagerie, un calendrier ou une gestion de paiement pour résoudre un problème de suivi opérationnel. Une application spécifique peut s’appuyer sur des services existants tout en concentrant le développement sur le parcours métier.

Dans l’exemple de la maintenance, le logiciel de facturation peut rester en place. Le développement spécifique peut porter uniquement sur le portail client et le suivi des interventions, avec une transmission contrôlée vers la facturation.

Cette approche réduit le périmètre à construire. Elle conserve toutefois un coût d’intégration et une dépendance à chaque fournisseur. Il faut donc la comparer, elle aussi, sur son fonctionnement complet.

Prendre une décision que l’on pourra expliquer

Retenez le SaaS lorsque vos exigences essentielles sont couvertes, que les adaptations restent raisonnables et que les conditions d’exploitation vous conviennent.

Étudiez le sur-mesure lorsque les écarts portent sur un fonctionnement réellement important, que les contournements sont coûteux et que l’entreprise peut financer l’entretien du produit dans la durée.

Si l’usage lui-même reste incertain, ne tranchez pas uniquement sur la base d’une longue liste de fonctions. Un MVP au périmètre resserré peut permettre de vérifier le besoin avant un investissement plus large : choisissez un parcours complet, quelques utilisateurs concernés et un résultat observable.

Pour préparer un arbitrage, rassemblez trois éléments : vos scénarios métier, les coûts complets des options et les points qui restent non vérifiés. Nous pouvons vous aider à comparer ces options, y compris lorsqu’une solution du marché suffit.