Empêcher le support réactif de réduire la marge du MSP

La marge bénéficiaire d’un Managed Service Provider (MSP) est un animal délicat. Elle ne disparaît généralement pas à cause d’un grand désastre, d’une faille de sécurité ou de la perte de ce client important, mais elle meurt le plus souvent par mille coupures invisibles qui la vident de son sang, sans remède. Une érosion constante qui est souvent provoquée par un support réactif et qui, si elle n’est pas surveillée, transforme un modèle qui pourrait être scalable en une odyssée pour sauver le Titanic.
Pour cette raison, les directeurs des opérations et les CTO se focalisent souvent sur le volume : « Nous avons trop de tickets » est le refrain habituel en réunion, mais le volume est le symptôme. Le défi qui se cache derrière et qui allume ses cigares avec nos billets, c’est la variabilité incontrôlée et la normalisation du chaos au quotidien.
Si chacun, dans l’équipe, mène sa propre guerre et passe ses journées à écoper, personne n’a le temps de réparer les fissures de la coque.
Et en gestion IT, l’entropie finit toujours par l’emporter : analysons donc le sujet en profondeur afin d’identifier les meilleures pratiques qui préservent des marges bénéficiaires saines dans notre MSP.

Ce que signifie réellement le « support réactif » dans un MSP

Pour protéger nos marges, il faut d’abord écouter Sun Tzu et son Art de la guerre et connaître l’ennemi, en élaborant une stratégie globale avant de se jeter dans les tactiques et les techniques.
Le support réactif s’incarne surtout en trois cavaliers de l’apocalypse opérationnelle :

• Incidents réels avec impact : Comme le serveur qui décide de cesser de respirer à trois heures du matin, ou la base de données qui se corrompt. Ces incidents sont inévitables, car telle est la vie en IT, mais leur fréquence et leur durée déterminent notre survie.
• Le bruit de fond : Une information qui gêne au lieu d’aider, comme des alertes mal conçues, sans contexte, ou tout simplement inutiles. C’est l’équivalent de l’ordinateur de l’Enterprise qui déclenche l’alerte rouge dès qu’il détecte un vaisseau. Si tout est critique, rien ne l’est, et le temps des techniciens se consume à écarter des déchets.
• Des demandes utilisateurs déguisées en incidents : « Le mail ne fonctionne pas » se traduit souvent par « j’ai oublié mon mot de passe pour la quatrième fois ». Traiter ces demandes avec le même flux de travail qu’une chute de réseau relève du suicide économique.

Si nous ne gérons pas ces catégories de manière optimale, il sera impossible d’arrêter l’hémorragie de nos marges. Nous gaspillerons des heures d’ingénieurs seniors à redémarrer des services ou à réinitialiser des mots de passe, et c’est la manière la plus rapide de faire cesser l’équilibre des comptes.

La marge bénéficiaire d’un Managed Service Provider (MSP) est un animal délicat. Elle ne disparaît généralement pas à cause d’un grand désastre, d’une faille de sécurité ou de la perte de ce client important, mais elle meurt le plus souvent par mille coupures invisibles qui la vident de son sang, sans remède. Une érosion constante qui est souvent provoquée par un support réactif et qui, si elle n’est pas surveillée, transforme un modèle qui pourrait être scalable en une odyssée pour sauver le Titanic.
Pour cette raison, les directeurs des opérations et les CTO se focalisent souvent sur le volume : « Nous avons trop de tickets » est le refrain habituel en réunion, mais le volume est le symptôme. Le défi qui se cache derrière et qui allume ses cigares avec nos billets, c’est la variabilité incontrôlée et la normalisation du chaos au quotidien.
Si chacun, dans l’équipe, mène sa propre guerre et passe ses journées à écoper, personne n’a le temps de réparer les fissures de la coque.
Et en gestion IT, l’entropie finit toujours par l’emporter : analysons donc le sujet en profondeur afin d’identifier les meilleures pratiques qui préservent des marges bénéficiaires saines dans notre MSP.

Ce que signifie réellement le « support réactif » dans un MSP

Pour protéger nos marges, il faut d’abord écouter Sun Tzu et son Art de la guerre et connaître l’ennemi, en élaborant une stratégie globale avant de se jeter dans les tactiques et les techniques.
Le support réactif s’incarne surtout en trois cavaliers de l’apocalypse opérationnelle :

• Incidents réels avec impact : Comme le serveur qui décide de cesser de respirer à trois heures du matin, ou la base de données qui se corrompt. Ces incidents sont inévitables, car telle est la vie en IT, mais leur fréquence et leur durée déterminent notre survie.
• Le bruit de fond : Une information qui gêne au lieu d’aider, comme des alertes mal conçues, sans contexte, ou tout simplement inutiles. C’est l’équivalent de l’ordinateur de l’Enterprise qui déclenche l’alerte rouge dès qu’il détecte un vaisseau. Si tout est critique, rien ne l’est, et le temps des techniciens se consume à écarter des déchets.
• Des demandes utilisateurs déguisées en incidents : « Le mail ne fonctionne pas » se traduit souvent par « j’ai oublié mon mot de passe pour la quatrième fois ». Traiter ces demandes avec le même flux de travail qu’une chute de réseau relève du suicide économique.

Si nous ne gérons pas ces catégories de manière optimale, il sera impossible d’arrêter l’hémorragie de nos marges. Nous gaspillerons des heures d’ingénieurs seniors à redémarrer des services ou à réinitialiser des mots de passe, et c’est la manière la plus rapide de faire cesser l’équilibre des comptes.

Où se perd la marge : la mécanique économique du désastre

Continuons à analyser l’adversaire, en zoomant du général vers des aspects concrets sur lesquels nous devrons agir.
La marge ne disparaît pas par magie ; elle se consume dans des processus physiques et cognitifs qui apparaissent rarement dans les rapports mensuels si nous ne savons pas où regarder.

Parmi ces processus habituels dans un MSP :

1. Heures non planifiées et déplacement de la valeur

Chaque fois qu’un technicien doit abandonner une tâche d’amélioration ou un déploiement planifié pour éteindre un incendie réactif, le coût ne se limite pas à l’heure payée pour cette intervention, et nous devons l’intégrer si nous voulons quantifier correctement les pertes.
En tant que gestionnaires, nous devons également prendre en compte le coût d’opportunité, un concept économique qui me rappelle mes anciens cours universitaires.
Cela signifie que les choses ne coûtent pas seulement ce que nous payons à nos techniciens MSP, mais aussi ce que nous cessons de gagner ou les économies que nous aurions réalisées si, au lieu d’agir comme des pompiers, ces techniciens construisaient une infrastructure proactive et prédictive (qui éviterait nombre de ces incidents dès le départ).
Cette manière de travailler économise des milliers d’euros par mois en incidents qui ne se produisent même pas, tout en générant des gains de productivité et donc des marges de plus en plus larges.
Mais si notre MSP ressemble à une caserne de pompiers, le travail productif est déplacé, les délais s’allongent et l’efficacité opérationnelle s’effondre.

2. La mauvaise allocation de la séniorité

C’est le péché originel de nombreux MSP : utiliser une Ferrari pour aller faire les courses. Autrement dit, des ingénieurs L3 (coûteux, rares et à forte valeur stratégique) qui passent leurs journées à résoudre des incidents qui devraient être automatisés ou gérés par « le stagiaire » et une bonne base de connaissances.
Chaque fois qu’un senior effectue le travail d’un junior, la marge de ce contrat s’évapore.

3. Le poison du changement de contexte

Un technicien qui passe d’un client à l’autre et de cinq technologies différentes dans une seule matinée n’est pas productif ; il essaie simplement d’éviter l’explosion mentale.
Multiplions cela par le nombre de tickets réactifs et nous identifierons un autre gouffre par lequel la marge s’échappe.

4. Le « re-travail » dû à l’absence de standards

Si chaque client est un « flocon de neige spécial » avec sa configuration artisanale et ses scripts personnalisés, le support réactif devient exponentiellement coûteux.
Sans standards robustes, chaque diagnostic devient une enquête menée depuis zéro, et ce « re-travail » est l’antithèse de la rentabilité.

Les principaux signes que le support dévore notre rentabilité

Je suis le premier à ne pas reconnaître mes problèmes, et nous avons tous ce point aveugle. Mais lorsqu’il s’agit de perdre de la marge dans un MSP, nous avons la chance de pouvoir le détecter sans attendre le rapport trimestriel.
Parmi les symptômes les plus fréquents :

• Tickets répétitifs sans analyse de la cause racine : Si la même erreur chez le même client apparaît trois fois par semaine et que la solution est toujours « redémarrer le service », nous ne faisons pas du support, nous sommes un correctif humain.
• Des pics de charge imprévisibles : Si le lundi la chaudière est sur le point d’exploser et que le jeudi des buissons roulants traversent le serveur comme dans un western, notre capacité de planification est inexistante. La variabilité est l’ennemi de l’échelle.
• Mode urgence permanent : Si le cortisol de l’équipe déborde en permanence, le moral chute et la rotation augmente. Le coût du recrutement et de l’intégration d’un nouveau technicien est un coup dur porté à la marge que peu intègrent dans leurs feuilles de calcul.

Comment mesurer si nous récupérons de la marge dans le MSP

« Tout le monde a un plan jusqu’à ce qu’il reçoive un coup de poing dans la bouche. » Peu de phrases sont aussi vraies que celle du philosophe Mike Tyson. C’est pourquoi tout ce qui précède doit être mesuré afin de vérifier si les bonnes intentions deviennent réalité ou si elles ont été mises KO dès le départ.
Et puisque nous parlons ici de marges, nous devons oublier les métriques de vanité pour nous concentrer sur des indicateurs ayant un lien direct avec l’argent :
Bien que les KPI spécifiques dépendent de la nature de chaque activité, voici quelques indicateurs à considérer :

• Nombre de tickets par endpoint : S’il diminue, la proactivité fonctionne.
• Pourcentage de tickets répétitifs : Indicateur clair de notre capacité à traiter les causes racines plutôt qu’à poser des pansements sur les symptômes.
• Pourcentage d’escalades vers L2/L3 : S’il diminue, nous optimisons mieux notre structure de coûts en évitant que nos techniciens les mieux rémunérés ne passent leur temps à brancher et débrancher.
• Temps moyen de résolution (MTTR) par type de ticket : Bien que le MTTR global soit utile à un niveau macro, nous avons ici besoin d’une analyse plus fine, comme le MTTR par type de ticket, afin de savoir combien coûte réellement la résolution de ce qui importe.
• Ratio travail non planifié vs planifié : Même si son calcul peut être complexe selon l’organisation du MSP, il s’agit probablement de la métrique reine. Plus la part de travail planifié est élevée, plus notre opération en tant que MSP sera saine (et rentable).

Le chemin vers l’efficacité

Il n’existe pas de solution miracle pour protéger la marge opérationnelle, mais il existe une méthode. Cet article n’est que la partie émergée de l’iceberg d’une stratégie complète, dont nous avons développé les principaux éléments dans notre pôle d’opérations MSP.
Si vous souhaitez approfondir, nous vous recommandons d’explorer nos contenus spécialisés :

• Réduire les heures de support dans un MSP sans perdre les SLA : Avec des stratégies concrètes pour optimiser la charge de travail.
• Détecter les incidents avant qu’ils n’impactent le client MSP : Ou comment passer d’un mode réaction permanent à la prédiction et à la prévention des incidents avant qu’ils ne surviennent.
• Standardiser les services MSP sans dépendre de scripts manuels : Le chemin vers une infrastructure reproductible et rentable, en laissant derrière soi les solutions artisanales.
• Opérer des centaines de clients MSP avec la même équipe technique : Où nous approfondissons l’art (ce n’est pas vraiment de l’art, mais presque) d’évoluer à l’échelle sans multiplier les coûts.
• Rompre la dépendance du MSP envers des techniciens indispensables : Afin de garantir que leur connaissance (et la possibilité qu’ils partent un jour chez un concurrent) ne devienne pas un goulet d’étranglement.

Le support réactif est un parasite qui absorbe la rentabilité, et le succès dans la préservation de la marge ne se mesure pas aux incendies éteints, mais aux incendies évités.
Mais tant que le support réactif ne sera pas l’exception et non la règle, nos marges continueront de se réduire.