Mises à jour de sécurité automatiques : pourquoi ne pas les désactiver

Cadenas ouvert posé sur le clavier d'un ordinateur portable

« On a désactivé les mises à jour automatiques, ça redémarrait tout seul en pleine journée et ça a planté notre logiciel de caisse. » C'est l'une des phrases les plus entendues sur le terrain par les prestataires informatiques, et elle part d'une expérience réelle, pas d'une négligence. Le problème, c'est que la décision prise pour éviter un désagrément ponctuel laisse ensuite la porte grande ouverte, parfois pendant des mois.

Chaque semaine, GLSM documente ici des failles de sécurité précises : la récente faille PHP2Shell en est un bon exemple. Mais une faille corrigée ne protège personne si le correctif n'est jamais installé. Cet article explique pourquoi les mises à jour de sécurité automatiques sont, pour une TPE sans service informatique dédié, l'une des protections les plus simples et les plus rentables qui existent — et comment les activer sans subir les désagréments qui poussent à les couper.

Pourquoi tant de TPE désactivent les mises à jour, en pratique

Désactiver les mises à jour automatiques n'est presque jamais un choix de sécurité réfléchi : c'est une réaction à un incident vécu, ou une habitude héritée. Les raisons les plus fréquentes, sans aucun jugement :

La peur de casser un logiciel métier. Un logiciel de caisse, de comptabilité ou de gestion commerciale a parfois été configuré il y a des années par un prestataire qui n'est plus disponible. Une mise à jour système qui change une version de pilote, de framework ou de configuration peut, dans de rares cas, rendre ce logiciel instable. Le risque est réel, mais il concerne surtout les mises à jour de fonctionnalités, pas les correctifs de sécurité (voir plus bas).
La lenteur perçue au redémarrage. Un ordinateur ou un serveur qui redémarre en pleine journée de travail, ou qui met de longues minutes à appliquer une mise à jour avant de pouvoir rouvrir une session, est vécu comme une perte de temps agaçante — surtout quand ça arrive au mauvais moment, devant un client.
Le manque de temps pour superviser. Dans une TPE, personne n'a pour mission de surveiller les mises à jour. « On verra plus tard » devient vite « on ne le fait plus jamais », sans que ce soit une décision consciente.
Une mauvaise expérience passée. Une mise à jour qui a un jour cassé quelque chose (imprimante, logiciel, connexion réseau) suffit à motiver la désactivation définitive de toutes les mises à jour futures, par prudence — alors que l'incident initial concernait souvent une seule mise à jour précise.

Comprendre ces raisons ne change pas le constat : une fois désactivées, les mises à jour de sécurité le restent presque toujours, par défaut, indéfiniment.

Le risque concret : une faille connue reste exploitable tant qu'elle n'est pas corrigée

Une faille de sécurité critique suit toujours le même cycle : elle est découverte, un correctif (patch) est publié par l'éditeur, puis l'information devient publique — souvent via un identifiant CVE. À partir de ce moment précis, deux populations s'affrontent dans une course de vitesse : les administrateurs qui appliquent le correctif, et les attaquants qui cherchent les systèmes qui ne l'ont pas encore fait.

La faille PHP2Shell déjà couverte par GLSM illustre bien ce mécanisme : des tentatives d'exploitation ont été observées avant même la sortie officielle du correctif, et un exploit public a circulé quelques jours après la divulgation du CVE. Dans ce type de situation, l'écart entre « le correctif existe » et « le correctif est appliqué » devient la fenêtre d'exposition exacte dans laquelle un attaquant peut agir — et plus cette fenêtre reste ouverte longtemps (des semaines, des mois, parfois des années sur un système où les mises à jour sont coupées), plus la probabilité d'être ciblé augmente, pas forcément par un attaquant qui vous vise personnellement, mais par un scan automatisé qui balaie Internet à la recherche de systèmes non corrigés.

C'est l'essentiel à retenir : une faille corrigée par l'éditeur n'est dangereuse que pour qui n'a pas appliqué le correctif. Désactiver les mises à jour de sécurité ne protège de rien : cela prolonge simplement, volontairement, la durée pendant laquelle une faille publique et documentée reste ouverte sur vos postes ou vos serveurs.

Le cas le plus extrême de ce principe est celui d'un système qui n'est plus mis à jour du tout, même quand on le souhaite : c'est la situation de Windows 10 en fin de support, où aucune nouvelle faille découverte ne sera plus jamais corrigée, quelle que soit sa gravité. Désactiver volontairement les mises à jour sur un système encore supporté revient, en pratique, à s'imposer soi-même la même exposition, un correctif disponible à la fois.

Toutes les mises à jour ne se valent pas : sécurité vs fonctionnalités

La confusion la plus fréquente consiste à traiter toutes les mises à jour de la même façon, alors qu'il existe une vraie différence de nature :

Mise à jour de sécurité (correctif). Elle corrige une faille précise, déjà identifiée et parfois déjà exploitée. Elle ne change en général pas le fonctionnement visible du logiciel : même interface, mêmes fonctionnalités, juste une porte refermée. Le risque de casser quelque chose est faible, le risque de ne pas l'appliquer est élevé. C'est celle qu'il faut appliquer vite, sans attendre.
Mise à jour de fonctionnalités (version majeure). Elle ajoute, retire ou change des fonctions, parfois l'interface entière. C'est ce type de mise à jour qui peut réellement perturber un logiciel métier ou une habitude de travail — et c'est celle qui mérite d'être testée avant un déploiement généralisé, pas appliquée en urgence le jour de sa sortie.

Beaucoup de systèmes (Windows, macOS, les plugins WordPress, les routeurs professionnels) permettent de distinguer les deux : activer l'installation automatique des correctifs de sécurité, tout en gardant un contrôle manuel sur les montées de version majeures. C'est ce réglage précis, plutôt qu'un « tout ou rien », qui répond le mieux à la fois à l'exigence de sécurité et à la crainte légitime de casser un outil métier.

Bonnes pratiques réalistes pour une TPE sans DSI

Sans service informatique dédié, l'objectif n'est pas la perfection technique mais une couverture simple et fiable sur les quatre familles d'équipements les plus courantes :

Postes de travail Windows et Mac. Activer les mises à jour automatiques dans les paramètres système (Windows Update, mises à jour logicielles macOS), en particulier les mises à jour de sécurité qui sont généralement proposées en priorité et séparément des mises à jour de fonctionnalités majeures.
Serveurs (fichiers, applications métier, hébergement du site). Les correctifs de sécurité critiques doivent être appliqués rapidement, idéalement automatiquement pour les correctifs mineurs. Pour un serveur en autogestion (VPS, serveur dédié), c'est à l'administrateur ou au prestataire d'infogérance de s'en charger — cela fait partie des interventions normalement couvertes par un contrat de maintenance.
Box, routeurs et pare-feu. Souvent oubliés car invisibles au quotidien, ils sont pourtant directement exposés à Internet. La plupart des box professionnelles et des routeurs modernes proposent une mise à jour automatique du micrologiciel (firmware) : elle doit rester activée, et le modèle vérifié de temps en temps auprès du fournisseur ou de l'opérateur pour confirmer qu'il reçoit encore des correctifs.
Logiciels métier spécifiques. Caisse, comptabilité, gestion commerciale : demander explicitement à l'éditeur ou au prestataire qui les maintient si les mises à jour de sécurité sont appliquées, et à quelle fréquence. Un logiciel « qui tourne depuis 5 ans sans qu'on y touche » est précisément le profil de risque le plus élevé.

Deux précautions simples réduisent presque à zéro le risque qu'une mise à jour pose un vrai problème :

Sauvegarder avant une mise à jour majeure. Une mise à jour de fonctionnalités qui modifie en profondeur un système mérite une sauvegarde récente avant d'être lancée, pas par méfiance excessive, mais parce que c'est le moment où un retour en arrière peut être nécessaire.
Programmer une fenêtre de maintenance en dehors des heures de travail, quand c'est possible (nuit, début de matinée, week-end) pour les redémarrages de serveurs ou d'équipements partagés, afin que l'application des correctifs ne perturbe jamais une journée de travail ou un client sur site.

La sauvegarde, filet de sécurité en cas de problème rare

Même bien gérées, les mises à jour peuvent, de façon rare, provoquer un incident : c'est précisément pour ce cas de figure, et pour bien d'autres, qu'une stratégie de sauvegarde fiable existe. La règle 3-2-1 de sauvegarde — trois copies des données, sur deux supports différents, dont une hors site — permet de revenir en arrière sereinement si une mise à jour pose un problème inattendu, sans que cela remette en cause l'intérêt des mises à jour elles-mêmes. Une TPE qui a cette sauvegarde en place peut appliquer ses correctifs de sécurité avec confiance : le pire scénario reste réversible.

Plus largement, cette logique s'inscrit dans un plan de continuité d'activité (PCA) : savoir à l'avance qui fait quoi, et avec quelles ressources de secours, si un incident — qu'il vienne d'une cyberattaque ou d'une mise à jour qui tourne mal — interrompt temporairement un outil de travail. Les mises à jour de sécurité réduisent la probabilité d'un incident grave ; la sauvegarde et le PCA réduisent l'impact du jour où un incident, quelle qu'en soit l'origine, survient malgré tout.

Checklist pratique de vérification

Postes de travail : Windows Update / mises à jour macOS activées ; vérifier la date de la dernière mise à jour installée sur chaque poste.
Serveurs : correctifs de sécurité appliqués ou planifiés à intervalle régulier ; responsabilité clairement identifiée (hébergeur, prestataire, interne).
Box et routeurs : mise à jour automatique du firmware activée ; modèle encore supporté par le fabricant (pas un équipement abandonné depuis des années).
Logiciels métier : confirmation explicite auprès de l'éditeur ou du prestataire que les correctifs de sécurité sont appliqués, et à quelle fréquence.
Sauvegarde : une copie récente et testée disponible avant toute mise à jour majeure planifiée.
Systèmes en fin de support : aucun poste ou serveur sous un système qui ne reçoit plus aucun correctif (cas de Windows 10 après la fin du support).

Questions fréquentes

Une mise à jour de sécurité peut-elle vraiment casser un logiciel métier ?

C'est rare mais possible, en particulier si le logiciel métier dépend d'une version précise d'un composant système. C'est pour cette raison qu'il faut distinguer les mises à jour de sécurité (à appliquer vite, risque faible) des mises à jour de fonctionnalités majeures (à tester avant déploiement). En cas de doute sur un logiciel métier sensible, le signaler explicitement à son éditeur plutôt que de couper toutes les mises à jour du poste.

Faut-il désactiver les mises à jour automatiques en attendant de pouvoir les tester ?

Non, pas pour les correctifs de sécurité : le risque de laisser une faille connue ouverte dépasse presque toujours le risque de régression. La bonne pratique est d'activer l'automatisation des correctifs de sécurité tout en gardant, quand l'option existe, un délai ou un contrôle manuel sur les mises à jour de fonctionnalités majeures.

Qui doit s'occuper des mises à jour dans une TPE sans service informatique ?

La responsabilité peut être répartie : les postes de travail individuels s'auto-mettent à jour une fois l'option activée ; les serveurs et équipements partagés relèvent de l'hébergeur ou d'un prestataire d'infogérance, idéalement dans le cadre d'un contrat de maintenance qui couvre explicitement ce suivi.

Conclusion

Désactiver les mises à jour de sécurité part toujours d'une bonne raison pratique — éviter un désagrément vécu une fois — mais la conséquence est la même dans tous les cas : une faille connue, corrigée par l'éditeur, reste ouverte sur vos systèmes aussi longtemps que vous le décidez. Ce n'est pas un risque théorique : les tentatives d'exploitation commencent souvent dans les jours qui suivent la divulgation publique d'une faille, comme l'a montré PHP2Shell. Activer les mises à jour automatiques, en séparant sécurité et fonctionnalités, avec une sauvegarde récente en filet de sécurité, reste l'une des mesures les plus simples et les plus rentables qu'une TPE puisse mettre en place sans compétence technique particulière.

Pour faire le point sur la sécurité de vos postes, serveurs ou de votre site, contactez-nous : on vous répond simplement, sans jargon.

À lire aussi :