Gestion des correctifs tiers : pourquoi c'est essentiel et comment l'automatiser

Le tableau de bord de conformité des correctifs indique 96 %. Windows est à jour, macOS est à jour, l'équipe de sécurité donne son feu vert et le rapport est transmis à l'auditeur. Le problème, c'est que ce 96 % ne concerne que le système d'exploitation. Le terminal qui se cache derrière cette tuile verte utilise également une version de Chrome datant de la fin de l'été, une version d'Adobe Reader pour laquelle trois vulnérabilités (CVE) ont été publiées, un client Zoom antérieur au dernier avis de sécurité et un runtime Java dont personne dans l'équipe ne s'est soucié depuis dix-huit mois. Rien de tout cela n'apparaît dans le score.

C'est précisément cette lacune que la gestion des correctifs tiers est censée combler ; or, pour la plupart des équipes informatiques et des MSP, il s'agit de la partie du programme de mise à jour qui souffre d'un sous-financement discret par rapport au risque réel qu'elle représente. L'étude comparative 2026 de Qualys sur les entreprises estime le délai moyen de correction pour les applications tierces complexes à cinq mois et dix jours. Les pirates agissent dans un délai de quelques jours, voire de quelques heures. Ces deux délais sont incompatibles.

Les solutions RMM de Kaseya gèrent la gestion des correctifs sur des millions de terminaux pour les MSP et les équipes informatiques internes du monde entier, offrant ainsi une vision claire des points forts et des faiblesses des programmes de gestion des correctifs tiers lorsqu’ils sont mis à rude épreuve. Ce guide explique en quoi consiste la gestion des correctifs tiers, pourquoi son fonctionnement est plus complexe que celui des correctifs de système d’exploitation, quelles sont les priorités à établir, comment mettre en place le programme sur le plan opérationnel et ce que l’automatisation doit apporter pour suivre le rythme des mises à jour.

Qu'est-ce que la gestion des correctifs tiers ?

La gestion des correctifs tiers consiste à identifier, évaluer, déployer et vérifier les mises à jour des logiciels exécutés sur vos terminaux qui ne sont pas fournis par l'éditeur du système d'exploitation. Il s'agit d'une catégorie très large. Elle comprend les navigateurs, les lecteurs de PDF, les clients de visioconférence, les environnements d'exécution tels que Java et .NET, les suites bureautiques, les outils de développement, les utilitaires de compression, ainsi que la multitude d'applications métier qui s'accumulent au fil du temps dans n'importe quel environnement.

Cette pratique s'inscrit dans le cadre plus large de la gestion des correctifs, au même titre que la mise à jour des systèmes d'exploitation, mais elle est soumise à des contraintes différentes. Microsoft, Apple et les principales distributions Linux diffusent leurs mises à jour via des canaux standardisés et bien documentés. Ce n'est pas le cas des éditeurs tiers. Il n'y a pas de « Patch Tuesday » pour Slack. Aucun catalogue central ne relie le calendrier de publication d’Adobe à celui de Mozilla, à celui d’Oracle, ni à l’application métier de niche que l’équipe financière a installée en 2019. Chaque fournisseur publie à son propre rythme, dans son propre format, via son propre canal, et quelqu’un doit suivre l’ensemble de ces publications simultanément.

Le terme « tiers » recouvre ici un champ très large. Il englobe aussi bien un navigateur utilisé par tous les employés de l'entreprise qu'un outil d'ingénierie spécialisé installé sur trois machines. Ces deux cas relèvent du même cadre opérationnel et peuvent tous deux constituer un point d'entrée pour une intrusion.

Pourquoi les correctifs tiers sont plus importants que jamais

Pendant des années, on a considéré que les failles des systèmes d'exploitation constituaient la principale préoccupation, les applications n'étant qu'un souci secondaire. Ce n'est plus le cas depuis un certain temps. Les données ont progressivement confirmé ce que les pirates savaient déjà.

L'enquête « State of Patch Management 2025 » menée par Adaptiva en collaboration avec Demand Metric a révélé que 87 % des entreprises avaient été confrontées, au cours de l'année précédente, à des vulnérabilités dans des applications tierces nécessitant l'application de correctifs. Il ne s'agit pas là d'un cas isolé, mais bien de la norme dans presque tous les environnements informatiques utilisant des logiciels modernes.

Le catalogue des vulnérabilités connues et exploitées (KEV) de la CISA illustre ce même phénomène sous un autre angle. La liste KEV recense les vulnérabilités activement exploitées par les pirates, et non pas uniquement celles qui sont théoriques et notées selon le CVSS ; une part constante des nouvelles entrées concerne des applications tierces plutôt que les systèmes d'exploitation de base. Les navigateurs, les lecteurs de documents, les outils de conférence et les bibliothèques d'exécution apparaissent mois après mois. Ils sont largement déployés, leurs mises à jour de sécurité sont fréquentes, et c'est dans le délai entre la publication par le fournisseur et l'installation par l'utilisateur final que les attaquants agissent.

Le rythme ajoute une difficulté supplémentaire. Le « Patch Tuesday » d'avril 2026 de Microsoft a permis de corriger 163 vulnérabilités (CVE) rien que pour sa propre suite logicielle. Ajoutez à cela les suites d'Adobe, d'Oracle, de Google, de Mozilla, de Cisco, d'Atlassian et d'une douzaine d'autres éditeurs, et le volume mensuel auquel tout programme de mise à jour est censé faire face commence à sembler véritablement écrasant. L'examen manuel d'un flux de cette ampleur n'est pas une stratégie viable.

Le rapport 2025 de Verizon sur les enquêtes relatives aux violations de données a révélé que l'exploitation de vulnérabilités constituait le vecteur d'accès initial dans 20 % des cas — soit une hausse de 34 % par rapport à l'année précédente. Cette augmentation ne s'explique pas uniquement par les failles « zero-day » au niveau du système d'exploitation. Elle reflète l'utilisation croissante des vulnérabilités présentes dans des logiciels tiers que les entreprises ignoraient utiliser ou n'avaient pas encore pris le temps de corriger.

Les défis liés à la gestion des correctifs tiers

Une fois que l'on sait que le risque est bien réel, on se demande naturellement pourquoi tant de programmes laissent malgré tout cette faille ouverte. La réponse est d'ordre technique, et non motivé par des considérations de fond. L'application de correctifs à des logiciels tiers est structurellement plus difficile que celle à un système d'exploitation, et ce pour quatre raisons étroitement liées.

Fragmentation du marché des fournisseurs

L'infrastructure de mise à jour de Microsoft gère les logiciels Microsoft. Celle d'Apple gère macOS. Il n'existe pas de canal unifié équivalent pour les autres logiciels. Chaque éditeur de logiciels gère son propre portail de mises à jour, son propre format d'avis et son propre mécanisme de distribution. Suivre manuellement les mises à jour de 50 ou 100 applications tierces implique de s'abonner à des dizaines de flux distincts et de traduire chacun d'entre eux en actions concrètes. C'est une tâche à plein temps pour laquelle la plupart des équipes ne disposent pas des effectifs nécessaires.

Variabilité de la cadence

Le « Patch Tuesday » vous offre un calendrier régulier pour Windows. Les mises à jour des éditeurs tiers, elles, n’en suivent pas. Un correctif critique pour un navigateur peut être publié en milieu de semaine. Une mise à jour d'exécution peut être déployée sans avis préalable. Un outil de visioconférence peut publier une version de sécurité le jour même où un fournisseur de pilotes d'imprimante publie un CVE. Le volume n'est pas prévisible, pas plus que le moment de publication, ce qui signifie qu'un programme de correctifs basé sur une cadence mensuelle manquera systématiquement, par nature, les mises à jour urgentes des éditeurs tiers.

Diversité des installateurs

Les correctifs du système d'exploitation sont fournis via des mécanismes standardisés. Les applications tierces utilisent les formats MSI, EXE, MSIX, App-V, des programmes de mise à jour propres à chaque éditeur, des programmes d'installation en ligne et, parfois, des scripts de déploiement sur mesure. Chaque format dispose de ses propres paramètres d'installation silencieuse, de son propre comportement en matière de redémarrage, de sa propre logique de détection de version et de ses propres modes d'échec. Pour automatiser ce processus de manière fiable malgré cette diversité, il faut soit un outil offrant une prise en charge testée par les éditeurs pour chaque application, soit des scripts personnalisés gérés par votre équipe, et ce de manière permanente.

Découverte

On ne peut pas corriger ce dont on ignore l'existence. Les utilisateurs installent des applications en dehors des canaux approuvés par le service informatique. Les acquisitions s'accompagnent d'un parc logiciel non géré. Certains services adoptent des outils dont personne n'a informé l'équipe chargée des terminaux. Sans un processus de découverte continu, basé sur des agents, qui recense toutes les applications et versions installées sur chaque appareil géré, le programme de correctifs s'appuie sur un inventaire erroné avant même d'avoir commencé.

Ces quatre contraintes ne disparaissent pas, quels que soient les efforts déployés. Elles sont inhérentes à l'écosystème des logiciels tiers lui-même. Un programme efficace est celui qui s'adapte à ces contraintes plutôt que de tenter de les contrer.

Quelles applications faut-il privilégier en premier lieu ?

Toutes les applications tierces ne présentent pas le même niveau de risque ; or, les traiter comme un ensemble homogène revient à exposer les programmes autant que s’il n’y en avait aucun. La bonne approche consiste à les classer par niveau en fonction de leur empreinte de déploiement, de leur historique d’exploitation et de leur proximité avec la périphérie du réseau, puis à concentrer la fréquence des opérations et les accords de niveau de service (SLA) sur le niveau le plus élevé.

Les navigateurs figurent en tête de presque toutes les listes. Chrome, Edge, Firefox et Brave sont installés sur chaque terminal, affichent par définition du contenu non fiable provenant d’Internet et reçoivent des mises à jour de sécurité plusieurs fois par mois. Ils ont également pour habitude de reporter l’application des mises à jour jusqu’au redémarrage, ce qui signifie qu’un correctif disponible n’est appliqué qu’une fois que l’utilisateur a fermé la fenêtre. Un accord de niveau de service (SLA) de 24 à 48 heures pour les mises à jour critiques des navigateurs, assorti de mesures coercitives, constitue une base de référence raisonnable.

Viennent ensuite les lecteurs de PDF et de documents. Adobe Acrobat et Reader présentent une longue liste de vulnérabilités CVE critiques et ont depuis longtemps été la cible de documents malveillants diffusés par e-mail. La mise à jour de chaque terminal vers la version la plus récente constitue le moyen le plus économique dont disposent la plupart des équipes pour réduire de manière significative le taux de réussite des attaques de phishing.

Les environnements d'exécution constituent le troisième groupe. Java, OpenJDK, les environnements d'exécution .NET et divers moteurs JavaScript sous-tendent des applications métier qui ne sont pas toujours identifiées comme des dépendances distinctes par les outils de sécurité. Une vulnérabilité dans un environnement d'exécution affecte toutes les applications qui s'appuient sur celui-ci, et son champ d'action peut être vaste, même lorsque l'environnement d'exécution lui-même semble peu connu.

Les clients dédiés à la visioconférence et à la collaboration constituent un quatrième niveau. Zoom, Teams (dans sa version autonome), Slack et les outils similaires sont installés partout, interagissent avec des liens et des fichiers externes non fiables, et sont mis à jour fréquemment. Leur surface d'attaque est similaire à celle d'un navigateur, même si leur visibilité dans l'inventaire des actifs est différente.

Les utilitaires de compression, les outils d'archivage, les dépendances des développeurs et la multitude d'applications métier complètent le tableau. Chacun de ces éléments représente une part non négligeable du risque, et le cadre approprié pour les hiérarchiser est le même modèle basé sur le risque qui devrait régir l'application des correctifs du système d'exploitation : gravité (CVSS), statut d'exploitation (liste KEV, flux de renseignements sur les menaces, exploits publics) et contexte métier (exposition à Internet, données sensibles, potentiel de mouvement latéral). Pour en savoir plus sur l'intégration de ce cadre dans un programme plus large, consultez les meilleures pratiques en matière de gestion des correctifs.

Bonnes pratiques en matière de correctifs tiers : comment mettre en place un programme

Un programme de correction de correctifs tiers efficace suit le même schéma général que le processus global de gestion des correctifs, mais sa mise en œuvre à chaque étape doit tenir compte de la complexité supplémentaire inhérente aux logiciels tiers.

L'inventaire doit être continu, piloté par un agent et exhaustif. Un audit logiciel hebdomadaire du registre des actifs ne suffit pas. L'agent doit recenser toutes les applications installées, toutes les versions et toutes les instances installées par les utilisateurs sur chaque terminal géré, avec une mise à jour en temps quasi réel. Chaque fois que cette visibilité fait défaut, le programme de mise à jour est d'autant plus aveugle.

La surveillance repose sur le même principe. Une fois que vous savez ce qui est installé, vous avez besoin d'un flux qui vous indique quand chaque éditeur publie une mise à jour de sécurité, idéalement classée par niveau de gravité. Créer ce flux en interne pour une cinquantaine d'éditeurs représente un travail considérable. La solution la plus réaliste consiste à utiliser un outil de gestion des correctifs dont l'éditeur ajoute les nouvelles versions à un catalogue testé dans les heures qui suivent leur publication, ce qui permet à l'équipe de se contenter d'un seul flux au lieu de cinquante.

C'est au niveau de la hiérarchisation des priorités que la mise à jour des applications tierces s'écarte le plus souvent de celle du système d'exploitation dans la pratique opérationnelle. La classification des risques décrite ci-dessus s'intègre directement à votre structure de SLA, qui doit être clairement définie dans votre politique de gestion des correctifs. Une politique qui identifie les applications tierces, les classe par niveau de gravité avec des SLA précis et exige que les exceptions soient documentées permet d'éliminer la hiérarchisation implicite « le système d'exploitation d'abord, les applications tierces ensuite », qui est à l'origine même de cette lacune.

Les tests sont vraiment différents. Les correctifs pour les systèmes d'exploitation sont validés par Microsoft, Apple ou le responsable de maintenance Linux concerné avant leur publication. Les correctifs tiers sont validés par l'éditeur de logiciels et, dans l'idéal, par le service d'assurance qualité du catalogue de votre plateforme de gestion des correctifs. Le risque résiduel concerne l'interaction entre les applications : une mise à jour de navigateur qui modifie le comportement de rendu et perturbe une application web interne, une mise à jour du runtime Java qui fait apparaître des problèmes de compatibilité avec un progiciel métier, une version de Teams qui affecte une intégration personnalisée. Un petit groupe pilote de terminaux représentatifs, avec un délai de 24 à 48 heures pour les mises à jour de routine et un test de fumée condensé pour les vulnérabilités activement exploitées, permet de détecter la plupart de ces problèmes avant qu'ils n'atteignent l'environnement de production.

Le déploiement applique la mise à jour testée au reste du parc informatique selon les fenêtres de maintenance que vous avez définies, avec une logique de nouvelle tentative pour les terminaux qui étaient hors ligne lors de la première tentative et des procédures de restauration en cas d'échec. C'est la partie du programme qui pose le plus de problèmes lorsqu'elle est exécutée manuellement, car le volume de travail accapare toutes les heures disponibles et la gestion des exceptions prend le pas sur les tâches courantes.

La vérification permet de boucler la boucle. L'indicateur de conformité qui vous intéresse est la version installée, et non l'état du déploiement. Un rapport de déploiement peut indiquer « envoyé », alors qu'un échec silencieux du programme d'installation laisse l'ancienne version sur l'appareil. C'est la vérification, application par application et appareil par appareil, de la version en cours d'exécution qui vous permet de savoir si le correctif a bien été appliqué.

Le reporting porte sur chaque application, et non sur chaque appareil. Un appareil équipé de la dernière version de Chrome mais dont la version de Java date de trois versions n'est en aucun cas conforme selon les critères d'un auditeur. Le reporting doit être ventilé par application, par niveau de gravité et par manquement au SLA, avec les ventilations par client dont les MSP ont besoin pour établir les attestations destinées à leurs clients.

Pourquoi la gestion automatisée des correctifs par un tiers est indispensable

Sans cela, les chiffres ne tiennent pas la route. Cinquante applications tierces, des dizaines de mises à jour par mois pour chaque grand fournisseur, des centaines voire des milliers de terminaux, des calendriers de mise à jour des fournisseurs qui ne concordent pas, et des accords de niveau de service (SLA) mesurés en heures pour les correctifs les plus critiques. Aucune équipe ne peut gérer tout cela manuellement — et celles qui s’y essaient prennent d’abord du retard sur les logiciels tiers, car c’est là que le coût d’un tel retard est le moins visible au quotidien.

La gestion automatisée des correctifs décharge l'équipe des tâches routinières : détecter qu'une application a besoin d'une mise à jour, récupérer le package testé dans le catalogue, le déployer via une installation silencieuse pendant la fenêtre de maintenance convenue, gérer les redémarrages et réessayer en cas d'échec. Les intervenants humains restent impliqués dans la gestion des exceptions, l'approbation des fenêtres de changement pour les systèmes sensibles et le petit pourcentage d'applications qui nécessitent réellement une intervention manuelle.

Il convient de souligner deux aspects spécifiques à l'automatisation par des tiers, car ils ne sont pas suffisamment pris en compte dans le débat général sur l'automatisation.

Le premier critère est la qualité du catalogue. L'efficacité de l'automatisation dépend entièrement de la qualité du catalogue d'applications qui l'alimente. Une plateforme qui met deux semaines à intégrer une mise à jour critique de navigateur n'offre, pendant toute la durée de ce délai, aucune valeur ajoutée en matière de sécurité. Les questions à se poser lors de l'évaluation de toute solution de correctifs tierce sont les suivantes : combien d'applications sont prises en charge dès l'installation, à quelle vitesse le catalogue intègre-t-il les nouvelles versions des éditeurs (en particulier pour les mises à jour de sécurité), et quel contrôle qualité est appliqué à chaque package avant qu'il n'atteigne les terminaux de production ?

Le deuxième aspect concerne la surface de dépendance. Un correctif système d'exploitation mal conçu risque de perturber le fonctionnement du système. Un correctif tiers défectueux a tendance à perturber le fonctionnement de l'application qui en dépend, ce qui peut concerner un flux de travail métier, une intégration ou un outil de productivité utilisé par l'ensemble de l'entreprise. Les mesures d'atténuation sont les mêmes que pour tout programme de correctifs : anneaux de déploiement, périodes de retenue, retour en arrière automatisé. Cependant, la tolérance opérationnelle à la défaillance est plus faible, car les utilisateurs remarquent plus rapidement une panne d'Adobe Reader qu'une mise à jour du noyau.

L'aspect de la conformité

Les cadres de conformité ne considèrent plus les logiciels tiers comme un sujet distinct. L'exigence 6.3.3 de la norme PCI DSS 4.0 s'applique à l'ensemble des composants du système, y compris les applications, et pas seulement aux systèmes d'exploitation. L'annexe A, paragraphe 8.8, de la norme ISO 27001:2022 traite de la gestion des vulnérabilités techniques sans exception. La règle de sécurité de l'HIPAA a été interprétée, dans le cadre de mesures coercitives, comme couvrant l'application de correctifs aux applications dans le cadre de mesures de protection « raisonnables et appropriées ». La directive NIS2, en vigueur dans tous les États membres de l'UE, exige la preuve d'un traitement rapide des vulnérabilités, sans distinction entre le système d'exploitation et les applications. Le critère CC7.1 des services de confiance SOC 2 couvre la surveillance et la correction des nouvelles vulnérabilités à l'échelle du système.

Dans tous les cas, les conséquences pratiques sont les mêmes. Un audit qui examine votre programme de mise à jour et détecte des navigateurs non gérés, des lecteurs PDF non mis à jour ou des environnements d'exécution Java en fin de vie donnera lieu à des constatations, quelle que soit la qualité apparente de votre rapport de conformité Windows. Pour contrer ces constatations, il faut présenter des preuves opérationnelles : des rapports de conformité par application, des registres de déploiement datés, des exceptions documentées et des accords de niveau de service (SLA) respectés dans la pratique et pas seulement sur le papier.

Comment Kaseya simplifie l'application des correctifs tiers

La gestion des correctifs tiers n'est pas un problème de connaissances. Toutes les équipes informatiques et tous les MSP savent que les applications doivent être mises à jour. Il s'agit d'un problème opérationnel, et ce problème est de nature structurelle : il y a davantage de fournisseurs, de cadences de mise à jour, de formats d'installation et de surfaces de détection, et le workflow par défaut privilégie les correctifs du système d'exploitation, car ceux-ci sont plus faciles à mettre en place.

Pour y remédier, il faut cesser de considérer les solutions tierces comme un programme parallèle et les intégrer dans le même cadre que les activités déjà en cours. Même inventaire. Même hiérarchisation des risques. Mêmes SLA dans la politique. Mêmes anneaux de déploiement. Même automatisation. Mêmes rapports de conformité par application. Les outils sous-jacents doivent prendre en charge un catalogue tiers testé au rythme auquel les fournisseurs le publient, mais la conception du programme n’est pas un programme différent. C’est le même programme, dans son intégralité.

C'est sur ce principe de conception que reposent les solutions RMM de Kaseya : l'application des correctifs pour les systèmes d'exploitation, les logiciels tiers et les micrologiciels s'effectue via un seul agent, un seul cadre de politiques, un seul ensemble de créneaux de maintenance et une seule vue de conformité. Le module « Advanced Software Management » de Datto RMMcorrespond à cette fonctionnalité dédiée aux logiciels tiers ; il étend la couverture des correctifs à plus de 200 applications prêtes à l'emploi, grâce à un catalogue testé sur des millions d'appareils avant sa mise en service et en constante évolution.

Ce module prend également en charge l'installation et la désinstallation d'applications via ce même cadre de politiques, comblant ainsi une lacune que la plupart des outils de mise à jour laissent ouverte : les applications en fin de vie qui doivent être supprimées, et pas seulement mises à jour, avant qu'elles ne soient exploitées. Pour les MSP, cela se traduit par une configuration des politiques et des rapports de conformité par client à partir d’une seule console. Pour les équipes informatiques internes, il s’agit d’une vue unifiée de l’état des correctifs du système d’exploitation et des logiciels tiers, accompagnée de la piste d’audit attendue par les cadres de conformité, générée comme un sous-produit du flux de travail plutôt que comme un exercice trimestriel de collecte de preuves.

L'alternative consiste à laisser une surface d'attaque répertoriée exposée alors que le tableau de bord des correctifs du système d'exploitation reste au vert. C'est précisément cette faille sur laquelle misent les pirates — et les données actuelles sur les exploits montrent qu'ils ont raison.