Migrer de Patch Manager Plus On-Premises vers le Cloud : Un guide d’évaluation pratique
Avez-vous déjà entendu parler de la loi de Murphy de l’administration informatique ?
Elle stipule que le serveur hébergeant vos outils de sécurité tombera en panne exactement au moment où une vulnérabilité critique fera la une partout.
Qu’il s’agisse d’une coupure de courant soudaine, d’un problème de base de données ou d’une panne du réseau local, perdre l’accès à vos outils de gestion centraux au moment où vous en avez le plus besoin est le pire cauchemar de toute équipe informatique. Cette loi malheureuse (et fictive) soulève une question fondamentale : Vos opérations sont-elles pleinement équipées pour soutenir la rapidité, la flexibilité et l’échelle que votre entreprise exige aujourd’hui ?
Passer à un nouveau modèle de déploiement est une décision opérationnelle qui affecte la façon dont votre équipe travaille chaque jour. Les discussions avec les parties prenantes tournent généralement autour de la stabilité, de l’effort et de la question de savoir si le changement en vaut vraiment la peine.
Si vous envisagez de passer de Patch Manager Plus On-Premises à Patch Manager Plus Cloud, ce guide est conçu pour vous aider à prendre cette décision en toute confiance. Il aborde les préoccupations pratiques que la plupart des équipes informatiques ont — adéquation, impact et facteurs à évaluer — afin que vous puissiez avancer avec une vision claire de ce que la transition signifiera pour votre organisation. Entrons dans le vif du sujet.
Le cloud est-il adapté à votre situation ?
Passer de l’on-premises au cloud ne signifie pas que vous abandonnez un processus qui a bien servi votre organisation. Cela signifie simplement que vous envisagez un modèle de déploiement différent qui pourrait mieux soutenir la façon dont votre équipe travaille et la direction que prend votre organisation.
Le cloud a généralement le plus de sens si l’une de ces situations décrit la réalité de votre équipe :
- Vous gérez plusieurs succursales. Le cloud est particulièrement adapté lorsque vous devez corriger des périphériques sur plusieurs sites via Internet, car il centralise l’administration au lieu de dépendre d’un serveur local à chaque emplacement.
- Vous prenez en charge des utilisateurs distants ou nomades. Si les employés travaillent à domicile ou changent fréquemment de réseau, le modèle cloud facilite le maintien de leurs périphériques à jour sans dépendre d’une connectivité LAN permanente.
- Vous souhaitez réduire la maintenance des serveurs. Si votre équipe informatique préfère ne pas conserver un serveur Windows dédié à la plateforme de gestion des correctifs, le cloud supprime cette charge opérationnelle et simplifie l’administration continue.
- Vous avez besoin d’une empreinte opérationnelle plus légère. Les petites équipes informatiques bénéficient souvent du cloud car il réduit le nombre de systèmes à corriger, surveiller, sauvegarder et dépanner en interne. Cela peut libérer du temps pour des travaux critiques à forte valeur ajoutée.
- Votre focus de patching porte principalement sur les endpoints. Si votre environnement est centré sur des périphériques clients tels que des ordinateurs portables Windows, des postes de travail et des Mac, le cloud est souvent une solution pratique car le flux de travail est conçu autour de la gestion des endpoints.
- Vous souhaitez un accès plus facile pour les administrateurs. Une console cloud est facile d’accès depuis n’importe où, ce qui aide les équipes qui prennent en charge plusieurs fuseaux horaires, voyagent souvent ou gèrent des endpoints en dehors du bureau.
- Vous prévoyez de croître ou de changer rapidement. Le cloud est souvent préférable lorsque votre environnement évolue, car il est plus facile d’étendre à de nouveaux emplacements, d’ajouter de nouveaux utilisateurs distants et d’ajouter plus d’outils ou d’endpoints sans étendre l’infrastructure locale.
Quand l’on-premises reste un meilleur choix
Passer au cloud n’est pas l’objectif pour tout le monde ; de nombreuses organisations fonctionnent aujourd’hui en on-premises pour de bonnes raisons. Certains environnements sont construits autour d’exigences, de pratiques ou de priorités que l’on-premises sert encore bien.
L’on-premises est adapté à votre organisation si :
- L’hébergement interne est une exigence organisationnelle ferme.
- La connectivité Internet est limitée, peu fiable ou strictement contrôlée sur vos sites.
- Votre équipe informatique préfère posséder et gérer elle-même l’infrastructure de la plateforme.
- Les exigences de résidence des données, de conformité ou de gouvernance interne nécessitent un examen approfondi avant tout changement d’hébergement.
Si les règles de conformité de votre organisation exigent trois cartes d’accès, une empreinte digitale et un manuscrit romain antique pour déplacer des données, l’on-premises restera probablement votre meilleur ami.
En réalité, la plupart des équipes cochent quelques cases à la fois pour le cloud et l’on-premises. Ce qui tend à trancher, c’est de voir où se situe le véritable poids opérationnel dans les opérations quotidiennes, et c’est là que la comparaison ci-dessous peut aider.
Comparaison de l’expérience au quotidien
Au lieu d’une comparaison complète fonctionnalité par fonctionnalité (que vous pouvez trouver sur nos pages édition), voici un aperçu rapide de la façon dont les deux modèles se ressentent en pratique :
| Considération | On-Premises | Cloud |
| Maintenance de la plateforme | Votre équipe possède l’environnement d’hébergement, la base de données et les mises à niveau de la plateforme | ManageEngine maintient le service central |
| Focus de l’administrateur | Partagé entre le patching des endpoints et la maintenance de la plateforme | Concentré sur le patching des endpoints et les rapports |
| Main-d’œuvre à distance | Pris en charge via Internet une fois l’accès distant configuré, à l’aide d’un serveur accessible publiquement ou du module Secure Gateway Server | Pris en charge via Internet sans composant supplémentaire à configurer |
| Empreinte infrastructure | Nécessite une capacité de serveur interne, dimensionnée pour votre nombre d’endpoints | Nécessite un serveur de distribution dans la plupart des environnements AD, sans serveur central en interne |
| Localisation et contrôle des données | L’historique des correctifs et les données des endpoints restent dans votre base de données sous vos règles de rétention | Les données résident dans le centre de données régional de ManageEngine |
| Évaluation des coûts | Licence + matériel, personnel, maintenance et coûts de cycle de vie | Abonnement + coûts de migration et de service |
Le cloud peut sembler plus cher au premier abord car son prix d’abonnement est visible, alors que de nombreux coûts on-premises sont répartis sur l’infrastructure, les renouvellements de matériel, les sauvegardes, la maintenance, les mises à niveau et le temps des administrateurs. Cependant, lorsque vous considérez le coût total de possession (TCO), le cloud apporte des économies en supprimant le besoin de serveurs internes dédiés et en réduisant l’effort informatique requis pour héberger et maintenir la plateforme. Cela permet aux équipes informatiques de rediriger cette capacité vers des priorités de sécurité et commerciales à plus forte valeur ajoutée.
Rappelez-vous, la question la plus utile n’est pas « Quelle option a le prix de licence le plus bas ? ». C’est « Quel modèle de déploiement nous offre le meilleur équilibre entre coût, effort, propriété et valeur opérationnelle ? »
Cas d’usage : Quand la salle des serveurs s’est éteinte
Marcus gère une équipe informatique de trois personnes pour une entreprise manufacturière de 60 personnes. Un jeudi après-midi, un transformateur tombe en panne à deux pâtés de maisons du bureau, et le bâtiment perd l’électricité pour le reste de la journée. Le générateur se met en marche pour quelques systèmes critiques, mais la salle des serveurs n’est pas branchée sur ce circuit. Elle s’éteint avec tout le reste.
La plupart des ordinateurs portables de l’entreprise vont bien. La moitié de l’équipe travaille à distance, et leurs machines restent intactes sur les réseaux domestiques, déjà corrigées plus tôt dans la semaine. Mais lorsque Marcus essaie de se connecter à la console de patching pour vérifier un déploiement qui était en cours lorsque le courant a sauté, il ne peut pas. Le serveur hébergeant la console est le même serveur qui vient de perdre l’alimentation.
Pendant quelques heures, l’outil censé lui donner de la visibilité est la seule chose qu’il ne peut pas utiliser. Il ne peut pas confirmer quelles machines ont reçu le correctif et lesquelles non, ni si le déploiement doit être relancé après la panne. Si ce déploiement partiel incluait un correctif pour une vulnérabilité déjà exploitée, un attaquant aurait eu ces quelques heures pour trouver l’une des machines non corrigées avant même que Marcus ne sache qu’elle était encore exposée.
Le soir, le courant revient. Mais l’incident laisse Marcus avec une pensée tenace : l’outil responsable de la résilience de ses endpoints n’était résilient que dans la mesure où l’était la salle dans laquelle il se trouvait. Ce type de problème est souvent négligé jusqu’à ce qu’un incident le mette en lumière.
Il existe deux façons d’y répondre. La première consiste à construire une véritable redondance dans la configuration on-premises : un serveur de basculement, délibérément placé ailleurs que dans la salle des serveurs, afin qu’une panne locale ne mette pas toute la plateforme hors service. L’autre consiste à passer à un modèle où cette redondance existe déjà, répartie sur des centres de données que Marcus n’a jamais à planifier, alimenter ou s’inquiéter.
Marcus n’a réalisé cela que parce qu’une panne a forcé la question. Heureusement, vous n’avez pas besoin d’attendre une version de cela pour y réfléchir. Cela se résume à une poignée de facteurs concrets. Passons en revue ce qu’il convient de peser avant de décider dans un sens ou dans l’autre.
Facteurs à prendre en compte
Selon Gartner®, 90 % des organisations devraient adopter une approche de cloud hybride d’ici 2027. Cet équilibre est différent pour chaque organisation, ce qui fait de l’évaluation de votre propre adéquation le point de départ naturel. Vous pouvez commencer par évaluer si cela correspond à la main-d’œuvre de votre organisation, à sa stratégie d’infrastructure, à ses exigences de conformité, à son modèle budgétaire et à ses plans à long terme.
Travaillez sur les questions ci-dessous, pertinentes pour chaque partie prenante :
Informatique et administration
- Combien d’heures ont été consacrées aux mises à niveau de la plateforme, à la maintenance de la base de données et au dépannage du serveur lui-même au cours des douze derniers mois ?
- Sommes-nous censés prendre en charge davantage d’endpoints sans augmentation correspondante des ressources ?
- La suppression de la maintenance de la plateforme libérerait-elle du temps pour le travail de sécurité des endpoints ?
Infrastructure
- Les utilisateurs distants, nomades ou en succursale deviennent-ils une part plus importante de notre environnement ?
- Prévoyons-nous de réduire notre empreinte serveur ou d’adopter davantage d’outils SaaS ?
- Des renouvellements de matériel ou des changements d’infrastructure sont-ils déjà à l’horizon ?
- Devrions-nous planifier de nouveaux bureaux ou une croissance rapide des endpoints ?
- Combien de bureaux distants avons-nous, combien d’endpoints se trouvent dans chacun, et notre édition prévue permet-elle suffisamment de serveurs de distribution pour les couvrir ?
Sécurité et conformité
- Existe-t-il des exigences de résidence des données, de conformité ou de connectivité qui doivent être examinées avant tout changement d’hébergement ?
- Devons-nous exporter des rapports historiques ou des journaux d’audit pour la conformité avant tout changement de notre déploiement ?
- Notre politique de sécurité a-t-elle des règles concernant une console de gestion accessible via Internet public ?
- Qui valide cela, et quelles preuves demanderont-ils ?
Finance
- Un modèle de coût basé sur l’abonnement serait-il plus facile à prévoir et à budgétiser que notre modèle actuel ?
- Avons-nous pris en compte les coûts exclusivement on-premises (matériel, licences de base de données, modules complémentaires comme Failover Server ou Secure Gateway Server) dans notre comparaison de coûts actuelle, et pas seulement le prix de la licence ?
Direction
- Notre déploiement actuel est-il toujours adapté à l’endroit où se trouvera l’organisation dans trois à cinq ans ?
Aligner les équipes Informatique, Sécurité, Finance et Direction sur une décision d’infrastructure majeure est notoirement plus facile à dire qu’à faire. Si l’un de ces éléments est difficile à peser de manière abstraite, commencez par regarder les dates. L’expiration de la garantie, l’avis de fin de support du système d’exploitation, le devis de renouvellement, ou tout autre élément qui forcera de toute façon une décision. La plupart des équipes constatent que la question se résout rapidement une fois qu’elles savent combien de mois les séparent de cette date et ce que cela coûte de dire oui.
Besoin d’aide ?
Vous n’avez pas à évaluer le passage seul. ManageEngine peut vous aider à comprendre si Patch Manager Plus Cloud est adapté à votre organisation et discuter de vos exigences. Si vous décidez d’aller de l’avant, notre équipe de support est prête à vous accompagner tout au long du processus de migration.
Contactez PG Software dès aujourd’hui pour évaluer vos options et assurer une transition en douceur de votre abonnement on-premises existant vers l’édition cloud.
Bon patching !
Source : ManageEngine – Migrating from Patch Manager Plus On-Premises to Cloud: A practical evaluation guide