Gestion des correctifs pour MSP : une seule politique pour tous vos clients

Vous dirigez un MSP. Avec trois clients, les correctifs sont une habitude du mardi soir : vous savez quel serveur héberge le logiciel comptable, quel portable appartient à l'administrateur délégué et qui appeler quand une mise à jour bloque l'imprimante. Au dixième client, cette habitude ne suit plus. Chaque client a ses exceptions, chaque technicien approuve les mises à jour un peu différemment, et quand un client demande « sommes-nous à jour ? », la réponse vous prend un après-midi.

Cet article s'adresse aux dirigeants et responsables techniques de MSP qui veulent une seule politique de correctifs applicable à tous leurs clients : quoi approuver automatiquement, comment déployer par anneaux, comment traiter les logiciels tiers et les serveurs, et comment montrer à un client où il en est. Vous verrez à la fin comment nous le faisons dans Xcellerate RMM.

En bref

• Rédigez la politique une seule fois, par type d'appareil : postes de travail, serveurs et serveurs critiques ont chacun leur délai d'approbation, leur fenêtre d'installation et leur règle de redémarrage.
• Déployez par anneaux : vos appareils de test d'abord, puis vos machines internes, puis des clients pilotes, puis tout le monde.
• Traitez les logiciels tiers avec le même processus que le système d'exploitation, et ne redémarrez jamais automatiquement un serveur en dehors d'une fenêtre de maintenance.
• Remettez à chaque client un rapport mensuel : état des correctifs par appareil, ce qui a été installé, ce qui a échoué et ce que vous avez reporté volontairement.

Pourquoi les correctifs déraillent au dixième client

Les correctifs échouent rarement parce qu'un technicien ne sait pas comment faire. Ils échouent parce que les règles sont dans les têtes. Un technicien approuve tout le mercredi, un autre attend une semaine, un troisième saute le serveur du client qui s'est plaint d'un redémarrage l'an dernier. Rien n'est écrit, donc rien n'est cohérent, et personne ne peut montrer ce qui s'est réellement passé.

Une politique de correctifs règle ce problème. C'est un document court, et idéalement un paramètre de votre RMM, qui répond à quatre questions pour chaque appareil : quelles mises à jour sont approuvées automatiquement, après combien de jours, dans quelle plage horaire, et l'appareil peut-il redémarrer seul ? Une fois ces réponses écrites, les correctifs deviennent un processus que vous pouvez vérifier, et non plus une habitude sur laquelle vous comptez.

La politique en un tableau

Partez des types d'appareils, pas des clients. La plupart des MSP en ont besoin de trois. Les chiffres ci-dessous sont un exemple à adapter, pas une règle :

Pourquoi un délai ? Quelques jours laissent à la communauté le temps de signaler une mise à jour défectueuse avant qu'elle n'atteigne vos clients. Pourquoi des fenêtres différentes ? Les postes se mettent à jour au mieux quand les gens font une pause, les serveurs quand personne ne travaille.

Ajoutez ensuite les exceptions par client, pas par appareil : un client qui travaille en équipes de nuit reçoit une autre fenêtre pour ses postes ; un client avec une application métier fragile voit son serveur passer en classe critique. Notez chaque exception, avec sa raison.

Les anneaux : vos propres appareils d'abord

Un anneau de déploiement est un groupe d'appareils qui reçoit les mises à jour à la même étape. Une configuration simple pour un MSP en compte quatre :

1. Anneau de test : quelques appareils à vous, qui reçoivent chaque mise à jour en premier.
2. Anneau interne : le reste de votre propre bureau.
3. Anneau pilote : un ou deux clients tolérants, bien documentés, et qui savent qu'ils sont pilotes.
4. Anneau général : tous les autres.

Chaque anneau attend le précédent. Si une mise à jour casse quelque chose dans l'anneau de test ou interne, vous la bloquez avant qu'elle n'atteigne un client. Les anneaux vous donnent aussi une réponse claire quand un client demande pourquoi il n'a pas reçu une mise à jour le premier jour : c'est voulu.

Les logiciels tiers, la vraie faille

Les mises à jour du système d'exploitation sont la partie facile : Windows, macOS et Linux ont chacun leur mécanisme, et la plupart des RMM les gèrent. La faille, c'est tout le reste : navigateurs, lecteurs PDF, Java, Zoom et les autres applications que les utilisateurs installent et que personne ne met à jour.

Traitez-les comme le système d'exploitation : mêmes règles d'approbation, mêmes anneaux, mêmes fenêtres. Tenez par client la liste des logiciels tiers que vous prenez en charge, et décidez du sort des autres (les supprimer, ou les laisser au client avec une note écrite).

Serveurs : jamais de redémarrage sans fenêtre

La façon la plus rapide de perdre la confiance d'un client, c'est un redémarrage imprévu, en pleine journée, du serveur qui fait tourner son application métier. Trois règles :

• Aucun redémarrage automatique des serveurs en dehors d'une fenêtre de maintenance convenue.
• Convenez de la fenêtre par écrit avec le client, dans le fuseau horaire du client.
• Pour les serveurs critiques, prévoyez quelqu'un de disponible pendant la fenêtre pour vérifier les services après coup.

La preuve : le rapport que voit votre client

Une politique n'inspire confiance que si le client la voit fonctionner. Une fois par mois, envoyez à chaque client un court rapport de correctifs :

• État des correctifs par appareil : la part des mises à jour applicables qui est installée.
• Ce qui a été installé le mois écoulé, et ce qui a échoué.
• Ce que vous avez reporté ou bloqué volontairement, et pourquoi.
• Les appareils qui demandent de l'attention : hors ligne depuis des semaines, en attente de redémarrage ou plus pris en charge.

Parcourez-le lors de votre suivi mensuel ou trimestriel. Les correctifs cessent alors d'être un coût invisible et deviennent un service que le client voit.

Comment nous le faisons dans Xcellerate RMM

Xcellerate RMM est notre RMM : source-available sous licence FSL, sur vos propres serveurs ou dans notre cloud européen. La gestion des correctifs fait partie du cœur source-available. Voici comment la politique ci-dessus s'y retrouve :

• Systèmes d'exploitation et logiciels tiers : Windows Update, apt/yum sous Linux et softwareupdate sous macOS, plus un catalogue d'applications tierces courantes qui suivent le même processus d'approbation et de planification.
• Politiques de correctifs par groupe : approbation automatique, délais de report, fenêtres de maintenance et comportement de redémarrage, définis une fois et liés à un groupe. Des stratégies de correctifs nommées, avec leurs propres plannings et règles, s'attachent à n'importe quel agent ou groupe.
• Approuver, reporter ou bloquer par lot : passez en revue les correctifs en attente sur tout votre parc et changez leur statut en une seule opération.
• Anneaux de déploiement : choisissez l'anneau que suit chaque tenant, pour garder les premières versions loin des clients en production.
• Détail et historique par appareil : ce qui est installé, en attente ou en échec sur chaque appareil, et un journal de chaque installation avec son résultat et son heure.
• Score de conformité et rapports : le pourcentage de correctifs applicables installés par appareil ou par groupe, un compliance report exportable à partager avec le client, et une alerte quand le score passe sous un seuil que vous fixez.

La page sur la gestion des correctifs donne la vue d'ensemble, et la documentation sur la gestion des correctifs vous guide pas à pas dans la création d'une politique. Vous voulez l'héberger sur vos propres serveurs ? Le guide d'installation décrit l'installation auto-hébergée.

Vous utilisez aussi un PSA à côté de votre RMM ? Xcellerate RMM et Xcellerate OPS sont deux produits distincts, et une connexion prête à l'emploi entre les deux n'existe pas encore. RMM + PSA tout-en-un ou best-of-breed vous aide à décider ce dont votre stack a besoin.

Testez la politique sur votre propre parc : gratuit pour toujours sur vos propres serveurs, ou un essai Cloud de 14 jours. Commencer gratuitement