La plupart des programmes de mise à jour échouent non pas parce que l'équipe ignore les étapes à suivre, mais à cause des lacunes qui se glissent entre celles-ci : l'actif qui n'a jamais été répertorié dans l'inventaire, la mise à jour restée trois semaines au statut « approuvée » dans l'attente d'une fenêtre de maintenance, ou encore le rapport de déploiement que personne n'a examiné parce que le tableau de bord indiquait déjà un taux de conformité de 96 %.
C'est grâce à un processus de gestion des correctifs bien rodé que ces transitions souvent hasardeuses deviennent des opérations reproductibles. Il vous fournit une procédure à suivre, un moyen de vérifier qu'une étape est bien terminée et une réponse claire si un auditeur vous demande comment vous avez déterminé quels correctifs avaient été déployés mardi dernier.
Ce guide vous accompagne pas à pas tout au long du cycle de vie complet. Vous découvrirez ce qui se passe à chaque étape, qui en est généralement responsable, où le processus rencontre le plus souvent des difficultés et combien de temps chaque étape devrait prendre, en moyenne, dans un environnement fonctionnant correctement. Le logiciel RMM de Kaseya gère l'application des correctifs sur des millions de terminaux pour les MSP et les équipes informatiques internes, ce qui permet d'avoir une idée assez précise des points de rupture et de ce à quoi ressemble un « bon » déroulement à chaque étape du processus.
Qu'est-ce qu'un processus de gestion des correctifs ?
Si vous découvrez ce sujet, commencez par consulter notre guide complet intitulé «Qu'est-ce que la gestion des correctifs ?», puis revenez ici. Pour tous les autres, ce processus constitue le pilier opérationnel de cette définition. Il s'agit d'un cycle reproductible qui permet de transformer une vulnérabilité ou une mise à jour d'un fournisseur en un terminal corrigé, vérifié et documenté.
On y trouve plusieurs appellations différentes dans la pratique : cycle de vie de la gestion des correctifs, workflow de gestion des correctifs, procédure de gestion des correctifs ou tout simplement processus de correction. Toutes ces expressions désignent la même chose. Le nombre d'étapes varie entre quatre et dix, selon l'auteur, mais la logique sous-jacente reste globalement la même.
Nous avons opté ici pour sept étapes, car c'est le niveau de détail qui permet d'attribuer clairement un responsable et un résultat attendu à chaque phase. S'il y en a moins, les étapes finissent par se confondre. S'il y en a plus, on finit par créer des distinctions qui n'existent pas dans la pratique.
Avant d’entrer dans le vif du sujet, il convient de souligner un point : le processus de correction de routine, planifié à l’avance, diffère de celui des correctifs d’urgence ou « zero-day ». Si les étapes peuvent sembler similaires sur le papier, les délais, les étapes d’approbation et la tolérance au risque sont considérablement réduits. Nous aborderons ces deux cas de figure, en nous appuyant sur le processus de routine comme trame de fond et en mettant en évidence les variations liées aux situations d’urgence là où elles sont les plus importantes.
Déroulement du processus de gestion des correctifs : 7 étapes clés
Un processus efficace de gestion des correctifs définit une méthode reproductible pour identifier, hiérarchiser, déployer et vérifier les mises à jour sans se fier à des suppositions. Voici comment ce processus se déroule généralement, de l'inventaire des actifs jusqu'à la génération de rapports.
Étape 1 : Inventaire et recensement des actifs
Responsable : il s'agit généralement de l'administrateur des terminaux ou des systèmes, en collaboration avec le service de sécurité.
On ne peut pas corriger ce que l'on ne connaît pas. La première étape consiste à établir et à tenir à jour un inventaire complet, précis et à jour de tous les appareils, systèmes d'exploitation, applications et versions de micrologiciels présents dans votre environnement. Cela inclut les serveurs, les postes de travail, les ordinateurs portables, les appareils mobiles, les machines virtuelles, les équipements réseau, les appareils IoT et toutes les charges de travail dans le cloud dont vous avez la gestion.
L'idéal, ce n'est pas un tableur que quelqu'un met à jour tous les trimestres. C'est un inventaire actualisé en permanence, établi à partir d'une détection automatisée, où chaque ressource est complétée par la liste des composants logiciels, la version du système d'exploitation, la date de la dernière vérification et le nom du propriétaire. Chaque lacune dans cet inventaire se traduit par une lacune dans votre couverture des correctifs, et chaque lacune dans la couverture se révèle plus tard sous la forme d'un serveur dont personne ne se doutait qu'il tournait sous une version d'OpenSSL arrivée en fin de vie.
Problèmes courants : les appareils BYOD sur lesquels l'agent n'est pas installé, les ordinateurs portables des sous-traitants qui se connectent au VPN une fois par trimestre, le serveur de laboratoire que quelqu'un a mis en place sans penser à l'enregistrer, ainsi que tout élément hébergé dans un abonnement cloud appartenant à une seule équipe.
Durée estimée : le processus de découverte s'exécute en continu. L'obtention d'une base de référence complète et fiable pour la première fois prend généralement entre une et quatre semaines, en fonction de la taille de l'environnement et de l'ampleur du « shadow IT ».
Étape 2 : Surveillance et identification des correctifs
Responsable : cette fonction est généralement partagée entre le service informatique et le service de sécurité.
Une fois que vous savez ce dont vous disposez, vous devez connaître les solutions disponibles pour y remédier. Cette étape consiste à suivre régulièrement les publications de correctifs de tous les éditeurs dont les logiciels sont utilisés dans votre environnement, ainsi que les avis de sécurité émis par la CISA, les équipes PSIRT des éditeurs et les sources de renseignements sur les menaces, afin d'identifier les vulnérabilités pouvant nécessiter une intervention hors cycle.
Pour Microsoft, Adobe et Oracle, ce processus est relativement structuré. Le « Patch Tuesday » a lieu le deuxième mardi du mois, les bulletins sont prévisibles et la plupart des outils de gestion des correctifs les intègrent automatiquement. C'est partout ailleurs que les difficultés apparaissent. Les navigateurs, les outils de visioconférence, les bibliothèques d'exécution, les applications métier de niche, les micrologiciels réseau et les pilotes d'imprimante sont tous publiés selon leur propre rythme et souvent sans grande fanfare. C'est l'un des arguments les plus convaincants en faveur d'un outil de gestion des correctifs qui gère nativement la détection des composants tiers plutôt que d'obliger votre équipe à surveiller manuellement une centaine de flux RSS.
Erreurs courantes : ne pas tenir compte du tout des versions publiées par des éditeurs tiers, négliger les avis de sécurité hors cycle publiés entre les « Patch Tuesdays » et considérer les flux CVE comme la source de référence plutôt que les avis des éditeurs.
Délai prévu : en cours. Entre la mise en production et la détection dans votre environnement, ce délai devrait être de quelques heures pour les fournisseurs de premier rang et d'un ou deux jours pour les autres.
Étape 3 : Évaluation des risques et hiérarchisation
Responsable : Sécurité, avec la contribution du service informatique concernant l'impact opérationnel.
La plupart des équipes disposent de plus de correctifs qu'elles ne peuvent en tester et en déployer. La hiérarchisation des priorités permet de s'assurer que les correctifs les plus importants sont traités en premier.
L'approche traditionnelle consistait à trier les vulnérabilités en fonction de leur score CVSS et à corriger toutes celles jugées critiques. Cette méthode a toujours sa place, mais elle s'avère trop simpliste lorsqu'elle est utilisée seule. Une vulnérabilité notée CVSS 9,8 dans un logiciel qui n'est pas exposé à Internet, pour laquelle aucun exploit n'est connu et qui s'exécute sur trois hôtes internes, ne pose pas le même problème qu'une vulnérabilité notée CVSS 7,5 pour laquelle un exploit fonctionnel est activement utilisé dans la nature contre votre secteur d'activité. Une approche basée sur les risques tient compte de la gravité, mais aussi de la criticité des actifs, de l'exposition, de la disponibilité des exploits et de l'impact sur l'activité.
C'est là que le catalogue des vulnérabilités exploitées de la CISA et les flux d'informations sur les menaces prennent tout leur sens. Ils vous indiquent quelles vulnérabilités les pirates exploitent, ce qui permet de mieux déterminer quelles correctifs appliquer en priorité que le seul indice CVSS.
Cette étape aboutit à une liste hiérarchisée accompagnée d'échéances approximatives. Un cadre type prévoit le déploiement des correctifs critiques dans un délai de 48 à 72 heures, ceux de niveau élevé dans les 14 jours, ceux de niveau moyen dans les 30 jours et ceux de niveau faible dans les 90 jours. Au Royaume-Uni, la norme Cyber Essentials exige que les correctifs relatifs aux vulnérabilités notées 7,0 ou plus soient déployés dans les 14 jours, ce qui est devenu une référence utile pour les organisations visant ce niveau de maturité en matière de conformité. Quels que soient les délais que vous fixez, consignez-les dans votre politique de gestion des correctifs afin que le reste du processus s'y conforme.
Problèmes courants : se limiter exclusivement au CVSS, ne pas tenir compte des données relatives à l'exploitabilité, considérer tous les correctifs « critiques » comme ayant la même gravité, le problème inverse consistant à considérer les délais comme des dates butoirs plutôt que des objectifs, et attendre le 13e jour pour procéder au déploiement.
Estimation du temps nécessaire : nombre d'heures par cycle de correctifs si vos outils se chargent du gros du travail. Une journée entière, voire plus, si votre équipe évalue manuellement chaque avis.
Étape 4 : Test cutané
Responsable : le service des opérations informatiques, en collaboration avec les responsables des applications pour les correctifs à haut risque.
Les tests sont la première étape à passer à la trappe lorsqu’une équipe est sous pression, et c’est celle qui suscite le plus de regrets lorsqu’elle est négligée. L’objectif est justement de repérer le correctif qui provoque un dysfonctionnement avant qu’il n’atteigne l’environnement de production.
Les équipes expérimentées ont recours à des cycles de déploiement ou à des déploiements par étapes. Un correctif est d'abord appliqué à un échantillon représentatif de machines de test, comprenant idéalement un mélange de modèles matériels, de versions de système d'exploitation et d'applications clés. Après 24 à 72 heures de fonctionnement sans incident, il est déployé sur un groupe pilote plus large. Ce n'est qu'ensuite qu'il est déployé sur l'ensemble du parc de production. Le nombre exact de cycles importe moins que le principe : à aucun moment un seul déploiement ne doit concerner tous les terminaux en même temps.
Pour les correctifs de routine, la phase de test dure généralement entre 24 et 72 heures. Pour les correctifs d'urgence ou « zero-day », vous pouvez réduire ce délai à quelques heures de tests de validation sur un petit réseau avant de procéder à un déploiement à grande échelle, en acceptant un risque plus élevé afin de combler plus rapidement la faille de sécurité. Ce compromis doit être le fruit d'une décision mûrement réfléchie, et non la norme par défaut.
Problèmes courants : ne pas effectuer de tests du tout sur les petits parcs informatiques, ne tester que sur du matériel qui ne correspond pas à l'environnement de production, déclarer un correctif « testé » après seulement 30 minutes d'exécution sur un seul hôte et ne pas prévoir de plan de repli en cas de panne.
Délai prévu : 24 à 72 heures pour les correctifs standard, 2 à 12 heures pour les urgences, en fonction de la tolérance au risque.
Étape 5 : Déploiement
Responsable : Opérations informatiques
C'est lors du déploiement que les choses se concrétisent. Les correctifs sont transférés de l'environnement de préproduction vers l'environnement de production selon un calendrier défini et pendant les fenêtres de maintenance convenues avec l'entreprise.
Cette étape comporte plus de points de défaillance que n’importe quelle autre du processus, principalement parce que c’est là que le monde réel, avec toutes ses aléas, entre en jeu. Des ordinateurs portables qui ne sont pas connectés au réseau au moment du déploiement. Des utilisateurs finaux qui repoussent sans cesse le redémarrage. Des serveurs dont l’ordre d’exécution doit être soigneusement planifié en raison de dépendances. Des correctifs qui nécessitent l’arrêt préalable d’un service spécifique. Des appareils hors réseau qui ne se sont pas connectés depuis des semaines.
Un outil RMM bien configuré effectue la majeure partie du travail en arrière-plan. Il déploie les correctifs conformément à la politique définie, effectue de nouvelles tentatives lorsque les machines se reconnectent, gère les redémarrages dans les créneaux horaires convenus et signale les exceptions afin qu’un intervenant humain puisse s’en occuper. À ce stade, ce que vous attendez de votre outil, c’est un taux de réussite élevé des déploiements sans intervention manuelle, ainsi qu’une visibilité sur les appareils qui n’ont pas reçu le correctif lors de la première tentative.
Les fenêtres de maintenance ont plus d'importance qu'on ne le pense. Un correctif nécessitant un redémarrage sur un poste de travail clinique en plein milieu d'un service à l'hôpital sera inévitablement reporté, ce qui signifie qu'il ne sera en réalité pas appliqué, même si votre tableau de bord indique le contraire. C'est la capacité à adapter les fenêtres de maintenance au fonctionnement réel de l'entreprise qui distingue les programmes de mise à jour qui fournissent de bons rapports de ceux qui réduisent réellement les risques.
Problèmes courants : supposer que le terme « déployé » signifie que le correctif est installé alors qu'il désigne en réalité l'envoi du paquet ; négliger la multitude d'appareils hors réseau ou non conformes ; procéder au déploiement sans coordonner les fenêtres de maintenance ; et ne pas prévoir de plan de repli en cas de défaillance du déploiement en production.
Durée estimée : quelques minutes à quelques heures par machine pour le déploiement technique proprement dit, mais le temps total nécessaire pour couvrir l'ensemble du parc informatique au cours d'un cycle de mise à jour de routine est généralement d'une à deux semaines, une fois pris en compte les appareils hors réseau, les redémarrages différés et la gestion des exceptions.
Étape 6 : Vérification
Responsable : Service informatique, avec contrôle par le service de sécurité.
La vérification est l'étape que la plupart des équipes savent qu'elles devraient mieux maîtriser. L'objectif est de s'assurer, une fois que tout est rentré dans l'ordre, que chaque correctif a bien été installé sur chaque appareil cible et que la faille sous-jacente a été corrigée.
Il y a deux aspects à prendre en compte ici. Premièrement, le correctif s'est-il installé correctement ? La plupart des outils de gestion des correctifs vous le diront, même si la réponse cache souvent une longue série d'états « redémarrage en attente » ou « différé » qui semblent corrects mais ne le sont pas. Deuxièmement, la vulnérabilité a-t-elle réellement été corrigée ? Un scan de vulnérabilité distinct effectué après l'application du correctif permet de détecter les cas où un correctif a été installé mais n'a pas entièrement résolu le problème, ou ceux où une vulnérabilité connexe persiste parce qu'un autre correctif était nécessaire.
C'est souvent dans l'écart entre le « taux de réussite des déploiements » indiqué par votre outil de gestion des correctifs et le « taux de correction des vulnérabilités » indiqué par votre scanner que se situent les constatations d'audit. Une équipe qui fait état d'une conformité des correctifs de 98 % mais d'un taux de correction des vulnérabilités de 85 % présente une lacune dans ses processus, et non un problème lié à l'outil.
Erreurs courantes : se fier aux indicateurs de réussite du déploiement comme preuve de la résolution du problème, ne pas effectuer d'analyse après le déploiement, ne jamais examiner les cas résiduels de déploiements ayant échoué.
Délai prévu : 24 à 48 heures après le déploiement pour que l'analyse post-correction s'exécute et génère des données valides.
Étape 7 : Rapports et documentation
Responsable : Opérations informatiques, souvent en collaboration avec les services de sécurité et de conformité.
Le cycle ne s'achève pas une fois les correctifs vérifiés. Il ne s'achève que lorsque l'activité est documentée de manière à prouver aux auditeurs que les mesures de diligence raisonnable ont été respectées, à mettre en évidence les tendances pour la direction et à servir de base à l'amélioration du cycle suivant.
À quoi ressemble une documentation de qualité : un rapport par cycle de mise à jour indiquant ce qui a été publié, ce qui a été jugé prioritaire, ce qui a été déployé, ce qui a échoué et pourquoi, quelles dérogations ont été accordées et pour quels actifs. Des indicateurs de délai de mise à jour par niveau de gravité. Les pourcentages de conformité aux mises à jour par client, par service ou par catégorie d'actifs. Une piste d'audit claire qu'un auditeur externe pourrait suivre pour vérifier l'historique des mises à jour de n'importe quel terminal.
C'est également là que se trouvent vos axes d'amélioration. Si 30 % de vos correctifs critiques sont déployés en dehors de la fenêtre de 14 jours, la question à se poser n'est pas « comment déployer plus rapidement ? », mais « à quelle étape des six précédentes le temps s'écoule-t-il ? ». La réponse se trouve presque toujours soit à l'étape trois (la hiérarchisation des priorités est trop lente), soit à l'étape cinq (le déploiement comporte trop d'exceptions). C'est la documentation qui rend ce diagnostic possible.
Problèmes courants : une documentation rédigée après coup, des tableaux de bord qui rendent compte du déploiement sans fournir de contexte, l'absence de cycle de révision, ainsi que l'absence de lien entre les indicateurs et l'amélioration des processus.
Temps nécessaire : réunion mensuelle de bilan et collecte continue des indicateurs. La production des rapports elle-même devrait être automatisée ; ce qui prend du temps, c'est l'examen par des personnes et les modifications de processus qui en découlent.
Comment les correctifs d'urgence modifient le processus
Tout ce qui précède décrit le processus habituel de correction. Lorsqu'une vulnérabilité de type « zero-day » ou activement exploitée apparaît, ce processus s'accélère. Les sept étapes restent les mêmes, mais le délai passe de plusieurs semaines à quelques heures.
Dans le cadre d'un cycle de correctifs d'urgence, l'identification s'effectue dans les heures qui suivent la publication de l'avis ; la hiérarchisation des priorités est en quelque sorte imposée (si c'est critique, si c'est exploité, le correctif est déployé) ; les tests se limitent à une vérification rapide sur un petit réseau, et le déploiement est généralisé, l'idée étant qu'il vaut mieux risquer quelques dysfonctionnements plutôt que de rester exposé au risque. La vérification et la documentation sont renforcées, car un audit aura lieu.
Dans le cadre d'une intervention d'urgence, le risque ne réside généralement pas dans une action trop précipitée, mais dans l'absence de plan. L'équipe se retrouve alors contrainte d'improviser sous la pression et de sauter des étapes cruciales. C'est la mise en place d'un processus de correction d'urgence documenté, comprenant la désignation d'un décideur, une dérogation préapprouvée aux procédures habituelles de contrôle des changements et une procédure de restauration testée, qui garantit la sécurité d'une correction rapide.
Lorsque le processus de mise à jour varie selon l'environnement
Les serveurs, les terminaux, les applications tierces et les charges de travail dans le cloud s'appuient tous sur le même modèle en sept étapes, mais présentent des spécificités sensiblement différentes.
Pour les serveurs, le graphe des dépendances revêt une importance particulière. L'application d'un correctif sur un serveur de base de données dans un ordre incorrect par rapport aux serveurs d'applications qui en dépendent peut entraîner des heures d'indisponibilité. Les fenêtres de maintenance sont plus restreintes, le contrôle des modifications est plus strict et la planification de la restauration est incontournable. Le délai de correction des vulnérabilités non critiques sur les serveurs est généralement plus long que pour les terminaux, ce qui est tout à fait normal.
En ce qui concerne les terminaux, le problème réside dans la « longue traîne » : les ordinateurs portables qui se déplacent, les appareils qui repoussent les redémarrages, les utilisateurs qui préfèrent éteindre leur machine plutôt que de la redémarrer. La gestion des correctifs sur les terminaux doit permettre de traiter de manière fiable les appareils hors réseau et de gérer les 5 à 10 % inévitables de machines qui ne sont pas prises en compte lors d'un cycle de mise à jour donné.
En ce qui concerne les applications tierces, le volume pose problème. Un environnement type compte des dizaines d'applications tierces, chacune ayant son propre calendrier de mise à jour, et une part non négligeable des failles de sécurité trouve son origine dans une application tierce non mise à jour plutôt que dans un système d'exploitation non mis à jour. Ce phénomène est suffisamment important pour que nous l'ayons traité séparément. Consultez notre guide dédié à la gestion des correctifs pour les applications tierces pour en savoir plus sur les aspects opérationnels.
Pour les charges de travail dans le cloud, l'immuabilité change la donne. Dans un environnement cloud bien conçu, on n'applique pas de correctif à une instance en cours d'exécution ; on la remplace par une nouvelle instance créée à partir d'une image mise à jour. Le processus en sept étapes reste d'actualité, mais la cinquième étape s'apparente davantage à la création d'une image et au remplacement d'une instance qu'à l'installation d'un logiciel. Les environnements hybrides finissent par faire coexister ces deux modèles, ce qui est à l'origine de la majeure partie de la complexité opérationnelle.
Les points où le processus rencontre le plus souvent des problèmes
On observe régulièrement certaines tendances dans les environnements où le programme de mise à jour ne fonctionne pas comme il le devrait.
Le premier problème est un inventaire incomplet. Si la première étape est défaillante, toutes les étapes suivantes en subissent les conséquences. Les hôtes dont vous ignorez l'existence ne sont pas mis à jour, et ce sont souvent eux que les pirates repèrent en premier, car ils sont mal entretenus pour la même raison qui explique leur absence de l'inventaire.
Le deuxième problème est le décalage entre les tests et le déploiement. Les correctifs sont testés, validés, puis restent en attente d'une fenêtre de maintenance que l'entreprise ne cesse de repousser. Deux semaines plus tard, le correctif n'est toujours pas en production et l'urgence initiale s'est estompée. La solution consiste généralement à renforcer le lien entre la validation et le déploiement, et à mettre en place des fenêtres de maintenance moins nombreuses mais plus fiables.
Le troisième point concerne la longue traîne des appareils non conformes. Le tableau de bord indique un taux de 95 %. Les 5 % restants sont les mêmes à chaque cycle, et ce sont presque toujours les 5 % les plus importants : les ordinateurs portables des dirigeants, les serveurs dont personne ne veut s’occuper, l’environnement de laboratoire avec ses propres règles. Un programme bien rodé rend cette longue traîne visible, désigne un responsable pour chaque exception et s’attelle à la résoudre plutôt que de l’ignorer.
La quatrième consiste à se fier uniquement au rapport de déploiement. L'outil indique que l'opération a réussi, l'équipe passe à autre chose, mais l'analyse de vulnérabilité effectuée trois semaines plus tard révèle que 8 % du parc informatique censé avoir été corrigé est toujours vulnérable. Pour combler cette lacune, il faut considérer les résultats de l'analyse de vulnérabilité comme la référence absolue pour la correction, et non le rapport de déploiement de l'outil de correctifs.
C'est la combinaison de ces modes de défaillance qui explique pourquoi les entreprises ont mis en moyenne 209 jours à corriger les 17 vulnérabilités des appareils périphériques recensées par Verizon dans son rapport DBIR 2025, alors que les pirates n'ont mis que cinq jours à les exploiter. Il s'agit d'un problème de processus, et non d'un problème de sensibilisation.
Comment les outils modernes de Kaseya transforment le processus
La correction manuelle, quelle que soit l'ampleur raisonnable de la tâche, n'est plus viable. Le volume des mises à jour, la diversité des plateformes et la rapidité avec laquelle les failles sont exploitées ont largement dépassé ce qu'une équipe peut gérer à l'aide de tableurs et de déploiements individuels.
Un bon outil permet de regrouper ces sept étapes en un flux de travail automatisé cohérent, dans lequel les humains interviennent uniquement aux moments clés. La découverte des ressources s'effectue en continu. L'identification des correctifs intervient dans les heures qui suivent leur publication par les éditeurs. La hiérarchisation peut être basée sur des règles, les correctifs critiques étant automatiquement approuvés pour les cycles de déploiement d'urgence. Les tests sont effectués dans des cycles de déploiement définis, sans intervention manuelle. Le déploiement identifie les appareils hors réseau et gère les redémarrages dans les créneaux horaires convenus. La vérification alimente les analyses de vulnérabilité. Les rapports sont générés automatiquement.
C'est le modèle opérationnel qui sous-tend la gestion automatisée des correctifs, désormais la norme pour tout environnement qui souhaite sérieusement mettre en œuvre une stratégie de correctifs à grande échelle. Le processus en sept étapes décrit ci-dessus constitue le fondement de l'automatisation ; c'est cette automatisation qui en assure la pérennité.
Le logiciel de gestion des correctifs de Kaseya prend en charge ce processus pour les équipes informatiques et les MSP, quel que soit le système d'exploitation et pour plus d'un millier d'applications tierces. Il regroupe en une seule solution le déploiement basé sur des règles, les cycles de déploiement, la gestion des appareils hors réseau et les rapports de conformité des correctifs. Datto RMM, qui fait partie de la gamme Kaseya RMM, est l'option native du cloud destinée aux équipes qui souhaitent bénéficier des mêmes fonctionnalités de gestion des correctifs sans avoir à gérer l'infrastructure sous-jacente.
Le processus prime sur l'outil. Mais une fois que le processus est bien rodé, c'est le choix de l'outil adéquat qui fait la différence entre un programme qui fonctionne sur le papier et un programme qui assure réellement la mise à jour du parc informatique au rythme imposé par l'entreprise. À partir de là, l'étape suivante consiste à passer du processus au programme : consultez notre guide complémentaire sur les meilleures pratiques en matière de gestion des correctifs pour découvrir les principes qui distinguent un programme de mise à jour efficace d'un programme d'excellence.
