Dans mon nouveau rôle de chef d’équipe, un serveur n’est plus seulement la destination du build. C’est une recette, un état et plusieurs dépendances que le groupe devra comprendre pendant un déploiement ou une panne.

La virtualisation sépare le système invité de son hôte, mais une VM copiée n’est pas nécessairement reproductible. Son disque peut contenir trois ans de correctifs, une DLL remplacée à la main, un compte de service et un certificat dont personne ne connaît l’origine. L’image déplace ce secret vers un autre hôte sans l’expliquer.

Je séparerais donc quatre couches :

image de base -> système et correctifs communs
configuration -> rôles, paramètres, comptes et certificats
application   -> build versionné et procédure de déploiement
état          -> base, fichiers utiles et journaux à conserver

L’image de base ne devrait pas contenir un mot de passe partagé. La configuration associe un compte de service au rôle et documente où son secret est géré. Le build peut être réinstallé. L’état possède sa propre sauvegarde et son objectif de reprise.

Reconstruire à partir d’une fiche testable

Pour un serveur Web interne, la fiche pourrait dire :

1. créer une VM avec 2 vCPU, 4 Go et deux volumes;
2. joindre le domaine et appliquer le niveau de correctifs approuvé;
3. installer IIS avec les modules listés;
4. créer le pool avec le compte DOMAINE\svc_portail;
5. déployer le build Portail-2.4.17;
6. charger la configuration de l’environnement;
7. exécuter /health.aspx puis une transaction synthétique.

Une autre personne doit pouvoir suivre cette séquence sans appel privé à l’auteur. Un script peut automatiser les étapes répétitives, mais sa sortie et ses erreurs doivent rester lisibles; remplacer un expert par un script opaque ne réduit pas la dépendance.

Les données sortent du disque système. Une base SQL externe, un partage sauvegardé ou un volume géré séparément permet de remplacer la VM sans emporter l’état. Il faut néanmoins connaître la cohérence entre le build et la base : repartir avec une ancienne application sur un schéma déjà migré peut être impossible. Le plan de retour doit couvrir code et données ensemble.

Les instantanés restent tentants avant une release. Ils facilitent un retour court, mais une longue chaîne consomme du stockage et dépend du même environnement. Ils ne remplacent pas une sauvegarde testée ailleurs. Une copie de VM démarrée avec le même nom, la même adresse ou le même compte peut aussi entrer en conflit avec la production; l’exercice se fait dans un réseau isolé.

Je testerais enfin la panne qui compte : supprimer la VM de test, demander à une personne différente de la reconstruire et mesurer jusqu’à la première transaction réussie. On note chaque intervention manuelle et on remet la recette à jour.

Une VM rend le matériel remplaçable. La documentation, la configuration versionnée et la séparation de l’état rendent le service remplaçable. Si le groupe dépend encore de celui qui connaît le bon clic, le serveur conserve toute sa personnalité, même lorsqu’il n’est plus une boîte physique.