Gérer les correctifs des applications tierces sur le parc

Windows Update maintient le système d'exploitation à jour, mais laisse de côté l'essentiel des logiciels réellement installés : navigateurs, lecteurs PDF, outils de visioconférence, clients de messagerie, utilitaires métier. Or c'est justement dans ces applications tierces que se concentre une grande partie des vulnérabilités activement exploitées par les attaquants. Sans processus dédié, ces logiciels dérivent silencieusement vers des versions vulnérables, poste après poste, sans que personne ne s'en aperçoive avant qu'il ne soit trop tard.

Le problème est double. D'une part, la diversité des éditeurs, chacun avec son propre rythme de publication, ses formats d'installeur et ses mécanismes de mise à jour. D'autre part, l'absence de mécanisme central pour pousser les mises à jour à l'ensemble du parc de manière fiable et vérifiable. Résultat : une même application coexiste souvent en trois ou quatre versions différentes sur le parc, dont certaines corrigées depuis des mois.

Pourquoi les applications tierces sont le maillon faible

Plusieurs facteurs se conjuguent pour faire des logiciels tiers l'angle mort de la sécurité des postes. Les comprendre aide à concevoir un processus qui les traite réellement.

• Elles se mettent souvent à jour individuellement, quand l'utilisateur y pense, ou jamais.
• Les auto-updaters sont fréquemment désactivés en entreprise ou bloqués par les droits limités des utilisateurs.
• Une même application coexiste en plusieurs versions sur le parc, dont d'anciennes vulnérables.
• Les CVE critiques (navigateurs, lecteurs de documents) sont exploitées peu après leur publication.
• Les postes en télétravail échappent souvent aux fenêtres de mise à jour prévues.

Un processus de patch à l'échelle du parc

Gérer les correctifs tiers, ce n'est pas installer une mise à jour à la main sur un poste isolé quand on y pense. C'est un cycle continu, répétable et mesuré, qui doit s'appliquer à l'ensemble des appareils de manière homogène.

1. 1Inventorier les applications installées et leurs versions exactes sur l'ensemble du parc.
2. 2Identifier celles qui sont obsolètes ou vulnérables, en s'appuyant sur les CVE connues.
3. 3Déployer la dernière version signée par l'éditeur via Intune, par vagues successives.
4. 4Vérifier le taux de réussite et relancer automatiquement sur les appareils en échec.

Le déploiement doit s'appuyer sur les vrais installeurs des éditeurs, poussés par Intune, sans dépendre de winget sur les postes, souvent absent, désactivé ou restreint dans les environnements gérés. C'est une garantie d'intégrité : on installe exactement le binaire officiel, signé par l'éditeur, et non une source intermédiaire dont on ne maîtrise pas la chaîne.

Le déploiement par vagues, un réflexe de prudence

Déployer une nouvelle version sur tout le parc d'un coup fait courir le risque qu'une régression touche tout le monde en même temps. La bonne pratique consiste à commencer par un groupe pilote restreint, à valider que tout fonctionne, puis à étendre progressivement au reste du parc. Cette approche par anneaux, familière pour Windows Update, s'applique tout aussi bien aux applications tierces et limite fortement l'impact d'un éventuel problème.

Le cas particulier des postes en télétravail

Les appareils utilisés hors des locaux posent un défi supplémentaire : ils sont rarement allumés au bon moment, souvent hors du réseau de l'entreprise, et échappent aux fenêtres de maintenance classiques. Un déploiement via Intune, qui atteint l'appareil dès qu'il est connecté à Internet et relance automatiquement en cas d'échec, résout ce problème sans dépendre d'une présence physique sur site ni d'une connexion VPN permanente.

Éviter les pièges du déploiement manuel

Beaucoup d'équipes tentent d'abord une approche artisanale, qui atteint vite ses limites dès que le parc grandit au-delà de quelques dizaines de postes.

• Empaqueter et re-tester chaque nouvelle version à la main est chronophage et source d'erreurs.
• Suivre manuellement les versions publiées par chaque éditeur est tout simplement irréaliste.
• Sans reporting, impossible de savoir si un correctif a réellement atteint tout le parc.
• Les postes en télétravail ou éteints au moment du déploiement passent entre les mailles du filet.
• Les utilisateurs sans droits administrateur ne peuvent pas installer eux-mêmes la correction.

Mesurer pour piloter dans la durée

Un processus de patch ne vaut que par sa mesure. Sans indicateurs, impossible de savoir si l'on progresse ou si des poches d'appareils vulnérables persistent au sein du parc. Quelques métriques simples suffisent à piloter l'effort et à démontrer les résultats à la direction, à un auditeur ou à un assureur cyber.

• Le délai moyen entre la publication d'un correctif et son déploiement complet.
• Le pourcentage d'appareils à jour pour chaque application critique.
• Le nombre de vulnérabilités connues encore présentes sur le parc.
• La liste des appareils récalcitrants nécessitant une intervention manuelle.

Un exemple concret de cycle de correctifs

Imaginons un parc de quatre-vingts postes sur lequel un utilitaire de compression très répandu vient de faire l'objet d'un bulletin de sécurité. L'inventaire montre que cinquante appareils sont déjà à jour, mais que trente tournent sur une version antérieure exposée à la faille. Plutôt que d'intervenir machine par machine, l'équipe cible ces trente postes, pousse l'installeur officiel de l'éditeur via Intune sur un premier groupe pilote de cinq appareils, valide l'absence de régression, puis étend au reste. Les postes éteints ou en télétravail reçoivent le correctif dès leur reconnexion.

• Partir de l'inventaire pour cibler uniquement les versions vulnérables.
• Valider d'abord sur un petit groupe pilote avant de généraliser.
• Pousser l'installeur signé par l'éditeur, sans dépendre de winget sur les postes.
• Laisser la relance automatique traiter les appareils temporairement injoignables.
• Comparer l'inventaire après déploiement à l'objectif pour clôturer la vague.

En moins d'une journée, la faille est refermée sur l'ensemble du parc, avec une trace complète du déploiement. Cet exemple illustre l'intérêt d'un processus mesuré : on ne travaille que sur les appareils réellement concernés, on limite le risque de régression grâce au pilote, et on obtient une preuve datée que la correction a bien été appliquée partout. C'est exactement ce type d'enregistrement qu'un auditeur ou un assureur cyber demande pour vérifier que les délais de correction annoncés sont tenus dans les faits.

Comment AuPoint vous aide

AuPoint industrialise ce cycle pour les PME et MSSP : inventaire des applications installées, détection des versions vulnérables et des CVE associées, puis déploiement des installeurs officiels des éditeurs via Intune, sans winget sur les endpoints. Le déploiement se fait par groupes, avec relance automatique sur les échecs et reporting du taux de couverture. Vous gardez un parc à jour et documenté, avec un tableau de bord montrant précisément ce qui reste à corriger et sur quels appareils.

Questions fréquentes

Pourquoi ne pas simplement activer les auto-updaters ?

Parce qu'ils sont hétérogènes, souvent désactivés en entreprise et incompatibles avec les droits limités des utilisateurs. Ils ne fournissent aucune preuve centralisée que la mise à jour a bien eu lieu sur chaque poste, ce qui rend le pilotage et la conformité impossibles.

Faut-il utiliser winget pour déployer les correctifs ?

Ce n'est pas recommandé en environnement géré : winget est souvent absent, désactivé ou restreint sur les postes. Il est plus fiable de pousser les installeurs officiels des éditeurs directement via Intune, ce qui garantit l'intégrité du binaire installé.

Combien de temps pour corriger une CVE critique ?

L'objectif visé est généralement de quelques jours pour une faille activement exploitée sur une application répandue. Un processus automatisé et mesuré permet de réduire ce délai et surtout de prouver qu'il a été respecté.

Comment gérer une application sans installeur silencieux ?

La plupart des éditeurs fournissent un installeur acceptant des paramètres d'installation silencieuse, adaptés à un déploiement de masse. Lorsqu'un logiciel ne le permet pas nativement, il faut préparer un paquet avec les bons commutateurs avant de le pousser via Intune. Une plateforme dédiée mutualise ce travail d'empaquetage, ce qui évite à chaque équipe de le refaire pour les applications les plus courantes.

Ne laissez plus les logiciels tiers dériver vers des versions vulnérables. Avec AuPoint, inventoriez, détectez et corrigez vos applications tierces via Intune, à l'échelle de tout le parc et sans empaquetage manuel. Demandez une démonstration pour voir l'état réel de vos correctifs applicatifs.