
Ce qui s’est passé
Deux éditeurs très présents dans les PME ont publié des correctifs de sécurité urgents en novembre 2026. Une troisième alerte concerne un problème iOS qui n’a pas encore de correctif confirmé.
Google Chrome : une 8e faille zero-day en 2026
Google a publié une mise à jour de sécurité de Chrome. Elle corrige une faille zero-day (faille déjà utilisée par des pirates avant qu’un correctif existe), la huitième exploitée dans des attaques depuis le début de 2026. L’identifiant de la faille, le composant touché et les numéros de versions corrigées figurent dans le bulletin de sécurité de Google. Servez-vous de ces numéros comme référence pour vérifier votre parc.
Chrome partage son moteur (Chromium) avec d’autres navigateurs, dont Microsoft Edge. Ces navigateurs reçoivent en général le correctif peu après Google. Vérifiez aussi l’état d’Edge sur vos postes.
Apple : une vague de correctifs sur toute la gamme
Apple a publié en novembre 2026 une vague de mises à jour de sécurité. Des correctifs touchent les différents systèmes de l’éditeur. Le SANS Internet Storm Center maintient son niveau d’alerte global au vert (InfoCON: green). Cette vague corrige notamment des failles de confidentialité dans les discussions de groupe iMessage et des failles dans l’appairage Bluetooth (connexion d’un appareil à un autre sans fil).
iOS : une sortie d’isolement sans correctif confirmé
La plateforme de cryptomonnaies Binance met en garde contre une faille iOS de type « sandbox escape ». Sur un iPhone, chaque application tourne dans un « bac à sable » (une zone isolée qui l’empêche de lire les données des autres applications). Une sortie de ce bac à sable permet à une application de franchir cette barrière. La faille pourrait exposer les clés de portefeuilles de cryptomonnaies, et aucun correctif n’est confirmé à ce jour.
Pourquoi ça compte pour une PME
- Le navigateur est la porte d’entrée la plus utilisée. Vos employés y ouvrent vos courriels web, votre CRM, votre comptabilité en ligne et vos outils infonuagiques. Une faille zero-day de navigateur peut être déclenchée par une simple visite d’une page piégée. Il n’y a souvent ni pièce jointe ni clic suspect qui pourrait alerter l’utilisateur.
- Huit zero-days en onze mois : les attaques contre Chrome ne sont plus exceptionnelles. Elles reviennent en moyenne presque une fois par mois. Une mise à jour manuelle « quand on y pense » ne suit plus ce rythme.
- Une mise à jour téléchargée ne protège pas tant que le navigateur n’a pas redémarré. Beaucoup d’utilisateurs gardent Chrome ouvert pendant des semaines. Le poste affiche alors « à jour » mais reste vulnérable.
- Le téléphone, c’est l’entreprise dans une poche. L’iPhone donne accès aux courriels, aux codes d’authentification multifacteur (MFA, la deuxième étape de connexion), aux messageries et parfois aux applications bancaires. Une faille d’isolement des applications veut dire qu’une seule application malveillante ou compromise pourrait accéder à des données d’autres applications.
- Niveau de risque : élevé pour Chrome et Edge non mis à jour, car la faille est déjà exploitée. Moyen à élevé pour les appareils Apple non corrigés, selon leurs usages. À surveiller pour la faille iOS sans correctif : la seule protection pour l’instant est de limiter ce qui est installé sur les téléphones.
Comment se protéger
Priorité 1 : traiter la faille Chrome comme un incident (sous 24 à 72 h)
Dans une logique ITIL, une faille déjà exploitée ne relève pas du cycle normal de gestion des vulnérabilités. Ouvrez un changement urgent, avec un responsable désigné et une échéance claire.
- Comparez la version de Chrome et d’Edge installée sur vos postes aux versions corrigées indiquées dans les bulletins de Google et de Microsoft.
- Forcez la mise à jour et le redémarrage du navigateur (voir ci-dessous).
- Fermez le changement seulement quand 100 % des postes actifs ont la bonne version. Documentez les exceptions.
Vérification rapide sur un poste Windows (PowerShell) :
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion
(Get-Item "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe").VersionInfo.ProductVersion
Sur un Mac (Terminal) :
defaults read "/Applications/Google Chrome.app/Contents/Info.plist" CFBundleShortVersionString
Priorité 2 : automatiser Chrome et Edge par stratégie de groupe (GPO)
Importez les modèles d’administration (ADMX) de Google Chrome, de Google Update et de Microsoft Edge dans votre magasin central. Ensuite, appliquez une GPO aux postes avec ces paramètres :
- Mises à jour toujours autorisées : interdire la désactivation des mises à jour automatiques.
- Redémarrage obligatoire : « RelaunchNotification » réglé sur « Obligatoire » (valeur 2). Le navigateur prévient l’utilisateur, puis redémarre de lui-même à la fin du délai.
- Délai de redémarrage : « RelaunchNotificationPeriod » en millisecondes. 86 400 000 correspond à 24 h, ce qui laisse de la marge sous l’objectif de 72 h.
Équivalent en registre (utile pour tester sur un poste ou pour un outil RMM) :
:: Google Chrome
reg add "HKLM\SOFTWARE\Policies\Google\Update" /v UpdateDefault /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v RelaunchNotification /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v RelaunchNotificationPeriod /t REG_DWORD /d 86400000 /f
:: Microsoft Edge
reg add "HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate" /v UpdateDefault /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v RelaunchNotification /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v RelaunchNotificationPeriod /t REG_DWORD /d 86400000 /f
Vérifiez sur un poste test avec chrome://policy et edge://policy que les stratégies sont bien appliquées avant de déployer sur tout le parc.
Priorité 3 : sans domaine Windows, passer par la console Google ou Intune
- Console d’administration Google (Chrome Enterprise Core, gratuit) : inscrivez les navigateurs, puis réglez la notification de redémarrage sur « obligatoire » avec un délai court. Le tableau de bord montre les versions installées sur chaque poste, ce qui sert de preuve de conformité.
- Microsoft Intune : les mêmes paramètres Chrome et Edge existent dans le catalogue de paramètres. C’est la solution adaptée pour des postes en télétravail qui ne sont pas reliés à un domaine.
Priorité 4 : gérer les iPhone et les Mac avec un outil MDM
Un outil MDM (gestion des appareils mobiles, par exemple Intune, Jamf ou un équivalent) permet d’imposer les mises à jour au lieu de compter sur la bonne volonté de chacun.
- Imposez une version cible avec une date limite : les MDM récents permettent de fixer une version minimale d’iOS ou de macOS et une échéance. Passé ce délai, l’appareil installe la mise à jour et redémarre.
- Ajoutez une règle de conformité : un appareil sous la version minimale perd l’accès aux courriels et aux applications d’entreprise (accès conditionnel). C’est le moyen le plus efficace de motiver les retardataires.
- Appareils personnels (BYOD) : inscrivez-les au minimum en mode « utilisateur » pour séparer les données d’entreprise et vérifier la version du système.
Vérification d’un Mac sans MDM (Terminal) :
softwareupdate -l
Priorité 5 : prudence face à la faille iOS sans correctif
Tant qu’aucun correctif n’est confirmé, la seule façon de réduire le risque est de contrôler ce qui est installé sur les téléphones utilisés pour le travail :
- Faites l’inventaire des applications installées sur les téléphones gérés. Supprimez celles qui sont inutiles, peu connues ou de développeurs douteux.
- Avec le MDM, limitez si possible l’installation d’applications à une liste approuvée.
- Ne conservez pas de secrets sensibles sur le téléphone : clés de portefeuilles crypto, mots de passe notés en clair, codes de récupération.
- Appliquez la mise à jour iOS dès qu’Apple publie un correctif, en suivant la même règle de 72 h.
Synthèse des délais recommandés
| Situation | Délai maximal | Processus ITIL |
|---|---|---|
| Faille déjà exploitée (zero-day Chrome) | 72 h, redémarrage compris | Changement urgent |
| Correctifs Apple de sécurité (iOS, macOS) | 72 h pour les failles exploitées, sinon 14 jours | Changement standard pré-approuvé |
| Faille sans correctif (sortie d’isolement iOS) | Mesures d’atténuation immédiates | Gestion des problèmes, avec suivi jusqu’au correctif |
Qui alerter
- À l’interne : le responsable TI ou votre fournisseur de services gérés (MSP), pour lancer le changement. La direction doit être informée si l’échéance de 72 h ne peut pas être respectée.
- Les employés : un message court qui demande de ne pas reporter les redémarrages du navigateur ni du téléphone, et de signaler toute application suspecte.
- En cas de compromission soupçonnée : isolez l’appareil, réinitialisez les mots de passe et les sessions associées, puis suivez votre processus de gestion des incidents.