Le processus de gestion des correctifs : un guide étape par étape

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 » en attendant 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 fragiles deviennent des opérations reproductibles. Il vous fournit une séquence à suivre, un moyen de vérifier qu'une étape est bel et bien terminée, ainsi qu'une réponse claire lorsqu'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 présente le plus souvent des défaillances et combien de temps chaque étape devrait prendre, en gros, dans un environnement fonctionnant correctement. Le logiciel RMM de Kaseya gère l’application des correctifs sur des millions de terminaux pour le compte de prestataires de services informatiques (MSP) et d’équipes informatiques internes, ce qui donne une idée assez précise des points de défaillance 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 la colonne vertébrale opérationnelle qui sous-tend cette définition. Il s'agit d'un cycle reproductible qui permet de transformer une vulnérabilité ou une mise à jour d'éditeur en un terminal corrigé, vérifié et documenté.

Vous verrez que ce concept porte plusieurs noms différents 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 ». Tous ces termes 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 utilisons ici sept étapes, car c'est le niveau de détail qui permet d'attribuer clairement à chaque étape un responsable et un résultat attendu. S'il y en a moins, les étapes commencent à 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 fil conducteur et en mettant en évidence les variations liées aux situations d’urgence là où elles sont les plus pertinentes.

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 permettant d'identifier, de hiérarchiser, de déployer et de vérifier les mises à jour sans se fier à des suppositions. Voici comment ce processus se déroule généralement, depuis 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 ignore. 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 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 enrichie par la liste des composants logiciels, la version du système d'exploitation, l'heure de la dernière vérification et l'identité 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 hôte dont personne ne s'était rendu compte qu'il exécutait 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 prestataires qui se connectent au VPN une fois par trimestre, le serveur de laboratoire qu'un collaborateur a mis en place sans 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'un état de référence complet 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 chaque éditeur 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 mis à jour selon leur propre rythme et souvent sans grande publicité. C’est l’un des arguments les plus convaincants en faveur d’un outil de gestion des correctifs capable de détecter nativement les 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 deux « 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 à deux jours pour tous les autres.

Étape 3 : Évaluation des risques et hiérarchisation

Responsable : Sécurité, avec l'avis du service informatique concernant l'impact opérationnel.

La plupart des équipes disposent de plus de correctifs que ce qu'elles sont en mesure de tester et de déployer. La hiérarchisation des priorités permet de s'assurer que les correctifs les plus importants soient déployés en premier.

L’approche traditionnelle consistait à trier les vulnérabilités par score CVSS et à corriger toutes celles jugées critiques. Cette méthode a toujours sa place, mais à elle seule, elle manque de précision. Une vulnérabilité notée CVSS 9,8 dans un logiciel non 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 prend en compte la gravité, mais aussi la criticité de l'actif, son exposition, la disponibilité d'un exploit et l'impact sur l'activité.

C'est là que le catalogue des vulnérabilités connues et exploitées de la CISA et les flux d'informations sur les menaces prennent tout leur sens. Ils vous indiquent quelles vulnérabilités sont exploitées par les attaquants, ce qui constitue un indicateur bien plus fiable pour déterminer les 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 courant 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.

Modes de défaillance courants : se limiter exclusivement au CVSS, ignorer les données relatives à l'exploitabilité, considérer tous les correctifs « critiques » comme ayant le même niveau de gravité, le problème inverse consistant à considérer les délais comme des dates butoirs plutôt que comme des objectifs, et attendre le 13e jour pour procéder au déploiement.

Temps estimé : 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 de sécurité.

É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 à être sacrifiée lorsqu'une équipe est sous pression, et c'est celle dont on regrette le plus de s'être privé. L'objectif est justement de détecter le correctif qui provoque un dysfonctionnement avant qu'il n'atteigne l'environnement de production.

Les équipes expérimentées ont recours à des « anneaux 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 étendu à 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 d’anneaux importe moins que le principe : à aucun moment un 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 sommaires sur un petit réseau en anneau 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 qu'un correctif a été « testé » après seulement 30 minutes d'exécution sur un seul hôte et ne pas disposer de plan de repli en cas de défaillance.

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 sérieuses commencent. Les correctifs sont transférés de l'environnement de préproduction vers l'environnement de production selon un calendrier défini et dans le cadre des fenêtres de maintenance convenues avec l'entreprise.

Cette étape comporte plus de sources d’échec 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 ne cessent de repousser les redémarrages. Des serveurs dont la mise à jour doit être minutieusement séquencée 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 ici 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 nécessitant une intervention humaine. À ce stade, ce que vous attendez de vos outils, 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 dès la première tentative.

Les créneaux 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 que ce correctif ne sera en réalité pas appliqué, même si votre tableau de bord indique le contraire. C'est la capacité à adapter ces créneaux au fonctionnement réel de l'entreprise qui fait la différence entre les programmes de mise à jour qui fournissent de bons rapports et ceux qui réduisent réellement les risques.

Modes de défaillance courants : considérer 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 « longue traîne » des appareils hors réseau ou non conformes ; procéder au déploiement sans fenêtres de maintenance coordonnées ; et ne pas disposer de plan de retour en arrière en cas de défaillance du déploiement en production.

Durée estimée : de 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 des opérations informatiques, 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 vulnérabilité sous-jacente a bien été corrigée.

Il y a ici deux aspects à prendre en compte. 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é est-elle réellement 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 corrigé le problème, ou ceux où une vulnérabilité associée persiste parce qu’un autre correctif était nécessaire.

C'est souvent dans l'écart entre le « taux de réussite du déploiement » indiqué par votre outil de correction 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é de 98 % en matière de correctifs, mais d'un taux de correction des vulnérabilités de 85 %, présente une lacune au niveau des processus, et non un problème lié à l'outil.

Erreurs courantes : se fier aux indicateurs de réussite du déploiement comme preuve que le problème a été résolu, ne pas effectuer d'analyse après le déploiement, ne jamais enquêter sur les cas résiduels de déploiements ayant échoué.

Délai prévu : entre 24 et 48 heures après le déploiement pour que l'analyse post-correctif s'exécute et génère des données valides.

Étape 7 : Rapports et documentation

Responsable : les opérations informatiques, souvent en collaboration avec les services chargés de la sécurité et de la 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 la diligence requise a été respectée, à mettre en évidence les tendances pour la direction et à alimenter 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 est-il perdu ? ». 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 : documentation rédigée à la va-vite, tableaux de bord présentant les déploiements sans contexte, absence de cycle de révision, absence de lien entre les indicateurs et l'amélioration des processus.

Temps estimé : réunion mensuelle de bilan, ainsi que la collecte continue des indicateurs. La production des rapports elle-même devrait être automatisée ; ce qui prend du temps, c'est l'analyse humaine et les changements de processus qui en découlent.

En quoi les correctifs d'urgence modifient-ils le processus ?

Tout ce qui précède décrit le processus habituel de correction des failles. Lorsqu'une vulnérabilité « 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 disponible passe de plusieurs semaines à quelques heures.

Dans le cadre d'un cycle de correctifs d'urgence, l'identification intervient dans les heures qui suivent la publication de l'avis ; la hiérarchisation des priorités est en grande partie décidée pour vous (si la vulnérabilité est critique et exploitée, le correctif est déployé) ; les tests se limitent à un test rapide sur un petit réseau en boucle ; et le déploiement s'effectue à grande échelle, l'idée étant qu'il vaut mieux accepter 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 négliger des étapes essentielles. C'est la mise en place d'un processus de correction d'urgence documenté, comprenant notamment la désignation d'un décideur, une dérogation pré-approuvée au contrôle habituel 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 utilisent tous la même structure de base en sept étapes, mais avec des spécificités sensiblement différentes.

Pour les serveurs, le graphe de dépendances revêt une importance accrue. 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 une interruption de service de plusieurs heures. Les fenêtres de maintenance sont plus restreintes, le contrôle des changements 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 sera généralement plus long que pour les terminaux, ce qui est tout à fait justifié.

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 mise à jour des terminaux nécessite une gestion fiable des appareils hors réseau et un moyen de traiter 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 des applications tierces pour en connaître les détails opérationnels.

Pour les charges de travail dans le cloud, l’immuabilité change la donne. Dans un environnement cloud correctement 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 s’applique toujours, 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 constitue la principale source de complexité opérationnelle.

À quel stade le processus rencontre-t-il 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 reçoivent pas de correctifs, et ce sont souvent ceux que les pirates identifient 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 toujours 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 qui obéit à ses propres règles. Un programme abouti rend cette « longue traîne » visible, identifie les responsables de chaque exception et s’attache à la résoudre plutôt que de l’ignorer.

La quatrième consiste à se fier uniquement à l'état de déploiement. L'outil signale 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 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 source de référence 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 mise en place manuelle de correctifs, quelle que soit l'échelle, 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é et cohérent, dans lequel les humains interviennent uniquement aux moments clés de la prise de décision. La découverte des actifs s'effectue en continu. L'identification des correctifs intervient dans les heures qui suivent leur publication par le fournisseur. La hiérarchisation peut être régie par des règles, les correctifs critiques étant automatiquement approuvés pour les cercles d'urgence. Les tests s'exécutent dans des cercles 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 garantit la pérennité du système.

Le logiciel de gestion des correctifs de Kaseya prend en charge ce flux de travail 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 politiques, 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 « cloud-native » destinée aux équipes qui souhaitent bénéficier des mêmes capacité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.