Votre dernière mise à jour a fait tomber un service en pleine journée, et depuis vous repoussez ? C’est exactement comme ça que des parcs entiers finissent avec plusieurs mois de retard. La peur est compréhensible. Une faille connue laissée ouverte reste pourtant l’une des portes d’entrée les plus banales pour se faire compromettre. Ce qui manque, dans ces cas-là, c’est presque toujours une méthode.
Tenir un parc à jour sans casser la prod tient en quatre gestes : un snapshot avant d’intervenir, un essai sur un serveur sans enjeu, une fenêtre planifiée, et le retour arrière déjà prêt.
Trier avant d’agir
Première chose à trancher : de quoi on parle. Un correctif de sécurité critique ferme une faille parfois activement exploitée, et là, attendre vous expose plus que l’opération elle-même. Une montée de version, mineure ou majeure, apporte des fonctions ou des corrections qui peuvent patienter, mais elle casse parfois des choses. Le premier se traite vite, la seconde se planifie.
Les deux erreurs que je croise le plus ? Repousser un correctif critique « par prudence », alors que c’est exactement l’inverse de la prudence. Et balancer une grosse montée de version en urgence, sans rien tester, parce qu’un dirigeant a lu un article qui fait peur.
Le filet d’abord, l’application ensuite
Avant de toucher quoi que ce soit, on fige l’état. Sur une infra virtualisée, un snapshot Proxmox se prend en quelques secondes. C’est le filet qui transforme un incident en non-événement : si la mise à jour part en vrille, on restaure, et on retrouve l’état d’avant en moins de cinq minutes. Sans ce filet, la même panne devient une soirée de débogage à chaud, téléphone qui sonne en boucle. Pas de snapshot, pas de mise à jour : je suis catégorique là-dessus, c’est ce qui me permet de dormir.
Vient ensuite l’essai. On applique là où une casse n’a aucune conséquence, une préprod ou un serveur de second rôle, et on vérifie que tout répond comme avant. La machine qui compte, on n’y touche qu’après. Reste le moment : pas le mardi à 15h quand le trafic est au plus haut, mais une fenêtre annoncée où une coupure passe sans drame, avec assez de marge pour vérifier et, au besoin, faire marche arrière sans courir. La précipitation casse bien plus souvent que la mise à jour elle-même.
J’ai un client industriel, une vingtaine de VM (des serveurs virtuels tournant sur une même machine physique), passé d’un grand chantier annuel que personne n’osait lancer à des fenêtres courtes toutes les trois semaines. Le chantier annuel cumulait trop de versions de retard, trop d’inconnues, donc on repoussait, et l’écart grossissait. Par petits pas, chaque opération devient minuscule : deux ou trois paquets, un snapshot, dix minutes, c’est plié.
Le conseil que je vous laisse, si vous ne deviez en retenir qu’un : bloquez dès maintenant une fenêtre récurrente dans l’agenda, courte, toutes les deux ou trois semaines, et tenez-la même les semaines où il n’y a rien d’urgent. C’est ce rendez-vous fixe, plus que n’importe quel outil, qui empêche l’écart de se creuser.