Comment définir des politiques techniques selon le type de client dans un MSP

La technologie stimule souvent l’imagination avec des scénarios utopiques, comme une automatisation totale digne de Star Trek ou, pour le sujet qui nous occupe, la standardisation. Ainsi, lorsque les MSP décident enfin de mettre de l’ordre dans leurs opérations, ils aspirent à un modèle technique unique applicable à tous les clients. Mais le rêve se heurte à la réalité dès la première minute, et la réalité gagne toujours. C’est alors que nous réalisons que traiter de la même manière des clients différents revient à mal homogénéiser plutôt qu’à standardiser.
Et cela génère autant de bruit que le chaos que nous voulions éliminer.
Lorsque nous standardisons, nous avons tendance à vouloir effacer les différences, mais l’essentiel est de regrouper correctement celles qui se ressemblent afin de construire des cadres reproductibles.
C’est pourquoi la première étape d’une bonne standardisation chez un MSP consiste à segmenter correctement les clients. Nous allons donc approfondir la manière d’homogénéiser les opérations sans que le prix à payer ne dépasse les bénéfices.

Pourquoi traiter tous les clients de la même manière génère des problèmes

Lorsque nous appliquons la même politique technique à un petit cabinet comptable de quartier employant cinq personnes et à l’hôpital de la région, ce modèle unique échoue simultanément aux deux extrêmes, le pire type d’incendie.
À l’extrémité supérieure, nous faisons fausse route en surveillant excessivement les clients les plus simples avec le même arsenal de contrôles, de seuils et de vérifications toutes les dix secondes que celui que mérite une infrastructure critique. C’est comme prendre une Ferrari pour aller faire ses courses, et le résultat est un tsunami de notifications sans intérêt. C’est là que nous découvrons que l’excès d’alertes ressemble à l’excès actuel de publicité : c’est le moyen le plus rapide de conditionner une équipe à ignorer les notifications, y compris celles qui comptent.
À l’extrémité inférieure, nous n’allons pas assez loin avec les clients critiques. Les politiques conçues pour ne pas noyer le petit client sous des informations inutiles sont beaucoup trop permissives pour une organisation qui ne peut pas se permettre ne serait-ce que deux minutes d’interruption. Ici, la question est celle du manque de couverture, et c’est bien pire que le bruit, car les conséquences se remarquent tard et, lorsque nous intervenons, la tumeur a déjà métastasé et nous sommes confrontés à un problème grave.
Et entre ces deux extrêmes s’installe également une facture silencieuse, que nous payons sous la forme de :

• Temps inutilement consommé, à poursuivre les faux positifs avec un filet à papillons dans des environnements qui n’avaient pas besoin de ce niveau de surveillance.
• Difficulté à justifier le service et son coût, car lorsque tous les clients paient la même chose, le client critique a le sentiment de payer trop cher, tandis que le client le plus simple estime ne bénéficier de rien de particulier. Et même si nous travaillons dans l’IT avec du silicium et des câbles, ce sont les impressions du client qui commandent.
• Une baisse de l’efficacité opérationnelle qui augmente avec chaque nouveau client gagné, au lieu de se diluer, comme on pourrait l’attendre d’une standardisation bien conçue.

En définitive, le modèle unique est aussi facile à dessiner sur un tableau blanc qu’il est coûteux à exploiter dans les tranchées du quotidien.

Quelles variables permettent de segmenter les clients dans un MSP

Alors, comment devons-nous aborder la standardisation ? J’ai déjà révélé que la première étape était la segmentation et, pour une fois, voici enfin une bonne nouvelle : il n’est pas nécessaire d’inventer les catégories au hasard.
Il existe des critères objectifs permettant une segmentation professionnelle et utile des clients MSP, notamment :

• Criticité de l’activité : que se passe-t-il réellement si le système du client tombe en panne pendant une heure ? Le cabinet de conseil peut se consacrer à autre chose ou en profiter pour prendre un café, mais l’hôpital ne le peut pas, pas plus qu’un site e-commerce lorsque le Black Friday arrive.
• Taille de l’environnement : avons-nous affaire à un jardin de dix endpoints ou à une jungle de trois mille ? Le volume change les règles du jeu et constitue un facteur clé de la segmentation.
• Maturité technique : notre client dispose-t-il de sa propre équipe capable de comprendre ce que nous surveillons, ou sommes-nous son seul service IT et la technologie lui semble-t-elle relever de la magie ?
• Obligations de sécurité ou de conformité : un client soumis à une réglementation draconienne, comme une entreprise appartenant à un secteur considéré comme stratégique par la loi, ne peut pas adopter les mêmes politiques de conservation ou d’audit que le magasin de chaussures du coin.
• Complexité de l’infrastructure : car nous gérerons des environnements homogènes aussi plats qu’une plaine, espérons-le, mais aussi des architectures hybrides associant cloud, virtualisation et une demi-douzaine de technologies qui se disputent les ressources à coups de coude.
• Type de service souscrit : la loi suprême du territoire reste ce qui a été signé. Ce que le client nous a acheté détermine donc logiquement jusqu’où s’étend notre responsabilité.
• Niveau de disponibilité attendu, qui finit presque toujours par être consigné dans un SLA (Service Level Agreement) qu’il vaut mieux respecter, car les pénalités prévues en cas de non-respect figurent généralement un peu plus bas.

En définitive, il s’agit de la Première Directive de Star Trek, selon laquelle Starfleet n’intervient pas de la même manière sur tous les mondes. Son action dépend du niveau de développement de chaque civilisation, car appliquer la même recette à une culture préindustrielle et à une autre capable de courber l’espace entraîne des conséquences funestes tous les deux épisodes.
Notre segmentation des clients doit fonctionner de la même manière. Il serait certes plus confortable de pouvoir déployer la même chose partout, mais la maturité et le contexte réel de chaque client restent prioritaires.

Quelles politiques techniques nécessitent généralement une adaptation selon le type de client

Dans la vie réelle, nous ne pouvons pas segmenter chaque détail et, pour préserver l’hygiène opérationnelle ainsi que la santé mentale de l’équipe, certaines décisions doivent rester identiques pour tous.
Cependant, il existe une série de politiques techniques que nous devrons nécessairement adapter selon le type de client dans un MSP.
Il s’agit de celles pour lesquelles un modèle unique nous causerait davantage de difficultés, notamment :

• Les politiques de supervision MSP : autrement dit, ce qui est surveillé et avec quel niveau de profondeur dans chaque environnement. Il est impossible d’unifier cet aspect. Mieux vaut donc ne pas perdre de temps à essayer et segmenter correctement dès le départ.
• Les seuils d’alerte, qui doivent se déclencher plus tôt pour un client critique et uniquement lorsqu’il existe une raison réelle pour un client plus simple.
• La fréquence des contrôles, car les paramètres d’un magasin employant trois personnes n’ont probablement pas besoin d’être mesurés à la seconde près.
• Le reporting, qui sera détaillé pour un client technique et prendra la forme, pour un responsable, d’un résumé lisible qui ne ressemble pas à un hiéroglyphe.
• Les automatisations autorisées, car nous ne pouvons pas, ou plutôt ne devons pas, laisser le système agir seul dans tous les environnements.
• Les fenêtres de maintenance, puisqu’elles dépendront de l’activité et des horaires de chaque entreprise.
• L’escalade et la réponse aux incidents, qui doivent être alignées sur la criticité et le SLA que nous avons signé.

La morale est que, même si la logique opérationnelle peut être identique pour différents clients, les paramètres qui lui donnent sa forme définitive doivent être adaptés.
En réalité, confondre la logique et les paramètres est à l’origine de bien trop de complications en matière de standardisation.

Comment standardiser sans créer une exception différente pour chaque client

Nous arrivons au cœur du sujet, car entre le modèle unique et identique pour tous et l’idée selon laquelle « chaque client est un flocon de neige particulier », il existe un juste milieu dans lequel se situe une standardisation MSP réellement efficace.
Ce point d’équilibre consiste à standardiser par groupes.
La première étape est de définir des tiers ou groupes opérationnels, c’est-à-dire un nombre réduit de catégories correspondant aux fameux service tiers d’un MSP, dans lesquels sont regroupés les clients ayant des besoins similaires.
Nous devrions en avoir entre trois et cinq au maximum.
Une fois les groupes définis, nous construisons sur cette base des modèles par typologie, c’est-à-dire des politiques techniques complètes, validées et prêtes à être déployées.
Et lorsque le modèle ne suffit pas, nous paramétrons.
Nous obtenons ainsi le meilleur des deux mondes. La logique du tier reste commune, tandis que la valeur concrète du seuil, de la fenêtre de maintenance ou du destinataire du rapport est extraite de la configuration personnalisée de chaque client.
Nous atteignons ainsi un équilibre entre uniformité et flexibilité, avec une même colonne vertébrale, mais des réglages fins différents.
C’est d’ailleurs ce qui distingue le fait de standardiser réellement les services de l’accumulation de scripts artisanaux que seule la personne qui les a écrits est capable de comprendre.
À partir de là, le mot-clé est la discipline, que nous mettons en œuvre en…

• Limitant les exceptions. Une exception ponctuelle peut constituer un correctif nécessaire, certes, mais vingt exceptions correspondent en réalité à un nouveau tier mal déguisé qu’il convient de formaliser ou de supprimer.
• Documentant les règles communes, afin que les connaissances résident dans le système et non dans les neurones peu fiables du technicien d’astreinte que la concurrence tente de recruter.
• Réévaluant régulièrement l’adéquation réelle de chaque client à son groupe, car les clients grandissent, évoluent et changent parfois même de groupe sans prévenir.
• Ne laissant pas la pression commerciale détruire le fonctionnement standard. La phrase redoutée de l’équipe commerciale, « Nous avons promis quelque chose de spécial à ce client », constitue la brèche par laquelle se vident de leur substance de nombreuses opérations MSP pourtant parfaitement conçues.

Lorsqu’elle est correctement mise en œuvre, cette approche permet de gérer des centaines de clients avec la même équipe technique sans y laisser sa peau.

Les erreurs les plus fréquentes lors de la conception de politiques par typologie

L’IT est un donjon de Dungeons & Dragons : le chemin est semé de pièges et, lorsqu’il s’agit de concevoir des politiques dans un MSP, la plupart d’entre eux viennent du fait que nous cherchons à être trop malins.
Forts de plusieurs décennies d’expérience depuis la création de Pandora, les erreurs que nous avons vu se répéter le plus souvent sont les suivantes :

• Créer trop de catégories. Si nous avons un tier pour chaque client, nous avons recréé le même chaos qu’auparavant sous un autre nom, ce qui ne sert à rien. Gardons à l’esprit la discipline évoquée dans le paragraphe précédent.
• Personnaliser trop tôt, avant de savoir si ce besoin particulier est réel ou s’il s’agit simplement d’un caprice qui disparaîtra dans trois mois.
• Ne pas examiner la rentabilité opérationnelle de chaque tier. Certains groupes demandent davantage de travail qu’ils ne génèrent de chiffre d’affaires, et il faut le détecter avant que la plaie ne vide le compte de résultat de son sang.
• Conserver sans discernement des politiques héritées, comme des configurations dont personne ne se souvient de la raison d’être, mais que tout le monde redoute de modifier.
• Mélanger les exigences commerciales et opérationnelles. Autrement dit, placer dans la même boîte ce que nous avons vendu et ce qui a réellement du sens d’un point de vue technique. Toute personne disposant d’un minimum d’expérience dans l’IT sait que toute ressemblance entre l’utopie commerciale et la réalité technique est purement fortuite. Nous devons donc surveiller très attentivement cette voie ferrée, afin que le marketing ne fasse pas dérailler notre travail avec des promesses qui ne valent rien, comme dans la chanson.
• Ne pas adapter les alertes et les automatisations au contexte, en laissant un tier hériter du bruit d’un autre qui ne lui ressemble en rien.

Ces faux pas sont proches de ceux que j’ai déjà décrits en parlant des erreurs commises lors de l’automatisation des processus dans un MSP et se résument presque toujours à un mal appelé excès de complexité déguisé en rigueur.

Ce qui change lorsqu’un MSP segmente ses politiques avec discernement

Lorsque l’exploitation multiclient d’un MSP cesse de traiter tous les clients de la même manière et commence à regrouper les contextes similaires, le changement se remarque rapidement, et de manière positive, à travers des effets concrets tels que :

• Une plus grande cohérence opérationnelle : car un même type de client reçoit un même type de service, quelle que soit la personne chargée de piloter le service pendant ce créneau.
• Moins de bruit, car chaque tier génère des alertes sur ce qui le concerne réellement, sans créer d’agitation autour de ce qui est en réalité superflu.
• Un meilleur alignement entre le service et la criticité : en trouvant un équilibre entre les ego et les budgets, puisque le client critique reçoit ce pour quoi il paie, tandis que le client plus simple ne paie pas pour ce dont il n’a pas besoin.
• Une automatisation plus sûre, en permettant au système d’agir seul uniquement lorsque le contexte l’autorise, et non partout de la même manière, en configurant un élément tout en en déconfigurant cent autres.
• Une meilleure réutilisation des modèles, que nous pourrons déployer chez de nouveaux clients similaires moyennant seulement quelques ajustements.
• Une véritable évolutivité, celle où la gestion de mille appareils ne coûte pas mille fois plus cher que celle d’un seul.

Comment Pandora FMS aide à appliquer des politiques techniques selon le type de client

Je ne sais pas s’il reste encore un domaine de l’IT dans lequel une stratégie adaptée, comme celle que nous venons de détailler, peut être mise en œuvre concrètement sans outils professionnels. Cela fait longtemps que nous avons cessé d’être des artisans, et c’est précisément là que Pandora FMS et Pandora SIEM permettent au modèle de tiers de devenir une réalité pratique au lieu de rester cantonné à une présentation PowerPoint.
Tout d’abord, parce qu’ils nous permettent de travailler avec des modèles et des politiques réutilisables, qui constituent la colonne vertébrale de la stratégie.
Nous définissons ainsi une seule fois la logique de chaque tier, puis nous l’appliquons à tous les clients appartenant à ce groupe, qui héritent automatiquement de la configuration.
Cette segmentation par groupes est native. Chaque contrat obtenu et chaque tier restent donc organisés et isolés, avec une paramétrisation propre à chaque client permettant d’ajuster les seuils ou les fenêtres de maintenance sans modifier la structure ni casser le modèle de base.
Au-dessus de tout cela plane une supervision centralisée de l’infrastructure, tel un aigle capable de repérer sa proie à plusieurs kilomètres depuis notre Metaconsole. Elle constitue le tant attendu single pane of glass depuis lequel nous pouvons contempler l’ensemble de l’exploitation multiclient sans passer constamment d’une console à l’autre, réalisant ainsi nos fantasmes de domination.
À cela s’ajoutent :

• Des tableaux de bord et des rapports adaptables au profil de chaque client.
• Une gestion des événements et des alertes affinée par tier.
• Une couche de sécurité avec Pandora SIEM pour les clients soumis à des obligations de conformité, que le client le plus simple n’envisage même pas et dont il n’a pas besoin.

En définitive, il s’agit exactement de ce qui est nécessaire et qui a déjà été éprouvé auprès de clients et dans des opérations réelles, pour détecter les incidents avant qu’ils n’affectent le client et réduire les heures de support sans affecter le SLA.
Récapitulons l’essentiel.
La réalité est qu’un MSP ne peut pas évoluer en traitant tous ses clients de la même manière, même si le dire manque quelque peu de diplomatie.
La clé d’une croissance réelle réside dans le regroupement de contextes similaires et dans l’application de politiques reproductibles qui respectent leurs différences réelles sans multiplier les exceptions.
Standardiser de manière optimale consiste à domestiquer la diversité sans l’éliminer et sans la laisser nous emporter comme un cheval emballé. Cela revient à passer du chaos artisanal dans lequel chaque client constitue un univers à part entière, une philosophie séduisante mais impraticable, à un nombre limité de cadres clairs dans lesquels chaque client trouve sa place.
C’est ainsi que nous atteindrons l’Olympe des MSP capables de survivre sans accumuler les catastrophes jusqu’à ce qu’il ne reste plus aucune main pour y remédier.