Choisir un SaaS : critères d’exigences, évaluation et décision

Le SaaS est un modèle opérationnel, pas seulement un mode d’acquisition

Utiliser le SaaS ne signifie pas acheter un logiciel au sens classique, mais souscrire à un service continu. Le fournisseur exploite l’application, fournit les mises à jour et prend en charge l’assistance et la formation ; la solution est hautement disponible et accessible depuis n’importe quel appareil connecté à Internet, où que l’on soit. L’enjeu de la décision se déplace ainsi : ce qui compte n’est pas l’installation, mais l’exploitation durable.

Comme le fournisseur assume la responsabilité de l’exploitation, les priorités changent : le modèle opérationnel, la qualité de service et la dépendance pèsent plus lourd que pour un logiciel installé localement, dont l’exploitation, la maintenance et les actualisations sont gérées en interne. Le choix ne se fonde donc pas uniquement sur les fonctionnalités, mais aussi sur la manière dont le service sera fourni de façon fiable, sécurisée et prévisible tout au long du contrat.

La logique des coûts évolue également : les plateformes SaaS basées sur le cloud remplacent les dépenses d’investissement par des charges d’exploitation assorties de modèles tarifaires prévisibles et d’une réduction des efforts de maintenance informatique (Philips). Ce n’est pas l’acquisition ponctuelle qui prime, mais les dépenses récurrentes. Cela rend la comparaison des offres plus complexe, mais abaisse la barrière à l’entrée.

De ses propres processus aux exigences

Les exigences découlent de son propre fonctionnement, non d’une liste de fonctions. Forterro considère comme déterminant qu’une solution corresponde au secteur d’activité, à la taille de l’entreprise, au pays, à la complexité des processus et à l’axe métier principal – qu’il s’agisse de commerce, de production, de distribution, de finance, de gestion de projets ou de fabrication industrielle. Un système cloud destiné aux entreprises commerciales met l’accent sur d’autres aspects qu’un système dédié à une production orientée projets.

La démarche pratique passe par l’analyse de ses propres flux : consigner les processus clés dans leur ordre réel, noter les volumes et le nombre de documents, identifier les rôles impliqués, définir les points de transfert vers d’autres systèmes et décrire les exceptions qui génèrent des efforts au quotidien. On peut ensuite en déduire des critères obligatoires, souhaitables et optionnels vérifiables.

Un catalogue de critères sans lien avec ses propres processus ne sert pas de base décisionnelle solide. Chaque fournisseur y répondrait de manière similaire, et le débat glisserait vers des questions secondaires pour l’exploitation. Il est donc utile de relier chaque critère au processus qu’il doit améliorer – et d’écarter ceux qui n’ont aucun lien concret.

Cloud natif ou option cloud ajoutée a posteriori

Le modèle opérationnel constitue un critère d’évaluation à part entière. Forterro juge décisif de savoir si une solution a été développée dès le départ comme un ERP cloud ou si un système ERP éprouvé est proposé en supplément dans un mode cloud. La présentation citée classe Myfactory comme un ERP purement cloud ; Abas, Jeeves, Sylob, ProConcept et Orderwise proposent leurs solutions cloud en complément d’offres ERP établies. Cette distinction vaut la peine car elle révèle dans quelle mesure un produit est conçu pour une exploitation durable.

Au modèle opérationnel se rattachent les questions qui rythment le quotidien : coûts prévisibles, concepts de sécurité professionnels, haute disponibilité et infrastructure évolutive. Pour l’exploitation cloud, Abas mentionne notamment la transparence des coûts, les sauvegardes automatisées, les correctifs, la surveillance, la sécurité, la disponibilité et une infrastructure évolutive.

Pour l’évaluation, cela implique de poser des questions concrètes : où sont stockées les données, comment les failles de sécurité sont-elles comblées, à quelle fréquence les mises à jour sont-elles effectuées, comment les sauvegardes sont-elles créées et restaurées, quel niveau de disponibilité est garanti, comment la mise à l’échelle est-elle gérée en cas de croissance et qui intervient dans quels délais en cas d’incident ? Les réponses montrent dans quelle mesure la charge interne en TI change réellement – et si le soulagement promis par le modèle se concrétise.

L’ouverture technique comme critère d’évaluation

Pour l’évaluation technique, on peut formuler des critères vérifiables : le logiciel devrait être utilisable via un navigateur et idéalement disposer d’une application mobile, l’entreprise devrait pouvoir configurer elle-même tout ce dont elle a besoin et des adaptations plus poussées devraient être possibles grâce à des fonctions NoCode ou LowCode. S’y ajoutent une API Web polyvalente et bien documentée pour les intégrations, des déclencheurs et actions standards pour les principales plateformes d’intégration NoCode comme Zapier et Make, ainsi que la possibilité d’exporter à tout moment toutes les données dans des formats pertinents (topsoft).

Ces points déterminent l’utilisabilité à long terme. Un compte que l’on peut ouvrir en ligne sans intervention du fabricant est une promesse différente d’une solution où chaque modification passe par le fournisseur. Celui qui configure lui-même et effectue des connexions via des interfaces documentées conserve sa capacité d’action lorsque les processus évoluent ou que d’autres systèmes s’ajoutent.

Un regard sur le marché suisse montre pourquoi il faut examiner cette question de près. Dans l’aperçu du marché de topsoft, en restreignant la sélection aux critères « client dans le navigateur » et « cloud », il ne restait plus que 18 produits de 12 fournisseurs sur 2253 produits de 960 fournisseurs ; une API REST était proposée par 51 produits de 35 fournisseurs. L’exportation des données n’est donc pas une condition accessoire, mais une assurance de sortie.

Aperçu du marché : Ouverture technique des solutions SaaS en Suisse

Profondeur dans sa niche plutôt que largeur fonctionnelle

Une solution qui couvre tout pour tout le monde devient rarement indispensable. Une analyse du marché suisse du SaaS résume bien le principe : vouloir être tout pour tous rend inutile pour personne.

En revanche, celui qui s’adresse à un secteur réglementé avec un savoir-faire technique spécifique construit une position qu’un généraliste peut difficilement reproduire (Scalemetrics). La source cite à titre d’exemple Exnaton, qui se concentre sur la tarification dynamique et la facturation énergétique assistée par IA pour les fournisseurs d’énergie, et a intégré dans son produit les exigences de conformité telles que l’ElCom et l’ENTSO-E – des domaines où, selon la source, les solutions SaaS génériques échouent.

On peut en déduire deux critères de contrôle. Premièrement : les connaissances sectorielles et les exigences de conformité spécifiques au secteur sont-elles ancrées dans le produit, plutôt que proposées comme prestation de conseil séparée ? La conformité peut être un motif d’achat pour certains groupes de clients, pas seulement un obstacle. Deuxièmement : le fournisseur peut-il présenter des déploiements avérés chez des clients comparables ? L’analyse mentionnée cite pour Exnaton des projets pilotes démontrés auprès de fournisseurs d’énergie avant le tour de financement – un signal de résolution réelle de problèmes plutôt que de simples annonces.

Pour la décision de sélection, il en résulte ceci : une longue liste de fonctionnalités n’a pas de valeur en soi. Celui qui résout vraiment un problème circonscrit dans son secteur maintient le savoir-faire dans le produit et pas seulement dans le discours commercial.

Critères pour le choix d’un fournisseur SaaS sur le marché suisse

Rendre comparables les coûts, les bénéfices et les risques

L’évaluation doit inclure les charges d’exploitation prévisibles au lieu des dépenses d’investissement, ainsi que la réduction des efforts de maintenance. Selon Philips, les plateformes SaaS basées sur le cloud permettent une mise à l’échelle rapide sans nouveau matériel, transforment les investissements en charges d’exploitation et réduisent la charge de maintenance informatique. Ces effets doivent figurer dans le calcul – non pas comme hypothèse, mais comme poste chiffré.

La comparaison porte sur toute la durée du contrat, pas seulement sur la première année. Outre les coûts de licence ou d’abonnement, il faut comptabiliser le déploiement, la migration des données, les interfaces, la formation, d’éventuelles adaptations et la charge interne de suivi. Seule cette vue d’ensemble permet de comparer deux offres et montre si le soulagement promis pour l’informatique interne se réalise.

Il faut accorder la même attention aux risques : protection des données et cybersécurité, intégration dans les systèmes existants, dépendance vis-à-vis du fournisseur, ainsi que scénarios de sortie et portabilité des données. Philips souligne que les fournisseurs de SaaS dans le secteur de la santé doivent garantir le respect des exigences HIPAA et RGPD grâce au chiffrement et à la gestion des données ; Philips indique en arrière-plan que seulement 47 % des données sensibles sont stockées dans le cloud, contre 61 % dans d’autres secteurs. Pour les entreprises suisses, il convient de clarifier avant la signature ses propres prescriptions en matière de protection des données, le lieu de stockage des données et la restitution contractuellement garantie des données.

Avantages et risques de l’utilisation du SaaS dans le secteur de la santé suisse

Préparer la décision et sécuriser le déploiement

Le processus décisionnel suit une logique simple : pondérer les critères, évaluer les offres selon cette pondération, réaliser une phase de test limitée avec des données réelles et des cas d’utilisation concrets, et impliquer les services concernés. Ceux qui n’associent pas les utilisateurs tôt prennent une décision qui ne sera pas soutenue au quotidien.

La décision elle-même doit être documentée : quels critères, avec quelle pondération, ont fait la différence, quels fournisseurs ont été écartés et pour quelles raisons, et quelles conditions restent à remplir avant la signature du contrat. Ce n’est pas une fin en soi – la documentation rend la décision compréhensible ultérieurement, lorsque les exigences changent ou qu’un changement est envisagé.

La sélection ne s’achève pas avec la signature du contrat. Du point de vue des fournisseurs, les mises à jour régulières du produit et le développement continu sont essentiels pour satisfaire les utilisateurs et les lier plus longtemps à l’entreprise. Pour l’utilisatrice, c’est l’autre face de la même médaille : la pertinence du choix au quotidien se révèle ensuite – dans l’entretien du produit, dans son évolution et dans l’adoption du service par les utilisateurs.

Étapes pour une décision de sélection SaaS fondée