Gestion des mises à jour & correctifs

Le dilemme des mises à jour

Chaque semaine, des correctifs de sécurité sont publiés pour les systèmes d'exploitation, les bases de données, les frameworks applicatifs. Ne pas les appliquer expose à des vulnérabilités connues et exploitées. Les appliquer sans test peut introduire des régressions.

Ce dilemme explique pourquoi tant de serveurs restent vulnérables pendant des mois. L'équipe technique sait qu'il faudrait mettre à jour, mais la peur de "casser quelque chose" l'emporte. Jusqu'au jour où une faille est exploitée.

Types de mises à jour

Correctifs de sécurité

Les patches de sécurité corrigent des vulnérabilités identifiées. Certains sont critiques et doivent être appliqués rapidement (failles activement exploitées). D'autres sont moins urgents mais ne doivent pas être ignorés indéfiniment.

Mises à jour fonctionnelles

Les mises à jour mineures apportent des corrections de bugs et des améliorations. Elles sont généralement moins risquées mais peuvent parfois modifier des comportements attendus.

Montées de version majeures

Les upgrades majeurs (PHP 7 vers PHP 8, Ubuntu 20.04 vers 22.04) nécessitent une planification spécifique. Ils peuvent impliquer des changements incompatibles et demandent des tests approfondis.

Processus de patch management

Inventaire et veille

La première étape est de connaître précisément les versions installées sur chaque serveur. Sans inventaire à jour, impossible de savoir quels correctifs s'appliquent. La veille sur les bulletins de sécurité permet d'identifier les patches prioritaires.

Évaluation et priorisation

Tous les correctifs ne se valent pas. Une faille critique sur un service exposé à Internet est plus urgente qu'un bug mineur sur un outil interne. L'évaluation tient compte de la criticité de la vulnérabilité et de l'exposition du système concerné.

Test avant déploiement

Dans l'idéal, chaque mise à jour est testée sur un environnement de pré-production avant d'être appliquée en production. Pour les petites structures sans environnement de test, des procédures de rollback doivent être prévues.

Déploiement et vérification

L'application du correctif s'accompagne d'une vérification fonctionnelle. Les services critiques sont-ils toujours opérationnels ? Les performances sont-elles nominales ? La supervision permet de détecter rapidement une régression.

Automatisation raisonnée

L'automatisation des mises à jour est tentante mais dangereuse si elle est totale. Les mises à jour de sécurité mineures peuvent souvent être automatisées. Les mises à jour majeures ou les changements de version nécessitent une intervention humaine.

Sur les serveurs Linux, des outils comme unattended-upgrades permettent d'appliquer automatiquement les correctifs de sécurité tout en excluant les mises à jour potentiellement disruptives.

Cas concret : cabinet d'avocats à Bordeaux

Un cabinet de 15 avocats utilisait un serveur de fichiers sous Windows Server 2012, plus maintenu par Microsoft depuis 2023. Les mises à jour de sécurité n'étaient plus disponibles, exposant le cabinet à des risques majeurs.

La migration vers une version supportée a été planifiée sur un week-end. Sauvegarde complète le vendredi soir, installation du nouveau système le samedi, restauration des données et tests le dimanche. Le lundi matin, les utilisateurs retrouvaient leur environnement habituel sur une infrastructure sécurisée.

Documentation des interventions

Chaque mise à jour appliquée doit être tracée : date, version précédente, version installée, éventuels problèmes rencontrés. Cette documentation permet de diagnostiquer les régressions et de maintenir un historique des changements.

La maintenance informatique entreprise intègre naturellement ce suivi dans les rapports d'intervention réguliers.

Mises à jour applicatives

Au-delà des systèmes d'exploitation, les applications métiers nécessitent aussi des mises à jour. CMS, frameworks, bibliothèques tierces : chaque composant a son cycle de vie et ses vulnérabilités potentielles.

Pour les applications web, des outils comme Dependabot ou Snyk détectent automatiquement les dépendances obsolètes ou vulnérables. L'intégration de ces vérifications dans le processus de développement évite l'accumulation de dette technique.

Planification à long terme

Les systèmes d'exploitation et les logiciels ont des cycles de support définis. Ubuntu LTS est supporté 5 ans, Windows Server 10 ans. Anticiper les fins de support permet de planifier les migrations sans urgence.

Un calendrier de maintenance à 12-24 mois identifie les échéances à venir et les ressources nécessaires. Cette visibilité évite les situations où un système critique devient soudainement obsolète.