Software as a Service (SaaS)

Vous avez déjà utilisé du SaaS aujourd'hui

Vous n'avez pas installé de serveur de messagerie ce matin. Vous n'avez pas patché un système d'exploitation, provisionné de machine virtuelle ni écrit une ligne de code. Vous avez tapé un mot de passe dans un navigateur, et votre boîte de réception était déjà là, tournant sur du matériel que vous n'avez jamais vu, maintenu par une équipe que vous n'avez jamais rencontrée. C'est ça, le Software as a Service, et contrairement aux 2 dernières leçons, vous l'avez presque certainement utilisé avant même de finir votre petit-déjeuner.

La définition du NIST, en pratique

Le NIST définit SaaS comme la capacité "d'utiliser les applications du fournisseur tournant sur une infrastructure cloud", accessibles "via une interface client léger, comme un navigateur web... ou une interface de programmation". Le consommateur ne gère ni ne contrôle l'infrastructure cloud sous-jacente, y compris le réseau, les serveurs, les systèmes d'exploitation, le stockage, ni même les capacités individuelles de l'application, à l'exception possible de paramètres de configuration limités et propres à l'utilisateur.

Cette exception fait un vrai travail dans la phrase. Vous ne pouvez pas installer un plugin sur les serveurs de Gmail ni changer le langage dans lequel Salesforce est écrit. Vous pouvez créer un filtre d'e-mail ou personnaliser un tableau de bord Salesforce. L'application elle-même, et tout ce qui est en dessous, appartient entièrement au fournisseur.

Qui gère quoi, version complète

Les données et votre propre configuration sont la seule ligne qui ne bouge jamais. Toutes les autres couches finissent par passer au fournisseur une fois que vous arrivez au SaaS.

Le multi-tenant : l'architecture qui rend cela abordable

Un éditeur SaaS ne fait pas tourner une copie séparée de Gmail pour chacun de ses milliards d'utilisateurs. Gartner décrit le multi-tenant comme un logiciel où une seule instance sert plusieurs clients, isolés logiquement les uns des autres tout en partageant physiquement la même infrastructure en dessous. Votre boîte de réception et celle d'un inconnu tournent sur la même instance d'application, les mêmes serveurs, le logiciel du fournisseur garantissant que ni l'un ni l'autre ne peut voir les données de l'autre.

Ce partage est exactement ce qui rend le prix du SaaS possible. Répartir une seule instance d'application entre des millions de tenants coûte nettement moins cher par client que de faire tourner une copie dédiée pour chacun, ce qui explique pourquoi un abonnement SaaS coûte généralement une fraction du prix de construire et d'héberger la même application soi-même.

Des produits réels, par catégorie

L'idée fausse : un abonnement n'est pas la même chose qu'un SaaS

Il est tentant d'appeler "SaaS" tout ce qui est facturé mensuellement. Ce n'est pas exact. Une application en boîte que vous installez sur votre propre ordinateur, et que vous maintenez vous-même à jour, ne devient pas du SaaS juste parce que sa licence se renouvelle chaque mois. Le test n'est pas le mode de facturation, c'est qui la fait tourner et où. Si le fournisseur héberge, patche et exploite l'application sur une infrastructure que vous ne touchez jamais, et que vous y accédez via un navigateur ou une API, c'est du SaaS. Si vous l'avez installée vous-même et que c'est vous qui appliquez ses mises à jour, ce n'en est pas, peu importe la manière dont arrive la facture.

Où cela vous mène

SaaS marque la fin du transfert commencé avec IaaS : le fournisseur fait maintenant tourner le système d'exploitation, le runtime et l'application elle-même, et il ne vous reste que vos données et vos propres paramètres de votre côté de la ligne. Vous avez maintenant rencontré les 3 modèles de service individuellement. La prochaine leçon les met côte à côte et vous donne la frontière qu'un examen teste vraiment : pas ce que chacun est, mais lequel un scénario décrit.