Le correctif fait partie de ce que vous reprenez
Dans un SaaS, la mise à jour de sécurité est invisible : l'éditeur la déploie sur sa propre flotte, parfois avant même l'annonce publique. La même vulnérabilité sur une instance que vous hébergez ne bouge pas tant que personne ne l'applique. CVE-2026-63077 illustre le décalage : la faille permettait l'exécution de commandes système sans authentification sur TeamCity On-Premises, corrigée dans les versions 2025.11.7 et 2026.1.3, pendant que les déploiements cloud du même éditeur ne demandaient aucune action à leurs clients. L'écart n'est pas technique, il est organisationnel.
Ce qui casse quand personne ne s'en occupe
- La version installée devient introuvable — sans inventaire, personne ne sait quelle brique tourne sur quelle machine, et un avis de sécurité ne peut même pas être trié.
- L'avis arrive à une adresse morte — les notifications de l'éditeur partent vers la boîte d'un prestataire parti ou vers un alias que plus personne ne relève.
- Le retard s'accumule jusqu'à l'impasse — trois versions majeures de décalage transforment un correctif de dix minutes en migration de deux jours.
- La mise à jour se fait sans filet — sans sauvegarde vérifiée, une migration de schéma appliquée puis regrettée ne se rejoue pas en arrière.
- Personne ne vérifie après — le service redémarre, la page d'accueil répond, et un consommateur de file d'attente reste mort pendant des semaines sans un seul signal.
Les quatre prérequis d'une routine tenable
Une routine de correctifs ne tient pas sur la bonne volonté, elle tient sur quatre choses écrites. Un inventaire : chaque application, sa version, son hôte, son responsable. Des sources d'avis restreintes aux briques réellement installées, parce qu'un flux généraliste noie le signal. Une fenêtre annoncée : un créneau récurrent où l'interruption est admise, faute de quoi le correctif attend un moment calme qui n'arrive jamais. Une sauvegarde restaurable, essayée avant d'en avoir besoin. Sans ces quatre points, chaque mise à jour redevient un projet à négocier.
La routine, en cinq gestes
Dresser l'inventaire de ce qui tourne vraiment
Listez chaque application exposée, sa version exacte, son hôte et son responsable. docker compose ls puis docker image inspect donnent l'état réel des conteneurs ; dpkg -l ou rpm -qa celui des paquets système. Versionnez ce fichier à côté de vos configurations : un inventaire qui ne vit que dans une mémoire humaine n'existe pas.
S'abonner aux avis des briques installées, pas à tout l'Internet
Pour chaque ligne de l'inventaire, ouvrez un abonnement nommé : le flux Atom des releases du dépôt (https://github.com/org/repo/releases.atom), la liste de diffusion sécurité de l'éditeur, ou une requête NVD filtrée sur le produit. Un abonnement par brique reste triable. Faites-les arriver dans une boîte partagée, jamais sur une adresse personnelle.
Fixer une fenêtre de correctif, et une voie rapide
Réservez un créneau récurrent où une interruption est admise et annoncée. Deux classes suffisent : les correctifs ordinaires attendent la fenêtre ; une faille critique activement exploitée déclenche une application immédiate, hors fenêtre. Écrire cette règle avant l'incident évite d'avoir à la négocier pendant.
Sauvegarder juste avant, et prouver la restauration
Avant d'appliquer, prenez un export de la base (mysqldump, pg_dump) et une sauvegarde datée du volume de données, puis notez la version que vous quittez. Un instantané côté hyperviseur et une sauvegarde applicative (restic, borg) ne couvrent pas le même risque : gardez les deux, et testez une restauration pendant qu'elle n'est pas urgente.
Vérifier le comportement après, puis le confier à une sonde
Un port ouvert ne prouve rien. Après chaque correctif, contrôlez ce que l'application fait réellement : réponse de l'endpoint de santé (curl -fsS https://votre-domaine.com/health), files d'attente consommées, envoi d'un e-mail de test, absence d'erreurs neuves dans les journaux. Inscrivez ensuite ces contrôles dans une supervision permanente, avec Uptime Kuma par exemple, qui les rejoue sans vous.
Réduire la surface plutôt que courir après les correctifs
Une console d'administration ou un protocole d'agent exposé à l'Internet public transforme chaque faille non authentifiée en incident immédiat. Placez ces interfaces derrière un réseau privé, un VPN ou une liste d'adresses autorisées. La mise à jour reste obligatoire, mais le délai entre la publication d'un avis et votre correctif cesse d'être une fenêtre d'exposition ouverte à tous.
Qui met à jour quoi, exactement
Sur un serveur que vous administrez, la répartition doit rester nette. L'hébergeur fournit et maintient le socle : la machine, le réseau, le stockage, la disponibilité de l'hyperviseur. Les applications que vous installez dessus — leur version, leurs correctifs, leur configuration — restent sous votre administration. Personne ne les mettra à jour à votre place, et c'est le prix du contrôle que vous avez choisi. La routine décrite ici est ce qui rend ce partage tenable : elle transforme une charge diffuse en un rendez-vous court et prévisible.
