Le mot livré devient bizarre avec le SaaS. Dans un logiciel installé, une version part sur un CD et chaque client choisit son moment. Dans un service Web, le fournisseur garde le code, les serveurs et le déploiement. La même centralisation simplifie les versions et concentre les erreurs.

Je ne prétends pas exploiter moi-même une grande plateforme SaaS. Comme architecte, je peux tout de même décomposer le modèle. Une requête arrive au serveur Web avec l’identité d’un utilisateur. L’application détermine son organisation, charge sa configuration, applique les règles et lit des données qui doivent rester séparées de celles des autres clients.

navigateur -> équilibrage -> application -> contexte du client
                                      |-> base partagée avec tenant_id
                                      `-> logs, files et surveillance

Une base partagée peut placer un tenant_id sur chaque ligne. Cette approche utilise bien les ressources, mais chaque requête doit inclure la frontière.

SELECT id, statut, total
FROM commandes
WHERE tenant_id = @tenant
  AND id = @commande;

Oublier le premier prédicat peut exposer la commande d’un autre client. Je cacherais donc ce filtre dans la couche d’accès aux données, utiliserais l’identité de session côté serveur plutôt qu’un tenant_id fourni librement par le navigateur, et ajouterais des tests qui tentent explicitement de traverser la frontière.

Déployer une version commune sans tout casser

Une modification de schéma doit fonctionner pendant la transition. Pour renommer une colonne, on peut d’abord ajouter la nouvelle, écrire dans les deux, migrer les anciennes lignes, faire lire la nouvelle version, puis retirer l’ancienne plus tard. Une seule opération brutale rend le retour arrière difficile si des millions de lignes sont déjà transformées.

Je déploierais d’abord à un petit groupe ou à une instance, vérifierais les erreurs et garderais l’ancienne version prête. Le code et le schéma doivent être compatibles assez longtemps pour éviter qu’un serveur ancien et un serveur nouveau interprètent différemment la même donnée.

Les tâches longues passent par une file. Une demande d’export peut être enregistrée, exécutée par un worker et signalée lorsqu’elle est prête. Si le worker tombe, le message doit revenir dans la file; l’opération doit reconnaître qu’un export existe déjà pour ne pas en créer dix. La file, sa profondeur et l’âge du plus vieux message deviennent des mesures de service.

Le SaaS transforme aussi le soutien. Il faut suivre le temps de réponse par client, les erreurs, la capacité et les changements déployés. Un taux global de 99,9 % peut cacher un client bloqué par une configuration particulière. Les logs doivent contenir un identifiant de requête et de client sans recopier inutilement des données sensibles.

Enfin, le client doit pouvoir partir. Je vérifierais un export complet, documenté et relisible sans l’application. Le contrat précise la rétention, les sauvegardes, la suppression et l’avis après incident. Une interface Web ne remplace pas ces garanties.

Le produit continue donc après le build : isolation à chaque requête, migration compatible, reprise des travaux, surveillance et export. Une version commune est un avantage seulement si l’équipe peut la déployer et la retirer sans transformer tous les clients en testeurs involontaires.