Gestion des mises à jour

Les dépôts du VPS interrogés : tout est à jour.

Téléphone, ordinateur, applications, serveurs : tout outil numérique vit dans un écosystème qui évolue sans cesse. Pour continuer à fonctionner, il doit en suivre les évolutions, et donc être mis à jour régulièrement.

C’est d’abord une question de sécurité. Une mise à jour corrige des failles par lesquelles un attaquant pourrait endommager le système ou voler des données.

Gérer les mises à jour de tous ses outils prend du temps, beaucoup de temps, et ça ne s’arrête jamais. Ce temps est proportionnel au nombre d’outils que l’on a, et à ceux que l’on crée. Une partie s’automatise, pas tout.

Je reviens ici sur les précautions à prendre, sur ce que l’automatisation fait ou ne fait pas, sur les particularités de chaque système et les erreurs à éviter, avant de montrer comment je gère les mises à jour de mon VPS et de Supabase.

Une mise à jour est aussi un risque

Une mise à jour n’est pas anodine : elle peut casser un système qui fonctionne, en changeant un comportement ou en restructurant des données.

Elle peut aussi être piégée, avec du code malveillant glissé dans une version.

Voici quelques recommandations :

• Sauvegarder avant de mettre à jour, et tester quand c’est possible.
• Passer par le site officiel de l’outil ou le gestionnaire de mises à jour du système.
• Pour un téléchargement manuel, vérifier la signature numérique quand elle existe.
• Suivre l’actualité de ses outils pour voir si rien n’est signalé.
• Séparer les correctifs de sécurité, à appliquer vite, des nouvelles versions d’un programme tiers, qui peuvent attendre quelques jours quand elles n’apportent aucun correctif. Malheureusement, les deux arrivent souvent ensemble.

Cybermalveillance.gouv.fr en a fait une fiche.

Mettre à jour, c’est donc une veille et un suivi continus de tous ses outils. L’enjeu est encore plus fort quand on traite des données confidentielles.

Ce qui s’automatise, ce qui reste

L’automatisation télécharge et installe les mises à jour sans qu’on ait à y penser. La plupart des systèmes le proposent.

Mais elle le fait parfois à moitié. Certains correctifs n’agissent qu’après un redémarrage du programme ou de la machine, et l’outil ne le fait pas forcément. Tant qu’il n’est pas fait, la mise à jour est installée mais la faille reste ouverte.

Ce qui ne s’automatise pas :

• Décider. Certaines montées de version ne doivent pas se faire automatiquement : après, le service ne démarre plus ou ne fonctionne plus normalement. Il faut en évaluer l’impact avant, et parfois choisir d’attendre.
• Vérifier. S’assurer que la mise à jour est bien active. Une alerte peut signaler un échec, mais quelqu’un doit la lire et agir.
• Isoler ou remplacer. Un matériel qui ne reçoit plus de mises à jour, comme une vieille box ou un objet connecté, ne se corrige plus. Il faut l’isoler du réseau ou le remplacer.

L’automatisation fait gagner du temps sur le téléchargement et l’installation, pas sur le suivi. Elle en ajoute même : l’outil qui installe devient lui aussi à surveiller.

Système par système

Aujourd’hui, la plupart des systèmes savent gérer leurs mises à jour automatiquement, et Cybermalveillance.gouv.fr recommande d’activer cette installation automatique partout où elle est proposée. Mais chaque système a ses particularités, qui demandent une vigilance adaptée. En voici quelques-unes, sans être exhaustif.

Windows 11. Les mises à jour sont téléchargées et installées automatiquement. Pour terminer l’installation, il faut redémarrer : le système tente de le faire quand la machine n’est pas utilisée.

Windows 10. Depuis le 14 octobre 2025, il ne reçoit plus de correctifs de sécurité, sauf avec l’extension proposée aux particuliers jusqu’au 12 octobre 2027.

macOS et iOS. Depuis la version 26.1, Apple peut distribuer des améliorations de sécurité en arrière-plan. Si le réglage d’installation automatique est désactivé, elles attendent la mise à jour suivante.

Android. La plupart des mises à jour du système et des correctifs de sécurité s’installent seuls. Leur calendrier dépend de l’appareil, du fabricant et de l’opérateur. Avant un achat, il faut vérifier jusqu’à quand l’appareil recevra des mises à jour.

Serveur Debian. unattended-upgrades installe automatiquement les mises à jour officielles de la version en cours, correctifs de sécurité compris, pas les nouvelles fonctionnalités. needrestart repère les programmes à relancer pour que les correctifs soient pris en compte, sans redémarrer toute la machine. Mais certaines mises à jour exigent un redémarrage complet, que unattended-upgrades ne fait pas par défaut.

Conteneurs. On peut demander une version large, comme 3.21. Elle suit les mises à jour de l’éditeur : 3.21.1 aujourd’hui, 3.21.4 dans trois mois. Les correctifs arrivent au prochain téléchargement, mais le contenu change sans qu’on le décide. On peut aussi figer l’image exacte : rien ne change, mais aucun correctif n’arrive tant qu’on ne la change pas soi-même. Docker propose cette seconde option, avec un outil qui signale les nouvelles versions.

Box, routeurs et objets connectés. Inventorier ses appareils et installer les mises à jour des fabricants. Un appareil qui n’en reçoit plus doit être protégé autrement, par exemple déconnecté d’Internet ou séparé du reste du réseau.

L’installation automatique fait une grande partie du travail, mais elle ne garantit pas que tout est à jour et pris en compte. Quel que soit le système, rien ne se fait jamais entièrement tout seul.

Ce qu’il ne faut pas faire

Certaines erreurs annulent le travail fait sur les mises à jour, ou ouvrent une porte aux attaquants. Voici celles à éviter.

• Installer une mise à jour proposée par une fenêtre ou une publicité sur un site web. C’est un procédé courant pour diffuser des logiciels malveillants. Une vraie mise à jour passe par le système ou par l’outil lui-même.
• Reporter un correctif sans fixer de date. Repousser peut se justifier, mais un report sans échéance devient un oubli.
• Trier les correctifs sur la seule note de gravité. Une faille moins bien notée mais déjà exploitée par des attaquants passe avant, comme le rappelle le NCSC britannique.
• Installer un logiciel piraté ou d’origine douteuse. Il est souvent piégé, et coupé des mises à jour de l’éditeur.
• Désactiver son antivirus parce qu’un programme le demande. C’est souvent ainsi qu’un logiciel malveillant s’installe.
• Oublier une machine parce qu’elle n’est pas reliée à Internet. Elle ne reçoit rien automatiquement : il faut la mettre à jour à la main.
• Croire qu’un correctif répare tout. Il ferme la faille, mais si elle a déjà été exploitée, il faut chercher les traces d’une intrusion.

Gérer les mises à jour demande donc une vraie organisation : savoir ce qu’on a à mettre à jour, comment et quand. Plus on a d’outils, plus cette organisation compte.

Ce que je fais sur mon VPS et Supabase

Mettre à jour mon VPS et Supabase, c’est ma routine quotidienne, ou presque, et j’interviens aussi à la demande quand le VPS me notifie par mail.

Le VPS est sauvegardé chaque nuit par une image chez OVH, conservée 7 jours : si une mise à jour casse un service, je peux récupérer l’état d’avant.

Prenons l’exemple d’hier : voici ce que j’ai fait.

Système. Sous Debian, les paquets officiels s’installent tout seuls, correctifs de sécurité compris. Ceux des dépôts tiers, comme Docker ou Caddy, ne s’installent pas automatiquement. Le VPS me les a signalés par mail, puis j’ai lancé la mise à jour à la main :

sudo apt update
sudo apt upgrade

Deux paquets étaient à mettre à jour : containerd.io et docker-buildx-plugin. Il restait aussi un sudo apt autoremove à lancer, pour supprimer un ancien noyau devenu inutile.

Ce mail vient d’un script maison, lancé chaque jour à 7 h 30 UTC par un timer systemd, après unattended-upgrades : il signale un redémarrage en attente ou des paquets à mettre à jour à la main.

Le timer qui vérifie chaque jour s’il faut redémarrer le VPS ou mettre à jour des paquets.

Services. Un skill Claude Code a comparé les versions de mes cinq services, notées dans la documentation du serveur, avec les dernières publiées. Voici sa réponse :

Deux services étaient à mettre à jour : n8n et Stalwart.

n8n, en conteneur Docker. Dans le fichier docker-compose.yml, j’ai changé la version de l’image (2.46.6 devient 2.47.6), puis téléchargé la nouvelle image, relancé le conteneur et supprimé l’ancienne image, qui occupait près de 2 Go :

cd n8n/
nvim docker-compose.yml
sudo docker compose pull
sudo docker compose up -d
sudo docker image ls
sudo docker rmi docker.n8n.io/n8nio/n8n:2.46.6

Stalwart, le serveur mail. Il est installé directement sur Debian, hors Docker, par un script. La note de version 1.1.0 ajoutait une étape : redémarrer une fois avec la variable STALWART_UPDATE_ROLE_PERMISSIONS=true, puis la retirer. Ce redémarrage ajoute aux rôles existants les permissions des passkeys (la connexion sans mot de passe).

sudo systemctl stop stalwart
curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh | sudo sh
sudo systemctl set-environment STALWART_UPDATE_ROLE_PERMISSIONS=true
sudo systemctl restart stalwart
sudo systemctl unset-environment STALWART_UPDATE_ROLE_PERMISSIONS
stalwart --version

Supabase. La mise à jour mineure de Postgres se lance d’un clic, mais le projet est resté hors ligne environ 5 minutes. Il faut choisir le moment.

La mise à jour mineure de Postgres se lance depuis les réglages du projet.

Pour finir, j’ai redémarré le VPS (sudo reboot) et vérifié que tous les services repartaient seuls, pas seulement ceux que je venais de mettre à jour.

Aujourd’hui, le VPS m’a notifié par mail qu’un nouveau noyau était installé. Il a fallu redémarrer à nouveau, car c’est le redémarrage qui met le nouveau noyau en service.

Après chaque mise à jour, je reporte la nouvelle version dans la fiche du service, dans la documentation du serveur : c’est là que le skill lit les versions installées.

Conclusion

Les gestes sont courts et très répétitifs, mais il faut être derrière pour vérifier que tout fonctionne. Tout automatiser n’est pas pertinent : il faut lire les notes de version et s’assurer que rien n’empêche l’installation, pour qu’elle n’endommage pas le bon fonctionnement du service.

Parfois, cela demande plus de temps, comme ici avec la 1.1.0 de Stalwart, où une petite manipulation manuelle, indiquée dans la note de version, s’ajoutait au script. Et parfois, c’est encore plus long : le passage de Stalwart de la 0.16 à la 1.0.0 m’a pris une bonne demi-heure. La 1.0 n’ouvre pas l’ancienne base : réglages et données ont dû être copiés dans une base neuve avec l’outil de migration de l’éditeur, stalwart-migrate. L’interface d’administration a aussi connu de gros changements, et il a fallu la publier avec Caddy.

Un outil numérique ne doit pas être laissé en roue libre. Pour qu’il vieillisse bien et dure dans le temps, il faut un entretien régulier.