Sur un mandat ce mois-ci, on a un client qui a une salle pleine de serveurs, chacun avec sa job : un pour le courriel, un pour l’application maison, un pour les fichiers, un pour les tests. La plupart roulent à 10 % de leur capacité. Ils chauffent, ils prennent de la place, ils coûtent cher en électricité pis en climatisation, pis ils dorment 90 % du temps. C’est là que la virtualisation entre dans la game. Pis comme architecte, je dois faire comprendre au client que ce virage-là, ça commence par un p’tit changement de mentalité.

Le déclic, c’est d’arrêter de penser « serveur = boîte de métal ». Avec la virtualisation, un serveur devient un fichier. Une machine virtuelle, c’est un système d’exploitation complet qui roule dans un autre, isolé, déplaçable, copiable. Tu peux en mettre cinq, dix, sur une seule grosse boîte physique. La boîte travaille enfin à plein, pis tes dix « serveurs » sont juste des fichiers que tu peux sauvegarder pis bouger.

Voici, en gros, ce qui change dans la salle.

flowchart TD
    subgraph Avant
    A1[Serveur courriel - 10%]
    A2[Serveur appli - 15%]
    A3[Serveur fichiers - 8%]
    A4[Serveur tests - 5%]
    end
    subgraph Après
    H[Un hôte physique bien utilisé]
    H --> V1[VM courriel]
    H --> V2[VM appli]
    H --> V3[VM fichiers]
    H --> V4[VM tests]
    end

Quand le client voit ça, il voit juste les économies : moins de boîtes, moins d’électricité, moins de place. Mon job, c’est de lui montrer l’autre bord de la médaille. Parce que mettre tous tes œufs dans le même panier, ça change ton profil de risque. Avant, si un serveur lâchait, t’en perdais un. Là, si l’hôte physique lâche, t’en perds dix d’un coup. La virtualisation, c’est pas magique : ça déplace le risque, ça l’efface pas.

C’est pour ça que mon premier réflexe, c’est pas la consolidation, c’est la reprise. Avant de tout entasser, je veux savoir : on restaure comment ? On a-tu testé la restauration, pas juste la sauvegarde ? Parce qu’une sauvegarde qu’on a jamais restaurée, c’est juste une supposition. Pis la beauté de la virtualisation, justement, c’est que tu peux restaurer une VM complète sur une autre boîte sans réinstaller le système au complet. Bien fait, ça rend la reprise plus simple, pas plus risquée.

L’autre piège, c’est l’emballement. Dès que créer un serveur devient aussi facile que copier un fichier, le monde en crée partout. « Ah, j’ai besoin d’un serveur de test pour deux jours » — clic, t’en as un. Pis trois mois plus tard, t’as quarante VM dont personne se rappelle l’utilité. Ça mange ta capacité, ça complique tes sauvegardes, ça ouvre des trous de sécurité. La facilité de création, c’est une bénédiction pis une malédiction. Faut une discipline : chaque VM a un propriétaire, une raison d’exister, pis une date de péremption.

Sur le terrain, je commence petit. On prend les serveurs les moins critiques — les environnements de test, les vieux services peu utilisés — pis on les virtualise en premier. Ça nous fait pratiquer, ça nous apprend les outils, pis si on se plante, c’est pas la fin du monde. Une fois qu’on est à l’aise pis qu’on a testé une vraie reprise, on monte vers les affaires plus sérieuses. Toucher au serveur de courriel de la compagnie en premier « parce que c’est lui qui chauffe le plus », c’est la meilleure façon de se ramasser dans le trouble.

La page que je laisse au client, c’est pas un gros document. C’est une feuille courte : c’est quoi nos hôtes, quelles VM roulent dessus, c’est qui le responsable de chacune, où sont les sauvegardes, pis comment on remonte tout ça si la grosse boîte meurt à 3 h du matin. Quelqu’un qui arrive dans le dossier sans connaître l’histoire doit pouvoir comprendre pis agir. Pas très spectaculaire, mais c’est ça qui sauve la mise sous pression.

Ce que je retiens de ce mandat-là, c’est que les gros virages d’infrastructure commencent toujours par un petit changement qu’on sous-estime. « Un serveur, c’est un fichier maintenant » — ça a l’air anodin, mais ça change toute la façon de penser la capacité, la reprise pis le risque. Mon rôle d’architecte, c’est de profiter de la souplesse sans tomber dans la fragilité.

La suite, sobre comme d’habitude : virtualiser progressivement, tester la reprise pour vrai, garder une discipline sur la création de VM, pis documenter assez pour que la salle reste compréhensible. La virtualisation, mal gérée, ça fait juste cacher le bordel. Bien gérée, ça remet de l’ordre pis ça donne une marge qu’on avait pas avant.