SaaS

SaaS signifie Software as a Service, ou logiciel en tant que service. L’utilisateur accède à une application exploitée par un fournisseur, généralement par réseau. Le contrat et l’offre définissent les fonctions, les limites et les conditions d’utilisation. Un abonnement est fréquent, mais le modèle ne se résume pas au mode de facturation.

L’entreprise utilise le logiciel sans exploiter nécessairement ses serveurs. Elle conserve toutefois des responsabilités : configuration des comptes, qualité des données, droits et processus de travail. Le fournisseur ne décide pas automatiquement qui doit avoir accès à chaque dossier ni comment l’équipe valide une opération.

Le fournisseur gère l’application selon son périmètre. L’entreprise doit vérifier les tâches incluses : maintenance, mises à jour, disponibilité et assistance. Les engagements dépendent du contrat. Une interface accessible ne signifie pas que chaque fonction ou intégration est couverte par le même niveau de service.

Les utilisateurs et les administrateurs gèrent les données et les autorisations selon les fonctions disponibles. Un compte partagé peut compliquer la traçabilité. Des rôles adaptés facilitent le contrôle. Prévoyez l’arrivée, le changement de fonction et le départ des personnes.

Une application installée localement peut demander une exploitation interne ou confiée à un prestataire. Un SaaS déplace une partie de cette exploitation chez son fournisseur. Le choix doit comparer les besoins, les dépendances et les responsabilités sur un périmètre similaire.

Une intégration par API ou connecteur peut ajouter des fonctions d’analyse. Elle ne supprime pas les règles du SaaS. Vérifiez les opérations exposées, les limites de l’offre et les permissions. Une option annoncée dans une autre formule peut ne pas être disponible pour votre compte.

Imaginons une PME qui choisit un SaaS pour suivre ses demandes internes. Elle définit les rôles, les catégories et les règles de clôture. Elle importe un ensemble de test, puis contrôle les accès avec plusieurs profils.

L’équipe vérifie aussi l’export des données et la récupération d’une information supprimée. Si un assistant IA consulte l’application, il doit utiliser les mêmes droits et les mêmes définitions de statut. Les brouillons ou propositions ne doivent pas devenir des opérations confirmées sans validation.

Ce scénario est illustratif. Une démonstration générale ne suffit pas : le test doit couvrir les fonctions quotidiennes, les erreurs et la sortie du service. L’équipe doit connaître les opérations qu’elle peut réaliser et celles qui nécessitent une intervention du fournisseur.

Le contrat doit permettre de comprendre les lieux de traitement, les destinataires et les règles de conservation. Vérifiez les possibilités de suppression et les conditions après résiliation. Révoquer une intégration et fermer un abonnement ne sont pas nécessairement la même opération.

L’export mérite un essai. Un fichier récupéré peut perdre les pièces jointes, les liens ou les informations nécessaires à son interprétation. Vérifiez ce qu’il contient et comment il sera réutilisé. Une réversibilité annoncée doit correspondre aux données et au processus qui comptent pour l’entreprise.

Les tarifs peuvent dépendre des utilisateurs, des fonctions ou des volumes. Les intégrations et les options peuvent modifier le budget. Comparez les mêmes périmètres et indiquez les hypothèses au lieu de retenir uniquement un prix d’entrée.

Une interruption peut venir du SaaS, de la connexion ou d’un service d’identité. Définissez un mode dégradé pour les usages essentiels. Les engagements contractuels et les possibilités pratiques de continuer le travail doivent être examinés séparément.

Le partage et les invitations doivent être vérifiés avec les rôles retenus. Un lien public, un accès externe et une invitation nominative ne présentent pas le même périmètre. Testez les restrictions et la suppression d’un partage. Conservez les règles qui précisent qui peut inviter une personne et quelles informations peuvent être diffusées. Cette configuration doit évoluer lorsque l’équipe ou les usages changent.

Décrivez les tâches, les utilisateurs et les données nécessaires. Préparez un test avec vos règles métier, sans importer inutilement des informations sensibles. Vérifiez les rôles, les limites de l’offre et les fonctions de récupération.

Comparez les responsabilités et les conditions contractuelles. Identifiez les opérations qui resteront à la charge de l’équipe. Testez un export et le départ d’un utilisateur avant de considérer le service comme intégré au fonctionnement courant.

Documentez les administrateurs, les connexions et les règles de conservation. Prévoyez la sortie et les situations d’indisponibilité. Après une évolution de l’offre ou des fonctions, revoyez les permissions et les procédures qui en dépendent.

Le modèle SaaS est décrit dans la définition du cloud du NIST.

Référence consultée le 10 octobre 2026.