Ça fait un boutte que j’entends parler du « nuage » dans les présentations de fournisseurs, pis honnêtement, longtemps ça sonnait comme un mot à la mode pour dire « le serveur de quelqu’un d’autre ». Mais en mars 2008, je commence à voir le cloud quitter la slide pis entrer dans le vrai. Amazon loue de la capacité de calcul à l’heure, du stockage qui s’étire tout seul, pis on peut monter une machine en quelques minutes sans appeler personne ni signer un bon de commande. Comme architecte, c’est ça qui m’accroche: ce n’est plus une idée, c’est une affaire qu’on peut utiliser aujourd’hui.

Ce qui change, ce n’est pas juste où vit le serveur. C’est le modèle au complet. Avant, pour avoir un serveur, on l’achetait, on le rackait, on l’amortissait sur trois ans, pis on priait pour avoir bien estimé la capacité. Là, on loue ce qu’on consomme, pis on rend ce qu’on n’utilise plus. La grosse dépense d’avance (le capex) devient une dépense qui suit l’usage (l’opex). Pour un projet qui ne sait pas encore combien d’utilisateurs il va avoir, c’est un changement énorme.

flowchart LR
    subgraph Avant[Modele classique]
    A[Acheter serveur] --> B[Racker]
    B --> C[Capacite fixe]
    C --> D[Payer meme si inutilise]
    end
    subgraph Cloud[Modele nuage]
    E[Demander capacite] --> F[Disponible en minutes]
    F --> G[Ajuster a la demande]
    G --> H[Payer a l'usage]
    end

Là où je deviens prudent, par contre, c’est sur les questions qui ne paraissent pas dans la démo. Où sont mes données, physiquement? Qui peut les voir? Qu’est-ce qui arrive si le fournisseur a une panne — pis ça arrive, même aux gros? Comment je sors mes données si je veux changer plus tard? La facilité d’entrer dans le nuage cache souvent la difficulté d’en sortir. Un architecte qui ne pose pas ces questions-là au début se prépare une mauvaise surprise.

Sur le plan technique, ce qui me fascine, c’est que le cloud force à penser autrement. Une machine n’est plus précieuse — elle est jetable. Si une instance plante, on ne la répare pas, on en relance une autre à partir d’une image. Ça veut dire qu’on arrête de bichonner des serveurs uniques, pis qu’on conçoit des systèmes où n’importe quelle pièce peut mourir sans tout faire tomber. C’est un changement de philosophie autant que de technologie.

Le test que je voudrais faire avant de me prononcer, c’est le scénario plate: une panne. Tout a l’air beau tant que ça roule. La vraie question, c’est ce qui se passe quand une zone du fournisseur tombe, quand la facture explose à cause d’un usage mal surveillé, ou quand on doit restaurer une sauvegarde sous pression. C’est dans ces moments-là qu’on voit si le nuage simplifie vraiment la vie ou s’il déplace juste les problèmes ailleurs.

Le piège que je veux nommer, c’est de croire que « dans le nuage » veut dire « plus mon problème ». Le fournisseur s’occupe du matériel, oui. Mais la conception, la sécurité des données, les sauvegardes applicatives, la surveillance des coûts — tout ça reste sur nos épaules. Le nuage déplace la responsabilité, il ne la fait pas disparaître.

Ce que je retiens en ce printemps 2008, c’est qu’on assiste au début d’un vrai virage. Pas une révolution du jour au lendemain — les vieux serveurs vont rester longtemps — mais un changement de modèle qui va remodeler comment on conçoit les systèmes. Je ne sais pas encore jusqu’où ça va aller, pis c’est correct. Mon job, c’est de comprendre assez tôt pour faire des choix d’architecture qui ne nous enferment pas.

La suite, je la garde curieuse mais prudente: essayer le nuage sur un projet où l’erreur n’est pas dramatique, mesurer les vrais coûts, vérifier comment on sort, pis garder l’état important indépendant de la machine qui le fait rouler. Le cloud quitte la slide, c’est vrai. Mais avant de tout y mettre, je veux le voir tenir debout un mauvais jour, pas juste un bon.