SaaS (Software as a Service)

Qu'est-ce que le SaaS ?

SaaS signifie Software as a Service, logiciel en tant que service. Vous vous abonnez à un logiciel que quelqu'un d'autre exploite, au lieu d'acheter une licence et de l'installer sur des machines dont vous répondez.

Le navigateur n'est pas le trait déterminant, même s'il est le plus visible. Beaucoup de produits SaaS ont des clients bureau et mobile, et beaucoup de logiciels auto-hébergés tournent dans un navigateur. Ce qui distingue vraiment le SaaS, c'est le partage des responsabilités. L'éditeur exploite les serveurs, applique les mises à jour, effectue les sauvegardes, corrige les vulnérabilités et s'engage sur la disponibilité. Vous restez responsable de vos données, de vos processus, de vos utilisateurs et de leurs droits.

Vu ainsi, l'abonnement n'est pas une facilité de paiement. C'est le prix du transfert d'un ensemble d'obligations opérationnelles vers quelqu'un dont c'est le métier à plein temps. Pour une entreprise dont l'activité n'est pas d'exploiter des serveurs, c'est en général un bon échange. Ce qui mérite examen, c'est ce qui revient en sens inverse.

Pourquoi le SaaS est important

• La responsabilité opérationnelle se déplace. Personne chez vous n'a à planifier une montée de version, surveiller un espace disque ou appliquer un correctif de sécurité à vingt-deux heures. Pour une entreprise sans équipe système, c'est tout l'argument.
• Le coût devient prévisible et immédiat. Un abonnement remplace un achat immobilisé, ce qui change la façon dont la décision est approuvée et raccourcit le délai entre la décision et l'usage.
• Le délai de mise en service s'effondre. Démarrer prend un après-midi plutôt qu'un projet, ce qui rend raisonnable de tester sérieusement un outil avant de s'engager.
• Vous héritez de changements que vous n'avez pas choisis. La contrepartie, rarement inscrite sur la page tarifaire. L'éditeur décide quand une fonction change, quand une interface est refondue et quand un comportement disparaît. Votre équipe absorbe cela à son calendrier.
• Le coût s'accumule discrètement. Un tarif par utilisateur qui paraît dérisoire à dix se comporte autrement à quatre-vingts, et une entreprise revisite rarement un abonnement approuvé trois ans plus tôt. Le total sur cinq ans est le chiffre qui compte et presque personne ne le calcule.

Pour une entreprise belge il existe désormais un test concret de cet échange. La facturation électronique structurée est obligatoire pour les opérations B2B nationales depuis le 1er janvier 2026, et savoir si un outil en abonnement gère correctement l'émission et la réception relève de la conformité et non du confort. C'est aussi une bonne illustration du modèle : quand l'obligation est arrivée, les utilisateurs de SaaS ont généralement reçu la fonction, tandis que les utilisateurs auto-hébergés ont dû planifier une mise à niveau.

Comment ça fonctionne

Quatre mécanismes se retrouvent derrière presque tout produit SaaS.

La multi-location. Une seule application en fonctionnement sert de nombreux clients, avec des données séparées par conception plutôt que par une copie par client. C'est ce qui rend l'économie du modèle viable, et c'est aussi pourquoi vous ne pouvez pas demander à rester sur une version pendant que les autres avancent.

Le déploiement continu. Les mises à jour arrivent quand l'éditeur les publie, souvent chaque semaine, parfois chaque jour. Il n'y a pas de projet de montée de version, et il n'y a pas non plus de choix sur le moment.

L'abonnement compté. La facturation suit les utilisateurs, l'usage, le volume ou une combinaison. La dimension retenue vous dit où le coût croîtra si vous réussissez, et elle mérite plus d'attention que le prix affiché.

L'engagement de service. Un SLA indique la disponibilité promise et ce qui se passe quand elle n'est pas tenue. Lisez la réparation réellement prévue : un avoir sur la facture du mois suivant est courant, et il ne compense pas une journée d'activité arrêtée. Le SLA décrit l'exposition de l'éditeur, pas la vôtre.

Mise en œuvre

Deux situations très différentes se cachent derrière le même mot, la liste se dédouble donc.

Si vous achetez du SaaS, quatre questions pèsent plus lourd que la démonstration.

1. Comment récupérez-vous vos données ? Pas seulement si un export existe, mais s'il contient l'historique et les relations, et si vous pouvez le lancer vous-même aujourd'hui. Testez-le pendant l'essai.
2. Qu'est-ce qui fait gonfler la facture ? Utilisateurs, enregistrements, stockage, appels. Modélisez le coût à trois fois votre taille actuelle, puisque c'est le scénario où l'outil a réussi.
3. Que vous donne réellement le SLA ? Un avoir n'est pas une indemnisation. Confrontez l'engagement à ce que coûterait vraiment une journée d'indisponibilité.
4. Y a-t-il une API, et est-elle incluse ? C'est ce qui décide si l'outil peut se connecter à l'existant, et si partir plus tard sera un projet ou un calvaire.

Si vous construisez du SaaS à partir d'un outil interne, l'avertissement honnête est que l'application qui fonctionne est la plus petite moitié.

1. La multi-location est une refonte, pas un réglage. Séparer données, droits et paramétrage par client touche au modèle de données, et le rétrofiter coûte bien plus cher que de le concevoir ainsi.
2. Facturation, essais et relances sont un produit à part entière. Abonnements, prorata, paiements échoués et résiliations sont ingrats et inévitables.
3. Le support devient une fonction. Un outil interne a des utilisateurs que vous connaissez par leur prénom. Un produit a des clients avec des attentes, des délais de réponse et un canal que quelqu'un doit tenir.
4. La disponibilité devient une promesse. Dès que vous vendez un SLA, il faut de la supervision, une astreinte et un plan pour la nuit où la base sature.
5. Validez la demande avant de construire la plateforme. L'échec le plus fréquent est un produit techniquement excellent pour lequel trois entreprises étaient prêtes à payer, découvert après la refonte multi-locataire plutôt qu'avant.

Technologies et outils liés

• Multi-location : l'architecture qui permet à une instance de servir de nombreux clients avec des données isolées, principale différence technique entre un outil interne et un produit.
• API : l'interface qui décide si l'outil s'intègre à vos autres systèmes, et ce que vous pourrez emporter en partant.
• Dépendance fournisseur : le coût accumulé du départ, déterminé par la portabilité des données, la profondeur des intégrations et la part de vos processus qui vit désormais chez quelqu'un d'autre.
• SLA : l'engagement de disponibilité et sa réparation, généralement plus mince que les acheteurs ne le supposent.
• Plateformes de facturation récurrente : les services qui gèrent plans, prorata, échecs de paiement et factures, un travail que vous ne voulez pas écrire vous-même.

Conclusion

Le SaaS est un transfert de responsabilité opérationnelle, facturé au mois. Pour la plupart des entreprises c'est un bon échange, et le modèle s'est imposé pour de vraies raisons plutôt que par effet de mode. Les deux points à surveiller sont ceux que personne n'inscrit sur une page tarifaire : le total sur cinq ans, que la tarification par utilisateur dissimule bien, et la sortie, qui n'est jamais plus simple que l'export de données que vous avez testé avant de signer.

Pour une entreprise qui envisage d'en construire un, le recadrage utile est que le SaaS est un modèle d'affaires et non une méthode de déploiement. L'application est nécessaire et insuffisante. Ce qui fait tenir l'ensemble, c'est une multi-location conçue dès le départ, une facturation qui gère les cas pénibles, un support réellement tenu, et la preuve que des clients paieront avant que la plateforme ne soit construite.

• OpenAPI Initiative, la spécification derrière les interfaces documentées qui déterminent la portabilité réelle d'un outil en abonnement.
• Les exceptions à l'obligation belge de facturation électronique, Wolters Kluwer, utile pour vérifier si un outil en abonnement couvre votre cas de conformité.