Gestion des correctifs tiers : pourquoi c'est essentiel et comment automatiser les processus informatiques

Le tableau de bord de conformité des correctifs indique un taux de 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 taux de 96 % ne concerne que les systèmes d’exploitation. Le terminal représenté par cette tuile verte exécute é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 environnement d’exécution Java dont personne dans l’équipe ne s’est soucié depuis dix-huit mois. Aucun de ces éléments n’apparaît dans le score.

C’est cette lacune que la gestion des correctifs tiers est censée combler, et pour la plupart des équipes informatiques et des MSP, il s’agit de la partie du programme de correctifs qui est discrètement sous-financée 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 attaquants opèrent dans un délai qui se mesure en jours, voire parfois en heures. Ces deux délais ne sont pas compatibles.

Les solutions RMM de Kaseya gèrent la gestion des correctifs sur des millions de terminaux pour le compte de prestataires de services informatiques (MSP) et d’équipes informatiques internes à travers le monde, offrant ainsi une vision opérationnelle 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 vaste. Elle englobe 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 celle des correctifs du système 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 à celui de l’application métier de niche que l’équipe financière a installée en 2019. Chaque éditeur publie ses mises à jour selon son propre rythme, dans son propre format et via son propre canal, et quelqu’un doit en assurer le suivi simultané.

Le terme « tiers » recouvre ici un champ très large. Il englobe aussi bien un navigateur utilisé par tous les collaborateurs 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 vulnérabilités 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 situation par défaut de la quasi-totalité des 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 attaquants, et non pas uniquement celles qui sont théoriques et notées selon le score CVSS ; une part constante des nouvelles entrées concerne des applications tierces plutôt que les systèmes d’exploitation eux-mêmes. Navigateurs, lecteurs de documents, outils de visioconférence et bibliothèques d’exécution apparaissent mois après mois. Ces applications sont largement déployées, 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 corrigé 163 CVE rien que pour sa propre pile logicielle. Ajoutez à cela les piles 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 correctifs est censé faire face commence à paraître 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 fuites de données a révélé que l’exploitation de vulnérabilités constituait le vecteur d’accès initial dans 20 % des incidents, soit une hausse de 34 % par rapport à l’année précédente. Cette augmentation ne provient pas uniquement des 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 dont les entreprises ignoraient l’existence ou qu’elles 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 motivationnelle. L'application de correctifs à des logiciels tiers est structurellement plus difficile que celle appliquée aux systèmes d'exploitation, et ce pour quatre raisons étroitement liées.

Fragmentation 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 le reste. Chaque éditeur de logiciels indépendant (ISV) gère son propre portail de publication, son propre format d’avis et son propre mécanisme de diffusion. 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 fonction à temps plein 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 ne suivent pas ce rythme. Un correctif critique pour un navigateur peut être publié en milieu de semaine. Une mise à jour d’environnement d’exécution peut être déployée sans préavis. 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. Ni le volume ni le calendrier ne sont prévisibles, ce qui signifie qu’un programme de mise à jour basé sur une cadence mensuelle manquera systématiquement, de par sa conception, 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 spécifiques aux éditeurs, des programmes d'installation en ligne et, parfois, des scripts de déploiement sur mesure. Chaque format possède ses propres paramètres d'installation silencieuse, son propre comportement en matière de redémarrage, sa propre logique de détection de version et ses propres modes d'échec. Pour automatiser de manière fiable cette grande 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 indéfiniment.

Découverte

On ne peut pas appliquer de correctifs à 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 de parcs logiciels non gérés. 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 qui fonctionne est un programme conçu en tenant compte de ces contraintes plutôt qu'en cherchant à les contrer.

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

Toutes les applications tierces ne présentent pas le même risque ; les traiter comme un ensemble homogène revient à considérer que les programmes exposent l'entreprise 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 cadence des interventions et les 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 reportent également souvent l’application des mises à jour jusqu’au redémarrage, ce qui signifie qu’un correctif disponible n’est pas appliqué tant que l’utilisateur n’a pas fermé la fenêtre. Un SLA de 24 à 48 heures pour les mises à jour critiques des navigateurs, assorti d’une application stricte, 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. Disposer d’une version à jour sur chaque terminal constitue, pour la plupart des équipes, le moyen le plus économique de réduire de manière significative les taux de réussite des charges utiles de hameçonnage.

Les environnements d'exécution constituent le troisième groupe. Java, OpenJDK, les environnements d'exécution .NET et divers moteurs JavaScript sont à la base d'applications métier qui ne sont pas nécessairement 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'impact peut être considérable, même lorsque l'environnement d'exécution lui-même semble peu connu.

Les clients dédiés aux conférences 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 font l'objet de mises à jour fréquentes. 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 longue liste des applications métier complètent le tableau. Chacun de ces éléments représente une part significative du risque, et le cadre approprié pour les classer 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 bonnes 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 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 qu'implique l'utilisation d'un logiciel 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 correctifs 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 n’utiliser qu’un seul flux au lieu de cinquante.

C’est au niveau de la hiérarchisation des priorités que la gestion des correctifs tiers s’écarte le plus souvent de celle des correctifs du système d’exploitation dans la pratique opérationnelle. La classification des risques décrite ci-dessus alimente directement votre structure de SLA, qui doit être explicitement codifiée dans votre politique de gestion des correctifs. Une politique qui identifie les applications tierces, les classe par niveau de gravité avec des SLA clairement définis et exige que les exceptions soient documentées élimine 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 véritablement différents. Les correctifs des 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 indépendant (ISV) et, dans l’idéal, par le service d’assurance qualité du catalogue de votre plateforme de gestion des correctifs. Le risque résiduel réside dans les interactions entre applications : une mise à jour de navigateur qui modifie le comportement d’affichage et perturbe le fonctionnement d’une application web interne, une mise à jour du runtime Java qui fait apparaître des problèmes de compatibilité avec un progiciel métier, ou encore une version de Teams qui affecte une intégration personnalisée. Un petit groupe pilote composé de terminaux représentatifs, avec un délai de 24 à 48 heures pour les mises à jour de routine et un test de validation accéléré 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 transfère la mise à jour testée vers le reste du parc informatique, en respectant les fenêtres de maintenance que vous avez définies. Il intègre une logique de nouvelle tentative pour les terminaux qui étaient hors ligne lors de la première tentative, ainsi que 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 est en retard 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 prestataire tiers est-elle indispensable ?

Sans cela, les chiffres ne tiennent pas la route. Cinquante applications tierces, des dizaines de versions par mois pour chaque grand éditeur, des centaines voire des milliers de terminaux, des cadences de mise à jour des éditeurs qui ne s’alignent pas, et des SLA mesurés en heures pour les correctifs présentant le plus grand risque. 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 de ce 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 nécessite 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 continuent d'intervenir pour la gestion des exceptions, l'approbation des fenêtres de changement pour les systèmes sensibles et le faible 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 concerne 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 en matière de sécurité. Les questions à se poser lors de l’évaluation de toute solution tierce de gestion des correctifs 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 a tendance à perturber le fonctionnement du système d'exploitation. Un correctif tiers défectueux a tendance à perturber le fonctionnement de l’application qui en dépend, qu’il s’agisse d’un workflow métier, d’une intégration ou d’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 d’attente, 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é ont cessé de considérer les logiciels tiers comme un sujet à part. L’exigence 6.3.3 de la norme PCI DSS 4.0 couvre tous les composants du système, y compris les applications, et pas seulement les 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 la loi HIPAA a été interprétée, dans le cadre de mesures coercitives, comme couvrant l’application de correctifs aux applications au titre des 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 en temps opportun des vulnérabilités, sans distinction entre le système d’exploitation et les applications. Le critère CC7.1 des Trust Services Criteria de la norme SOC 2 couvre la surveillance et la correction des nouvelles vulnérabilités à l’échelle du système.

Les implications pratiques sont les mêmes dans tous les cas. Un audit portant sur votre programme de mise à jour et mettant en évidence 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

L'application des correctifs tiers n'est pas un problème de connaissances. Toutes les équipes informatiques et tous les prestataires de services gérés (MSP) savent que les applications doivent être mises à jour. Il s'agit d'un problème opérationnel, et ce problème opérationnel est de nature structurelle : davantage de fournisseurs, davantage de cadences de mise à jour, davantage de formats d'installation, une surface de détection plus étendue et un workflow par défaut qui privilégie les correctifs du système d'exploitation, car ceux-ci sont plus faciles à mettre en œuvre.

Pour y remédier, il faut cesser de considérer les solutions tierces comme des programmes parallèles et les intégrer dans le même cadre que les activités déjà en cours. Même inventaire. Même classification des risques. Mêmes SLA dans la politique. Mêmes cycles de déploiement. Même automatisation. Mêmes rapports de conformité par application. Les outils sous-jacents doivent prendre en charge un catalogue de solutions tierces testées au rythme réel des mises à jour des fournisseurs, mais la conception du programme ne constitue pas un programme distinct. Il s’agit du même programme, dans son intégralité.

C’est autour de ce principe de conception que s’articulent les solutions RMM de Kaseya : l’application des correctifs pour le système 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 production et qui ne cesse de s’enrichir.

Le module prend également en charge l’installation et la désinstallation d’applications via ce même cadre de politiques, ce qui comble une lacune que la plupart des outils de correction laissent ouverte : les applications en fin de vie qui doivent être supprimées, et pas seulement mises à jour, avant d’être exploitées. Pour les MSP, cela se traduit par une configuration des politiques et des rapports de conformité spécifiques à chaque client, le tout depuis une seule console. Pour les équipes informatiques internes, cela offre 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 exigée par les cadres de conformité, générée naturellement par le flux de travail plutôt que dans le cadre d’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 exploitations montrent qu'ils ont raison de le faire.