Choisir avant de développer

Logiciel métier sur mesure ou SaaS existant : comment choisir ?

Commencez par un SaaS si un produit existant couvre vos besoins essentiels et vos contraintes. Envisagez le sur mesure lorsque vos règles métier justifient un outil spécifique et que vous pouvez le faire vivre. Une approche hybride peut réunir les deux.

Par Jonathan Fidi · CTO et architecte logiciel · Publié le 7 octobre 2026

Trois options, selon ce qui rend votre activité particulière

Un SaaS est un logiciel accessible comme un service, exploité par son fournisseur. Le sur mesure décrit un logiciel conçu pour un besoin particulier. Ces notions ne sont pas opposées sur le plan technique : une application sur mesure peut aussi être hébergée dans le cloud. La décision porte ici sur l’achat d’un produit existant ou la construction de votre propre outil.

Choisir un SaaS existant

Cette piste mérite d’être testée en premier pour une fonction standard : prise de rendez-vous, suivi commercial ou gestion de demandes simples. Faites exécuter vos tâches réelles dans le produit. Vérifiez les droits d’accès, les exports et les limites de la formule envisagée. Une démonstration séduisante ne suffit pas si le travail quotidien impose ensuite des doubles saisies.

Construire un logiciel métier sur mesure

Le sur mesure devient pertinent lorsque les écarts concernent le cœur de votre activité : validations particulières, calculs propres à votre métier, coordination de plusieurs systèmes ou expérience client distinctive. Il demande un responsable capable de décider des priorités, du temps pour les retours utilisateurs et un budget de maintenance. Posséder du code ne dispense pas d’organiser son exploitation.

Combiner les deux

Vous pouvez conserver vos outils de référence et développer une interface ou un workflow autour d’eux. Par exemple, un outil de pilotage des opérations pourrait regrouper des tâches et des validations tout en laissant la comptabilité dans son logiciel. Ce scénario est illustratif. Sa faisabilité dépend notamment des API, des droits d’accès et de la qualité des données.

Une grille pour comparer vos contraintes

Utilisez ces critères pour préparer vos échanges. Ils orientent la décision ; ils ne remplacent pas un essai du produit ou un cadrage du projet.

Dans quelles situations privilégier chaque option
Critère	SaaS à privilégier si…	Sur mesure à étudier si…
Votre besoin	Un processus courant couvert par le produit	Un processus spécifique qui crée de la valeur
Votre délai	Un outil à configurer et à déployer rapidement	Un premier périmètre à concevoir, tester et livrer
Vos intégrations	Des connecteurs ou API qui couvrent les échanges nécessaires	Des règles complexes ou des systèmes peu compatibles
Vos évolutions	Vous pouvez suivre la feuille de route de l’éditeur	Vous devez décider du rythme et des priorités
Votre organisation	Un référent peut administrer le produit et former l’équipe	Un responsable métier peut arbitrer et suivre le logiciel dans la durée

Une contrainte bloquante peut suffire à écarter une solution : données impossibles à exporter, règle essentielle non couverte ou intégration indispensable indisponible. Ne la diluez pas dans une moyenne de critères secondaires.

Quel budget prévoir ? Comparez le coût total sur trois ans

Comparer un abonnement mensuel à un devis de développement donne une vision incomplète. Prenez le même périmètre, le même nombre d’utilisateurs et les mêmes volumes, puis estimez les dépenses initiales et récurrentes sur trois ans. Cette durée est une convention de comparaison à adapter à votre projet.

Coûts à intégrer dans les deux scénarios
Poste	SaaS existant	Sur mesure
Démarrage	Paramétrage, reprise des données, formation	Cadrage, conception, développement, tests, reprise des données
Utilisation	Abonnements, utilisateurs, volumes, options	Hébergement, services tiers, supervision, support
Intégrations	Connecteurs payants, automatisations, développements complémentaires	Construction et entretien des connexions aux autres outils
Évolutions	Changement de formule, adaptations et limites du produit	Maintenance corrective, sécurité et nouvelles fonctionnalités
Sortie	Export des données, migration et fin de contrat	Documentation, transfert à une autre équipe et migration

Coût total = mise en place + dépenses récurrentes sur 36 mois + intégrations + évolutions prévues + temps interne + coût de sortie estimé.

Évitez de compter deux fois une prestation déjà incluse dans un forfait. Faites une hypothèse basse et une hypothèse haute pour les volumes, les évolutions et la disponibilité des équipes. Comparez les montants sur une même base, par exemple hors taxes. Sans périmètre défini, annoncer un prix de logiciel serait trompeur.

Les gains attendus doivent aussi être vérifiés : mesurez le temps consacré à une tâche avant le pilote, puis après. Du temps libéré n’est pas automatiquement une économie de trésorerie. Identifiez comment il sera utilisé et qui bénéficiera de l’amélioration.

Données, confidentialité et dépendance : les questions à poser

Dans les deux cas, demandez qui peut accéder aux données, où elles sont hébergées, comment les sauvegardes sont restaurées et comment vous récupérez vos informations. Testez un export exploitable, avec les pièces jointes et les relations entre les enregistrements si elles sont nécessaires.

Pour des données personnelles confiées à un prestataire, la CNIL recommande de formaliser les obligations de sécurité et de vérifier les garanties de sous-traitance. Le choix du sur mesure ne garantit pas à lui seul la conformité. Consultez la fiche « Sécurité : gérer la sous-traitance » de la CNIL pour préparer ces vérifications.

Pour un développement spécifique, précisez aussi les droits sur le code, l’accès au dépôt, la documentation et les conditions de reprise par une autre équipe. Pour un SaaS, examinez les limites d’usage, les modalités de résiliation et les conditions d’export. Dans une approche hybride, prévoyez ce qui se passe si une API change ou devient indisponible.

Comment trancher sans lancer un projet trop large

Décrivez trois tâches réelles. Qui fait quoi, avec quelles informations, quelles validations et quelles exceptions ? Séparez les exigences indispensables des préférences.
Testez les solutions sur ces tâches. Utilisez des données fictives ou anonymisées. Faites participer les personnes qui utiliseront l’outil, et consignez les écarts observés.
Chiffrez les options comparables. Demandez ce qui est inclus, ce qui reste à votre charge et ce qui pourrait faire varier le coût. Étudiez l’hybride si seuls quelques besoins restent sans réponse.
Limitez le premier périmètre. Choisissez un workflow utile, un groupe pilote et des critères d’acceptation : tâches réalisables, droits corrects, absence de ressaisie inutile et données récupérables.
Décidez après le pilote. Poursuivez si les critères sont atteints et si l’exploitation est financée. Sinon, ajustez le périmètre ou reconsidérez la solution avant d’étendre le déploiement.

Deux exemples pour rendre la décision concrète

Une équipe qui souhaite simplement partager des documents avec ses clients peut commencer par tester un outil existant. Si elle doit gérer des accès par organisation, des validations spécifiques et des échanges avec son système interne, le scénario de portail client SaaS donne une idée du périmètre à étudier.

Pour une équipe opérationnelle, un tableau partagé peut suffire au départ. Lorsque plusieurs outils doivent être synchronisés et que les règles de validation deviennent centrales, une application métier peut mériter un cadrage. Ces situations sont des exemples de décision, pas des témoignages clients ni des promesses de résultat.

Vous hésitez entre acheter et construire ?

Décrivez le processus à améliorer, vos outils actuels, le nombre d’utilisateurs et votre échéance. Ces éléments permettent de discuter d’un périmètre réaliste et des options à évaluer.

Discuter de votre besoin

Votre projet intègre de l’IA ? Protéger les documents confidentiels. Pour aller plus loin : exemples de projets · audit d’architecture