Une équipe trouve un service Web, démarre un essai et commence à travailler. Quand la demande d’achat arrive enfin, le logiciel contient déjà des clients, des commentaires et des pièces jointes. Le SaaS inverse l’ordre traditionnel : l’usage peut précéder l’analyse des données, des accès et de la sortie.

Le navigateur parle au service par HTTPS. Le fournisseur associe le compte à un tenant, c’est-à-dire un espace logique pour l’organisation. Dans une architecture multi-tenant, plusieurs clients partagent l’application et parfois les mêmes tables, avec une clé tenant_id qui doit filtrer chaque requête. Cette mutualisation rend les mises à jour et les coûts efficaces, mais une erreur d’isolation peut exposer un client à un autre.

Faire l’inventaire avant de signer

Je demanderais à l’équipe de parcourir une opération réelle :

1. un administrateur invite un employé;
2. l’employé importe un fichier de clients;
3. il partage un dossier avec un partenaire;
4. un autre utilisateur modifie une donnée;
5. le premier compte est désactivé;
6. l’organisation exporte tout ce qui reste.

Ce parcours révèle l’identité, les rôles, l’historique, le partage et la portabilité. Un bouton CSV peut exporter les champs simples mais oublier commentaires, fichiers, relations ou journaux. Il faut ouvrir l’export et tenter une reconstruction, pas seulement croire son existence.

Le compte propriétaire est un risque. S’il appartient à une personne qui quitte, le renouvellement, la facturation et les accès peuvent être bloqués. J’utiliserais un compte organisationnel, plusieurs administrateurs nommés, une authentification forte et un processus de révision des membres. Le SSO réduit les comptes séparés lorsque le fournisseur le supporte; le retrait doit réellement couper les sessions existantes.

Le contrat doit couvrir la fin

La disponibilité ne dit rien sur la récupération d’une suppression. Je chercherais les sauvegardes, leur rétention, le délai de restauration et le coût. La localisation des données, les sous-traitants, le chiffrement, la notification d’incident et les limites d’API appartiennent aussi à la décision.

Le fournisseur déploie souvent une version pour tous. C’est une force du SaaS, mais une modification d’interface ou d’API peut casser un processus. Un environnement de test, un avis de changement et quelques tests automatisés sur les fonctions critiques réduisent la surprise. Si le service ferme ou double son prix, la procédure de sortie doit nommer le format, le délai et le système qui recevra les données.

Je ne veux pas remettre six mois d’approbation devant un essai de dix dollars. Je mettrais plutôt un catalogue à trois niveaux : outil sans données sensibles, outil avec données internes, système critique. Chaque niveau déclenche des contrôles proportionnés et une date de révision.

Le SaaS retire beaucoup de plomberie, pas le cycle de vie. Avant qu’un essai contienne le seul exemplaire d’un dossier important, je veux savoir qui possède le compte, qui peut lire, comment on récupère et comment on part.