Mises à jour système : appliquer vite ou tester d'abord — arbitrage par type de correctif
Une mise à jour système est une décision à trois vitesses. Un correctif de sécurité sur un service exposé ne s'arbitre pas comme une évolution fonctionnelle, et une montée de version majeure ne se traite pas dans la même fenêtre. Ce qui distingue une infogérance sérieuse n'est pas la fréquence des mises à jour, mais la règle écrite qui dit, par type de correctif, qui décide et ce qui le prouve.
Trois familles de correctifs, trois vitesses
Un correctif de sécurité ferme une vulnérabilité connue. Un correctif fonctionnel corrige un défaut de comportement sans intention de sécurité. Une montée de version majeure remplace une branche logicielle entière, avec ses changements de syntaxe et ses incompatibilités. Les trois arrivent par le même canal, mais n'engagent pas le même risque : les confondre mène à retarder l'urgent, ou à casser le stable un vendredi soir.
Le Guide d'hygiène informatique de l'ANSSI demande une politique de mise à jour des composants et fixe un repère au niveau standard : appliquer les correctifs de sécurité sur l'ensemble du système dans le mois qui suit leur publication par l'éditeur. Un mois est un plafond, pas un objectif. Le même guide ajoute deux exigences : anticiper les fins de support, et limiter les adhérences qui empêchent de mettre à jour un composant parce qu'un autre s'y accroche.
Le critique : ce qui justifie de ne pas attendre la fenêtre
Tous les correctifs de sécurité ne se valent pas. Trois questions suffisent à trier : le composant est-il joignable depuis l'extérieur, la vulnérabilité est-elle exploitable à distance sans authentification, et un code d'exploitation est-il déjà public ? Un service en façade qui répond oui aux trois ne se traite pas dans la fenêtre du mardi : il se traite le jour même, y compris si cela impose un redémarrage en heures ouvrées.
À l'inverse, une vulnérabilité qui exige un accès local préalable supporte une fenêtre planifiée. Le score de gravité seul ne tranche pas : il décrit la vulnérabilité, pas votre exposition. La décision se note — composant, version, date de publication, motif — pour être relue au rapport mensuel. Et elle suppose un inventaire tenu à jour, car le composant dangereux est souvent celui qu'on avait oublié : une bibliothèque partagée ou un micrologiciel.
Le fonctionnel : tester avant, parce que le risque change de camp
Sur un correctif fonctionnel, le risque s'inverse. Le défaut corrigé est connu et souvent mineur ; le changement de comportement introduit ne l'est pas. C'est là que les régressions arrivent : une option qui disparaît, un format de configuration modifié, une dépendance qui change de version en même temps. Appliquer ce type de correctif sans passage par une recette revient à faire de la production l'environnement de test.
La méthode tient en trois lignes : regroupement dans une fenêtre annoncée, application d'abord sur une copie de l'environnement de production, vérification des parcours critiques — connexion, écriture en base, envoi de courriel. Le compte rendu distingue ensuite une régression due à la mise à jour d'un incident sans rapport. Quant au report, il doit avoir une échéance : passé quelques fenêtres, le correctif s'applique ou le blocage se documente comme un risque accepté.
La montée de version majeure ne se traite pas comme un correctif
Changer de branche majeure, ce n'est pas corriger : c'est remplacer. Les fichiers de configuration changent de syntaxe, les extensions doivent être recompilées, les données passent parfois par une conversion, et le retour arrière n'est plus une réinstallation de paquet. Ce chantier se planifie avec une date, un responsable, une copie de l'environnement, des tests de non-régression et un temps d'indisponibilité annoncé.
Le repère utile est la date de fin de support : un composant qui n'est plus maintenu ne reçoit plus de correctifs, et aucune politique de mise à jour ne compense cela. Le guide de l'ANSSI recommande d'en tenir la liste et de choisir des solutions dont le support couvre la durée d'usage prévue. Dans un contrat, l'opération doit être nommée séparément : elle consomme du temps et ne relève pas du forfait de maintenance courante.
Qui applique, quand, et ce qui redémarre vraiment
Sur un serveur Linux, l'automatisation existe et elle est utile : le mécanisme de mises à jour fourni par la distribution installe par défaut les correctifs de sécurité, sans les changements de fonctionnalités. Encore faut-il savoir qu'il tourne, sur quel périmètre et à quelle heure. La configuration installée est conservatrice, mais rien ne garantit qu'elle soit active : le paquet peut être absent, ou présent puis désactivé après un incident.
La planification passe par des minuteurs systemd, dont l'état se lit sans rien modifier : systemctl list-timers --all affiche les échéances, la dernière exécution et la suivante. Un décalage aléatoire évite que des milliers de machines se connectent à la même seconde, ce qui explique qu'une mise à jour n'arrive pas à l'heure exacte annoncée. La simulation, sans effet non plus, se lance avec unattended-upgrade --dry-run.
Reste le redémarrage, que l'automatisation ne règle pas. Un noyau ou une bibliothèque partagée mis à jour ne prend effet qu'après redémarrage des processus concernés, parfois de la machine entière. Un système qui installe sans jamais redémarrer accumule des correctifs non actifs : la version du paquet est à jour, le processus en mémoire ne l'est pas. D'où une règle explicite et une trace : le gestionnaire de paquets journalise ses opérations, comme le mécanisme d'automatisation.
La preuve : journaux, versions, test après coup
Une mise à jour appliquée n'est pas une mise à jour vérifiée. Trois éléments font la différence dans un compte rendu : la version avant, la version après, et le test qui montre que le service fonctionne encore. Ce triptyque se relit six mois plus tard. Le test, lui, ne se réduit pas au redémarrage : il vérifie ce que l'utilisateur fait réellement — une page qui répond, une écriture en base, un courriel qui part.
Reste l'échec : une mise à jour qui casse le service doit pouvoir être annulée, et cette possibilité se prépare avant, pas pendant. Instantané pris avant l'opération, version précédente encore disponible, procédure écrite, délai connu. Une mise à jour sans retour arrière possible n'est pas une opération d'exploitation, c'est un pari sur la compatibilité. Demandez donc où sont les journaux, qui les conserve et combien de temps : « c'est automatique » n'est pas une réponse.