En juillet 2014, je remarque un glissement intéressant dans ma tête d’architecte. Le cloud arrête d’être une simple question de « où est-ce que j’héberge mes affaires » pour devenir un vrai choix d’architecture. C’est une nuance, mais elle est importante. On parle plus juste de déménager des serveurs ailleurs: on parle de concevoir les systèmes différemment parce que le cloud rend possible des choses qu’on pouvait pas faire avant.

Pendant longtemps, le cloud, c’était un peu « un serveur, mais loin ». On prenait ce qu’on avait, on le mettait chez un fournisseur, pis c’était tout. En 2014, ça mûrit. La vraie valeur, c’est plus le déménagement: c’est l’élasticité. La capacité de monter pis descendre selon le besoin.

Penser en élastique

Le grand changement, pour moi, c’est qu’on conçoit maintenant en pensant que la capacité bouge. Avant, on achetait une grosse machine pour le pire moment de l’année, pis elle dormait le reste du temps. Le cloud renverse cette logique.

flowchart LR
    A[Trafic normal] --> B[2 serveurs]
    C[Grosse pointe] --> D[Monte à 10 serveurs]
    E[Nuit calme] --> F[Descend à 1 serveur]
    B --> G[On paie ce qu'on utilise]
    D --> G
    F --> G

C’est ça qui change la conception. Au lieu de bâtir pour le pic pis gaspiller le reste du temps, on bâtit des systèmes qui s’ajustent. Ça monte quand il y a de la demande, ça descend quand c’est tranquille. Pis on paie en fonction de ce qu’on utilise vraiment. Pour un architecte, c’est libérateur — mais ça oblige aussi à penser autrement.

Ce que ça impose de repenser

Concevoir pour l’élasticité, c’est pas gratuit. Un système qui doit grossir pis rapetisser tout seul doit être bâti pour ça dès le départ.

Le secret, c’est de pas coller l’état à une machine précise. Si chaque serveur garde des données importantes en local, on peut pas l’éteindre sans rien perdre. Mais si les serveurs sont interchangeables pis que l’état vit ailleurs, on peut en ajouter ou en enlever sans drame. C’est un changement de mentalité plus que de technologie.

Ma prudence d’architecte

Cela dit, je tombe pas dans le panneau du « cloud pour tout ». C’est un choix d’architecture, pis comme tout choix, il a ses contreparties. La dépendance à un fournisseur. Les coûts qui peuvent déraper si on surveille pas. Les questions de où vivent les données, surtout dans le secteur public où je travaille. Pis la complexité ajoutée: un système élastique est plus puissant, mais aussi plus dur à comprendre quand ça plante.

Le cloud devient un vrai choix d’architecture justement parce que c’est plus automatique. Faut peser le pour pis le contre, cas par cas. Parfois c’est évident, parfois ça l’est pas pantoute.

Ce que je retiens

En juillet 2014, je vois le cloud passer d’un endroit où on range ses serveurs à une vraie option de conception. L’élasticité — monter, descendre, payer à l’usage — change la façon dont on dessine les systèmes. C’est plus juste de la plomberie, c’est de l’architecture.

Je garde quand même la tête froide. Un bon architecte choisit ses outils selon le besoin, pas selon la mode. Le cloud ouvre des possibilités magnifiques, mais la vraie compétence, c’est de savoir quand il faut s’en servir — pis quand un bon vieux serveur bien placé fait encore parfaitement la job.