DigitalWebWorks.
← Tous les articles

Site vitrine, application métier ou SaaS : comment choisir ?

Un guide de décision pour un dirigeant : les 3 familles de projets web, à quoi elles servent, et les questions à se poser avant de trancher.

1 août 20265 min de lecture
Stratégie produitGuideSaaS

Un dirigeant qui a besoin d’un projet digital arrive souvent avec une solution déjà en tête — « il me faut un site », « il me faut une appli » — avant d’avoir posé le vrai problème. Le résultat est un projet mal calibré : trop léger pour le besoin réel, ou beaucoup trop lourd pour ce qu’il fallait résoudre. Avant de choisir un format, il faut d’abord comprendre les trois familles disponibles et ce que chacune fait réellement.

Un site vitrine, c’est fait pour quoi ?

Le site vitrine présente une activité, rassure et convertit un visiteur en contact. C’est un support de communication à sens unique : l’entreprise y expose son offre, un prospect y trouve l’information dont il a besoin pour prendre rendez-vous ou remplir un formulaire. Il n’y a pas de compte utilisateur, pas de logique métier, pas de données propres à chaque visiteur — le contenu est le même pour tout le monde. C’est le bon choix quand l’objectif est la visibilité et la génération de contacts, pas la gestion d’un processus.

Une application métier, c’est fait pour quoi ?

L’application métier automatise un processus interne précis : planification de rendez-vous, suivi de dossiers, gestion des stocks, facturation. Elle a des utilisateurs identifiés — le plus souvent les équipes de l’entreprise, parfois un cercle restreint de clients — et une logique propre à un fonctionnement métier spécifique, pas à une audience large. L’enjeu n’est pas de convertir un visiteur anonyme mais de faire gagner du temps à des personnes qui utilisent l’outil tous les jours. Ce n’est pas un produit qu’on revend : c’est un outil interne taillé sur mesure pour une organisation donnée.

Un SaaS, c’est fait pour quoi ?

Le SaaS (Software as a Service) est un produit vendu à plusieurs clients indépendants les uns des autres, hébergé et opéré par son éditeur, avec une facturation récurrente. La différence structurante avec une application métier n’est pas fonctionnelle mais architecturale : un SaaS doit gérer plusieurs organisations cloisonnées sur une même infrastructure (le « multi-tenant »), avec de la facturation automatisée, de l’onboarding self-service et une exigence de fiabilité bien supérieure — une panne touche tous les clients à la fois, pas une seule entreprise. C’est le bon choix quand l’ambition est de vendre le même outil à de nombreux clients, pas de résoudre le problème d’une seule organisation.

Quel effort pour chacun, en ordre de grandeur ?

Sans donner de chiffres — chaque projet a ses spécificités — voici l’ordre de grandeur relatif à garder en tête :

  • Site vitrine : l’échelle est celle de quelques semaines. Le périmètre est borné, le contenu est connu à l’avance, il n’y a pas de logique applicative complexe à concevoir.
  • Application métier : l’échelle passe en semaines à mois, selon la complexité du processus à automatiser et le nombre d’intégrations avec les outils existants (facturation, CRM, agenda…).
  • SaaS : l’échelle se compte en mois, et le travail ne s’arrête jamais vraiment. Au-delà du développement initial, il faut prévoir l’authentification multi-organisation, la facturation récurrente, le support client, et une charge d’exploitation continue qui grandit avec chaque nouveau client.

Un SaaS coûte structurellement plus cher à construire et à opérer qu’une application métier qui rendrait le même service à une seule entreprise. C’est le prix de la mutualisation — justifié seulement s’il y a vraiment plusieurs clients à mutualiser.

Les questions à se poser avant de trancher

Avant de lancer un projet, un dirigeant devrait pouvoir répondre clairement à ces questions :

  1. Qui va utiliser l’outil ? Un public large et anonyme (site vitrine), une équipe interne identifiée (application métier), ou plusieurs entreprises clientes indépendantes (SaaS) ?
  2. Le besoin est-il vraiment récurrent chez d’autres entreprises, ou est-il spécifique à la façon de fonctionner de la mienne ?
  3. Suis-je prêt à assumer un rôle d’éditeur logiciel — support, facturation, mises à jour continues, engagement de disponibilité — ou est-ce que je veux juste un outil qui marche pour mon équipe ?
  4. Ai-je vraiment besoin d’une logique applicative, ou est-ce que je cherche avant tout à être visible et à générer des contacts ?

Quand ne surtout pas faire un SaaS ?

Le SaaS est le format le plus valorisé dans l’imaginaire entrepreneurial — et le plus souvent choisi pour de mauvaises raisons. Trois signaux doivent alerter :

  • Le besoin n’est pas validé au-delà de sa propre organisation. Construire une architecture multi-tenant pour un seul client réel, c’est payer le coût de la généralité sans en tirer le bénéfice. Une application métier suffit, et coûte nettement moins cher à construire et à opérer.
  • Il n’y a pas de capacité à assumer le support et l’exploitation dans la durée. Un SaaS mal opéré — pannes non détectées, support absent — abîme la confiance des clients plus vite qu’il ne la construit.
  • Le marché n’a pas encore confirmé qu’il y a une vraie demande répétée. Il est souvent plus sain de démarrer par une application métier pour un premier client, de valider que le besoin se retrouve ailleurs, puis de généraliser vers un SaaS une fois la demande prouvée — plutôt que de construire la généricité avant d’avoir vendu quoi que ce soit.

Le bon réflexe n’est pas de choisir le format le plus ambitieux, mais celui qui correspond exactement à la taille du problème à résoudre aujourd’hui.

Un projet ? Parlons-en.

30 minutes pour cadrer votre besoin — réponse honnête, même si c’est « vous n’avez pas besoin de nous ».

Réserver un appel