Comment exploiter un MSP à grande échelle : croître sans compromettre le support ni les SLA

Grandir fait mal, comme le disait cette ancienne série avec Kirk Cameron dont seuls les plus anciens se souviennent. C’est l’une de ces vérités (celle sur la croissance, pas sur l’âge) que personne ne mentionne lors des réunions stratégiques remplies de graphiques ascendants et de toasts aux nouveaux clients. Mais dans les tranchées d’un Managed Service Provider (MSP), une croissance incontrôlée ressemble davantage à une lente asphyxie qu’à une victoire.

Vu d’en haut, la musique est toujours la même : « Ce n’est pas grave, si nous obtenons dix nouveaux clients, nous embauchons deux techniciens supplémentaires. » Mais la réalité ne fonctionne pas avec des équations aussi simples, et la croissance implique nécessairement un chaos imprévisible et non linéaire.

Ce qui, avec cinq clients, n’est qu’une petite gêne (« Javier doit vérifier et redémarrer manuellement les services chaque jour, parce que l’utilisateur est la force la plus destructrice de l’univers »), avec cinquante clients devient pousser la pierre de Sisyphe en haut de la colline.

Scaler un MSP ne consiste pas à accumuler davantage de personnes dans la bataille du Service Desk comme au Moyen Âge. Il s’agit de changer les règles du jeu afin que la charge de travail ne dépende pas du nombre d’actifs gérés.

Si pour doubler le chiffre d’affaires nous devons doubler les effectifs, nous n’avons pas un modèle scalable, mais un cabinet de conseil déguisé qui, tôt ou tard, dévorera sa marge.

Le véritable défi de la croissance dans les MSP

Il existe un point d’inflexion dans le cycle de vie de tout prestataire de services. Au départ, le « mode héros » fonctionne. Vous avez deux techniciens brillants qui connaissent par cœur le mot de passe du firewall du client A et les cartes perforées du System/370 que le client B n’a pas débranché depuis 1978. Le service est personnel, rapide… et artisanal.

Puis le succès arrive, cause fréquente de disparition de nombreuses initiatives, car il entraîne davantage de tickets, d’alertes et d’urgences.

Soudain, le « mode héros » devient le goulet d’étranglement.

Ces techniciens brillants n’ont plus le temps d’implémenter des améliorations, gaspillant leur savoir avancé à écoper l’eau. De plus, cette connaissance reste enfermée dans leurs têtes, les transformant de génies en points uniques de défaillance.

Si Javier tombe malade, le client B panique et même IBM ne sait plus parler System/370.

Les MSP chutent généralement à cause de conceptions opérationnelles médiocres, et non par manque de talent.

Cela s’explique par le fait qu’ils opèrent sous un modèle de support réactif et attendent que quelque chose casse avant de le réparer. À petite échelle, cela reste gérable ; à grande échelle, c’est un hara-kiri.

Croître sans transformer l’opération est la manière la plus rapide de détruire la réputation qui nous a permis de croître au départ.

Grandir fait mal, comme le disait cette ancienne série avec Kirk Cameron dont seuls les plus anciens se souviennent. C’est l’une de ces vérités (celle sur la croissance, pas sur l’âge) que personne ne mentionne lors des réunions stratégiques remplies de graphiques ascendants et de toasts aux nouveaux clients. Mais dans les tranchées d’un Managed Service Provider (MSP), une croissance incontrôlée ressemble davantage à une lente asphyxie qu’à une victoire.

Vu d’en haut, la musique est toujours la même : « Ce n’est pas grave, si nous obtenons dix nouveaux clients, nous embauchons deux techniciens supplémentaires. » Mais la réalité ne fonctionne pas avec des équations aussi simples, et la croissance implique nécessairement un chaos imprévisible et non linéaire.

Ce qui, avec cinq clients, n’est qu’une petite gêne (« Javier doit vérifier et redémarrer manuellement les services chaque jour, parce que l’utilisateur est la force la plus destructrice de l’univers »), avec cinquante clients devient pousser la pierre de Sisyphe en haut de la colline.

Scaler un MSP ne consiste pas à accumuler davantage de personnes dans la bataille du Service Desk comme au Moyen Âge. Il s’agit de changer les règles du jeu afin que la charge de travail ne dépende pas du nombre d’actifs gérés.

Si pour doubler le chiffre d’affaires nous devons doubler les effectifs, nous n’avons pas un modèle scalable, mais un cabinet de conseil déguisé qui, tôt ou tard, dévorera sa marge.

Le véritable défi de la croissance dans les MSP

Il existe un point d’inflexion dans le cycle de vie de tout prestataire de services. Au départ, le « mode héros » fonctionne. Vous avez deux techniciens brillants qui connaissent par cœur le mot de passe du firewall du client A et les cartes perforées du System/370 que le client B n’a pas débranché depuis 1978. Le service est personnel, rapide… et artisanal.

Puis le succès arrive, cause fréquente de disparition de nombreuses initiatives, car il entraîne davantage de tickets, d’alertes et d’urgences.

Soudain, le « mode héros » devient le goulet d’étranglement.

Ces techniciens brillants n’ont plus le temps d’implémenter des améliorations, gaspillant leur savoir avancé à écoper l’eau. De plus, cette connaissance reste enfermée dans leurs têtes, les transformant de génies en points uniques de défaillance.

Si Javier tombe malade, le client B panique et même IBM ne sait plus parler System/370.

Les MSP chutent généralement à cause de conceptions opérationnelles médiocres, et non par manque de talent.

Cela s’explique par le fait qu’ils opèrent sous un modèle de support réactif et attendent que quelque chose casse avant de le réparer. À petite échelle, cela reste gérable ; à grande échelle, c’est un hara-kiri.

Croître sans transformer l’opération est la manière la plus rapide de détruire la réputation qui nous a permis de croître au départ.

Les principaux freins à la scalabilité opérationnelle

Il est facile de prêcher depuis la chaire de la théorie, je le sais, mais en pratique, scaler n’est pas un chemin en descente et nous rencontrerons des mines, dont certaines auront été posées par nous-mêmes.
Pour les éviter, voici des schémas récurrents observés chez les MSP stagnants :

1. Le culte du support réactif

L’adrénaline est très addictive et il existe une satisfaction immédiate à éteindre un incendie. Le client vous remercie si vous êtes rapide, vous vous sentez utile, vous avez démontré vos compétences et prouvé au management intermédiaire que l’IA le remplacera avant de vous remplacer.
Mais vivre d’adrénaline épuise et vivre en mode réaction empêche la prévention.
Si notre équipe passe 80 % de son temps à réagir aujourd’hui, personne ne construit l’infrastructure qui évitera ces incendies demain.

2. La dépendance au savoir personnel et aux génies habituels

« Demande à Luis, c’est lui qui sait comment ça fonctionne. »
Voilà la sentence de mort de la scalabilité et une goutte de plus dans le verre de Luis, qui, entre deux urgences, met à jour son CV.
Si la connaissance n’est pas documentée dans une Wiki ou une base de connaissances complète et à jour, la rotation du personnel ira à Warp 8 et l’intégration des nouveaux prendra une éternité.

3. Outils fragmentés

Un outil de monitoring pour les réseaux, un autre pour les sauvegardes, quelqu’un conserve les mots de passe dans un Excel en violation de multiples réglementations, et le logiciel de ticketing est un open source non maintenu parce que l’ancien CTO pensait économiser.
L’absence d’une « source unique de vérité » oblige les techniciens à passer d’une console à l’autre, perdant du contexte et du temps à chaque changement.
Sans vision centralisée, l’automatisation est impossible.

4. Manque de standardisation (le syndrome du « sur-mesure »)

Dire oui à chaque exigence de chaque client est une stratégie commerciale tentante au début, parfois même valable, mais elle devient désastreuse sur le plan opérationnel et financier à long terme.
Si chaque client possède une configuration de sauvegarde différente et une politique de sécurité unique, nous gérerons en permanence des exceptions sans pouvoir automatiser quoi que ce soit.

Les piliers d’une opération MSP à grande échelle

Lorsque Homer Simpson est engagé par Hank Scorpio pour optimiser ses opérations de domination mondiale, sa stratégie principale consiste à dire aux techniciens de faire plus vite ce qu’ils sont en train de faire.
Ils serrent les dents et s’activent, mais cette stratégie ne dure que cinq minutes.

Pour sortir du cycle réactif et construire une opération capable de croître, nous devons atteindre les objectifs suivants :

1. Réduction du support réactif grâce à la détection précoce

La seule bonne incidence est celle qui ne s’ouvre jamais en tant que ticket.
La monitorisation moderne ne doit pas se limiter à indiquer qu’un serveur est tombé (ce qui arrive toujours trop tard) ; elle doit nous alerter lorsque les schémas d’usage indiquent qu’il va tomber dans deux heures.
Détecter la dégradation du service avant le client est la seule manière de protéger les SLA et la santé cardiaque de l’équipe.

2. Standardisation technique et des processus

La productisation des services s’est récemment popularisée et nous devons nous inspirer de cette philosophie d’entreprise.
Idéalement, nous devrions vendre des produits plutôt que des projets, car les premiers scalent par nature, tandis que les seconds non.

Définir un stack technologique standard et des politiques de configuration de base pour tous les clients permet de mettre en place des scripts et des processus de maintenance valables pour 500 machines comme pour 5.
La standardisation est le préalable à l’automatisation, à l’image de McDonald’s ou Burger King.

Leurs processus sont tellement standardisés que lorsqu’une personne part et qu’un novice la remplace, le goût des frites ne change pas, car elles sont toujours préparées de la même façon. Le nouveau n’a qu’à suivre des étapes prédéfinies conformes aux meilleures pratiques.

3. Automatisation à impact réel

L’automatisation n’est pas une mode, mais une approche consistant à identifier des tâches répétitives à faible valeur (nettoyage de disques, redémarrage de services, déploiement de correctifs…) et à les confier aux machines.
Cette automatisation a un impact mesurable : des heures de techniciens libérées.
Si un bot basé sur un LLM correctement entraîné peut résoudre 30 % des tickets simples de niveau 1, nous scalons de 30 % sans recruter.

4. Des outils adaptés aux MSP, pas seulement modernes

Les outils de monitoring et de gestion font toute la différence, mais nous n’avons pas besoin de celui qui possède le plus de voyants lumineux. Nous avons besoin d’outils conçus pour les MSP permettant une gestion multi-clients simple.
La ségrégation des données, les permissions granulaires et la capacité d’appliquer des politiques globales ou spécifiques par client sont des fonctions critiques pour ne pas perdre le contrôle en passant de 10 à 100 clients.

5. Mesure continue et obsessionnelle

Il ne s’agit plus seulement de dire que l’on ne peut pas gérer ce que l’on ne mesure pas ; ce que l’on ne mesure pas se détériore aussi, comme une pièce où l’on ne met jamais les pieds.
Cela dit, il faut mesurer les bonnes choses, pas celles qui flattent l’ego.
Peu importe combien de tickets nous fermons ; ce qui importe, c’est combien nous en recevons par endpoint. De même, le véritable MTTR et la rentabilité par client sont essentiels.

Une opération à grande échelle se pilote avec des données, pas avec des sensations. Ou des « vibes », comme on dit aujourd’hui.

Le chemin vers l’efficacité opérationnelle

Détailler toutes les étapes vers cette efficacité opérationnelle transformerait cet article en Le Seigneur des Anneaux.

C’est pourquoi nous avons créé un cluster de contenus abordant en détail les domaines clés où se joue la bataille de la scalabilité dans un MSP, et expliquant comment :

• Réduire les heures de support dans un MSP sans perdre les SLA : En redéfinissant nos opérations pour diminuer la charge de travail sans éroder les engagements contractuels.
• Standardiser les services MSP sans dépendre de scripts manuels : En évoluant de solutions artisanales vers des politiques techniques reproductibles entre clients.
• Éviter que le support réactif ne consume la marge du MSP : Ou comment colmater les fuites par lesquelles la rentabilité se perd en raison d’une mauvaise structure opérationnelle.
• Détecter les incidents avant qu’ils n’impactent le client MSP : En utilisant la monitorisation proactive et la corrélation pour prédire les pannes avant qu’elles ne surviennent, comme Tom Cruise dans *Minority Report*.
• Démontrer la valeur au client MSP grâce à des rapports automatiques : En transformant des données techniques en rapports compréhensibles même pour le CEO.
• Opérer des centaines de clients MSP avec la même équipe technique : En construisant un véritable modèle multi-clients, avec ségrégation par ACL, opérations centralisées et procédures standardisées.
• Éliminer l’erreur humaine dans les maintenances massives du MSP : Ou comment identifier et optimiser des processus critiques qui ne devraient pas dépendre du jugement du technicien de service.
• Unifier les outils dans un MSP sans perturber l’opération quotidienne : En améliorant les coûts, les délais et la fiabilité grâce à la consolidation de plateformes dispersées.
• Scaler un MSP sans redessiner son architecture existante : En expliquant comment croître en endpoints sans reconstruire l’infrastructure.
• Rompre la dépendance du MSP envers des techniciens indispensables : En utilisant la standardisation et la traçabilité comme bases de la continuité de service.

La scalabilité et sa relation avec les autres domaines clés du MSP

Une opération à grande échelle ne doit pas être une île, mais être reliée par des vases communicants au reste de la stratégie technique et à ses dimensions :

• Automatisation et standardisation : Le moteur de la scalabilité. Sans elles, l’opération est manuelle et donc limitée et hétérogène.
• Architecture multi-clients : La structure qui soutient le service et détermine s’il fonctionne avec l’efficacité et le professionnalisme du Star Trek classique ou comme le désastre du nouveau Star Trek. Oui, je fais partie de ceux-là.
• Sécurité opérationnelle : Plus l’échelle est grande, plus la surface d’attaque est importante. À une époque où chaque jour apporte de plus mauvaises nouvelles que le précédent, la sécurité n’est plus optionnelle — c’est une question de survie.

Scaler un MSP ne relève pas de la taille — même si cela compte dans d’autres domaines de la vie — ni de la force brute, mais d’un design intelligent.

Une opération bien construite, soutenue par des outils qui comprennent la nature multi-clients du métier (comme Pandora FMS), permet de rendre possible ce qui semble impossible :

• Augmenter le nombre de clients.
• Améliorer les SLA.
• Réduire le stress de l’équipe technique.

L’objectif n’est pas seulement de gagner davantage d’argent (même si cela compte, soyons honnêtes), mais de reprendre le contrôle. Cesser d’être esclaves des alertes pour devenir maîtres de la technologie.

Car si la technologie ne travaille pas pour nous, alors nous travaillons pour la machine. Et c’est ainsi que Skynet nous dominerait de la manière la plus ennuyeuse possible.