Il y a un changement qui se passe sous nos yeux pis qui est plus profond qu’il en a l’air: le logiciel arrête de s’installer pis commence à se louer. Le SaaS — le logiciel servi par le web, payé à l’abonnement — casse une série de vieux réflexes qu’on tenait pour acquis depuis vingt ans. En mai 2008, ça me touche personnellement: je suis en train de regarder vers ce monde-là de proche, pis plus je creuse, plus je vois à quel point ça rebrasse la game, pas juste la technique.

Le premier réflexe qui saute, c’est l’installation. Avant, livrer un logiciel, c’était graver un CD, le déployer sur des postes, gérer les versions client par client. Avec le SaaS, il y a une seule version, qui roule chez le fournisseur, pis tout le monde l’utilise par le navigateur. Quand on corrige un bogue, il est corrigé pour tout le monde le matin même. C’est libérateur côté maintenance, mais ça vient avec une responsabilité écrasante: si ça brise, ça brise pour tous les clients en même temps.

flowchart LR
    subgraph Avant[Logiciel installe]
    A[Version 1.2 chez client A]
    B[Version 1.0 chez client B]
    C[Version 1.4 chez client C]
    end
    subgraph SaaS[Logiciel servi]
    D[Une seule version] --> E[Tous les clients<br/>en meme temps]
    end

Le deuxième réflexe qui change, c’est la relation avec le client. Quand on vendait une licence, la vente était la fin de l’histoire. Avec l’abonnement, la vente est juste le début. Le client peut partir à la fin du mois s’il n’est pas content. Ça veut dire que le produit doit être bon en continu, pas juste le jour de la démo. On ne vend plus un logiciel, on loue un service qu’il faut mériter chaque mois. Ça discipline une équipe d’une manière que la vente de licence ne faisait pas.

Côté technique, le SaaS impose des affaires que le logiciel installé pardonnait. La disponibilité devient sacrée — un client ne peut pas « attendre le redémarrage de ce soir », il veut que ça marche là, maintenant. Le multi-tenant (plusieurs clients sur la même infrastructure) oblige à isoler les données proprement, parce qu’une fuite entre deux clients, c’est la fin de la confiance. Et la montée en charge n’est plus le problème du client, c’est le nôtre.

Le piège que je vois, c’est de prendre un vieux logiciel pensé pour être installé pis de juste le « mettre sur le web ». Ça ne marche pas. Le SaaS, ce n’est pas un mode de livraison qu’on ajoute à la fin; c’est une façon de concevoir dès le départ — pour la disponibilité, pour le multi-client, pour la mise à jour continue. Bâtir ça par-dessus une vieille architecture, c’est se construire une dette qui va faire mal.

Ce qui me fascine, c’est l’effet sur la culture d’équipe. Quand le produit est servi en continu, le développement, l’exploitation pis le support ne peuvent plus vivre en silos. Le monde qui code doit penser à ce qui se passe à trois heures du matin quand ça plante. La frontière entre « bâtir » pis « faire rouler » s’efface, pis je trouve ça sain — ça force tout le monde à se sentir responsable du résultat réel, pas juste de sa petite portion.

Ce que je retiens en ce printemps 2008, c’est que le SaaS n’est pas juste une nouvelle façon de vendre du logiciel. C’est un changement de contrat avec le client, de discipline pour l’équipe, pis de manière de concevoir. Les vieux réflexes — installer, livrer une version, oublier — ne tiennent plus. Pis personnellement, c’est exactement le genre de virage qui me donne le goût de m’en rapprocher pour le vivre de l’intérieur.

La suite, je la vois claire: arrêter de penser « logiciel qu’on installe » pis commencer à penser « service qu’on fait vivre ». Disponibilité, isolation des données, mise à jour continue, responsabilité partagée. C’est plus exigeant, mais c’est aussi plus honnête — parce que dans le SaaS, on ne peut pas se cacher derrière la version vendue l’an passé. On est jugé sur ce qui marche aujourd’hui.